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.

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 CSP

From 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 performance

The rest of this paper is organized as follows. Section 2 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

Let ( and are distinct primes), and be cyclic groups of order , and be a generator of . We call as a bilinear pairing, if it is a map with the following properties: (1)Bilinear: for all and (2)Nondegenerate: there exists , such that (3)Computable: There is an efficient algorithm to compute for all

Let and denote the subgroups of with order and . Then, ; and are the generators of and . Let and denote the generators of and . For all random elements and , then we have ; because of that, .

3.2. Linear Secret-Sharing Scheme (LSSS)

Let be a set of parties, and denote an access structure in which is an access matrix with mapping its rows. A linear secret-sharing scheme (LSSS) consists of two polynomial-time algorithms: (1): to share a secret value , it randomly chooses and let . Let denote the vector as the th row in matrix , and then, the share belongs to party (2): the algorithm takes as input; let . Then, a set of recovery coefficients can be calculated effectively according to , so that . Research has shown that the monotonic access structure is equivalent to the LSSS. Let be an access structure and be a set of authorization; then makes that . 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)

Initialization 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 , to generate the system public key PSK and the system master key MSK. (2)

Key generation algorithm generates a private key USK for the data user according to the system public key PSK, the system master key MSK, and the data user’s attributes . (3)

Encryption algorithm is executed by the data owner. The algorithm inputs the system public key PSK, the message M to be encrypted, and the access control structure associated with the access policy and outputs the ciphertext CM. (4)

Decryption algorithm is executed by the data user. The inputs of the algorithm are the system public key PSK, 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 .

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 by . 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]:

denotes the reference to the block number and header of a block which generated recently to prevent transactions from appearing on a forked chain. 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. represents the operation to be performed, where is the name of the Smart Contract to be invoked, is a method in Smart Contract to be called, is used to verify whether the user who initiated the transaction has the permission, and 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: (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. Table 1 shows some symbols and abbreviations involved in this paper.

4.1. System Model of BSSPD

Our proposed scheme BSPPD consists of four components: IPFS, blockchain, data owner, and data user. The DO 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 the DO 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. The DO 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: the DU 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 data

The system model of the proposed scheme is shown in Figure 2.

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)The DO 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)The DO generates the system master key and system public key locally and stores the system public key in DSContract(iii)The DU 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)The DO 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)The DU obtains the ciphertext information of the keys and decrypts them with his private communication key(vi)The DO 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)The DO 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)The DO selects keywords to generate ciphertext indices for data-related DUs and then invokes the DSContract to store the indices and data-related information(ix)The DU selects a keyword of the data to be retrieved and uses the trapdoor function to generate a search token(x)The DU 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)The DU obtains the search results from DSContract(xiii)The DU 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 the DO wants to revoke a DU’s attribute to a certain shared data, he can add this DU’s uid to the revocation list of attribute . 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 the DO 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 , which was executed by the DO. The algorithm’s input is a security parameter , 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 the DU 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 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 and the search key of the DU. The DO executes and invokes UMContract to store 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 the DO 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 and executed by the DO. It consists of the following three substeps:

Step 1. .

The input of the data encryption algorithm is the sharing data , and outputs are the key of a symmetric encryption algorithm and an IPFS address . The whole process is to randomly select a private key and encrypt to get the ciphertext CF and then upload CF to IPFS to get the address . The corresponding step in the system flowchart is (vi).

Step 2. .

The algorithm is used to encrypt the address, and the key whose inputs are the decryption key , the IPFS address , the access policy , a revocation list for each attribute in , and system public parameters PK. Its output is the ciphertext of and encrypted with CP-ABE. The corresponding step in the system flowchart is (vii).

Step 3. .

In the algorithm that generates the ciphertext keyword index, the DO selects a keyword kw of data , which is used as inputs together with the search secret key of a relevant DU. The output is a search token and the corresponding step in the system flowchart is (viii).

4.2.4. Search Phase

The main function of the search phase is that a DU 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. .

Generate search token algorithm, which is executed by the DU. The DU selects the keyword related to the shared data he wants to search, together with his as inputs, and the output is the search token corresponding to the keyword. This corresponds to step (ix) in the system flowchart.

Step 2. .

The search algorithm is executed by DSContract, which uses the search token 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 that DUs 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 which was executed by the DU. The inputs of the algorithm are the private attribute key of the DU, the data-related information , and the public system parameters PK. It outputs the decryption key and the address . Because the access policy and the revocation list of each attribute are embedded in the ciphertext, if the attribute set of the DU that have not been revoked still satisfies access policy , he will decrypt and obtain and successfully. In this way, the DU could download from IPFS and decrypt it to obtain the data . 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 the DO 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 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 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 , 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)

The UMContract is composed of five function interfaces: SetTarget, GetUserByUid, Apply, Register, and Authenticate. We initialize UMContract as follows.

Let three-tuple denote a DU, and create a multi_index named table_user for it in which is an EOS account of the DU, uid is the unique ID assigned by the DO, and is a public key of the DU used for communication with the DO. Let 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 invoker

5.1.2. Date Sharing Contract (DSContract)

The DSContract is composed of six function interfaces: SetPK. SetSK, AddData, PolicyUpdate, Search and EndSearch, and Remove. We initialize DSContract as follows.

Let PK denote the system public parameters. Let two-tuple (, 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 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, , , fid) be an index of DU related to shared data in which is the EOS account of DU, 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 , , 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, , )), 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, )), 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, )), 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 DO

5.2. Concrete Construction of BSSPD

In this section, we will show the concrete construction of our scheme, including the algorithms that the DO and DUs need to execute at each phase and their interactions with the EOS blockchain. Our initialization is as follows.

Let ( and are distinct primes) and be cyclic groups of order . Let and denote the subgroups of with order and . Let be a bilinear pairing and be the set of all attributes. Let be a pseudorandom function, where , and be the uid set of all DUs obtained from UMContract. (1)

For each attribute , the algorithm first randomly picks two elements and computes . Next, it picks randomly, then computes .

The public key is PK:

The system master key is MSK:

Among them, and are used for calculations related to attributes, and are used for calculations related to attribute revocation, u is used for calculations related to DU’s identity, and is used for randomization of DU’s private key.

Then, send the following transaction to EOS blockchain and store the public key in the DSContract: (2)

Firstly, send the following transaction to EOS blockchain to obtain the DU’s information including , , and uid from UMContract:

After that, the algorithm randomly chooses and computes . For each attribute , randomly pick and , then compute the following:

Let , then DU’s attribute private key will be . 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 key for search where . Let , and send the following transaction to set and update the DU’s private keys: (3)

The algorithm randomly chooses a private key of , and encrypts the sharing data , then uploads the CF to the IPFS network, and the returned address is , set .

The algorithm first randomly picks and lets . For to , it calculates where is the vector corresponding to the th row of . Assume that in which the number of revocable users is variable. For each , it randomly chooses a , where and , and then computes

For each attribute , it computes that

When , it computes for each revoked as follows:

The ciphertext CF is set to (4)

The algorithm calculates a search token for a keyword kw of the sharing data.

After that, it will send the following transaction to EOS blockchain to publish the data-related information and add the indices for the relevant DUs: (5)

The DU obtains from the DSContract and decrypts it with his own private key.

Then, it calculates the search token corresponding to . (6)