Abstract
As the product of the third information technology revolution, the Internet of Things (IoT) has greatly altered our way of lifetime. Cloud storage has gradually become the best choice for data processing due to its scalability and flexibility. However, the cloud is not a completely trusted entity, such as tampering with user data or leaking personal privacy. Therefore, cloud storage usually adopts attribute-based encryption schemes to accomplish data confidentiality and fine-grained access control. However, applying the ABE scheme to the Internet of Things still faces many challenges, such as dynamic user revocation, data sharing, and excessive computational burden. In this paper, we propose a novel searchable attribute encryption system that replaces the traditional key generation center with consortium blockchain to generate and manage partial keys. In addition, our scheme can perform predecryption operations in the cloud, and users only need to spend a small amount of computational cost to achieve decryption operations. Security analysis proves that our scheme achieves security under both the chosen keyword attack and the chosen plaintext attack. Compared with other schemes, this scheme is more economical in terms of computing and storage.
1. Introduction
The Internet of Things (IoT) originated in the media field, and it is an important part of the new generation of information technology. It connects all items to the Internet through information sensing devices to achieve positioning, tracking, supervision, and intelligent identification [1]. Simply put, the IoT is the Internet that connects everything. In recent years, the IoT has gradually become digitized in the real world, reduced the dispersion of information, and integrated the digital information between objects. The IoT is widely used in the fields of transportation and logistics, industrial manufacturing, medical care, and smart environments [2–7].
Sahai and Waters first proposed the concept of attribute-based encryption (ABE) in 2005 [8]. Because the access structure needs to be more flexible to adapt to more application scenarios, Goyal et al. [9] and Bethencourt et al. [10], respectively, proposed the concepts of key policy ABE (KP-ABE) and ciphertext policy ABE (CP-ABE). In KP-ABE, the ciphertext is associated with a set of attributes, and the access policy is embedded in the key. In contrast, in CP-ABE, the ciphertext is associated with the access policy, and a set of attributes is embedded in the key [11–14].
Although IoT has now blossomed in various fields, there are still many problems in applying ABE to the IoT. Compared with the traditional Internet, the IoT lacks standardization. In addition, the IoT itself is a complex network system involving many application domains, which is difficult to manage [15]. This makes it challenging to achieve its security and privacy. Therefore, blockchain technology is widely used in IoT for its persistence, anonymity, and auditability [16].
In this article, we will present a new blockchain-aided searchable attribute-based encryption (BC-SABE) scheme. This scheme replaces a traditional centralized server using a distributed consortium blockchain consisting of a predefined set of trusted consensus nodes. Our main contributions can be summarized as follows: (i)We present a novel BC-SABE scheme. Our scheme uses a distributed consortium blockchain containing a set of credible consensus nodes to achieve the function of key generation. Pedersen secret sharing protocol [17] and reciprocal protocol [18] are used to generate all secret parameters, which also means that the master key is not needed. Our scheme can also support keyword search under cloud assistance. Users only need to provide user identity information and partial token information to the blockchain, and the cloud server will receive the complete token from the blockchain and search for it. Moreover, the scheme can realize predecryption in the cloud, which can greatly reduce the burden of users(ii)In our scheme, the Pedersen secret sharing protocol enables the sharing of subsecrets between consensus nodes, and each consensus node can combine the subsecrets as the master secret. And the reciprocal protocol ensures that the key information is shared without a trusted party(iii)In addition, we use blockchain technology to realize the dynamic revocation of users. Because consensus nodes in the blockchain can use time period tags and status tags to update the user revocation list, this also means that we can use the blockchain to update the user revocation list to achieve user revocation. And our scheme does not require the user to re-encrypt the ciphertext for user revocation
Our scheme can also be applied in simple medical scenarios. For example, hospital can register admission information for patient and store the admission information in the blockchain. Registered patients can enter their data and information into the cloud server. When searching for relevant information, he/she only needs to submit a partial token to blockchain, and then, blockchain can produce the complete token for him/her and send it to the cloud server for search operations. In addition, patients can access data information from the cloud, which will first generate a predecryption key for them, and the patient can fully decrypt the data with a simple calculation.
The remainder of this paper is organized as follows. In Section 2, we reviewed some related work, and then, we gave some preliminaries in Section 3, including the complexity assumptions, binary trees, and blockchain. The system model, system procedure, and security model are given in Section 4, and the detailed structure of the system is given in Section 5. We give the security proof of the scheme in Section 6 and compare the performance of the scheme in Section 7, and finally, we give a brief summary in Section 8.
2. Related Work
Since the concepts of ABE were introduced, many improved ABE schemes have been proposed, such as traceable ABE [19], anonymous ABE [20, 21], and hierarchical ABE [22–25]. However, the application of ABE to IoT is still an issue that needs to be discussed. The resources of the Internet of Things devices are limited, and most of the ABE algorithm encryption and decryption calculation costs are relatively large, so the outsourcing ABE scheme has been proposed [26–29]. In addition, IoT systems should be able to revoke malicious users and update legitimate users with new attributes. How to implement dynamic user revocation is also an issue. Liu et al. [30] proposed a direct revocation scheme; however, in this scheme, all data owners are required to maintain the revocation list. Recently, Cui et al. [31] proposed a server-aided revocable ABE scheme. This scheme outsources all the workload to the server at the time of user revocation, and each user stores only a fixed size private key.
However, this single authorization ABE scheme has limited security and cannot carry a large number of IoT devices. Many multiauthorization-based ABE schemes have been proposed by scholars [32–35]. Chase [32] first presented the concept of multiauthority attribute-based encryption (MA-ABE) in 2007. Recently, Belguith et al. [34] presented a policy-hidden outsourced MA-ABE scheme, which hides the access structure to protect user privacy. In [35], a new MA-CP-ABE scheme was presented by Sethi et al. This system decentralizes authority and can support white box traceability along with outsourcing decryption.
Recently, the widespread application of data sharing has deepened the academic research on searchable encryption schemes, and many searchable attribute-based encryption (SABE) schemes have also been proposed [36–44]. In [36], Miao et al. presented a multikeyword SABE scheme, which supports comparable attributes by using 0-encoding and 1-encoding. Xu et al. [37] proposed for the first time a decentralized attribute-based keyword search (ABKS) scheme for multikeyword search in cloud storage. In this scheme, data sharing and data searching can be achieved without a fully trusted central authority. Recently, a seed string searchable ABE (SSS-ABE) solution for sharing and querying encrypted data was proposed by Sun et al. [38]; data users can query the entire ciphertext by substring without presetting keywords.
Blockchain technology originated from Bitcoin; the concept of blockchain was first proposed by Satoshi Nakamoto in [45]. Blockchain is a distributed shared ledger and database. Compared with the previous centralized accounting model, blockchain can achieve decentralization, which means removing the trust intermediary, which also makes the transactions on blockchain more open and transparent. Recently, Wu et al. [46] used blockchain technology to propose a privacy-protected and traceable ABE scheme, using blockchain to achieve data integrity and nonrepudiation. In [47], Pournaghi et al. proposed a scheme to share medical data based on blockchain technology and attribute-based encryption (MedSBA), which utilizes blockchain to share medical data. Recently, Liu et al. [48] presented a blockchain-aided attribute-based searchable encryption scheme, and Zheng et al. [49] proposed a fair outsourcing decryption ABE scheme utilizing blockchain and sampling technology. In [50], Guo et al. used blockchain technology to propose an efficient and traceable ABE scheme with dynamic access control, which implements dynamic access control and can flexibly update the access structure.
As of late, blockchain technology has been universally exploited in ABE scheme, because compared to the traditional server structure, blockchain has no central node, which allows no single institution or member to achieve control over global data, while any node stops working without affecting the overall operation of the system. In addition, blockchain is also superior to traditional key management center in ensuring the confidentiality of data. Therefore, we adopt blockchain technology to assure the security and robustness of the system.
3. Preliminaries
3.1. Composite Order Bilinear Groups and Complexity Assumptions
First of all, the concept of bilinear group is reviewed as follows. Let and be the multiplicative groups of order , is a generator of , and are three different prime. Then, is a bilinear map, and it has these properties as follows: (1)Bilinearity: For , (2)Nondegeneracy: (3)Computability: There is an algorithm to calculate efficiently
Now, we show the definition of the composite order bilinear groups. It is similar to bilinear groups except the order of the group is the product of two or more distinct prime numbers. That is to say, is a composite order group; are its three subgroups of order . For and , if , then .
Decisional linear assumption. Given , , any probabilistic polynomial time (PPT) algorithm is difficult to distinguish from , where and are randomly selected.
Decisional bilinear Diffie–Hellman problem (DBDH). Given and , any PPT algorithm is difficult to distinguish from , where .
3.2. Access Structure and Linear Secret Sharing Scheme (LSSS)
Definition 1. Assume is a set of attributes, and is a nonempty subset of , where represents the set constituted by all subsets of ; that is, is a nonempty set constituted by some subsets of . We call is an access structure on . If for any , satisfies the condition and , namely , and then set is monotonic. Authorized set refers to the set in ; on the contrary, the unauthorized set is not in .
Definition 2. In the linear secret sharing matrix formed by the access policy, each row corresponds to an attribute value, that is, row vector and attribute value form a one-to-one mapping relationship. If the following two properties are satisfied, and then, a secret sharing scheme on a set of is called linear.
(1)The shared secret key for each attribute is a vector formed on (2)In scheme , there is an secret sharing matrix A, whose row label is , . Given a secret sharing column vector , where is the secret key to be shared, is selected at random, represents the vector of n shared secret keys according to . Shared , that is the inner product belongs to the property , where is a function that maps to
The LSSS matrix has an important feature, that is, linear reconstruction. Suppose is a LSSS scheme representing access structure , is an authorized set, and then, we can define as . If there has constant that can be discovered in polynomial time such that are valid shares of the secret key , then . There is no such constant for any unauthorized set.
3.3. Binary Tree
First, there is a brief review of the definition of binary tree. Suppose UT represents a binary tree, in which there are L leaves corresponding to L users, the root node of BT is Rt. represents the set of all nodes on the path of leaf node from the root to . Note that and the root node are included here. , represents the left and right children of nonleaf nodes. The algorithm KUNodes is used to calculate the minimum set of nodes that need to release key updates, and only unrevoked users can decrypt the ciphertext within a period of time. That is, nodes in rl corresponding to time periods before or t do not have any ancestors in the set, and all other leaf nodes have exactly one ancestor in the set. Figure 1 gives the working principle of the KUNodes algorithm, where it first marks all ancestors of the revoked nodes as revoked and then outputs all unrevoked children of the revoked nodes. The Algorithm 1 is the formal definition of the KUNodes algorithm.
| ||||||||||||
3.4. Shamir Secret Sharing [51]
The Shamir secret sharing scheme is based on Lagrange interpolation polynomials, which are described as follows:
(1) A trusted dealer D first randomly chooses a polynomial with order l-1 such that , where are in finite filed . Then, computes ,…, and sends to each shareholder secretly
(2) More than l shareholder () work together can reconstruct the secret using the Lagrange interpolating formula
3.5. Pedersen (, ) Secret Sharing [17]
The Pedersen secret sharing scheme allows each dealer (shareholder) to randomly select a secret as a subsecret and can share the subsecret with other shareholders. Therefore, each shareholder can merger all the subsecrets as the master secret. The Pedersen secret sharing scheme is described as follows: (1)Each shareholder () randomly independently picks a subsecret , and then, the master secret can be described as (2)For each subsecret , a l-1 polynomial is randomly selected by shareholder such that . After that, it calculates , for other shareholders by using Shamir’s secret sharing. Finally, sends each to other secretly, and each shareholder has subshares (3)Each shareholder calculates its own master share (4)More than shareholders () work together can reconstruct the secret by using the Lagrange interpolating formula
3.6. Reciprocal Protocol [18]
Suppose that shareholders share a secret using Pedersen (, ) secret sharing protocol. The role of the reciprocal protocol is to get share without disclosing relevant message about and . The description of this protocol is as follows: (1)Shareholders jointly run the Pedersen (, ) secret sharing scheme to generate a (l, m) sharing of a random element . Denote all shares as (2)Shareholders jointly run the Pedersen (2l, m) secret sharing scheme to generate and retain a share of zero value (3)Shareholders need to pass the value and interpolating the corresponding 2l degree polynomial to reconstruct the value (4)Each shareholders sets to calculate it share of
3.7. Blockchain
On January 3, 2009, Satoshi Nakamoto generated the first Bitcoin block. A few days later, a second bitcoin block appeared to connect with the first block to form the chain, marking the birth of the blockchain. Because of its four main features, immutability, irreproducible uniqueness, smart contracts, and decentralized self-organization or community, blockchain is widely used in various fields.
In simple terms, a hash function (SHA-256) is used to form a blockchain. Each block contains a parent block hash, a timestamp, and a Merkle root. Where the parent block hash stores the hash value of the previous block header and is used to connect the previous block, the timestamp records the approximate time when the block was created, and the Merkle root is the Merkle tree root hash generated by the transaction list. There are three general types of blockchains: public blockchains, consortium blockchains, and private blockchains. Our system uses a consortium blockchain. Figure 2 illustrates the basic structure of a consortium blockchain.
In our consortium blockchain, consensus node nodes perform the consistency protocol to renovate the blockchain and reserve all nodes in the system with a consistent state. The consortium blockchain used in our system is similar to the scheme [48] in that firstly the consensus nodes can initialize the system parameters using the Pedersen secret sharing scheme and the reciprocity protocol. Secondly, the consensus nodes manage the associated keys of the users. Updating the user revocation list requires the joint participation of all consensus nodes, which effectively improves the system security. Users can submit searches to the blockchain, and the cloud server is able to perform predecryption operations for the users.
4. System Definition
4.1. System Model
Our data management system includes the following four participants:
Data owner (DO): The data owner stores the generated index and encrypted data in the cloud, where the index is used for the cloud to perform search operations.
Data user (DU): The data user is able to store the generated partial token in the consortium blockchain and is able to get the predecrypted message from the cloud to fully decrypt it using their private key.
Blockchain (BC): The consortium blockchain in the system consists of a set of credible predefined consensus nodes, a data pool, and a distributed ledger. The blockchain is responsible for initializing the system, storing the users’ public identity keys, and generating the users’ public decryption keys, key update information, and predecryption keys. In addition, the blockchain is also responsible for generating the complete token and sending it to cloud.
Cloud server (CS): Cloud server can search and predecrypt for users, and putting predecryption operations in the cloud can effectively reduce the burden of users.
Figure 3 shows the system procedure.
4.2. System Procedure
Based on [48], the basic process of the scheme is defined as follows:
4.2.1. System Init
All consensus nodes run algorithm to get the . Pedersen (, ) secret sharing protocol and reciprocal protocol are used by all consensus nodes to jointly determine the master key, and the exact value of the master parameter is unknown.
4.2.2. User Registration and Revocation
(1)The data user runs the to get its identity key pair to join the system and sends to BC. Then, the user public decryption key is generated by the consensus nodes using . In the meantime, the user’s predecryption key is also generated later using the public decryption key(2)For user revocation, based on a time period , a state mark , and the revocation list , consensus node runs the to update whenever a user wishes to be revoked
4.2.3. Key Gen
In this step, consensus nodes generate three keys: (1)Public decryption key generation: In this step, consensus nodes use the user identity , an access structure to run algorithm to generate the user public decryption key, which is used to verify whether the user has the attributes included in its attribute set(2)Updated key generation: Consensus nodes run the to get a key update message after is updated; it inputs a new time period t and a state mark , users who have not revoked will use it when generating a predecryption key(3)Predecryption key generation: Consensus nodes use to run ; it generates the predecryption key for user
4.2.4. Encryption
First, the data owner selects several keywords related to his/her data to generate a keyword set , and then, he/she uses a symmetric algorithm with the key to encrypt the data. Then, data owner runs the to hide the symmetric encryption key and runs the to generate an index set, where the same attribute set is used. Finally, data owner sends and to cloud.
4.2.5. Token Gen
(1)Patrial token generation: first, the data user runs the to generate the partial token. Then, data user sends to BC(2)Complete token generation: consensus nodes run algorithm for data user after receiving . Then, data user sends to the cloud
4.2.6. Search
When data users need to search, the cloud runs the algorithm to search.
4.2.7. Decryption
(1)Predecryption: The predecryption operation is done in the cloud, and the cloud takes as input the predecryption key sent to it by the blockchain, and it runs the to convert the ciphertext of data users after receiving the requested key. In this phase, most of the calculation costs will be carried out in the cloud(2)User decryption: Since a portion of the predecryption work has already been done in the cloud, data user runs the to generate the symmetric decryption key. After that, the complete decryption is done by running the symmetric algorithm
4.3. Security Model
4.3.1. Ciphertext Indistinguishability
Based on [48], we give a security definition of indistinguishability under chosen plaintext attacks (IND-CPA) for BC-SABE, defined by an indistinguishable game between adversary A and challenge B. Let be the authority universe. Adversary A is defined as an ( ) adversary that can compromise at most l-1 authority; Pedersen (l, m) secret sharing protocol and reciprocity protocol are applied in this security model.
Setup. A corrupted authority set is output by A, where . Then, B runs the to get the global public key , a state mark and a revocation list rl. Note that rl is initially empty. It outputs to A.
Phase 1. First, B creates an empty list , and A can perform the following queries adaptively: (i)IdKey query: First of all, A issues a IdKey query on an identity , B returns by running algorithm, and then, it adds to list . It returns to A(ii)PubDKey query: A issues a PubDKey Query on an identity and an access structure . If has not been issued to PubDKey query, then B returns by running , runs algorithm, and returns to A(iii)Upkey query: Algorithm A submits a Upkey query on a time period . B returns the to A by running (iv)PreDKey query: Algorithm A submits a PreDKey query on . If has not been issued to PreDKey query, B runs the ,, , and . Then, B returns the to A. Note that this oracle cannot be queried on a time period t before a Upkey query has been queried on t(v)Revocation query: A submits a PreDKey Query on , where t is not queried in UpKey query. B returns an updated revocation list rl to A by running
Challenge. A hands over two symmetric keys with same length and , an attribute set , and a time period satisfying the following restrictions: (i)If an identity has performed to the IdKey query, of satisfies a query on issued to the PubDKey query. Then, the revocation query must be queried on with or any t occurs before , and the PreDKey query cannot be queried on (ii)If with access structure can be satisfied by is not revoked before or at , then has never been queried by the IdKey query
B picks random and runs to encrypt , and then, it returns to A.
Phase 2. A can adaptively perform the same five queries to B as in phase 1; the queries sent by A must also meet the above conditional restrictions.
Guess. A makes a guess for ; if , it wins.
The advantage of the adversary A in this game is described as .
If the advantages of any (, ) PPT adversary defined above are negligible, then a BC-SABE scheme is IND-CPA secure.
4.3.2. Index Indistinguishability
Based on [48], we give a security definition of indistinguishability under selective access structure and chosen keyword attacks (IND-sCKA) for BC-SABE, defined by an indistinguishable game between adversary A and challenge B.
Init. Let be the challenge access structure defined by A.
Setup. B returns the global public parameter to A by running algorithm.
Phase 1. A can adaptively submit the following query: (i)IdKey query: A issues a IdKey query on an identity , B returns by running , and then, it adds to list and returns to A(ii)Token query: A issues a token query on , an access structure , and a keyword . B runs by using . Then, B returns to A by running the algorithm. Note that the challenge access structure does not contain the attribute set (iii)Index query: A issues an index query on and a keyword set . Then, B returns an index set by running
Challenge. A submits two keywords and of the same size. B picks random , and then it returns the to A by running the algorithm with the challenge access structure .
Phase 2. A can perform IdKey query, token query, and index query to B; the queries sent by A must also meet the above conditional restrictions.
Guess. A makes a guess for ; if , it wins.
The advantage of the adversary A in this game is described as .
If the advantages of any PPT adversary defined above are negligible, then a BC-SABE scheme is IND-sCKA secure.
5. Construction
5.1. System Init
is a consensus node set which has consensus nodes. First, consensus nodes exploit the Pedersen (, ) secret sharing protocol [17] and the reciprocal protocol [18] to run the to generate the global public key , the user revocation list , and the user tree , where is a randomly public string. Let be groups of a prime order , is a generator of , and is a bilinear map. Then, it chooses random . Let and , be the collision-resisted hash function, and be the admissible bilinear group parameters. Then, share two secret parameters and using Pedersen (, ) secret sharing scheme and reciprocal protocol to compute shares of . Based on its shares , , and , each consensus node computes and broadcasts , , and ; excess consensus nodes cooperate to recreate ; and each nodes spreads . The public parameters of the system are also generated in this way: , , Finally, it outputs global public key:
5.2. User Registration and Revocation
5.2.1. User Registration
The IdKG algorithm inputs the , the user identity , and ; it picks random and ; and then, it calculates , . The user runs this algorithm to generate the user public and private key pair , and then the user sends to BC. An undefined leaf node is selected by BC from the to storage and .
5.2.2. User Revocation
The revoke algorithm is run by the consensus node to update the user revocation listwhenever user want to be revoked. It inputs the user identity , a state mark , a time period, and ; then, it will find all nodes associated with the identity and put (, ) into the list and outputs the revised .
5.3. Key Generation
5.3.1. Public Decryption Key Gen
Consensus nodes run the PubDecKG algorithm to generate the public decryption key ; it takes , user identity , and a state mark and an access structure as the input, where matrix D is an with row label , . Then, it selects random the leaf node from the UT based on , and compute . It selects random and let , and then, it computes for , where denotes the vector of the i-th row of matrix . For each , it takes and computes and stores in the node . Then, share among consensus nodes by exploiting the Pedersen (, ) secret sharing scheme, and each consensus nodes computes and spreads based on share . Then, excess consensus nodes cooperate to compute the public decryption key as follows:
, , . Finally, BC stores in the ledger:
5.3.2. Key Update Messages Gen
Consensus nodes run the UpKG algorithm to generate the update information ; it inputs the , the revocation list , a time period t, the user tree, and a state mark . Share among consensus nodes by exploiting the Pedersen (, ) secret sharing scheme, and each consensus nodes computes and spreads based on share .
For all , it takes from the node y. Then, more than consensus nodes cooperate to compute the update information as follows: , . BC stores in the ledger:
5.3.3. Predecryption Key Gen
Consensus nodes run the PreDecKG algorithm to generate the update information ; it inputs the , a time period , user identity , an access structure , the user tree , a state mark , the revocation list , user public decryption key , and a update information . Then, let and , so we have and . If , it returns . Then, share and among consensus nodes by exploiting the Pedersen (, ) secret sharing protocol. Based on share and , each consensus nodes computes and spreads , . Then, more than consensus nodes cooperate to compute the predecryption key.
BC stores in the ledger.
5.4. Encryption
5.4.1. Data Encryption
Date owner runs the Enc algorithm to get the ciphertext CT. It inputs the , an attribute set , and a symmetric key and a time period t. Let and choose . It calculates , , , and and outputs and .
5.4.2. Index Generation
Date owners run the IdxG algorithm to generate the . It inputs the , the same attribute set , and a keyword set , and then, it computes ,, , and . Finally, it sent index set along with and to the cloud.
5.5. Token Gen
5.5.1. Partial Token Gen
In this phase, data users run the PTokG algorithm to get the partial token. It inputs the , user private key , and a keyword w. Then, it randomly selects ; it computes the partial token and the hash value . Finally, it sends and to BC.
5.5.2. Complete Token Gen
Blockchain runs the TokG algorithm to get the complete token. It inputs the , the user identity , the same access structure , and the partial token . Share among consensus nodes by exploiting Pedersen (, ) secret sharing protocol. Based on share , each consensus nodes computes and spreads . Then, more than consensus nodes cooperate to compute the complete token as follows:
Finally, it sends the token to the cloud:
5.6. Search
Cloud runs search algorithms to perform search operations; it takes the , the same access structure , the complete token , and the as inputs. It yields the capacity address Addr of related ciphertext if and only if the algorithm runs successfully; otherwise, the algorithm stops. First, it verifies whether the user’s attribute set satisfies the access structure, and if not, it outputs a stop character . If it is satisfied, let , and then the algorithm can calculate a set which makes . Then, it verifies whether the equation described is valid.
If the formula holds, the stored address Addr is the output.
5.7. Decryption
5.7.1. Predecryption
The predecryption operation is performed by the cloud, which runs the PreD algorithm to complete. It inputs the , user identity , the predecryption key , a time period , the same set , and the ciphertext . If are valid shares of any secret from , then the algorithm can compute a set which makes . It computes
5.7.2. Decryption
The Dec algorithm inputs the , private user key , the predecryption ciphertext , and the symmetric decryption algorithm to generate the symmetric decryption key. This algorithm is run by the DU, and it can finish full decryption. The decryption is as follows. Using to run symmetric algorithms can enable users to get plaintext, and users will not consume a lot of costs because the previous operations are already performed in the cloud.
6. Security Proof
Theorem 4. If Pedersen (, ) secret sharing protocol is IND-CPA secure and the SR-ABE scheme presented by Cui et al. [31] is IND-CPA secure, then our BC-SABE scheme is IND-CPA secure.
Proof: In contrast to the scheme in [31], distributed consortium blockchain is used in our scheme, replacing the centralized server in [31]. This allows the security of the whole system to be improved. Supposing that the adversary in our scheme can compromise at most l-1 authority, the reasons are as follows: Our PubDKey Oracle, the UpKey Oracle, and the PreDKey Oracle have excellent performance because it needs more than authorities that are required to execute together. In addition, during the challenge phase, we defined related restrictions. Therefore, the proof of this scheme can be deduced from the security proof of the scheme [31] under the security of Pedersen (, ) secret sharing protocol, and reciprocity protocol.
Theorem 5. Under the DBDH assumption, The BC-SABE scheme is IND-sCKA secure.
Proof: Assuming that there is a PPT adversary A who can win the exponential indistinguishability game with an advantage that cannot be ignored, then the challenge B is constructed to resolve the DBDH problem with an advantage that cannot be ignored.
Init. Let be the challenge access structure defined by A.
Setup. B returns the to A by running the algorithm, the difference in is and , and other parameters are ignored here.
Phase 1. A can adaptively execute the following queries: (i)IdKey query: A issues a IdKey query on an identity , B returns by running , and then, it adds to list and returns to A(ii)Token query: A issues a token query on , an access structure , and a keyword . B runs by using . Then, B returns to A by running the algorithm. The attribute set does not meet challenge access structure(iii)Index query: A issues an index query on a keyword set and . Then, B returns the index set by running
Challenge. A submits two keywords and of the same size. B picks random , and then, it returns the to A by running the algorithm with the challenge access structure , where , , , and .
Two different situations require attention as follows: (1). Let and , and then, the index set obtained in this case is the real index. , , ,(2). In this case, A cannot get information about because of the randomness of p
Phase 2. A can perform IdKey query, token query, and index query to B. The queries sent by A must also meet the above conditional restrictions.
Guess. A performs a guess for ; if , it wins. If it is case one , then ; if it is case two , then . Finally, we can get that the probability that B can resolve DBDH assumption is
is negligible due to the difficulty of the BDDH problem; that is, it is negligible that A can break the advantage of our scheme; that is to say, our scheme is security.
7. Performance Comparison
The performance of other related scheme [34–37] is compared with this scheme in this section. Let and denote exponential operation in and ; denotes pairing operation. For convenience, indicates the number of attributes in the decryption operation and search operation in the system, indicates the number of attributes in the encryption operation in the system, denotes the number of attributes in the token generation in the system, and indicates the number of attributes in the index generation in the system. Let symmetric encryption and decryption operations expressed as .
We use JPBC library version 2.0.0 for related experiments. The experiment was simulated on Windows system with an Intel(R) Core (TM) i5 CPU 3.20GHz and 8.00GB RAM to approximate the actual operation. We have obtained the measured values of exponentiation and pairing operations. The operating times of , , and are 10.9 ms, 7.8 ms, and 0.15 ms, respectively. Table 1 shows the comparison of our scheme with other schemes in terms of encryption cost, decryption cost, and other aspects.
Figure 4 shows the comparison of the cost of encryption and decryption between our scheme and the other three multiauthority attribute-based encryption schemes. It is not difficult to see that the encryption and decryption time has a linear relationship with the number of attributes. Our scheme shifts the decryption process to operate on the cloud server, which makes the user’s computational cost effectively reduced.
(a) Encrypt cost
(b) Decrypt cost
Figure 5 compares our scheme with the scheme [36]. It is not difficult to see from the figure that our scheme is highly efficient in index generation, search, and token generation stages. Among them, in the token generation stage, our scheme transfers the work of token generation to the blockchain node, and users only need to generate part of the token.
(a) Index gen cost
(b) Tok gen cost
(c) Search cost
Obviously, because most of the calculation and storage work in the scheme is handed over to cloud servers and blockchain nodes, this makes our scheme more efficient in all aspects, especially in user decryption and token generation. Although the performance of some algorithms will be affected by the throughput of the blockchain and other factors, the security of the scheme will not be affected.
8. Conclusion
In this essay, we have presented a new BC-SABE scheme that replaces the centralized key management server in [31] using a consortium blockchain. The consortium blockchain consist of a trusted set of consensus nodes and is responsible for jointly generating the relevant partial parameters. We can guarantee the confidentiality of data transmission using the Pedersen secret sharing protocol, which enables sharing of subsecrets among consensus nodes, and the reciprocity protocol ensures that key information is shared without a trusted party. The update of the user revocation list is also performed entirely by the blockchain without re-encrypting the ciphertext. In addition, we move the predecryption operations to be performed in the cloud, and users are able to fully decrypt them with only a small amount of computation. Performance analysis shows that this scheme is more efficient compared to other schemes.
Data Availability
We guarantee the confidentiality of data transmission.
Conflicts of Interest
The authors declare that there is no conflict of interest regarding the publication of this paper.
Acknowledgments
This research was funded by the National Natural Science Foundation of China under Grant No. 61902140, No. 61972095, No. 62072104, and No. U21A20465; the Anhui Provincial Natural Science Foundation under Grant No. 1908085QF288; the Nature Science Foundation of Anhui Higher Education Institutions under Grant No. KJ2021A0527, No. KJ2019A0605, No. KJ2020A0034, and No. KJ2020A0032; the Natural Science Foundation of the Fujian Province under Grant No. 2020 J01159; and the Key Projects of Science and Technology of Henan Province under Grant No. 222102210043, No. 222102210173, and No. 222102210209.