# BSSPD: A Blockchain-Based Security Sharing Scheme for Personal Data with Fine-Grained Access Control

Authors: Hongmin Gao; Zhaofeng Ma; Shoushan Luo; Yanping Xu; Zheng Wu
Journal: Wireless Communications and Mobile Computing
 (2021)

---

## Abstract

Privacy protection and open sharing are the core of data governance in the AI-driven era. A common data-sharing management platform is indispensable in the existing data-sharing solutions, and users upload their data to the cloud server for storage and dissemination. However, from the moment users upload the data to the server, they will lose absolute ownership of their data, and security and privacy will become a critical issue. Although data encryption and access control are considered up-and-coming technologies in protecting personal data security on the cloud server, they alleviate this problem to a certain extent. However, it still depends too much on a third-party organization’s credibility, the Cloud Service Provider (CSP). In this paper, we combined blockchain, ciphertext-policy attribute-based encryption (CP-ABE), and InterPlanetary File System (IPFS) to address this problem to propose a blockchain-based security sharing scheme for personal data named BSSPD. In this user-centric scheme, the data owner encrypts the sharing data and stores it on IPFS, which maximizes the scheme’s decentralization. The address and the decryption key of the shared data will be encrypted with CP-ABE according to the specific access policy, and the data owner uses blockchain to publish his data-related information and distribute keys for data users. Only the data user whose attributes meet the access policy can download and decrypt the data. The data owner has fine-grained access control over his data, and BSSPD supports an attribute-level revocation of a specific data user without affecting others. To further protect the data user’s privacy, the ciphertext keyword search is used when retrieving data. We analyzed the security of the BBSPD and simulated our scheme on the EOS blockchain, which proved that our scheme is feasible. Meanwhile, we provided a thorough analysis of the storage and computing overhead, which proved that BSSPD has a good performance.


---

## Body

## 1. Introduction

The development of 5G and Internet of Things technology provides a large amount of training data for the rapid implementation of artificial intelligence (AI). At the same time, data security and privacy protection have become the most interesting topics in data governance and sharing. Powerful data mining and analysis have brought potential threats to personal privacy protection. Traditionally, most people choose to outsource their data to cloud servers for sharing and dissemination. However, most of the data stored in the cloud is very sensitive, especially those data generated by IoT devices that are closely related to human life. These data have their particularities and may contain personal-related information such as life, work, and healthcare; once personal data is stolen or leaked illegally and linked to the data owner’s real identity, it may bring great trouble to an individual. Therefore, integrating data and generating value while ensuring data security and privacy have become a significant challenge for all contemporary companies that use big data and AI.At present, researchers have proposed many secure sharing schemes in the cloud environment [1–9]. These schemes seem to solve the security and privacy issues during data sharing. Nevertheless, these schemes all have a standard feature: they are overly dependent on the Cloud Service Provider (CSP). They believe that the CSP is a trusted third-party organization, and their security models assume that the CSP is semitrustable, which means that the CSP will be curious about the data but will not destroy it. It means that the following situations are always inevitable:
(1)
The CSP itself may make profits from the user’s private data, or its insiders may do evil and cause the user’s privacy disclosure. Although some methods, such as attribute-based encryption algorithms, can achieve user-defined access policies that seem user-centric, these methods still require a trusted third party to generate and manage user keys. It is impossible to exclude the possibility of collusion between these trusted centers. All these will lead to the fact that once the data owners upload their data to the cloud server, they will no longer have their data’s absolute possession(2)
The data is centrally stored on cloud servers and managed by the CSP. An inevitable single point of failure may lead that users cannot obtain their data generally by using the cloud service. The CSP can improve data security and service stability by utilizing disaster recovery backup. However, some irresistible factors will prevent users from using cloud services to obtain their data, such as political factors(3)
To provide better service, the CSP needs to spend more money to buy servers, hire better employees, rent the data center venues, and so on. These costs are increasing gradually, and the CSP cost is also increasing and the construction of the management platform. Users ultimately pay the operating costs of the CSPFrom the above point of view, to better protect data security and personal privacy, it is very urgent to design a whole user-centric data-sharing scheme to solve the above problems. In this scheme, we do not need to rely on any trusted third party to store and disseminate data, nor do we worry that the data will be inaccessible. Fortunately, with the emergence and development of Bitcoin [10], as a decentralized and self-organized cryptocurrency, its underlying technology blockchain can elegantly help us realize such a data security sharing scheme [11–14]. In this paper, we proposed a data-sharing scheme based on blockchain. The main contributions of this paper are as follows:
(1)
A user-centric data security sharing scheme named BSSPD is proposed, which combines blockchain, CP-ABE, and IPFS. The data owner encrypts his sharing data and stores it on IPFS to maximize decentralization, and BSSPD allows the data owners to have fine-grained access control over their data. Moreover, it supports revoking permissions of a specific data user at an attribute level without affecting others(2)
In BSSPD, the data owner publishes data-related information and distributes decryption keys for data users through the blockchain. To avoid denial of service attacks, data users need to complete a proof of work (PoW) before registering, which is similar to the mining process of Bitcoin, and the data owner can adjust the target of PoW according to the number of data users in the system(3)
BSSPD sets ciphertext keyword indices for each data-related data user. Combined with CP-ABE, it further prevents the privacy disclosure that data labels may cause to the data owner and protects the data user’s privacy during retrieval(4)
We experimented with our scheme on the EOS blockchain and provided the detailed implementation of algorithms and Smart Contracts. Together with the security analysis, it proved that our scheme is feasible(5)
We used five MacBooks to build an EOS private chain in the laboratory environment and simulated our scheme. Analysis of storage and computing overhead proved that BSSPD has a good performanceThe rest of this paper is organized as follows. Section2 consists of related works. Section 3 reviews some preliminary knowledge used throughout this paper. In Section 4, we have an overview of our scheme. Specific implementation details are described in Section 5. Security and performance analysis are discussed in Section 6. Finally, the conclusion and future direction are presented.


## 2. Related Work

As early as 2015, Swan pointed out that there was not yet an acceptable “health data common” model [15] with appropriate privacy and reward systems for public sharing of personal health data and quantified self-tracking data. Simultaneously, the author believes that blockchain can precisely provide such a structure for creating a secure, remunerated, and owner-controlled health data sharing. Zyskind et al. described a distributed personal data management system [16] that ensures users own and control their data. The system encrypts the data collected from the user’s mobile phone and stores it off-chain and only stores the data’s hash value on the blockchain. Meanwhile, two acceptable transaction types named Taccess and Tdata are defined, in which Taccess is used to implement access control management, and Tdata is used for data storage and retrieval. Azaria et al. proposed MedRec system [17], a blockchain-based decentralized record management system for electronic medical records (EMRs). MedRec provides patients with a comprehensive and immutable log, and the patients can access their medical information at any time across providers and locations. However, the system implements permissionless blockchain with PoW consensus, lacking data security, data privacy, and throughput. Xia et al. proposed MeDShare [18], a system that solves the problem of sharing medical data in a trustless environment by custodians of medical big data. Dubovitskaya et al. have proposed a framework for managing and sharing EMR data for cancer patient care [19]. It uses a permission chain to maintain metadata and access control policies and uses cloud services to store the encrypted data. Patients can define their access control policies to ensure data security and availability. The above-mentioned data-sharing schemes based on blockchain give an ideal blueprint, but most of them only describe the scheme’s outline and do not provide the implementation details of the required protocol.In the following years, many researchers have designed and implemented more robust access control protocols on blockchain to protect data privacy and security during sharing. Liang et al. used the consortium chain Hyperledger Fabric to realize a user-centric health data-sharing model [20] in which the cloud storage is used as a data warehouse and the blockchain ledger is constructed to store operations such as query and update. At the same time, it uses the member management service provided by Hyperledger Fabric to strengthen the users’ identity authentication and the channel model to protect users’ privacy. Fan et al. focused their attention on mobile network data sharing and privacy protection in the 5G era and proposed an efficient sharing scheme based on blockchain [21]. The main idea is to define a transaction format on blockchain to represent an access strategy. The strategy includes access requestor, content provider, visitor, and the beginning and ending time of access allowed, which is a role-based access control model. Zhang et al. proposed a blockchain-based data-sharing scheme for AI-powered network operations [22]. The scheme sets up two different types of chain, in which DataChain is used as access control tools for data, and BehaviorChain is used to store access records and ensure they cannot be tampered with. They divide access permissions into four levels. Zhou et al. proposed a blockchain-based file-sharing system [23] to address inefficient file sharing during the review of academic papers. The scheme uses Access Control Language (ALC) to exercise access control over the information stored on-chain. It needs to define an access policy on the blockchain for each pair of users and resource. Patel proposed a crossdomain image-sharing framework based on blockchain [24], which uses blockchain as data storage and allows patients to define an access policy. They pointed out that this approach can protect the data from unrelated parties, but no research has been conducted on privacy and security. Tan et al. have proposed a blockchain-based access control scheme for Cyber-Physical Social System (CPSS) big data [25], called BacCPSS. BacCPSS uses an address of blockchain as the user’s identity and maintains a user access matrix on the Smart Contract, ensuring that only operations authorized in the access matrix can be performed. The access control methods implemented in the above data-sharing schemes either need to maintain large numbers of access rules on the chain or cannot achieve fine-grained access control. Neither the access control matrix nor the RBAC is suitable for distributed environments like blockchain.ABE is considered the most appropriate technology to solve data security and privacy protection problems in a distributed environment. Therefore, recently, researchers have used ABE to achieve fine-grained access control over data on the blockchain. Jemel and Serhrouchni proposed a decentralized access control mechanism [26]. For the first time, researchers used blockchain nodes to execute a CP-ABE algorithm to verify user access rights’ legitimacy. The scheme designs two types of transactions: SetPolicy and GetAccess. But it does not use Smart Contracts, and it is obvious that the scheme is unable to achieve more complex requirements. Sun et al. constructed a model of secure storage and effective sharing for electronic medical data based on ABE and blockchain [27], which provides better access control. Doctors use ABE to encrypt patients’ medical data and store it on IPFS. However, it also does not use Smart Contracts. It only broadcasts some ABE parameters stored in transactions, which cannot achieve more complex business functions. Wang et al. proposed a sharing scheme [28] in which users distribute secret keys. It realizes that the data owner has a fine-grained access control on his data. At the same time, the Ethereum Smart Contract is used to realize the retrieval of ciphertext keywords. However, it requires multiple off-chain communication between users, and more importantly, it does not implement the permit revocation. Pournaghi et al. proposed a secure and efficient sharing scheme based on blockchain and ABE entitled MedSBA to record and store medical data [29]. It implements the update and revocation of permissions by broadcasting a new strategy to cover the previous transaction, but this will lead to users who do not want to be revoked to update their keys.


## 3. Preliminary

### 3.1. Bilinear Groups of Composite Order

Letn=p1p2 (p1 and p2 are distinct primes), G1 and G2 be cyclic groups of order n, and g be a generator of G1. We call e:G1×G1→G2 as a bilinear pairing, if it is a map with the following properties:
(1)
Bilinear:eg1a,g2b=eg1,g2ab for all g1,g2∈G1 and a,b∈Z(2)
Nondegenerate: there existsg1,g2∈G1, such that eg1,g2≠1(3)
Computable: There is an efficient algorithm to computeeg1,g2≠1 for all g1,g2∈G1LetGp1 and Gp2 denote the subgroups of G1 with order p1 and p2. Then, G1=Gp1×Gp2; gp2 and gp1 are the generators of Gp1 and Gp2. Let g1 and g2 denote the generators of Gp1 and Gp2. For all random elements h1∈Gp1 and h2∈Gp2, then we have eh1,h2=1; because of that, eh1,h2=eg1a,g2b=egap2,gbp1=eg,gabp1p2.


### 3.2. Linear Secret-Sharing Scheme (LSSS)

LetP=P1,⋯,Pn be a set of parties, and A,ρ denote an access structure in which A is an l×k access matrix with ρ mapping its rows. A linear secret-sharing scheme (LSSS) consists of two polynomial-time algorithms:
(1)
ShareA,ρ: to share a secret value s, it randomly chooses v1,v2,⋯,vk−1∈Z and let v=s,v1,⋯,vk−1T. Let Ai denote the vector as the ith row in matrix A, and then, the share σi=Aiv belongs to party ρi(2)
ReconA,ρ: the algorithm takes ω∈A as input; let L∈i∣ρi∈ω. Then, a set of recovery coefficients can be calculated effectively according to μii∈L, so that ∑i∈Lμiσi=s. Research has shown that the monotonic access structure is equivalent to the LSSS. Let A,ρ be an access structure and ω be a set of authorization; then ∃μii∈L makes that ∑i∈Lμiσi=s. For unauthorized sets, such constants do not exist


### 3.3. Ciphertext-Policy Attribute-Based Encryption (CP-ABE)

The CP-ABE mechanism was proposed by Bethencourt et al. [30]. It is a public key encryption scheme, but unlike RSA and ECC, CP-ABE is a one-to-many encryption scheme. In CP-ABE, the user’s attributes correspond to the private key, and the access policy is embedded in the ciphertext [31]. Only when the decryption user’s attributes satisfy the access policy can the data be decrypted. CP-ABE is mostly used for fine-grained access control. CP-ABE consists of four phases: initialization, key generation, encryption, and decryption, corresponding to the following four algorithms:
(1)
Setupλ,S→PSK,MSKInitialization algorithm is a randomization algorithm, which is generally executed on a trusted key distribution center. The algorithm inputs a secure parameterλ and the attributes are set S, to generate the system public key PSK and the system master key MSK.
(2)
KeyGenPSK,MSK,ω→USKKey generation algorithm generates a private keyUSK for the data user according to the system public key PSK, the system master key MSK, and the data user’s attributes ω.
(3)
EncryptPSK,M,A→CMEncryption algorithm is executed by the data owner. The algorithm inputs the system public keyPSK, the message M to be encrypted, and the access control structure A associated with the access policy and outputs the ciphertext CM.
(4)
DecryptPSK,CM,USK→MDecryption algorithm is executed by the data user. The inputs of the algorithm are the system public keyPSK, the user’s private key USK, and the ciphertext CM. If the data user’s attribute set ω satisfies the access policy, he will decrypt the ciphertext and obtain the corresponding plaintext M.


### 3.4. Blockchain

A blockchain concept originated from Nakamoto’s Bitcoin paper [10], and it is based on cryptography and P2P network. The data on the blockchain is organized into blocks, which are chained in a particular chronological order. Cryptography and consensus mechanisms ensure the security and nonforgery of data. In short, as the underlying technology of cryptocurrencies like Bitcoin, blockchain is a distributed trusted ledger that cannot be tampered with.


#### 3.4.1. Smart Contract

At the early stage of blockchain development, only cryptocurrencies like BTC and LTC were more successful applications. In 2013, Buterin introduced the concept of Smart Contract in his Ethereum white paper [32], demonstrating the first public blockchain with a built-in Turing complete language. Smart Contract [33] was defined as “a computerized transaction protocol that executes the terms of the contract.” In the blockchain, Smart Contract is a code that relies on blockchain’s trusted environment to automatically execute while enabling the blockchain to realize a more complex business. The smart contract operation mechanism based on blockchain is shown in Figure 1.Figure 1
The operation mechanism of smart contract on blockchain.From a higher point of view, blockchain can be considered a state machine triggered by transactions, and its public ledger is a world state starting from the Genesis Block. Users can build a transaction and broadcast it from any node in the blockchain network. All block producers will perform the corresponding operation after receiving the transaction. Because of the consensus mechanism, all nodes will eventually get a consistent result and update the world state. The action triggered by a transaction can be to deploy a new Smart Contract or to invoke a Smart Contract from blockchain and execute it in a sandbox environment. Blockchain provides Smart Contract with the following capabilities:Public state: everyone can see the Smart Contract’s execution and its current global status on the public ledger, which cannot be tampered with.Trusted propagation channel: after encrypting the message by the receiver’s public key, the sender can broadcast the message through the blockchain. The receiver will receive the message, and it will be recorded on the blockchain securely and undeniably.


#### 3.4.2. Transaction of EOS

In the EOS blockchain, there are three essential components named address, account, and transaction. Each user has his account in EOS, and each account corresponds to multiple ECDSA key pairs denoted bypk,sk. The public key calculates an address of EOS through a hash function and base58 coding. The private key and the public key are used to sign and verify the transaction, respectively. If a user wants to invoke a Smart Contract on-chain, he needs to prepare such a transaction Tx [34]:
(1)Tx=Refblock,t,SiguChain_ID,Tx,ActionCode,Name,Authu,Data.Refblock denotes the reference to the block number and header of a block which generated recently to prevent transactions from appearing on a forked chain. SiguChain_ID,Tx denotes the user’s signature information on the transaction which is used to verify the identity of the user who initiated the transaction by his public key. Action represents the operation to be performed, where Code is the name of the Smart Contract to be invoked, Name is a method in Smart Contract to be called, Authu is used to verify whether the user who initiated the transaction has the permission, and Data is the parameters to be passed into the contract.


#### 3.4.3. Data Persistence of EOS

After the Smart Contract is executed, the occupied memory will be released, and all variable data in the program will be lost, so it is necessary to persist the data in Smart Contract. In the Smart Contact of Ethereum, data can only be stored in key-value pairs, which is difficult to meet more complex requirements. In EOS, it imitates Multiindex Containers in Boost library and develops a C++ class:eosio::multi_index (hereinafter referred to as multi_index). Each multi_index can be regarded as a table in the traditional database. Each row of the table can store an object, and the object’s attributes can be any C++ data type. Therefore, the table constructed by multi_index in EOS is no less flexible than traditional databases. A significant feature of multi_index is that a primary key can be set as the main index and 16 secondary indices. Users can obtain any of these indices and use the emplace, erase, modify, and find functions of the index to insert, delete, update, and select data.


### 3.5. IPFS (InterPlanetary File System)

The InterPlanetary File System is a globally oriented, point-to-point distributed version of the File System, dedicated to creating persistent and distributed storage and shared file network transmission protocols. By integrating existing technologies such as BitTorrent, DHT, Git, and SFS (self-certifying File System), IPFS provides a high-throughput content block storage model that contains content addressing hyperlinks. Simultaneously, it does not have a single point of failure, and the nodes in the system do not need to trust each other. Any resource, such as text, images, sound, video, and website code, once added to the IPFS network, computes the content to a uniquely encrypted hash value unique to the address. This address can be understood as a URL (Uniform Resource Locator) on the Web. If the user wants to use the file, they just need to go to this address to get them.


## 3.1. Bilinear Groups of Composite Order

Letn=p1p2 (p1 and p2 are distinct primes), G1 and G2 be cyclic groups of order n, and g be a generator of G1. We call e:G1×G1→G2 as a bilinear pairing, if it is a map with the following properties:
(1)
Bilinear:eg1a,g2b=eg1,g2ab for all g1,g2∈G1 and a,b∈Z(2)
Nondegenerate: there existsg1,g2∈G1, such that eg1,g2≠1(3)
Computable: There is an efficient algorithm to computeeg1,g2≠1 for all g1,g2∈G1LetGp1 and Gp2 denote the subgroups of G1 with order p1 and p2. Then, G1=Gp1×Gp2; gp2 and gp1 are the generators of Gp1 and Gp2. Let g1 and g2 denote the generators of Gp1 and Gp2. For all random elements h1∈Gp1 and h2∈Gp2, then we have eh1,h2=1; because of that, eh1,h2=eg1a,g2b=egap2,gbp1=eg,gabp1p2.


## 3.2. Linear Secret-Sharing Scheme (LSSS)

LetP=P1,⋯,Pn be a set of parties, and A,ρ denote an access structure in which A is an l×k access matrix with ρ mapping its rows. A linear secret-sharing scheme (LSSS) consists of two polynomial-time algorithms:
(1)
ShareA,ρ: to share a secret value s, it randomly chooses v1,v2,⋯,vk−1∈Z and let v=s,v1,⋯,vk−1T. Let Ai denote the vector as the ith row in matrix A, and then, the share σi=Aiv belongs to party ρi(2)
ReconA,ρ: the algorithm takes ω∈A as input; let L∈i∣ρi∈ω. Then, a set of recovery coefficients can be calculated effectively according to μii∈L, so that ∑i∈Lμiσi=s. Research has shown that the monotonic access structure is equivalent to the LSSS. Let A,ρ be an access structure and ω be a set of authorization; then ∃μii∈L makes that ∑i∈Lμiσi=s. For unauthorized sets, such constants do not exist


## 3.3. Ciphertext-Policy Attribute-Based Encryption (CP-ABE)

The CP-ABE mechanism was proposed by Bethencourt et al. [30]. It is a public key encryption scheme, but unlike RSA and ECC, CP-ABE is a one-to-many encryption scheme. In CP-ABE, the user’s attributes correspond to the private key, and the access policy is embedded in the ciphertext [31]. Only when the decryption user’s attributes satisfy the access policy can the data be decrypted. CP-ABE is mostly used for fine-grained access control. CP-ABE consists of four phases: initialization, key generation, encryption, and decryption, corresponding to the following four algorithms:
(1)
Setupλ,S→PSK,MSKInitialization algorithm is a randomization algorithm, which is generally executed on a trusted key distribution center. The algorithm inputs a secure parameterλ and the attributes are set S, to generate the system public key PSK and the system master key MSK.
(2)
KeyGenPSK,MSK,ω→USKKey generation algorithm generates a private keyUSK for the data user according to the system public key PSK, the system master key MSK, and the data user’s attributes ω.
(3)
EncryptPSK,M,A→CMEncryption algorithm is executed by the data owner. The algorithm inputs the system public keyPSK, the message M to be encrypted, and the access control structure A associated with the access policy and outputs the ciphertext CM.
(4)
DecryptPSK,CM,USK→MDecryption algorithm is executed by the data user. The inputs of the algorithm are the system public keyPSK, the user’s private key USK, and the ciphertext CM. If the data user’s attribute set ω satisfies the access policy, he will decrypt the ciphertext and obtain the corresponding plaintext M.


## 3.4. Blockchain

A blockchain concept originated from Nakamoto’s Bitcoin paper [10], and it is based on cryptography and P2P network. The data on the blockchain is organized into blocks, which are chained in a particular chronological order. Cryptography and consensus mechanisms ensure the security and nonforgery of data. In short, as the underlying technology of cryptocurrencies like Bitcoin, blockchain is a distributed trusted ledger that cannot be tampered with.


### 3.4.1. Smart Contract

At the early stage of blockchain development, only cryptocurrencies like BTC and LTC were more successful applications. In 2013, Buterin introduced the concept of Smart Contract in his Ethereum white paper [32], demonstrating the first public blockchain with a built-in Turing complete language. Smart Contract [33] was defined as “a computerized transaction protocol that executes the terms of the contract.” In the blockchain, Smart Contract is a code that relies on blockchain’s trusted environment to automatically execute while enabling the blockchain to realize a more complex business. The smart contract operation mechanism based on blockchain is shown in Figure 1.Figure 1
The operation mechanism of smart contract on blockchain.From a higher point of view, blockchain can be considered a state machine triggered by transactions, and its public ledger is a world state starting from the Genesis Block. Users can build a transaction and broadcast it from any node in the blockchain network. All block producers will perform the corresponding operation after receiving the transaction. Because of the consensus mechanism, all nodes will eventually get a consistent result and update the world state. The action triggered by a transaction can be to deploy a new Smart Contract or to invoke a Smart Contract from blockchain and execute it in a sandbox environment. Blockchain provides Smart Contract with the following capabilities:Public state: everyone can see the Smart Contract’s execution and its current global status on the public ledger, which cannot be tampered with.Trusted propagation channel: after encrypting the message by the receiver’s public key, the sender can broadcast the message through the blockchain. The receiver will receive the message, and it will be recorded on the blockchain securely and undeniably.


### 3.4.2. Transaction of EOS

In the EOS blockchain, there are three essential components named address, account, and transaction. Each user has his account in EOS, and each account corresponds to multiple ECDSA key pairs denoted bypk,sk. The public key calculates an address of EOS through a hash function and base58 coding. The private key and the public key are used to sign and verify the transaction, respectively. If a user wants to invoke a Smart Contract on-chain, he needs to prepare such a transaction Tx [34]:
(1)Tx=Refblock,t,SiguChain_ID,Tx,ActionCode,Name,Authu,Data.Refblock denotes the reference to the block number and header of a block which generated recently to prevent transactions from appearing on a forked chain. SiguChain_ID,Tx denotes the user’s signature information on the transaction which is used to verify the identity of the user who initiated the transaction by his public key. Action represents the operation to be performed, where Code is the name of the Smart Contract to be invoked, Name is a method in Smart Contract to be called, Authu is used to verify whether the user who initiated the transaction has the permission, and Data is the parameters to be passed into the contract.


### 3.4.3. Data Persistence of EOS

After the Smart Contract is executed, the occupied memory will be released, and all variable data in the program will be lost, so it is necessary to persist the data in Smart Contract. In the Smart Contact of Ethereum, data can only be stored in key-value pairs, which is difficult to meet more complex requirements. In EOS, it imitates Multiindex Containers in Boost library and develops a C++ class:eosio::multi_index (hereinafter referred to as multi_index). Each multi_index can be regarded as a table in the traditional database. Each row of the table can store an object, and the object’s attributes can be any C++ data type. Therefore, the table constructed by multi_index in EOS is no less flexible than traditional databases. A significant feature of multi_index is that a primary key can be set as the main index and 16 secondary indices. Users can obtain any of these indices and use the emplace, erase, modify, and find functions of the index to insert, delete, update, and select data.


## 3.4.1. Smart Contract

At the early stage of blockchain development, only cryptocurrencies like BTC and LTC were more successful applications. In 2013, Buterin introduced the concept of Smart Contract in his Ethereum white paper [32], demonstrating the first public blockchain with a built-in Turing complete language. Smart Contract [33] was defined as “a computerized transaction protocol that executes the terms of the contract.” In the blockchain, Smart Contract is a code that relies on blockchain’s trusted environment to automatically execute while enabling the blockchain to realize a more complex business. The smart contract operation mechanism based on blockchain is shown in Figure 1.Figure 1
The operation mechanism of smart contract on blockchain.From a higher point of view, blockchain can be considered a state machine triggered by transactions, and its public ledger is a world state starting from the Genesis Block. Users can build a transaction and broadcast it from any node in the blockchain network. All block producers will perform the corresponding operation after receiving the transaction. Because of the consensus mechanism, all nodes will eventually get a consistent result and update the world state. The action triggered by a transaction can be to deploy a new Smart Contract or to invoke a Smart Contract from blockchain and execute it in a sandbox environment. Blockchain provides Smart Contract with the following capabilities:Public state: everyone can see the Smart Contract’s execution and its current global status on the public ledger, which cannot be tampered with.Trusted propagation channel: after encrypting the message by the receiver’s public key, the sender can broadcast the message through the blockchain. The receiver will receive the message, and it will be recorded on the blockchain securely and undeniably.


## 3.4.2. Transaction of EOS

In the EOS blockchain, there are three essential components named address, account, and transaction. Each user has his account in EOS, and each account corresponds to multiple ECDSA key pairs denoted bypk,sk. The public key calculates an address of EOS through a hash function and base58 coding. The private key and the public key are used to sign and verify the transaction, respectively. If a user wants to invoke a Smart Contract on-chain, he needs to prepare such a transaction Tx [34]:
(1)Tx=Refblock,t,SiguChain_ID,Tx,ActionCode,Name,Authu,Data.Refblock denotes the reference to the block number and header of a block which generated recently to prevent transactions from appearing on a forked chain. SiguChain_ID,Tx denotes the user’s signature information on the transaction which is used to verify the identity of the user who initiated the transaction by his public key. Action represents the operation to be performed, where Code is the name of the Smart Contract to be invoked, Name is a method in Smart Contract to be called, Authu is used to verify whether the user who initiated the transaction has the permission, and Data is the parameters to be passed into the contract.


## 3.4.3. Data Persistence of EOS

After the Smart Contract is executed, the occupied memory will be released, and all variable data in the program will be lost, so it is necessary to persist the data in Smart Contract. In the Smart Contact of Ethereum, data can only be stored in key-value pairs, which is difficult to meet more complex requirements. In EOS, it imitates Multiindex Containers in Boost library and develops a C++ class:eosio::multi_index (hereinafter referred to as multi_index). Each multi_index can be regarded as a table in the traditional database. Each row of the table can store an object, and the object’s attributes can be any C++ data type. Therefore, the table constructed by multi_index in EOS is no less flexible than traditional databases. A significant feature of multi_index is that a primary key can be set as the main index and 16 secondary indices. Users can obtain any of these indices and use the emplace, erase, modify, and find functions of the index to insert, delete, update, and select data.


## 3.5. IPFS (InterPlanetary File System)

The InterPlanetary File System is a globally oriented, point-to-point distributed version of the File System, dedicated to creating persistent and distributed storage and shared file network transmission protocols. By integrating existing technologies such as BitTorrent, DHT, Git, and SFS (self-certifying File System), IPFS provides a high-throughput content block storage model that contains content addressing hyperlinks. Simultaneously, it does not have a single point of failure, and the nodes in the system do not need to trust each other. Any resource, such as text, images, sound, video, and website code, once added to the IPFS network, computes the content to a uniquely encrypted hash value unique to the address. This address can be understood as a URL (Uniform Resource Locator) on the Web. If the user wants to use the file, they just need to go to this address to get them.


## 4. Overview of Our Scheme

This section will give an overview of the system model and the design of our proposed scheme. Table1 shows some symbols and abbreviations involved in this paper.Table 1
The symbols and abbreviations involved in this paper.
No.SymbolDescription1DOThe data owner2DUThe data user3MSKSystem master key4PKSystem public parameters5SAll general attributes set6ωThe attributes set of a specificDU7PAccess policy8uidA user ID which is unique9SKuid,ωThe attribute private key ofDU whose ID is uid10SKsearchThe secret key ofDU for search11E=E.Enc,E.DecAn asymmetric encryption algorithm like ECC12Skcom,PkcomA pair of keys for algorithmE13ε=ε.Enc,ε.DecA symmetric encryption algorithm like AES14FData that theDO intends to share15CFCiphertext of the dataF16hreflocationThe address where the data is stored on IPFS17kwKeyword18tkwSearch token ofkw


### 4.1. System Model of BSSPD

Our proposed scheme BSPPD consists of four components: IPFS, blockchain, data owner, and data user. TheDO encrypts his data and uploads it to IPFS, then invokes the Smart Contract on blockchain to save the returned address along with the decryption key. CP-ABE is used to realize a fine-grained access control of data. The DO distributes the private keys for DUs through blockchain, and only those who satisfy the access policy can download and decrypt the shared data. The whole process is entirely decentralized. The data is encrypted and stored in the IPFS to ensure the security of data and accessibility. The traces of the DO and DUs are stored on the blockchain, which cannot be tampered with or denied. The specific functions and responsibilities of these four parts are as follows:
(1)
IPFS: provide a secure and reliable storage service. The incentive mechanism ensures that the data on IPFS will never be unavailable(2)
Blockchain: stores the public information and operational records in the whole scheme. Meanwhile, it can be used as a reliable broadcast channel for transferring messages from theDO to DU. Without any trusted third party, it is the cornerstone of trust for the scheme. There are two Smart Contracts in BSSPD. UMContract is used to manage data users and DSContract is used to share data(3)
Data owner: responsible for creating and deploying the Smart Contract in the scheme. TheDO can publish his sharing data and set an access policy for it. Meanwhile, the DO can grant and revoke a DU’s access rights(4)
Data user: theDU is the person who wants to access the shared data. When DU’s attributes meet the policy embedded in the ciphertext, he will decrypt the address and key to obtain the shared dataThe system model of the proposed scheme is shown in Figure2.Figure 2
The system model of BSSPD.The CP-ABE algorithm we adopted was mainly inspired by [35] and extended to use the user’s ID as an attribute to support permission revocation. The keyword ciphertext search in BSSPD was learned from [36]. The corresponding description of each step number in Figure 2 is shown as follows:
(i)
TheDO creates and deploys Smart Contracts. There are two Smart Contracts in our scheme. UMContract includes the functions of user registration, attribute management, identity management, and authentication. DSContract includes publishing sharing data, updating access policy, permission revocation, and data retrieval(ii)
TheDO generates the system master key and system public key locally and stores the system public key in DSContract(iii)
TheDU invokes UMContract to apply for registration, and he needs to provide his account of EOS and a public key. The public key is used to communicate with the DO, and the DO uses it to encrypt the message and broadcasts the ciphertext to the blockchain. Only the corresponding DU can decrypt the ciphertext and obtain the message(iv)
TheDO assigns a unique uid to each DU who applies for, and generates a private attribute key and a secret search key for the DU. After encrypting these two keys with the DU’s communication public key, the DO will save them in the Smart Contract together with the uid(v)
TheDU obtains the ciphertext information of the keys and decrypts them with his private communication key(vi)
TheDO randomly selects a key of the symmetric encryption algorithm, uses it to encrypt the sharing data, then uploads the ciphertext to the IPFS network, and IPFS returns an address(vii)
TheDO sets an access policy for sharing data and sets a revocation list for each attribute in the policy, then encrypts the address along with the decryption key of shared data. The DUs in the revocation list do not have corresponding attributes when accessing the data(viii)
TheDO selects keywords to generate ciphertext indices for data-related DUs and then invokes the DSContract to store the indices and data-related information(ix)
TheDU selects a keyword of the data to be retrieved and uses the trapdoor function to generate a search token(x)
TheDU invokes DSContract to start searching for the desired data. DSContract will call UMContract to authenticate the DU and check whether the DU is legal(xi)
UMContract returns the authentication result to DSContract. If the DU is legal, the search function will continue to be executed(xii)
TheDU obtains the search results from DSContract(xiii)
TheDU uses his attribute private key to decrypt the acquired data-related information. If the DU’s unrevoked attributes still satisfy the access policy, he will get the address where the ciphertext data is stored on IPFS and the corresponding decryption key. The DU can download the ciphertext of the shared data from IPFS and decrypt it(xiv)
If theDO wants to revoke a DU’s attribute A to a certain shared data, he can add this DU’s uid to the revocation list of attribute A. Then, the DO will generate a new ciphertext and invoke DSContract to update the data-related information


### 4.2. Detail Design of BSSPD

The scheme we proposed is mainly composed of the following phases: initialization phase, apply and register phase, encryption and uploading phase, search phase, decryption and downloading phase, and permission revocation phase. This section will describe the detailed design of each phase and the corresponding relationship with the process steps in the previous section.


#### 4.2.1. Initialization Phase

The primary function of the initialization phase is that theDO deploys Smart Contracts, then generates the system master key and the public parameters in the scheme, and stores them in the Smart Contract. The core algorithm of this phase is Setup1λ→MSK,PK, which was executed by the DO. The algorithm’s input is a security parameter 1λ, and the outputs are the system master key MSK and public system parameters PK. MSK will be kept secret by the DO, and PK will be stored in UMContract by the DO initiating a transaction. The corresponding steps in the system flowchart are (i) and (ii).


#### 4.2.2. Apply and Register Phase

The apply and register phase’s primary function is that theDU invokes to apply for registration, and an asymmetric encryption algorithm public key is required when applying. After that, the DO assigns a unique uid and distributes private keys for the DU. The core algorithm is KeyGenMSK,PK,uid,ω→SKdata,SKsearch which is run by the DO. The inputs of the algorithm are the system master key MSK, the public parameters PK, the uid of the DU, and the general attribute set ω of the DU. It outputs the private attribute key SKdata and the search key SKsearch of the DU. The DO executes SKuid,ω=EncPkcomSKdata∣SKsearch and invokes UMContract to store SKuid,ω in the Smart Contract. In this way, the DU can obtain his private keys securely and reliably. The corresponding steps in the system flowchart are (iii)–(v).


#### 4.2.3. Encryption and Uploading Phase

The encryption and uploading phase’s main function is that theDO encrypts sharing data and uploads it to IPFS. After that, the address and decryption key are encrypted and uploaded to DSContract, and the ciphertext keyword indices are established for the relevant DUs. The core algorithm is EncryptF,Al×k,ρ,Rρxx∈1,⋯,l,PK and executed by the DO. It consists of the following three substeps:Step 1.
EncryptFileF→KF,hreflocation.The input of the data encryption algorithm is the sharing dataF, and outputs are the key KF of a symmetric encryption algorithm and an IPFS address hreflocation. The whole process is to randomly select a private key KF and encrypt F to get the ciphertext CF and then upload CF to IPFS to get the address hreflocation. The corresponding step in the system flowchart is (vi).Step 2.
EncryptKeyKF,hreflocation,P,Rii∈P,PKKF∣hreflocation.The algorithm is used to encrypt the address, and the key whose inputs are the decryption keyKF, the IPFS address hreflocation, the access policy P, a revocation list Ri for each attribute in P, and system public parameters PK. Its output is the ciphertext of KF and encrypted with CP-ABE. The corresponding step in the system flowchart is (vii).Step 3.
IndexGenkw,Ksearch→tkw.In the algorithm that generates the ciphertext keyword index, theDO selects a keyword kw of data F, which is used as inputs together with the search secret key Ksearch of a relevant DU. The output is a search token tkw and the corresponding step in the system flowchart is (viii).


#### 4.2.4. Search Phase

The main function of the search phase is that aDU uses the trapdoor function to generate the corresponding search token according to the keyword of the shared data which he wants. After that, the DU invokes the contract DSContract for retrieval. This phase can be divided into two steps, as follows:Step 1.
Trpdrkw′,SKsearch→t′kw.Generate search token algorithm, which is executed by theDU. The DU selects the keyword related to the shared data he wants to search, together with his SKsearch as inputs, and the output is the search token t′kw corresponding to the keyword. This corresponds to step (ix) in the system flowchart.Step 2.
Searcht′kw→CTKF∣hreflocation.The search algorithm is executed byDSContract, which uses the search token t′kw generated by the DU in the previous step as input. If such data exists, the algorithm returns data-related information successfully. In this algorithm, the DU sends a transaction to DSContract to trigger the execution, corresponding to steps (x)–(xii).


#### 4.2.5. Decryption and Downloading Phase

The main function of the decryption and downloading phase is thatDUs use their attribute private keys to decrypt the data-related information to obtain the address where the shared data stored on IPFS and the decryption key. The core algorithm is DecryptSKuid,ω,CTKF∣hreflocation,PK→KF,hreflocation which was executed by the DU. The inputs of the algorithm are the private attribute key SKuid,ω of the DU, the data-related information CTKF∣hreflocation, and the public system parameters PK. It outputs the decryption key KF and the address hreflocation. Because the access policy P and the revocation list Ri of each attribute are embedded in the ciphertext, if the attribute set of the DU that have not been revoked still satisfies access policy P, he will decrypt and obtain KF and hreflocation successfully. In this way, the DU could download CTF from IPFS and decrypt it to obtain the data F. This corresponds to step (xiii) in the system flowchart.


#### 4.2.6. Permission Revocation Phase

The main function of the permission revocation phase is that theDO performs an attribute-level fine-grained permission revocation to a DU on a certain ciphertext. At the same time, it does not need to update the keys of other DUs related to the ciphertext. The core algorithm of this phase is RevokeKF,hreflocation,P,Rii∈P,PK,i,uid→CT′KF∣hreflocation which is run by the DO. This is similar to the encryption algorithm, but a DU’s uid and the attribute i to be revoked are added to the parameters. The algorithm will add uid to the revocation list Ri and output a new ciphertext. The DO sends a transaction to DSContract to update the data-related information. In this way, if the remaining attribute set of the DU cannot satisfy the policy P, he can no longer decrypt the data after obtaining the ciphertext, while other DUs are not affected. This corresponds to step (xiv) in the system flowchart.


## 4.1. System Model of BSSPD

Our proposed scheme BSPPD consists of four components: IPFS, blockchain, data owner, and data user. TheDO encrypts his data and uploads it to IPFS, then invokes the Smart Contract on blockchain to save the returned address along with the decryption key. CP-ABE is used to realize a fine-grained access control of data. The DO distributes the private keys for DUs through blockchain, and only those who satisfy the access policy can download and decrypt the shared data. The whole process is entirely decentralized. The data is encrypted and stored in the IPFS to ensure the security of data and accessibility. The traces of the DO and DUs are stored on the blockchain, which cannot be tampered with or denied. The specific functions and responsibilities of these four parts are as follows:
(1)
IPFS: provide a secure and reliable storage service. The incentive mechanism ensures that the data on IPFS will never be unavailable(2)
Blockchain: stores the public information and operational records in the whole scheme. Meanwhile, it can be used as a reliable broadcast channel for transferring messages from theDO to DU. Without any trusted third party, it is the cornerstone of trust for the scheme. There are two Smart Contracts in BSSPD. UMContract is used to manage data users and DSContract is used to share data(3)
Data owner: responsible for creating and deploying the Smart Contract in the scheme. TheDO can publish his sharing data and set an access policy for it. Meanwhile, the DO can grant and revoke a DU’s access rights(4)
Data user: theDU is the person who wants to access the shared data. When DU’s attributes meet the policy embedded in the ciphertext, he will decrypt the address and key to obtain the shared dataThe system model of the proposed scheme is shown in Figure2.Figure 2
The system model of BSSPD.The CP-ABE algorithm we adopted was mainly inspired by [35] and extended to use the user’s ID as an attribute to support permission revocation. The keyword ciphertext search in BSSPD was learned from [36]. The corresponding description of each step number in Figure 2 is shown as follows:
(i)
TheDO creates and deploys Smart Contracts. There are two Smart Contracts in our scheme. UMContract includes the functions of user registration, attribute management, identity management, and authentication. DSContract includes publishing sharing data, updating access policy, permission revocation, and data retrieval(ii)
TheDO generates the system master key and system public key locally and stores the system public key in DSContract(iii)
TheDU invokes UMContract to apply for registration, and he needs to provide his account of EOS and a public key. The public key is used to communicate with the DO, and the DO uses it to encrypt the message and broadcasts the ciphertext to the blockchain. Only the corresponding DU can decrypt the ciphertext and obtain the message(iv)
TheDO assigns a unique uid to each DU who applies for, and generates a private attribute key and a secret search key for the DU. After encrypting these two keys with the DU’s communication public key, the DO will save them in the Smart Contract together with the uid(v)
TheDU obtains the ciphertext information of the keys and decrypts them with his private communication key(vi)
TheDO randomly selects a key of the symmetric encryption algorithm, uses it to encrypt the sharing data, then uploads the ciphertext to the IPFS network, and IPFS returns an address(vii)
TheDO sets an access policy for sharing data and sets a revocation list for each attribute in the policy, then encrypts the address along with the decryption key of shared data. The DUs in the revocation list do not have corresponding attributes when accessing the data(viii)
TheDO selects keywords to generate ciphertext indices for data-related DUs and then invokes the DSContract to store the indices and data-related information(ix)
TheDU selects a keyword of the data to be retrieved and uses the trapdoor function to generate a search token(x)
TheDU invokes DSContract to start searching for the desired data. DSContract will call UMContract to authenticate the DU and check whether the DU is legal(xi)
UMContract returns the authentication result to DSContract. If the DU is legal, the search function will continue to be executed(xii)
TheDU obtains the search results from DSContract(xiii)
TheDU uses his attribute private key to decrypt the acquired data-related information. If the DU’s unrevoked attributes still satisfy the access policy, he will get the address where the ciphertext data is stored on IPFS and the corresponding decryption key. The DU can download the ciphertext of the shared data from IPFS and decrypt it(xiv)
If theDO wants to revoke a DU’s attribute A to a certain shared data, he can add this DU’s uid to the revocation list of attribute A. Then, the DO will generate a new ciphertext and invoke DSContract to update the data-related information


## 4.2. Detail Design of BSSPD

The scheme we proposed is mainly composed of the following phases: initialization phase, apply and register phase, encryption and uploading phase, search phase, decryption and downloading phase, and permission revocation phase. This section will describe the detailed design of each phase and the corresponding relationship with the process steps in the previous section.


### 4.2.1. Initialization Phase

The primary function of the initialization phase is that theDO deploys Smart Contracts, then generates the system master key and the public parameters in the scheme, and stores them in the Smart Contract. The core algorithm of this phase is Setup1λ→MSK,PK, which was executed by the DO. The algorithm’s input is a security parameter 1λ, and the outputs are the system master key MSK and public system parameters PK. MSK will be kept secret by the DO, and PK will be stored in UMContract by the DO initiating a transaction. The corresponding steps in the system flowchart are (i) and (ii).


### 4.2.2. Apply and Register Phase

The apply and register phase’s primary function is that theDU invokes to apply for registration, and an asymmetric encryption algorithm public key is required when applying. After that, the DO assigns a unique uid and distributes private keys for the DU. The core algorithm is KeyGenMSK,PK,uid,ω→SKdata,SKsearch which is run by the DO. The inputs of the algorithm are the system master key MSK, the public parameters PK, the uid of the DU, and the general attribute set ω of the DU. It outputs the private attribute key SKdata and the search key SKsearch of the DU. The DO executes SKuid,ω=EncPkcomSKdata∣SKsearch and invokes UMContract to store SKuid,ω in the Smart Contract. In this way, the DU can obtain his private keys securely and reliably. The corresponding steps in the system flowchart are (iii)–(v).


### 4.2.3. Encryption and Uploading Phase

The encryption and uploading phase’s main function is that theDO encrypts sharing data and uploads it to IPFS. After that, the address and decryption key are encrypted and uploaded to DSContract, and the ciphertext keyword indices are established for the relevant DUs. The core algorithm is EncryptF,Al×k,ρ,Rρxx∈1,⋯,l,PK and executed by the DO. It consists of the following three substeps:Step 1.
EncryptFileF→KF,hreflocation.The input of the data encryption algorithm is the sharing dataF, and outputs are the key KF of a symmetric encryption algorithm and an IPFS address hreflocation. The whole process is to randomly select a private key KF and encrypt F to get the ciphertext CF and then upload CF to IPFS to get the address hreflocation. The corresponding step in the system flowchart is (vi).Step 2.
EncryptKeyKF,hreflocation,P,Rii∈P,PKKF∣hreflocation.The algorithm is used to encrypt the address, and the key whose inputs are the decryption keyKF, the IPFS address hreflocation, the access policy P, a revocation list Ri for each attribute in P, and system public parameters PK. Its output is the ciphertext of KF and encrypted with CP-ABE. The corresponding step in the system flowchart is (vii).Step 3.
IndexGenkw,Ksearch→tkw.In the algorithm that generates the ciphertext keyword index, theDO selects a keyword kw of data F, which is used as inputs together with the search secret key Ksearch of a relevant DU. The output is a search token tkw and the corresponding step in the system flowchart is (viii).


### 4.2.4. Search Phase

The main function of the search phase is that aDU uses the trapdoor function to generate the corresponding search token according to the keyword of the shared data which he wants. After that, the DU invokes the contract DSContract for retrieval. This phase can be divided into two steps, as follows:Step 1.
Trpdrkw′,SKsearch→t′kw.Generate search token algorithm, which is executed by theDU. The DU selects the keyword related to the shared data he wants to search, together with his SKsearch as inputs, and the output is the search token t′kw corresponding to the keyword. This corresponds to step (ix) in the system flowchart.Step 2.
Searcht′kw→CTKF∣hreflocation.The search algorithm is executed byDSContract, which uses the search token t′kw generated by the DU in the previous step as input. If such data exists, the algorithm returns data-related information successfully. In this algorithm, the DU sends a transaction to DSContract to trigger the execution, corresponding to steps (x)–(xii).


### 4.2.5. Decryption and Downloading Phase

The main function of the decryption and downloading phase is thatDUs use their attribute private keys to decrypt the data-related information to obtain the address where the shared data stored on IPFS and the decryption key. The core algorithm is DecryptSKuid,ω,CTKF∣hreflocation,PK→KF,hreflocation which was executed by the DU. The inputs of the algorithm are the private attribute key SKuid,ω of the DU, the data-related information CTKF∣hreflocation, and the public system parameters PK. It outputs the decryption key KF and the address hreflocation. Because the access policy P and the revocation list Ri of each attribute are embedded in the ciphertext, if the attribute set of the DU that have not been revoked still satisfies access policy P, he will decrypt and obtain KF and hreflocation successfully. In this way, the DU could download CTF from IPFS and decrypt it to obtain the data F. This corresponds to step (xiii) in the system flowchart.


### 4.2.6. Permission Revocation Phase

The main function of the permission revocation phase is that theDO performs an attribute-level fine-grained permission revocation to a DU on a certain ciphertext. At the same time, it does not need to update the keys of other DUs related to the ciphertext. The core algorithm of this phase is RevokeKF,hreflocation,P,Rii∈P,PK,i,uid→CT′KF∣hreflocation which is run by the DO. This is similar to the encryption algorithm, but a DU’s uid and the attribute i to be revoked are added to the parameters. The algorithm will add uid to the revocation list Ri and output a new ciphertext. The DO sends a transaction to DSContract to update the data-related information. In this way, if the remaining attribute set of the DU cannot satisfy the policy P, he can no longer decrypt the data after obtaining the ciphertext, while other DUs are not affected. This corresponds to step (xiv) in the system flowchart.


## 4.2.1. Initialization Phase

The primary function of the initialization phase is that theDO deploys Smart Contracts, then generates the system master key and the public parameters in the scheme, and stores them in the Smart Contract. The core algorithm of this phase is Setup1λ→MSK,PK, which was executed by the DO. The algorithm’s input is a security parameter 1λ, and the outputs are the system master key MSK and public system parameters PK. MSK will be kept secret by the DO, and PK will be stored in UMContract by the DO initiating a transaction. The corresponding steps in the system flowchart are (i) and (ii).


## 4.2.2. Apply and Register Phase

The apply and register phase’s primary function is that theDU invokes to apply for registration, and an asymmetric encryption algorithm public key is required when applying. After that, the DO assigns a unique uid and distributes private keys for the DU. The core algorithm is KeyGenMSK,PK,uid,ω→SKdata,SKsearch which is run by the DO. The inputs of the algorithm are the system master key MSK, the public parameters PK, the uid of the DU, and the general attribute set ω of the DU. It outputs the private attribute key SKdata and the search key SKsearch of the DU. The DO executes SKuid,ω=EncPkcomSKdata∣SKsearch and invokes UMContract to store SKuid,ω in the Smart Contract. In this way, the DU can obtain his private keys securely and reliably. The corresponding steps in the system flowchart are (iii)–(v).


## 4.2.3. Encryption and Uploading Phase

The encryption and uploading phase’s main function is that theDO encrypts sharing data and uploads it to IPFS. After that, the address and decryption key are encrypted and uploaded to DSContract, and the ciphertext keyword indices are established for the relevant DUs. The core algorithm is EncryptF,Al×k,ρ,Rρxx∈1,⋯,l,PK and executed by the DO. It consists of the following three substeps:Step 1.
EncryptFileF→KF,hreflocation.The input of the data encryption algorithm is the sharing dataF, and outputs are the key KF of a symmetric encryption algorithm and an IPFS address hreflocation. The whole process is to randomly select a private key KF and encrypt F to get the ciphertext CF and then upload CF to IPFS to get the address hreflocation. The corresponding step in the system flowchart is (vi).Step 2.
EncryptKeyKF,hreflocation,P,Rii∈P,PKKF∣hreflocation.The algorithm is used to encrypt the address, and the key whose inputs are the decryption keyKF, the IPFS address hreflocation, the access policy P, a revocation list Ri for each attribute in P, and system public parameters PK. Its output is the ciphertext of KF and encrypted with CP-ABE. The corresponding step in the system flowchart is (vii).Step 3.
IndexGenkw,Ksearch→tkw.In the algorithm that generates the ciphertext keyword index, theDO selects a keyword kw of data F, which is used as inputs together with the search secret key Ksearch of a relevant DU. The output is a search token tkw and the corresponding step in the system flowchart is (viii).


## 4.2.4. Search Phase

The main function of the search phase is that aDU uses the trapdoor function to generate the corresponding search token according to the keyword of the shared data which he wants. After that, the DU invokes the contract DSContract for retrieval. This phase can be divided into two steps, as follows:Step 1.
Trpdrkw′,SKsearch→t′kw.Generate search token algorithm, which is executed by theDU. The DU selects the keyword related to the shared data he wants to search, together with his SKsearch as inputs, and the output is the search token t′kw corresponding to the keyword. This corresponds to step (ix) in the system flowchart.Step 2.
Searcht′kw→CTKF∣hreflocation.The search algorithm is executed byDSContract, which uses the search token t′kw generated by the DU in the previous step as input. If such data exists, the algorithm returns data-related information successfully. In this algorithm, the DU sends a transaction to DSContract to trigger the execution, corresponding to steps (x)–(xii).


## 4.2.5. Decryption and Downloading Phase

The main function of the decryption and downloading phase is thatDUs use their attribute private keys to decrypt the data-related information to obtain the address where the shared data stored on IPFS and the decryption key. The core algorithm is DecryptSKuid,ω,CTKF∣hreflocation,PK→KF,hreflocation which was executed by the DU. The inputs of the algorithm are the private attribute key SKuid,ω of the DU, the data-related information CTKF∣hreflocation, and the public system parameters PK. It outputs the decryption key KF and the address hreflocation. Because the access policy P and the revocation list Ri of each attribute are embedded in the ciphertext, if the attribute set of the DU that have not been revoked still satisfies access policy P, he will decrypt and obtain KF and hreflocation successfully. In this way, the DU could download CTF from IPFS and decrypt it to obtain the data F. This corresponds to step (xiii) in the system flowchart.


## 4.2.6. Permission Revocation Phase

The main function of the permission revocation phase is that theDO performs an attribute-level fine-grained permission revocation to a DU on a certain ciphertext. At the same time, it does not need to update the keys of other DUs related to the ciphertext. The core algorithm of this phase is RevokeKF,hreflocation,P,Rii∈P,PK,i,uid→CT′KF∣hreflocation which is run by the DO. This is similar to the encryption algorithm, but a DU’s uid and the attribute i to be revoked are added to the parameters. The algorithm will add uid to the revocation list Ri and output a new ciphertext. The DO sends a transaction to DSContract to update the data-related information. In this way, if the remaining attribute set of the DU cannot satisfy the policy P, he can no longer decrypt the data after obtaining the ciphertext, while other DUs are not affected. This corresponds to step (xiv) in the system flowchart.


## 5. Implementation Details of Our Scheme

In order to achieve our goal, we will construct a CP-ABE which supports permission revocation and combine it with the EOS blockchain to implement our scheme. This section will elaborate on the details of our Smart Contracts deployed on EOS blockchain and concrete construction of BSSPD.


### 5.1. Smart Contract Design

To make the logic clearer, we divide the Smart Contract in the scheme into two parts:UMContract and DSContract. UMContract is used to manage DUs’ identity, while DSContract is used to handle business operations related to data sharing. In the contract, we will use _self to represent the account of the DO who created the contract. We will describe the detailed design of these two contracts.


#### 5.1.1. User Management Contract (UMContract)

Algorithm 1: SetTarget.
Input: newTargetOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4target = newTarget;5return true;6endAlgorithm 2: GetUserByUid.
Input: uidOutput: all information of DU1ifmsg.sender is not _selfthen2 throw;3else4user_row = uid_idx.find(uid);5returnuser_row;6endAlgorithm 3: Apply.
Input: from, pk, nonceOutput: bool1u = account_idx.find(from)2ifu != nullthen3u.Pkcom=pk;account_idx.modify(u);4return true;5else6pow=SHA256SHA256from∣pk∣nonce;7ifpow > targetthen8return false;9else10u.A = from;11u.Pkcom=pk;12account_idx.emplace(u);13return true;14end15endTheUMContract is composed of five function interfaces: SetTarget, GetUserByUid, Apply, Register, and Authenticate. We initialize UMContract as follows.Let three-tupleA,uid,Pkcom denote a DU, and create a multi_index named table_user for it in which A is an EOS account of the DU, uid is the unique ID assigned by the DO, and Pkcom is a public key of the DU used for communication with the DO. Let A be the primary key of table_user whose corresponding index is account_idx. Let uid_idx be a secondary index corresponding to uid. Let target be the target value of PoW.
(1)
SetTarget: when UMContract receives action (UMContract, SetTarget, Auth, (newTarget)), this function interface will be triggered to execute. It can only be invoked by the DO who created the contract to adjust the difficulty of PoW. When there are too many users in the system, the DO can increase the difficulty of PoW(2)
GetUserUid: when UMContract receives action (UMContract, GetUserByUid, Auth, (account)), this function interface will be triggered to execute. It is used to get all the information of a DU according to his uid and can only be invoked by the DO who created the contract(3)
Apply: when UMContract receives action (UMContract, Apply, Auth, (from, pk, nonce)), this function interface will be triggered to execute. It is invoked by the DU to apply for registration in the system(4)
Register: when UMContract receives action (UMContract, Register, Auth, (account, id)), this function interface will be triggered to execute. It is used to complete the registration of a DU and can only be invoked by the creator of the contract(5)
Authenticate: when UMContract receives action (UMContract, Authenticate, Auth, (from, method, account, id, args)), this function interface will be triggered to execute. It is used to authenticate the identity of a DU, which is invoked by another contract and returns the result to the invokerAlgorithm 4: Register.
Input: account, idOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4u = account_idx.find(account);5ifu==nullthen6return false;7else8u.uid=id;10account_idx.modify(u);11return true;12end13endAlgorithm 5: Authenticate.
Input: from, method, account, id, argsOutput: nullu=account_idx.find(account)1ifu != null then2ifu.id == id then3  send action (from, method, (_self, true, args));4else5  send action (from, method, (_self, false, args));6end7else8 send action (from, method, (_self, false, args));9end


#### 5.1.2. Date Sharing Contract (DSContract)

TheDSContract is composed of six function interfaces: SetPK. SetSK, AddData, PolicyUpdate, Search and EndSearch, and Remove. We initialize DSContract as follows.LetPK denote the system public parameters. Let two-tuple (A, SK) be the corresponding relationship between the DU’s account and his attribute private key, and the multi_index table_sk is created for it. Let A be the primary key of table_sk whose corresponding index is ua_idx. Let two-tuple (fid, cf) denote the shared data in which fid is the id of shared data and cf is the data-related information. Then, create a multi_index data_table for it, where fid is the primary key and fid_idx is the corresponding index. Let four-tuple (id, A, t, fid) be an index of DU related to shared data in which A is the EOS account of DU, t is the search token, and fid is the id of shared data in data_table, then create a multi_index search_table for it. Let sa_idx, t_idx, sf_idx be the secondary indices of search_table, corresponding to A, t, and fid, respectively.
(1)
SetPK: when DSContract receives action (DSContract, SetPK, Auth, (newPk)), this function interface will be triggered to execute. It can only be invoked by the DO to set and update the system public parameters(2)
SetSK: when DSContract receives action (DSContract, SetSK, Auth, (account, sk)), this function interface will be triggered to execute. It can only be invoked by the DO to set and update the private keys of the DU(3)
AddData: when DSContract receives action (DSContract, AddData, Auth, (account, tkw, CTKF∣hreflocation)), this function interface will be triggered to execute. It is used to publish the sharing data and add the indices for the relevant DUs. There can be multiple index relationships. For clarity, we only add an index for one DU here. It can only be invoked by the DO(4)
PolicyUpdate: when DSContract receives action (DSContract, PolicyUpdate, Auth, (fid, CTKF∣hreflocation)), this function interface will be triggered to execute. It can only be invoked by the DO and used to update the access policy for a certain shared data. In this way, the DO can revoke the access permission of a DU to this shared data(5)
Search and EndSearch: when DSContract receives action (DSContract, Search, Auth, (from, uid, tkw)), this function interface will be triggered to execute. These two function interfaces work together to complete the retrieval of shared data. Because we have divided BSSPD into two contracts, it needs to invoke UMContract to verify the identity of the DU during the retrieval(6)
Remove: when DSContract receives action (DSContract, Remove, Auth, (fid)), this function interface will be triggered to execute. It is used to remove a shared data and the search indices related to this data. It can only be invoked by the DOAlgorithm 6: SetPK.
Input: newPkOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4PK = newPk;5return true;6endAlgorithm 7: SetSK.
Input: account, skOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4u=ua_idx.find(account);5ifu!=nullthen6u.SK=sk7ua_idx.modify(u)8return true;9else10u.A=account;11u.SK=sk;12ua_idx.emplace(u)13return true;14end15endAlgorithm 8: AddData.
Input: account, tkw, CTKF∣hreflocationOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4data_row.cf = CTKF∣hreflocation;5data_table.emplace(data_row);6search_row.A = account;7search_row.t = tkw;8search_row.fid = data_row.fid.9search_table.emplce(search_row);10return true;11endAlgorithm 9: PolicyUpdate.
Input: fid, CTKF∣hreflocationOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4data_row = data_table.find(fid);5ifdata_row == nullthen6returnfalse;7else8date_row.cf = CTKF∣hreflocation;9data_table.modify(data_row);10returntrue;11end12endAlgorithm 10: Search and EndSearch.
Input: from, uid, tkwOutput: data_rows1 send action (UMContract,Authenticate,Auth,(_self,Search,from,id,tkw))2if get false then3 throw;4else5t_itr=t_idx.find(tkw);6whilet_itr != search_table.end() andt_itr.t == tkwandt_itr.A == from7data_row=search_table.find(t_itr.fid);8data_rows.add(data_row);t_idx++;9end10returndata_rows;11endAlgorithm 11: Remove.
Input: fidOutput: bool1ifmsg.sender is not _selfthen2returnfalse;3else4s_itr = sf_idx.find(fid);5whiles_itr != sf_idx.end() ands_itr.fid == fid6sf_idx.erase(s_itr);7end8data_row = fid_idx.find(fid)9fid_idx.erase(data_row)10returntrue;11end


### 5.2. Concrete Construction of BSSPD

In this section, we will show the concrete construction of our scheme, including the algorithms that theDO and DUs need to execute at each phase and their interactions with the EOS blockchain. Our initialization is as follows.LetN=p1p2 (p1 and p2 are distinct primes) G1 and G2 be cyclic groups of order N. Let Gp1 and Gp2denote the subgroups of G1 with order g and Y. Let e:G1×G1→G2 be a bilinear pairing and I=1,⋯,m be the set of all attributes. Let F be a pseudorandom function, where F:0,1k×0,1∗→0,1k, and U=uid1,⋯,uidn be the uid set of all DUs obtained from UMContract.
(1)
setup1λ,IFor each attributei∣i∈I, the algorithm first randomly picks two elements ti,γi∈Zp1 and computes Ti=gt1,hi∈gγi. Next, it picks α,a∈Zp1 randomly, then computes eg,g.The public key isPK:
(2)PK=N,eg,gα,g,u=ga,Ti=gti,hi∈gγii∈I.The system master key isMSK:
(3)MSK=α,a,tii∈I,Y.Among them,ti and Ti are used for calculations related to attributes, γiand hi are used for calculations related to attribute revocation, u is used for calculations related to DU’s identity, and Y is used for randomization of DU’s private key.Then, send the following transaction to EOS blockchain and store the public key in theDSContract:
(4)Tx=Refblock,t,Sigchain_id,Tx,ActionDSContract,SetPK,AuthDO,PK.(2)
KeyGenuid,ω,MSK,PKFirstly, send the following transaction to EOS blockchain to obtain theDU’s information including A, Pkcom, and uid from UMContract:
(5)Tx=Refblock,t,SigDOchain_id,Tx,ActionUMContract,GetUserByUid,AuthDO,uid.After that, the algorithm randomly choosesr∈Zp1 and computes K0=ga+αr. For each attribute i∈ω, randomly pick ri∈Zp1 and Yi,1,Yi,2,Yi,3∈Gp2, then compute the following:
(6)Ki,1=gαr+tiri+ariYi,1,Ki,2=griYi,2,Ki,3=uuidhiriYi,3.LetKi=Ki,1,Ki,2,Ki,3, then DU’s attribute private key will be SKuid,ω=K0,Kii∈ω. As can be seen, the attribute-related part of the private key is embedded with the DU’s identity.Then, the algorithm randomly picks a secret keySKsearch for search where SKsearch=SKi←0,1λ. Let SKuid=E.EncPkcomSKuid,ω∣SKsearch, and send the following transaction to set and update the DU’s private keys:
(7)Tx=Refblock,t,SigDOchain_id,Tx,ActionDSContract,SetSK,AuthDO,A,SKuid.(3)
EncryptF,Al×k,ρ,Rρxx∈1,⋯,l,PKThe algorithm randomly chooses a private keyKF of ε, and encrypts the sharing data CF=ε.EncKFF, then uploads the CF to the IPFS network, and the returned address is hreflocation, set M=KF∣hreflocation.The algorithm first randomly pickss,v2,⋯,vk∈Zp1 and lets v=s,v2,⋯,vkT. For i=1 to l, it calculates λx=Ax·v where Ax is the vector corresponding to the xth row of Al×k. Assume that Rρx=uid1,⋯,uidlρx in which the number of revocable users lρx is variable. For each uidj∈Rρx, it randomly chooses a ηx,j∈Zp1, where j=1,2,⋯,lρx and ∑j=1lρx, and then computes
(8)C0=M·eg,gαs.C1=gs.For each attributeρx, it computes that
(9)Cx,0=gλx,Cx,1=Tρxλx.WhenRρX≠∅, it computes for each revoked uidj∈Rρx as follows:
(10)Cx,j,1=gηx,j,Cx,j,2=uuidjhρxηx,j.The ciphertextCF is set to
(11)CTKF∣hreflocation=C0,C1,Cx,0,Cx,1,Cx,j,1,Cx,j,2j=1,⋯,lρxx∈1,..,l.(4)
IndexGenA,kw,Ksearch,CTKF∣hreflocationThe algorithm calculates a search token for a keywordkw of the sharing data.
(12)tkw=FKsearch,kw.After that, it will send the following transaction to EOS blockchain to publish the data-related information and add the indices for the relevantDUs:
(13)Tx=Refblock,t,SigDOchain_id,Tx,ActionDSContract,AddData,AuthDO,A,tkw,CTKF∣hreflocation.(5)
Trpdrkw′,SKsearchTheDU obtains SKuid from the DSContract and decrypts it with his own private key.
(14)SKuid,ω∣Ksearch=E.DecSkcomSKuid.Then, it calculates the search token corresponding tokw′.
(15)t′kw=FKsearch,kw′.(6)
Searcht′kwSend the following transaction to EOS blockchain:(16)Tx=Refblock,t,SigDUchain_id,Tx,ActionDSContract,Search,AuthDU,t′kw.If the search is successful, theDU will obtain the data-related information CTKF∣hreflocation.
(7)
DecryptSKuid,CTKF∣hreflocation,PKLetL=x∣ρx∈ω,uid∉Rρx, then ω′=ρxx∈L denote the attribute set of the DU that has not been revoked. Assume that ω′ still satisfies the access policy Al×k,ρ; for any x from 1 to l, it will calculate Dx,1 and Dx,2.
(17)Dx,1=∏j=1lρxeKρx,2,Cx,j,2eKρx,3,Cx,j,11/uid−uidj,Dx,2=eKρx,1,Cx,0eKρx,2,Cx,1.Letμx be the restitution coefficient corresponding to the xth row in Al×x, and finally obtain the plaintext.
(18)M=KF∣hreflocation=C0·1eK0,C1·∏x∈LDx,1,Dx,2μx.TheDU can download CF from IPFS according to hreflocation and then use KF to decrypt CF and obtain the shared data F.
(19)F=ε.DecKFCF.(8)
RevokeM,Al×k,ρ,Rρxx∈1,⋯,l,PK,uid,iTake the revoking of the attributei of a DU to the sharing data F as an example; the DO needs to add the uid of the DU to the revocation list corresponding to the attribute i and execute the CP-ABE part of Encrypt to encrypt the data-related information M. Then, the DO sends a transaction as following to the EOS blockchain.
(20)Tx=Refblock,t,SigDOchain_id,Tx,ActionDSContract,PokicyUpdate,AuthDO,fid,CT′KF∣hreflocation.


## 5.1. Smart Contract Design

To make the logic clearer, we divide the Smart Contract in the scheme into two parts:UMContract and DSContract. UMContract is used to manage DUs’ identity, while DSContract is used to handle business operations related to data sharing. In the contract, we will use _self to represent the account of the DO who created the contract. We will describe the detailed design of these two contracts.


### 5.1.1. User Management Contract (UMContract)

Algorithm 1: SetTarget.
Input: newTargetOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4target = newTarget;5return true;6endAlgorithm 2: GetUserByUid.
Input: uidOutput: all information of DU1ifmsg.sender is not _selfthen2 throw;3else4user_row = uid_idx.find(uid);5returnuser_row;6endAlgorithm 3: Apply.
Input: from, pk, nonceOutput: bool1u = account_idx.find(from)2ifu != nullthen3u.Pkcom=pk;account_idx.modify(u);4return true;5else6pow=SHA256SHA256from∣pk∣nonce;7ifpow > targetthen8return false;9else10u.A = from;11u.Pkcom=pk;12account_idx.emplace(u);13return true;14end15endTheUMContract is composed of five function interfaces: SetTarget, GetUserByUid, Apply, Register, and Authenticate. We initialize UMContract as follows.Let three-tupleA,uid,Pkcom denote a DU, and create a multi_index named table_user for it in which A is an EOS account of the DU, uid is the unique ID assigned by the DO, and Pkcom is a public key of the DU used for communication with the DO. Let A be the primary key of table_user whose corresponding index is account_idx. Let uid_idx be a secondary index corresponding to uid. Let target be the target value of PoW.
(1)
SetTarget: when UMContract receives action (UMContract, SetTarget, Auth, (newTarget)), this function interface will be triggered to execute. It can only be invoked by the DO who created the contract to adjust the difficulty of PoW. When there are too many users in the system, the DO can increase the difficulty of PoW(2)
GetUserUid: when UMContract receives action (UMContract, GetUserByUid, Auth, (account)), this function interface will be triggered to execute. It is used to get all the information of a DU according to his uid and can only be invoked by the DO who created the contract(3)
Apply: when UMContract receives action (UMContract, Apply, Auth, (from, pk, nonce)), this function interface will be triggered to execute. It is invoked by the DU to apply for registration in the system(4)
Register: when UMContract receives action (UMContract, Register, Auth, (account, id)), this function interface will be triggered to execute. It is used to complete the registration of a DU and can only be invoked by the creator of the contract(5)
Authenticate: when UMContract receives action (UMContract, Authenticate, Auth, (from, method, account, id, args)), this function interface will be triggered to execute. It is used to authenticate the identity of a DU, which is invoked by another contract and returns the result to the invokerAlgorithm 4: Register.
Input: account, idOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4u = account_idx.find(account);5ifu==nullthen6return false;7else8u.uid=id;10account_idx.modify(u);11return true;12end13endAlgorithm 5: Authenticate.
Input: from, method, account, id, argsOutput: nullu=account_idx.find(account)1ifu != null then2ifu.id == id then3  send action (from, method, (_self, true, args));4else5  send action (from, method, (_self, false, args));6end7else8 send action (from, method, (_self, false, args));9end


### 5.1.2. Date Sharing Contract (DSContract)

TheDSContract is composed of six function interfaces: SetPK. SetSK, AddData, PolicyUpdate, Search and EndSearch, and Remove. We initialize DSContract as follows.LetPK denote the system public parameters. Let two-tuple (A, SK) be the corresponding relationship between the DU’s account and his attribute private key, and the multi_index table_sk is created for it. Let A be the primary key of table_sk whose corresponding index is ua_idx. Let two-tuple (fid, cf) denote the shared data in which fid is the id of shared data and cf is the data-related information. Then, create a multi_index data_table for it, where fid is the primary key and fid_idx is the corresponding index. Let four-tuple (id, A, t, fid) be an index of DU related to shared data in which A is the EOS account of DU, t is the search token, and fid is the id of shared data in data_table, then create a multi_index search_table for it. Let sa_idx, t_idx, sf_idx be the secondary indices of search_table, corresponding to A, t, and fid, respectively.
(1)
SetPK: when DSContract receives action (DSContract, SetPK, Auth, (newPk)), this function interface will be triggered to execute. It can only be invoked by the DO to set and update the system public parameters(2)
SetSK: when DSContract receives action (DSContract, SetSK, Auth, (account, sk)), this function interface will be triggered to execute. It can only be invoked by the DO to set and update the private keys of the DU(3)
AddData: when DSContract receives action (DSContract, AddData, Auth, (account, tkw, CTKF∣hreflocation)), this function interface will be triggered to execute. It is used to publish the sharing data and add the indices for the relevant DUs. There can be multiple index relationships. For clarity, we only add an index for one DU here. It can only be invoked by the DO(4)
PolicyUpdate: when DSContract receives action (DSContract, PolicyUpdate, Auth, (fid, CTKF∣hreflocation)), this function interface will be triggered to execute. It can only be invoked by the DO and used to update the access policy for a certain shared data. In this way, the DO can revoke the access permission of a DU to this shared data(5)
Search and EndSearch: when DSContract receives action (DSContract, Search, Auth, (from, uid, tkw)), this function interface will be triggered to execute. These two function interfaces work together to complete the retrieval of shared data. Because we have divided BSSPD into two contracts, it needs to invoke UMContract to verify the identity of the DU during the retrieval(6)
Remove: when DSContract receives action (DSContract, Remove, Auth, (fid)), this function interface will be triggered to execute. It is used to remove a shared data and the search indices related to this data. It can only be invoked by the DOAlgorithm 6: SetPK.
Input: newPkOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4PK = newPk;5return true;6endAlgorithm 7: SetSK.
Input: account, skOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4u=ua_idx.find(account);5ifu!=nullthen6u.SK=sk7ua_idx.modify(u)8return true;9else10u.A=account;11u.SK=sk;12ua_idx.emplace(u)13return true;14end15endAlgorithm 8: AddData.
Input: account, tkw, CTKF∣hreflocationOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4data_row.cf = CTKF∣hreflocation;5data_table.emplace(data_row);6search_row.A = account;7search_row.t = tkw;8search_row.fid = data_row.fid.9search_table.emplce(search_row);10return true;11endAlgorithm 9: PolicyUpdate.
Input: fid, CTKF∣hreflocationOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4data_row = data_table.find(fid);5ifdata_row == nullthen6returnfalse;7else8date_row.cf = CTKF∣hreflocation;9data_table.modify(data_row);10returntrue;11end12endAlgorithm 10: Search and EndSearch.
Input: from, uid, tkwOutput: data_rows1 send action (UMContract,Authenticate,Auth,(_self,Search,from,id,tkw))2if get false then3 throw;4else5t_itr=t_idx.find(tkw);6whilet_itr != search_table.end() andt_itr.t == tkwandt_itr.A == from7data_row=search_table.find(t_itr.fid);8data_rows.add(data_row);t_idx++;9end10returndata_rows;11endAlgorithm 11: Remove.
Input: fidOutput: bool1ifmsg.sender is not _selfthen2returnfalse;3else4s_itr = sf_idx.find(fid);5whiles_itr != sf_idx.end() ands_itr.fid == fid6sf_idx.erase(s_itr);7end8data_row = fid_idx.find(fid)9fid_idx.erase(data_row)10returntrue;11end


## 5.1.1. User Management Contract (UMContract)

Algorithm 1: SetTarget.
Input: newTargetOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4target = newTarget;5return true;6endAlgorithm 2: GetUserByUid.
Input: uidOutput: all information of DU1ifmsg.sender is not _selfthen2 throw;3else4user_row = uid_idx.find(uid);5returnuser_row;6endAlgorithm 3: Apply.
Input: from, pk, nonceOutput: bool1u = account_idx.find(from)2ifu != nullthen3u.Pkcom=pk;account_idx.modify(u);4return true;5else6pow=SHA256SHA256from∣pk∣nonce;7ifpow > targetthen8return false;9else10u.A = from;11u.Pkcom=pk;12account_idx.emplace(u);13return true;14end15endTheUMContract is composed of five function interfaces: SetTarget, GetUserByUid, Apply, Register, and Authenticate. We initialize UMContract as follows.Let three-tupleA,uid,Pkcom denote a DU, and create a multi_index named table_user for it in which A is an EOS account of the DU, uid is the unique ID assigned by the DO, and Pkcom is a public key of the DU used for communication with the DO. Let A be the primary key of table_user whose corresponding index is account_idx. Let uid_idx be a secondary index corresponding to uid. Let target be the target value of PoW.
(1)
SetTarget: when UMContract receives action (UMContract, SetTarget, Auth, (newTarget)), this function interface will be triggered to execute. It can only be invoked by the DO who created the contract to adjust the difficulty of PoW. When there are too many users in the system, the DO can increase the difficulty of PoW(2)
GetUserUid: when UMContract receives action (UMContract, GetUserByUid, Auth, (account)), this function interface will be triggered to execute. It is used to get all the information of a DU according to his uid and can only be invoked by the DO who created the contract(3)
Apply: when UMContract receives action (UMContract, Apply, Auth, (from, pk, nonce)), this function interface will be triggered to execute. It is invoked by the DU to apply for registration in the system(4)
Register: when UMContract receives action (UMContract, Register, Auth, (account, id)), this function interface will be triggered to execute. It is used to complete the registration of a DU and can only be invoked by the creator of the contract(5)
Authenticate: when UMContract receives action (UMContract, Authenticate, Auth, (from, method, account, id, args)), this function interface will be triggered to execute. It is used to authenticate the identity of a DU, which is invoked by another contract and returns the result to the invokerAlgorithm 4: Register.
Input: account, idOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4u = account_idx.find(account);5ifu==nullthen6return false;7else8u.uid=id;10account_idx.modify(u);11return true;12end13endAlgorithm 5: Authenticate.
Input: from, method, account, id, argsOutput: nullu=account_idx.find(account)1ifu != null then2ifu.id == id then3  send action (from, method, (_self, true, args));4else5  send action (from, method, (_self, false, args));6end7else8 send action (from, method, (_self, false, args));9end


## 5.1.2. Date Sharing Contract (DSContract)

TheDSContract is composed of six function interfaces: SetPK. SetSK, AddData, PolicyUpdate, Search and EndSearch, and Remove. We initialize DSContract as follows.LetPK denote the system public parameters. Let two-tuple (A, SK) be the corresponding relationship between the DU’s account and his attribute private key, and the multi_index table_sk is created for it. Let A be the primary key of table_sk whose corresponding index is ua_idx. Let two-tuple (fid, cf) denote the shared data in which fid is the id of shared data and cf is the data-related information. Then, create a multi_index data_table for it, where fid is the primary key and fid_idx is the corresponding index. Let four-tuple (id, A, t, fid) be an index of DU related to shared data in which A is the EOS account of DU, t is the search token, and fid is the id of shared data in data_table, then create a multi_index search_table for it. Let sa_idx, t_idx, sf_idx be the secondary indices of search_table, corresponding to A, t, and fid, respectively.
(1)
SetPK: when DSContract receives action (DSContract, SetPK, Auth, (newPk)), this function interface will be triggered to execute. It can only be invoked by the DO to set and update the system public parameters(2)
SetSK: when DSContract receives action (DSContract, SetSK, Auth, (account, sk)), this function interface will be triggered to execute. It can only be invoked by the DO to set and update the private keys of the DU(3)
AddData: when DSContract receives action (DSContract, AddData, Auth, (account, tkw, CTKF∣hreflocation)), this function interface will be triggered to execute. It is used to publish the sharing data and add the indices for the relevant DUs. There can be multiple index relationships. For clarity, we only add an index for one DU here. It can only be invoked by the DO(4)
PolicyUpdate: when DSContract receives action (DSContract, PolicyUpdate, Auth, (fid, CTKF∣hreflocation)), this function interface will be triggered to execute. It can only be invoked by the DO and used to update the access policy for a certain shared data. In this way, the DO can revoke the access permission of a DU to this shared data(5)
Search and EndSearch: when DSContract receives action (DSContract, Search, Auth, (from, uid, tkw)), this function interface will be triggered to execute. These two function interfaces work together to complete the retrieval of shared data. Because we have divided BSSPD into two contracts, it needs to invoke UMContract to verify the identity of the DU during the retrieval(6)
Remove: when DSContract receives action (DSContract, Remove, Auth, (fid)), this function interface will be triggered to execute. It is used to remove a shared data and the search indices related to this data. It can only be invoked by the DOAlgorithm 6: SetPK.
Input: newPkOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4PK = newPk;5return true;6endAlgorithm 7: SetSK.
Input: account, skOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4u=ua_idx.find(account);5ifu!=nullthen6u.SK=sk7ua_idx.modify(u)8return true;9else10u.A=account;11u.SK=sk;12ua_idx.emplace(u)13return true;14end15endAlgorithm 8: AddData.
Input: account, tkw, CTKF∣hreflocationOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4data_row.cf = CTKF∣hreflocation;5data_table.emplace(data_row);6search_row.A = account;7search_row.t = tkw;8search_row.fid = data_row.fid.9search_table.emplce(search_row);10return true;11endAlgorithm 9: PolicyUpdate.
Input: fid, CTKF∣hreflocationOutput: bool1ifmsg.sender is not _selfthen2 throw;3else4data_row = data_table.find(fid);5ifdata_row == nullthen6returnfalse;7else8date_row.cf = CTKF∣hreflocation;9data_table.modify(data_row);10returntrue;11end12endAlgorithm 10: Search and EndSearch.
Input: from, uid, tkwOutput: data_rows1 send action (UMContract,Authenticate,Auth,(_self,Search,from,id,tkw))2if get false then3 throw;4else5t_itr=t_idx.find(tkw);6whilet_itr != search_table.end() andt_itr.t == tkwandt_itr.A == from7data_row=search_table.find(t_itr.fid);8data_rows.add(data_row);t_idx++;9end10returndata_rows;11endAlgorithm 11: Remove.
Input: fidOutput: bool1ifmsg.sender is not _selfthen2returnfalse;3else4s_itr = sf_idx.find(fid);5whiles_itr != sf_idx.end() ands_itr.fid == fid6sf_idx.erase(s_itr);7end8data_row = fid_idx.find(fid)9fid_idx.erase(data_row)10returntrue;11end


## 5.2. Concrete Construction of BSSPD

In this section, we will show the concrete construction of our scheme, including the algorithms that theDO and DUs need to execute at each phase and their interactions with the EOS blockchain. Our initialization is as follows.LetN=p1p2 (p1 and p2 are distinct primes) G1 and G2 be cyclic groups of order N. Let Gp1 and Gp2denote the subgroups of G1 with order g and Y. Let e:G1×G1→G2 be a bilinear pairing and I=1,⋯,m be the set of all attributes. Let F be a pseudorandom function, where F:0,1k×0,1∗→0,1k, and U=uid1,⋯,uidn be the uid set of all DUs obtained from UMContract.
(1)
setup1λ,IFor each attributei∣i∈I, the algorithm first randomly picks two elements ti,γi∈Zp1 and computes Ti=gt1,hi∈gγi. Next, it picks α,a∈Zp1 randomly, then computes eg,g.The public key isPK:
(2)PK=N,eg,gα,g,u=ga,Ti=gti,hi∈gγii∈I.The system master key isMSK:
(3)MSK=α,a,tii∈I,Y.Among them,ti and Ti are used for calculations related to attributes, γiand hi are used for calculations related to attribute revocation, u is used for calculations related to DU’s identity, and Y is used for randomization of DU’s private key.Then, send the following transaction to EOS blockchain and store the public key in theDSContract:
(4)Tx=Refblock,t,Sigchain_id,Tx,ActionDSContract,SetPK,AuthDO,PK.(2)
KeyGenuid,ω,MSK,PKFirstly, send the following transaction to EOS blockchain to obtain theDU’s information including A, Pkcom, and uid from UMContract:
(5)Tx=Refblock,t,SigDOchain_id,Tx,ActionUMContract,GetUserByUid,AuthDO,uid.After that, the algorithm randomly choosesr∈Zp1 and computes K0=ga+αr. For each attribute i∈ω, randomly pick ri∈Zp1 and Yi,1,Yi,2,Yi,3∈Gp2, then compute the following:
(6)Ki,1=gαr+tiri+ariYi,1,Ki,2=griYi,2,Ki,3=uuidhiriYi,3.LetKi=Ki,1,Ki,2,Ki,3, then DU’s attribute private key will be SKuid,ω=K0,Kii∈ω. As can be seen, the attribute-related part of the private key is embedded with the DU’s identity.Then, the algorithm randomly picks a secret keySKsearch for search where SKsearch=SKi←0,1λ. Let SKuid=E.EncPkcomSKuid,ω∣SKsearch, and send the following transaction to set and update the DU’s private keys:
(7)Tx=Refblock,t,SigDOchain_id,Tx,ActionDSContract,SetSK,AuthDO,A,SKuid.(3)
EncryptF,Al×k,ρ,Rρxx∈1,⋯,l,PKThe algorithm randomly chooses a private keyKF of ε, and encrypts the sharing data CF=ε.EncKFF, then uploads the CF to the IPFS network, and the returned address is hreflocation, set M=KF∣hreflocation.The algorithm first randomly pickss,v2,⋯,vk∈Zp1 and lets v=s,v2,⋯,vkT. For i=1 to l, it calculates λx=Ax·v where Ax is the vector corresponding to the xth row of Al×k. Assume that Rρx=uid1,⋯,uidlρx in which the number of revocable users lρx is variable. For each uidj∈Rρx, it randomly chooses a ηx,j∈Zp1, where j=1,2,⋯,lρx and ∑j=1lρx, and then computes
(8)C0=M·eg,gαs.C1=gs.For each attributeρx, it computes that
(9)Cx,0=gλx,Cx,1=Tρxλx.WhenRρX≠∅, it computes for each revoked uidj∈Rρx as follows:
(10)Cx,j,1=gηx,j,Cx,j,2=uuidjhρxηx,j.The ciphertextCF is set to
(11)CTKF∣hreflocation=C0,C1,Cx,0,Cx,1,Cx,j,1,Cx,j,2j=1,⋯,lρxx∈1,..,l.(4)
IndexGenA,kw,Ksearch,CTKF∣hreflocationThe algorithm calculates a search token for a keywordkw of the sharing data.
(12)tkw=FKsearch,kw.After that, it will send the following transaction to EOS blockchain to publish the data-related information and add the indices for the relevantDUs:
(13)Tx=Refblock,t,SigDOchain_id,Tx,ActionDSContract,AddData,AuthDO,A,tkw,CTKF∣hreflocation.(5)
Trpdrkw′,SKsearchTheDU obtains SKuid from the DSContract and decrypts it with his own private key.
(14)SKuid,ω∣Ksearch=E.DecSkcomSKuid.Then, it calculates the search token corresponding tokw′.
(15)t′kw=FKsearch,kw′.(6)
Searcht′kwSend the following transaction to EOS blockchain:(16)Tx=Refblock,t,SigDUchain_id,Tx,ActionDSContract,Search,AuthDU,t′kw.If the search is successful, theDU will obtain the data-related information CTKF∣hreflocation.
(7)
DecryptSKuid,CTKF∣hreflocation,PKLetL=x∣ρx∈ω,uid∉Rρx, then ω′=ρxx∈L denote the attribute set of the DU that has not been revoked. Assume that ω′ still satisfies the access policy Al×k,ρ; for any x from 1 to l, it will calculate Dx,1 and Dx,2.
(17)Dx,1=∏j=1lρxeKρx,2,Cx,j,2eKρx,3,Cx,j,11/uid−uidj,Dx,2=eKρx,1,Cx,0eKρx,2,Cx,1.Letμx be the restitution coefficient corresponding to the xth row in Al×x, and finally obtain the plaintext.
(18)M=KF∣hreflocation=C0·1eK0,C1·∏x∈LDx,1,Dx,2μx.TheDU can download CF from IPFS according to hreflocation and then use KF to decrypt CF and obtain the shared data F.
(19)F=ε.DecKFCF.(8)
RevokeM,Al×k,ρ,Rρxx∈1,⋯,l,PK,uid,iTake the revoking of the attributei of a DU to the sharing data F as an example; the DO needs to add the uid of the DU to the revocation list corresponding to the attribute i and execute the CP-ABE part of Encrypt to encrypt the data-related information M. Then, the DO sends a transaction as following to the EOS blockchain.
(20)Tx=Refblock,t,SigDOchain_id,Tx,ActionDSContract,PokicyUpdate,AuthDO,fid,CT′KF∣hreflocation.


## 6. Security and Performance Analysis of the Proposed Scheme

### 6.1. Security and Privacy Analysis of BPSSD

#### 6.1.1. Correctness

LetL=x∣ρx∈ω,uid∉Rρx, then ω′=ρxx∈L denote the attributes set of the DU that has not been revoked. Assume that ω′ still satisfies the access policy Al×k,ρ; for any x from 1 to l, then
(21)Dx,1=∏j=1lρxegrρxYρx,2,uuidjhρxηx,jeuuidhρxrρxYρx,3,gηx,j1/uid−uidj=eg,u−rρx∑j=1lρxηx,j=eg,g−arρxλx,Dx,2=egαr+tρxrρx+arρxYρx,1,gλxegrρxYρx,2,Tρxλx=eg,gαr+tρxrρx+arρxλx−tρxrρxλx=eg,gαr+arρxλx,M′=KF∣hreflocation=C0·1eK0,C1·∏x∈LDx,1Dx,2μx=Meg,gαs·1egα+αr,gs·eg,gαr∑x∈Lλxμx=Meg,gαs·1egα+αr,gs·eg,gαrs=M.After the proof, the data-related informationM can be decrypted by the DU.


#### 6.1.2. Security Analysis

The CP-ABE algorithm used in this paper is based on the scheme [37], referring to the revocation idea in [35] that introduces a revocation list for each attribute. The scheme [37] has proved to be completely secure. The detailed proof process can refer to the security analysis in [37], which is based on the standard model, and the security depends on three static assumptions.This paper focuses on security data sharing based on blockchain. The security of CP-ABE is not within the main scope of this article. We will conduct a brief analysis of the security after adding an attribute revocation mechanism to the scheme [37].If an adversaryA can win the game with a nonnegligible advantage in the security model in [37], he must be able to calculate eg,gαs. To obtain such a pairing, the adversary needs to utilize K0=ga+rα in the private key and C1=gs in the ciphertext, both of which can get eg,gαseg,gαrs. This means that A needs to get eg,gαrs. Then, A needs to get Dx,1 and Dx,2 corresponding to each attribute and get eg,gαrλx by calculation. If A does not satisfy the challenge attributes, he cannot obtain the correct attribute keys to calculate eg,gαrλxconforming to the access policy and recover eg,gαrs.For collusion attacks, when generating private keys for eachDU, a random element r is contained in K0 and random elements ri and Yi,1,Yi,2,Yi,3 are added to the attributes, so that different DUs cannot combine their private keys to launch attacks.The attribute private keyKi,3=uuidhiriYi,3 which is related to the revocation contains the DU’s identity information uid. When Rρx≠∅, each uidj∈Rρx in the revocation list contains Cx,j,1=gηx,j and Cx,j,2=uuidjhρxηx,j, which need to be eliminated when decrypting. 1/uid−uidj is used when eliminating. If uid is in the revocation list, 1/uid−uidj will not be calculated to achieve the purpose of revoking the attribute j of uid.


#### 6.1.3. Other Security Problem

(1) Data Security. Data security includes the confidentiality, integrity, and availability of the shared data. In our scheme, the large-capacity sharing data of the DO is encrypted using an efficient asymmetric encryption algorithm such as AES and uploaded to IPFS. The IPFS will split the encrypted data and store them on different IPFS nodes in a distributed manner. The access will be routed through the dynamic hash table maintained by each node, and a certain redundancy mechanism will ensure fault tolerance. Besides, IPFS also provides version control like Git. Thus, data encryption and storage in blocks ensure the confidentiality of the shared data. The integrity is guaranteed by dynamic hash table routing, and the tampered data blocks will not be available. The redundant storage and incentive mechanisms of IPFS ensure that users can access their data at any time. As long as IPFS is secure, then the data stored on it in our scheme is secure.(2) Privacy Analysis. In a data-sharing system, privacy includes the content of the DO’s shared data and the traces of the DU when using the data. In our scheme, the DO will encrypt the address of the shared data and the corresponding decryption key with CP-ABE according to the established access policy. Then, the ciphertext is stored on the blockchain, and only the DUs whose attribute set satisfies the access policy can obtain the data. The content of the data will not be leaked. For the traces generated by DUs, we encrypt the keywords corresponding to the sharing data. The DU invoked the trapdoor function to calculate the search token for the keyword that he needs to retrieve and then uses the search token for retrieving on the blockchain without revealing any information he wants. More importantly, the user’s identity is represented in the form of an address on the blockchain, and the real information of the user will not be exposed.(3) Fine-Grained Access Control. In our scheme, the fine-grained access control of shared data is realized by CP-ABE. The DO can make different access policies through LSSS and assign different attributes to DUs. Meanwhile, fine-grained access control should also include fine-grained revocation. The proposed scheme draws on the identity-based broadcast encryption scheme, in which the DO assigns a unique uid for each DU, and the uid will be used as a user attribute, embedded in the ciphertext together with the general attributes. Each general attribute in the ciphertext carries a revocation list, and the DU whose uid in this list no longer has the corresponding attribute, so that it achieves the purpose of directly revoking a DU’s attribute.(4) Avoid a Single Point of Failure. Compared with traditional cloud storage solutions, there is no centralized third party in our proposed scheme. Blockchain and IPFS used in BSSPD are all distributed technologies. Even if some of the nodes fail, the availability of the whole scheme will not be affected. More importantly, the BitTorrent protocol adopted by IPFS can enjoy a high throughput only by requiring paying a small number of fees to incentive storage nodes. Simultaneously, the EOS blockchain is free to users, only the DO needs to mortgage some system tokens in exchange for storage and CPU resources, and these tokens can also be redeemed.(5) User-Centric. In our proposed scheme, the DO can generate public parameters and the system master key and generate and distribute the private keys for DUs according to their attributes. Moreover, the DO can formulate access policies arbitrarily to assign and revoke the permission of DUs. All of these are controlled by the DO without any trusted third party. In this manner, the DO has complete control over his shared data.(6) Identity Authentication. The user generates his identity in the blockchain through an asymmetric encryption algorithm with generating key pairs, whose cost is too low. In our proposed scheme, since the uid is embedded in the ciphertext of CP-ABE as an attribute, the DUs may register a large number of uids and use different uids to search and decrypt the shared data, which increases the burden of the DO. In order to prevent such attacks, BSSPD requires identity authentication. Before applying for registration, the DU needs to perform a PoW, which is similar to Bitcoin mining. The DO can adjust the difficulty of PoW according to the total number of DUs in the system. User management and identity authentication are carried out on the blockchain, and only authenticated users can perform operations. These are all executed in Smart Contract ensuring transparency and security.


### 6.2. Experiments and Performance Analysis of BPSSD

#### 6.2.1. Functional Comparison

We compared the scheme proposed in this article with the recent blockchain-based data-sharing models from the following aspects, including security and privacy, identity management, fine-grained access control, immediate access revocation, and ciphertext keyword retrieval, as shown in Table2.Table 2
Functional comparison between BSSPD and other blockchain-based data-sharing scheme.
No.BSSPDRef. [18]Ref. [21]Ref. [28]Security and privacy√√√√Identity management√×××Fine-grained access control√××√Immediate access revocation√×××Keyword ciphertext retrieval√××√From the comparison in the table, it can be concluded that due to the blockchain’s decentralized and trustless nature, the data-sharing models based on blockchain allowDOs to formulate access control policies for their data on-chain, so they all can guarantee security and privacy. Early schemes like Ref. [18] mostly only described the model’s outline without the specific implementation details. Generally, they only describe how blockchain can benefit security and privacy during the sharing, so the function is relatively simple. Reference [21] implemented a role-based access control model on the blockchain, but it turns out that RBAC is not suitable for implementing fine-grained access control and revocation in a distributed environment. Reference [28] utilized CP-ABE to achieve fine-grained access control, but it does not achieve permission revocation. However, in the access control scheme based on CP-ABE, an immediate access revocation is indispensable.In our proposed scheme, we utilized CP-ABE to achieve fine-grained access control and realized the identity management ofDUs. The DO assigns and manages unique uids and attributes for registered DUs. Maintaining a revocation list for each attribute in the ciphertext can directly revoke a particular attribute of a DU without updating others’ keys. BSSPD uses ciphertext keyword search to protect the privacy of DUs on-chain. Therefore, our proposed scheme has better applicability and usability.


#### 6.2.2. Storage Analysis

BSSPD is a user-centric data-sharing scheme based on the EOS blockchain, and it stores the public system parameters, user information, and data-related information in the persistent database of Smart Contract. Because the storage resource on-chain is valuable and the acquisition of RAM in the EOS blockchain requires mortgaging system tokens, so it is necessary to analyze the size of the data stored in the Smart Contract.We first define some symbols; we set∣G1∣, ∣G2∣, ∣Gp1∣, ∣Gp2∣ to represent the bit length of an element in group G1,G2,Gp1, and Gp2, respectively. Let ∣ZN∣ be the bit length of an element in filed ZN, ∣KAES∣ be the bit length of a key of AES algorithm, and ∣Skcom∣ and ∣Pkcom∣ be the bit length of private key and public key of ECC, respectively; |S| denote the number of attributes in system, and Ksearch denote the bit length of a secret key of pseudorandom function F.According to the experiment simulation in our scheme, we set∣G1∣=∣G2∣=∣Gp1∣=∣Gp2∣=1024bits;∣ZN∣=128bits;∣KAES∣=256 bits;∣Skcom∣=256 bits;∣Pkcom∣=272bits;∣Ksearch∣=128bits; the bit length of account, uid, fid, and search tokentkwto be 64; and the bit length of an IPFS address to be 256. The storage overhead of BSSPD at each phase varies with the number of attributes which is shown in Figure 3.Figure 3
Storage overhead of BSSPD at each phase varies with the number of attributes.In our proposed scheme, there are three operations that interact with the blockchain to store data in the Smart Contract, which are as follows:(1)
InitializationTheDO uploads the system public parameters to the Smart Contract; the storage overhead is
(22)∣ZN∣+∣G1∣+2∣Gp1∣+∣S∣2∣Gp1∣=3200+2048∣S∣bits.(2)
RegistrationTheDU uploads information to the Smart Contract when applying for registration, and the DO assigns a unique uid and private keys for the DU. The storage overhead is
(23)account+uid+Pkcom+∣Ksearch∣+Gp1+3Gp1S=1552+3072Sbits.(3)
Encryption and uploadingTheDO uploads data-related information and the private keys of the DU to the Smart Contract, as well as the indices for the DU. The storage overhead is
(24)KAES+address+2Gp1+2Gp1S+2Gp1R+fid+tkw+fid+account=2752+2048S+2048R.For simplicity, the figure shows that the storage overhead varies with the number of attributes when there are 10DUs in the revocation list. As the number of DUs in the revocation list and the relevant DUs increases, the storage overhead will also increase to a certain extent.The RAM in the EOS blockchain is obtained by collateralizing system tokens, and the current price is 0.05 EOS/KB. TheDO can purchase RAM according to the scale of his system. Unlike Ethereum transactions that need to consume ETH as gas, the tokens mortgaged when acquiring RAM in EOS can still be redeemed at the original price. Above all, the proposed scheme is feasible and practical.


#### 6.2.3. Performance Analysis

As we all know, the computing resource on the blockchain is also precious, and the computational efficiency of the existing blockchains is often criticized. For example, Bitcoin takes 10 minutes to produce a block. Ethereum has dramatically improved the block generation time, but it also takes about 15 seconds. In this section, we will conduct experiments on our proposed scheme and evaluate the scheme’s performance and user scale.We used 5 nodes to build an EOS private chain in a laboratory environment. The 5 nodes we chose were all MacBook Pro (2017) with Intel (R) Core (TM) i5 CPU that clocks at 3.1 GHz and has 16.0 GB of RAM. The version of the EOS blockchain we chose is v2.0.6. The code of the indices of the two tables related to the sharing data in our Smart Contract is as follows:Code 1: The code of the tables in Smart Contract.
typedef eosio::multi_index<"sharedatas"_n, my_data> data_table;ttypedef eosio::multi_index<"searchindexs"_n, s_index, indexed_by<"username"_n,const_mem_fun<s_index, uint64_t, &s_index::by_secondary>>,indexed_by <"searchtoken "_n, const_mem_fun<s_index, checksum256, &s_index::by_thirdary>>,indexed_by<"fid"_n, const_mem_fun<s_index, uint64_t, &s_index::by_forthary>>> search_table;In our scheme’s initialization phase, the operation on-chain is to set and update the public system parameters. The previous section shows that the storage overhead will continue to expand as the attributes increase. However, it can be seen from Figure4 that as the attributes increase, the computing overhead will not be significantly affected in this phase.Figure 4
Computing overhead of the initialization phase varies with the number of attributes.In the encryption and uploading phase of our scheme, the operations that need to be performed on-chain are uploading the data-related information to Smart Contract and establishing the keyword indices for the data-relatedDUs. As shown in Figure 5, the increase in the number of attributes will not have too much influence on the computing overhead of AddData. In the case of a different number of attributes, the computing overhead of AddData is generally stable. What impacts the computing overhead of AddData is the scale of DUs, especially the number of DUs related to the sharing data. It can be seen from Figure 5 that the computing overhead of 500 DUs is obviously higher than that of 100 DUs, and the time cost is mainly spent on establishing search indices for the relevant DUs.Figure 5
Computing overhead of the AddData varies with the number of attributes.Since BSSPD sets the search token as a secondary index of thesearch_table in the Smart Contract, no matter how many pieces of index data exist in the system, the time complexity of retrieving according to the search token is O1. As shown in Figure 6, when there are 10 billion pieces of index data, the search time is not much different from that of 1 million, and the search time is in milliseconds.Figure 6
Computing overhead of the search phase varies with the number of rows of index information.The deletion of a certain data in our scheme is to remove the data-related information and the indices to the data. As shown in Figure7, as the number of data-related DUs continues to expand, the computing overhead of deletion will increase too. The main time cost is spent on deleting the search indices to the data.Figure 7
Computing overhead of the remove varies with the number of DUs associated with the shared data.Since only the ciphertext data needs to be updated according to the shared data’s primary key id when revoking aDU’s attribute of a specific shared data, there is no need to operate on the relevant indices, and its computing overhead is similar to set and update the public system parameters in the initialization phase, which is stable.In summary, in our proposed scheme, the total number of attributes will not impact much on the computing overhead on-chain. According to experience, it only affects operations off-chain, such as key generation, encryption, and decryption. However, the expansion of the user scale will increase the time cost of some operations. Specifically, it is increased with the number ofDUs related to certain shared data because search indices will be established. When the related search indices of a specific data increase to 500, the computing overhead is still in milliseconds. For all operations on-chain in our scheme, the computing overhead is less than 100 milliseconds. The configuration of the EOS main network’s block producer is much better than the laptop we use, so when the contract is deployed on the main network of EOS, the computing overhead will be much lower than that of our simulation. Now, since EOS takes 0.5 seconds to generate a block, our scheme’s operation will be confirmed soon after execution. Therefore, the experiment has proved that our scheme has a good performance.


## 6.1. Security and Privacy Analysis of BPSSD

### 6.1.1. Correctness

LetL=x∣ρx∈ω,uid∉Rρx, then ω′=ρxx∈L denote the attributes set of the DU that has not been revoked. Assume that ω′ still satisfies the access policy Al×k,ρ; for any x from 1 to l, then
(21)Dx,1=∏j=1lρxegrρxYρx,2,uuidjhρxηx,jeuuidhρxrρxYρx,3,gηx,j1/uid−uidj=eg,u−rρx∑j=1lρxηx,j=eg,g−arρxλx,Dx,2=egαr+tρxrρx+arρxYρx,1,gλxegrρxYρx,2,Tρxλx=eg,gαr+tρxrρx+arρxλx−tρxrρxλx=eg,gαr+arρxλx,M′=KF∣hreflocation=C0·1eK0,C1·∏x∈LDx,1Dx,2μx=Meg,gαs·1egα+αr,gs·eg,gαr∑x∈Lλxμx=Meg,gαs·1egα+αr,gs·eg,gαrs=M.After the proof, the data-related informationM can be decrypted by the DU.


### 6.1.2. Security Analysis

The CP-ABE algorithm used in this paper is based on the scheme [37], referring to the revocation idea in [35] that introduces a revocation list for each attribute. The scheme [37] has proved to be completely secure. The detailed proof process can refer to the security analysis in [37], which is based on the standard model, and the security depends on three static assumptions.This paper focuses on security data sharing based on blockchain. The security of CP-ABE is not within the main scope of this article. We will conduct a brief analysis of the security after adding an attribute revocation mechanism to the scheme [37].If an adversaryA can win the game with a nonnegligible advantage in the security model in [37], he must be able to calculate eg,gαs. To obtain such a pairing, the adversary needs to utilize K0=ga+rα in the private key and C1=gs in the ciphertext, both of which can get eg,gαseg,gαrs. This means that A needs to get eg,gαrs. Then, A needs to get Dx,1 and Dx,2 corresponding to each attribute and get eg,gαrλx by calculation. If A does not satisfy the challenge attributes, he cannot obtain the correct attribute keys to calculate eg,gαrλxconforming to the access policy and recover eg,gαrs.For collusion attacks, when generating private keys for eachDU, a random element r is contained in K0 and random elements ri and Yi,1,Yi,2,Yi,3 are added to the attributes, so that different DUs cannot combine their private keys to launch attacks.The attribute private keyKi,3=uuidhiriYi,3 which is related to the revocation contains the DU’s identity information uid. When Rρx≠∅, each uidj∈Rρx in the revocation list contains Cx,j,1=gηx,j and Cx,j,2=uuidjhρxηx,j, which need to be eliminated when decrypting. 1/uid−uidj is used when eliminating. If uid is in the revocation list, 1/uid−uidj will not be calculated to achieve the purpose of revoking the attribute j of uid.


### 6.1.3. Other Security Problem

(1) Data Security. Data security includes the confidentiality, integrity, and availability of the shared data. In our scheme, the large-capacity sharing data of the DO is encrypted using an efficient asymmetric encryption algorithm such as AES and uploaded to IPFS. The IPFS will split the encrypted data and store them on different IPFS nodes in a distributed manner. The access will be routed through the dynamic hash table maintained by each node, and a certain redundancy mechanism will ensure fault tolerance. Besides, IPFS also provides version control like Git. Thus, data encryption and storage in blocks ensure the confidentiality of the shared data. The integrity is guaranteed by dynamic hash table routing, and the tampered data blocks will not be available. The redundant storage and incentive mechanisms of IPFS ensure that users can access their data at any time. As long as IPFS is secure, then the data stored on it in our scheme is secure.(2) Privacy Analysis. In a data-sharing system, privacy includes the content of the DO’s shared data and the traces of the DU when using the data. In our scheme, the DO will encrypt the address of the shared data and the corresponding decryption key with CP-ABE according to the established access policy. Then, the ciphertext is stored on the blockchain, and only the DUs whose attribute set satisfies the access policy can obtain the data. The content of the data will not be leaked. For the traces generated by DUs, we encrypt the keywords corresponding to the sharing data. The DU invoked the trapdoor function to calculate the search token for the keyword that he needs to retrieve and then uses the search token for retrieving on the blockchain without revealing any information he wants. More importantly, the user’s identity is represented in the form of an address on the blockchain, and the real information of the user will not be exposed.(3) Fine-Grained Access Control. In our scheme, the fine-grained access control of shared data is realized by CP-ABE. The DO can make different access policies through LSSS and assign different attributes to DUs. Meanwhile, fine-grained access control should also include fine-grained revocation. The proposed scheme draws on the identity-based broadcast encryption scheme, in which the DO assigns a unique uid for each DU, and the uid will be used as a user attribute, embedded in the ciphertext together with the general attributes. Each general attribute in the ciphertext carries a revocation list, and the DU whose uid in this list no longer has the corresponding attribute, so that it achieves the purpose of directly revoking a DU’s attribute.(4) Avoid a Single Point of Failure. Compared with traditional cloud storage solutions, there is no centralized third party in our proposed scheme. Blockchain and IPFS used in BSSPD are all distributed technologies. Even if some of the nodes fail, the availability of the whole scheme will not be affected. More importantly, the BitTorrent protocol adopted by IPFS can enjoy a high throughput only by requiring paying a small number of fees to incentive storage nodes. Simultaneously, the EOS blockchain is free to users, only the DO needs to mortgage some system tokens in exchange for storage and CPU resources, and these tokens can also be redeemed.(5) User-Centric. In our proposed scheme, the DO can generate public parameters and the system master key and generate and distribute the private keys for DUs according to their attributes. Moreover, the DO can formulate access policies arbitrarily to assign and revoke the permission of DUs. All of these are controlled by the DO without any trusted third party. In this manner, the DO has complete control over his shared data.(6) Identity Authentication. The user generates his identity in the blockchain through an asymmetric encryption algorithm with generating key pairs, whose cost is too low. In our proposed scheme, since the uid is embedded in the ciphertext of CP-ABE as an attribute, the DUs may register a large number of uids and use different uids to search and decrypt the shared data, which increases the burden of the DO. In order to prevent such attacks, BSSPD requires identity authentication. Before applying for registration, the DU needs to perform a PoW, which is similar to Bitcoin mining. The DO can adjust the difficulty of PoW according to the total number of DUs in the system. User management and identity authentication are carried out on the blockchain, and only authenticated users can perform operations. These are all executed in Smart Contract ensuring transparency and security.


## 6.1.1. Correctness

LetL=x∣ρx∈ω,uid∉Rρx, then ω′=ρxx∈L denote the attributes set of the DU that has not been revoked. Assume that ω′ still satisfies the access policy Al×k,ρ; for any x from 1 to l, then
(21)Dx,1=∏j=1lρxegrρxYρx,2,uuidjhρxηx,jeuuidhρxrρxYρx,3,gηx,j1/uid−uidj=eg,u−rρx∑j=1lρxηx,j=eg,g−arρxλx,Dx,2=egαr+tρxrρx+arρxYρx,1,gλxegrρxYρx,2,Tρxλx=eg,gαr+tρxrρx+arρxλx−tρxrρxλx=eg,gαr+arρxλx,M′=KF∣hreflocation=C0·1eK0,C1·∏x∈LDx,1Dx,2μx=Meg,gαs·1egα+αr,gs·eg,gαr∑x∈Lλxμx=Meg,gαs·1egα+αr,gs·eg,gαrs=M.After the proof, the data-related informationM can be decrypted by the DU.


## 6.1.2. Security Analysis

The CP-ABE algorithm used in this paper is based on the scheme [37], referring to the revocation idea in [35] that introduces a revocation list for each attribute. The scheme [37] has proved to be completely secure. The detailed proof process can refer to the security analysis in [37], which is based on the standard model, and the security depends on three static assumptions.This paper focuses on security data sharing based on blockchain. The security of CP-ABE is not within the main scope of this article. We will conduct a brief analysis of the security after adding an attribute revocation mechanism to the scheme [37].If an adversaryA can win the game with a nonnegligible advantage in the security model in [37], he must be able to calculate eg,gαs. To obtain such a pairing, the adversary needs to utilize K0=ga+rα in the private key and C1=gs in the ciphertext, both of which can get eg,gαseg,gαrs. This means that A needs to get eg,gαrs. Then, A needs to get Dx,1 and Dx,2 corresponding to each attribute and get eg,gαrλx by calculation. If A does not satisfy the challenge attributes, he cannot obtain the correct attribute keys to calculate eg,gαrλxconforming to the access policy and recover eg,gαrs.For collusion attacks, when generating private keys for eachDU, a random element r is contained in K0 and random elements ri and Yi,1,Yi,2,Yi,3 are added to the attributes, so that different DUs cannot combine their private keys to launch attacks.The attribute private keyKi,3=uuidhiriYi,3 which is related to the revocation contains the DU’s identity information uid. When Rρx≠∅, each uidj∈Rρx in the revocation list contains Cx,j,1=gηx,j and Cx,j,2=uuidjhρxηx,j, which need to be eliminated when decrypting. 1/uid−uidj is used when eliminating. If uid is in the revocation list, 1/uid−uidj will not be calculated to achieve the purpose of revoking the attribute j of uid.


## 6.1.3. Other Security Problem

(1) Data Security. Data security includes the confidentiality, integrity, and availability of the shared data. In our scheme, the large-capacity sharing data of the DO is encrypted using an efficient asymmetric encryption algorithm such as AES and uploaded to IPFS. The IPFS will split the encrypted data and store them on different IPFS nodes in a distributed manner. The access will be routed through the dynamic hash table maintained by each node, and a certain redundancy mechanism will ensure fault tolerance. Besides, IPFS also provides version control like Git. Thus, data encryption and storage in blocks ensure the confidentiality of the shared data. The integrity is guaranteed by dynamic hash table routing, and the tampered data blocks will not be available. The redundant storage and incentive mechanisms of IPFS ensure that users can access their data at any time. As long as IPFS is secure, then the data stored on it in our scheme is secure.(2) Privacy Analysis. In a data-sharing system, privacy includes the content of the DO’s shared data and the traces of the DU when using the data. In our scheme, the DO will encrypt the address of the shared data and the corresponding decryption key with CP-ABE according to the established access policy. Then, the ciphertext is stored on the blockchain, and only the DUs whose attribute set satisfies the access policy can obtain the data. The content of the data will not be leaked. For the traces generated by DUs, we encrypt the keywords corresponding to the sharing data. The DU invoked the trapdoor function to calculate the search token for the keyword that he needs to retrieve and then uses the search token for retrieving on the blockchain without revealing any information he wants. More importantly, the user’s identity is represented in the form of an address on the blockchain, and the real information of the user will not be exposed.(3) Fine-Grained Access Control. In our scheme, the fine-grained access control of shared data is realized by CP-ABE. The DO can make different access policies through LSSS and assign different attributes to DUs. Meanwhile, fine-grained access control should also include fine-grained revocation. The proposed scheme draws on the identity-based broadcast encryption scheme, in which the DO assigns a unique uid for each DU, and the uid will be used as a user attribute, embedded in the ciphertext together with the general attributes. Each general attribute in the ciphertext carries a revocation list, and the DU whose uid in this list no longer has the corresponding attribute, so that it achieves the purpose of directly revoking a DU’s attribute.(4) Avoid a Single Point of Failure. Compared with traditional cloud storage solutions, there is no centralized third party in our proposed scheme. Blockchain and IPFS used in BSSPD are all distributed technologies. Even if some of the nodes fail, the availability of the whole scheme will not be affected. More importantly, the BitTorrent protocol adopted by IPFS can enjoy a high throughput only by requiring paying a small number of fees to incentive storage nodes. Simultaneously, the EOS blockchain is free to users, only the DO needs to mortgage some system tokens in exchange for storage and CPU resources, and these tokens can also be redeemed.(5) User-Centric. In our proposed scheme, the DO can generate public parameters and the system master key and generate and distribute the private keys for DUs according to their attributes. Moreover, the DO can formulate access policies arbitrarily to assign and revoke the permission of DUs. All of these are controlled by the DO without any trusted third party. In this manner, the DO has complete control over his shared data.(6) Identity Authentication. The user generates his identity in the blockchain through an asymmetric encryption algorithm with generating key pairs, whose cost is too low. In our proposed scheme, since the uid is embedded in the ciphertext of CP-ABE as an attribute, the DUs may register a large number of uids and use different uids to search and decrypt the shared data, which increases the burden of the DO. In order to prevent such attacks, BSSPD requires identity authentication. Before applying for registration, the DU needs to perform a PoW, which is similar to Bitcoin mining. The DO can adjust the difficulty of PoW according to the total number of DUs in the system. User management and identity authentication are carried out on the blockchain, and only authenticated users can perform operations. These are all executed in Smart Contract ensuring transparency and security.


## 6.2. Experiments and Performance Analysis of BPSSD

### 6.2.1. Functional Comparison

We compared the scheme proposed in this article with the recent blockchain-based data-sharing models from the following aspects, including security and privacy, identity management, fine-grained access control, immediate access revocation, and ciphertext keyword retrieval, as shown in Table2.Table 2
Functional comparison between BSSPD and other blockchain-based data-sharing scheme.
No.BSSPDRef. [18]Ref. [21]Ref. [28]Security and privacy√√√√Identity management√×××Fine-grained access control√××√Immediate access revocation√×××Keyword ciphertext retrieval√××√From the comparison in the table, it can be concluded that due to the blockchain’s decentralized and trustless nature, the data-sharing models based on blockchain allowDOs to formulate access control policies for their data on-chain, so they all can guarantee security and privacy. Early schemes like Ref. [18] mostly only described the model’s outline without the specific implementation details. Generally, they only describe how blockchain can benefit security and privacy during the sharing, so the function is relatively simple. Reference [21] implemented a role-based access control model on the blockchain, but it turns out that RBAC is not suitable for implementing fine-grained access control and revocation in a distributed environment. Reference [28] utilized CP-ABE to achieve fine-grained access control, but it does not achieve permission revocation. However, in the access control scheme based on CP-ABE, an immediate access revocation is indispensable.In our proposed scheme, we utilized CP-ABE to achieve fine-grained access control and realized the identity management ofDUs. The DO assigns and manages unique uids and attributes for registered DUs. Maintaining a revocation list for each attribute in the ciphertext can directly revoke a particular attribute of a DU without updating others’ keys. BSSPD uses ciphertext keyword search to protect the privacy of DUs on-chain. Therefore, our proposed scheme has better applicability and usability.


### 6.2.2. Storage Analysis

BSSPD is a user-centric data-sharing scheme based on the EOS blockchain, and it stores the public system parameters, user information, and data-related information in the persistent database of Smart Contract. Because the storage resource on-chain is valuable and the acquisition of RAM in the EOS blockchain requires mortgaging system tokens, so it is necessary to analyze the size of the data stored in the Smart Contract.We first define some symbols; we set∣G1∣, ∣G2∣, ∣Gp1∣, ∣Gp2∣ to represent the bit length of an element in group G1,G2,Gp1, and Gp2, respectively. Let ∣ZN∣ be the bit length of an element in filed ZN, ∣KAES∣ be the bit length of a key of AES algorithm, and ∣Skcom∣ and ∣Pkcom∣ be the bit length of private key and public key of ECC, respectively; |S| denote the number of attributes in system, and Ksearch denote the bit length of a secret key of pseudorandom function F.According to the experiment simulation in our scheme, we set∣G1∣=∣G2∣=∣Gp1∣=∣Gp2∣=1024bits;∣ZN∣=128bits;∣KAES∣=256 bits;∣Skcom∣=256 bits;∣Pkcom∣=272bits;∣Ksearch∣=128bits; the bit length of account, uid, fid, and search tokentkwto be 64; and the bit length of an IPFS address to be 256. The storage overhead of BSSPD at each phase varies with the number of attributes which is shown in Figure 3.Figure 3
Storage overhead of BSSPD at each phase varies with the number of attributes.In our proposed scheme, there are three operations that interact with the blockchain to store data in the Smart Contract, which are as follows:(1)
InitializationTheDO uploads the system public parameters to the Smart Contract; the storage overhead is
(22)∣ZN∣+∣G1∣+2∣Gp1∣+∣S∣2∣Gp1∣=3200+2048∣S∣bits.(2)
RegistrationTheDU uploads information to the Smart Contract when applying for registration, and the DO assigns a unique uid and private keys for the DU. The storage overhead is
(23)account+uid+Pkcom+∣Ksearch∣+Gp1+3Gp1S=1552+3072Sbits.(3)
Encryption and uploadingTheDO uploads data-related information and the private keys of the DU to the Smart Contract, as well as the indices for the DU. The storage overhead is
(24)KAES+address+2Gp1+2Gp1S+2Gp1R+fid+tkw+fid+account=2752+2048S+2048R.For simplicity, the figure shows that the storage overhead varies with the number of attributes when there are 10DUs in the revocation list. As the number of DUs in the revocation list and the relevant DUs increases, the storage overhead will also increase to a certain extent.The RAM in the EOS blockchain is obtained by collateralizing system tokens, and the current price is 0.05 EOS/KB. TheDO can purchase RAM according to the scale of his system. Unlike Ethereum transactions that need to consume ETH as gas, the tokens mortgaged when acquiring RAM in EOS can still be redeemed at the original price. Above all, the proposed scheme is feasible and practical.


### 6.2.3. Performance Analysis

As we all know, the computing resource on the blockchain is also precious, and the computational efficiency of the existing blockchains is often criticized. For example, Bitcoin takes 10 minutes to produce a block. Ethereum has dramatically improved the block generation time, but it also takes about 15 seconds. In this section, we will conduct experiments on our proposed scheme and evaluate the scheme’s performance and user scale.We used 5 nodes to build an EOS private chain in a laboratory environment. The 5 nodes we chose were all MacBook Pro (2017) with Intel (R) Core (TM) i5 CPU that clocks at 3.1 GHz and has 16.0 GB of RAM. The version of the EOS blockchain we chose is v2.0.6. The code of the indices of the two tables related to the sharing data in our Smart Contract is as follows:Code 1: The code of the tables in Smart Contract.
typedef eosio::multi_index<"sharedatas"_n, my_data> data_table;ttypedef eosio::multi_index<"searchindexs"_n, s_index, indexed_by<"username"_n,const_mem_fun<s_index, uint64_t, &s_index::by_secondary>>,indexed_by <"searchtoken "_n, const_mem_fun<s_index, checksum256, &s_index::by_thirdary>>,indexed_by<"fid"_n, const_mem_fun<s_index, uint64_t, &s_index::by_forthary>>> search_table;In our scheme’s initialization phase, the operation on-chain is to set and update the public system parameters. The previous section shows that the storage overhead will continue to expand as the attributes increase. However, it can be seen from Figure4 that as the attributes increase, the computing overhead will not be significantly affected in this phase.Figure 4
Computing overhead of the initialization phase varies with the number of attributes.In the encryption and uploading phase of our scheme, the operations that need to be performed on-chain are uploading the data-related information to Smart Contract and establishing the keyword indices for the data-relatedDUs. As shown in Figure 5, the increase in the number of attributes will not have too much influence on the computing overhead of AddData. In the case of a different number of attributes, the computing overhead of AddData is generally stable. What impacts the computing overhead of AddData is the scale of DUs, especially the number of DUs related to the sharing data. It can be seen from Figure 5 that the computing overhead of 500 DUs is obviously higher than that of 100 DUs, and the time cost is mainly spent on establishing search indices for the relevant DUs.Figure 5
Computing overhead of the AddData varies with the number of attributes.Since BSSPD sets the search token as a secondary index of thesearch_table in the Smart Contract, no matter how many pieces of index data exist in the system, the time complexity of retrieving according to the search token is O1. As shown in Figure 6, when there are 10 billion pieces of index data, the search time is not much different from that of 1 million, and the search time is in milliseconds.Figure 6
Computing overhead of the search phase varies with the number of rows of index information.The deletion of a certain data in our scheme is to remove the data-related information and the indices to the data. As shown in Figure7, as the number of data-related DUs continues to expand, the computing overhead of deletion will increase too. The main time cost is spent on deleting the search indices to the data.Figure 7
Computing overhead of the remove varies with the number of DUs associated with the shared data.Since only the ciphertext data needs to be updated according to the shared data’s primary key id when revoking aDU’s attribute of a specific shared data, there is no need to operate on the relevant indices, and its computing overhead is similar to set and update the public system parameters in the initialization phase, which is stable.In summary, in our proposed scheme, the total number of attributes will not impact much on the computing overhead on-chain. According to experience, it only affects operations off-chain, such as key generation, encryption, and decryption. However, the expansion of the user scale will increase the time cost of some operations. Specifically, it is increased with the number ofDUs related to certain shared data because search indices will be established. When the related search indices of a specific data increase to 500, the computing overhead is still in milliseconds. For all operations on-chain in our scheme, the computing overhead is less than 100 milliseconds. The configuration of the EOS main network’s block producer is much better than the laptop we use, so when the contract is deployed on the main network of EOS, the computing overhead will be much lower than that of our simulation. Now, since EOS takes 0.5 seconds to generate a block, our scheme’s operation will be confirmed soon after execution. Therefore, the experiment has proved that our scheme has a good performance.


## 6.2.1. Functional Comparison

We compared the scheme proposed in this article with the recent blockchain-based data-sharing models from the following aspects, including security and privacy, identity management, fine-grained access control, immediate access revocation, and ciphertext keyword retrieval, as shown in Table2.Table 2
Functional comparison between BSSPD and other blockchain-based data-sharing scheme.
No.BSSPDRef. [18]Ref. [21]Ref. [28]Security and privacy√√√√Identity management√×××Fine-grained access control√××√Immediate access revocation√×××Keyword ciphertext retrieval√××√From the comparison in the table, it can be concluded that due to the blockchain’s decentralized and trustless nature, the data-sharing models based on blockchain allowDOs to formulate access control policies for their data on-chain, so they all can guarantee security and privacy. Early schemes like Ref. [18] mostly only described the model’s outline without the specific implementation details. Generally, they only describe how blockchain can benefit security and privacy during the sharing, so the function is relatively simple. Reference [21] implemented a role-based access control model on the blockchain, but it turns out that RBAC is not suitable for implementing fine-grained access control and revocation in a distributed environment. Reference [28] utilized CP-ABE to achieve fine-grained access control, but it does not achieve permission revocation. However, in the access control scheme based on CP-ABE, an immediate access revocation is indispensable.In our proposed scheme, we utilized CP-ABE to achieve fine-grained access control and realized the identity management ofDUs. The DO assigns and manages unique uids and attributes for registered DUs. Maintaining a revocation list for each attribute in the ciphertext can directly revoke a particular attribute of a DU without updating others’ keys. BSSPD uses ciphertext keyword search to protect the privacy of DUs on-chain. Therefore, our proposed scheme has better applicability and usability.


## 6.2.2. Storage Analysis

BSSPD is a user-centric data-sharing scheme based on the EOS blockchain, and it stores the public system parameters, user information, and data-related information in the persistent database of Smart Contract. Because the storage resource on-chain is valuable and the acquisition of RAM in the EOS blockchain requires mortgaging system tokens, so it is necessary to analyze the size of the data stored in the Smart Contract.We first define some symbols; we set∣G1∣, ∣G2∣, ∣Gp1∣, ∣Gp2∣ to represent the bit length of an element in group G1,G2,Gp1, and Gp2, respectively. Let ∣ZN∣ be the bit length of an element in filed ZN, ∣KAES∣ be the bit length of a key of AES algorithm, and ∣Skcom∣ and ∣Pkcom∣ be the bit length of private key and public key of ECC, respectively; |S| denote the number of attributes in system, and Ksearch denote the bit length of a secret key of pseudorandom function F.According to the experiment simulation in our scheme, we set∣G1∣=∣G2∣=∣Gp1∣=∣Gp2∣=1024bits;∣ZN∣=128bits;∣KAES∣=256 bits;∣Skcom∣=256 bits;∣Pkcom∣=272bits;∣Ksearch∣=128bits; the bit length of account, uid, fid, and search tokentkwto be 64; and the bit length of an IPFS address to be 256. The storage overhead of BSSPD at each phase varies with the number of attributes which is shown in Figure 3.Figure 3
Storage overhead of BSSPD at each phase varies with the number of attributes.In our proposed scheme, there are three operations that interact with the blockchain to store data in the Smart Contract, which are as follows:(1)
InitializationTheDO uploads the system public parameters to the Smart Contract; the storage overhead is
(22)∣ZN∣+∣G1∣+2∣Gp1∣+∣S∣2∣Gp1∣=3200+2048∣S∣bits.(2)
RegistrationTheDU uploads information to the Smart Contract when applying for registration, and the DO assigns a unique uid and private keys for the DU. The storage overhead is
(23)account+uid+Pkcom+∣Ksearch∣+Gp1+3Gp1S=1552+3072Sbits.(3)
Encryption and uploadingTheDO uploads data-related information and the private keys of the DU to the Smart Contract, as well as the indices for the DU. The storage overhead is
(24)KAES+address+2Gp1+2Gp1S+2Gp1R+fid+tkw+fid+account=2752+2048S+2048R.For simplicity, the figure shows that the storage overhead varies with the number of attributes when there are 10DUs in the revocation list. As the number of DUs in the revocation list and the relevant DUs increases, the storage overhead will also increase to a certain extent.The RAM in the EOS blockchain is obtained by collateralizing system tokens, and the current price is 0.05 EOS/KB. TheDO can purchase RAM according to the scale of his system. Unlike Ethereum transactions that need to consume ETH as gas, the tokens mortgaged when acquiring RAM in EOS can still be redeemed at the original price. Above all, the proposed scheme is feasible and practical.


## 6.2.3. Performance Analysis

As we all know, the computing resource on the blockchain is also precious, and the computational efficiency of the existing blockchains is often criticized. For example, Bitcoin takes 10 minutes to produce a block. Ethereum has dramatically improved the block generation time, but it also takes about 15 seconds. In this section, we will conduct experiments on our proposed scheme and evaluate the scheme’s performance and user scale.We used 5 nodes to build an EOS private chain in a laboratory environment. The 5 nodes we chose were all MacBook Pro (2017) with Intel (R) Core (TM) i5 CPU that clocks at 3.1 GHz and has 16.0 GB of RAM. The version of the EOS blockchain we chose is v2.0.6. The code of the indices of the two tables related to the sharing data in our Smart Contract is as follows:Code 1: The code of the tables in Smart Contract.
typedef eosio::multi_index<"sharedatas"_n, my_data> data_table;ttypedef eosio::multi_index<"searchindexs"_n, s_index, indexed_by<"username"_n,const_mem_fun<s_index, uint64_t, &s_index::by_secondary>>,indexed_by <"searchtoken "_n, const_mem_fun<s_index, checksum256, &s_index::by_thirdary>>,indexed_by<"fid"_n, const_mem_fun<s_index, uint64_t, &s_index::by_forthary>>> search_table;In our scheme’s initialization phase, the operation on-chain is to set and update the public system parameters. The previous section shows that the storage overhead will continue to expand as the attributes increase. However, it can be seen from Figure4 that as the attributes increase, the computing overhead will not be significantly affected in this phase.Figure 4
Computing overhead of the initialization phase varies with the number of attributes.In the encryption and uploading phase of our scheme, the operations that need to be performed on-chain are uploading the data-related information to Smart Contract and establishing the keyword indices for the data-relatedDUs. As shown in Figure 5, the increase in the number of attributes will not have too much influence on the computing overhead of AddData. In the case of a different number of attributes, the computing overhead of AddData is generally stable. What impacts the computing overhead of AddData is the scale of DUs, especially the number of DUs related to the sharing data. It can be seen from Figure 5 that the computing overhead of 500 DUs is obviously higher than that of 100 DUs, and the time cost is mainly spent on establishing search indices for the relevant DUs.Figure 5
Computing overhead of the AddData varies with the number of attributes.Since BSSPD sets the search token as a secondary index of thesearch_table in the Smart Contract, no matter how many pieces of index data exist in the system, the time complexity of retrieving according to the search token is O1. As shown in Figure 6, when there are 10 billion pieces of index data, the search time is not much different from that of 1 million, and the search time is in milliseconds.Figure 6
Computing overhead of the search phase varies with the number of rows of index information.The deletion of a certain data in our scheme is to remove the data-related information and the indices to the data. As shown in Figure7, as the number of data-related DUs continues to expand, the computing overhead of deletion will increase too. The main time cost is spent on deleting the search indices to the data.Figure 7
Computing overhead of the remove varies with the number of DUs associated with the shared data.Since only the ciphertext data needs to be updated according to the shared data’s primary key id when revoking aDU’s attribute of a specific shared data, there is no need to operate on the relevant indices, and its computing overhead is similar to set and update the public system parameters in the initialization phase, which is stable.In summary, in our proposed scheme, the total number of attributes will not impact much on the computing overhead on-chain. According to experience, it only affects operations off-chain, such as key generation, encryption, and decryption. However, the expansion of the user scale will increase the time cost of some operations. Specifically, it is increased with the number ofDUs related to certain shared data because search indices will be established. When the related search indices of a specific data increase to 500, the computing overhead is still in milliseconds. For all operations on-chain in our scheme, the computing overhead is less than 100 milliseconds. The configuration of the EOS main network’s block producer is much better than the laptop we use, so when the contract is deployed on the main network of EOS, the computing overhead will be much lower than that of our simulation. Now, since EOS takes 0.5 seconds to generate a block, our scheme’s operation will be confirmed soon after execution. Therefore, the experiment has proved that our scheme has a good performance.


## 7. Conclusion

In the AI-driven era, a user-centered sharing model is proposed to open data while ensuring data privacy. We combined blockchain, CP-ABE, and IPFS to propose a blockchain-based security data-sharing scheme with fine-grained access control and permission revocation. In our proposed scheme, theDO encrypts his data and uploads it to IPFS, then encrypts the returned address and decryption key by CP-ABE. Only DUs whose attributes satisfy the access policy can decrypt and obtain the data. There is no centralized node in the scheme, and the DO has complete control over his shared data, which promises privacy and security. To achieve the goal, we have implemented our scheme on the EOS blockchain. The security and performance analysis proves that our scheme is feasible and practical and has a good performance. We can also add a cryptocurrency to introduce an economic system for data sharing and further enrich our scheme’s functions. At the same time, there are many shortcomings in our scheme. For example, the CP-ABE we designed with permission revocable does not have the best performance. There are also many types of research on CP-ABE [38–42]. We can use a CP-ABE with better performance to improve our scheme. Besides, for the searchable encryption algorithm used in our scheme, the DO needs to distribute a secret key for each DU and store it on-chain. It also needs to maintain large amounts of indices for each shared data, which can be further optimized. At present, some researchers have proposed using blockchain to solve the fairness problem in searchable encryption algorithm [43–47]. In the future, we will study and discuss the endowment of a better ciphertext searchable algorithm to further optimize our scheme. Simultaneously, to make our scheme more practical, we can combine some studies [48–52] with ours and put forward a data governance scheme that is more in line with the practical application.



---

*Source: 6658920-2021-02-20.xml*