# BaDS: Blockchain-Based Architecture for Data Sharing with ABS and CP-ABE in IoT

Authors: Yunru Zhang; Debiao He; Kim-Kwang Raymond Choo
Journal: Wireless Communications and Mobile Computing
 (2018)

---

## 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.


---

## Body

## 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 Figure1,Owner1 can store and share the collected data withOwner2 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).Figure 1
IoT data storage and sharing in a cloud-based model.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.,AES). 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 Section3.5).The rest of the paper is organized as follows: In Section2, 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 defineG1 and G2 as two additive cyclic groups on elliptic curve F(p), GT as a multiplication cyclic group. Let q be a big prime number, which is the order of G1, G2, and GT. e:G1×G2→GT denote a bilinear map. Suppose that the generators of G1 and G2 are P and Q; g is the element that P and Q map to GT. Thus, the map e is a bilinear pairing on condition that e satisfies the following properties:(i)
Bilinearity. Given any two elements a,b∈Zq∗, and ∀X∈G1,∀Y∈G2, there is e(a·X,b·Y)=e(X,Y)a·b.(ii)
Nondegenerate. There exists at least one element X which satisfies e(X,X)≠1.(iii)
Efficient Computability. Given any two elements ∀X∈G1,∀Y∈G2, there exists at least one efficient algorithm to compute e(X,Y).We define the computationally hard mathematical problems.(i)
Discrete Logarithm (DL) Problem. Given an element X∈G1 or x∈GT, for anyP.P.T. (probability polynomial time) attacker, it is computationally hard to calculate τ∈Zq∗ which satisfies X=τ·P or x=gτ.(ii)
Computational Diffie-Hellman (CDH) Problem. Given a tuple (g,e,P,Q,aP,bQ) in which (a,b)∈Zq∗, P, Q and g are the generators of G1, G2, and GT, respectively. The purpose ofCDH problem is to compute ω=gab∈GT, in which (a,b)∈Zq∗ are unknown.


### 2.2. Monotone Span Program

LetΓ:{0,1}n→{0,1} as a monotone Boolean function. For an l×t matrix M over a filed F and every (x1,…,xn)∈{0,1}n, a monotone span program is defined as follows: (1)Γx1,x2,…,xn=1⇔∃v→∈Fl×t:M=1,0,0,…,0in which ∀i:xa(i)=0⇒vi=0 and the labeling function a:[l]→[n]. That means Γ(x1,x2,…,xn)=1 if and only if the index to the rows of matrix spans the vector [1,0,0,…,0]. We say the length and width of span program are l and t, and the size of it is l+t.


### 2.3. Network Model

Our BaDS architecture consists of the following participants:IoT devices,Data Owner,Blockchain Network, andCloud; see Figure 2.Figure 2
IoT device data sharing system.(i)
IoT Devices. IoT devices collect data and send data to the network layer (e.g., cloud or some other applications). Such devices are also responsible for data acquisition, preliminary processing, encryption (if they can support the encryption), and transmission. The devices can usually remotely request access and handle the commands. When the devices need to request data from other devices, they should publish a corresponding request to the cloud or the data owner. (ii)
Data Owner. There is a very large number of data owners, who are divided into administrators and ordinary data owners. The administrators are responsible for vetting the participants. When data owner receives an access data request from other IoT device, he/she should authenticate the identity before responding to the request accordingly. (iii)
Blockchain Network. In this architecture, we adopt a permissioned model (e.g., hyperledger fabric). Specifically, its security is guaranteed under the assumption that most participants are honest and the difficult problems. In other words, the average time an attacker can solve the problem is much less than the time it takes to disseminate information over the network. The consensus algorithm in our system is the Byzantine fault tolerance mechanismPBFT, rather than Proof of Work (POW) used in Bitcoin. The fabric contains verification nodes (to verify the transaction) and ordering nodes (to pack the verified transaction into the block). When the nodes receive the transaction (request from cloud or data owner), they will verify and pack them into the blockchain. (iv)
Cloud. It is used to store the encrypted devices’ data, and sends a corresponding request transaction to the blockchain network to query the permission of the device, when the cloud receives a request from IoT device. That means the cloud monitors the blockchain network and responds to the requested data.In the BaDS architecture, the following steps are undertaken to request data between devices.At first, ownerA 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 B) 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, ownerB should sends a request for data access to owner A. 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 A permits the access from the device of B, 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, A 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.


## 2.1. Bilinear Pairings

We defineG1 and G2 as two additive cyclic groups on elliptic curve F(p), GT as a multiplication cyclic group. Let q be a big prime number, which is the order of G1, G2, and GT. e:G1×G2→GT denote a bilinear map. Suppose that the generators of G1 and G2 are P and Q; g is the element that P and Q map to GT. Thus, the map e is a bilinear pairing on condition that e satisfies the following properties:(i)
Bilinearity. Given any two elements a,b∈Zq∗, and ∀X∈G1,∀Y∈G2, there is e(a·X,b·Y)=e(X,Y)a·b.(ii)
Nondegenerate. There exists at least one element X which satisfies e(X,X)≠1.(iii)
Efficient Computability. Given any two elements ∀X∈G1,∀Y∈G2, there exists at least one efficient algorithm to compute e(X,Y).We define the computationally hard mathematical problems.(i)
Discrete Logarithm (DL) Problem. Given an element X∈G1 or x∈GT, for anyP.P.T. (probability polynomial time) attacker, it is computationally hard to calculate τ∈Zq∗ which satisfies X=τ·P or x=gτ.(ii)
Computational Diffie-Hellman (CDH) Problem. Given a tuple (g,e,P,Q,aP,bQ) in which (a,b)∈Zq∗, P, Q and g are the generators of G1, G2, and GT, respectively. The purpose ofCDH problem is to compute ω=gab∈GT, in which (a,b)∈Zq∗ are unknown.


## 2.2. Monotone Span Program

LetΓ:{0,1}n→{0,1} as a monotone Boolean function. For an l×t matrix M over a filed F and every (x1,…,xn)∈{0,1}n, a monotone span program is defined as follows: (1)Γx1,x2,…,xn=1⇔∃v→∈Fl×t:M=1,0,0,…,0in which ∀i:xa(i)=0⇒vi=0 and the labeling function a:[l]→[n]. That means Γ(x1,x2,…,xn)=1 if and only if the index to the rows of matrix spans the vector [1,0,0,…,0]. We say the length and width of span program are l and t, and the size of it is l+t.


## 2.3. Network Model

Our BaDS architecture consists of the following participants:IoT devices,Data Owner,Blockchain Network, andCloud; see Figure 2.Figure 2
IoT device data sharing system.(i)
IoT Devices. IoT devices collect data and send data to the network layer (e.g., cloud or some other applications). Such devices are also responsible for data acquisition, preliminary processing, encryption (if they can support the encryption), and transmission. The devices can usually remotely request access and handle the commands. When the devices need to request data from other devices, they should publish a corresponding request to the cloud or the data owner. (ii)
Data Owner. There is a very large number of data owners, who are divided into administrators and ordinary data owners. The administrators are responsible for vetting the participants. When data owner receives an access data request from other IoT device, he/she should authenticate the identity before responding to the request accordingly. (iii)
Blockchain Network. In this architecture, we adopt a permissioned model (e.g., hyperledger fabric). Specifically, its security is guaranteed under the assumption that most participants are honest and the difficult problems. In other words, the average time an attacker can solve the problem is much less than the time it takes to disseminate information over the network. The consensus algorithm in our system is the Byzantine fault tolerance mechanismPBFT, rather than Proof of Work (POW) used in Bitcoin. The fabric contains verification nodes (to verify the transaction) and ordering nodes (to pack the verified transaction into the block). When the nodes receive the transaction (request from cloud or data owner), they will verify and pack them into the blockchain. (iv)
Cloud. It is used to store the encrypted devices’ data, and sends a corresponding request transaction to the blockchain network to query the permission of the device, when the cloud receives a request from IoT device. That means the cloud monitors the blockchain network and responds to the requested data.In the BaDS architecture, the following steps are undertaken to request data between devices.At first, ownerA 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 B) 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, ownerB should sends a request for data access to owner A. 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 A permits the access from the device of B, 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, A 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 ofs+2 elements, where s is the width of the monotone span program of the claim-predicate [24]. The maximum width of monotonic span program is defined as qm, and A=Zp∗, in which p is a big prime number and also the order of the cyclic group.(i)
ABS.PSetup. Let G1, G2, and e:G1×G2→GT denote two cyclic groups and a bilinear map, respectively, where the order of cyclic groups is p. Suppose g and hi are the generators of G1 and G2, where i∈[0,qm]. Choose a hash function H:{0,1}∗→Zp∗. Thus, the public parameters are Param={G1,G2,H,g,h0,…,hqm}.(ii)
ABS.MSetup. Randomly choose four numbers l0,l,m,n∈Zp∗ and compute: N=gn, L0=h0l0, Lj=hjl, and Mj=hjm, j∈[1,qm]. Thus, the master key is MSK={l0,l,m}, and the public key is MPK={N,L0,…,Lqm,M1,…,Mqm}.(iii)
ABS.Gen. Input the master key MSK and an attribute set A⊆A. Choose a random generator Kbase in cyclic group G1 and compute K0=Kbasel0-1 and Ku=Kbase(l+mu)-1, u∈A. Thus, the device private key is SKA={Kbase,K0,Ku}, u∈A.(iv)
ABS.Sign. Input the public key MPK, device private key SKA, the message m, and a monotone Boolean function γ, in which (γ(A)=1). γ→MN∈(Zp)x×y, u:[x]→A, and the vector v→ meets the assignment A. Compute μ=H(m∥γ) and choose the random numbers β0∈Zp∗ and β1,…,βx∈Zp. After that compute C=Kbaseβ0, F=K0β0, Si=(Ku(i)vi)βi·(Ngμ)βi, and Ri=∏i=1x(Lj·Mju(i))Tij·βi, ∀i∈[x] and ∀j∈[y]. The signature is σ={C,F,Si,Rj}, ∀i∈[x] and ∀j∈[y].(v)
ABS.Veri. Input the public key MPK, the signature σ, the message m, and the monotone Boolean function γ. First compute γ→MN∈(Zp)x×y, u:[x]→A, and μ=H(m∥γ). If C=1, then output 0. Otherwise, checks e(F,L0)=e(C,h0) and (2)∏i=1xeSi,LjMjuiTij=eC,h1eNgμ,R1,j=1eNgμ,Rj,j>1,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)
ABE.Setup. Input an attribute set A. Choose two multiplicative cyclic groups G3 and GT, whose order is p. Let e:G3×G3→GT denote a bilinear map. Suppose k is a generator of G3, and f1,…,f|A| are |A| random elements in group G3. Select two random numbers s,a∈Zp, and compute the public parameters Param={k,G3,f1,…,f|A|} and the master private key ESK=ks.(ii)
ABE.KeyGen. Input the master private key ESK and an attribute set A. Choose a random number t∈Zp, and compute sk=kskat,T=kt,ski=fit(∀i∈A). The private key is SK=(sk,T,ski); the public key is PK={e(k,k)s,ka}.(iii)
ABE.Encrypt. Input the public parameters Param, the public key PK, the message m, and an Linear Secret Sharing Scheme (LSSS) access structure (M,β). M is a x×y matrix and β is a function that links rows of M with attributes. Choose a vector v→=(l,b2,…,by)T∈Zpy, and compute γi=v→·Mi, Mi is the ith row of matrix M. Select x random numbers n1,…,nx∈Zp, and compute C=Me(k,k)sl, C′=kl, (C1=kaγ1fβ(1)-n1),..., (Cx=kaγxfβ(x)-γy,Dx=knx). The ciphertext is CT=(C,C′,(C1,D1),…,(Cx,Dx)).(iv)
ABE.Decrypt. Input the private key SK for attribute set A and the ciphertext CT for (M,β). Suppose A satisfies (M,β) and define U={i:β(i)∈A}. Let ρi∈Zp, i∈U. and Σi∈Uρiγi=l. Decrypt the ciphertext: (3)eC′,sk∏i∈UeCi,TeDi,skβiρi=ek,kslek,kalt∏i∈Uek,ktaγiρi=ek,ksl


### 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 “[SK1](AorB)andC” and “[SK3](AorB)andC” 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 of3f+1 nodes in the system, where f is the maximum number of nodes that may be failed. When more than 2f+1 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, andReplay.(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 (2f) of prepare messages during thePrepare phase, it enters theCommit phase. The replicas broadcast commit message.(v)
Replay. If more than 2f+1 replicas accept the commit message, it means that there is a replica receiving more than 2f+1 commit messages. After completing the request operation, each replica sends a replay message to the primary node.BothPreprepare andPrepare 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.


## 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 ofs+2 elements, where s is the width of the monotone span program of the claim-predicate [24]. The maximum width of monotonic span program is defined as qm, and A=Zp∗, in which p is a big prime number and also the order of the cyclic group.(i)
ABS.PSetup. Let G1, G2, and e:G1×G2→GT denote two cyclic groups and a bilinear map, respectively, where the order of cyclic groups is p. Suppose g and hi are the generators of G1 and G2, where i∈[0,qm]. Choose a hash function H:{0,1}∗→Zp∗. Thus, the public parameters are Param={G1,G2,H,g,h0,…,hqm}.(ii)
ABS.MSetup. Randomly choose four numbers l0,l,m,n∈Zp∗ and compute: N=gn, L0=h0l0, Lj=hjl, and Mj=hjm, j∈[1,qm]. Thus, the master key is MSK={l0,l,m}, and the public key is MPK={N,L0,…,Lqm,M1,…,Mqm}.(iii)
ABS.Gen. Input the master key MSK and an attribute set A⊆A. Choose a random generator Kbase in cyclic group G1 and compute K0=Kbasel0-1 and Ku=Kbase(l+mu)-1, u∈A. Thus, the device private key is SKA={Kbase,K0,Ku}, u∈A.(iv)
ABS.Sign. Input the public key MPK, device private key SKA, the message m, and a monotone Boolean function γ, in which (γ(A)=1). γ→MN∈(Zp)x×y, u:[x]→A, and the vector v→ meets the assignment A. Compute μ=H(m∥γ) and choose the random numbers β0∈Zp∗ and β1,…,βx∈Zp. After that compute C=Kbaseβ0, F=K0β0, Si=(Ku(i)vi)βi·(Ngμ)βi, and Ri=∏i=1x(Lj·Mju(i))Tij·βi, ∀i∈[x] and ∀j∈[y]. The signature is σ={C,F,Si,Rj}, ∀i∈[x] and ∀j∈[y].(v)
ABS.Veri. Input the public key MPK, the signature σ, the message m, and the monotone Boolean function γ. First compute γ→MN∈(Zp)x×y, u:[x]→A, and μ=H(m∥γ). If C=1, then output 0. Otherwise, checks e(F,L0)=e(C,h0) and (2)∏i=1xeSi,LjMjuiTij=eC,h1eNgμ,R1,j=1eNgμ,Rj,j>1,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)
ABE.Setup. Input an attribute set A. Choose two multiplicative cyclic groups G3 and GT, whose order is p. Let e:G3×G3→GT denote a bilinear map. Suppose k is a generator of G3, and f1,…,f|A| are |A| random elements in group G3. Select two random numbers s,a∈Zp, and compute the public parameters Param={k,G3,f1,…,f|A|} and the master private key ESK=ks.(ii)
ABE.KeyGen. Input the master private key ESK and an attribute set A. Choose a random number t∈Zp, and compute sk=kskat,T=kt,ski=fit(∀i∈A). The private key is SK=(sk,T,ski); the public key is PK={e(k,k)s,ka}.(iii)
ABE.Encrypt. Input the public parameters Param, the public key PK, the message m, and an Linear Secret Sharing Scheme (LSSS) access structure (M,β). M is a x×y matrix and β is a function that links rows of M with attributes. Choose a vector v→=(l,b2,…,by)T∈Zpy, and compute γi=v→·Mi, Mi is the ith row of matrix M. Select x random numbers n1,…,nx∈Zp, and compute C=Me(k,k)sl, C′=kl, (C1=kaγ1fβ(1)-n1),..., (Cx=kaγxfβ(x)-γy,Dx=knx). The ciphertext is CT=(C,C′,(C1,D1),…,(Cx,Dx)).(iv)
ABE.Decrypt. Input the private key SK for attribute set A and the ciphertext CT for (M,β). Suppose A satisfies (M,β) and define U={i:β(i)∈A}. Let ρi∈Zp, i∈U. and Σi∈Uρiγi=l. Decrypt the ciphertext: (3)eC′,sk∏i∈UeCi,TeDi,skβiρi=ek,kslek,kalt∏i∈Uek,ktaγiρi=ek,ksl


## 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 “[SK1](AorB)andC” and “[SK3](AorB)andC” 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 of3f+1 nodes in the system, where f is the maximum number of nodes that may be failed. When more than 2f+1 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, andReplay.(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 (2f) of prepare messages during thePrepare phase, it enters theCommit phase. The replicas broadcast commit message.(v)
Replay. If more than 2f+1 replicas accept the commit message, it means that there is a replica receiving more than 2f+1 commit messages. After completing the request operation, each replica sends a replay message to the primary node.BothPreprepare andPrepare 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 comprisesInitialization,Request and Transaction for Cloud, andRequest 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 qm and cyclic groups G1,G2. Generate the public parameters Param={G1,G1,H,g,h0,hqm}. Choose the master key MSK={l0,l,m}, and compute the public key MPK={N,L0,…,Lqm,M1,…,Mqm} by calling ABS.PSetup and ABS.MSetup. When each device registers on the system for the first time, based on its attribute tags A, manager generates the private key SKA={Kbase,K0,Ku} for device using the ABS.Gen algorithm.(ii)
ABE.Initialization.Select a cyclic group G3 and a generator k. Choose the master key ESK=ks, and generate the public parameters Param={k,G3,f1,…,f|A|} by calling ABE.Setup. 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 tagsA, manager generates their public and private key pairs (PKj,SKj)(j=1,…,π,oa,ob,c) using ABE.KeyGen. PKj={e(k,k)js,kja}, and SKj={skj,Tj,skij}, where skj=kjskjat,Tj=kjt,skij=fijt(∀i∈A).(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 {to,from,value} 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 SKA 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 SKj 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 inRequest 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.


## 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 defineAuth.KA as authentication key agreement algorithm and PACT.deploy and SC.deploy as the deployment of permission access control table in smart contract and the deployment of smart contract in blockchain, respectively. getPACT and UpdataPACT 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. Table1 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.Table 1
Simulation platform.
Operating System Ubuntu 16.04  CPU Intel (R) Core (TM) i7-6700 CPU @ 3.40 GHZ  Memory 3 GB RAM  Configuration go-ethereum nodejs npm truffleTable 2
Operations needed at each phase inBaDS.
Phase Cryptographic Algorithms Smart Contract Publication Smart Contract Trigger Initialization ABS.PSetup + ABS.MSetup +ABS.Gen + ABE.Setup + ABE.KeyGen + ABE.Encrypt PACT.deploy + SC.deploy Null  Request and Transaction for cloud Auth.KA + ABE.Decrypt + ABS.Sign + ABS.Veri Null getPACT  Request and Transaction for Owner Auth.KA + 2∗ABS.Sign + 2∗ABS.Veri Null getPACT + UpdataPACTTable 3
Computation cost(s) of cryptographic algorithms.
ABS  Algorithm ABS.PSetup & ABS.MSetup ABS.Gen ABS.Sign ABS.Veri  Max Time 0.17939 0.068969 0.136605 0.18168  Min Time 0.049207 0.021929 0.055461 0.050144  Average Time 0.058182 0.028793 0.069066 0.064048  CL-MRE  Algorithm ABE.Setup ABE.KeyGen ABE.Encrypt ABE.Decrypt  Max Time 0.161446 0.058168 0.164257 0.234115  Min Time 0.037582 0.017119 0.050459 0.025966  Average Time 0.045421 0.02222 0.05951 0.035304


## 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.



---

*Source: 2783658-2018-11-04.xml*