Abstract
Attribute-based encryption (ABE) is a powerful encryption scheme with flexible access control over encrypted data that has been widely adopted in cloud computing scenarios to facilitate data sharing. However, despite convenience and efficiency provided by data sharing based on cloud, it is commonly vulnerable to issues like key abuse (namely, illegal key sharing by user or key distribution by authority) and key escrow (namely, illegal decryption by ABE authority). Hence, exploring a more secure ABE scheme that can be key abuse and key escrow resistant is crucial. Furthermore, data modification that happens in cloud storage and outsourced computation is also a challenge for the cloud-based data sharing schemes. To handle the above issues, in this paper, we propose a secure and efficient data sharing scheme based on attribute-based encryption (ABE) and blockchain equipped with InterPlanetary File System (IPFS). In particular, we show that the large-universe ABE with outsourced decryption (LU-ABE-OD) scheme proposed by Ning et al. is vulnerable to key escrow attack, which is not secure enough in the data sharing scenario. Therefore, based on their basic proposal, we construct an improved multi-authority LU-ABE-OD scheme to encrypt personal data, which are stored in the IPFS system while blockchain is applied to store the hash value returned by IPFS and be responsible for the outsourced decryption. As a result, our scheme greatly reduces the decryption overheads of the user while risks of key abuse and key escrow can be settled. Meanwhile, the introduction of IPFS significantly reduces the storage burden on chain without data tampering problem. Through theoretical analysis and experimental simulation, we prove the feasibility, security, and efficiency of our scheme.
1. Introduction
With the advent of the era of big data, the storage, processing, and sharing of massive data has become a bottleneck. To solve this issue, cloud storage has been considered to be the most efficient, convenient, and economical method for many users. However, the trust issue in terms of data privacy between the cloud and users is brought up, and thus encrypting sensitive data before they are uploaded is of great significance. Furthermore, apart from data privacy, particular scenario like data sharing always requires flexible access of encrypted data, which leads to the necessity of a fine-grained access control encryption scheme.
Attribute-based encryption (ABE), a cryptographic primitive proposed by Sahai and Waters [1] that guarantees only those who possess certain attributes can access the targeted encrypted data, is proved to be a positive solution. According to Goyal et al. [2], ABE schemes can be generally divided into two patterns: ciphertext-policy ABE (CP-ABE) and key-policy ABE (KP-ABE). In a CP-ABE scheme, the access policy is embedded into ciphertexts and user’s private key is associated with an attribute collection, which is widely used in traditional cloud-based data sharing scenarios. However, practical applications based on basic ABE schemes suffer from the restriction of small-universe setting (SU-ABE) [3], in which the attribute universe must be determined when generating public parameters and no attribute can be added then. Hence, large-universe ABE (LU-ABE) [3] was proposed, realizing the unbounded attribute universe so that new attributes can be added arbitrarily. Meanwhile, key abuse and key escrow issues remain challenges to be faced. Specifically, the former risk can be caused by malicious users illegally sharing their keys (which can also be maliciously attained by attacker, namely, key leakage) and attribute authority (AA) illegally distributing keys to unauthorized users while the latter risk mainly caused by curious AA who masters all users’ private keys and intends to violate their privacy. For key abuse problem, traceable ABE schemes [4–6] were proposed to track the owner of leaked or abused key to relieve subsequent impact. For key escrow issue, multi-authority ABE (MA-ABE) schemes [7–9] were considered to be promising since the powerful decryption ability of a single center has been dispersed and none of the centers can illegally intrude on users’ privacy.
Apart from all the above, traditional ABE schemes also suffer from the limitation in efficiency. Furthermore, data encrypted by ABE will lead to huge decryption costs. To solve these issues especially for resource-limited users, Green et al. [13] proposed the outsourcing decryption scheme of ABE (ABE-OD), which greatly reduces local decryption overheads by outsourcing most of decryption tasks to the cloud. Later, based on Waters’s CP-ABE scheme, Lai et al. [14] realized the verification of ABE-OD in the standard model to handle the malicious computation in ABE-OD scenarios. Along the previous constructions, schemes [15–19] have been proposed to promote efficiency and reduce costs. Nonetheless, the introduction of cloud in the above leads to the centralization of system, which will bring up problems of data tampering.
Blockchain, with its powerful decentralized mechanism, has attracted a growing number of researchers and provides feasible approaches to address the impact of cloud since data stored on chain are tamper resistant and transparent. Efficient blockchain-based CP-ABE schemes for specific data sharing scenarios like electronic health records (EHRs) and Internet of Things (IoT) [20–26] have received widespread attention. However, in most mentioned cases, the decryption of ciphertexts is still outsourced to cloud while blockchain is only used to record access control data in which storage burden on chain raises another problem. Fortunately, benefiting from peer-to-peer distributed storage systems such as InterPlanetary File System (IPFS) [27] and distributed hash table (DHT) [28], the challenge of on-chain data storage can be well solved through stored off chain. Schemes in [12, 29, 30] adopting such distributed storage system instead of on-chain or cloud storage are proved secure and efficient. Furthermore, according to the above proposals, blockchain can also be considered as an effective technique that takes over decryption tasks as the role of cloud, thus making it significant to explore both secure and efficient blockchain-based data sharing scheme.
1.1. Motivation
In traditional data sharing scenarios, cloud computing and cloud storage are usually adopted to process data. However, despite great convenience brought by the introduction of the third party, it unavoidably leads to trust issues. Most schemes assume that the third party (i.e., the cloud) is semi-trusted or even trusted, which means users can only confirm whether the result of outsourced computation is correct and the stored data are tampered. Nonetheless, it cannot prevent the underlying threat of data modification by malicious cloud in practice. To address the issue of data tampering, a promising solution is to introduce blockchain or shared database for storage instead of the cloud. However, in terms of huge computational costs of ABE decryption in data sharing scenarios, we should also consider the improvement of decryption efficiency especially for the users who are resource-limited. Blockchain equipped with smart contracts or chaincode, which can perform specific computing task, provides a feasible solution. Among the previous mentioned blockchain-based data sharing schemes, proposals in [20–26] ignored the huge data storage on chain. Wang et al. [29] proposed an improved scheme by IPFS, but the user has to take huge computational costs, while Wang et al. [12] put forward an ABE-OD scheme assisted by blockchain to reduce users’ costs, but it ignored the security in practice. Pham et al. [30] considered both security and efficiency, but their scheme lacks concrete instantiation and security analysis. Therefore, it is still necessary to explore a secure and efficient blockchain-based access control and data sharing scheme, which is the focus of this article.
1.2. Contributions
In this paper, we mainly propose a data sharing system based on blockchain and ABE which can achieve both high security and efficiency for data users. In particular, we present a blockchain-based large-universe multi-authority CP-ABE with outsourced decryption scheme (LU-MAABE-OD) based on basic outsourced CP-ABE scheme proposed by Ning et al. [10] and traceable multi-authority CP-ABE scheme proposed by Zhang et al. [11]. Our contributions are as follows:(i)We construct a user-friendly data sharing scheme that combines large-universe CP-ABE and blockchain to promote flexibility and efficiency. The constant size of public parameters makes the system more scalable, and it will be practical and convenient for users to join without the limitation on attribute universe. Moreover, partial decryption assisted by smart contracts or chaincode in blockchain instead of the cloud in traditional scenarios can further reduce the computation overhead of the user side since the verification is not necessary.(ii)Our proposed scheme is multi-authority based and key escrow and key abuse resistant. The user’s decryption secret key is produced by the collaboration of two semi-trusted parties, i.e., key generation center (KGC) and attribute authority (AA), which is also blinded by the public key owned by user, so that none of participants can forge the key alone. Besides, in our scheme, the key generated is a transformation key which can just partially recover the ciphertexts and can be public, and thus none of the third party can recover the ciphertexts (i.e., the encapsulated key). Furthermore, due to the sophisticated design of key sanity and owner check mechanism before the decryption of blockchain, the public transformation key can only be used by its owner in our system, thus avoiding malicious computation burden on chain.(iii)We give formal security analysis and concrete construction which proves that our proposal is feasible and secure. Besides, experimental simulation and comparison indicate that our scheme is efficient, especially for resource-constrained users.
Table 1 shows a functional comparison between our proposal and several representative related schemes.
1.3. Organization
We organize the rest of our paper as follows. In Sections 2 and 3, we briefly review the related work and preliminaries involved in our scheme, respectively. Then, in Section 4, the overview of our system model, system assumptions, formal description, and security model will be displayed. In Section 5, we will describe our concrete scheme and security analysis in detail. Next, we evaluate the system in Section 6 and finally draw a conclusion in Section 7.
2. Related Work
2.1. Attribute-Based Encryption
Attribute-based encryption (ABE), first proposed by Sahai and Waters [1], was a sophisticated cryptography scheme that could support flexible and fine-grained access control, thus commonly being used in data sharing scenarios. However, the huge computational overhead has been the bottleneck, thus attracting numerous relevant research studies [31–33] on promoting the security, expressiveness, and efficiency of ABE. Among them, a promising method to reduce costs of user is to outsource partial decryption to a proxy (i.e., cloud), which was formalized in [13] as ABE with outsourcing decryption (ABE-OD). In such a setting, users only need to expose a transformation key to cloud while the final decryption key is kept secretly. To solve the invalid decryption in ABE-OD scenarios, Lai et al. [14] put forward a verifiable ABE-OD scheme while sacrificing the size of ciphertexts and operation complexity compared with [31], followed by schemes [16–19] proposed to achieve higher efficiency and expressiveness. However, all of the above schemes restrict the final decryption and verification to individual who owns the final decryption key, thus leading to inflexible data sharing and access since data users must obtain the final decryption key from the data owner. Besides, the limitation on attribute universe restricts their practical scenarios because no additional attribute can be added when the public parameters are set up, which was defined as small-universe ABE (SU-ABE) [3]. For better scalability, large-universe ABE (LU-ABE) [3] was put forward so that new attributes can be added arbitrarily. Nonetheless, key abuse and key escrow remain two obstacles. To achieve higher security, traceable ABE schemes [4–6] that could deal with key abuse issue were proved effective by embedding user’s id in the key. In 2017, Ning et al. [10] presented an efficient key abuse resistant LU-ABE-OD scheme while it depends on a single authority that is considered to be honest, thus leading to key escrow problem. To remove the impact caused by centralization of single authority, multi-authority ABE schemes [7–9] which could deal with key escrow problem were proposed. Since the key is jointly generated by multiple AA, any AA cannot forge the key or decrypt underlying data. Later, Zhang et al. [11] proposed a multi-authority LU-ABE scheme which is resistant to key escrow and key abuse attack. In their scheme, the key was comprised by the collaboration of two authorities (i.e., KGC and AA) and traceable mechanism was integrated to follow the abused key. However, the user decryption cost has not been taken into consideration so that it cannot be well performed particularly for resource-limited users. Furthermore, although all of the abovementioned ABE schemes can achieve higher efficiency or security in data sharing scenarios, most of them ignore the impact of malicious cloud services while data integrity is of great significance especially for data owners. In a word, research on more secure data sharing scheme is worthy of exploration.
2.2. Blockchain-Based Data Sharing Scheme
The development of blockchain technology contributes to addressing issues in data sharing caused by traditional cloud storage system due to its transparency and tamper resistance. For better combination with practical applications, schemes in [20–23] proposed blockchain-based EHRs sharing models and schemes in [24–26] put forward blockchain-based sharing models in scenario of IoT (Internet of Things). Despite the sophisticated design of ABE schemes that can support traceable, searchable, and outsourced decryption, key leakage resistance, etc., none of them concentrates on the storage burden on chain caused by huge ABE ciphertext storage overheads. To reduce overheads on chain, distributed storage systems like IPFS and DHT have been widely concerned. Based on IPFS and smart contracts, Wang et al. [29] put forward a data sharing model in which personal data management is controlled by data owner himself. Despite the promotion of privacy, data owner has to bear huge computation costs of key generation and distribution while data user has to take on the whole decryption cost, too. Similarly, Wang et al. [12] put forward a personal privacy data protection scheme based on blockchain and DHT, combing proxy reencryption scheme to outsource partial decryption task to blockchain and achieving access transparency. Nonetheless, data owner still undertakes large amounts of computation tasks and the proposed ABE scheme is actually poor in security. Later, a decentralized storage system combining IPFS, ABE, and blockchain was proposed by Pham et al. [30] without concrete construction and experimental analysis that can prove the feasibility. Therefore, exploring a more secure and efficient data sharing scheme in decentralized storage system remains an issue.
3. Preliminaries
In this section, we briefly present the involved basic knowledge related to our system.
3.1. Bilinear Pairings
Let , and denote three multiplicative cyclic groups of the same prime order . and are the generators of and , respectively. is a bilinear map with properties as follows:(i)Bilinearity: for all , .(ii)Non-degeneracy: .(iii)Computability: should be efficiently computable.
3.2. Access Structure
Definition 1. (access structure [34]). Let be the attribute universe. A collection is monotone while satisfy that if and then . An access structure (respectively, monotone access structure) is a collection (resp. monotone collection) of non-empty subsets of , i.e., . The sets in are called the authorized sets while the sets not in are called the unauthorized ones. In this paper, the role of the parties is delegated by attributes. Thus, is a collection of authorized attributes and we only discuss the monotone access structure.
3.3. Linear Secret Sharing Schemes (LSSS)
Definition 2. Let denote the attribute and be a prime. A secret sharing scheme over a set of parties on is called linear (over ) if it satisfies(1)The shares of secret for each attribute form a vector over .(2)For each access structure on , there exists a share-generating matrix with rows and columns for . And for , a function labels row of with attribute from . During the generation of the shares , we consider the column vector , where are randomly chosen. Then the vector of shares of according to is equal to . The share where “belongs” to attribute .
According to [34], each linear secret sharing scheme satisfying the above definition enjoys the linear reconstruction property, defined as follows: suppose that is an LSSS for an access control , and is an authorized set. Let be defined as . For any valid shares of a secret according to , there exist constants such that .
3.4. Blockchain and IPFS
First proposed in [35], blockchain is known as the underlying concept of Bitcoin and can simply be considered as a distributed ledger in the peer-to-peer network, in which all transactions can be recorded on chain. As each transaction in blockchain is public, traceable, and tamper resistant, it gradually plays an important role in various industrial scenarios (i.e., medical, financial, educational, and so on) and blockchain-based system Ethereum [36] and Hyperledger Fabric [37] have achieved prominent achievement. Most significantly, the introduction of blockchain solves the trust problem in traditional centralized systems due to the arrival of smart contract [38] (in Ethereum, or called chaincode in Hyperledger Fabric), which is a series of codes that can be executed and recorded automatically when running conditions are triggered. Once executed successfully, the result cannot be tampered. Nonetheless, blockchain has to undertake the issue of massive data storage on chain, and a promising method is to transfer the data off chain. IPFS, a peer-to-peer distributed file system proposed by Benet [27], provides a promising solution. Unlike traditional Internet HTTP protocol which needs to search the domain address, IPFS is designed to search the content address so that any peer can be a server and can also request the file in content-addressed block, thus contributing to cheaper, faster, and more secure network services. With the assistance of IPFS, the hash value of data can be stored on chain instead while the data can be stored in IPFS. So far, the combination of blockchain and IPFS system has attracted attention from researchers in different fields.
3.5. Review of Ning Et Al.’s Basic Scheme [10]
Our blockchain-based outsourced CP-ABE scheme is related to that of basic outsourced CP-ABE scheme [10] proposed by Ning et al., so we now revisit it. According to their construction, the system is composed of four entities, namely, cloud, authority (AA), data owner (DO), and data user (DU), in which cloud is semi-honest (who will obey the protocol but try to collect private information of users as possible) while AA is honest (who is totally trusted by other entities). Their construction can be briefly depicted as follows:(i)Setup: with the input of a security parameter , this algorithm (run by AA) produces a bilinear group and randomly chooses elements and . It outputs the system public parameters and system master secret key .(ii): with the input of public parameters , this algorithm (run by cloud) randomly chooses and generates the public key and secret key of cloud.(iii): with the input of public parameters , this algorithm (run by DU) randomly chooses and generates the public key and secret key of user.(iv)KeyGen: with the input of public parameters , public key of cloud , public key of user , the system master secret key and attribute set of user ., this algorithm (run by AA) randomly chooses and then computes . It finally outputs the secret key .(v): the algorithm (run by DU) simply sets and returns the transformation key .(vi)Encrypt: with the input of public parameters and an LSSS access structure , this algorithm (run by DU) first randomly chooses and to construct a column vector and computes the vector of shares . It also randomly chooses for each and . It then computes , in which the encapsulated key is and ciphertext is .(vii): with the input of public parameters , the ciphertext , the transformation key and secret key of cloud , this algorithm (run by cloud) calculates a share to attributes in and computes the constants with the set of rows in such that . If does not satisfy the access structure , it outputs . Otherwise, it calculates And it outputs the partially decrypted ciphertext .(viii): with the input of a partially decrypted ciphertext and the user secret key , the algorithm (run by DU) calculates and outputs As is proved in [10], the above construction is secure under the proposed security model. Nonetheless, it cannot be practical in terms of the honest AA. In fact, if we consider AA as a semi-honest party, the proposed scheme will no longer be secure under key escrow attack.(ix)With the master secret key , semi-honest AA privately calculates . With the given ciphertext , semi-honest AA withdraws .(x)AA easily computes which is actually the encapsulated key , thus making the system insecure.
To sum up, scheme in [10] is insecure in the security model comprised of semi-honest AA, and thus solving key escrow issue caused by such single-authority system and exploring scheme with higher security is necessary.
4. Our Construction
In this section, we mainly propose our construction of system model, system assumptions, formal description, and security model.
4.1. System Model
In our blockchain-based data sharing model, key/data encapsulation mechanism (KEM/DEM) [39] is applied in which our LU-MAABE-OD scheme is involved to generate the symmetric session key for encrypting data. As depicted in Figure 1, our data sharing model mainly consists of five entities, namely, key generation center (KGC), attribute authority (AA), data user (DU), data owner (DO), and blockchain (BC) equipped with smart contracts (SCs) or chaincode (chaincode is preferred in our system) and IPFS.(i)KGC: the key generation center who participates in the setup of public parameter and key generation of DO and DU.(ii)AA: the attribute authority who participates in the setup of public parameter and key generation of DO and DU.(iii)DO: the owner who expects to share some data with those who satisfy specific access structure, so he/she needs to determine the access policy and the symmetric session key which is encrypted by KEM ciphertexts and further used to encrypt shared data; then he/she generates DEM ciphertexts which will be uploaded to IPFS together with KEM ciphertexts. After uploading, DO only needs to save the IPFS address of KEM/DEM ciphertexts to BC.(iv)DU: the user who owns certain access structure and wants to access data. DU is uniquely labelled by his/her public identity in the whole system. Besides, DU possesses his/her own public and secret key pair which contributes to the generation of private transformation key together with his/her attribute set and with the help of KGC and AA. The transformation key can be public while the secret key is always kept privately and used to make final decryption.(v)BC: the data storage center which is maintained by a number of recording nodes, which are called miners in public blockchain like Ethereum and authorized nodes in permissioned blockchain like Hyperledger. In our scheme, BC with SC/chaincode can also undertake the task of partially decrypting KEM ciphertexts. To relieve the burden on chain, all the KEM/DEM ciphertexts are stored in IPFS while the addresses of IPFS are stored on chain. When needed, BC will retrieve the corresponding data through the IPFS address.
The workflow can be mainly described as follows:(i): in the phase of system public parameter generation, both KGC and AA will participate and keep their master keys secretly. Any user (i.e., ) can randomly choose his/her private key and generate his/her public key according to system public parameter. It should be noted that no user can use a duplicate public key.(ii): KGC and AA audit the authentication information together with attribute set , which can be denoted as a pair (, ) submitted by and collectively generate his/her transformation key .(1) forwards his/her key pair to KGC. After audited, an intermediate key will be produced and sent to AA.(2)After receiving, AA generates the final decryption key and sends it to .(3) simply keeps as the transformation key .(iii): with the help of KEM/DEM mechanism, DO encrypts data with the generated encapsulated key which is encrypted by KEM ciphertexts to produce DEM ciphertexts, and then KEM and DEM ciphertexts will be uploaded to IPFS. If finished, corresponding IPFS addresses should be saved on chain for searching.(iv): to obtain the encapsulated key for decryption, DU can decrypt KEM ciphertexts with the help of chaincode according to the following steps.(1)DU can invoke the chaincode which is preencoded and deployed by one system maintainer of blockchain for helping decryption. If executed, the chaincode will check whether is used by the key owner. It first checks whether of DU satisfies , in which is the embedded value in that records the hash of key owner’s . If it fails, decryption will be refused. Otherwise, it will then do key sanity check to validate whether is just forged by changing . If it fails, decryption will also be refused. It should be noted that such checking is designed to avoid heavy burden caused by invalid decryption of malicious users.(2)If the key is confirmed to be used by its owner, KEM ciphertexts from IPFS will be decrypted and partially decrypted ciphertext will be sent back to DU through chaincode.(3)DU finally decrypts with his/her private key and achieves the encapsulated key that can be further used in the decryption of DEM ciphertexts stored in IPFS.
We briefly take the medical data sharing scenario as an example for the better understanding of our protocol. We choose Hyperledger as the blockchain in which recording nodes are composed of some permissioned regulators and the preencoded decryption chaincode is deployed by one of them, and the system initiators are KGC and AA. Any user can generate their own public-secret key pair according to the system public parameter and then achieve the transformation key generated by the cooperation of KGC and AA according to his/her unique label and access structure in the system. According to the specific access policy, DO who wants to share medical data can generate KEM ciphertexts that can decrypt the encapsulation key, which can be further used to encrypt the medical data to DEM ciphertexts, and then KEM/DEM ciphertexts are uploaded to IPFS. DU who wants to access medical data but lacks computing power can decrypt KEM ciphertexts by invoking the deployed chaincode with the transformation key. During the execution of the chaincode, it will first check whether the key is used by its owner. If not, the execution of the chaincode will fail. Otherwise, the chaincode will output the decrypted result and DU only needs to decrypt the encapsulation key with his/her secret key by performing one exponential operation and finally decrypts the DEM ciphertexts from IPFS with the encapsulation key to achieve the underlying medical data. It is easy to find that the application of blockchain can not only solve the problem of tamper-resistant data storage but also help the decryption of resource-limited users with chaincode.
4.2. System Assumptions
In this paper, we suppose all the entities are driven by their interests and not entirely trusted.(i)KGC: it is a semi-honest entity who may be curious about the data owned by DO and the secret key of DU, but it will honestly execute the agreed protocol. Besides, it is noted that KGC will never collude with AA.(ii)AA: it is also a semi-honest entity who may be curious about the data owned by DO and the secret key of DU, but it will honestly execute the agreed protocol. Besides, it is noted that AA will never collude with KGC.(iii)DO: DO may be curious about the data owned by other DOs and he/she will always keep his/her secret key in the system.(iv)DU: DU may be curious about the data that he/she cannot access and he/she will always keep his/her secret key in the system.(v)BC: in terms of the consensus protocol of blockchain, we consider this entity as a semi-honest one, which means the recording nodes will honestly obey the specific protocol and run chaincode, but they may also be curious about the underlying data. Besides, they are restricted not to collude with KGC and AA at the same time.
4.3. Definition
According to the description above, a formal definition of our proposed LU-MAABE-OD scheme consists of ten probabilistic polynomial time (PPT) algorithms as follows.(1): with a security parameter , this algorithm (run by KGC) produces KGC public parameter and KGC master secret key .(2): with KGC public parameter , this algorithm (run by AA) produces AA public parameter and AA master secret key . And it finally outputs system public parameter which is denoted by the union .(3): with public parameter , the output of this algorithm (run by user) is the public key and master secret key of user.(4): with public parameter , KGC master key , user public key together with his/her attribute set and id label , this algorithm (run by KGC) produces the partial decryption key .(5): with public parameter , AA master key , partial decryption key , the user’s attribute set and id label , this algorithm (run by AA) produces the final decryption key .(6): with final decryption key , the output of this algorithm (run by user) is the user transformation key .(7)Encrypt: with public parameter and the LSSS access structure chosen by DO, this algorithm (run by user) produces the encapsulated key which is further used for generation of DEM ciphertext and outputs KEM ciphertext .(8)KeySanityCheck: with public parameter and user transformation key , this algorithm (run by BC) checks whether the key is well-formed and used by its owner. If it passes, this algorithm will output 1. Otherwise, it outputs 0.(9): with public parameter , user transformation key , and KEM ciphertext , this algorithm (run by chaincode invoked by DU) produces the transformed ciphertext if the passes KeySanityCheck and access structure embedded in it satisfies the given access policy. Otherwise, it outputs .(10): with the transformed ciphertext together with user master secret key , this algorithm (run by user) finally produces the encapsulated key for decrypting DEM ciphertext.
4.4. Security Model
Let , , , , , , , , , denote our LU-MAABE-OD scheme. To concretely define the security notion of , specific security requirements should be satisfied which can be described as the following security games.
Definition 3. (RCCA-secure ABE with outsourcing [13]). A CP-ABE scheme with outsourcing is RCCA-secure if any PPT adversary can win the RCCA game defined as follows with at most negligible advantage.(i)CPA security: it is defined that a scheme is CPA-secure, namely, secure against chosen-plaintext attacks if cannot make decryption queries.(ii)Selective security: it is defined that a scheme can achieve selective security if an Init stage is added before Setup where commits to the challenge .RCCA-secure game for malicious DU which is similar to scheme [10]: in our LU-MAABE-OD scheme, the security model of RCCA security game can be denoted by , in which the adversary interacts with the challenger .(1)Setup: executes algorithm and , then is forwarded to .(2)QueryPhase-1: initializes an integer counter , an empty table , and a set . answers the following queries from :(i)Create(S): sets and then executes to achieve a user master secret key and public key . It then runs on attribute-identity pairs to fetch the intermediate decryption key . It also executes on to fetch the final decryption key (can also be denoted by ). Afterwards, on is run to fetch the user transformation key . Eventually, the entry is stored in .(ii)Corrupt.SK(i): checks whether the - entry is in . If such an entry exists, and is returned to , or is output.(iii)Corrupt.TK(i): checks whether the - entry is in . If such an entry exists, will be returned to , or is output.(iv)Decrypt(i,ct): checks whether the - entry is in . If there is such an entry, it then returns the decryption on , or it will output .(3)Challenge: a challenge value is submitted by , which has the restriction that does not satisfy . then executes Encrypt to achieve ciphertexts , and then a random bit is selected. If , is returned, or a random key is chosen in the encapsulated key space and it returns if .(4)QueryPhase-2: the same as QueryPhase-1 except it should satisfy the restrictions that neither can issue a Corrupt query nor can make a Decrypt query on .(5)Guess: outputs a guess of . It is defined that wins the game if .
Definition 4. The LU-MAABE-OD is RCCA-secure if any PPT adversary can win the above game with at most a negligible advantage.
Key Sanity Check Game. In our LU-MAABE-OD scheme, the security model of key sanity check game is similar to scheme [11] and can be denoted by , in which the adversary interacts with the challenger .(1) invokes to run algorithm and to produce the system parameter , the master secret key of KGC , and AA .(2) returns , a ciphertext together with two distinct transformation keys and which are associated with the same attribute-identity label .(3)It is defined that wins if the following requirements are satisfied:(i), which indicates that both of transformation keys can pass the key sanity check.(ii), which indicates that both of transformation keys can be used to decrypt the ciphertext.(iii), which indicates that the results of decryption by two transformation keys are different.
Definition 5. LU-MAABE-OD is a scheme that can make key sanity check if any PPT adversary can win the above game with at most a negligible advantage.
5. LU-MAABE-OD Construction
5.1. Construction
Our LU-MAABE-OD scheme is based on the idea in [10, 11], and the detailed construction is described in Figure 2.
5.2. Correctness
The correctness of our LU-MAABE-OD scheme is proved as described in Figure 3.
5.3. Security Analysis
Theorem 1. Assume that the CP-ABE scheme in [33] is selectively CPA-secure, and the proposed LU-MAABE-OD scheme is selectively CPA-secure with respect to Definition 4.
Proof. We simply denote the LU-MAABE-OD system proposed in Section 1 by , , , , , , , , , and the CP-ABE system in [33] by , , , . To prove the security of , we reduce the selective security of it to , which indicates that if there is an adversary who can selectively break with a non-negligible advantage , it can also be used to break . We build a PPT adversary with a challenge access structure that can selectively break with a non-negligible advantage and a PPT simulator algorithm that can selectively break with a non-negligible advantage . In the system, challenger of is denoted by .(1)Init: receives a challenge access structure selected by and sends it to .(2)Setup: after obtaining , generates public parameter in which and then sends it to . Once received, chooses at random and sets , , , .(3)QueryPhase-1: initializes an integer counter , an empty table , and then answers the queries from as follows:(i)Create(S): with an attribute-identity set issues the decryption key query. When receiving, forwards to and obtains a secret key . Next, randomly chooses and computes . To formalize, the user public key is set as while user master key is . Then, computes , , , , . Let , , and then are random numbers due to the randomness of , respectively. Therefore, inherits the randomness. It sets the transformation key and the entry is stored in .(ii)Corrupt.SK(i): checks whether the - entry is in table . It then returns to , or if there is no such entry.(iii)Corrupt.TK(i): checks whether the - entry is in table . It then returns to , or if there is no such entry.(4)Challenge: declares two messages of the same length which are forwarded to . Then, they are sent to by and achieve a challenge ciphertext . Then, selects a random bit to calculate and returns to the new challenge ciphertext .(5)QueryPhase-2: the same as QueryPhase-1.(6)Guess: outputs a guess bit . If , it denotes that is a random key and outputs . Otherwise, it means that is guessed as the key encapsulated by and outputs .Obviously, if can selectively break our scheme with a non-negligible advantage , can also selectively break scheme with the same advantage.
Theorem 2. In our LU-MAABE-OD scheme, the advantage of any PPT adversary winning in the key sanity check game is negligible.
Proof. It is similar to the proof in [11]. We build a PPT adversary in our LU-MAABE-OD scheme, which can be denoted by . It produces the public parameter , a ciphertext , and two different transformation keys , . wins the game only if the following three requirements are all satisfied.(i).(ii).(iii).Based on the first condition, we have for , it satisfies.(i).(ii).Based on the second condition, we have for , there isTherefore, we will finally achieve , from which we can calculate that.(i).(ii).It is obvious that the respective decryption result is the same which contradicts with the last condition. Thus, the advantage that can win the game is negligible.
Theorem 3. In our LU-MAABE-OD scheme, semi-honest KGC or AA cannot recover the underlying encrypted data and secret key of DU since they are not allowed to collude with each other.
Proof. Suppose is a PPT adversary who is curious about obtaining the encapsulated key and DU’s private key .(i)For DU’s private key, can easily obtain the public parameter and DU’s private key message . To obtain DU’s secret key , either a semi-honest KGC or a semi-honest AA as is required to solve discrete logarithm problems of computing or , which are considered to be impossible for any PPT adversary. Therefore, any semi-honest KGC or AA cannot illegally obtain DU’s secret key.(ii)For the encapsulated key, can easily obtain the public parameter and ciphertext message related to calculating . If is a semi-honest KGC (who cannot collude with AA), with the master secret key , can easily calculate . To obtain,at least one of DU’s secret key (which has been proved difficult for PPT adversary to achieve), AA’s secret key and random secret information should be obtained; otherwise, KGC can never decrypt due to the discrete logarithm problem of computing or . If is a semi-honest AA (who cannot collude with KGC), similarly, it is required to obtain or or ; otherwise, is required to handle the discrete logarithm problem of computing or . In a word, any semi-honest KGC or AA cannot illegally obtain encapsulated key.
Lemma 1. In our LU-MAABE-OD system, any PPT adversary cannot abuse public or leaked transformation key which is not owned by him/her.
Proof. Suppose there exists a PPT adversary (with his/her identity ) who wants to abuse public (since the transformation key will be publicly recorded after it is used through BC) or leaked transformation key which is not owned by him/her. It is noted that due to our sophisticated design, chaincode invoked by will make a check before decryption. If in the transformation key does not satisfy , chaincode will reject to provide decryption services and produce . Otherwise, it will make a key sanity check to validate whether the transformation key is well-formed. If it passes, can make a decryption through chaincode, or it will be rejected. According to Theorem 2, can only win the game with a negligible advantage, and thus cannot abuse public or leaked transformation key which is not owned by him/her.
6. System Analysis
In this section, we will evaluate the practical performance and the challenges brought by blockchain system in our scheme.
6.1. Performance Evaluations
We evaluated the performance of our scheme and made a comparison with three other existing schemes [10–12] in terms of overheads of the following stages: Setup, KeyGen, Encrypt, and Decrypt. It should be noted that we evaluated all the costs in the former three stages while only the user decryption time was evaluated in the last stage.
We implemented our LU-MAABE-OD scheme in software based on Charm [40] (Version 0.50). To make a comparison, we also implemented the scheme in [10–12] and MNT224 elliptic curve is applied. All the experiments were executed on a computer equipped with 2.4 GHz Intel Core i5 with 8 GB of RAM running MacOS Mojave 10.14.6 and Python3. By increasing number of policy attributes from 1 to 100, we compared the total running time in stage of Setup, KeyGen, Encrypt, and Decrypt. For accuracy, we repeated 50 times for each scheme and the average was taken as the results in our figures and the time is all given in seconds.
As shown in Figure 4, we examine the time cost of Setup, from which we can find the overhead in [12] is linear to the attribute universe while that of our scheme and [10, 11] is constant. As the introduction of two authorities, costs in our scheme and in [11] are 0.02 s higher than those in [10] on average. Figure 5 shows the cost of KeyGen, from which we can follow that our scheme costs much more than [10, 12] for the reason of key blindness by two authorities, which will unavoidably increase considerable overheads. However, compared with another multi-authority scheme in [11], our scheme improves the efficiency of nearly 2.8 s on average when the user attribute size is 100. From Figure 6 which tests the cost of Encrypt, it is shown that scheme in [10, 11] and our scheme achieve nearly the same encryption efficiency while scheme in [12] is around 2.6 s faster on average when the policy attribute size is 100 owing to the low-paid small-universe construction of access tree. Figure 7 displays the Decrypt cost in user side, which only costs a constant time of 0.004 s on average in our scheme because most of cost is taken by blockchain. Despite the use of outsourced decryption, scheme in [10] can also achieve constant decryption cost, but it is about 0.013 s lower than that of our scheme as the verification of decryption result from cloud is needed while it is unnecessary in our scheme. It is noted that although blockchain-assisted decryption is adopted in scheme [21], heavy computation is still required for users which is linear to the attribute size and in scheme [11], the whole decryption task is taken by users so that huge overheads will be put on the user side. As a result, our scheme achieves higher security compared with [10, 12] while efficiency on KeyGen and Encrypt has been sacrificed; however, the high performance of Decrypt is realized so that our scheme is made especially applicable for resource-constrained data users. Besides, with the same high security, our scheme performs better than scheme in [11] in terms of overall overheads.
6.2. Blockchain Analysis
As mentioned above, our system implementation is based on blockchain, and the IPFS data storage and partial decryption by smart contracts/chaincodes are the keys to solve on-chain storage burden and user computing overheads in traditional schemes. Therefore, we need to consider some problems that may be brought by the introduction of blockchain platform. In terms of public blockchain like Ethereum, resource-limited DU can ask blockchain to make outsourced decryption and the execution cost of smart contracts needs to be paid by DU for the help of decryption. However, due to the technique problem that smart contract cannot well support pairing operations in ABE currently, it is not recommended to be deployed in Ethereum until the related language library (i.e., Solidity) is introduced. Besides, regular problems like network congestion remains to be further discussed. In terms of permissioned blockchain like Hyperledger, it can be deployed in scenarios like healthcare and IoT data sharing, in which the system is maintained by a number of authorized nodes (i.e., data center managers). Since the key received by chaincode is just the transformation key which can be public and the final secret key to decrypt is always kept by DU themselves, the underlying data will also never be achieved illegally by those nodes. Besides, even if these nodes can collude with one of AA and KGC, according to the analysis of Theorem 3, as long as AA and KGC do not collude with each other, the underlying data and the user’s secret key will not be disclosed, and thus the collusion between the node and AA/KGC will not affect the security. Therefore, under the assumption of this article mentioned in Section 2, the system is still secure.
7. Conclusion
In this paper, an efficient large-universe multi-authority CP-ABE scheme with blockchain-assisted outsourced decryption (LU-MAABE-OD) for data sharing system is proposed. In particular, we extended the basic outsourced scheme based on [10] and introduced two authorities (namely, KGC and AA) to avoid key escrow problem which was ignored in [10] while key leakage resilience was reserved. Then, the technique of blockchain and IPFS was applied to be responsible for outsourced decryption and data storage, solving the issue of malicious decryption in traditional cloud computation scenarios and storage burden on chain, respectively. As of independent interest, our scheme was also key abuse resistant due to the key owner and key sanity check through chaincode on blockchain. Furthermore, we evaluated the performance and discussed the security of our LU-MAABE-OD scheme. As a result, our scheme achieved higher security at the expense of some efficiency. However, LU-MAABE-OD was user-friendly in terms of the most lightweight user decryption cost, which was especially needed for resource-limited data users. For the future work, we think it is promising to explore more significant functions like attribute revocation, user revocation, and policy hiding and devote to promoting overall efficiency in such blockchain-based access control and data sharing system.
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
This study was supported in part by the National Natural Science Foundation of China (62002120), Shanghai Rising-Star Program (no. 22QA1403800), Innovation Program of Shanghai Municipal Education Commission (2021-01-07-00-08-E00101), NSFC-ISF Joint Scientific Research Program (61961146004), and the “Digital Silk Road” Shanghai International Joint Lab of Trustworthy Intelligent Software (Grant No. 22510750100).