BC-PC-Share: Blockchain-Based Patient-Centric Data Sharing Scheme for PHRs in Cloud Computing

1  Introduction

A Personal Health Record (PHR) refers to an electronic record collection administratered by the patients themselves. It commonly includes healthcare information and medical information obtained from a variety of sources, such as multiple healthcare providers (e.g., hospitals) and the patients themselves (e.g., wearable devices) [1,2]. More specifically, PHR usually contains personal information, drug history (including dosages), history of drug allergy, records of previous illnesses and surgeries, chronic health problems, such as high blood pressure, family history, immunization records, lab test results, and other personal health information. A PHR system demonstrates the potential benefits of reducing misunderstandings and mistakes, avoiding unnecessary double treatments, physical examinations and medical tests, and eliminating adverse drug events, and so on in healthcare. The PHR is a patient-centric tool that can help increase patients’ engagement to actively learn their own health status, easily track the course of treatment, and actively cooperate with the scientific medical treatment of the health care provider. With the assistance of PHR service, the quality of healthcare can be improved significantly. Given their enormous merits, PHR systems have attracted extensive interest worldwide. Cloud computing, as a resource provision platform, offers users mass storage space, powerful computing capability, and ubiquitous access service, which is like the traditional public utility, such as water and electricity [3]. In the pursuit of universal accessibility and low cost, in practice, the PHR service providers usually resort to the cloud server to store and share their PHRs data. Although the great potential benefits are indisputable, the adoption of PHRs data sharing via the cloud computing is hindered by data security and data privacy concerns in the healthcare domain, because the PHRs include a large amount of sensitive information of the patient. For the sake of ensuring the security of the PHRs, a large number of relevant schemes have been put forward, such as [4–8]. Nevertheless, these schemes commonly rely on a third trust authority which is difficult to find in reality, and are faced with the single point of failure issue. These security challenges urge further consideration and exploration.

Fortunately, the emerging blockchain technology can provide a promising and feasible solution for the secure sharing of PHRs data. The blockchain technology incorporates many promising characteristics such as decentralization, immutability, traceability, openness and anonymity. The intrinsic value of blockchain is to establish trust in a trustless distributed system without introducing any third trusted authority due to its unique features. In recent years, the blockchain technology has been envisioned as a significant innovation in information technology and aroused considerable interest in both the academic community and the industrial alliance. Over the past few years, sparked by the enormous achievements of blockchain in digital cryptocurrency, many scholars have endeavored to extend its application to various fields, such as Internet of Things [9–11], medical data sharing [12–15], cloud computing [16–18], and so forth.

1.1 Motivation and Contribution

Motivation. To achieve secure, efficient and flexible PHRs data sharing in multi-receiver settings, it is essential to identify the following potential attacks:

1) Unauthorized access. In a healthcare system, PHRs data requires maintenance in a secure and private environment. The patient should have complete control over his/her PHR data and only the users authorized by the patient can have the right to full or partial access to the patient’s PHRs data. Any unauthorized access should be prohibited. In practice, a passive adversary or malicious cloud server may eavesdrop on the sensitive PHRs data of patient for making profits or other evil purpose. All these malicious behaviors can pose a security threat of leaking the sensitive PHR information.

2) Integrity and consistency of shared data. An active malicious adversary may try to get unauthorized right to tamper the PHRs data before an authorized user (e.g., a doctor) can access them. This vicious active attack may lead to a misdiagnosis or a wrong treatment for the patient and cause serious harms to the patient’s health. What is even worse, this vicious behavior may cause the death of the patient. Therefore, it is of the utmost importance that the integrity and consistency of the shared sensitive PHRs data of the patient is ensured.

3) Efficient revocation and decryption. To take the advantage of the premium computational ability, we introduce transformation key technique to relieve the heavy computation burden of the data users by offloading computationally intensive operations to the cloud server without leaking any sensitive data nor compromising privacy. This is especially meaningful considering the increasing popularity of resource-limited mobile devices. In addition, the efficient revocation should also be considered.

To achieve the patient-centric data sharing in a multiple receiver setting, it is essential to utilize the fine-grained access control that can support multiple domain users for accessing the PHRs data simultaneously. For instance, the patient intends to share their PHRs data to a hospital for the purpose of gaining the services of diagnosis, examination, and healthcare. And the patient can share partial non-sensitive information with medical research institute for conducting scientific research to enhance the quality of healthcare for human beings. And the patient can also share relevant information with their medical insurance company for processing of medical insurance claims.

Driven by these demands, the attribute-based encryption (ABE) scheme is introduced to guarantee the confidentiality and fine-grained access control simultaneously. However, directly using the ABE mechanism will result in several security issues. Firstly, most of the existing ABE schemes do not support the consistency and integrity checking of the shared data, and that puts the data owner and/or user at a clear disadvantage, especially in medical field, as it can lead to a misdiagnosis or other event that could endanger the patient’s life. Secondly, currently, with the broad adoption of mobile devices, the utilization of the highly efficient user revocation and user decryption should be considered because most existing ABE schemes commonly involve heavy cryptographic operations.

Contribution. To fill the identified gaps, in this work, we employ the consortium blockchain technology to enhance the trustworthiness of each participant and propose a blockchain-based patient-centric data sharing scheme to achieve public verifiability, immutability, scalability and fine-grained PHRs data sharing in a multiple receiver setting. The main contributions of this work are listed as follows:

1) First, we devise a novel blockchain based system model for patient-centric secure data sharing of PHRs in cloud computing under a multiple receiver setting. In the system model, we conceptually categorize the receiver into three different domains: hospitals, medical research institutes, and medical insurance companies.

2) Second, the proposed BC-PC-Share scheme can not only ensure the integrity and consistency of the shared data via semi-trust cloud computing by adopting smart contracts to perform public consistency and integrity checking, but also achieve scalable and fine-grained access control and PHRs data sharing with multiple domain users by utilizing the ABE mechanism. Moreover, the envisaged scheme can significantly reduce the decryption cost by leveraging the transformation key technique and can achieve efficient user revocation by introducing time-controlled access (i.e., the patient indirectly revokes user’s access privileges by assigning the invalid period).

3) Finally, we present a concrete security analysis of the proposed BC-PC-Share scheme in terms of the correctness, CPA security, completeness, and efficient user revocation under the random oracle model. Moreover, we conduct a simulation experiment to evaluate the performance of our proposed BC-PC-Share solution. We also make a comparison of our blockchain based solution with several representative works and demonstrate that our scheme is both practical and efficient.

1.2 Paper Organization

The remainder of the paper is organized as follows. The related literatures are reviewed in Section 2. The background knowledge is presented in Section 3. The system framework of the BC-PC-Share scheme is modeled in Section 4. Following this, the concrete BC-PC-Share scheme is proposed in Section 5. Next, in Sections 6 and 7, security analysis and performance evaluation, are respectively conducted. Finally, the conclusion of this work is drawn in Section 8.

2  Related Work

In this section, we discuss the literature related to the PHRs sharing, including cloud-based PHRs sharing schemes and blockchain-based PHRs sharing schemes.

A. Cloud-Based PHRs Sharing Schemes

In 2013, Li et al. [4] proposed a patient-centric role-based framework for secure sharing of PHRs data in a cloud computing environment. Considering that the cloud server is not fully trusted, they adopted the ABE mechanism to achieve the confidentiality and secure sharing of PHRs data among different domain users simultaneously. Au et al. [5] suggested a general cloud-based framework for patients to fully control and securely share their sensitive PHRs data with users in the same domain and across domains. Xhafa et al. [7] proposed a multi-authority CP-ABE based PHRs data sharing scheme, which supports hidden access policy as well as the traceability and accountability of misbehaving PHR users. Despite the ABE scheme being very powerful and promising, it still suffers from a decryption efficiency weakness due to the fact that the traditional ABE based schemes involve many expensive pairing operations. To improve the decryption efficiency, many lightweight ABE data sharing schemes with outsourced decryption have been proposed [19–22]. Xiong et al. [19] proposed an A2B2E scheme with the features of hidden access policy, in which they utilized the verifiable outsourcing decryption technique for ABE and the technique of online/offline to reduce the computational cost. However, their scheme does not support user revocation. To enhance the computational efficiency on the user-side in a PHR system, Zhang et al. [6] devised a lightweight scheme called CCP-ABAC-UA. In their scheme, the PHR receivers can access PHRs with non-bilinear-pairing computation. Additionally, their scheme can support public auditing and user revocation.

B. Blockchain-Based PHRs Sharing Schemes

However, all the above-mentioned schemes suffer from the single point of failure issue. To facilitate sharing of PHRs data with a high level of confidence in the distribution setting, the blockchain technique is introduced as a potentially promising approach for building trustworthiness among different distributed institutions.

To improve the quality of medical diagnosis, Zhang et al. [23] utilized private blockchain and consortium blockchain technology to design a secure and privacy-preserving personal health information sharing (BSPP) system, in which by getting the trapdoors from the patient, enables the authorized doctor to have the privilege to search specific health records for certain patients. Thwin et al. [24] suggested a privacy-preserving access control model for secret PHRs data sharing, which supports granting and revoking access rights by incorporating the blockchain technology and proxy re-encryption (PRE) technique. Chen et al. [11] combined the searchable encryption technology with blockchain technology and proposed a blockchain-based searchable encryption scheme for eHealth data outsourced to the public cloud server, however, one of the critical concerning issues is that the cloud server is not fully reliable and not entirely trustworthy. Cao et al. [25] proposed a cloud-based secure eHealth scheme, named TP-EHR, to prevent the EHRs from any illegal tampering by adopting the blockchain technology, where a password-based authentication mechanism was introduced to resist password guessing attacks. Nagasubramanian et al. [26] proposed a KSIBC framework to guarantee the security and integrity of sensitive healthcare data between doctors and patients by leveraging blockchain technology. By combing the ABE and blockchain technology, Yang et al. [27] proposed an ABE keyword search scheme for blockchains, which can support users to search encrypted files over the blockchain according to their attributes. The above-mentioned blockchain-based eHealth data systems have a similar characteristic, that is, all of them do not use blockchain for storing eHealth data, while these schemes use blockchain for storing the metadata. Different from the previous schemes given above, Nagasubramanian et al. [26] and Al Omar et al. [28] store the healthcare data of patients in the blockchain directly and deploy it in the cloud computing environment.

3  Preliminaries

In this section, we present some background knowledge associated with this paper.

3.1 Blockchain

Blockchain contains continuously growing blocks, which are chronologically linked by using a set of cryptography techniques and the consensus algorithm, and thus forming a chain [29,30]. It is the underlying technology of the well-known Bitcoin which was originally developed by a mysterious person, named Satoshi Nakamoto in 2008 [31]. Essentially speaking, blockchain is a distributed publicly shared transaction ledger where transaction data is recorded permanently. As an innovative architecture, the blockchain system integrates many advanced technologies, such as a Peer-to-Peer (P2P) network, distributed ledger, and consensus mechanism as well as smart contracts. In a blockchain network, all the participating nodes are equal and collaborate with each other without the requirement of a trusted central party. Thus, it can eliminate the potential security risk of single point of failure (SPOF).

A block in blockchain is composed of two components: the block header and the block body, and the data structure of blocks is illustrated in Fig. 1. Each block in the blockchain contains a hash-pointer that points to the immediate prior block, and this basic structure produces one of the most prominent feature of the blockchain called immutability, i.e., once the data is verified by consensus nodes and stored in a blockchain, it cannot be permanently tampered with because of the irreversibility of cryptographic hash function. And the block body records the specific transaction data by using Merkle hash tree. With the time goes by, the new blocks are continuously generated and appended to the chain and once accepted by the consensus nodes, cannot be tampered with nor removed.

Figure 1: Data structure of blocks

According to the application scenarios and the access privilege, the blockchain can be divided into three categories: public blockchain, consortium blockchain, and private blockchain.

Public blockchain refers to a blockchain in which anyone around the world can access it at any time to read data, conduct transactions, and consent nodes. Public blockchains are generally regarded as “completely decentralized” architecture because there is no individual or institution that can control or tamper with the blockchain. The public blockchain generally relies on the incentive mechanism to encourage participants to compete for bookkeeping. For instance, the well-known Bitcoin and Ethereum are two typical applications of public blockchains.

Private blockchain refers to a blockchain whose write permission is controlled by an organization or institution, and the eligibility of participating nodes is severely restricted. The application scenario of private blockchain is generally the internal application of an enterprise, such as database management, and auditing.

Consortium blockchain refers to a blockchain that is managed by several institutions. Each institution runs one or more nodes. Consortium blockchain is generally considered as a “partially decentralized” platform because the data only allows participations within the system to read, write, and send transactions, and together record transaction data.

3.2 Smart Contracts

Smart contract [32] is a terminology used to describe some special script codes deployed on the blockchain that automatically executes all or parts of an agreement on all the nodes of the blockchain network among distributed untrustworthy entities without the involvement of a third trusted central party if a predefined condition is fulfilled. Smart contract is commonly an indispensably key component of the applications based on blockchain or distributed ledger technology. When predetermined conditions are met, the smart contracts automatically trigger the execution of an agreement. Moreover, they can also trigger the next action to support automatic continuous execution, namely, to form a workflow. To prevent contract from being tampered with, the smart contracts are copied to each node of the blockchain network. To further prevent contracts from being tampered with, each node also holds a copy of the smart contracts and executes the codes. The execution result of the smart contract is visible to each participant node and is verified by all participants. Only when all the participants agree on the result will they update their ledger. By this mechanism, it can yield a correct, immutable, and credible result, and further can avoid any disputes regarding the execution result of smart contracts. Thus, the smart contract can be regarded as a public trusted mechanism for correctness, but not for privacy [11].

3.3 Access Structure

It should be noted that, in our work, the role of the parties is represented by the attributes. Therefore, the access structure A will consist of the authorized sets of attributes. From now on, unless otherwise indicated, an access structure is referred to a monotone one in our context.

3.4 Access Tree

An access tree is used to describe an access structure [33]. In this subsection, a brief description of an access policy tree is given below:

T: This represents an access tree representing the access structure.

x: This represents a node in the access tree T, which can be categorized into two types: Leaf node and non-leaf node (interior node). Each non-leaf interior node is represented by a threshold gate, such as “AND” or “OR” threshold gate while each leaf node is associated with an attribute.

numx: This represents the number of children of the node x.

kx: This represents the threshold value of node x, where 0≤kx≤numx. If kx=1 and x is an interior node, it means that the threshold is an “OR” gate. If kx=numx and x is an interior node, it means that the threshold is an “AND” gate. In particular, the threshold value of each leaf node x is defined as kx=1.

parent(x): The function parent(x) is used to return the parent of the node x in the access tree.

index(x): The function index(x) is used to return a unique number associated with the node x, where the number is uniquely assigned to x in a certain manner.

att(x): The function att(x) is used to return an attribute associated with the leaf node x in the access tree.

Tx: This represents the sub-tree for T rooted at the node x in the access tree.

If an attribute set S matches the sub-access-tree Tx, it is represented as Tx(S)=1. Tx(S) outputs 1 if and only if the following conditions are satisfied:

(1)   If x is a leaf node, Tx(S)=1 if and only if att(x) ∈ S.

(2)   If x is an interior node, each child Tz(S) of node x is individually computed in a recursive way. Tx(S)=1 if and only if at least kx children return 1.

3.5 Attribute-Based Encryption

Attribute-based encryption(ABE) is a hot direction in cryptographic research in recent years. It can effectively realize fine-grained non-interactive access control mechanisms and has a broad range of application prospects. In 2005, Sahai et al. [34] first developed a new idea of a fuzzy identity-based encryption scheme (Fuzzy-IBE), in which the unique identity information was extended to biological characteristic information. And later, it was developed to the notion of attribute-based encryption by Goyal et al. [35]. On the base of the combination approach of the secret key and ciphertext associated with the access policy, the ABE schemes can be mainly classed as Key-Policy ABE(KP-ABE) scheme [35] and Ciphertext-Policy ABE(CP-ABE) scheme [33]. In the KP-ABE mechanism, the secret keys are bound with an access policy and the ciphertext are bound with a set of attributes. In contrast, in the CP-ABE mechanism, the secret keys are associated with a set of attributes and the ciphertext are bound with an access policy. In the CP-ABE scheme, the data owners can define access policies over ciphertexts arbitrarily, therefore, it is more suited for fine grained access control than KP-ABE scheme in cloud computing. By virtue of this merit, a number of CP-ABE schemes for securely sharing medical data have been proposed in cloud computing [4,36–38].

3.6 Bilinear Pairing

3.7 Complexity Assumptions

4  System Model

In this section, we discuss the system model of the proposed BC-PC-Share scheme, including the system architecture, the workflow of the proposed scheme and the general definition of the BC-PC-Share scheme.

4.1 System Architecture

In this work, we consider a specific scenario that a patient wants to share his/her PHRs data to multiple organizations, such as hospitals, medical research institutes, and medical insurance companies for different uses and purposes. Thus, we adopt a consortium blockchain to reserve the authentication information and achieve the patient-centric secure medical data sharing. Accordingly, as illustrated in Fig. 2, the system model of the proposed BC-PC-Share scheme mainly consists of four entities: the Data Owner (DO), the Data User (DU), the Cloud Service Provider (CSP), and the BlockChain (BC). The patient-centric data sharing framework can be divided into three different layers, named Data Layer, User Layer and Authentication layer, respectively. The function of each layer is discussed as follows:

Figure 2: System model of BC-PC-Share

1) Data Layer. The function of this layer is to provide the storage service for the data owner DO and provide the downloading service for the data user DU. There is only one entity in the Data Layer.

• CSP. The CSP is responsible for storing the patient’s encrypted PHRs data uploaded by the patient, and it is also responsible for simplifying the complicated ciphertext and providing the service of downloading the shared data for the authorized data user DU. Note that the CSP is generally regarded as a semi-trusted third party because its trust domain is not identical to the DO or DU. Especially, the cloud computing provider may intentionally destroy or tamper with the user’s sensitive data or only transform partial ciphertext of the shared PHRs or even return wrong computation results in a bid to save its storage and computation resource to pursue maximum economic interest, or other malicious purpose. Thus, the data storing to the CSP or the shared data downloading from the CSP should be performed with integrity and consistency verification and the validity of the ciphertext transformed by the CSP should also be checked.

2) User Layer. The components of this layer include two entities: the data owner DO and the data user DU. Their roles in our scheme can be described as below:

• DO. In the proposed BC-PC-Share scheme, the DO is referred to as the patient owning a series of PHR data and with full control over his/her PHR data for sharing them with hospitals, medical research institutes, medical insurance companies and other entities.

• DU. The DU is referred to the individuals or organizations that are allowed to access the patient’s PHR data for medically relevant purposes. Only the authenticated users can access the specified PHR data of the patient. In the proposed BC-PC-Share scheme, the DU is categorized into three different types according to their different uses of the PHR data: the hospital (for the purpose of diagnosis, examination, and healthcare for the patient himself/herself), the medical research institute (for the purpose of conducting scientific research to enhance the quality of healthcare for human beings), and the medical insurance company (for the purpose of providing medical insurance services).

3) Authentication layer. The component of this layer only includes one entity, named the Blockchain. The function of this layer is to record the related authentication information during the PHR data storage and sharing process by the blockchain network. The blockchain plays an essential role in our scheme. It is a peer-to-peer network composed of consensus nodes, a data pool, miners and so on. The consortium blockchain is introduced in our system to keep the authentication information and achieve secure data storage and data sharing.

4.2 Workflow of the BC-PC-Share Scheme

The interaction between each entity is shown in Fig. 2, and the specific workflow of the BC-PC-Share scheme (the description of each numbered step) in Fig. 2 can be described as follows.

① The patient (PHR data owner, DO) encrypts his/her PHR data to be outsourced and uploads the generated ciphertext to the cloud server for storage.

② The DO generates the storage authentication information for the outsourced PHR data and sends it to the smart contracts for storage verification.

③ The cloud server generates the storage validation request and sends it to the smart contracts for storage validation verification. If the storage verification is passed, the smart contracts send the storage authentication information as a transaction to the blockchain.

④ The DU sends a data sharing request with his/her attributes to the DO.

⑤ After successful verification of the validity of the request of DU, the data owner DO generates a user decryption key for DU and sends it to the DU.

⑥ At the same time, the DO generates a cloud-assisted transformation key for the DU and sends it to the cloud server.

⑦ After transforming the complicated ciphertext to a simplified ciphertext, the cloud server sends the transformation authentication information to the smart contracts for transform validation verification. If the transform verification is passed, the smart contracts send the storage authentication information as a transaction to the blockchain.

⑧ The consensus nodes in the blockchain inform the data user DU to download the shared PHR data from the cloud server.

⑨ The DU downloads the encrypted sharing data from the cloud server.

⑩ The DU decrypts the untampered encrypted sharing data and obtains the correct plain message.

4.2.1 Formal Definition

● PHR data storage stage

The PHR data storage stage contains six procedures, i.e., Signingkey Generation, Ciphertext Generation, Storage Authentication Generation, Storage Validation Request, Storage Verification, Block Generation, and Storage Confirm, respectively. The brief description of each procedure is given below:

1) Signingkey Generation.

The DO randomly generates a signing key pair.

2) Ciphertext Generation.

The DO defines an access structure (policy), and encrypts the plaintext message to generate the corresponding ciphertext.

3) Storage Authentication Generation.

The DO sends the ciphertext to the cloud server for storage and sends the corresponding storage authentication information to the smart contracts, respectively.

4) Storage Validation Request.

The cloud server generates the storage validation request and sends it to the smart contracts for storage validation

5) Storage Verification.

The smart contracts automatically execute the storage verification. If the storage verification is passed, the smart contracts send the storage authentication information as a transaction to the blockchain.

6) Block Generation.

The consensus nodes in the blockchain run the consensus algorithm to verify the transaction which is sent by smart contracts and generate a valid block linked to the blockchain, then return the block ID to the data owner DO and the cloud server, respectively.

7) Storage Confirm.

According to the information of the returned block ID, the DO can confirm whether his/her data has been stored in integrity in the cloud server.

● PHR data sharing stage

The PHR data sharing stage involves six procedures, named, Signingkey Generation, Sharing Request Generation, Sharing Request Authorization, PHRs Transformation and Sharing, Transformation Verification and Block Generation, and Decryption, respectively. The brief description of each procedure is given below:

1) Signingkey Generation.

The data user DU generates a random signing key pair.

2) Sharing Request Authorization.

The DU sends a data sharing request to the DO.

3) Sharing Request Authorization.

The DO generates the cloud-assisted transformation key TK and the user decryption key UK, then sends the former to the cloud server and sends the latter to the DU, respectively.

4) PHR Transformation and Sharing.

The cloud server calls the Transformout algorithm to transform the complicated ciphertext to a simplified ciphertext. Next, the cloud server sends the transformation authentication information to the smart contracts for transform validation verification.

5) Transformation Verification and Block Generation.

The smart contracts verify the integrity and consistency of the shared PHR information (i.e., the validity of the transformed ciphertext given by the cloud server). If the transformation verification is passed, the smart contracts send the transformation authentication information as a transaction to the blockchain. Then, the consensus nodes in the blockchain perform the consensus algorithm (e.g., PBFT) to verify the transaction and generate a valid block linked to the blockchain.

6) Decryption.

After the above successful verification, the DU can decrypt the untampered encrypted PHR data with the user decryption key obtained from the DO and recover the plain message.

5  The Concrete BC-PC-Share Scheme

5.1 Scheme Description

In this section, we first design a novel cloud-assisted decryption algorithm of CP-ABE with public third-party verification in subsection A, then we propose the concrete blockchain-based patient-centric data sharing scheme for PHRs in cloud computing in subsection B.

A. Attribute-Based Encryption with Public Verifiable Outsourced Decryption (PVOD-ABE)

Lai et al. [39] proposed a novel model of CP-ABE with verifiable outsourced decryption to guarantee the correctness of the outsourced ciphertext transformation by an untrusted third party (e.g., the remote cloud server). Undoubtedly, the feature of verifiability is a tremendous progress for outsourcing ABE schemes. Nevertheless, their scheme only supported the data user to check the validity of the outsourced ciphertext transformation and failed to support the public verification. Thus, their scheme is not appropriate for the blockchain scenarios. To fill this gap, in this subsection, we develop an Attribute-Based Encryption with Public Verifiable Outsourced Decryption (PVOD-ABE) algorithm, which cannot only achieve the goal of outsourcing the majority of the intensive decryption operations to the cloud server to reduce the computational burden of the classical CP-ABE scheme, but also support the good security property of public verification.

Now, we present the details of our proposed PVOD-ABE algorithm, which consists of five steps, that is, SystemSetup, KeyGen, Encrypt, Transformout, and UserDecrypt. Each of them is described as follows:

•   SystemSetup(1k,U)→(MSK,PP). This step is performed by the DO. Given a system security parameter k and the universal attribute set U, it first chooses two multiplicative cyclic groups G1, G2 with the same prime order q (≥2k), a bilinear map e: G1×G1→G2 between the two group G1, G2, and three secure one-way hash functions H0: Zq∗→G1, H1: G2→{0,1}k and H2: {0,1}∗→{0,1}k. Then, it defines the Lagrange coefficients as Li,K(x)=∏j∈K,j≠ix−ji−j, where i∈Zq∗, and the K is a set with the elements in Zq∗. Next, it randomly picks g,g2∈G1 and α,β∈Zq∗, then computes g1=gα, g3=g2α−1β. Denote the master public key and the master secrete key pair as (MPK={g,g1,g2,g3}, MSK={α,β}). Finally, the DO publishes the system public parameters PP={G1,G2,H0,H1,H2,g,g1,g2,g3}, and keeps the master secrete key MSK confidentially.

•   KeyGen(MSK, PP, S) → (TK, UK). Upon receiving the master secrete key MSK={a,β}, the system public parameters PP, and the attribute set of user S, the key generation algorithm firstly selects three random numbers t,k,d∈Zq∗, then for each attribute, randomly chooses a number ui∈Zq∗ and computes TKi=(TKi,1,TKi,2), where TKi,1=g2t(α+d)(g1iH0(ωi))tui, TKi,2=gtui. Finally, it returns the transform key TK=({TKi}i∈SU, g1tβ−1d,gt,α−1βk,gtk) and the user decryption key UK = t.

•   Encrypt(PP, T, m) → (CT). On input the system public parameters PP, the access policy tree T, and the message m∈{0,1}k to be encrypted, the data owner DO generates the ciphertext CT as follows:

(1)   The DO randomly selects r∈Zq∗, and assigns a polynomial qx with the degree dx=kx−1 in a top-down approach, and sets qroot(0)=r, where the node root is the root of the access policy tree T. Otherwise, for non-root node x, the DO sets qx(0)=qp(x)(index(x)), where p(x) denotes the parent node of x, and index(x) denotes a unique number assigned to x in an arbitrary order.

(2)   Calculate Cx=(Cx,1,Cx,2) for each leaf node x, where Cx,1=gqx(0), Cx,2=(g1att(x)hx)qx(0) and hx=H0(att(x)). Here, the function att(x) is used to return an attribute associated with the leaf node x in the access tree T.

(3)   The DO computes K=H1(e(g1,g2)r), C0=m⊕K.

(4)   Finally, the DO outputs CT=(T,C0,C1,Cj∗).

• Transformout(PP,CT,TK)→(CT′)

This algorithm is used to transform the complicated ciphertext CT to a simplified ciphertext CT′ by the cloud server. The specific steps for the transform process are as follows:

(1)   The cloud server defines a recursive algorithm Dec(CT, TK, x). It takes the ciphertext CT, the cloud-assisted transformation key TK, and a node x in the access tree T as input.

(a)   If x is the leaf node, then

(1)   If ωj=att(x)∈S, then return as formula (1).

Dec(CT,TK,x)=e(gqx(0),g2t(α+d)(g1ωjH0(ωj))tuj)e((g1ωjH0(ωj))qx(0),gtuj)=e(g1,g2)tqx(0)e(g,g2d)tqx(0)(1)

(2)   If att(x)∉S, then return Dec(CT, TK, x) = ⊥.

(b)   For node x is an internal node of access tree T, for all the children z of x, if the number of nodes which satisfy Dec(CT, TK, z) ≠ ⊥ is less than the threshold kx, then return Dec(CT, TK, x) = ⊥. Otherwise, randomly chooses kx child nodes such that Dec(CT, TK, z) ≠ ⊥ to construct a node set Sx′={i=index(z)|z∈Sx′, then continue to calculate as formula (2).

Dec(CT,TK,x)=∏z∈Sx′Dec(CT,TK,z)Li,Sx(0)=e(g1,g2)tqx(0)e(g,g2d)tqx(0)(2)

(2)   The cloud server obtains temp′=e(g1,g2)tre(g,g2d)tr by calling Dec(CT, TK, root), where root is the root node of the access tree T. Further, we could get temp=temp′e(g1tβ−1d,g3r)=e(g1,g2)tr.

(3)   The cloud server returns the simplified ciphertext CT′=(temp,C0,C1).

• UserDecrypt(PP, UK, CT′) → (m)

On input the public parameters PP, and the transformed cyphertext CT′, the DU first verify the validity of the outsourced decryption by checking whether tempα−1βk=e(C1,g1tk) holds or not. If the equation holds, it means that the transformed ciphertext is valid. After the verification is passed, the DU computes K=H1(tempt−1), then the DU decrypts the ciphertext and obtains the plaintext message m=C0⊕K. Actually, the verification process can be performed by a public verifier because the verification equation is independent with the decryption key.

Correctness Proof:

According to formulas (1) and (2), the value of temp in the transformed ciphertext CT′ can be computed as formula (3).

temp=Dec(CT,TK,root)e(g1tβ−1d,g3r)=e(g1,g2)tr.(3)

Then, the data user DU can gain the plain message m by the user decryption key UK as follows. m=C0⊕H1(e(g1,g2)r)=C0⊕H1(tempt−1). Therefore, the data user DU can recover the shared data. Hence, the correctness of the PVOD-ABE is proved.

B. The Construction of the BC-PC-Share Scheme

On the base of the PVOD-ABE algorithm in subsection A, we propose a blockchain-based patient-centric data sharing scheme for PHR data in cloud computing, which consists of two procedures: PHR data storage stage and PHR data sharing stage. To fulfill the automatic public verification, we resort to smart contracts in the proposed BC-PC-Share scheme. In addition, only the patient (i.e., the owner of the smart contract) can deploy the smart contracts on the blockchain, where the entire content of a contract is transparent to all participating nodes in the blockchain and each node can interact with the smart contract. It should be noted that all involved transactions below will automatically trigger the execution of the smart contracts if predefined conditions are satisfied. And the execution result of smart contracts is correct, immutable, and credible to all nodes as long as the security of the blockchain is guaranteed. In this sense, it cannot only achieve public verification, but also reduce the burden of data integrity and consistency checking for the patient and multiple data users.

• PHR data storage stage

In the PHR data storage stage, we introduce a hash linked list to record the storage authentication information of each file in the blockchain and use “link” as a pointer to the head of the hash list for supporting scalable storage verification by utilizing the smart contract. Specifically, the patient (DO) can outsource their PHR data to the cloud server by performing the following seven steps, namely Signingkey Generation, Ciphertext Generation, Storage Authentication Generation, Storage Validation Request, Storage Verification, Block Generation, and Storage Confirm, respectively. Each of them is described in detail as follows:

(1) Signingkey Generation.

The data owner DO first runs SystemSetup algorithm of the PVOD-ABE to generate the system public parameters PP, and generates a random signing key pair (sskO, spkO).

(2) Ciphertext Generation.

Given a plaintext file m, the DO defines an access policy tree T, then generates the corresponding ciphertext CT by calling the Encrypt algorithm of the PVOD-ABE.

(3) Storage Authentication Generation.

The data owner DO calculates R=H2(CT), σO=SSigsskO(link,R,time,spkO,pkC), and let link=H3(prelink,H2(CT),time,ID), where the pointer prelink is pointed to the head of the previous linked hash list, which is introduced for facilitating retrieval of the storage authentication information of the entire user’s data stored in the cloud server at different times by connecting them as a complete linked hash list. The pointer link is initially a fixed-length string (e.g., all “1” strings). pkC is the public key of the cloud server. time is a timestamp representing the signing time. ID is the block label for storing H2(CT),T,prelink,time. The data owner DO keeps the value of link locally. At last, the DO sends the ciphertext CT to the cloud server for storage and the corresponding storage authentication information Authen1=(σO,link,R,spkO,pkC,time) to the smart contracts, respectively.

(4) Storage Validation Request.

Upon receiving the ciphertext CT, the cloud server generates the storage validation request σC=(SSigsskC(H2(CT)),H2(CT)), and finally sends it to the smart contracts for storage validation verification.

(5) Storage Verification.

The storage validation request from the cloud server will automatically trigger the deployed smart contracts to execute the storage validation by determining whether H2(CT)=R holds or not. If it holds, the smart contracts confirm that the relevant PHRs information has been stored intact on the cloud server intactly, i.e., the storage verification is passed. Finally, the smart contracts send the storage authentication information Authen1 as a transaction to the blockchain.

(6) Block Generation.

The consensus nodes in the blockchain perform the consensus algorithm (e.g., PBFT) to verify the transaction and generate a valid block linked to the blockchain and return the block ID to the data owner DO and the cloud server, respectively.

(7) Storage Confirm.

According to the information of the returned block ID, the data owner DO can confirm his/her data has been stored in integrity in the cloud server.

• PHR data sharing stage

In the PHR data sharing stage, we leverage the blockchain to achieve a publicly verifiable data sharing scheme between the DO and the DU, i.e., the DU can verify the integrity and consistency of the shared PHR data. Specifically, the PHR data sharing stage is composed of six procedures, namely, Signingkey Generation, Sharing Request Generation, Sharing Request Authorization, PHR Transformation and Sharing, Transformation Verification and Block Generation, and Decryption, respectively. Each of them is described in detail as follows:

(1) Signingkey Generation.

The data user DU generates a random signing key pair (sskU, spkU).

(2) Sharing Request Generation.

The data user DU calculates σU=SSigsskU(SU,period) as a data sharing request and sends it to the data owner DO.

(3) Sharing Request Authorization.

After successful verification of σU, the DO firstly calculates σO′=SSigsskO(σU||link||pkC||α−1βk,g1tk), and calls the KeyGen algorithm of the PVOD-ABE to generate the cloud-assisted transformation key TK and the user decryption key UK, then sends (σO′||σU||TK) to the cloud server and (σO′||σU||UK) to the data user DU, respectively.

(4) PHR Transformation and Sharing.

Upon receiving the message (σO'||σU||TK) from the DO, the cloud server verifies its valid and whether period is within the validity period, the cloud server selects the corresponding ciphertext C=(CT1,CT2, ⋯,CTn) which satisfy the attribute set SU of DU, and calls the Transformout algorithm of the PVOD-ABE to transform the complicated ciphertext C=(CT1,CT2,⋯, CTn) to a simplified ciphertext C′=(CT1′,CT2′,⋯,CTn′). Thus, migrating the majority of the heavy computation costs of the DU to the cloud server and thus greatly reducing the decryption overhead of the DU. Next, the cloud server sends the transformation authentication information Authen2=SSigsskC(σO'||σU||link||α−1βk||AD(C)||AD(C')) to the smart contracts for transform validation verification.

(5) PHRs Verification and Block Generation.

Since the cloud server is a semi-trusted third party and it may return tampered data to the data user, it is therefore essential to verify the integrity and consistency of the shared PHR information, i.e., the returned shared data should be consistent with the requested shared data and the integrity of the shared data is not tampered. Concretely, it will automatically trigger the deployed smart contracts to perform integrity and consistency verification of C=(CT1,CT2,⋯,CTn) by comparing the transformation authenticate information Authen2 with the hash value retrieved from the hash list pointed by the pointer link in blockchain. If the hash values retrieved from the blockchain is equal to the hash values sent by the cloud server in Authen2, it means that the validity of the transformed ciphertext given by the cloud server can be guaranteed. Then, the consensus nodes in the blockchain perform the consensus algorithm (e.g., PBFT) to verify the transaction and generate a valid block linked to the blockchain.

Subsequently, the smart contracts verify the validity of the outsourced decryption by checking whether tempα−1βk=e(C1,g1tk) holds or not. If the equation holds, it means that the transformed ciphertext is valid. Then, the consensus nodes in the blockchain perform the consensus algorithm (e.g., PBFT) to verify the transaction and generate a valid block linked to the blockchain.

(6) Decryption.

After the above successful verification, the data user DU downloads the encrypted sharing data from the cloud server and decrypts the untampered encrypted PHRs data with the user decryption key UK obtained from the DO and get the plain PHRs data as follows: K=H1(tempt−1),m=C0⊕K. Otherwise, outputs ⊥.

6  Security Analysis

6.1 Security Model

Prior to proving the security of the proposed scheme, we first describe the security model for our work, which is adapted from the security model of Lai et al. [39]. To formalize the security model, the adaptive Chosen Plaintext Attacks (CPA) security game between a challenger 𝒞 and an adversary 𝒜 is defined as follows:

•   Setup. The challenger 𝒞 runs SystemSetup algorithm with the security parameter k and attribute universe U to generate the system public parameters PP, and returns them to the adversary 𝒜.

•   Query Phase I. The attacker 𝒜 adaptively issues the following queries:

– TK query. Given an attribute set S from 𝒜, the challenger 𝒞 runs KeyGen algorithm to generate the transformation key TK and returns it to the adversary 𝒜.

– UK query. Given an attribute set S from 𝒜, the challenger 𝒞 runs KeyGen algorithm to generate the user decryption key UK and returns it to the adversary 𝒜.

– Transformout query. Given a ciphertext CT, the challenger 𝒞 runs Transformout algorithm to generate the transformed ciphertext CT′ and returns it to 𝒜.

•   Challenge. Once Query Phase I is over, the attacker 𝒜 submits two messages m0, m1 with equal length and one access structure T∗, the challenger 𝒞 randomly selects b ∈ {0, 1}, then returns the challenge ciphertext CT∗ to the adversary 𝒜.

•   Query Phase II. The adversary 𝒜 continues to adaptively issue the queries in Query Phase I with the following two restrictions:

1)   The adversary 𝒜 cannot simultaneously make the TK Query and the UK Query on the attribute sets that satisfy the challenging access structures T∗.

2)   If the adversary 𝒜 has made the TK Query, he/she cannot make the UK Query on the attribute sets that satisfy the challenging access structures T∗ and vice versa.

•   Guess. At the end of the game, the adversary 𝒜 outputs a guess b′ ∈ {0, 1} for b and the adversary 𝒜 succeeds in the security game if and only if b′ = b.

6.2 Security Proof

In this subsection, we discuss the security of the proposed BC-PC-Share scheme under the general assumptions and the random oracle model, including CPA security, completeness, and efficient user revocation.

Proof. Since our devised BC-PC-Share scheme is constructed on the basis of the aforementioned PVOD-ABE algorithm, the data confidentiality of the BC-PC-Share scheme is guaranteed by the PVOD-ABE scheme. The CPA security proof of the PVOD-ABE scheme is described as a security game between a challenger 𝒞 and an adversary 𝒜. Given an instance of the DBDH problem (g,ga,gb,R) randomly, the aim of the challenger 𝒞 is to decide if R=e(g,g)a2b holds or not. The specific processes of the security game are as follows:

•   Setup. The challenger 𝒞 performs the Setup algorithm and returns the relevant system global parameters to the adversary 𝒜as follows:

(1)   The challenger 𝒞 firstly defines two secure one-way hash functions: H0(ω)=g1−ωgrω, where rω∈RZq∗, and H1(R)=K, where K∈R{0,1}k.

(2)   The challenger 𝒞 chooses two random numbers r,v∈Zq∗, and returns the system global parameters to the adversary 𝒜.

(3)   The challenger 𝒞 chooses two random numbers r,v∈Zq∗, and returns the system global parameters PP=(G1,G2,H0,H1,H2, g,g1=ga,g2=gar,g3=gvr,e) to the adversary 𝒜. The adversary 𝒜 can only obtain the value of hash function by performing hash query. And MSK={α=a,β=av} is the master secret key. In addition, the challenger 𝒞 maintains a list TKList, which is initially an empty list.

•   Query Phase I. The adversary 𝒜 initiates a series of queries as follows:

– TK Query: The adversary 𝒜 submits an attribute set S to the challenger 𝒞. If the adversary 𝒜 has been queried the cloud-assisted transformation key TK before, then 𝒞 returns the previous TK. Otherwise, the challenger 𝒞 returns the cloud-assisted transformation key as follows:

(1)   The challenger 𝒞picks d′,t,k∈RZq∗.

(2)   The challenger 𝒞 randomly chooses a number ui∈Zq∗ for each attribute i ∈ S, and computes TKi=(TKi,1,TKi,2), where TKi,1=g2t(α+d)(g1iH0(ωi))tui, TKi,2=gtui.

(3)   The challenger 𝒞 returns TK=({TKi}i∈S,gtv−1d′g1−tv−1,gt,vk,g1tk) to the adversary 𝒜and adds tuple (TK,UK) to the list TKList.

– UK Query. The adversary 𝒜 submits an attribute set S to the challenger 𝒞. If the adversary 𝒜 has been queried for the user decryption key UK before, then 𝒞 returns the previous UK, otherwise, the challenger 𝒞 makes TK Query to get TK and UK, and finally returns the UK.

– Transformout Query. In this phase, 𝒜 runs the Transformout(PP,CT,TK)→CT′ algorithm to transform the complicated ciphertext CT to a simplified ciphertext CT′ by leveraging the cloud-assisted transformation key TK obtained in TK Query.

•   Challenge. The adversary 𝒜 submits two messages m0, m1 with the same length and an access policy tree T∗ to the challenger 𝒞. The challenger 𝒞 randomly picks a bit coin ∈{0, 1}, and responds to the challenging ciphertext CT∗ as follows:

1)   Let qroot(0)=r∗, where the node root is the root node of T∗, and compute qx(0) for each leaf node x by using the first step in Encrypt(PP, T, M) → CT algorithm of the PVOD-ABE.

2)   Compute Cx∗=(Cx,1∗,Cx,2∗) for each leaf node x, where Cx,1∗=gbqx(0), Cx,2∗=gbrx∗qx(0), and rx∗ can be obtained by making queries H0(ωx∗). Here, ωx∗=att(x). Let S∗ denote the set of leaf nodes in the access tree T∗.

3)   Compute C0∗=mcoin⊕H1(Rrr∗),C1∗=(gb)vrr∗=g3br∗.

4)   Return CT∗=(T∗,C0∗,C1∗,{Cx∗}x∈S∗) to the adversary 𝒜.

Note that the adversary 𝒜 cannot simultaneously make the TK Query and the UK Query on the attribute sets that satisfy the challenging access structures T∗.

•   Query Phase II. The adversary 𝒜 still can launch the queries adaptively as Query Phase I except for the two queries below:

1)   The adversary 𝒜 cannot simultaneously make the TK Query and the UK Query on the attribute sets that satisfy the challenging access structures T∗.

2)   If the adversary 𝒜 has made the TK Query, he/she cannot make the UK Query on the attribute sets that satisfy the challenging access structures T∗ and vice versa.

•   Guess. Finally, the adversary 𝒜 outputs a guess coin′ for coin. If coin′ = coin holds, the challenger 𝒞 outputs “1”, otherwise, outputs “0”.

According to the UserDecrypt algorithm, it is easy to get temp∗=e(g2a,gbr∗), that is, if R=e(g,g)a2b, the CT∗ is the valid ciphertext of mcoin, therefore, based on the response from the adversary 𝒜, the challenger 𝒞 can determine whether R=e(g,g)a2b holds or not.

Additionally, there is no failure case in the security game, therefore, if 𝒜 can break the proposed scheme with non-negligible probability ε, we can conclude that 𝒞 can also decide if R=e(g,g)a2b holds or not with the same non-negligible probability ε. In other words, DBDHP could be solved. However, it is a paradox to the well accepted DBDH problem. Therefore, the advantage of adversary 𝒜 breaking the proposed scheme is negligible and our scheme achieves CPA security.

Proof. According to the traceability and immutability properties of the blockchain, the integrity and consistency of the shared data in our scheme can be guaranteed. During the data sharing process, the deployed smart contracts compare the hash value of ciphertext CT returned by the cloud server in transformation authenticate information Authen2 with the hash value retrieved from the hash list pointed by the pointer link in blockchain to verify the integrity and consistency of the shared data. If the above two hash values are equal, it can ensure that the returned shared data is consistent with the requested shared data and the integrity of the shared data is not compromised. In addition, the smart contracts verify the validation of the transformed ciphertext by checking whether the equation tempα−1βk=e(C1,g1tk) holds or not. Therefore, our scheme can satisfy the property of completeness.

Proof. Assume that the cloud server does not collusion with the data user DU, the cloud server will provide the cloud-assisted transformation service of the ciphertext of the data owner DU within the valid period. In other words, according to the proof of Theorem 6.1, if the data owner DU is not within the valid period, even if the data user DU has made the UK Query and obtained the user decryption key UK, he/she is forbidden to launch the Transformout Query either, thereby ensuring that the data user DU who is not within the valid period cannot obtain the desired data. In this sense, our scheme realizes the user revocation. In addition, different from most of the existing user revocation schemes, our scheme does not require the system to perform the complicated ciphertext re-encryption and key update operations. Therefore, the proposed BC-PC-Share scheme can achieve the property of efficient key revocation.

7  Performance Evaluation

In this section, we provide the performance evaluation of our proposed BC-PC-Share scheme vs. three existing relevant attribute-based data sharing schemes proposed in [19,40,41]. The concrete comparison is divided into three terms. Firstly, we make a comparison of the security properties among the proposed BC-PC-Share scheme and that of schemes in [19,40,41]. Secondly, the complexity analyses in terms of computation cost and storage overhead are presented. Thirdly, we perform the efficiency analysis by a numerical simulation experiment.

7.1 Comparison of Properties

In this subsection, we make a comparison of the security properties among the proposed BC-PC-Share scheme and that of schemes in [19,40,41] in terms of the properties of access control, blockchain-based, sharing consistency, ciphertext transformation, and time-controlled access, and the comparison results are summarized in Table 1. All the schemes in [19,40,41] support the property of the fine-grained access control. In addition, the scheme in [40] can support the properties of the fine-grained access control, blockchain-based, and ciphertext transformation, but fails to support the properties of sharing consistency and time-controlled access. The scheme in [41] can support the properties of fine-grained access control and blockchain-based, but fails to support the properties of sharing consistency, ciphertext transformation, and time-controlled access. The comparison results in Table 1 validate that only the proposed BC-PC-Share scheme satisfies all the desired security features and is more promising and suitable for secure medical data sharing in multiple receiver scenarios.

7.2 Complexity Analysis

In this subsection, we perform the comparison in terms of computation cost and communication overhead, respectively. For the sake of the comparison, the notations and their meanings used in this subsection are summarized in Table 2.

Table 3 gives the comparison of the computation cost between the proposed BC-PC-Share scheme with the existing schemes in [19,40,41] and the comparison of communication overhead among them is briefly presented in Table 4.

From Table 3, it can be observed that in the Encrypt phase, the computation cost on the data owner side in our scheme is much smaller than that of the schemes in [19,40]. And our scheme only adds one Texp compared with the scheme in [41]. In the phase of Transformout, the computation cost on the cloud server side in our scheme is much smaller than that of the scheme in [19], and is slightly higher than that of the scheme in [40] (i.e., more costly). In addition, as the scheme in [41] does not involve the Transformout algorithm, its computation cost for the transform phase is represented as None. In the phase of UserDecrypt, the computation cost on the data user side of the schemes in [40] and ours is much smaller than that of the schemes in [19,41]. As presented in Table 4, the size of the ciphertext, the transformation key, and the user decryption key in our scheme is relative smaller in overall compared with that of the schemes in [19,40,41].

7.3 Efficiency Analysis

The simulation experiment is implemented by a rapid cryptographic prototyping toolkit called Charm [42] with Python, and the operating system is Ubuntu 16.04 64-bit.

Note: considering that the specific implementation details of the blockchain may affect the efficiency of the scheme, but will not affect the security of the scheme, in our experiments, we do not simulate the operation of blockchain nodes. To deploy the scheme in specific blockchain application scenarios is our future research work. Besides, considering that the scheme in [19] is not based on blockchain, here, we only make simulation comparison of the three blockchain-based schemes of [40,41] and ours in terms of encryption time, transformation time and user decryption time.

A comparative study of the execution time of encryption phase, transformation phase, and userdecryption phase among the schemes in [40,41] and ours has been depicted in Figs. 3–5, respectively.

Figure 3: Comparison of encryption time

Figure 4: Comparison of transformation time

Figure 5: Comparison of userdecryption time

Fig. 3 illustrates the comparison of computation cost in the encryption phase. The change trend of computation cost in all the three schemes, [40,41] and ours, grows linearly with the number of attributes involved in the access policy. In addition, it is also can be seen that, with the amount of attributes involved in the access policy, the computation cost of scheme [40] is more costly than that of scheme [41] and ours. And the computation cost of scheme [41] is roughly equivalent with ours, and they both keep at a relatively low level.

Fig. 4 illustrates the comparison of computation cost in the transformation phase, and it is not surprising to observe that the change trend of computational cost in scheme [41] grows linearly with the amount of attributes involved in the access policy, while it is constant in scheme [40] and ours because the transformation time in scheme [40] and ours does not grow with the number of attributes.

Fig. 5 shows that the change trend of the computation cost in the userdecryption phase, and the change trend of the scheme in [40] and ours grows linearly with the number of attributes and only with a minor gap. Although the computation cost in our scheme is slightly higher than that of the scheme in [40], the former can support the public verification of the integrity and consistency of the shared data, and the latter cannot. Thus, our scheme is more promising and more practical than others.

8  Conclusion

In this paper, we investigated the security issues of PHR data sharing and devised a system paradigm of the combination of cloud computing and consortium blockchain technology and proposed a feasible and promising solution to enhance the trustworthiness of each entity and fulfilled public verifiability, consistency, immutability, scalability and fine-grained PHR sharing in a multi-receiver setting. In addition, our scheme can achieve efficient user revocation and user decryption. The security analysis and simulation experiments conducted in this study demonstrated the security, scalability, and efficiency of the proposed BC-PC-Share scheme.

Acknowledgement: The authors are very grateful to the editors and reviewers for their constructive feedback and insightful suggestions.

Funding Statement: This work was supported by the Youth Doctoral Foundation of Gansu Education Committee under Grant No. 2022QB-176.

Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.