A secure and efficient electronic medical record data sharing scheme based on blockchain and proxy re-encryption

Abstract

With the rapid development of the Internet of Medical Things (IoMT) and the increasing concern for personal health, sharing Electronic Medical Record (EMR) data is widely recognized as a crucial method for enhancing the quality of care and reducing healthcare expenses. EMRs are often shared to ensure accurate diagnosis, predict prognosis, and provide health advice. However, the process of sharing EMRs always raises significant concerns about potential security issues and breaches of privacy. Previous research has demonstrated that centralized cloud-based EMR systems are at high risk, e.g., single points of failure, denial of service (DoS) attacks, and insider attacks. With this motivation, we propose an EMR sharing scheme based on a consortium blockchain that is designed to prioritize both security and privacy. The interplanetary file system (IPFS) is used to store the encrypted EMR while the returned hash addresses are recorded on the blockchain. Then, the user can authorize other users to decrypt the EMR ciphertext via the proxy re-encryption algorithm, ensuring that only authorized personnel may access the files. Moreover, the scheme attains personalized access control and guarantees privacy protection by employing attribute-based access control. The safety analysis shows that the designed scheme meets the expected design goals. Security analysis and performance evaluation show that the scheme outperforms the comparison schemes in terms of computation and communication costs.

Introduction

An electronic medical record (EMR) is a computerized version of a patient’s previously paper-based medical records, encompassing medical history, lab results, and records of diagnosis and treatment [1]. The implementation of EMRs in medical institutions has enabled cross-regional accessibility of patient data, improved the quality of patient care, and reduced time costs. In addition, EMR sharing assists doctors in making more precise diagnoses and helps researchers develop new drugs or vaccines [2,3,4]. Therefore, EMRs are increasingly considered vital for the advancement of medical information [5].

Although electronic medical records have greatly improved healthcare, they still face many challenges when it comes to practical application. One inevitable challenge is the increased risk of medical data breaches in the EMR system when sharing or trading EMRs between medical organizations. Due to the inherently open nature of wireless channels, sensitive patient information such as addresses, ID numbers, and physiological data may be eavesdropped, tampered with, or disrupted by malicious attackers [6]. Furthermore, these exposed data can be traded for significant illegal gains. Additionally, many healthcare providers store EMRs on internal servers for quick access, which may be vulnerable to unexpected corruption or natural disasters. To address these complex problems, many cloud-based EMR systems [7, 8] have been introduced in recent years.

In general, cloud-based EMR systems encrypt patients’ EMRs and establish relevant access control policies before outsourcing them to the cloud. Users with different identity attributes then submit encrypted search keywords to the cloud server. By searching for keywords, the cloud server retrieves the ciphertext of the corresponding EMR and sends it to the user. Finally, users who satisfy the attribute requirements can successfully decrypt the ciphertext to access the appropriate EMR. This process demonstrates that cloud-based EMR systems ensure enhanced security for EMR storage and allow legitimate users to access the required data from anywhere, thus avoiding misuse of data.

However, the existing cloud-based EMR system relies on a central server to handle EMR and process inquiry requests, which presents significant drawbacks. First, the centralized model is susceptible to a single point of failure that renders the entire system inoperable. Second, the reliability of cloud servers can be questionable. Fortunately, the concept of distribution is increasingly gaining attention from researchers. Blockchain, a decentralized architecture technology, offers a new approach to solving these problems [9].

Blockchain technology has the potential to resolve security concerns associated with EMR data due to its decentralized nature. Additionally, it can help protect individual privacy and data security when sharing data in the healthcare domain. Despite the promising potential of a blockchain-based EMR sharing system, it still faces the following challenges:

• (1) How can patient privacy be protected on the blockchain while ensuring that they can verify and prove the authenticity of the shared EMR data?

• (2) How does the system set access control policies based on user attributes so that only authorized users can access a patient’s EMR?

• (3) How can we share a patient’s EMR using the Hyperledger Fabric system while ensuring data security?

  To address the aforementioned challenges, we propose a secure EMR sharing scheme with privacy protection using a consortium blockchain and proxy re-encryption in this paper. Specifically,

• (1) We design a scheme that combines attribute-based signature encryption (ABSE) with blockchain technology, which ensures the security of EMR data sharing. It allows for fine-grained access control and ensures that only authorized users can access and verify the authenticity of shared EMR data.

• (2) We propose a framework that employs the inter-planetary file system (IPFS) for distributed storage of ciphertexts of patients’ EMRs. Additionally, we utilize proxy re-encryption (PRE) to effectively mitigate the risk of collusion attacks and reduce the possibility of unauthorized access.

• (3) Comprehensive functionality and performance evaluation results show that the proposed scheme can achieve security requirements and outperform other existing schemes in terms of computation and communication costs.

  The remainder of this paper is structured as follows. Related work is introduced in Related work section. Section 3 outlines the preliminary work relevant to the proposed scheme. Our proposed scheme is presented in Sect. 4. In Sect. 5, we conduct a security analysis and performance evaluation. Finally, Sect. 6 summarizes our work as a whole.

Related work

• A Blockchain-based EMR data sharing schemes

  Since the emergence of blockchain technology, many EMR data-sharing schemes [10,11,12] have been proposed in recent years, which utilize its promising potential for privacy protection. For instance, Azaria et al. [10] proposed the first scheme to implement a decentralized electronic medical record management system using blockchain, called MedRec. However, Akkaoui et al. [11] pointed out that MedRec does not provide access policies and relies heavily on hospital databases. Therefore, they proposed a new data management framework called “EdgeMedichain” to share medical data more securely and efficiently. Liu et al. [12] constructed a scheme to share medical data on a private blockchain. However, Wang et al. [13] pointed out that private blockchain is not effective when sharing patients’ data among different healthcare organizations, so they proposed a patient-centered healthcare data-sharing system that implements querying a single keyword on the blockchain. However, the systems [13,14,15] are all implemented on Ethereum, whereas Rajput et al. [16] pointed out that the Ethereum system suffers from the weaknesses of inefficient transactions and higher energy consumption compared to Hyperledger Fabric. Thus, they utilized Hyperledger Fabric in their scheme. However, Chi et al. [17] pointed out that the scheme in [16] was limited by the scalability of the blockchain. Mani et al. [18] proposed a novel approach, known as patient-centric healthcare data management (PCHDM), for storing certain data on IPFS to address the issue of data storage on the blockchain. To provide complete privacy protection and efficient ciphertext retrieval for EMR, Liu et al. [19] proposed an inner product searchable encryption scheme with multi-keyword search based on blockchain. To solve the inefficiency of the existing scheme, Lin et al. [20] proposed a pairing-free and blockchain-friendly universal designated verifier signature proof (UDVSP) scheme. It is worth noting that the scheme is the first system with anti-malicious propagation to date. Driven by the above work, we have designed a trusted data-sharing framework utilizing Hyperledger Fabric and IPFS that supports personal privacy protection and gets rid of the blockchain’s scalability problem.

• B Applications of proxy re-encryption

  PRE is an encryption method that securely converts ciphertext without revealing any corresponding plaintext information during the conversion process. In the course of related research, many researchers have improved and innovated this algorithm [21,22,23]. Chu et al. [23] proposed allowing the proxy to convert the ciphertext into a set of delegates. Alice can then grant decryption privileges to the user, resulting in significant cost savings. But Shabisha et al. [24] pointed out that [23] is not suitable for some dynamic data sharing. Subsequently, they proposed a scheme using pairing-free proxy re-encryption that can store data in the cloud. Unfortunately, they just proposed the idea and did not practice it. Kan et al. [25] proposed the chosen-ciphertext attack (CAA) scheme, which allows for selected ciphertext attacks and reduces the cost of keys, thus preventing collusion attacks and ensuring distributed storage. However, Wang et al. [26] pointed out that although their scheme could prevent the leakage of confidential information, it needed to replace the key regularly, which increased the operating cost. Therefore, they proposed an improvement scheme that combined proxy re-encryption and searchable encryption to achieve a better cost reduction of keys. However, Mamta et al. [27] pointed out that storage costs had increased. Chen et al. [28] propose a new EMR system that utilizes proxy re-encryption to secure data on the consortium blockchain, thereby addressing the issue of data security. In order to protect user privacy, Qi et al. [29] presented a point-of-interest (POI) category recommendation model based on group preferences, which can capture users’ dynamic preferences to better recommend the POI categories. Liu et al. [30, 31] pointed out that the data in [29] is not encrypted at the root, and there is a risk of user privacy data leakage. Based on the above work, we also use the PRE algorithm to protect the data sharing authorization and consider combining it with IPFS and Fabric, achieving a secure and lightweight EMR sharing framework.

• C Blockchain-based EMR sharing schemes with access control

  Access control is widely recognized as a crucial method for ensuring secure and manageable sharing of EMRs. Many researchers have explored fruitful results [32,33,34] in this field. Attribute-based encryption (ABE) can be broadly categorized into two types, the first is key-policy attribute-based encryption (KP-ABE) [33] for biometric systems and the second is ciphertext-policy attribute-based encryption (CP-ABE) [34] for cryptographic storage systems. So many researchers have applied ABE to various scenarios based on blockchain. Sun et al. [35] proposed an attribute-based scheme that allows for cloud server data access through keyword searching. However, Guo et al. [36] pointed out that it is not feasible to verify the accuracy and completeness of the retrieved data. Consequently, they have devised an alternate scheme that encrypts the medical data employing CP-ABE technology and assigns distinct search privileges to different users. However, Xu et al. [37] pointed out that excessive searches can occasionally fail to validate all returned results, resulting in a waste of resources. Therefore, they proposed a scheme for decreasing the number of attribute encryptions and decryptions in a cloud environment, which permits effective data access control. However, Jiang et al. [38] pointed out that cloud servers are not entirely trustworthy. Egala et al. [39] proposed an efficient blockchain access system that employs a selection ring-based approach to attain data security. Wang et al. [40] designed a decentralized framework for secure EMR sharing. The scheme uses smart contract technology to build a trusted platform for medical centers to share encrypted EMRs. Driven by the above work, we combine blockchain and access control to achieve data traceability and integrity.

  To address the shortcomings of previous related work, we propose to store patients’ EMRs in IPFS and use proxy re-encryption to safeguard the data. To achieve controlled access to patients’ data, access logs of users with different attributes will also be uploaded to the consortium blockchain. Through comparative analysis and experimental simulations, our scheme can solve the aforementioned challenges in EMR systems and be practical in the real world.

Preliminary

Hyperledger fabric

Hyperledger Fabric is a platform based on blockchain technology, which can protect data through channels [16]. This platform allows participants to establish a subnet, and only relevant nodes can view the transactions of a specific set. In this way, smart contracts and processed data can only be accessed by authorized members, thus protecting the privacy and confidentiality of transactions.

Private data refers to data that can be aggregated among channel members, and they can be protected like channel data. This means that even if the data is aggregated, only authorized members can access them. This method can provide the same protection as the channel without the need to maintain and build a separate channel.

Interplanetary file system (IPFS)

IPFS replaces traditional domain-based addressing with content-based addressing, eliminating the need to worry about the location of servers or the storage path and name of files. Whenever a file is uploaded to an IPFS node, a unique encrypted hash value is generated based on the file’s content. The hash value reflects the file’s content, so even a slight change in a single bit will result in a different hash value. When IPFS receives a request for a file hash, it uses a distributed hash table to locate the corresponding file node and retrieve and verify its content data [18]. The most important feature of IPFS is its ability to retrieve content by completely transforming the lookup process.

Elliptic curve Digital signature algorithm (ECDSA)

ECDSA is mainly used to create digital signatures to verify the authenticity of data without affecting the security of data. It should be noted that ECDSA is not used to encrypt data or provide data access protection. Its purpose is to ensure that data is not tampered with during transmission.

The digital signature is a unique identification generated by applying mathematical algorithms to data, which is used to prove the integrity and identity of data. ECDSA uses elliptic curve cryptography to generate public key and private key pairs and uses the private key to sign the data. The signed data and the related public key can be publicly displayed without disclosing the private key. The receiver can use the public key to verify the authenticity of the signature, to determine whether the data has been tampered with.

In short, ECDSA ensures the integrity of data using digital signatures and can verify the authenticity of data even during transmission. This section provides an overview of the standard process of the ECDSA algorithm for generating key pairs and private key signatures.

Symbol Definition:

The parameter of elliptic curve $E$ is defined as $params= (p, a, b, G, n)$, where $a$ and $b$ are parameters of the elliptic curve equation, $p$ is a major prime number, the operation of coordinates $x$ and $y$ on the elliptic curve is uniform modulus $p$, $G$ is the base point of the elliptic curve $({G}_{x}, {G}_{y})$, $n$is the order of $G$ on the elliptic curve, and [$k$]$P$ represents the k-fold point of $P$ on the elliptic curve.

Signature process:

• (1) Select an elliptic curve ${E}_{P}$, and a base point $G$.

• (2) Generate a random private key ${SK}_{A}$ and use $G$ to compute the public key ${PK}_{A} = {SK}_{A}G$.

• (3) Generate a random integer $k$ ($k<n$, $n$ is the order of $G$) and compute the point $\left({x}_{q}, {y}_{q}\right)=kG$.

• (4) Let $Q={x}_{q}\%n$ and compute $T=\frac{H+Q*{SK}_{A}}{k}\%n$.

• (5) Get signature ($Q, T$), if $Q$ is 0 then re-select the random number $k$ to compute again.

Verification process:

• (1) After receiving the message $m$ and the signature value $(Q, T)$.

• (2) $\text{C}\text{o}\text{m}\text{p}\text{u}\text{t}\text{e} {u}_{1} = \left(H mod n\right)/T, { u}_{2}= \left(Q mod n\right)/T$.

• (3) Calculate the point $\left({x}_{v},{y}_{v}\right)={u}_{1}*G +{u}_{2}* {PK}_{A}$.

• (4) Verify the equation: $Q= {x}_{v} mod n$.

• (5) If holds, $(Q, T)$ is accepted, otherwise $(Q, T)$ is invalid.

Proxy Re-encryption (PRE)

In proxy re-encryption based on elliptic curves, we designate $E$ as an elliptic curve over a finite field ${F}_{q}$, where $q$ is a large prime number, and $G$ is a point on the elliptic curve $E$ of order $n$ [41]. Let ${G}_{1}$ and ${G}_{2}$ be two cyclic groups of multiplication with the prime modulo $n$. We can describe the bilinear map $e : {G}_{1} \times {G}_{1} \to {G}_{2}$, such that $z = e({G}_{1},{G}_{1}) \in {G}_{2}$ [42]. The following properties are met:

• (1) Bilinear: For any $a,b\in { Z}_{p}^{*}$ and $x, y \in { G}_{1}$, $e ({x}^{a}, {y}^{b})=e {(x, y)}^{ab}$ holds;

• (2) Non-degenerate: There exists $x, y \in { G}_{1}$ such that $e (x,y)\ne 1$;

• (3) Computable: For any $x, y \in { G}_{1}$, there exists an effective algorithm to compute$e (x, y)$.

Proxy re-encryption is a secure encryption technology, which can help users to achieve more flexible operations in the process of transforming ciphertext while maintaining data confidentiality. Specifically, PRE allows user A to encrypt and upload the ciphertext using the public key, and then convert the ciphertext to another format. In this way, user B can decrypt the new ciphertext with its private key, while ensuring the confidentiality of any corresponding plaintext during the whole conversion process.

In short, PRE provides a way to encrypt and decrypt data, so that the owner of the data can operate without directly exposing the plaintext. By using PRE, users can choose to convert the ciphertext to different formats, so that other users can decrypt and obtain plaintext using their private key. This method provides higher flexibility and security because the ciphertext can be decrypted by multiple users without disclosing the plaintext content:

• (1) Key generation algorithm $KeyGen \left(G\right)\to ({PK}_{A}, {Sk}_{A}, {PK}_{B}, {Sk}_{B})$: When the system public parameter $G$ is inputted, the algorithm produces a public-private key pair ($PK, SK$) for the user.

• (2) Encryption algorithm $Enc (G, M, {PK}_{A}) \to {C}_{A}$: When “$G$”, the plaintext message “$M$” in the information space and “${PK}_{A}$” are entered into the algorithm, the algorithm generates the ciphertext “${C}_{A}$” encrypted by “${PK}_{A}$”.

• (3) Rekey generation algorithm $ReKeyGen ({Sk}_{A}, {PK}_{B}) \to {rk}_{A\to B}$: A transformation key ${rk}_{A\to B}$ for one-way re-encryption between user A and B is generated by the algorithm using ${Sk}_{A}$ and ${PK}_{B}$.

• (4) Re-encryption algorithm $ReEnc ({C}_{A}, {rk}_{A\to B}) \to {C}_{B}$: The operation converts ${C}_{A}$ to ${C}_{B}$ and sends it to user B. Then, ${C}_{B}$ can be decrypted by user B with their private key ${Sk}_{B}$.

• (5) Decryption algorithm $Dec ({C}_{B}, {Sk}_{B}) \to M$: When ${Sk}_{B}$ and ${C}_{B}$ are inputted, the algorithm produces the corresponding plaintext M.

Attribute-based signature encryption (ABSE)

ABSE technology is a method for information encryption, which allows the encrypting party to specify the access policy and express it as an access structure. This access structure describes the set of attributes required to understand the secret party. Only when the decrypting party has a set of attributes that meet the requirements of the access structure can the information be decrypted successfully.

In short, ABSE technology is an encryption method that can restrict the decryption permission according to the decryption Party’s attributes. For example, suppose a file is encrypted, and decryption of the file needs to meet certain conditions, such as age over 18, position as a doctor, etc. Only those who meet these conditions can decrypt the file.

By using the ABSE technology, the encrypting party can more accurately control the access rights of information and ensure that only qualified personnel can decrypt sensitive information. This is important for protecting confidential data and privacy:

• (1) $Setup$: This algorithm is executed by system and is mainly used to generate public key$PK$ and private key $SK$.

• (2) $Encrypt$: This algorithm is executed by the data owner and uses access structures to encrypt plaintext, generating ciphertext.

• (3) $KeyGen$: This algorithm is executed by system and generates the key $SK$ based on the attribute set $S$ provided by the data user.

• (4) $Decrypt$: This algorithm is executed by the data user, using $SK$ to decrypt the ciphertext and obtain the plaintext.

System model

Figure 1 shows the EMR sharing system model of our proposed scheme, which is based on Hyperledger Fabric and IPFS. There are four entities in the system, i.e., Hospital blockchain system (HB), Doctor (D), Patient (P), and IPFS.

Fig. 1

System model

Hospital blockchain system (HB)

Hospital blockchain system consists of multiple medical institutions, e.g., the general hospital, and specialized hospital. Its functions include distributed storage capabilities, digital identity certification, user identity management, and signature verification. It is built on Hyperledger Fabric and pre-deployed chain codes such as signature verification. Any user (e.g., a doctor, or a patient) who needs services of the consortium system must register with it first.

Doctor (D)

When the doctor requests a patient’s medical records for further diagnosis and treatment, he sends the patient a request for access through HB. After the reception of the patient’s authorization, the doctor can use the obtained hash address to query the patient’s EMR in IPFS to diagnose the patient.

Patient (P)

The patient is the owner of the personal electronic medical record. They upload encrypted EMRs to IPFS for storage. In addition, the patient is responsible for giving the doctor permission to access his EMR according to configurable access policies.

Interplanetary File System (IPFS)

IPFS can store a patient’s EMR and return hashes when the patient uploads an encrypted EMR. Moreover, the patient submits these hashes to the chain, a process that enables decentralized data storage. Once the doctor’s access is approved, the doctor can retrieve the patient’s corresponding EMR from the IPFS by getting the hash value from the patient’s authorization information.

The proposed scheme

The main notations and corresponding definitions are listed in Table 1.

Table 1 Notations

System overview

According to the system model in Fig. 1, the workflow of the proposed scheme is as follows.

• Step 1: Doctors and patients are required to register through HB. When a registration request is received, HB creates public-private key pairs and digital certificates for every user and sends them to the corresponding recipients. It is worth noting that every certificate contains a specific set of predetermined characteristics, which includes role.

• Step 2: The EMR is encrypted by the patient and then uploaded to IPFS storage. Following that, patients sign the information returned by IPFS to upload it to the blockchain.

• Step 3: The doctor desires to access the patient’s EMR and initiates an access request to HB. Subsequently, the HB assesses compliance with the access policy before granting the request. If the HB grants approval, the patient receives the request message from the doctor. Subsequently, the patient utilizes the doctor’s public key to execute a proxy re-encryption algorithm and sends the resulting data back to the HB. The doctor receives the patient’s authorization information through HB and gets the ciphertext for the patient’s corresponding EMR on IPFS using the hash value. Finally, the doctor can decrypt the EMR with his private key.

Construction of the proposed scheme

Registration phase

During the registration phase, all users must register via HB. The registration phase is presented in Fig. 2. The specific steps are described as follows:

• Step 1. To register, User X registers through the client and sends the registration information ${Info}_{X}$ to HB.

• Step 2. Upon validation of user X’s registration information, HB returns the key pair ${(SK}_{X},{PK}_{X})$ and the user’s certificate ${Cert}_{X}$ to user X, where ${PK}_{X} = {SK}_{X}G$.

• Step 3. The user X saves ${({Info}_{X},SK}_{X},{PK}_{X},{Cert}_{X})$.

Fig. 2

Registration phase

EMR storage phase

During the EMR storage phase, the patient first encrypts the EMR source files and stores them in IPFS. Subsequently, the returned message is signed and uploaded to the blockchain. Figure 3 illustrates the flowchart of this phase.

Fig. 3

EMR storage phase

First, patient P is required to encrypt his EMR and upload its ciphertext to IPFS. The specific process is as follows:

• Step 1: The Patient P first constructs a function on the medical record data ${m}_{{P}_{i}}$.

  $$P{m}_{{P}_{i}}=f\left({m}_{{P}_{i}}\right)$$

  (1)

Then choose a random number ${k}_{1}$ to encrypt ${m}_{{P}_{i}}$, obtaining the ciphertext.

$$({C}_{A} , {C}_{B}) = ({k}_{1}{PK}_{{P}_{i}} , {z}^{{k}_{1}}G+P{m}_{{P}_{i}})$$

(2)

• Step 2: P packages his EMR-related information.

$${M}_{{P}_{i}}=({Info}_{{P}_{i}},({C}_{A},{C}_{B}\left)\right)$$

(3)

Then, P randomly selects a random number ${k}_{2}$ and invokes the general signature algorithm of ECDSA to generate a signature $({Q}_{{P}_{i1}}, {T}_{{P}_{i1}})$ on ${M}_{{P}_{i}}$:

$${H}_{{P}_{i1}}=hash\left({M}_{{P}_{i}}\right)$$

(4)

$${ Q}_{{P}_{i1}}={x}_{q}\%n$$

(5)

$$if \left({Q}_{{P}_{i1}}!= 0\right)$$

(6)

$${T}_{{P}_{i1}}=\frac{{H}_{{P}_{i1}}+{Q}_{{P}_{i1}}*{SK}_{{P}_{i}}}{k2}\%n$$

(7)

• Step 3: P sends $({ Q}_{{P}_{i1}}, {T}_{{P}_{i1}})$ and ${M}_{{P}_{i}}$ to IPFS for storage. Once received by IPFS, it will calculate ${H}_{{P}_{i2}}$ and return ${H}_{{P}_{i2}}$ to P.

$${H}_{{P}_{i2}}=hash\left({J}_{{P}_{i}}\right)$$

(8)

• Step 4: Once P receives ${H}_{{P}_{i2}}$ from IPFS, P will select a random number ${k}_{3}$ and call the ECDSA signature algorithm to generate a signature $({ Q}_{{P}_{i2}}, {T}_{{P}_{i2}})$.

$$({ Q}_{{P}_{i2}}, {T}_{{P}_{i2}})= Sign ({H}_{{P}_{i2}}, {k}_{3},{SK}_{{P}_{i}})$$

(9)

After that, P will upload the signed ${H}_{{P}_{i2}}$ to HB for storage.

• Step 5: Once the HB system receives ${H}_{{P}_{i2}}$ and $({ Q}_{{P}_{i2}}, {T}_{{P}_{i2}})$ sent by the patient, the nodes participating in the consensus in the HB system will calculate the hash value of the transaction ${H}_{{P}_{i2}}$ and call the verification algorithm to verify the validity of the signature $({ Q}_{{P}_{i2}}, {T}_{{P}_{i2}})$ sent by the patient.

If the signature is valid, the consistency node puts it into the data transaction pool. After some time, the sorting node packs valid transactions into a block and submits them to the network.

Request for data access phase

To conduct further diagnosis, the doctor submits an access request to the HB to obtain permission to access the patient’s EMRs. Subsequently, the HB processes the access request according to the access policy. The specific steps are shown in Fig. 4.

Fig. 4

Request for data access phase

• Step 1: Doctor D generates the request message:${Req}_{{D}_{i}} ( I{nfo}_{{D}_{i}} , {Cert}_{{D}_{i}} , operation , object , timetamp)$. Then, he selects a random number ${k}_{4}$ and calculates${H}_{{D}_{i1}}$ and $({Q}_{{D}_{i1}}, {T}_{{D}_{i1}})$.

• $${H}_{{D}_{i1}} = hash \left({Req}_{{D}_{i}}\right)$$

  (10)

$$({Q}_{{D}_{i1}}, {T}_{{D}_{i1}}) = Sign ({H}_{{D}_{i1}}, {k}_{4}, {SK}_{{D}_{i}})$$

(11)

Then doctor D sends the request information to the patient p through the HB system.

• Step 2: Once HB receives the message ${H}_{{D}_{i1}}$ and$({Q}_{{D}_{i1}}, {T}_{{D}_{i1}})$ sent by the doctor, it will immediately verify the signature $({Q}_{{D}_{i1}}, {T}_{{D}_{i1}})$.

The values of the “role”, “object”, “operation”, and “time” fields are read by HB, depending on the access policy.

$$Policy \left(Role object operation Time\right)\to allow$$

(12)

If the output allows, it indicates that access is possible; otherwise, the access request is denied.

• Step 3: Once patient P receives the requested information from doctor D through the HB system, patient P will be able to obtain the public key ${PK}_{{D}_{i}}$ of doctor D from the information ${Req}_{{D}_{i}}$, to set the re-encryption key ${rk}_{{P}_{i}\to {D}_{i}}$ in combination with its private key ${SK}_{{P}_{i}}$.

$${rk}_{{P}_{i}\to {D}_{i}} = {{SK}_{{P}_{i}}}^{-1}{PK}_{{D}_{i}}$$

(13)

Then patient P selects a random number ${k}_{5}$ to re-encrypt the ciphertext to get $({C'}_{A},{C'}_{B})$, and patient P stores $({C'}_{A},{ C'}_{B})$ in IPFS.

$$({C'}_{A},{ C'}_{B})=\left(e\right({k}_{5}{PK}_{{P}_{i}},{rk}_{{P}_{i}\to {D}_{i}}),{z}^{{k}_{5}}G+{Pm}_{{P}_{i}})$$

(14)

• Step 4: Once doctor D receives the patient P’s authorization message ${Aut}_{{P}_{i}}$ through the HB system, doctor D can obtain the hash address of patient P’s encrypted EMR and find the corresponding EMR on IPFS. Because patient P has set the key for proxy re-encryption, doctor D can decrypt the EMR using the private key ${SK}_{{D}_{i}}$.

$${Pm}_{P_i}={C'}_B-\left({C'}_A\right)^{1/{SK}_{D_i}}\ast G$$

(15)

$${m}_{{P}_{i}} ={ f}^{-1}\left({Pm}_{{P}_{i}}\right)$$

(16)

Analysis and performance evaluation

Functional analysis

This subsection presents an informal functional analysis of the proposed scheme and compares it with previous schemes [18, 28, 39] in terms of several common features. Table 2 presents the comparison results. The symbol √ indicates that the scheme supports that function, and the symbol indicates that it does not. It can be seen from Table 2 that the proposed scheme is superior to other protocols in terms of functional features.

Data integrity

Ensuring data integrity, the proposed scheme utilizes ECDSA for signing and verifying the information. In addition, proxy re-encryption can convert encrypted data from one key to another while ensuring that user A’s private key is not leaked, and authorize user B to use his own private key to decrypt the ciphertext. This can protect the privacy of both the sender and receiver, ensuring the security of the data.

We take the transaction ${J}_{Pi}$ to be stored in blockchain as an example. After patient P signs ${H}_{{P}_{i2}}$ using ECDSA, a signature $\left({Q}_{{P}_{i2}}, {T}_{{P}_{i2}}\right)$ is generated and sent to HB. HB can verify whether $\left({Q}_{{P}_{i2}}, {T}_{{P}_{i2}}\right)$ is legal through ECDSA’s verification algorithm.

$$\left({Q}_{{P}_{i2}}, {T}_{{P}_{i2}}\right)= Sign \left({H}_{{P}_{i2}}, {k}_{3},{SK}_{{P}_{i}}\right)$$

(17)

$${u}_{1} = \left({H}_{{P}_{i2}} mod n\right)/{T}_{{P}_{i2}}$$

(18)

$${ u}_{2}= \left({Q}_{{P}_{i2}} mod n\right)/{T}_{{P}_{i2}}$$

(19)

$$\left({x}_{v},{y}_{v}\right)={u}_{1}*G +{u}_{2}* {PK}_{{P}_{i}}$$

(20)

Further, tapering any data in the blockchain at this point requires extremely expensive computing power, which is impractical in the real world. Based on the above analysis, the proposed scheme can ensure the integrity of the data.

Access control

In the proposed scheme, if the doctor needs to access the patient’s electronic medical records, he needs to submit an access request to HB first. Only after HB has passed the verification according to the visitor’s attributes can the doctor have access to the patient’s electronic medical records. Unauthorized users can’t access electronic medical records. Therefore, this scheme not only realizes access control but also protects patients’ privacy and data security.

Traceability

The traceability of the proposed scheme is achieved by using the blockchain’s distributed ledger and encryption algorithm. Specifically, each block contains the hash value of the previous block, thus forming a tamper-proof chain. This mechanism ensures that previous transactions cannot be tampered with. Subsequent blocks rely on the information of the previous block, and tampering is detected and rejected by other nodes.

After the doctor has checked the patient’s EMR, because the doctor has previously sent a request to the patient, an interactive process occurs. If the patient’s condition suddenly deteriorates, due to the traceability of the system, the doctor who has previously treated the patient can be found faster through signature verification, so that the patient can receive treatment in a shorter time.

$${H}_{{P}_{i4}}= hash\left({Aut}_{{P}_{i}}\right)$$

(21)

$$({Q}_{{P}_{i3}}, {T}_{{P}_{i3}}) = Sign ({H}_{{P}_{i4}}, {k}_{6}, {SK}_{{P}_{i}})$$

(22)

$$Verify({H}_{{P}_{i4}},{Q}_{{P}_{i3}}, {T}_{{P}_{i3}})$$

(23)

Through the above analysis, the proposed scheme can ensure the traceability of data.

Scalability

In the on-chain database, hash values of EMRs instead of operation logs are recorded in Hyperledger Fabric. The proposed scheme uploads ${H}_{{P}_{i2}}$of the patient’s data address stored in IPFS to HB, and the doctor can obtain ${H}_{{P}_{i3}}$ from HB after the patient’s authorization, so that the patient’s EMR can be viewed. In the off-chain solution, the actual EMRs are encrypted and stored securely through IPFS, which ensures the scalability of the HB system. In the proposed scheme, the patient stores the encrypted ${M}_{{P}_{i}}$ in IPFS. After re-encryption by proxy, the doctor can use his private key to obtain the patient’s ${M}_{{P}_{i}}$ in IPFS.

Based on the above analysis, the proposed scheme can ensure scalability.

Table 2 Comparison of functionality

Security analysis

In this subsection, the proposed scheme is proved to be insusceptible to some widely known attacks with an informal security analysis.

• Resistance to Replay Attack. In our scheme, random numbers and timestamps are used for each round of interaction. Due to the randomness of the random number and the freshness of the timestamp, the replay behavior will be accurately judged. Therefore, the proposed protocol withstands the replay attack.

• Resistance to Man-in-the-Middle Attack. Because of the open nature of wireless channels, adversary can intercept messages in transit. If the adversary wanted to tamper with the intercepted message, it would need random numbers and associated private keys, which is impossible to achieve. Therefore, the proposed protocol withstands the man-in-the-middle attack.

• Resistance to Stolen Verifier Table Attack. The proposed scheme adopts the blockchain technology of distributed architecture, no entity needs to maintain the verifier table, which avoids the risk of the verification table being stolen. Therefore, the proposed protocol withstands the stolen verifier table attack.

• Resistance to Collusion Attack. The proposed scheme computes the re-encryption key ${rk}_{{P}_{i}\to {D}_{i}}$ by utilizing ${SK}_{{P}_{i}}$ of patient and ${PK}_{{D}_{i}}$ of doctor. Furthermore, patient’s key is well protected by the PRE algorithm. Therefore, our proposed scheme is well protected against collusion attacks.

Computation cost

In this subsection, we evaluate the performance of the proposed scheme by comparing the computation cost. To facilitate the comparison of the computation costs between the proposed scheme and other related solutions, we first define the execution time of various cryptographic operations involved in the scheme. Let ${T}_{eo}$, ${T}_{so}$, ${T}_{ho}$,${ T }_{vo}$, ${T}_{do}$, ${T}_{rk}$,${ T}_{reo}$ respectively represent the time to execute an encryption operation, signature operation, hash operation, verification operation, decryption operation, re-encryption key operation, and re-encryption operation. Table 3 shows the comparison results of computation costs between the proposed scheme and related schemes in terms of data storage and data access phases.

It can be seen from Table 3 that the computational overhead of the proposed scheme in the data storage phase and data access phase is lower than that of several other related schemes. This is because, in the traditional way of data storage and access, data usually needs to be stored locally or on the server, and read and accessed according to the demand. This method has some problems. For example, when the amount of data is large, the capacity of local storage or server may be insufficient. At the same time, in the process of data interaction, a large number of computing operations are required, which increases the computer overhead of the user. This paper uses IPFS for data storage and sharing. In the process of interaction, some computing operations are transferred to IPFS, which reduces the computer overhead of the user. In contrast, IPFS adopts a distributed storage method, which stores data blocks on each node and uses a hash pointer for data access, which can effectively solve the problems of capacity and access speed in traditional storage methods. In IPFS, the storage and access operations of data are carried out between nodes, not on the client side, so it can reduce the computational burden on the client side.

To sum up, the scheme proposed in this paper uses IPFS distributed storage and sharing technology to reduce the computational overhead of the user in the process of data storage and access, to improve the performance and efficiency of the system.

Table 3 Computation cost

Communication cost

In evaluating the performance of a scheme, communication overhead is also another important factor. In this section, we will compare the communication overhead of the proposed scheme with other existing schemes. We assume that the sizes of ECDSA signatures, private/public keys, hash values, transactions, and requests are 256 bits, 256 bits, 160 bits, 1024 bits, and 1024 bits respectively, while other information is 80 bits. The comparison results of communication costs are shown in Table 4.

By utilizing the IPFS mechanism for storage and access, the proposed scheme effectively reduces communication overhead. Let’s take the communication costs of the proposed scheme in the data storage phase and data access phase as examples. Firstly, in the data storage phase, the patient needs to send encrypted medical record information to IPFS for storage, including encryption, signature, and request verification, with a size of 80 bits + 256 bits + 1024 bits = 1360 bits. Then IPFS returns the hash value to the patient and uploads it to HB for storage, including hash value, signature, verification, and other information, with a size of 160 bits + 256 bits + 1024 bits + 80 bits = 1520 bits. The message length in the data storage phase is 1360 bits + 1520 bits = 2880 bits.

Next, in the data access phase, the doctor needs to send a request to the patient, including signature, hash value, request message, and other messages, with a total size of 256 bits + 160 bits + 1024 bits + 80 bits = 1520 bits. The patient sends signature information, transaction information, key information, hash value, and other information, totaling 256 bits + 160 bits + 1024 bits + 80 bits = 1520 bits. Then the doctor accesses IPFS to retrieve the EMR information using the hash address and decrypts it into 256 bits using the private key. The message length in the data access phase is 1520 bits + 1520 bits + 256 bits = 3296 bits.

Table 4 Communication cost

Conclusions

To ensure the secure storage and sharing of EMRs, a secure and efficient sharing scheme based on blockchain and proxy re-encryption was proposed. Our scheme combines IPFS and proxy re-encryption. In addition, the scheme uses attribute-based personalized access control on the blockchain to enhance security. Security analysis and performance evaluation show that the proposed scheme can satisfy security requirements and outperforms the existing schemes in terms of computation and communication overhead. In future work, we will develop a prototype system to apply this scheme to real smart medical scenarios.