Keywords

1 Introduction

With the development of technology in healthcare systems, the scale of medical data has grown rapidly. Among them, EHRs [1] are widely used because they contain all health data of patients, including medical records, medications, and experience reports, etc. In the traditional medical system, EHRs are stored on the internal networks of medical institutions [2] and managed by dedicated internal staff only, resulting in the following problems. On the one hand, the EHRs data between different medical institutions do not interoperate, which triggers the data island effect. Patients need to carry multiple copies of cases for inter-hospital visits, which brings inconvenience to the cross-hospital diagnosis and treatment [3]. On the other hand, EHRs are used without the patients’ consent, which may lead to the leakage of patient privacy. Furthermore, EHRs data are also of great value and easy to be attacked by attackers [4]. To address the above issues and enable secure sharing of EHRs data, a challenging problem is how to achieve fine-grained access control for patients to their EHRs.

ABE is one of the most effective methods to ensure confidentiality while achieving fine-grained access control. ABE was first proposed by Sahai et al. [5], which refers to that the ciphertext can only be decrypted if it meets specific attribute requirements. When in the healthcare system, patients can set adequate attributes for their EHRs data to allow access, such as attending hematologist, nurse-in-charge, etc. Doctors can take their access control structure to match the attributes set by patients. Once the patients’ attribute requirements are met, doctors can decrypt and access the data. Blockchain was first proposed by Nakamoto [6] in 2008. It is considered to be a distributed database [7] with decentralization, transparency, and non-tamper ability. There is a special program that can interact with the blockchain called smart contract [8]. It can execute automatically according to a pre-determined program. Since the execution process does not require the involvement of a third party, the results of the execution of smart contracts are trusted. To enable secure sharing of EHRs, the existing solutions [2, 9,10,11,12,13] mainly use ABE for fine-grained access control, where encrypted data are stored on a special server and all access actions are recorded on the blockchain with a smart contract. Wang et al. [2] proposed a C-AB/IB-ES scheme combined with ABE and Identity-based encryption (IBE) to achieve access control. In their scheme, patients first sign their data using Identity-Based Signatures (IBS) to ensure data integrity. All data are stored on a healthcare cloud server and the encryption process is handled by the hospital. Wang et al. [9] believed that the patient can also be the subject of access control. The patient generates and distributes the attribute private key to those who are allowed to access it. And the smart contract records the list of users who are allowed to access it. Huang et al. [10] write every query and write operations of EHRs into the blockchain, which ensures traceability. Naresh et al. [11] utilize the consortium chain to store the hash value of EHRs to ensure integrity. Searchable encryption [14] technology can realize fast retrieval of ciphertext without revealing the plaintext. When there are large-scale encrypted EHRs stored on the server, searchable encryption can be used to accelerate the search. Reference [12, 13] also combines searchable encryption into attribute encryption to improve the speed of ciphertext retrieval. In these schemes, the blockchain is used only as a decentralized database to store access records, not involved in trusted computing. And they all rely on a centralized third-party authority to generate and manage the private keys. In reality, there is no guarantee that a third-party authorized authority will always be credible.

With the rise of the cloud servers, some services related to EHRs are transferred to cloud servers. Cloud servers are generally considered to have the unlimited computing power and can perform assigned tasks as required. The low price, as well as infinite storage space have drawn more people’s attention. They [15,16,17,18] store the encrypted data on it, or use cloud services to assist in computing. Hua et al. [15] pointed out that the EHRs ought to be outsourced to cloud for storage after encryption, which ensures patients’ privacy safety while reducing the strain on local systems. To address the issue of high computational overhead in ABE decryption, Zhang et al. [16] proposed a matching stage before decryption scheme, which improves decryption efficiency for outsourced data storage in cloud computing. IPFS is also one of cloud storage services. It allows data to be shared across multiple organizations while also avoiding single points of failure. References [17, 18] store the encrypted data on IPFS. Despite the tremendous benefits, security and privacy remain cloud servers’ most important considerations. On the one hand, cloud servers allow access on the public network, which means that an attacker can also access the data. On the other hand, cloud services are often provided by third parties. It is unknown whether third-party institutions are always credible [19, 20]. Hence, the security of cloud services is significant and worth considering.

Through the analysis of the existing schemes, we remark that the security of the existing EHRs sharing systems is mostly based on a centralized third-party authority. However, a single third-party authority will also have a single point of failure, especially, it’s difficult to find an always trusted third-party authority in reality. To address this problem, we propose a blockchain-assisted key generation EHRs sharing scheme. Our specific contributions are listed below.

  1. 1.

    We propose a EHRs sharing scheme without the third-party trusted authorized authority. Compared with the existing EHRs scheme, our scheme removes the third-party trusted authorized authority. Medical institutions play the role of consortium chain nodes to realize the safe sharing of EHRs among them. We use the consortium blockchain nodes to generate and manage the master key and attribute private key. All access operations need to be recorded on the chain.

  2. 2.

    In our scheme, we outsource the attribute pre-decryption and ciphertext retrieval assignments that consume a lot of computing power to the cloud servers, which takes pressure off the blockchain system while ensuring security.

  3. 3.

    We propose a EHRs sharing scheme also based on a searchable encryption. Data users with search trapdoors can retrieve data quickly from cloud servers.

  4. 4.

    The proposed scheme is feasible in practice. We implement our scheme based on the open-source cryptographic library and build a consortium blockchain network on Hyperledger Fabric. Performance analysis shows that our scheme can achieve fine-grained access control and fast decryption of EHRs.

The structure of this paper is as follows: Sect. 2 briefly introduced the basic knowledge. Our scheme architecture, system procedure, and security model are presented in Sect. 3. We introduced our scheme in detail in Sect. 4. After security proof and performance analysis in Sect. 5, we summarize the scheme in the last section.

2 Preliminaries

2.1 Bilinear Map

For two cyclic groups \(G_{a}\) and \(G_{b}\) with prime order p. Suppose that \(e:G_{a} \times G_{a} \to G_{b}\) is a general map, we call e as a bilinear map [21] if e satisfies the following three properties.

  • Bilinearity: \(e(g_{1}^{a} ,g_{2}^{b} ) = e(g_{1} ,g_{2} )^{ab}\) for all \(g_{1} ,g_{2} \in G_{a}\) and \(a,b \in Z_{p}\).

  • Non-degeneracy: There exits \(g_{1} ,g_{2} \in G_{a}\) such that \(e(g_{1} ,g_{2} ) \ne 1\), where 1 is the unit of \(G_{b}\).

  • Computability: For all \(g_{1} ,g_{2} \in G_{a}\), \(e(g_{1} ,g_{2} )\) can be calculated quickly in a polynomial-time.

2.2 Pedersen (k, N) Secret Share (PSS)

Suppose there are n participants \(P_{1} ,P_{2} ,P_{3} ...,P_{n}\) who are equal to each other. They select a sub-secret \(S_{i}\) respectively, and all sub-secrets add up to the main secret S in the form of an algebraic sum. Denote \(G_{p}\) is a finite field with a large prime order p. The Pedersen (k, n) Secret Share [22] protocol is composed of the next four steps.

  1. 1.

    Main-secret production: Each participant picks a random number \(N_{i} \in Z_{p}\) as the sub-secret, and adds them to generate the main-secret S by Eq. (1).

    $$S = \sum\limits_{i = 1}^{n} {N_{i} }$$
    (1)
  1. 2.

    Sub-share production: All participants independently execute the Shamir secret sharing algorithm [23]. Each participant \(P_{j}\) randomly selects a k-1 degree of polynomial \(f_{j} (x)\) and sets \(f_{j} (0) = N_{j}\). Then, \(P_{j}\) computes n sub-shares \(ss_{ji} = f_{j} (x_{i} )\) for \(i = 1,2,3...,n\) and sends \(ss_{ji}\) to \(P_{i}\) through a secret channel.

  2. 3.

    Main-share production: After receiving n sub-share \(ss_{ij}\) for \(i = 1,2,3...,n\), \(P_{j}\) calculates its master-share \(ms_{j}\) with Eq. (2).

    $$ms_{j} = \sum\limits_{i = 1}^{n} {ss_{ij} }$$
    (2)
  1. 4.

    Main-secret recovery: If there are more than k participants \(P_{i} \in P_{R}\), the main-secret can be recovered with Eq. (3).

    $$S = \mathop \sum \limits_{{P_{i} \in P_{R} }} ms_{i} \mathop \prod \limits_{{P_{j} ,P_{i} \in P_{R} ,j \ne i}} \frac{j}{j - i}(\bmod p)$$
    (3)

2.3 Decision Bilinear Diffie-Hellman (DBDH) Assumption

Let G and \(G_{T}\) be two cyclic groups with prime order p, and e is a bilinear map. Randomly select \(x,y,z \in Z_{p}\) and \(T \in G_{T}\), denote \(X = g^{x} ,Y = g^{y} ,Z = g^{z}\). It is difficult to determine whether T is equal to \(e(g,g)^{xyz}\) in any probabilistic polynomial-time [24].

3 System Design

3.1 System Architecture

The architecture of our scheme is shown in Fig. 1, which contains five participants, BC, Patients, IPFS, CSP, Data Users and CSP.

Fig. 1.
figure 1

System architecture.

Full size image

BC: A consortium blockchain composed of multiple medical institutions including regulatory authorities. BC is responsible for generating and managing the master key and users’ private keys. And it is also in charge of assigning outsourced decryption or retrieval assignments, and recording all users’ operations on the chain.

Patients: The data owner in the system. After the treatment in the hospital, patients get medical data from the doctor, such as their own cases or medication status. Then they select appropriate keywords and attribute sets according to the data content. After encrypting the data and calculating the index, patients upload the encrypted data to IPFS, index to BC for recording.

DU: Data user in the system. DU can be doctors in other hospitals, staff from regulatory authorities, etc. If attribute set embedded in DU’s access structure satisfies the patient’s attribute requirement, he/she can obtain the Patient’s data. At the same time, DU can also generate search trapdoors to search ciphertexts.

CSP: Cloud service provider. It is responsible for the index-retrieval and pre-decryption tasks assigned by BC. We assume that CSP has high computing power and always keeps online. In addition, we suppose that CSP is honest and curious about security.

IPFS: The IPFS is built by multiple medical institutions. We use IPFS to store EHRs from various healthcare facilities, avoiding the single point of failure associated with centralized storage.

3.2 System Procedure

S1. System initialization: All blockchain nodes perform \(SysInit(1^{\lambda } ) \to (MK,PK)\) to generate the public key PK and master key MK. Especially, MK is generated through all blockchain nodes by PSS protocol, no one knows the exact master key value.

S2. Key generation: In this subsection, all blockchain nodes generate two kinds of keys: outsourced private key \(SK_{out}\) and attribute private key \(SK_{attr}\). \(KeyGen({\mathbb{A}},PK,MK) \to (SK_{attr} ,SK_{out} )\) is performed by BC. It takes the user’s access structure \({\mathbb{A}}\), global public key PK, master key MK as input and outputs the user’s outsourced private key \(SK_{out}\), the user’s attribute private key \(SK_{attr}\). Finally, BC sends the \(SK_{attr}\) and \(SK_{out}\) to DU in a secret channel.

S3. Encryption: First, patients select appropriate access attributes and keywords according to data content. Then he/she runs AES encryption over the data, and uploads the AES ciphertext to IPFS. Next, he/she executes \(Encrypt(K_{aes} ,PK,w) \to CT\) for fine-grained access control, and gets attribute ciphertext CT. Patients also execute \(IndexGen(PK,CT,KW) \to Ix(kw)\) to generate the index \(Ix(kw)\). Finally, he/she submits tuple \((CT,Ix(kw))\) to BC for recording and latter search.

S4. Index key generation: First, BC executes the algorithm \(IndexKeyGen(PK,BF_{\beta } ,{\mathbb{A}}) \to IK\). Among them, \({\mathbb{A}}\) is DU’s access structure, \(BF_{\beta }\) is a commitment value. This algorithm outputs the query private key IK.

S5. Trapdoor generation: DU performs the algorithm \(TrapDoor(PK,IK,kw,\beta ) \to Td_{kw}\). Among the inputs, kw is the keyword for search and \(\beta\) is a blinding factor. This algorithm outputs the trapdoor \(Td_{kw}\).

S6. Pre-decryption: Pre-decryption is run by CSR. Firstly, DU submits trapdoor \(Td_{kw}\) to BC. Then BC commissions CSR to execute the algorithm \(Search(Td_{kw} ,(CT,Ix(kw))) \to \bot /CT\). If keywords in \(Td_{kw}\) satisfies one of the index-set of \(Ix(kw)\) , CSR will run \(Pre - decrypt(CT,PK,SK_{out} ) \to Q_{pre}\) to gain partial ciphertext \(Q_{pre}\) and return it to BC. Finally, BC sends \(Q_{pre}\) to DU.

S7. Local decryption: After receiving the partial ciphertext \(Q_{pre}\), DU executes algorithm \(Decrypt(Q_{pre} ,CT,PK,SK_{attr} ) \to K_{aes}\) to obtain AES key \(K_{aes}\). Then, DU downloads the ciphertext from IPFS, decrypts it with \(K_{aes}\), and verifies its integrity.

3.3 Security Model

The security requirement for our blockchain-assisted key generation electric health records sharing scheme is based on Li et al.’ scheme [25]. The difference is that we use blockchain to generate and manage all keys, and there are no curious KG-CSP and TypeII-Adversary in [25]. Replayable chosen ciphertext attack (RCCA) security was put forward in [26], which allows modifying the ciphertext, and cannot effectively change the implicit information. The adversary 𝒜 can be described as a malicious DU, it will conspire with curious CSR to decrypt the data stored on the cloud servers. The 𝒜 is permitted to obtain all users’ outsourced private key \(SK_{out}\) and trapdoor \(Td_{kw}\). The definition of the game between challenger and adversary 𝒜 is as follows.

Setup:

Challenger executes the System initialization method in Sect. 3.1 to get PK and MK. Then the challenger sends PK to 𝒜 and saves MK as a secret.

Query Phase:

Challenger first creates an empty collection C and the adversary 𝒜 repeatedly initiate the following queries:

  1. 1.

    KeysGeneration. Upon receiving an access structure \({\mathbb{A}}\), challenger runs key-generation algorithm to get \(SK_{attr}\) and \(SK_{out}\). Challenger stores key tuple \((SK_{attr} ,SK_{out} )\) with \({\mathbb{A}}\) in collection C and sends it to 𝒜.

  2. 2.

    TdGeneration. After receiving an access structure \({\mathbb{A}}\), challenger performs \(IndexKeyGen(PK,BF_{\beta } ,{\mathbb{A}}) \to IK\) and \(TrapDoor(PK,IK,kw,\beta ) \to Td_{kw}\) to generate a trapdoor \(Td_{kw}\). Challenger stores \(Td_{kw}\) in collection C and sends \(Td_{kw}\) to 𝒜.

  3. 3.

    Decrypt. After receiving \({\mathbb{A}}\) and ciphertext tuple \((CT,Q_{pre} )\), challenger checks whether the access structure exits in the tuple \(({\mathbb{A}},(SK_{attr} ,SK_{out} ),Td_{kw} )\) of collection C. If so, it executes algorithm \(Decrypt(Q_{pre} ,CT,PK,SK_{attr} )\) and sends \(K_{aes}\) to 𝒜. Else, it returns null value.

Challenge:

The adversary 𝒜 sends two plaintexts \(M_{0}\),\(M_{1}\) of equal length and a challenging attribute set \(w^{*}\) to challenger. It should be noted that \(w^{*}\) can’t satisfy the access structure \({\mathbb{A}}\). The challenger chooses \(\mu \in \{ 0,1\}\), and runs \(Encrypt(M_{\mu } ,PK,w) \to CT\). Then challenger returns the challenge ciphertext CT to the adversary.

Restrictions:

Since \(w^{*}\) can’t satisfy the access structure \({\mathbb{A}}\), the adversary 𝒜 can’t launch the KeysGeneration algorithm.

The adversary 𝒜 can’t launch TdGeneration query that the result equals to neither \(M_{0}\) nor \(M_{1}\).

Guess:

The adversary 𝒜 gives a guess \(\mu ^{\prime} \in \{ 0,1\}\) for μ.

Our scheme can meet RCCA-security. If the adversary’s advantage in winning the game is negligible at best in any polynomial-time, such as \(\left| {P(\mu ^{\prime} = \mu ) - \frac{1}{2}} \right| < \varepsilon\).

4 System Scheme

Before introducing the detailed definition of the system, we firstly define the Lagrange coefficient \(\Delta_{i,S} (x) = \sum\limits_{i = 0}^{n - 1} {S(i)} \prod {_{j \in S,i \ne j} } \frac{x - j}{{i - j}}\) for \(i,j \in S\), n is the length of S.

Our scheme is based on the Outsourced Attribute-based Encryption (OABE) [25] and the tree-based access structure. The user’s private key contains a tree-based access structure \({\mathbb{A}}\), the attribute set w is embedded in ciphertext, and U is the set of all attributes, d is a pre-set threshold value. If \(\gamma (w,{\mathbb{A}}) = 1\), S is an attribute set that satisfies \(S \in \{ w \cap {\mathbb{A}}\} \wedge \left| S \right| = d\). Based on the above structure, we use blockchain to take the place of authorized authority (AA) to generate and manage the user’s private key, and add integrity verification phase in the scheme.

\(SysInit(1^{\lambda } )\): All blockchain nodes of BC run this algorithm, and \(\lambda\) is a secure parameter. BC chooses two multiplicative cyclic groups of prime order p: \(G_{a}\) with generator g, \(G_{b}\), and a bilinear map \(e:e(G_{a} ,G_{a} ) = G_{b}\). Each consensus node of BC cooperates to generate a parameter \(x \in Z_{p}\) by the PSS protocol. BC calculates \(g_{1} = g^{x}\), randomly chooses \(g_{2} ,h \in Z_{p}\). BC chooses \(\{ u_{i} \in U\}_{0 < i \le n} \in Z_{p}\) to build the attribute universal U with length n. BC also selects secure hash functions:\(H_{a} :\{ 0,1\}^{*} \to Z_{p}\),\(H_{b} :G_{b} \to \{ 0,1\}^{\log p}\). Finally, BC sets \(PK = \{ G_{a} ,G_{b} ,g,g_{1} ,g_{2} ,h,\{ u_{i} \}_{0 < i \le n} ,H_{a} ,H_{b} \}\), \(MK = x\), and publishes PK as the global public key, keeps the MK as a secret.

\(KeyGen({\mathbb{A}},PK,MK)\): This algorithm is run by blockchain nodes of BC. When receiving the access structure \({\mathbb{A}}\), BC selects a random value \(x_{a} \in Z_{p}\) and calculates \(x_{b} = x - x_{a} \bmod p\). Then BC randomly selects a d − 1 degree of polynomial \(f(x)\) and sets \(f(0) = x_{a}\). For \(i \in {\mathbb{A}}\), BC randomly chooses \(\forall r_{i} \in Z_{p}\), calculates \(d_{{i_{0} }} = g_{2}^{f(i)} (g_{1} h_{i} )^{{r_{i} }}\), and \(d_{{i_{1} }} = g^{{r_{i} }}\). Denote DU’s outsourced private key \(SK_{out} = \{ d_{{i_{0} }} ,d_{{i_{1} }} \}_{{i \in {\mathbb{A}}}}\). Next, BC computes \(d_{{\theta_{0} }} = g_{2}^{{x_{b} }} (g_{1} h)^{{r_{\varphi } }}\) and \(d_{{\theta_{1} }} = g^{{r_{\varphi } }}\) where \(r_{\varphi } \in Z_{p}\). Denote \(\varphi\) as the default attribute. Let DU’s attributed private key \(SK_{attr} = \{ d_{{\theta_{0} }} ,d_{{\theta_{1} }} \}\). Finally, BC returns \(SK_{attr} ,SK_{out}\) to DU in a secret channel.

\(IndexKeyGen(PK,BF_{\beta } ,{\mathbb{A}})\): On receiving index-key generation request with DU’s access structure \({\mathbb{A}}\) and a commitment \(BF_{\beta } = g_{2}^{1/\beta }\) (DU randomly chooses \(\beta \in Z_{p}\) and keeps it as secret). BC searches \(\left( {g_{1} h} \right)^{{r_{\varphi } }}\) associated with \({\mathbb{A}}\) and calculates \(IK = g_{2}^{x/\beta } \left( {g_{1} h} \right)^{{r_{\varphi } }}\). Then BC returns the IK to DU.

\(Encrypt(K_{aes} ,PK,w)\): After treatment, patients get their case plaintext PT from the doctor. Patients use AES encryption PT with random \(K_{aes} \in G_{2}\) to obtain AES ciphertext \(M^{\prime}\), compute \(H_{a} (PT) = h^{\prime}\), and update \(M^{\prime}\) to IPFS to get IPFS address \(p^{\prime}\). Patients choose an attribute set w associated with PT. Patients also choose \(\eta \in Z_{p}\) randomly and compute \(C_{0} = K_{aes} e\left( {g_{1} ,g_{2} } \right)^{\eta } ,C_{1} = g^{\eta } ,C_{i} = \left( {g_{1} h_{i} } \right)^{\eta }\) for \(i \in w\), and \(C_{\varphi } = (g_{1} h)^{\eta }\). Denote ciphertext \(CT = (\omega \cup \{ \varphi \} ,C_{0} ,C_{1} ,\left\{ {C_{i} } \right\}_{i \in \omega } ,C_{\varphi } )\).

\(IndexGen(PK,CT,KW)\): According to the ciphertext CT, patients select the appropriate keyword set KW. For each keyword \(i \in KW\), patients compute \(k_{i} = e(g_{1} ,g_{2} )^{\eta } \cdot e(g,H_{a} (kw_{i} ))^{\eta } \in G_{2}\) and let \(K_{i} = H_{b} (k_{i} )\). Patients also let \(K_{1} = C_{1} = g^{\eta }\), \(K_{2} = C_{\theta } = (g_{1} h)^{\eta }\) and \(Ix(KW) = (K_{1} ,K_{2} ,K_{i} )\). Patients send \((CT,Ix(KW))\) with \(h^{\prime}\), \(p^{\prime}\) to BC, then BC sends \((CT,Ix(KW))\) to CSR.

\(TrapDoor(PK,IK,kw,\beta )\): To generate trapdoor \(Td_{kw}\) with keyword kw. DU computes \(T_{q} (kw) = H_{a} (kw)IK^{\beta }\), \(D_{1} = d_{{\theta_{1} }}^{\mu }\) and let \(I = (I_{{i_{0} }} = d_{{i_{0} }} ,I_{{i_{1} }} = d_{{i_{1} }} )\), \(Td_{kw} = (T_{q} (kw),I,D_{1} )\).

\(Search(Td_{kw} ,(CT,Ix(kw)))\): This algorithm is run by CSR, it runs Eq. (5) to get \(k_{kw}\).

$$\begin{aligned} k_{kw} & = \frac{{e(K_{1} ,T_{q} (kw))}}{{e(D_{1} ,K_{2} )}} \\ & = \frac{{e(g^{\eta } ,H_{a} (kw)g_{2}^{x} (g_{1} h)^{{r_{\varphi } \mu }} )}}{{e(g^{{r_{\theta } \mu }} ,(g_{1} h)^{\eta } )}} \\ & = \frac{{e(g^{x} ,g_{2} ) \cdot e(g,H_{a} (kw))^{\eta } \cdot e(g^{\eta } ,(g_{1} h)^{{r_{\varphi } \mu }} )}}{{e(g^{{r_{\varphi } \mu }} ,(g_{1} h)^{\eta } )}} \\ & = e\left( {g,g_{2} } \right)^{\eta x} \cdot e\left( {g,H_{a} (kw)} \right)^{\eta } \\ \end{aligned}$$
(4)

Then computes \(H_{b} (k_{kw} )\) and compares it with each of \(K_{i}\) in index Ix. If equals, CSR then tries to run pre-decrypt algorithm. Else CSR returns null value.

\(Pre - decrypt(CT,PK,SK_{out} )\): BC sends \(CT,PK,SK_{out}\) to CSR. If attributes in ciphertext match with \({\mathbb{A}}\) that corresponding to \(SK_{out}\)(\(SK_{out}\) can be found in \(Ix(KW)\)), CSR performs Eq. (5) to gain the pre-decrypted ciphertext \(Q_{pre}\), then CSR returns it to BC. Otherwise, CSR returns none. BC takes \(Q_{pre}\) with \(h^{\prime}\), \(p^{\prime}\), and returns them to DU.

\(Decrypt(Q_{pre} ,CT,PK,SK_{attr} )\): After receiving \(Q_{pre}\) from CSR, DU first performs Eq. (6) to get \(K_{aes}\). Then he/she downloads AES ciphertext \(M^{\prime}\) with \(p^{\prime}\), runs AES decryption, and gains plaintext \(PH^{\prime}\). DU compares \(H_{a} (PH^{\prime})\) with \(h^{\prime}\). If equals, indicating that \(PH^{\prime}\) has not been tampered with, otherwise \(PH^{\prime}\) will be discarded.

$$\begin{aligned} Q_{pre} & = \frac{{\mathop \prod \nolimits_{i \in S} e(C_{1} ,I_{{i_{0} }} )^{{{\Delta }_{i,S} (0)}} }}{{\mathop \prod \nolimits_{i \in S} e(I_{{i_{1} }} ,C_{i} )^{{{\Delta }_{i,S} (0)}} }} \\ & = \frac{{\mathop \prod \nolimits_{i \in S} e(g^{\eta } ,g_{2}^{f(i)} (g_{1} h_{i} )^{{r_{i} }} )^{{{\Delta }_{i,S} (0)}} }}{{\mathop \prod \nolimits_{i \in S} e(g^{{r_{i} }} ,\left( {g_{1} h_{i} } \right)^{\eta } )^{{{\Delta }_{i,S} (0)}} }} \\ & = \frac{{\mathop \prod \nolimits_{i \in S} e(g^{\eta } ,g_{2} )^{{f(i){\Delta }_{i,S} (0)}} \mathop { \cdot \prod }\nolimits_{i \in S} e(g^{\eta } ,(g_{1} h_{i} )^{{r_{i} }} )^{{{\Delta }_{i,S} (0)}} }}{{\mathop \prod \nolimits_{i \in S} e(g^{{r_{i} }} ,\left( {g_{1} h_{i} } \right)^{\eta } )^{{{\Delta }_{i,S} (0)}} }} \\ & = e\left( {g,g_{2} } \right)^{{\eta x_{a} }} \\ \end{aligned}$$
(5)
$$\begin{aligned} K_{aes} & = \frac{{C_{0} \cdot e(d_{{\theta_{1} }} ,C_{\theta } )}}{{Q_{pre} \cdot e(C_{1} ,d_{{\theta_{0} }} )}} \\ & = \frac{{K_{aes} e(g_{1} ,g_{2} )^{\eta } \cdot e(g^{{r_{\varphi } }} ,(g_{1} h)^{\eta } )}}{{e(g,g_{2} )^{{sx_{a} }} \cdot e(g^{s} ,g_{2}^{{x_{b} }} (g_{1} h)^{{r_{\varphi } }} )}} \\ & = \frac{{K_{aes} e(g^{x} ,g_{2} )^{\eta } \cdot e(g^{{r_{\varphi } }} ,(g_{1} h)^{\eta } )}}{{e(g,g_{2} )^{{\eta x_{a} }} \cdot e(g^{\eta } ,g_{2}^{{x_{b} }} ) \cdot e(g^{\eta } ,(g_{1} h)^{{r_{\varphi } }} )}} \\ & = \frac{{K_{aes} e(g^{x} ,g_{2} )^{\eta } \cdot e(g^{{r_{\varphi } }} ,(g_{1} h)^{\eta } )}}{{e(g,g_{2} )^{{\eta (x_{a} + x_{b} )}} \cdot e(g^{\eta } ,(g_{1} h)^{{r_{\varphi } }} )}} \\ \end{aligned}$$
(6)

5 Security and Performance Analysis

5.1 Security Proof

Compare with the scheme [25], our scheme utilizes distributed consortium blockchain rather than a centralized trusted authority to generate, manage master key and secret keys. We assume the consortium blockchain nodes always keep honest. Although there are some nodes that may betray, due to the PSS protocol, as long as no more than n nodes defected at the same time, the security of master key MK can still be guaranteed. The security of PSS protocol has been proved in [22]. We also use the integrity verification algorithm to check whether the data is tampered with.

Suppose that CSR is curious about security, with the help of available resources, CSR can recovery \(e\left( {g,g_{2} } \right)^{{\eta x_{a} }}\). But it still can’t restore \(e\left( {g_{1} ,g_{2} } \right)^{\eta }\) without getting \(x_{b}\) from \(SK_{attr}\). Under certain circumstances, the curious CSR and malicious user may collude to decrypt others’ data. However, due to the random division of MK, this collusion attack could be defended. Specifically, MK is randomly divided into different \(x_{a}\) and \(x_{b}\) for each user, and \(x_{a} + x_{b} = x\bmod p\). \(x_{a}\) is used for generating \(SK_{out}\), and \(x_{b}\) for \(SK_{attr}\). If and only if \(SK_{out}\) matches with \(SK_{attr}\), the ciphertext can be fully decrypted. Therefore, although CSR can get all users’ \(SK_{out}\), it cannot decrypt others’ ciphertexts without corresponding \(SK_{attr}\).

Theorem 1: Our scheme is RCCA security if DBDH problem can’t be solved in any polynomial-time.

The proof of security is not our main content, for a more detailed proof to outsourced attribute-based encryption, refer to Li et al. in [25]. Next, we give the security analysis to demonstrate the security of our system.

5.2 Security Analysis

Confidentiality:

Our scheme can meet the confidentiality requirements. Firstly, the patients’ EHRs are encrypted by AES with a random AES key, and the ciphertext is uploaded to IPFS for sharing. AES is a popular symmetric encryption algorithm whose security depends on the security of the AES key. However, the AES key is encrypted by attribute encryption. DU can obtain the AES key only if the attribute requirements set by the patients are met, then DU download the ciphertext from IPFS and decrypt it. The AES key is random for every ciphertext, even though DU decrypts a ciphertext, they cannot decrypt other ciphertext of this patient.

Integrity:

Comparing with [25], we have added an integrity verification step. Before encrypting EHRs, patients use the hash function like SHA-1 to calculate the message digest. After that, the message digest will be uploaded to the blockchain for recording. After DU downloads the decrypted data, the digest is calculated in the same way. Only if it is the same as the digest stored on the blockchain, which shows that the patients’ data has not been tampered with.

Non-repudiation:

In our scheme, blockchain is the central authority. All encryption, decryption, and access operations are recorded on blockchain. Because the data on the blockchain can’t be tampered, it is always possible to determine who accessed what data and when by querying the blockchain.

5.3 Performance Analysis

Our scheme is based on the java pairing-based cryptography library (JPBC) of version 1.2.1. For the consortium blockchain, we use version 1.4.4 of Hyperledger Fabric to build. And version 1.4.4 of fabric-java-sdk is used to execute the contract. More specifically, our system is deployed on a 64-bit Ubuntu 20.04 system with 3.4 GHz i7-6700 CPU and 8G RAM. Consortium blockchain architecture is configured for 2 organizations with total of 4 nodes, which can represent 4 medical institutions in 2 sectors. In terms of security, the elliptic curve in our scheme uses the default parameters provided by JPBC, which are based on the curve \(y^{2} = x^{3} + x\).

Fig. 2.
figure 2

Key generation time consumed.

Full size image

To simplify the experimental, we write the intermediate parameters of the PSS protocol on the blockchain. The master key and public key are generated later and can be queried directly from the chain. Figure 2 illustrates the user’s private key generation performance of our system. Note that this also includes the fabric-java-sdk initialization time, which is about 300ms.

Fig. 3.
figure 3

Pre-decryption time consumed

Full size image

In Fig. 3, the solid line indicates the time consumption only for pre-decryption at the local machine. Due to the constraints, note that we are only performing the pre-decryption computation with smart contract locally, rather than assigning it to CSR. The solid line can also represent the time consumed for pre-decryption on cloud servers. The dotted line here indicates that the smart contract performs the pre-decryption operation and all the nodes are involved in the endorsement. In contrast, the dashed line indicates that only one node executes the contract. We can conclude that endorsement will have some impact on the performance of key generation. However, there are few people who set 50 attributes on EHRs data. With attribute values limited to 15 or less, endorsements have a lesser impact on the system’s performance.

After simulation experiments, it is proved that our system is feasible in practice.

6 Conclusion

We propose a novel blockchain-assisted key generation electric health records sharing scheme. Compared to scheme [25], we remove the Decryption CSP, and replace Key Generation CSP, Storage CSP with BC and IPFS. While remove the TypeII-Adversary type attackers, our scheme is more suitable for sharing data among multiple organizations. To do this, we first encrypt the data with symmetric encryption, and then encrypt the symmetric encryption key with ABE. We also consider the possibility of tampering with the data stored on the cloud servers, and add the integrity verification phase. Hence, our scheme is safer and more practical than scheme [25].

In short, our scheme can meet the demand for secure sharing of EHRs among multiple healthcare institutions. In addition, it is also easily scalable, just add nodes on the blockchain.