BCAS: A blockchain-based ciphertext-policy attribute-based encryption scheme for cloud data security sharing

It is the most important and challenging problem to share the data safely in cloud computing. Some so-called trusted third parties may also infringe users’ data privacy. It is an urgent problem for data owners to share data safely with the designated users rather than the third party or other users. Traditional encryption schemes utilize different keys to produce multiple encrypted copies of the same data for users. It is no longer applicable for cloud data sharing security. Attribute-based encryption can solve above problems, but it needs to rely on trusted third parties to protect the users’ privacy. In this article, in order to address the above problems, we propose a blockchain-based ciphertext-policy attribute-based encryption scheme for cloud data secure sharing without relying on any trusted third parties. Blockchain-based ciphertext-policy attribute-based encryption scheme can protect the rights and security of data owner. Compared with existing cloud security schemes, the proposed scheme has more advantages in terms of the six aspects: (1) data owners have the authority to decide who can decrypt the data; (2) the operations of users are retained permanently, and all records are tamper-proof; (3) our proposed scheme has the characteristic of “one-to-many” encryption, and data is encrypted only once; (4) our scheme does not rely on any trusted third party; (5) in terms of the discrete logarithm problem and decisional q parallel-bilinear Diffie–Hellman exponent problem, we prove that our proposed scheme is secure; and (6) experiment shows that our proposed scheme is more efficient than the comparative scheme.


Introduction
Cloud computing 1,2 provides cost-effective and powerful data storage and management service on the Internet. The data sharing of this model is more flexible and convenient than that of the traditional storage ones. However, there are many challenges that have not yet been satisfactorily addressed in cloud storage security, [3][4][5] such as user authentication, identity management, and data security sharing and storage. At present, the data of most users are uploaded to the open cloud, which is easy to be retrieved or even attacked by others. Currently, most cloud data storage relies on the so-called ''trusted third party,'' but ordinary users cannot trust verification on the third party. In order to ensure our legal identity, the third party needs us to provide personal identity information. We cannot guarantee that the third-party platform will not damage our identity and data privacy. For trusted third parties, users have no privacy. Users cannot monitor the behavior of the trusted third party. In addition, users cannot know whether the so-called trusted third party will illegally obtain our information and data. It is also impossible for users to verify whether the trusted third party is really trusted. When using the third-party platform, we only passively choose to accept the agreements of the third party. Therefore, it is an urgent problem to be solved how to realize the trusted and secure cloud data sharing without the third party.
We use cryptography to solve most security problems in cloud computing. Key management 6-8 is a very important part of cloud computing. There are many challenges in terms of generating, managing, and distributing keys. In most cases, the key and its encryption and decryption mechanism 9 in cloud storage services are provided by the cloud service providers. It is difficult for users to learn the real security of the system, and there are many hidden dangers in the security of users' data. Many scholars have proposed a variety of encryption schemes for cloud storage. The attributebased encryption (ABE) scheme was first proposed by Sahai and Waters. 10 ABE is suitable for cloud storage systems, which has the characteristic of ''one-to-many'' encryption. What's more, ABE is better suitable for cloud data sharing. Ciphertext-policy attribute-based encryption (CP-ABE) 11 is one of the categories of ABE. In the CP-ABE scheme, ciphertext is associated with an access policy, while the user's decryption key is identified by a set of descriptive attributes. In the CP-ABE scheme, an attribute authority manages attribute sets and is responsible for issuing keys to users based on the attributes. The data owner (DO) defines the access policy and encrypts the data. The user can decrypt the ciphertext if and only if the attributes associated with its secret key satisfy the access policy in the ciphertext. CP-ABE is a very promising encryption technique for secure data sharing in the context of cloud computing environment. DOs are allowed to fully control the access policy associated with their data which to be shared. A CP-ABE scheme consists of four algorithms: Setup, Encrypt, KeyGen, and Decrypt.
Setup (l, U ). The Setup algorithm takes as input the security parameter l and the unique description of the attributes universe U . It outputs the public parameter PK and the master key MK. Encrypt (PK, M, A). The Encrypt algorithm takes as input the public parameters PK, a message M, and an access structure A over the universe of attributes. The algorithm will encrypt M and output a ciphertext CT such that only a user who possesses a set of attributes satisfying the access structure will be able to decrypt the message. We assume that the ciphertext implicitly contains A. KeyGen (MK, S). The KeyGen algorithm takes as input the master key MK and a set of attributes S. It outputs a private key SK: Decrypt (PK, CT, SK). The Decrypt algorithm takes as input the public parameters PK, a ciphertext CT which contains an access policy A and a private key SK. If the attributes set S satisfies the access structure A, then the algorithm will decrypt the ciphertext and return a message M.
Blockchain originates from bitcoin 12 which is a digital crypto-currency system proposed by S Nakamoto. 13 It is essentially an open and distributed decentralized database. The database based on cryptography and P2P network connects each block through a hash function. The database stores specific transactions in the block by utilizing the Merkle tree structure which links all transactions together. Once a transaction has been tampered, it will lead to change the root of Merkle tree hash, resulting in changing the hash of the block. If we find that the hash of a block cannot correspond to the hash of the whole network, we can request the other relevant blocks or transaction information to forward trace the relevant transactions and determine which transaction has been tampered, so as to achieve the unforgeability, non-tamperability, and traceability. 14 If a malicious user wants to tamper with a transaction, but he or she cannot obtain 51% of the computing power in the whole network. He or she also cannot get the recognition of other nodes in the whole network according to the consensus mechanism. In addition, he or she will not get the recognition of the blockchain. All transactions will be published in the whole network, and operate automatically employing the workload proof mechanism. All transactions will not be controlled by a third party. Consequently, the blockchain technology has the characteristics of open, autonomous and independent of a trusted third party. Blockchain uses cryptography technology to ensure anonymity, which makes the blockchain-based system more secure than traditional data storage systems.
The fusion of blockchain technology and cloud computing technology has a great prospect. 15 A lot of literatures applied blockchain technology to solve the problems of cloud security. At present, the blockchain technology is used to protect cloud data security. 16

Related work
Cloud computing provides the facility to store and share data and avail software, platform, and infrastructure as services. However, the security problem of cloud computing, [17][18][19] especially the security problem of cloud data and cloud storage, 20,21 has become an urgent problem to be solved, and many solutions have been put forward successively.
Most schemes use cryptography to secure cloud data, this requires the DO to encrypts the data before uploading it, so an important part of this is key management. Now, the question arises whether the keys are to be stored with DO or any other third party. In some schemes, [22][23][24] the data which are stored in the cloud are to be shared among multiple members of the particular members using group key.
In the research work, Kumar et al. 25 introduce a public key infrastructure certificate scheme to secure the cloud application program to encrypt the key, which also binds the key with files based on File-Id attributes for personal storage. It is easy to maintain and manage the keys to update, but it is required to update the user credentials regularly. Suppose if the user credentials are weak, then the security of file cannot be assured. Here, the author encrypts the stored cloud data using an elliptic curve.
Cryptographic Key Management System 26 (CKMS) provides encryption, decryption, identity authentication, integrity, and digital signatures with the help of certificate authority (CA). The owner of the data, which is to be uploaded in the cloud environment, has to register with CKMS by creating an account with login credentials. The same login credentials can be used even to upload the list of users and their permissions with whom the uploaded file can be shared. CKMS uses asymmetric encryption to generate both public and private key pair; the private key is used to encrypt the data and the public key is divided into two parts by CKMS: one part of it is transmitted to the owner, and the rest is kept with CKMS. To a certain extent, CKMS system supports ''one-to-many'' encryption, but it does not support finegrained access control. However, key management relies on CA and secure channel. Once the public key is obtained in the insecure channel transmission, or CA is not trusted, the security will be destroyed. The scheme does not consider data integrity verification.
Wei et al. 27 proposed a blockchain data-based cloud data integrity protection mechanism. In this article, the distributed agent model is deployed in the cloud using the mobile agent technology. The virtual machine agent permits multi-tenants to cooperate with each other to ensure data trust verification, and complete the tasks of reliable data storage, monitoring, and verification through the virtual machine agent mechanism. The unique hash value corresponding to the file generated by the Merkel hash tree is used to verify data integrity on the blockchain; the scheme does not rely on trusted third party. However, the encryption and security of data are not mentioned in this scheme. This scheme does not support ''one-to-many'' encryption and finegrained access control.
Block-Secure scheme 28 proposes a blockchain-based distributed cloud storage architecture, dividing users' files into several blocks of the same size, encrypting these file blocks, and signing them through a Digital Signature Algorithm (DSA). Blockchain technology is applied to trading mechanism, the architecture chooses a random file replica placement strategy in this architecture so that users can retrieve their files quickly from the cloud, which alleviates the burden of the P2P network. File integrity verification will be ensured using the Merkle Hash Tree as a validation method. Block-Secure scheme customizes a genetic algorithm to solve the file block replica placement problem between multiple users and multiple data centers in the distributed cloud storage environment. This scheme can reduce the data upload time and solve the data integrity verification. However, cloud data security sharing is limited because it is unable to support the fine-grained access control.
In order to ensure the security of cloud storage, many ABE schemes have been proposed to improve the efficiency, security, and expressiveness. ABE introduced by Goyal et al. 29 is a suitable solution for fine-grained access control in cloud storage systems. Generally, ABE can be classified into two main types: (1) Key-policy Attributebased Encryption (KP-ABE): a user's secret key is related to an access policy, while a ciphertext is labeled by a set of attributes and (2) Ciphertext-policy Attribute-based Encryption (CP-ABE): a ciphertext is associated with an access policy, while the user's decryption key is identified by a set of descriptive attributes.
The tuCP-ABE Scheme 30 belongs to the CP-ABE scheme. Aiming at the existing security problems of cloud computing, the tuCP-ABE Scheme provides a secure encryption strategy. The key is generated and managed by two authorities central authority (CA) and outsourcing authority (OA). If users want to obtain data, they need to cooperate with two authorities CA and OA to generate the decryption key. As the user can access the data after the identity authentication, the tuCP-ABE Scheme has high security. A single CA or OA can neither get the decryption key, nor decrypt the data. To some extent, it is difficult to collude. The tuCP-ABE Scheme is a solution suitable for finegrained access control in cloud storage systems, and it has high security. However, this scheme does not involve the user who provides the data and the user who is responsible for the data encryption. Key negotiation only involves two authorities and the user who requests the data. The user who provides the data cannot control the data provided by himself. If the user who provides the data cannot control who can access the data, the security is meaningless. In a real environment, to decrypt a small amount of data, two authorities are needed to generate the key, which is a waste of resources. In other words, the scheme relies on a trusted third party and the efficiency of key generation is low. Data integrity is an important part of data security and privacy, including key integrity, ciphertext integrity, and message integrity.
Blockchain-based ciphertext-policy attribute-based encryption scheme (BCAS) stores the hash of the key, the hash of the ciphertext, and the hash of the decrypted data in the blockchain. On one hand, the malicious user cannot obtain the ciphertext, the key, and the initial data through the hash. On the other hand, it can be used for data integrity verification. When the DO uploads the encrypted data to the cloud storage, he or she needs to upload the hash of the ciphertext and the hash of the initial data to the blockchain. The system will verify the ciphertext and the hash of ciphertext, and the data can be uploaded successfully only after the data verification is passed. After DR requests the data through the data label, it verifies whether the encrypted data are damaged. Then, the key needs to be generated by DO and DR. Then, each party uploads its own hash of the key, and both parties confirm the key in the blockchain. After the key generation, DR decrypts the encrypted data and then submits the hash of the decrypted data to compare with the initial data hash to verify the integrity of the decrypted data.
tuCP-ABE scheme verifies the integrity of the key, Wei et al. 27 , and Block-Secure scheme verifies the integrity of the encrypted data, in which Block-Secure scheme divides the data into blocks and provides a better replacement strategy for the file copy. CKMS system does not talk about integrity verification.
The results of comparison are shown in Table 1. FGAC means that it supports fine-grained access control, and O2M means that it supports ''one-to-many'' encryption, one user to encrypt and upload data, and multiple users to decrypt with their own independent key. TTPfree means that it does not rely on the trusted third party, SKIV is short for Secret Key Integrity Verification, CTIV is short for Ciphertext Integrity Verification, and MIV is short for Message Integrity Verification.

Our contributions
This article is distinct from other research works in related fields. We combine the advantages of blockchain and ABE and propose a BCAS. The main contributions of this article are as follows: We have defined the concept of cloud data security sharing and its important indicators clearly. On this basis, we propose a BCAS scheme for cloud data security sharing. In our scheme, DOs have the authority to decide who can decrypt the data. DOs encrypt the data and upload the encrypted data to the cloud environment through the blockchain system (BCS). Data requesters (DRs) must negotiate the key through the BCS that can be used to decrypt data with the DO. In our scheme, all operations of users need to be conducted in the BCS. The operations are retained in the blockchain permanently, and all records are tamper-proof. Our proposed scheme has the characteristic of ''oneto-many'' encryption. Data are only encrypted once. Users who meet the attribute requirements can negotiate the key with the DO. In our scheme, the global public parameters are initialized by the setup mechanism in the BCS, and the users negotiate the key in the BCS without relying on the trusted third party. We prove that our proposed scheme is secure based on Discrete Logarithm (DL) assumption and decisional q parallel-bilinear Diffie-Hellman exponent (BDHE) assumption. We compare and analyze our scheme with the other four schemes in terms of ''one-to-many'' encryption, integrity verification, and so on. According to the comparison, we find that our scheme is superior to other schemes.
We compared our scheme with the tuCP-ABE scheme 30 through four experiments. When the number of the messages is the same, with the increase in attributes, the time and storage of the whole process in our scheme are obviously less than those in tuCP-ABE scheme. For different processes with the same attribute, the time and storage of party key generation step and decryption key generation step are obviously better than those of tuCP-ABE scheme. What's more, DOs in our scheme have the right to decide who can decrypt the data, which would achieve the real security.

Organization
The rest of this article is organized as follows. In section ''Background,'' we introduce the definition of cloud data security sharing and related assumptions of our scheme including DL assumption and decisional q parallel-BDHE assumption. Then, we propose the BCAS and introduce transaction structure and process in section ''Architecture design.'' We introduce a specific encryption and decryption scheme for BCAS in section ''Our construction of BCAS scheme.'' In section ''Security and performance analysis,'' we proof the security of our scheme, and present the performance analysis by experiment. Finally, we conclude this article in section ''Conclusion.''

Background
Definition 1: cloud data security sharing. Cloud data security sharing focuses on data security storage and sharing in the cloud storage platform (CSP). DO can upload the encrypted data. Other users who want to decrypt the data need to obtain a unique decryption key with the consent of the DO. In other words, the data only need to be encrypted once, and the users who meet the requirements have their own unique key to decrypt. DO has its own absolute control over the uploaded data and is also responsible for its own uploaded data. All the actions of users will remain unchanged and cannot be tampered with. Users cannot deny their actions. In general, to realize cloud security sharing, we need to achieve the following: Support Fine-grained Access Control: support finegrained access control policy, DO encrypts the data, and other users can negotiate with the DO to generate a unique decryption key after meeting the attribute requirements. TTP-free: the operation of key management and data storage does not depend on the third party. Definition 2: bilinear maps. g is a prime-order bilinear group generator which takes a security parameter l as input and outputs prime-order bilinear groups (G, G T , e, p), where p is a prime, G, G T are the two cyclic groups of order p, and e : G 3 G ! G T is a bilinear maps. The bilinear map e has the following properties: Non-degeneracy: 9g 2 G such that e(g, g) has order p in G T .
Computability: e can be efficiently computed.
Assumption 1: DL assumption. The advantage of an algorithm A in solving the DL problem is defined to be We say that G satisfies the DL assumption if Adv DL (A) is a negligible function of security parameter l for any polynomial algorithm A.
Definition 4: decisional q parallel-BDHE problem. Inputting s * = g, g s , g a , . . . , g a q , g a q + 2 , . . . , g a 2q Assumption 2: decisional q parallel-BDHE assumption. The advantage of an algorithm A in solving the decisional q parallel-BDHE problem is defined to be We say that G satisfies the decisional q parallel-BDHE assumption if Adv BDHE (A) is a negligible function of security parameter l for any polynomial algorithm A.

Architecture design
We proposed a new cloud secure storage and sharing scheme for a series of security problems in cloud computing, namely, BCAS. Compared with the existing cloud security schemes, the proposed scheme is more advantages: 1. Authority of DO: DOs have the authority to decide who can decrypt the data. 2. Tamper-Proof: operations of users will be retained permanently in the blockchain. 3. Fine-grained Access Control: we have developed the CP-ABE scheme to achieve the secure data sharing. 4. ''One-to-Many'' Encryption: the data are encrypted by DO only once. 5. TTP-free: the scheme does not use any TTP throughout the execution of the scheme.

Architecture
In this section, we present an architecture for cloud storage and sharing called BCAS. As it is shown in Figure 1, the architecture consists of four entities like CSP, BCS, DO, and DR. DO and DR are different identities merely for different options on cloud. A user is a DO when uploading data and a DR when requesting to download data. When the user is used for different identity, the corresponding ID is different: 1. DO is an identity of the user which encrypts and uploads the data into the CSP and has full control over it.
2. DR is an identity of the user which would like to accesses and decrypts data stored in CSP. 3. BCS is a data and user management system based on blockchain. Each operation of the user will be stored in the blockchain as a transaction. Ensure the integrity and credibility of transactions using the tamper-proof of blockchain. BCS plays an important role in our architecture, which provides confidentiality (encryption and decryption), authentication of an identity, data authentication, integrity, User authority control, key management, and storage of user operation records. BCS will reduce the malicious operation of users, malicious operation will remain in BCS permanently, and users will be punished accordingly. Blockchain is a distributed database which structure as shown in Figure 2, Ti (i=1,2,3,...) is a specific user operation, including viewing, accessing, registering, uploading, downloading and other operations as well as accessing users and timestamps. 4. CSP is an open storage platform, which is only used to store encrypted data. Other operations are managed through BCS.
The whole process that DR requests the encrypted data uploaded to DO through BCS and obtains the decryption key to decrypt the data successfully is called transaction in our architecture. A complete transaction includes the following contents: First, users who want to upload or download data in the cloud environment must provide identity certificate information to register identity with BCS, which generates independent data upload identity and data download identity for users. Then, when DO needs to submit its own data upload identity to upload data. After passing the BCS verification, DO needs to submit the data encrypted by ABE technology and relevant information. After passing the BCS verification information, BCS will save the relevant information and user's operations in the blockchain and upload the encrypted data to the cloud. Finally, if DR wants to access the data in the cloud, it needs to provide the data download identity. After BCS verifies the information is legal and the DO agrees the request of DR, DO and DR negotiates the key, which is used for DR to decrypt the data. After BCS verification, DR can applies for the data to the BCS, and then DR uses the key to decrypt the data.
A specific transaction is all or part of a complete transaction. BCS will store the contents of the transaction and its timestamp on the blockchain. If DR determines that the data uploaded by the DO are illegal, the blockchain can provide relevant evidence to prove that, if a user accesses the data in the cloud storage space maliciously, it will also be recorded in the blockchain. For users who often maliciously operate, the blockchain will store the user's data If Id is added to blacklist, the user's operation permission in cloud storage will be restricted or even punished.

Transaction structure
A complete transaction shall include the identity of both parties, data-related information, key, operation, and corresponding timestamp. The structure of the transaction is shown in Figure 3.
It should include the following: IDInfo. IDInfo is the identity information of the transaction user, including the identity of the data uploader and the identity of the DR. When users perform different operations, they need to provide the corresponding identity. The storage format of identity in the transaction is as follows:   used by the user to find the data. The address is the storage address of the encrypted data in the cloud storage. The data are downloaded from the cloud storage to the system. The hash is used to verify whether the corresponding data of the label are complete. The format of data is as follows: ' Identity register. IDRegister (ID) ! (IDInfo DO , IDInfo DR ): the ID of users register algorithm is run by BCS. All users who want to upload or download data in the cloud need to register identity information in the blockchain. Users include DO and DR. BCS will generate unique identity information IDInfo DO and IDInfo DR for different identities of users. The blockchain will stores the user's register operation and the hash value of IDInfo DO and IDInfo DR . Users need to provide their own upload or download data, which can be followed up only after the BCS audit.
User key generation. UKeyGen (GPP) ! (SK, PK): the user key generation algorithm is run by user. Each user who wants to upload or download data in the cloud needs to generate his own public-private key pair (SK, PK) for authentication and encryption/decryption key generation, where SK means the secret private key and PK means the public key. The public-private key pair of DO is (SK DO , PK DO ), and the public-private key pair of DR is (SK DR , PK DR ). To ensure security, SK used by the same user in different identities should be different, and the corresponding PK should also be different. The SK of the user is kept by himself, and the PK is disclosed in the whole network.
Encryption and upload. Encrypt (GPP, SK DO , (W , r), M) ! C (W , r) : the encryption algorithm is run by DO. According to the given plaintext M, and access structure (W , r), DO encrypts the data with secret private key SK DO and GPP, uploads the ciphertext, and provides the corresponding label for other users to access. BCS will store the hash of the ciphertext, the corresponding label, and the address in the cloud storage.
In the upload process, the blockchain will record the DO's upload data application and operation. DO provides their own IDInfo DO for the blockchain. After the authentication is passed, the encrypted data will be uploaded into CSP. Once the user is reported to upload the malicious data, the corresponding data in the CSP will be cleared, but the upload record will be permanently saved. It will affect the user's own permissions and ensure that the vast majority of users upload data legally. In order to ensure that the data are wrong or tampered with in the process of transmission process, DO also needs to upload the hash value of the data. When the block link receives the encrypted data uploaded by the user, it needs to verify the integrity of data first. If it does not meet the requirements, it needs to be uploaded again.
Decryption key generation. DecryptKeyGen (GPP, (SK DO , PK DO ), (SK DR , PK DR ), S, u) ! SK DR, S : the decryption key generation algorithm is run by DO, DR, and BCS. DR needs to submits IDInfo DR to BCS to verify identity. When request data from DO, then DO determines the identity of DR. DR uses key SK DR to generate signature L, and submits identity and attributes together with signature L to DO. DO verifies the signature L, causing DO to confirm DR's identity. After confirming the identity, DO generates part of the key, respectively, DO sends the key by secret channel to DR, and DR summarizes all the keys as the final decryption key. In terms of the correctness of the final decryption key, DO and DR calculate the hash value and verify it in the BCS.
Decryption. Decrypt (W , S, SK DR, S , C (W , r) ) ! M: the decryption algorithm is executed by DR. DR obtains the necessary additional decryption parameters for decryption, downloads the encrypted data from the cloud, and decrypts the data with the decryption key and decryption parameters.

Our construction of BCAS scheme
According to the structure and specific process we proposed, we designed a detailed BCAS Scheme.

Global parameter setup
BCS chooses the security parameter l, and generates two cyclic groups G, G T of prime order p. g, g 1 are the two random generators of G: e : G 3 G ! G T is a bilinear map. For each attribute att i 2 U , BCS chooses randomly t i 2 R Z p and lets T i = g t i . The algorithm picks two secure hash functions H 1 : represents the bit length of the identity information.
The global public parameter GPP is (p, G, G T , e, g, g 1 , fT i g att i 2U , H 1 , H 2 ). GPP is published in the BCAS system, and all nodes in the network will receive parameters.

Identity register
Users register their personal identity in BCS, and submit their identity information to BCS. Users get two identities IDInfo DO and IDInfo DR generated by BCS.

User key generation
User randomly selects elements a 1 , a 2 , a 3 , x DR 2 R Z p . The user is DO if the user uploads the data to the cloud storage. DO chooses a 1 , a 2 , a 3 2 R Z p as his private key SK DO , and publishes (P 1 = e(g, g) a 1 , P 2 = e(g, g) a 2 , P 3 = g a 3 ) as his public key PK DO : The user is DR if the user downloads the data from the cloud storage. DR chooses x DR 2 Z p as his private key and publishes PK DR = g x DR as his public key. The public key of the user is published throughout the network.
The process of user identity registration and key generation is shown in Figure 4.

Encryption and upload
Given the message M (raw data that users need to encrypt and share) and the access structure (W , r), where W is a l 3 k matrix, the ciphertext C (W , r) = (C, C 0 , fC i , D i g i2½l ) is generated according to Algorithm 1. Figure 5 shows the data encryption and upload operation. After the message M is encrypted and the personal information is verified, the ciphertext C (W , r) , the data label, the message hash (MH), and the ciphertext hash (CH) are submitted by DO to BCS. Then, BCS verifies the ciphertext and the CH. If verification is correct, the ciphertext and the label are uploaded to the cloud. All operations of DO, CH, and MH are retained in the blockchain.
Decryption key generation DR needs to do the following to access the data uploaded by DO: First, DR needs to submit the identity information IDInfo DR to the BCS, and the system confirms that DR has registered and recorded the request operation of DR. Then, DR selects a one-time random number r DR 2 R Z p , which uses the signature key x DR 2 Z p to calculate L = h x DR 1 , where h 1 = H 1 (r DR , PK DR , IDInfo DR ) and sends (r DR , L, h 1 , PK DR , IDInfo DR , S) secretly to DO. DO verifies the correctness of L with e(L, g) = e(h 1 , PK DR ). If not, the transaction is terminated; on the contrary, DO searches (IDInfo DR , Ã , Ã, Ã , Ã ) in list L DO . If not,(IDInfo DR , L, PK DR , S) is stored in the list L DO and calculates h 2 = H 2 (PK DO , L).
The key SK DR, S = (h 2 , u, K, K 0 , K 00 , fK i g att i 2S ) of DR with attribute set S can be generated as follows: DO chooses u, s2 R Z p , and computes K = g s , K 0 = g a 1 =h 2 g s 1 , K 00 = g a 2 =u g s DO sends (u, K, K 0 , K 00 , fK i g att i 2S ) to DR secretly. Then, DR computes h 2 = H 2 (P DO , L). Finally, DR obtains the decryption key as follows SK DR, S = h 2 , u, K = g s , K 0 = g a1=h2 g s 1 , K 00 = g a2=u g s After the calculation is done, DO and DR will upload the hash value of the key, respectively, to verify the correctness of the key.
The process of DO and DR negotiating to generate the DR decryption key is shown in Figure 6.
Decryption DR requests and obtains encrypted data C (W , r) = (C, C 0 , fC i , D i g i2½l ) from BCS. For the encrypted data, DR is obtained fw i : i 2 Ig first such that P i2I w i W i = (1, 0, . . . , 0), where the index set is I = fi : att r(i) 2 S 0 g. If the attribute set S 0 satisfies the access structure (W , r), DR can recover the message as follows

Security and performance analysis
The proof of security The confidentiality (IND-CPA security) of the proposed scheme can be proved directly based on the decision q parallel-BDHE assumption. We denote the CP-ABE scheme by Waters 10 as WCP-ABE. For simplicity, we will reduce the security of the proposed scheme to that of WCP-ABE scheme.
Lemma 1. We say the WCP-ABE scheme is IND-CPA secure if the (decision) q parallel-BDHE assumption holds.
Proof. The details of proof are referred to Waters. 9 Lemma 2. If DO is a trusted data provider, the confidentiality of the proposed BCAS scheme can be reduced to that of the WCP-ABE scheme. Input: the message M, the access structure (W, r). Output: the ciphertext C (W, r) = (C, C 0 , fC i , D i g i2½l ).
1. DO chooses a random vectorṽ = (r, y 2 , . . . , y k )2 R (Z p ) k and random elements r 1 , . . . , r l 2 R Z p . 2. DO computes C 0 = g r , C = M(e(g, g) a1 e(g, g) a2 ) r . 3. For i = 1 to l, DO computes Proof. If DO is a trusted data provider, DR and DO run the Decryption Key Generation algorithm. The Decryption Key Generation algorithm is as follows: 1. DR selects a one-time random r DR 2 R Z p and computes L = h x DR 1 , where h 1 = H 1 (r DR , PK DR , IDInfo DR ) and sends (r DR , L, h 1 , PK DR , IDInfo DR , S) secretly to DO. 2. DO verifies the correctness of L by e(L, g) = e(h 1 ,PK DR ), where h 1 =H 1 (r DR ,PK DR ,IDInfo DR ). If it holds, DO searches (IDInfo DR , Ã, Ã, Ã, Ã) in list L DO . Else, he stores (IDInfo DR ,L,PK DR ,S,h 2 ) in L DO , where h 2 =H 2 (P DO ,L). DO chooses u,s2 R Z p , and computes K = g s , K 0 = g a 1 =h 2 g s 1 , K 00 = g a 2 =u g s DO sends (u, K, K 0 , K 00 , fK i g att i 2S ) to DR secretly. DR computes h 2 = H 2 (P DO , L). Then, DR obtains the decryption key as follows SK DR, S = h 2 , u, K = g s , K 0 = g a1=h2 g s 1 , K 00 = g a2=u g s If there is an adversary A that can break BCAS scheme with advantage Adv A , we can construct an adversary B against WCP-ABE with advantage Adv B such that Adv B = Adv A . The construction is as follows, where C simulates the queries both from A and B: Setup. C gives B the WCP-ABE public parameters (p, G, G T , e, g, e(g, g) a , g 1 = g a , fT i g att i 2U ). C randomly selects a 1 , a 2 , a 3 2 R Z p and gives (p, G, G T , e, g, g a , e(g, g) a , g 1 , fT i g att i 2U ) to A as public parameters of the BCAS scheme, which implicitly sets a 1 = a 2 = a 3 = a. Phase 1. A submits a attribute set S with identity U for DecryptKeyGen oracle. C generatesK = g s ,K 0 = g a g 1 s , fK i = T S i g att i 2S by running the KeyGen algorithm (or a KeyGen oracle queried by B) of WCP-ABE. Then, C computes and returns SK DR, S = (h 2 , u, K, K 0 , K 00 , fK i g att i 2S ) to A, where implicitly sets h 2 = u. Challenge. A submits two messages M 0 , M 1 of equal length along with target access structure W, C flips a random coin b 2 f0, 1g and generates the BCAS challenge ciphertext C W 0 = (C, C 0 , fC i , D i g i2½l ) of M b . C returns C W 0 to A and sends ((C=(e(g, g) ar e(g, g) ar )), C 0 , fC i , D i g i2½l ) to B.

Guess.
A outputs a guess bit b', then B outputs the same b' for WCP-ABE.
From the above simulation, the distributions of the public parameter, decryption keys, and challenge ciphertext are indistinguishable from the real scheme, we have Adv B = Adv A . Lemma 3. A curious-but-honest illegal user cannot decrypt any ciphertext.
Proof. Here, we give a heuristic analysis. A curious-buthonest illegal user needs to get r to decrypt ciphertext M(e(g, g) a 1 e(g, g) a 2 ) r e g, g ð Þ a 1 e g, g ð Þ a 2 ð Þ r ! e g, g ð Þ a 1 r e g, g ð Þ a 2 r ! M However, it is related to DL to compute r. Under the DL assumption, the illegal user cannot decrypt any ciphertext.
Theorem 1. If the (decision) q parallel-BDHE assumption holds, then the proposed blockchain-based CP-ABE scheme is IND-CPA secure.

Comparison and analysis
We make a deeper comparison between our scheme with tuCP-ABE scheme.
Efficiency. We compare the efficiency of our scheme with that of tuCP-ABE scheme. The main difference between the two schemes lies in the key generation process. In order to guarantee the security, tuCP-ABE scheme choose two third parties CA and OA to assist users in generating encryption and decryption keys. CA and OA will not collude with each other to ensure the security of the keys. The interaction process is shown in Figure 7.
Our BCAS scheme uses blockchain instead of two authorities, which can simplify the interaction process and improve the efficiency of key generation. To facilitate the comparison, we build Table 2 to compare the process of key generation between the two parties.
In the actual application scenario, the encryption data are uploaded to the cloud first. If DR finds the file and wants to access the file, DR can negotiate the key with DO to decrypt the data. Therefore, in our scheme, we first encrypt and upload the data, and then negotiate the key. However, in tuCP-ABE scheme, the key is negotiated before the encryption of data. In order to facilitate the comparison, we exchange the order of our encryption and key generation, which has no impact on our specific comparison results: Step 1: GlobalSetup. Generate global public parameters. The two schemes use similar GPP. In the first step, the efficiency of the two schemes is similar.
Step 2: IDReg. User identity registration, the tuCP-ABE scheme does not mention how to generate the ID. Compared with the following key generation processes, the ID generation process is relatively simple. We think the efficiency of the two schemes is similar.
Step 3: ParKeyGen. The key generation phase of the participants. In BCAS scheme, users generate their own public key/private key pair. This process is equivalent to that in tuCP-ABE, CA and users generate their own public key/private key pair, respectively. In this step, the efficiency of the two schemes is similar.
Step 4: DecKeyGen. Generate decrypt key. In BCAS scheme, DO and DR generate the decryption key. The operation of DO is equivalent to the operation of CA in tuCP-ABE scheme, and the operation of DR is equivalent to the operation of U in tuCP-ABE scheme. Compared with tuCP-ABE scheme, BCAS scheme saves the negotiation between CA and OA, and directly calculates the final key. In addition, BCAS scheme has less calculate D, K 000 than tuCP-ABE scheme, and the calculation process of K 0 , K 00 is also simplified. In the process of calculating the key, the parameters and the calculation are reduced. So, in this step, the efficiency of BCAS is higher than tuCP-ABE scheme.
Step 5: Encrypt. In this step, both BCAS scheme and tuCP-ABE scheme are encrypted, but the ciphertext generation process and the ciphertext are different. BCAS scheme has a smaller amount of calculation than tuCP-ABE scheme, BCAS scheme does not need to calculate C 00 = g br , the calculation process of C is simplified. So, in the encryption step, the efficiency of BCAS scheme is higher than that of tuCP-ABE scheme.
Step 6: Decrypt. In this step, both BCAS scheme and tuCP-ABE scheme are decrypted. The decryption process of BCAS scheme is relatively simpler, mainly because BCAS scheme reduces bilinear pairing operation. It has higher efficiency.
In addition to the efficiency difference in the above steps, there are four secret transmissions between users and third parties in tuCP-ABE scheme. In our scheme, it only takes two times. With the decrease in secret transmissions, the security dependence of the transmission channel decreases. In the process of key generation, tuCP-ABE scheme needs CA to calculate the parameters involved in generating intermediate key and ciphertext. As it is faster in the process of encryption and decryption, our scheme is more efficient in actual use.  Storage. To ensure the security, tuCP-ABE scheme uses two trusted third parties CA and OA to help users in generating the key and generates multiple intermediate keys in the process of generating the final decryption key. Compared with BCAS scheme, the final key generated by tuCP-ABE scheme has more parameters, longer key length, longer ciphertext, and larger storage space. BCAS scheme simplifies the process and parameters, so the final key and ciphertext take up less memory. In our BCAS scheme, the decryption key obtained by DR is while the user's key in tuCP-ABE scheme is our key is more compact and occupies less memory space.
In our BCAS scheme, the ciphertext of DO encryption is: C (W , r) = (C, C 0 , fC i , D i g i2½l ), where the data corresponding to the relevant characters in the ciphertext are as follows C = M e g, g ð Þ a1 e g, g ð Þ a2 r , The encrypted ciphertext in tuCP-ABE scheme is: CT (W , r) = (C, C 0 , C 00 , fC i , D i g i2½l ), where the data corresponding to the relevant characters in the ciphertext are as follows C = M e g, g ð Þ a1b e g, g ð Þ a2b e g, g ð Þ a3b r , When the same plaintext M is being encrypted, the memory of C in tuCP-ABE scheme is larger than that in BCAS scheme, and it takes additional memory space for the ciphertext to store C 00 .
DO authority. In tuCP-ABE scheme, DO is not mentioned. In the process of key generation, DR negotiates key with CA and OA. To a certain extent, the DO has no controlling authority over the data, and the control authority over the data is in CA and OA. Although the security of the tuCP-ABE scheme is high, this data security can only ensure that malicious users cannot obtain the key for data decryption, but the DO may not have the authority to manage the access authority of other users. Even if CA and OA audit the DR with the authorization of the DO, but the DO cannot control the decryption key, it may lose the control of the data to some extent. In this way, data security will lose its most fundamental significance: only when the DO has the right to authorize other users to access the data, without the authorization of the DO, it is safe to access the plaintext.
In our scheme, first, the user's identity is authenticated through the BCS. In the key negotiation process, DO and DR negotiate the key. DO has legal control over own data. DO can not only know who will access the data but also control who can decrypt the data. Only the DR who is authenticated by the DO. Only in this way can we negotiate with the DO to obtain the decryption key and decrypt the data. That is, our scheme realizes the DO's control authority to the data provided by himself on the premise of ensuring security.
Experimental results. To evaluate the difference of performance between the proposed BCAS scheme and tuCP-ABE scheme, we implement the BCAS scheme and the tuCP-ABE scheme in C with the PBC library Microsoft Visual C++ 6.0. We run the experiments on a Windows 10 system which is equipped with a quadcore Intel CPU and 8 GB RAM. Figure 8(a) and (b) shows the comparison of performance between two schemes of the same M, attributes, and access structure in different steps. Figure 8(a) shows that BCAS scheme takes less time than tuCP-ABE scheme, and Figure 8(b) shows that BCAS scheme consumes less storage space than tuCP-ABE scheme, especially in Step 3 (ParKeyGen) and Step 4 (DecKeyGen). BCAS scheme has better performance than tuCP-ABE scheme by reducing the interaction and computation of the third party. Figure 9(a) and (b) shows the comparison of performance between two schemes of the same M in different attributes. Figure 9(a) shows that with the increase in attributes, the runtime of whole process in tuCP-ABE scheme is longer than that in BCAS scheme, and Figure  9(b) shows that with the increase in attributes, the storage space of whole process in tuCP-ABE scheme is larger than that in BCAS scheme.

Conclusion
In this article, we propose the BCAS cloud data sharing security scheme without any trusted third party. Using blockchain to authenticate users' identities and control their access authority, we achieve the cloud security sharing without a trusted third party. Users need to register their identity to access, upload, and download the data in CSP. In our architecture, blockchain plays an important role. It guarantees the traceability of user's operations and the verification of data integrity through its own characteristics. In this scheme, the data in the CSP will not be accessed by illegal visitors unless the user is authenticated. In addition, our scheme combines the CP-ABE scheme to protect the data security in the CSP and enables the DOs to control their own data. Finally, we also prove the security of the scheme and analyze the security of the model. The experimental results show that our scheme has better performance than the contrast scheme. The BCAS can protect the user's private key and support fine-grained access control policy. Compared with the previous methods, BCAS scheme does not rely on the cloud service providers or the trusted third parties. It can protect the authority of the DO and achieve the secure data sharing. All the operations are not be tampered and the security is better guaranteed.

Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by the Key-Area Research and Development Program of Guangdong Province (grant no. 2019B010137002) and the Natural Science Foundation of Fujian, China (grant no. 2020J01171).