Abstract
Electronic medical records (EMR) have been commonly used in medical institutions in recent years. In particular, the combination of EMR and the cloud server has significantly improved the work efficiency and therapeutic level of the hospital. It also raises some security concerns, e.g., the information leaks. Blockchain has features including decentralization, traceability, openness, and tamper resistance. Therefore, the technology may be used to overcome the above flaws. In this paper, we introduce a new blockchain-assisted EMR in the cloud environment by using proxy reencryption and sequential multisignature. Firstly, blockchain makes the scheme have high-security performance without a trusty center. Secondly, we use proxy reencryption to protect personal medical data while helping doctors to access patients’ historical medical records. Moreover, the doctors have used a sequential multisignature, which is practical and can effectively improve security performance. The analysis results show that the proposed scheme can satisfy various security features of EMR and has an ideal computational and communication cost. Finally, the scheme is implemented to show its performance.
1. Introduction
With the full application of modern information technologies such as big data, cloud computing, and artificial intelligence in the medical field, medical informatization has exerted a significant influence on the optimal allocation of medical resources [1, 2]. EMR has emerged from this context, and it uses electronic devices (such as computers and smartphones) to store, manage, and transmit digitized medical records [3]. It can significantly enhance the work efficiency and therapeutic level of the hospital [4]. Also, EMR provides a judgment basis for dealing with medical malpractice [5]. When a patient goes to see a doctor, his/her medical history can help the doctor make an accurate diagnosis. However, most patients are often unable to detail their medical history due to long-time intervals and a lack of relevant expertise. It will affect the current diagnosis and increase the fiscal burden. Therefore, an ideal EMR should be able to help doctors timely obtain complete and accurate historical medical information. Furthermore, security and privacy preservation are crucial in EMR since medical information is sensitive and personal [6, 7].
EMR has developed significantly in recent years of its remarkable advantages, such as transmitting fast and easy to use [8, 9]. Notably, the emergence of cloud storage is a new milestone in the development of EMR [10]. They move medical data from the traditional data center to a cheaper and safer cloud server. It can improve work efficiency and allow hospitals to invest more time and resources in diagnosis and care. Thus, researchers proposed many cloud-assisted EMR architectures in recent years. However, the privacy, confidentiality, and integrity of medical data will face more threats since the data is outsourced to a third party, i.e., the cloud [11]. For example, doctors can collude with the cloud server to modify their erroneous diagnoses in medical malpractice. So, how to improve the efficiency of data storage and data sharing while ensuring data security and protecting patient privacy is the focus of research [12, 13]. It is necessary to design a lightweight, efficient, and secure EMR system.
Blockchain technology was introduced in 2008 [14]. It is a decentralized distributed (distributed in multiple locations and able to work together) database system. Blockchain has features of decentralization, tamper-resistant, openness, autonomy, and traceability. It can effectively overcome the adverse effects of centralization and reduce the cost of trust [15]. Therefore, blockchain may be a promising assisted technology of EMR, and it has received attention [16]. However, when blockchain technology is applied to the medical industry, it must be measured between improving efficiency and reducing cost. Only when appropriate blockchain technology is adopted and the system efficiency and operating cost are well balanced, can the business model be established. In addition, many problems are still unsolved before satisfying the practical application in recurrent [17, 18]. For example, (1) the data owner usually encrypts the data with the public key of the user or the session key of both parties, which leads to weak data sharing; (2) only the diagnosis of a single doctor was considered, regardless of a situation in which multiple doctors consult; (3) the cost of computing, communication, and storage is too high.
In this paper, we propose a blockchain-assisted EMR in the cloud environment by using proxy reencryption and sequential multisignature, and we call it BC-EMR. In BC-EMR, a group key and a sequential multisignature are utilized to enhance data security (a diagnosis may be made by a doctor or multiple doctors) [19]. Proxy reencryption helps doctors to access patients’ historical medical records while protecting data [20]. Especially, blockchain technology has enabled BC-EMR to overcome many flaws in general cloud-assisted EMR and dramatically improve security [21]. BC-EMR has an ideal computational and communication cost. The main contributions are listed as follows: We establish a group key between a hospital’s server and the doctors of one team utilizing a lightweight one-to-many authentication protocol. It can protect the patient’s information. We propose a blockchain-assisted EMR in the cloud environment by using proxy reencryption and sequential multisignature. The proposed scheme not only can realize the safe storage of data but also make secure data sharing between doctors at different hospitals. The security analysis of BC-EMR is given. The results show that BC-EMR can satisfy various security features. It also can fend off some specific threats, such as illegal cooperation between doctors and the cloud. Finally, we compare the computational and communication cost of BC-EMR with three existing schemes and then have implemented BC-EMR.
The remainder of the paper is organized as follows. In Section 2, we introduce related works. The preliminaries are presented in Section 3. In Section 4, we introduce the details of BC-EMR. In Section 5, the security analysis of BC-EMR is given. In Section 6, we evaluate the performance of BC-EMR and implement it. Finally, we conclude our paper in Section 7.
2. Related Works
Ekblaw et al. [22] used the Ethereum platform to realize MedRec that is a medical information sharing platform combining medical blockchain and big data. The system makes use of blockchain, the embedded authentication system, the security system, and an accountability system, which can provide users with powerful security technology when dealing with sensitive information. Xia et al. [23] proposed a blockchain-based health data sharing architecture that only allows the invited (verified) users to access. Thus, it solves many of the access control challenges associated with sensitive data. They have also come up with a system called MeDShare in [24]. The scheme deals with the problem of sharing medical data with big data custodians in untrusted environments. It uses smart contracts and access control mechanisms to track data behavior. Xue et al. [25] proposed a medical blockchain system by combining the medical server and auditing server. Zhang et al. [26] used a hospital-owned private blockchain to store patients’ health data, and the consortium blockchain to store safety indexes for personal health data. In particular, the authors have described the details and implemented the scheme on JUICE. In [27], Ivan analyzed the feasibility of using blockchain to protect health data, the implementation barriers, and specific plans for transitioning from current technology to blockchain solutions. Cao et al. [28] proposed a secure cloud-assisted EMR. This scheme utilizes Ethereum platform-based blockchain to protect outsourced medical data. Because every operation of the EMR is put into the blockchain as a transaction, it has excellent security. Esposito et al. [29] comprehensively analyzed the potential of blockchain to protect medical data in the cloud. They also pointed out the practical challenges and future works. Israa et al. [30] elaborated on the benefits and threats of blockchain technology in healthcare. Abdellatif et al. [31] introduced a new smart and safe healthcare system, which takes advantage of edge computing and blockchain to allow for epidemic detection and remote monitoring. The system also allows for the secure exchange of medical data between local medical entities. Shen et al. [32] analyzed the topological relationship among participants in the process of income distribution and established some Shapley value models from simple to complex. Based on the analysis of distribution rules, the incentive effect of secure data sharing and the rationality of the design scheme is discussed. Patil et al. [33] proposed an efficient blockchain authentication protocol for the Internet of Things based on the secret computational model of a physically unclonable function, which can guarantee data provenance and data integrity. Based on the elliptic curve digital signature algorithm, Xiong et al. [34] introduced an efficient and large-scale batch verification scheme with group testing technology for blockchain-enabled IoMT. Zhang et al. [35] proposed a reliable and efficient system based on edge computing and blockchain. Simulation results show that the proposed method has better computational efficiency and higher reliability than the existing methods. Cheng et al. [36] designed a blockchain-based data-sharing network model for medical cyber-physical systems and used BAN logic to analyze security protocols. Saini et al. [37] built an access control framework based on smart contracts, which is built on top of distributed ledger (blockchain) to ensure EMR sharing between different entities involved in smart healthcare systems.
In Table 1, we give a comparison between the different schemes introduced above. For convenience, we let F1, F2, F3, F4, and F5 denote payment for the blockchain platform, consensus mechanism and reduce the pressure for the main chain, the demand for calculating power, and the private blockchain.
3. Preliminaries
3.1. Blockchain
Blockchain is a novel application of distributed data storage, peer-to-peer transmission, and consensus mechanism, etc. [38]. As shown in Figure 1, a blockchain system consists of many blocks, and each block contains a block header and a block body. The block header includes the hash value of the current block, the timestamp, the hash value of the previous block, and so forth. Block body stores some transaction records. Its main characteristics are listed as follows:(1)Decentralization: there are numerous nodes distributed in the blockchain network, which can be freely connected to exchange information without any third institution.(2)Tamper resistance: after the information is added to the blockchain by consensus mechanism, all nodes will record it. Each block contains the hash value of the previous block. If a block’s data is modified, all the blocks behind that block need to be changed, which is almost impossible.(3)Traceability: blockchain stores all data through the block data structure, and any data stored in the blockchain can trace its origin through the chain structure.(4)Openness: any node can get the ledger of the whole network. Except for the information of the parties directly related to the data being encrypted by asymmetric encryption technology, other data is open to all nodes.(5)Autonomy: the use of a consensus mechanism in blockchain enables all nodes in the whole system to freely and securely exchange, record, and update data.
3.2. The Basic Requirements of EMR
(1)Security and Privacy Preservation. (a) The system can resist malicious attacks on medical data such as forgery attacks, modification attacks, replay attacks, guess attacks, man-in-the-middle attacks, and trackable attacks. (b) Nonrepudiation. The participants cannot deny the historical data generated by themselves. (c) Confidentiality. The data transmitted and stored in the network is sensitive personal information, so the system needs to resist data leakage. (d) Authenticity. The data cannot be illegally modified. For example, in the cloud environment, the system can prevent doctors and the cloud from conspiring to tamper with medical data.(2)Data Sharing. Authorized third parties such as other doctors can access the patient’s historical medical data with the consent of the patient. In particular, these data may be generated from different doctors at different hospitals.(3)Patient Control. Patients can control other people’s access to their historical medical records.(4)Uniform Standard. There are uniform data standards and sharing principles among all participants in the system, which is conducive to improving the efficiency and stability of the system.
3.3. Bilinear Map
Let and denote two multiplicative groups, respectively, and they have the same prime order . If a map satisfies the following three properties, then is called the bilinear map [39]:(1)Bilinear: for any points and any points , is satisfied.(2)Nondegeneracy: there is a point so that , 1 is ’s an identity element.(3)Computability: for any points , can be computed within polynomial time.
3.4. Intractable Problems
(1)Discrete Logarithm Problem (DLP): knowing two points and in and , it is hard to find so that .(2)Computational Diffie–Hellman Problem (CDH): knowing point in , for a given , it is hard to compute , where .
3.5. Proxy Reencryption
Proxy reencryption means that a delegate generates a proxy reencryption key of a delegatee and then sends to the agent. The agent uses to convert the ciphertext encrypted with ’s public key to the ciphertext encrypted with ’s public key . It does not need to use ’s private key to decrypt the ciphertext, and we will list the details as follows [40]:(1) encrypts the plaintext with , i.e., .(2) generates the proxy reencryption key for and sends and to the agent.(3)The agent converts into utilizing , where is ’s ciphertext encrypted with . Notably, the agent only makes the transformation service of ciphertext and does not know .(4)The agent sends to that decrypts it using its private key to get .
3.6. Sequential Multisignature
Sequential multisignature is a particular digital signature scheme. It means that multiple users sign the message in a specific order [19, 41]. A general sequential multisignature usually needs to execute the following four algorithms, i.e., Setup, Key Generation, Sign, and Verify:(1)Setup: the key generation center (KGC) inputs a security parameter and generates system parameter , and system master key.(2)Key Generation: given , users generate their private key and then compute their own public key by inputting .(3)Sign: the signer orderly verifies the partial signature of the previous signer . If it is valid, outputs own partial signature signed by .(4)Verify: the verifier verifies the signatures by inputting and the order of signature.
4. The Proposed BC-EMR
4.1. System Model
In this section, the details of BC-EMR will be given. We use the sequential multisignature of [41] and the proxy reencryption of [42] to construct the scheme. As shown in Figure 2, BC-EMR mainly consists of four entities, i.e., a doctor team, a patient, a hospital, and a cloud server. In BC-EMR, a patient first registers at the hospital. If the identity is approved, the hospital server assigns a medical team to the patient based on the initial condition. Then, the server and members of the team establish a group key that is used to protect the patient’s diagnosis results. In the diagnosis, when a doctor receives a message from the former doctor, he/she first verifies previous all doctors’ signatures. If it passes, the doctor will make the diagnosis and broadcast his/her signature in the blockchain. Otherwise, he/she requests the former doctor to resend the message. When the last doctor has finished the signature, he/she encrypts the result by using the patient’s public key and sends the ciphertext to the cloud server. The ciphertext and signatures will be stored in the cloud and blockchain, respectively, if the signatures pass the verification. Different doctors at different hospitals have the right to access the patient’s medical history with the patient’s consent. BC-EMR includes the following five phases, i.e., Initialization, Group key generation, Diagnose, Data storage, and Data sharing. In Table 2, we give the used notations in the paper.
4.2. Initialization
(1) inputs a security parameter , selects the bilinear map and a random number , where and are two multiplicative groups with the same prime order . is a generator of . Four hash functions are defined as follows: , , , and , where is the length of the verification keys [42]. Besides, selects a random number as the system master key, and the public key . The public parameters of BC-EMR are . In BC-EMR, we limit the number of the signer reissues the signature to no more than .(2)Hospital selects a random number as its private key and the public key .(3)Patient selects a random number as the private key and sets as the public key.(4)Doctor randomly selects , computes , , and . The private key is and the public key .
4.3. Group Key Generation
When a patient sees a doctor in the hospital , sends an identity and symptoms to ’s server securely. If the identity is legal, the server first selects a random number , computes ’s pseudoidentity and sends it to . It also assigns initial doctors to make a diagnosis according ’s condition, sends the evidence and a diagnosis order to , and sends a signature timestamp , , and to securely. Especially, as in Figure 3, a group key between and will be set to protect medical information. The details are given as follows:(1) chooses a random number , computes , and sends to .(2) randomly selects a number , computes , and sends to .(3) computes , , and sends to .(4) computes and . If , computes and sends to . Otherwise, .(5) computes and checks . If not, . Otherwise, computes and , and then sends to .(6) decrypts using to get the group key .
The correctness of the above protocol is based on the following equation
4.4. Diagnosis
(1) shows and to as the evidence, so that makes a diagnosis or accesses the history records of . If it is legal, first generates a diagnosis , randomly selects , computes , , , and . Then sends the signature message to . Meanwhile, broadcasts signature in the blockchain; please see Figure 4 for the structure of block. In BC-EMR, each block is used to store one patient’s information such as all doctors’ signatures.(2) shows to . If it is legal, confirms whether he/she received before . If not, requests to resend the message. Then, decrypts to get and verifies the following: If it is true, first randomly selects , generates diagnosis , computes , , , , and . Then encrypts the results as and sends the signature to . Meanwhile, boardcasts signature in the blockchain. Thus, the final diagnosis is and the signature message is .(3) encrypts the results using ’s public key to generate the ciphertext . We will give the details as follows:(a) selects a general signature key pair and sets (b) randomly selects a number and computes , , , , , and (c) signs the message using and outputs the ciphertext , where is the signature(d) sends ciphertext and to the cloud server
4.5. Data Storage
In BC-EMR, every doctor is the general node of the blockchain. The cloud server and ’s server are the supernodes, and they are responsible for verifying the signature message. That is, if the signature message passes their verification, all nodes will put the current signatures about the patient in a block and update their stored records. The verification scheme is that the supernodes check the following equation:
If it is true, the supernodes send a confirmation message in the blockchain so that all nodes accept the signatures about , put them in a block, and update the stored records. Otherwise, .
4.6. Data Sharing
When the doctor in the hospital makes a diagnosis for the patient , ’s medical history in other hospitals may help . Therefore, if wants, he/she can obtain these records with the consent of . The details are as follows:(1) and send their identities and request to . If it is passed, sends a notice to , and the server of extracts the ciphertext from the cloud server and sends it to . In addition, sends a trapdoor to .(2) and send the private keys and to , respectively. Then, outputs the reencryption key .(3) checks the signature on , i.e., , and . If any of them fails, . Otherwise, computes and sends the ciphertext to .(4) checks the signature , i.e., , , and . If any of them fails, . Otherwise, recovers the message .
5. Solutions to the Basic Requirements
BC-EMR has provided for the advantages described in Subsection 3.1 since it uses blockchain. Especially, the scheme is based on the sequential multisignature of [41] and the proxy reencryption of [42]. They are proven secure in the random oracle model, which is based on the hardness of the CDH problem and the modified DBDH problem, respectively, and please see [41, 42] for the full formal proof.
In this subsection, we will show why BC-EMR satisfies the basic requirements of BMR. In Table 3, we list the comparison results about BC-EMR and the other three blockchain-based EMR schemes ZL, CZ, and AS. Here, the schemes in [26, 28, 37] are denoted as ZL, CZ, and AS, respectively.
5.1. Security and Privacy Preservation (SP)
(a)Malicious attacks (MA) (M1): to get the doctor’s private key to generate a legal signature, the adversary must solve DLP intractable problem. Especially, it is not feasible to falsify the diagnosis by the cloud server or the collaboration between the patient and the cloud server. The reason is that they also can not get the doctors’ legal signatures from the hospital’s server or can detect any forged information by verifying the signatures stored in the blockchain. So, BC-EMR can resist the forgery attack. (M2): in BC-EMR, the last doctor encrypts the diagnosis results with the patient’s public key and outsources them to the cloud. If an adversary wants to modify them, it first needs to obtain the patient’s private key and the cloud’s permission. To get the private key illegally, the adversary must solve DLP intractable problem. Therefore, it is not possible. More importantly, BC-EMR stores the doctors’ signatures of their diagnoses in the blockchain. Then, it is easy to detect the modification to the diagnosis results, even if the patient’s private key is leaked or the patient (or doctor) cooperates with the cloud. Thus, BC-EMR can resist the modification attack. (M3): BC-EMR has introduced the timestamp . will confirm whether he/she received the message before . It is impossible to change timestamp since the signatures stored in the blockchain contain it. Any modification to is easily detected, and thus BC-EMR can resist the replay attack. (M4): in BC-EMR, the system sets the number of resigning as . If the number of resigning exceeds , the signature terminates. It can be to limit the number of attacks effectively and resist the guessing attack. (M5): protection against the man-in-the-middle attack follows from the protection against the forgery attack, modification attack, and replay attack. (M6): the patient and hospital generate different random numbers including , , and in each execution of BC-EMR. Thus, there is no constant value in the transmitted or stored messages, and the adversary can not trace the action. Therefore, our BC-EMR can resist the trackable attack.(b)Nonrepudiation (NR): blockchain technology makes BC-EMR satisfy traceability. We can search the origin of any record stored in the blockchain by the chain structure and the doctor’s signature. Thus, no participant can deny the data generated by himself/herself.(c)Confidentiality (CO): before diagnosis, the hospital server will set a pseudoidentity for each patient. During the diagnosis, the patient will use the pseudoidentity to interact with doctors. The doctors will encrypt the diagnosis results with the group key, and only members of the medical team can get them. When the diagnosis is over, the last doctor will encrypt the result with the patient’s public key before storing it in a cloud server. If the adversary wants to get the patient’s private key to decrypt the ciphertext, he/she needs to solve the DLP intractable problem. So BC-EMR has ideal confidentiality.(d)Authenticity (AU): no one but the patient can decrypt the ciphertext of diagnosis since the final doctor encrypts diagnosis results with the patient’s public key. Doctors have stored the signatures of diagnoses in the blockchain, and these violations are easy to spot.
5.2. Data Sharing (DS)
The scheme has utilized proxy reencryption technology. If the doctor has obtained the consent of the patient, he/she will get the ciphertext encrypted by their public key. Then the doctor accesses the patient’s historical medical records by decrypting the ciphertext. That is, BC-EMR realizes data sharing between different doctors at different hospitals.
5.3. Patient Control (PC)
When a doctor needs to know the patient’s historical records of another hospital, the doctor must get the ciphertext that is encrypted by his/her public key. However, the original ciphertext is encrypted by the patient’s public key. The transformation of ciphertext needs to be completed by using the reencryption key that is computed by utilizing the patient’s private key. So, the patient can control the doctor to access the historical data.
5.4. Uniform Standard (US)
In hospitals’ BC-EMR systems, we can use a uniform standard such as the same encryption algorithm. It is beneficial to implement data sharing and other functions.
In Table 3, we give the comparison results of BC-EMR, ZL, CZ, and AS according to the basic requirements. We can know that ZL and AS can not resist the guess attack. CZ not only can not resist the guess attack but also can not satisfy patient control and make the essential data sharing.
Remarks. Without the blockchain, if a doctor tries to forge EMR that has been outsourced to a cloud server in a medical accident, he/she can incentivize the cloud server to forge or modify the existing EMR at will. This is consistent with reality. The introduction of blockchain makes the scheme resistant to threats such as doctor-cloud collusion to forge or modify EMR without additional security mechanisms, strong hypotheses, and trusted entities. In other words, blockchain plays a key role in ensuring security in BC-EMR. Moreover, in BC-EMR, blockchain only stores some lightweight information such as the doctors’ signatures, and diagnostic results are stored in the cloud, thus reducing the burden of blockchain and facilitating the future implementation of the scheme.
6. Performance Evaluation
In this section, we will evaluate BC-EMR from the following two aspects: (1) computational and communication cost; (2) the implementation of BC-EMR.
6.1. Computational and Communication Cost
In this subsection, we will compare the main computational cost and communication cost of BC-EMR, ZL, CZ, and AS. usually has sufficient computational power and storage capacity, so we consider the burden on the patient and the last doctor of the team (the last doctor is responsible for outsourcing data, he/she needs to pay for more cost than other doctors). The comparison results of computational cost are shown in Table 4. Here, denotes the scale multiplication operator in , denotes the exponentiation operation in , denotes the bilinear pairing operation. We ignore the remaining operations because of their low computational cost.
In Table 4, is the size of the disease keyword set [26]. On the doctor’s side, ZL has the highest computational cost of since is usually large such as 1000 in ZL. The cost of CZ is lower than BC-EMR, but it can not satisfy a critical feature of EMR, i.e., the data sharing between doctors. CZ also omits the authentication between the server and doctors in generating the treatment key, and the current doctor only verifies the previous doctor’s signature. But BC-EMR will make the authentication in creating the group key, and the current doctor verifies previous all doctors’ signatures. The cost of AS is also lower than BC-EMR on the doctor’s side, but the scheme needs to decrypt the ciphertext using the patient’s private key and then encrypt the EMR using the shared secret key in the process of data sharing. Every time generation and management of the shared secret key both are consuming cost and there is a risk of data leakage. So BC-EMR has higher security, and the additional computational cost is worthy. In addition, the results in [43] show that the computational cost of the operation is approximately two times that of the operation . So, on the side of the patient, we can find that BC-EMR has the lowest computational cost of . It is worthy to note that doctors often have relatively reliable computational power, and it is vital to reduce the computational burden on patients.
In Table 5, we will give the main communication cost of the three schemes. and denote the size of the element in the ciphertext space and the size of the timestamp, respectively. is the number of the private blockchain’s verifiers in ZL, and is the size of personal data in AS. We use the supersingular curve with order over the finite field . To give a more explicit comparison of communication cost, we assume the prime number is 160 bits, the prime number is 1024 bits, the point in is 1024 bits, the point in is 512 bits, the point in the ciphertext space, the hash value, and all are 160 bits, the timestamp, the order message , and the identity all are 32 bits, the security parameter is 512 bits, in ZL, is 512 bits, and is 1024 bits. In Figure 5, we give the comparison diagram of communication cost versus (without loss of generality, we assume ). Besides, we provide a comparison diagram of communication cost versus the number of doctors in Figure 6. In ZL, , but we set for clearly showing the comparison results in Figure 6.
We can see from Figure 5 that the communication cost of ZL linearly increases with . The communication cost of CZ, AS, and BC-EMR is constant versus . Since is usually relatively large such as 1000 in ZL. So, ZL has the highest communication cost. In Figure 6, the communication cost of CZ and BC-EMR both linearly increase with , and the communication cost of BC-EMR is higher than CZ’s. AS has the lowest communication cost, and an important reason is that the scheme does not consider the case that multiple doctors generate the EMR for a patient. In addition, as mentioned in the analysis of computational cost, CZ can not satisfy some features such as data sharing. AS requires decrypting the ciphertext using the patient’s private key and then encrypting the EMR using the shared key to make data sharing. Every time the shared key is generated and managed, there is cost, and it will also increase the risk of EMR data leakage. Thus, the above results show that BC-EMR can achieve a better balance among security, basic requirements, computational cost, and communication cost. So it is an ideal EMR scheme.
6.2. Implementation of BC-EMR
In this subsection, we will give some implementation results of BC-EMR. The experiment used Python 3.7.4 as the programming language. Specially, we used the C language library PBC (v0.5.14) for bilinear pairing calculations, pypbc to call the PBC library in Python, and Python’s encryption algorithm library pycryptodome (v3.9.0) to implement AES encryption. We used a computer equipped with an Intel Core i7-9750H CPU @ 2.60 GHz and 15.6 GB of memory to run our experimental program. The operating system is Manjaro Linux 64 bit, the desktop environment is KDE (v5.61.0), and the kernel version is 4.19.69-1-MANJARO. During the experiment, we started multiple processes on the experimental computer. Each procedure was bound to a separate port and communicated with each other using sockets. In this way, we simulated the behavior of different roles in each phase of the scenario. All values are the average result of 100 times experiments.
We consider three security levels for BC-EMR, i.e., level 1 ( bits, bits), level 2 ( bits, bits), and level 3 ( bits, bits). In Table 6, we assume and summarize the phased computational costs for three security levels. The corresponding histogram is given in Figure 7. The result shows that the computational costs of the five stages increase as the security level increases. Besides, in Figure 8, we consider the computational delay versus . We can find that the computational delays of the initialization phase and data sharing phase have no significant change. With the increase in the number of doctors, the other three stages’ computational delays all significantly increase. The computational delay of the diagnostic phase is the fastest growing. The reason is that as the number of doctors increases, BC-EMR needs to perform more time-consuming exponential operations and bilinear pairing operations.
(a)
(b)
(c)
7. Conclusion
In this paper, we proposed a blockchain-based EMR in the cloud environment. A lightweight one-to-many authentication protocol is given to set a group key, which is used to protect the patient’s diagnosis results before storing them in the cloud. The proxy reencryption is utilized to make secure data sharing between doctors at different hospitals. Blockchain and sequential multisignature technologies ensure that the stored medical information is safe. Especially, BC-EMR can resist threats such as doctor-cloud collusion to forge or modify EMR. The analysis shows that BC-EMR has a lower computational cost on the side of the patient. It is very important for EMR since the patients usually rely on resource-limited mobile devices. Besides, BC-EMR can satisfy more basic requirements and security features. So the extra computational cost on the side of the doctor and the extra communication cost compared with CZ both are worthy. That is, BC-EMR is a practical EMR. Of course, as the analysis results show, the method presented in this paper has some shortcomings, such as a slightly higher cost of communication. Since blockchain is a massive ledger backup measure, these deficiencies will directly reduce the system performance. So the balance between efficiency, security, and cost remains at the heart of what we do next.
Data Availability
Some or all data, models, or codes generated or used during the study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported by the Fundamental Research Funds for the Central Universities of Southwest Minzu University (No. 2020NQN21) and the Fund of Guangxi Key Laboratory of Cryptography and Information Security (No. GCIS202121).