Design of Secure Protocol for Cloud-Assisted Electronic Health Record System Using Blockchain

In the traditional electronic health record (EHR) management system, each medical service center manages their own health records, respectively, which are difficult to share on the different medical platforms. Recently, blockchain technology is one of the popular alternatives to enable medical service centers based on different platforms to share EHRs. However, it is hard to store whole EHR data in blockchain because of the size and the price of blockchain. To resolve this problem, cloud computing is considered as a promising solution. Cloud computing offers advantageous properties such as storage availability and scalability. Unfortunately, the EHR system with cloud computing can be vulnerable to various attacks because the sensitive data is sent over a public channel. We propose the secure protocol for cloud-assisted EHR system using blockchain. In the proposed scheme, blockchain technology is used to provide data integrity and access control using log transactions and the cloud server stores and manages the patient’s EHRs to provide secure storage resources. We use an elliptic curve cryptosystems (ECC) to provide secure health data sharing with cloud computing. We demonstrate that the proposed EHR system can prevent various attacks by using informal security analysis and automated validation of internet security protocols and applications (AVISPA) simulation. Furthermore, we prove that the proposed EHR system provides secure mutual authentication using BAN logic analysis. We then compare the computation overhead, communication overhead, and security properties with existing schemes. Consequently, the proposed EHR system is suitable for the practical healthcare system considering security and efficiency.


Introduction
As patient healthcare records have been developed from traditional paper management to electronic record management, they can be safely stored and accessed and authorized only by legitimate medical centers [1]. With the electronic health record (EHR) management system, storage availability and historical errors can be minimized, improving the availability and accuracy of healthcare records. EHR systems can help people to prevent diseases and enhance the cure rate, and ensures great convenience for medical centers and patients. However, health-related information from each healthcare system is stored in their own medical servers, respectively, in traditional EHR systems [2]. Therefore, when the patients transfer from a hospital to another one, hospitals should establish a point-to-point channel to share patients information. Furthermore, the traditional EHR system is generally established as a centralized system so that it has a single point of failure. Blockchain can serve as a helpful method to solve these problems.

Research Contributions
The detailed contributions in this paper are summarized as below.

•
We propose the secure protocol for cloud-assisted EHR system using blockchain. The proposed scheme combines cloud computing, blockchain, and authentication to provide a secure and effective medical diagnosis for legitimate patients.

•
The proposed scheme withstands various attacks, including impersonation, session key disclosure, and replay attacks, and also provides secure mutual authentication and anonymity.

•
We present the Burrows-Abadi-Needham (BAN) logic analysis [19,20] to analyze that the proposed scheme provides secure mutual authentication.
• We perform the automated validation of internet security protocols and applications (AVISPA) [21,22] to analyze against man-in-the-middle (MITM) and replay attacks. Furthermore, we show the performance analysis of the proposed scheme with existing schemes.

Organization
The remainder of this paper is organized as follows. Section 2 presents the related works, and Section 3 shows the preliminaries for help explanation of this paper. In Sections 4 and 5, we introduce the system model and also propose a secure protocol for cloud-assisted EHR system using blockchain. Section 6 performs the security analysis of the proposed scheme using informal and formal security analysis. In Section 7, we compare the performance analysis of the proposed scheme with related schemes. Finally, we summarize the paper in Section 8.

Related Works
In the past decades, many authentication schemes in the healthcare system have been presented to ensure secure healthcare service and EHR sharing [23][24][25][26]. Kumar et al. [23] presented an efficient authentication scheme for healthcare applications in wireless medical sensor networks to provide secure healthcare services. Wu et al. [24] presented a reliable RFID-based authentication scheme in healthcare environments. Their scheme [24] does not reveal any private data, including the identity number and the health data of the legitimate patient. Liu et al. [25] presented a remote authentication protocol for wireless body area networks. Their scheme [25] is not suitable for limited-resource wearable sensor devices because it utilizes bilinear pairing cryptography with high computation and communication overheads. Renuka et al. [26] presented a three-factor authentication protocol for smart healthcare using ECC. Renuka et al. [26] demonstrated that their scheme can prevent against various attacks. However, their schemes for the healthcare system [23][24][25][26] are essentially a centralized system so that these schemes do not solve problems such as the single point of failure. Therefore, a blockchain mechanism with decentralized properties is essential for solving the problems of centralized systems.
In the last few years, many EHR system studies have been presented using blockchain to ensure data integrity along with decentralized properties [27][28][29]. Pandey and Litoriya [27] presented secure e-health networks from counterfeit medicine penetration using blockchain. Their scheme [27] ensures data integrity and security capability properties against drug data to provide secure healthcare services. Agbo and Mahmoud [28] presented a comparison of blockchain frameworks for healthcare applications. Tanwar et al. [29] presented a blockchain-based EHR system for secure medical data sharing. Their scheme [29] can avoid the reliability problem of the trusted third parties, and also can provide secure medical services between each entity. However, these schemes for the EHR systems using blockchain [27][28][29] should consider that it is hard to store whole EHR data in blockchain because of the size and price of blockchain [11]. Therefore, if there is a sudden and unexpected demand for storage and resources, the EHR systems using blockchain have to guarantee sufficient capacities. Therefore, these schemes require a cloud-based mechanism in the EHR system to provide cloud storage technology and decentralized properties using blockchain.
Recently, numerous cloud-based EHR system studies using the blockchain have been presented to solve the storage overload problem associated with blockchain [30][31][32]. Wang et al. [30] presented a cloud-assisted EHR sharing to ensure security and privacy using blockchain. Their scheme [30] uses searchable encryption and proxy re-encryption to realize data security and access control. Chen et al. [31] designed a secure storage scheme based on blockchain and cloud storage to manage personal health data. Cheng et al. [32] presented a secure medical data sharing scheme based on blockchain utilizing cloud techniques. Their scheme [32] uses bilinear mapping to provide secure medical data sharing and low storage and computing overhead. However, these cloud-based EHR systems using blockchain [30][31][32] have been studied so far, but a secure authentication scheme for EHR sharing has not been specifically considered. Therefore, we present a secure cloud-assisted EHR system using blockchain to ensure secure EHR sharing.

Preliminaries
In this section, we introduce the preliminaries for help explanation of this paper.

Adversary Model
We present the widely used Dolev-Yao (DY) model [33] to analyze the security of the proposed protocol. The detailed assumptions of the DY model are as follows.

•
An attacker can delete, inject, eavesdrop, and intercept the messages transmitted over a public channel.

•
An attacker can steal the smartcard of legitimate patients and can extract secret values stored in a smartcard using power-analysis [34,35].

•
An attacker may attempt various attacks such as impersonation, MITM, replay, session key disclosure attacks, and so on [36,37].

Hyperledger Fabric
In 2015, hyperledger fabric [10] was presented as an open source blockchain proposed by the Linux Foundation. The goal of this technology is to promote cross-industry cooperation using blockchain. Hyperledger fabric does not require digital currency and provides various advantages such as blockchain performance and reliability. Hyperledger fabric uses practical byzantine fault-tolerant (PBFT) consensus algorithm [38,39]. Therefore, we apply the PBFT algorithm to the proposed system to provide an effective consensus ability. The hyperledger architecture consists of six blockchain components:

1.
Membership Service Provider (MSP): MSP is a component that validates and authenticates credentials and defines the rules for accessing a network. The MSP manages user identities and authenticates all participants in the network, making hyperledger fabric available as both private and permissioned networks. This includes providing credentials for the clients to propose transactions. As a result, a single hyperledger fabric network can be controlled by multiple MSPs.

2.
Smart Contract: The smart contract of hyperledger fabric is called chaincode. Chaincode is software that defines assets and related transactions. The chaincode is called when the application needs to interact with the ledger. Every chaincode has an attached endorsement policy, which applies to all smart contracts defined in it. This identifies the organizations that need to sign transactions generated by smart contracts. In addition, smart contracts have the advantage of being able to make different smart contracts within the channel or across different channels.

3.
Ordering Service: The ordering service packages a transaction in blocks and delivers it to the channel's peers. It ensures the transaction delivery via the network. It communicates with peers and endorsing peers.

4.
Identity: Each node in the network peer, client, ordered, and the manager has a digital identity with the format of certificate X.509. This identity is used to verify at every stage of the transaction to ensure if the source of the transaction is a valid source. In addition to multiple assurances, validation, and version control checks that occur, there are ongoing identity verifications happening during each stage of the transaction flow.

5.
Channels: Hyperledger fabric networks can have multiple channels. Channels allow organizations to use the same network while maintaining separation between multiple blockchain. Only the peer of the channel can provide to see transactions made by all members of the channel.

6.
Peer Nodes: Peer nodes constitute a fundamental element of the network as they host smart contracts within the ledger. Peer nodes execute chaincode, access ledger data, approve transactions, and interface with applications.

Cloud-Assisted EHR System Model Using Blockchain
We introduce a cloud-assisted EHR system based on a hyperledger fabric in Figure 1. To improve the security and efficiency of medical data, this system is built on medical centers that share EHR in specific regions. The system model for the EHR comprises the four entities: the patient, the medical center, the cloud server, and the network administrator. The detailed descriptions of each entity are described as follows.

1.
Patient: A patient transmits the health data to the medical center in order to receive healthcare services through healthcare devices and wearable sensors. Health data of the patient are recorded in EHR with healthcare services provided by the medical center.

2.
Medical Centers: The medical centers are registered by the network administrator and participate in the private blockchain. The medical centers generate EHR and store it to the cloud server for sharing with other medical centers. When the medical centers view the EHRs of other medical center's the patient, they upload a log of EHR data to the blockchain as a transaction form.

3.
Network Administrator: A network administrator is a trusted entity, responsible for the registration of participants, that manages the private blockchain.

4.
Cloud Server: A cloud server is a trusted entity that has sufficient computing power and capacity. The cloud server stores and manages the patient's EHRs to provide secure data sharing and storage resources. A cloud server receives the EHR data from the medical center and sends the EHR to other medical centers requesting the EHR using a pre-shared secret key. The communication flows of the proposed EHR system are described as follows.

1.
Patient and doctor register their identities with the help of a network administrator to access EHR services.

2.
Patient and doctor authenticate each other and establish a session key for future secure communication.

3.
The medical center receives the information for a smart contract from the patient using a session key. Then, the medical center generates a patient's smart contract and EHR. After that, the medical center uploads a smart contract at the blockchain.

4.
The medical center encrypts EHRs of the legitimate patient using a pre-shared secret key and sends it to the cloud server. Then, the cloud server decrypts the encrypted EHR data and stores EHR data in the database.

5.
The other medical center requests the EHR data of the medical center to the cloud server. Next, the cloud server encrypts EHR data of the medical center using a pre-shared secret key and sends it to the other medical center.

6.
Finally, the medical center decrypts the encrypted EHR data and then uploads the log transaction, including the patient and medical center masked identities, signatures, and timestamps at the blockchain.

Proposed Protocol for Cloud-Assisted EHR System Using Blockchain
We present a secure protocol for cloud-assisted EHR system using hyperledger fabric. The proposed EHR system is that only the EHRs can be outsourced by authenticated participants and each operation on outsourcing EHRs is integrated into the blockchain as a transaction. The proposed scheme consists of six phases: the registration, authentication, smart contract uploading, EHR storing, EHR requesting, and log transaction uploading. Before the registration phase, a network administrator (N A) sets up the networks. The N A selects a base point G over an elliptic curve E p with order p that is a large prime number. P of order q is one of G's generators, in which q is a large prime number. Then, the N A selects a secret key s N A and generates a public key PK N A = s N A · G. Finally, N A shares the network configuration and policies with all system participants. Furthermore, the N A publishes, {p, q, G, P, PK N A } as system parameters, and a cloud server (CS) establishes a secure pre-shared key with medical centers. Table 1 illustrates the notations used in the proposed scheme.

Notations
Meanings Identity of P i and MC j PW i Password of P i r i , r j Secret keys of P i and MC j s N A Secret key of N A T 1 , T 2 Timestamps T up , T access Uploading/accessing time of EHR K N A , r N A Random numbers generated by N A PK i , PK j Public keys of P i and MC j Cert i , Cert j Certificates of P i and MC j E p (a, b) A nonsingular elliptic curve

Registration Phase
In the proposed scheme, the registration phase consists of the patient registration and the medical center registration.

Patient Registration Phase
If a patient (P i ) wants to receive a medical diagnosis, the P i must first register his/her information with the N A and generate a private key and a public key. The patient registration phase is executed over a secure channel. Figure 2 shows the patient registration phase and detailed steps are as follows. Figure 2. Patient registration phase of the proposed protocol.
Step 1: The P i requests registration to the network administrator N A. First, P i inputs identity ID i and password PW i . Then, the P i generates a random number a i and computes H ID i = h(a i ||ID i ) and sends H ID i to the N A. Step 2: The N A chooses a random number K N A and computes x i = h(H ID i ||K N A ) using the H ID i received from the P i . Then, the N A stores {x i } into the smartcard and issues it to the P i in the blockchain. Finally, the N A stores {HID i } in secure database.
Step 3: After the P i receives smartcard from the N A, the P i generates a random number r i as a secret key. P i computes . And then, the P i generates a public key PK i = r i · G and replaces

Medical Center Registration Phase
A medical center (MC j ) must register with the N A to have a key agreement with patients and exchange information with other related medical centers. The masked identity of the MC j is shared with other entities. This registration phase is also executed over a secure channel. The detailed steps are described as follows and are illustrated in Figure 3.  Step 1: A medical center MC j chooses a unique identity ID j and generates a random number r j as a its secret key. Then, the MC j computes a masked identity PID j = h(ID j ||r j ) and generates a public key PK j = r j · G. MC j sends PID j to the N A.
Step 2: After receiving registration request message, the N A chooses a random number r N A and Step 3: After the MC j receives the messages, the MC j stores {Cert j , H ID i } in secure database.

Authentication Phase
If the P i wants a secure health diagnosis, the patient and medical center must establish a session key. The detailed steps are as following in Figure 4. Step 1: The P i inputs his/her ID i , PW i , and smartcard. Then, the smartcard computes Then, the smartcard checks whether D * i ? = D i . If it is correct, the P i generates a timestamp T 1 and encrypts messages M 1 = {(x i ||HID i ||T 1 ) + r i · PK j } and computes M ap = h(x i ||HID i ). Next, the P i sends a message < M 1 , M ap , T 1 > to MC j via a public channel.
Step 2: After receiving the message < M 1 , M ap , . H ID i updates at the proper period. After that, the MC j generates a session key SK ij = h(H ID i ||PID j ||x i ||b j ). Finally, MC j sends message < E i , M amc , T 2 > to P i over an open channel.
Step 3: When the P i receives the message from the MC j , the P i computes b j = E i ⊕ x i , and M * amc = h(PID j ||b j ||T 2 ). Then, the P i checks whether M * amc ? = M amc . If it is valid, the P i computes a session key SK ij = h(H ID i ||PID j ||x i ||b j ).

Smart Contract Uploading Phase
After receiving information for the smart contract from the P i , the MC j generates a smart contract and then uploads the smart contract in the blockchain. The detailed steps are as following in Figure 5.
Step 1: The P i generates message M sc = h(H ID i ||PID j ||SK ij ) and encrypts his/her information with SK ij ; M in f = (HID i ||PID j ) SK ij . Then, the P i sends < M sc , M in f > to the MC j .
Step 2: The MC j computes M * sc = h(H ID i ||PID j ||SK ij ) and checks M * SC ? = M SC . If it is valid, MC j decrypts M in f and generates a smart contract Sc using (HID i , PID j , Cert j ). Finally, the MC j uploads Sc in the blockchain.

EHR Storing Phase
After uploading smart contract, the MC j generates EHR i and stores EHR i in CS. Detailed steps are as follows in Figure 6. Step 1: The MC j generates EHR i including H ID i , PID j , an information of health record RI, and EHR's uploading time T up . Then, the MC j encrypts EHR i using a secure pre-shared key M up = (EHR i ) KMS j and computes M CU = h(EHR i ⊕ PID j ). Finally, the MC j sends < M up , M CU > to the CS. = M CU . If it is correct, the CS stores EHR i in the server database.

EHR Requesting Phase
If the MC j wants to confirm EHR i , MC j sends request messages to the CS. Then, the CS sends EHR i to MC j . Detailed steps are as follows in Figure 7.
Step 1: The MC j generates request messages RE and encrypts M req = (RE||PID j ) KMS j using KMS j and computes M CR = h(RE ⊕ PID j ). Then, the MC j sends < M req , M CR > to the CS.  Figure 7. EHR requesting phase of the proposed protocol.

Log Transaction Uploading Phase
After MC j receives EHR i from CS, MC j generates a log transaction and uploads the log transaction in the blockchain. The MC j generates a log transaction Tx = {HID i , PID j , T access , Sig j }, where T access is accessing time of EHR i and Sig j is a signature of the MC j . Finally, the MC j uploads Tx in the blockchain. The detailed step is as following in Figure 8.

Security Analysis
In this section, we analyze the proposed protocol as a security aspect. We show that the proposed protocol is secure against malicious attacks using informal analysis. We also prove that the proposed protocol can provide secure mutual authentication using a widely adopted BAN logic. In addition, we simulate Automated Validation of Internet Security Protocols and Applications (AVISPA) to prove that the proposed protocol is secure against MITM and replay attacks.

Informal Security Analysis
We analyze the proposed protocol to perform informal security analysis and show the protocol can resist various attacks. Moreover, we show that our protocol can provide secure mutual authentication and patient's anonymity.

Impersonation Attack
A malicious adversary M A tries to impersonate a legitimate patient P i to obtain sensitive information. To impersonate P i , the M A has to successfully compute a message < M 1 , M ap , T 1 >. However, the M ap is masked with a secret value x i and the adversary cannot compute x i because he/she does not know a random number K N A . Moreover, the M 1 is encrypted by the P i 's secret key. Therefore, the proposed protocol is secure against impersonation attacks.

Session Key Disclosure Attack
If the M A wants to generate a legitimate session key SK ij = h(H ID i ||PID j ||x i ||b j ), the M A must know random number b j . However, the M A cannot obtain b j . Moreover, the M A cannot reveal real the identities of P i and MC j because they are masked with random numbers a i and r j . Therefore, the proposed protocol can prevent session key disclosure attacks.

Perfect Forward Secrecy
Even if a M A knows a long-term private secret key s N A , the M A cannot obtain the previous session key, because a session key SK ij = h(H ID i ||PID j ||x i ||b j ) does not include s N A . Further, if the long-term private parameter K N A is compromised, the M A cannot obtain x i . Because x i is masked with H ID i and H ID i is masked with a random number a i . Therefore, the proposed protocol guarantees perfect forward secrecy.

Privileged Insider Attack
Suppose a privileged insider user of the system, the user is an insider adversary. The insider adversary knows the registration information < H ID i > of a legitimate user. Moreover, the adversary also can know stored values {A i , B i , C i , D i } in the smartcard to perform power analysis attacks. However, stored values in the smartcard are masked with HPW i . Therefore, the adversary cannot know HPW i that cannot guess a valid password. Therefore, the proposed protocol prevents privileged insider attack.

Anonymity
A M A cannot reveal a legitimate patient's real identity ID i , because ID i is masked by hash function or encryption with random numbers or secret key. Therefore, our protocol provides the patient's anonymity. = M amc are correct. If the conditions are correct, the P i and MC j authenticate each other. Therefore, our protocol can provide secure mutual authentication.

BAN Logic Analysis
We demonstrate that the proposed protocol provides secure mutual authentication between P and MC using BAN logic [19,20]. Table 2 presents BAN logic notations. In addition, we define the rules, goals, idealized forms, and assumptions for performing BAN logic analysis. Table 2. Notations of Burrows-Abadi-Needham (BAN) logic.

Notation Description
Y has K as a public key X K ↔ Y X and Y may use shared key K to communicate SK Session key used in the current session

BAN Logic Rules
The BAN logic rules are defined as follows.

Goals
We define the security goals to prove that the proposed system is capable of performing secure mutual authentication.

Idealized Forms
We define the idealized forms as below.
The initial assumptions are given below.

Proof Using BAN Logic
We perform the BAN logic analysis. The detailed steps are as follows.
Step 1: From Msg 1 we can get, Step 2: From the message meaning rule with S 1 and A 2 , Step 3: We use the freshness rule with S 2 and A 6 , Step 4: Using the nonce verification rule with S 2 and S 3 , Step 5: By the Belief rule with S 4 and A 7 , Step 6: Because of the session key SK = h(H ID i ||PID j ||x i ||b j ), from S 5 and A 3 , Step 7: Using the jurisdiction rule with S 6 and A 5 , Step 8: From Msg 2 we can get, Step 9: From the message meaning rule with S 8 and A 1 , Step 10: We use the freshness rule with S 9 and A 3 , Step 11: Using the nonce verification rule with S 8 and S 9 , Step 12: By the belief rule with S 11 and A 8 , Step 13: Because of the session key SK = h(H ID i ||PID j ||x i ||b j ), from S 12 and A 6 , Step 14: Using the jurisdiction rule with S 13 and A 4 , Therefore, the goals 1-4 clearly show that the proposed protocol provides secure mutual authentication between P i and MC j .

AVISPA Analysis
This section shows the proposed protocol can resist against adversary's replay and MITM attacks to perform AVISPA simulation [21,22]. The AVISPA tool consists of High-Level Protocol Specification Language (HLPSL) [40] to generate input format (IF) of four back-ends, i.e., "On-the-Fly Model Checker (OFMC)", "Constraint Logic-based Attack Searcher (CL-AtSe)", "Tree automata based on Automatic Approximations for Analysis of Security Protocol (TA4SP)", and "SAT-based Model Checker (SATMC)". Then, the output format (OF) is created and the safety of the protocol is verified using OF. Generally, verification is performed with OFMC and CL-AtSe. The HLPSL syntax of each entity is shown in Figures 9-11. Furthermore, the goal and environment of the protocol are shown in Figure 12. Goal and environment describe participants, security goals, and environment conditions. As a Figure 13, the results of AVISPA simulation under OFMC and CL-AtSe is safe. The results show that OFMC has 5.88 search time and visits 1040 nodes with 9 piles depths. Furthermore, the CL-AtSe analyzed in 0.07 seconds. Therefore, our proposed protocol provides security against MITM and replay attacks.

Performance Analysis
In this section, we analyze the computation and communication costs of the proposed protocol compared with related schemes [25,26].

Computation Cost
Referring to the work in [41][42][43], we compare computation costs during authentication phase for the proposed system with related schemes [25,26].  Table 3 shows computation costs of the proposed scheme with related schemes [25,26].
In the proposed scheme, a patient computes {HPW i , r i , x i , D * i , M ap , M * amc , SK ij } with hash function, M 1 with ECC encryption. Moreover, the medical center computes {M 1 − r j · PK i } with ECC decryption, {M * ap , M amc , SK ij } with hash function. As a result, we provide better efficiency than existing schemes [25,26] because our scheme uses only hash function and ECC encryption/decryption.

Communication Cost
We compare communication costs during authentication phase for the proposed system with related schemes [25,26]. We assume that the ECC-based encryption (EN ecc ), timestamp (T), identity (I) hash function (H), and message authentication code (MAC) are 320, 32, 128, 160, and 160 bits [44,45], respectively. We also define that additive groups on super singular (G 1 ), and additive group (G) are 1024 and 320 bits [44,45], respectively. Table 4 shows communication costs of the proposed scheme with related schemes [25,26].
In Liu et al.'s scheme [25], transmitted messages {v, U, t c , T , I } and {MAC}. U, T , and I are elements of G 1 . Moreover, v is the element of hash function, t c is a timestamp, and MAC is the element of message authentication code. In Liu et al.'s scheme, transmitted messages require (160 + 1024 + 32 + 1024 + 1024 = 3264 bits) and (160 bits), respectively.
In Renuka et al.'s scheme [26], transmitted messages {D i , R i , F i , T 1 } and {R s , H i , T 2 }. R i and R s are elements of G. D i , F i , and H i are elements of hash function. And also, T 1 and T 2 are elements of timestamp. In Renuka et al.'s scheme, transmitted messages require (160 + 320 + 160 + 32 = 672 bits) and (320 + 160 + 32 = 512 bits), respectively.
In the proposed scheme, transmitted messages {M 1 , M op , T 1 } and {E i , M acm , T 2 }. M op , M acm , and E i are the elements of hash function and M 1 is the element of ECC-based encryption. And also, T 1 and T 2 are the elements of timestamp. In proposed scheme, transmitted messages require (320 + 160 + 32 = 512 bits) and (160 + 160 + 32 = 352 bits), respectively. Consequently, we provide better efficiency than related schemes [25,26] because our scheme uses hash function, timestamp, and ECC-based encryption/decryption.  Table 5 shows the comparison between the security properties of the proposed scheme and related schemes [25,26]. Our scheme guarantees perfect forward secrecy, anonymity, and mutual authentication, and avoids the single point of failure and bottleneck. In addition, the proposed scheme has the resistance of impersonation, session key disclosure, replay, and privileged insider attacks.

Conclusions
With the rapid development of the EHR system, medical centers obtain patient's health records to provide accurate medical services through medical wearable sensors. However, these health records contain sensitive information of patients, it is necessary to ensure the security from leakage or counterfeiting in the process of storing and sharing information. Furthermore, traditional protocols for the EHR system cannot prevent the single point of failure, and the EHR system should consider storage overload problems because of the large amounts of EHR data and scalability of the system. In this paper, we proposed the secure protocol for cloud-assisted EHR system using blockchain to resolve these problems. The proposed scheme presented detailed phases for six phases such as registration, authentication, smart contract uploading, EHR storing, EHR requesting, and log transaction uploading. We proved that the proposed scheme prevents various attacks and provides secure mutual authentication, anonymity, and perfect forward secrecy. We demonstrated the safety of the proposed scheme against MITM and replay attacks using AVISPA simulation. Furthermore, we proved that the proposed scheme ensures a secure mutual authentication between patient and medical server using BAN logic. We compared the security features and performance of the proposed scheme with some existing schemes. We proved that our scheme provides better safety and efficiency than related schemes. Therefore, the proposed EHR system can be suitable for the practical healthcare system for EHRs because it is more secure and efficient than other related schemes. In the future, we aim to develop a set of realistic simulations to test the protocol. If these practical simulations are available, it will help to develop a secure protocol for the cloud-assisted EHR system using blockchain.