Abstract
Internet of Things (IoT) and cloud computing are increasingly integrated, in the sense that data collected from IoT devices (generally with limited computational and storage resources) are being sent to the cloud for processing, etc., in order to inform decision making and facilitate other operational and business activities. However, the cloud may not be a fully trusted entity, like leaking user data or compromising user privacy. Thus, we propose a privacy-preserving and user-controlled data sharing architecture with fine-grained access control, based on the blockchain model and attribute-based cryptosystem. Also, the consensus algorithm in our system is the Byzantine fault tolerance mechanism, rather than Proof of Work.
1. Introduction
The Internet of Things (IoT) has many applications in a wide range of industries and settings, such as smart homes and intelligent transportation systems, as well as in consumer applications (e.g., medical and health-care equipment) [1, 2]. One typical role of IoT devices (e.g., sensors and smart devices) is to collect and transmit (the collected) data via the Internet, like further processing and statistical analysis. However, IoT devices are generally resource-constrained, for example, having limited computational and storage resources. Thus, there has been a trend for integrating IoT and the cloud, to which data storage, processing, and sharing functionalities are being outsourced [3, 4].
As shown in Figure 1, Owner1 can store and share the collected data with Owner2 via the cloud to minimize costs. However, there is a risk that data and user’s privacy may be leaked and compromised since the cloud is not fully trusted (i.e., semitrusted). Although there exists many privacy-preserving data processing solutions (e.g., utilizing cryptographic tools based on access control policies [5, 6]) for cloud storage systems, these approaches are vulnerable to attacks at the cloud end (e.g., access control policies may be tampered or deleted by a malicious cloud service provider or its employee).
Blockchain is a distributed ledger technology that underpins Bitcoin [7] and has been used in many other decentralized applications, such as digital currency [8, 9], data storage [10, 11], data provenance [12], Internet of Things [13–16], and so on. In this paper, we posit the potential of integrating blockchain with attribute-based cryptosystems [17, 18] in the design of a privacy-preserving and user-controlled solution to IoT data sharing. In other words, users can independently decide who can share their data without compromising data and identity privacy. Specifically, in our proposed BaDS (Blockchain-Based Architecture for Data Sharing with ABS and CP-ABE in IoT) architecture:(i)IoT data are first encrypted (e.g., ). Then, we integrate smart contract technology with an attribute encryption scheme [19] to realize its fine-grained sharing. The access policies are set on the encrypted key (the encrypted key are encrypted by attributes, ABE) to decide who can obtain this encrypted key to decrypt the ciphertext.(ii)The smart contract used in our architecture is to ensure the scalability of access control table. All the data sharing (or access) requests in the system interact with smart contracts through transactions (e.g., smart contract in Section 3.5).
The rest of the paper is organized as follows: In Section 2, we present the relevant cryptographic techniques, monotone span program, the network model, and security requirements. In Section 3, we briefly introduce ABS, CP-ABE, PACT, PBFT, and smart contract. After that, we describe our BaDS architecture and its security analysis in Section 4. In Section 5, we describe our evaluation of the proposed architecture, prior to concluding the paper in the last section.
2. Preliminaries
In this section, we will introduce the cryptographic techniques, monotone span program, the network model of our propose BaDS architecture, and the security requirements that need to be satisfied.
2.1. Bilinear Pairings
We define and as two additive cyclic groups on elliptic curve , as a multiplication cyclic group. Let be a big prime number, which is the order of , , and . denote a bilinear map. Suppose that the generators of and are and ; is the element that and map to . Thus, the map is a bilinear pairing on condition that satisfies the following properties:(i)Bilinearity. Given any two elements , and , there is .(ii)Nondegenerate. There exists at least one element which satisfies .(iii)Efficient Computability. Given any two elements , there exists at least one efficient algorithm to compute .
We define the computationally hard mathematical problems.(i)Discrete Logarithm (DL) Problem. Given an element or , for any P.P.T. (probability polynomial time) attacker, it is computationally hard to calculate which satisfies or .(ii)Computational Diffie-Hellman (CDH) Problem. Given a tuple in which , , and are the generators of , , and , respectively. The purpose of CDH problem is to compute , in which are unknown.
2.2. Monotone Span Program
Let as a monotone Boolean function. For an matrix over a filed and every , a monotone span program is defined as follows: in which and the labeling function . That means if and only if the index to the rows of matrix spans the vector . We say the length and width of span program are and , and the size of it is .
2.3. Network Model
Our BaDS architecture consists of the following participants: IoT devices, Data Owner, Blockchain Network, and Cloud; see Figure 2.
In the BaDS architecture, the following steps are undertaken to request data between devices.
At first, owner sends the encrypted devices’ data to the cloud and generates the responding access control table in the smart contract. When other device (e.g., device belonging to owner ) wants to access the data, it invokes the getPACT algorithm in the smart contract to obtain the predicates. If its attributes satisfy the predicates, then it sends a responding transaction to the smart contract with an attribute-based signature. If the signature can be successfully verified, then the device can receive the encrypted private key (CP-ABE).
Then, the device sends a request containing an attribute-based signature to the cloud to obtain the requested data. On receiving the request, the mutual authentication and session key between the cloud and device will be established by executing the existing authentication key agreement protocol [20]. After both sides have mutual authenticated each other, the device can get the encrypted data through the “secure channel” protected by the session key.
If the signature cannot be verified, it implies that the attributes of the device do not satisfy the policy of the data. Thus, owner should sends a request for data access to owner . Both owners will authenticate each other and generate a session key through the existing authentication key agreement protocol, and the session key is used to guarantee the subsequent session. If owner permits the access from the device of , he/she will send a transaction to the smart contract to update the access control table and the device can obtain the data from the cloud as before. Otherwise, rejects the request.
2.4. Security Requirement
Based on recent literatures [20–22], the blockchain-based architecture for data sharing with ABS and CP-ABE needs to satisfy the following security requirements:(1)Confidentiality. To protect the privacy of data, in this architecture, only devices which satisfy the attribute policy can access the data and get the corresponding decryption key.(2)Fine-Grained Access Control. The data manager or authority generate the corresponding access policy for their data, and they can grant or revoke devices’ access on a fine-grained basis, by modifying the access attributes.(3)Mutual Authentication. To protect the safety of participants, our system should provide mutual authentication. The participants should authenticate their communicating partner.(4)User Anonymity. To preserve privacy, the architecture should protect the device’s anonymity. Even if the adversary analyzes a series of transactions, (s)he cannot learn the devices’ real identity.(5)Impersonation Attack Resilience. If the adversary impersonates a legitimate device and sends a request to the cloud, it cannot be authenticated due to the invalid attribute signature.(6)Collision Attack Resilience. There is an extremely small possibility of generating two identical blocks at the same time. Thus, the system should resist collision attack.(7)Man-in-the-Middle Attack Resilience. The device can identify and abandon the messages transmitted in the open environment, which have been intercepted or replaced by the adversary.(8)Link Attack Resilience. Even if the adversary links multiple transactions which use the same address or public key, the adversary also cannot find users’ private messages.
3. Definitions and Security Model
We briefly introduce the attribute-based signature, ciphertext-policy attribute-based encryption, permission access control table to generate the attribute policy, and PBFT (the consensus algorithm) used in our architecture, in this section.
3.1. Attribute-Based Signature (ABS)
In the attribute-based signature scheme, the devices are tagged with a set of attributes whose certificates are issued by an attribute center [23]. Due to the fact that ABS scheme can provide fine-grained access control, we use ABS in our architecture to replace the original ECDSA signature in the blockchain.
A signature consists of elements, where is the width of the monotone span program of the claim-predicate [24]. The maximum width of monotonic span program is defined as , and , in which is a big prime number and also the order of the cyclic group.(i). Let , , and denote two cyclic groups and a bilinear map, respectively, where the order of cyclic groups is . Suppose and are the generators of and , where . Choose a hash function . Thus, the public parameters are .(ii). Randomly choose four numbers and compute: , , , and , . Thus, the master key is , and the public key is .(iii). Input the master key and an attribute set . Choose a random generator in cyclic group and compute and , . Thus, the device private key is , .(iv). Input the public key , device private key , the message , and a monotone Boolean function , in which . , , and the vector meets the assignment . Compute and choose the random numbers and . After that compute , , , and , and . The signature is , and .(v). Input the public key , the signature , the message , and the monotone Boolean function . First compute , , and . If , then output 0. Otherwise, checks and If they are all equal, then return 1; otherwise, return 0.
3.2. Ciphertext-Policy Attribute-Based Encryption (CP-ABE)
Attribute-based encryption has been used to share data with some target devices which have specified attributes [19]. The data owner can make policies (s)he wishes to share the data with. The users will be assigned a secret key associated with the attributes, and they can decrypt (or access) the shared data if their attributes “satisfy” the predicates [25].(i). Input an attribute set . Choose two multiplicative cyclic groups and , whose order is . Let denote a bilinear map. Suppose is a generator of , and are random elements in group . Select two random numbers , and compute the public parameters and the master private key .(ii). Input the master private key and an attribute set . Choose a random number , and compute . The private key is ; the public key is .(iii). Input the public parameters , the public key , the message , and an Linear Secret Sharing Scheme (LSSS) access structure . is a matrix and is a function that links rows of with attributes. Choose a vector , and compute , is the row of matrix . Select random numbers , and compute , , ,..., . The ciphertext is .(iv). Input the private key for attribute set and the ciphertext for . Suppose satisfies and define . Let , . and . Decrypt the ciphertext:
3.3. Permission Access Control Table PACT
We generate a permission access control table (PACT) to achieve fine-grained access control by using smart contract. The owner first deploys smart contract with the access control table in the blockchain. This allows other devices to request and/or access data when their attributes satisfy the predicates. For example, “(A or B) and C” mapping to “” and “” mean the devices which satisfy the attribute “(A or B) and C” can access the encrypted private keys of device with identities 1 and 3. Only the device (or smart contract) owner can update the PACT by calling the smart contract function.
3.4. Practical Byzantine Fault Tolerance (PBFT)
The consensus algorithm used in this paper is Practical Byzantine Fault Tolerance (PBFT). We assume that there are a total of nodes in the system, where is the maximum number of nodes that may be failed. When more than normal authorized nodes confirm the transaction, the authorized nodes come to a consensus. This means that users will eventually receive replies from authorized nodes pertaining to their requests.
This algorithm is suitable for asynchronous systems such as the Internet. It contains important optimization functions that enable it to be executed efficiently. Here, we introduce the working process of PBFT, which consists of the following five phases: Request, Preprepare, Prepare, Commit, and Replay.(i)Request. When the leader is found not to be honest, the other replica is elected as a new leader by the algorithm. The primary sends a request to a replica; here it is replica 0.(ii)Preprepare. When replica 0 receives the request, it broadcasts a preprepared message to other replicas.(iii)Prepare. When the other replicas receive the preprepared message, if they accept, they broadcast the prepare message to all the other replicas and add preprepare and prepare messages into their logs. Otherwise, they do nothing.(iv)Commit. When replicas receive more than a certain number () of prepare messages during the Prepare phase, it enters the Commit phase. The replicas broadcast commit message.(v)Replay. If more than replicas accept the commit message, it means that there is a replica receiving more than commit messages. After completing the request operation, each replica sends a replay message to the primary node.
Both Preprepare and Prepare phases are used to ensure the ordering of the request. The consensus algorithm does not rely on the orderly propagation of messages, so replicas can submit requests in a disorderly manner. Because each replica backs up the message log in the preprepare, prepare, and commit phases, the corresponding requests can be executed in order.
3.5. Smart Contract
The concept of smart contract is introduced in 1994 by Nick Szabo and defined as “a computerized transaction protocol that executes the terms of a contract” [26]. Smart contracts are autonomous scripts stored on blockchain and have unique addresses. The creator can compile, deploy, and update his/her smart contract, and the output is recorded in blockchain network as a transaction. In our architecture, we use smart contract to manage PACT. The devices can send a request to the cloud with its signature, and the cloud interacts with the smart contract to verify the signature and retrieve the policy.
4. Proposed BaDS Architecture
In the proposed BaDS architecture, the devices use their attribute private key to sign the data request. The architecture comprises Initialization, Request and Transaction for Cloud, and Request and Transaction for Owner. Let us assume that a device belonging to owner A wants to access the data of owner B. The steps below are carried out among the parties.(1) Initialization. In this phase, the authority or system manager selects the system private key and computes the parameters by executing the following steps.(i) ABS.Initialization. As explained in Section 3.1, select a maximum width of monotonic span program and cyclic groups . Generate the public parameters . Choose the master key , and compute the public key by calling and . When each device registers on the system for the first time, based on its attribute tags , manager generates the private key for device using the algorithm.(ii) ABE.Initialization. Select a cyclic group and a generator . Choose the master key , and generate the public parameters by calling . As explained in Section 2.3, the assumption is that there are IoT devices, two device managers (e.g., owner A and owner B) and a cloud in the system. When the nodes register on the system for the first time, based on their attribute tags , manager generates their public and private key pairs using . , and , where .(iii) Contract Deployment. First, we generate a smart contract which is designed to achieve permission access control table. Then we compile and deploy it on the blockchain, after that the smart contract will have its own address (e.g., PID). The access control table is made up of the device access policy and corresponding predicates. The data sharing private keys are encrypted with relevant attributes.(2) Request and Transaction for Cloud. In this phase, a device belonging to owner A invokes the algorithm in the smart contract for sharing data belonging to other devices. It executes as follows.(i) Query. The device invokes the getPACT algorithm in smart contract to get the corresponding predicate of the target device’s access policy. And it checks whether its attributes can satisfy the predicate or not. If yes, then it sends a transaction to smart contract. Otherwise, the device requests permission from owner.(ii) Transaction. The device prepares and constructs the corresponding transaction based on its request. For instance, a transaction consists of and other parts, “to” is filled with the address of smart contract that the device wants to call, and “from” is filled with the device’s address. After all the fields are constructed, the device uses its attribute private key to sign the transaction and broadcasts it to the blockchain network.(iii) State. The other nodes invoke the ABS.Veri algorithm to verify the attribute-based signature in it, when they receive the broadcast transaction. The architecture uses the PBFT consensus mechanism to achieve consensus, and the transaction can be recorded in the blockchain network, only if there are at least two-thirds nodes that have accepted it.(iv) Response. The smart contract returns the attribute-based encrypted private key in the access policy as a response message to the device, after the transaction is recorded in the blockchain network. The device can use its attribute private key to get the private key. Then, the device sends a request to the cloud. The two parties (between device and cloud) should authenticate each other using the existing authentication protocol [20] before the cloud deals with the request. Finally, the device obtains the data from the cloud and uses the private key to decrypt the data.(3) Request and Transaction for Owner. In this phase, the device requests permission from data owner. It executes as follows.(i) Request. The device invokes the getPACT algorithm in smart contract to get the corresponding predicate of the target device’s access policy. If its attributes cannot satisfy the predicate, then it requests for permission from the owner. Both device and owner should authenticate each other using the existing authentication protocol [20], prior to the owner dealing with the request. If the owner allows the device to access the data, then he/she calls the smart contract to modify the access control table by transaction. Otherwise, the device cannot access the data.(ii) Permission Update. As described in Section 3.3, we use permission access control table in smart contract to achieve fine-grained access control. The data owner can invoke the UpdatePACT algorithm in smart contract to add, delete, and modify the access policies and the predicates. Only if the device’s attributes satisfy the predicates in PACT can it obtain the encrypted key from access policies.(iii) Access. After the data owner has modified PACT, the device sends a request to cloud and performed as described in Request and Transaction for Cloud.
4.1. Security Analysis
In this section, we analyze how the architecture is resilient to the following typical security and privacy attacks.(1)Confidentiality. The permission access control table (PACT) is generated to restrict access; if an adversary sends request to cloud or smart contract, the request will be rejected owing to his/her invalid signature. Thus, only authorized (satisfied attribute policy) devices can access the data and get the corresponding decryption key.(2)Fine-Grained Access Control. The attribute-based signature provides fine-grained access control. In other words, the data manager or authority generate policies (some attributes set), and only devices satisfying the policies can access the data. In addition, the manager can grant or revoke device access by modifying the policy.(3)Mutual Authentication. Before the device can communicate securely with the cloud or data owner, they will confirm the identity of each other by their signatures. Any probabilistic polynomial time adversary cannot forge a valid signature due to the underpinning DL problem. Hence, mutual authentication can be achieved between the device and the cloud or data owner.(4)User Anonymity. In the BaDS architecture, we use attribute-based signature and encryption to protect the devices’ real identities. All the message transmitted in the open channel are signed or encrypted by some attributes or session key. Thus, when verifying the signature or decrypting the information, only the attributes public or secret keys are needed. Hence, the architecture can protect user anonymity.(5)Impersonation Attack. As discussed earlier, mutual authentication between devices and cloud or data owner is achieved in the BaDS architecture. If the adversary impersonates a legitimate device and sends a request to cloud, it cannot be authenticated, and the manager can revoke access of the malicious or compromised device. That is, only a legitimate device can generate a valid signature.(6)Collision Attack Resistance. In the BaDS architecture, we use the PBFT consensus algorithm to record new blocks, which effectively avoids collisions of blocks.(7)Man-in-the-Middle Attack Resistance. Man-in-the-middle attack means the adversary can intercept and replace the encrypted date transmitted in the open environment. Suppose that if an adversary modifies other response message, the device can identify them due to the use of the attribute signature and session key encryption; thus we can say that the adversary cannot modify the transaction message.(8)Link Attack Resistance. Link attack is defined as the adversary can link multiple transaction, which use the same address or public key, to find users’ private messages. Similar to our explanation for man-in-the-middle attack, all messages transmitted in the open environment are signed or encrypted by the attributes and session key. Even if the adversary obtains session key, he/she cannot extract something useful due to the attribute encryption of real device’s data.
5. Performance Analysis
In this section, we implement the BaDS architecture and analyze the computation cost of smart contract based on Ethereum (https://www.ethereum.org/). The blockchain platform allows one to write smart contract with a special language, and compile and deploy it to the blockchain network. The smart contracts are autonomous scripts stored on blockchain and have unique addresses. Thus, it can be regarded as a database in which function can be called by sending a transaction with corresponding parameters.
We define as authentication key agreement algorithm and and as the deployment of permission access control table in smart contract and the deployment of smart contract in blockchain, respectively. and denote invoking the corresponding get and update functions in smart contract. The operations needed at each phase in this architecture is shown in Table 2. We then evaluate the operation computation cost of those algorithm (e.g., ABS, CP-ABE) by using the pairing-based library and GNU multiple precision arithmetic library. Table 3 shows the computation cost of attribute-based signature and encryption algorithms.
We publish the smart contract on a private Ethereum network, which we constructed by ourselves, then we can compute the time of deploying and invoking a smart contract. Publishing transactions on private chain does not need transaction fees and has the same accurate results as public chains. Table 1 presents the information of the simulation platform. Web3j is used to evaluate the time cost of publishing a designed smart contract. However, the existing Ethereum platform does not provide ABS and ABE algorithm; in this research, we only use the smart contract to realize management of policies and execute the signing and encrypting in the external environment.
6. Conclusion
We proposed a novel blockchain-based architecture for data sharing with attribute-based cryptosystem (BaDS) in this paper. The architecture can achieve privacy-preserving, user-self-controlled data sharing, and decentralization by using blockchain and several attribute-based cryptosystems. Specifically, ABS and CP-ABE provide the capability for fine-grained access control. We introduced the security requirements of the proposed BaDS architecture and then explained how the proposed BaDS architecture satisfies the security requirement. We also implement the BaDS architecture and analyze its computation cost.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
The work was supported in part by the National Key Research and Development Program of China (no. 2018YFC1315400), the National Natural Science Foundation of China (nos. 61572370, 61572379, and 61501333), and the fund of the Jiangsu Key Laboratory of Big Data Security & Intelligent Processing (no. BDSIP1807).