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

Abstract

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.

1. 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.

In the last few years, numerous blockchain-based EHR system studies have been presented to address the problems of traditional EHR system and improve efficiency [3,4,5]. Blockchain is a network technology that ensures the decentralization and integrity of information by sharing records with multiple distributed nodes [6,7]. Blockchain is considered as a trusted distributed ledger that keeps transactions in a chain of chronological blocks linked through hash values. In addition, the blockchain has properties such as data anonymity, decentralization, and so on. In particular, many blockchain studies have presented various models such as ethereum and hyperledger [8]. Although both models have similar structures, hyperledger is relatively better in terms of network performance and energy efficiency [9]. Furthermore, hyperledger fabric [10] aims to solve the bottleneck problem of a cloud system and enables users to keep ownership of their own data, as well as to share data securely with feedback. However, the EHR system should consider that it is hard to store whole EHR data in blockchain because of the size and the price of blockchain [11]. Thus, if there is a sudden and unexpected demand for storage and resources, blockchain-based EHR systems should guarantee sufficient capacities.

In the last few years, many blockchain-based EHR systems have adopted cloud computing to enlarge scalability and to solve the storage problem associated with blockchain [12,13]. As an important technology to improve the development of smart medical services, cloud technology can serve as a platform for sharing information between remote hospitals and can solve the problem of remote collaboration diagnostic [14,15]. The health information can be efficiently managed on a cloud server facilitating precise and accurate diagnosis and treatment, as well as the development of various healthcare services [16]. Unfortunately, the cloud-based EHR system can be vulnerable to potential attacks because the sensitive data is sent over a public channel. To resolve these security problems, the cloud-based EHR systems require a secure and efficient protocol. Thus, we develop the security protocol using elliptic curve cryptosystems (ECC) that provides high security level, and efficient computation and communication overheads even in small storage spaces.

Recently, numerous EHR systems have been presented that combine blockchain, cloud, and authentication to solve each problem associated with cloud and blockchain [17,18]. Kaur et al. [17] presented a model architecture for EHR data using blockchain in the cloud environment to provide secure healthcare services. Furthermore, Nagasubramanian et al. [18] presented a cloud-assisted secure E-health record system using blockchain to provide integrity and decentralization for the EHR sharing and health diagnosis. However, these cloud-assisted EHR systems using blockchain [17,18] do not specifically address a secure protocol for registration, authentication, transaction uploading, and so on. Therefore, we propose the secure protocol for cloud-assisted EHR system using blockchain to guarantee security, integrity, and decentralization for EHR sharing and health diagnosis. The proposed EHR system utilizes the cloud technology to achieve storage efficiency, and the data in each block only stores metadata to increase block construction efficiency and minimize distributed storage waste. Furthermore, in the proposed EHR system, blockchain technology is used to efficiently provide data integrity and access control using log transactions. Moreover, the proposed EHR system provides secure health data sharing in a public channel using ECC.

1.1. 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.

1.2. 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 Section 4 and Section 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.

2. 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.

3. Preliminaries

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

3.1. 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].

3.2. 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.

4. 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.

Figure 1.

Proposed cloud-assisted electronic health record (EHR) system model using blockchain.

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.

5. 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 ($NA$) sets up the networks. The $NA$ 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 $NA$ selects a secret key $s_{NA}$ and generates a public key $P{K}_{NA}=s_{NA}·G$. Finally, $NA$ shares the network configuration and policies with all system participants. Furthermore, the $NA$ publishes, $\{p,q,G,P,P{K}_{NA}\}$ 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.

Table 1.

Notations.

Notations	Meanings
$P_i$	i-th patient
$M{C}_j$	j-th medical center
$NA$	Network Administrator
$I{D}_i,I{D}_j$	Identity of $P_i$ and $M{C}_j$
$P{W}_i$	Password of $P_i$
$r_i,r_j$	Secret keys of $P_i$ and $M{C}_j$
$s_{NA}$	Secret key of $NA$
$T_1,T_2$	Timestamps
$T_{up},T_{access}$	Uploading/accessing time of EHR
$K_{NA},r_{NA}$	Random numbers generated by $NA$
$P{K}_i,P{K}_j$	Public keys of $P_i$ and $M{C}_j$
$Cer{t}_i,Cer{t}_j$	Certificates of $P_i$ and $M{C}_j$
$E_p(a,b)$	A nonsingular elliptic curve $y^2=x^3+ax+b$ (mod p)
G	A base point for elliptic curve
$HI{D}_i,PI{D}_j$	Pseudo-identities of $P_i$ and $M{C}_j$
$T_x$	Log transaction
$KM{S}_j$	Secure pre-shared key among $M{C}_j$ and $CS$
$EHR$	Electronic health record
$RI$	Information of health record
$RE$	Request message of EHR
$SK$	Common session key shared among $P_i$ and $M{C}_j$
$h(*)$	Collision resistant one-way hash function
⊕	XOR operation
$\left|\right|$	Concatenation operation

5.1. Registration Phase

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

5.1.1. 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 $NA$ 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.

• Step 1: 

  The $P_i$ requests registration to the network administrator $NA$. First, $P_i$ inputs identity $I{D}_i$ and password $P{W}_i$. Then, the $P_i$ generates a random number $a_i$ and computes $HI{D}_i=h(a_i\left|\right|I{D}_i)$ and sends $HI{D}_i$ to the $NA$.

• Step 2: 

  The $NA$ chooses a random number $K_{NA}$ and computes $x_i=h(HI{D}_i\left|\right|K_{NA})$ using the $HI{D}_i$ received from the $P_i$. Then, the $NA$ stores $\left\{x_i\right\}$ into the smartcard and issues it to the $P_i$ in the blockchain. Finally, the $NA$ stores $\left\{HI{D}_i\right\}$ in secure database.

• Step 3: 

  After the $P_i$ receives smartcard from the $NA$, the $P_i$ generates a random number $r_i$ as a secret key. $P_i$ computes $HP{W}_i=h(I{D}_i\left|\right|P{W}_i)$, $A_i=HP{W}_i\oplus a_i$, $B_i=h(I{D}_i\left|\right|P{W}_i\left|\right|a_i)\oplus r_i$, $C_i=h(a_i\left|\right|r_i)\oplus x_i$ and $D_i=h(a_i\left|\right|r_i\left|\right|x_i)$. And then, the $P_i$ generates a public key $P{K}_i=r_i·G$ and replaces $\left\{x_i\right\}$ with $\left\{C_i\right\}$ in a smartcard. Finally, $P_i$ stores $\{A_i,B_i,C_i,D_i\}$ in the smartcard.

Figure 2.

Patient registration phase of the proposed protocol.

5.1.2. Medical Center Registration Phase

A medical center ($M{C}_j$) must register with the $NA$ to have a key agreement with patients and exchange information with other related medical centers. The masked identity of the $M{C}_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 $M{C}_j$ chooses a unique identity $I{D}_j$ and generates a random number $r_j$ as a its secret key. Then, the $M{C}_j$ computes a masked identity $PI{D}_j=h(I{D}_j\left|\right|r_j)$ and generates a public key $P{K}_j=r_j·G$. $M{C}_j$ sends $PI{D}_j$ to the $NA$.

• Step 2: 

  After receiving registration request message, the $NA$ chooses a random number $r_{NA}$ and retrieves $\left\{HI{D}_i\right\}$ in secure database. Then, the $NA$ computes $Cer{t}_j=h(PI{D}_j\left|\right|r_{NA})+s_{NA}·P{K}_j$. The $NA$ stores $Cer{t}_j$ with $PI{D}_j$ and sends $\{Cer{t}_i,HI{D}_i\}$ to $M{C}_j$.

• Step 3: 

  After the $M{C}_j$ receives the messages, the $M{C}_j$ stores $\{Cer{t}_j,HI{D}_i\}$ in secure database.

Figure 3.

Medical center registration phase of the proposed protocol.

5.2. 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 $I{D}_i$, $P{W}_i$, and smartcard. Then, the smartcard computes $HP{W}_i=h(I{D}_i\left|\right|P{W}_i)$, $a_i=HP{W}_i\oplus A_i$, $HI{D}_i=h(a_i\left|\right|I{D}_i)$, $r_i=h(I{D}_i\left|\right|P{W}_i\left|\right|a_i)\oplus B_i$, $x_i=h(a_i\left|\right|r_i)\oplus C_i$, and $D_i^{*}=h(a_i\left|\right|r_i\left|\right|x_i)$. Then, the smartcard checks whether $D_i^{*}\stackrel{?}{=}{D}_i$. If it is correct, the $P_i$ generates a timestamp $T_1$ and encrypts messages $M_1=\left\{\right(x_i\left|\right|HI{D}_i\left|\right|T_1)+r_i·P{K}_j\}$ and computes $M_{ap}=h(x_i\left|\right|HI{D}_i)$. Next, the $P_i$ sends a message $<M_1,M_{ap},T_1>$ to $M{C}_j$ via a public channel.

• Step 2: 

  After receiving the message $<M_1,M_{ap},T_1>$, the $M{C}_j$ decrypts $(x_i\left|\right|HI{D}_i\left|\right|T_1)=M_1-r_j·P{K}_i$. After that, the $M{C}_j$ retrieves $HI{D}_i^{*}$ in secure database and checks whether $HI{D}_i^{*}\stackrel{?}{=}HI{D}_i$. If it is correct, the $M{C}_j$ computes $M_{ap}^{*}=h(x_i\left|\right|HI{D}_i)$ and checks whether $M_{ap}^{*}\stackrel{?}{=}{M}_{ap}$. If it is valid, the $M{C}_j$ generates a random number $b_j$ and timestamp $T_2$ and calculates $E_i=b_j\oplus x_i$, $M_{amc}=h(PI{D}_j\left|\right|b_j\left|\right|T_2)$. $HI{D}_i$ updates at the proper period. After that, the $M{C}_j$ generates a session key $S{K}_{ij}=h(HI{D}_i\left|\right|PI{D}_j\left|\right|x_i\left|\right|b_j)$. Finally, $M{C}_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 $M{C}_j$, the $P_i$ computes $b_j=E_i\oplus x_i$, and $M_{amc}^{*}=h(PI{D}_j\left|\right|b_j\left|\right|T_2)$. Then, the $P_i$ checks whether $M_{amc}^{*}\stackrel{?}{=}{M}_{amc}$. If it is valid, the $P_i$ computes a session key $S{K}_{ij}=h(HI{D}_i\left|\right|PI{D}_j\left|\right|x_i\left|\right|b_j)$.

Figure 4.

Authentication phase of the proposed protocol.

5.3. Smart Contract Uploading Phase

After receiving information for the smart contract from the $P_i$, the $M{C}_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(HI{D}_i\left|\right|PI{D}_j\left|\right|S{K}_{ij})$ and encrypts his/her information with $S{K}_{ij}$; $M_{inf}=(HI{D}_i\left|\right|PI{D}_j{)}_{S{K}_{ij}}$. Then, the $P_i$ sends $<M_{sc},M_{inf}>$ to the $M{C}_j$.

• Step 2: 

  The $M{C}_j$ computes $M_{sc}^{*}=h(HI{D}_i\left|\right|PI{D}_j\left|\right|S{K}_{ij})$ and checks $M_{SC}^{*}\stackrel{?}{=}{M}_{SC}$. If it is valid, $M{C}_j$ decrypts $M_{inf}$ and generates a smart contract $Sc$ using $(HI{D}_i,PI{D}_j,Cer{t}_j)$. Finally, the $M{C}_j$ uploads $Sc$ in the blockchain.

Figure 5.

Smart contract uploading phase of the proposed protocol.

5.4. EHR Storing Phase

After uploading smart contract, the $M{C}_j$ generates $EH{R}_i$ and stores $EH{R}_i$ in $CS$. Detailed steps are as follows in Figure 6.

• Step 1: 

  The $M{C}_j$ generates $EH{R}_i$ including $HI{D}_i$, $PI{D}_j$, an information of health record $RI$, and EHR’s uploading time $T_{up}$. Then, the $M{C}_j$ encrypts $EH{R}_i$ using a secure pre-shared key $M_{up}={\left(EH{R}_i\right)}_{KM{S}_j}$ and computes $M_{CU}=h(EH{R}_i\oplus PI{D}_j)$. Finally, the $M{C}_j$ sends $<M_{up},M_{CU}>$ to the $CS$.

• Step 2: 

  The $CS$ decrypts $M_{up}$ with $KM{S}_j$, computes $M_{CU}^{*}=h(EH{R}_i\oplus PI{D}_j)$ and checks $M_{CU}^{*}\stackrel{?}{=}{M}_{CU}$. If it is correct, the $CS$ stores $EH{R}_i$ in the server database.

Figure 6.

EHR storing phase of the proposed protocol.

5.5. EHR Requesting Phase

If the $M{C}_j$ wants to confirm $EH{R}_i$, $M{C}_j$ sends request messages to the $CS$. Then, the $CS$ sends $EH{R}_i$ to $M{C}_j$. Detailed steps are as follows in Figure 7.

• Step 1: 

  The $M{C}_j$ generates request messages $RE$ and encrypts $M_{req}=\left(RE\right||PI{D}_j{)}_{KM{S}_j}$ using $KM{S}_j$ and computes $M_{CR}=h(RE\oplus PI{D}_j)$. Then, the $M{C}_j$ sends $<M_{req},M_{CR}>$ to the $CS$.

• Step 2: 

  After receiving the messages $<M_{req},M_{CR}>$, the $CS$ decrypts $M_{req}$ with $KM{S}_j$. After that, the $CS$ computes $M_{CR}^{*}=h(RE\oplus PI{D}_j)$ and checks $M_{CR}^{*}\stackrel{?}{=}{M}_{CR}$. If it is correct, the $CS$ retrieves $EH{R}_i$ corresponding request. The $CS$ encrypts $EH{R}_i$ with $KM{S}_j$ and calculates $M_{CE}=h\left(RE\right||EH{R}_i\left|\right|PI{D}_j)$. After then, the $CS$ sends $<M_E,M_{CE}>$ to the $M{C}_j$.

• Step 3: 

  $M{C}_j$ decrypts the received $M_E$ with $KM{S}_j$ and computes $M_{CE}^{*}=h\left(RE\right||EH{R}_i\left|\right|PI{D}_j)$. Then, the $M{C}_j$ checks $M_{CE}^{*}\stackrel{?}{=}{M}_{CE}$. If it is not valid, the $M{C}_j$ eliminates communication and received data.

Figure 7.

EHR requesting phase of the proposed protocol.

5.6. Log Transaction Uploading Phase

After $M{C}_j$ receives $EH{R}_i$ from $CS$, $M{C}_j$ generates a log transaction and uploads the log transaction in the blockchain. The $M{C}_j$ generates a log transaction $Tx=\{HI{D}_i,PI{D}_j,T_{access},Si{g}_j\}$, where $T_{access}$ is accessing time of $EH{R}_i$ and $Si{g}_j$ is a signature of the $M{C}_j$. Finally, the $M{C}_j$ uploads $Tx$ in the blockchain. The detailed step is as following in Figure 8.

Figure 8.

Log transaction uploading phase of the proposed protocol.

6. 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.

6.1. 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.

6.1.1. 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_{NA}$. Moreover, the $M_1$ is encrypted by the $P_i$’s secret key. Therefore, the proposed protocol is secure against impersonation attacks.

6.1.2. Session Key Disclosure Attack

If the $M_A$ wants to generate a legitimate session key $S{K}_{ij}=h(HI{D}_i\left|\right|PI{D}_j\left|\right|x_i\left|\right|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 $M{C}_j$ because they are masked with random numbers $a_i$ and $r_j$. Therefore, the proposed protocol can prevent session key disclosure attacks.

6.1.3. Perfect Forward Secrecy

Even if a $M_A$ knows a long-term private secret key $s_{NA}$, the $M_A$ cannot obtain the previous session key, because a session key $S{K}_{ij}=h(HI{D}_i\left|\right|PI{D}_j\left|\right|x_i\left|\right|b_j)$ does not include $s_{NA}$. Further, if the long-term private parameter $K_{NA}$ is compromised, the $M_A$ cannot obtain $x_i$. Because $x_i$ is masked with $HI{D}_i$ and $HI{D}_i$ is masked with a random number $a_i$. Therefore, the proposed protocol guarantees perfect forward secrecy.

6.1.4. Replay Attack

Suppose a $M_A$ learns transmitted messages performing a replay attack. However, the $M_A$ cannot use previous messages, because transmitted messages include timestamps, and $P_i$ and $M{C}_j$ check the timestamps are correct. Then, they check that $M_{ap}^{*}\stackrel{?}{=}{M}_{ap}$ and $M_{amc}^{*}\stackrel{?}{=}{M}_{amc}$ are correct. Thus, the proposed protocol can resist replay attacks.

6.1.5. Privileged Insider Attack

Suppose a privileged insider user of the system, the user is an insider adversary. The insider adversary knows the registration information $<HI{D}_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 $HP{W}_i$. Therefore, the adversary cannot know $HP{W}_i$ that cannot guess a valid password. Therefore, the proposed protocol prevents privileged insider attack.

6.1.6. Anonymity

A $M_A$ cannot reveal a legitimate patient’s real identity $I{D}_i$, because $I{D}_i$ is masked by hash function or encryption with random numbers or secret key. Therefore, our protocol provides the patient’s anonymity.

6.1.7. Mutual Authentication

According to Section 6.1.1, the $M_A$ cannot compute a valid session key and cannot impersonate a legitimate patient. Moreover, $P_i$ and $M{C}_j$ check a legitimate entity to verify whether $M_{ap}^{*}\stackrel{?}{=}{M}_{ap}$ and $M_{amc}^{*}\stackrel{?}{=}{M}_{amc}$ are correct. If the conditions are correct, the $P_i$ and $M{C}_j$ authenticate each other. Therefore, our protocol can provide secure mutual authentication.

6.2. 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
$X|\equiv Q$	Xbelieves statement Q
$X|\sim Q$	X once said Q
$X\Rightarrow Q$	Xcontrols statement Q
#Q	Statement Q is fresh
$X⊲Q$	Xsees statement Q
$<Q{>}_Z$	Formula Q is combined with formula Z
${\left\{Q\right\}}_K$	Q is encrypted under key K
$\stackrel{K}{{}_{⟶Y}}$	Y has K as a public key
$X\stackrel{K}{\leftrightarrow }Y$	X and Y may use shared key K to communicate
$SK$	Session key used in the current session

6.2.1. BAN Logic Rules

The BAN logic rules are defined as follows.

• 1. 
  Message meaning rule:

  $$\frac{X|\equiv X\stackrel{K}{\leftrightarrow }Y,X⊲{\left\{Q\right\}}_K}{X\left|\equiv Y\right|\sim Q}$$
• 2. 
  Nonce verification rule:

  $$\frac{X\left|\equiv \#\left(Q\right),X\right|\equiv Y|\sim Q}{X\left|\equiv Y\right|\equiv Q}$$
• 3. 
  Jurisdiction rule:

  $$\frac{X\left|\equiv Y\right|⟹Q,X\left|\equiv Y\right|\equiv Q}{X|\equiv Q}$$
• 4. 
  Freshness rule:

  $$\frac{X|\equiv \#(Q)}{X|\equiv \#\left(Q,Z\right)}$$
• 5. 
  Belief rule:

  $$\frac{X|\equiv \left(Q,Z\right)}{X|\equiv Q}$$

6.2.2. Goals

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

• Goal 1: 

  $P\mid \equiv (P\stackrel{SK}{⟷}MC)$

• Goal 2: 

  $P\mid \equiv MC\mid \equiv (P\stackrel{SK}{⟷}MC)$

• Goal 3: 

  $MC\mid \equiv (P\stackrel{SK}{⟷}MC)$

• Goal 4: 

  $MC\mid \equiv P\mid \equiv (P\stackrel{SK}{⟷}MC)$

6.2.3. Idealized Forms

We define the idealized forms as below.

• $Ms{g}_1$:$P\to MC$: $(x_i,HI{D}_i,T_1)\stackrel{P{K}_j}{{}_{⟶MC}}$
• $Ms{g}_2$:$MC\to P$: ${(PI{D}_j,b_j,T_2)}_{x_i}$

6.2.4. Assumptions

The initial assumptions are given below.

• $A_1$:$P\mid \equiv (P\stackrel{x_i}{⟷}MC)$
• $A_2$:$MC\mid \equiv \#\left(P{K}_j\right)$
• $A_3$:$P\mid \equiv \#\left(b_1\right)$
• $A_4$:$P\mid \equiv MC\Rightarrow (P\stackrel{SK}{⟷}MC)$
• $A_5$:$MC\mid \equiv P\Rightarrow (P\stackrel{SK}{⟷}MC)$
• $A_6$:$MC\mid \equiv \#\left(x_i\right)$
• $A_7$:$MC\mid \equiv \#\left(T_1\right)$
• $A_8$:$P\mid \equiv \#\left(T_2\right)$

6.2.5. Proof Using BAN Logic

We perform the BAN logic analysis. The detailed steps are as follows.

• Step 1: 
  From $Ms{g}_1$ we can get,

  $$S_1:MC⊲(x_i,HI{D}_i,T_1)\stackrel{P{K}_j}{{}_{⟶MC}}$$
• Step 2: 
  From the message meaning rule with $S_1$ and $A_2$,

  $$S_2:MC\mid \equiv P|\sim (x_i,HI{D}_i,T_1)$$
• Step 3: 
  We use the freshness rule with $S_2$ and $A_6$,

  $$S_3:MC\mid \equiv \#(x_i,HI{D}_i,T_1)$$
• Step 4: 
  Using the nonce verification rule with $S_2$ and $S_3$,

  $$S_4:MC\mid \equiv P\mid \equiv (x_i,HI{D}_i,T_1)$$
• Step 5: 
  By the Belief rule with $S_4$ and $A_7$,

  $$S_5:MC\mid \equiv P\mid \equiv (x_i,HI{D}_i)$$
• Step 6: 
  Because of the session key $SK=h\left(HI{D}_i\right|\left|PI{D}_j\right|\left|x_i\right|\left|b_j\right)$, from $S_5$ and $A_3$,

  $$S_6:MC\mid \equiv P\mid \equiv (P\stackrel{SK}{⟷}MC)\left(\mathbf{Goal}\mathbf{4}\right)$$
• Step 7: 
  Using the jurisdiction rule with $S_6$ and $A_5$,

  $$S_7:MC\mid \equiv (P\stackrel{SK}{⟷}MC)\left(\mathbf{Goal}\mathbf{3}\right)$$
• Step 8: 
  From $Ms{g}_2$ we can get,

  $$S_8:P⊲{(PI{D}_j,b_j,T_2)}_{x_i}$$
• Step 9: 
  From the message meaning rule with $S_8$ and $A_1$,

  $$S_9:P\mid \equiv MC|\sim {(PI{D}_j,b_j,T_2)}_{x_i}$$
• Step 10: 
  We use the freshness rule with $S_9$ and $A_3$,

  $$S_{10}:P\mid \equiv \#{(PI{D}_j,b_j,T_2)}_{x_i}$$
• Step 11: 
  Using the nonce verification rule with $S_8$ and $S_9$,

  $$S_{11}:P\mid \equiv MC\mid \equiv {(PI{D}_j,b_j,T_2)}_{x_i}$$
• Step 12: 
  By the belief rule with $S_{11}$ and $A_8$,

  $$S_{12}:P\mid \equiv MC\mid \equiv {(PI{D}_j,b_j)}_{x_i}$$
• Step 13: 
  Because of the session key $SK=h\left(HI{D}_i\right|\left|PI{D}_j\right|\left|x_i\right|\left|b_j\right)$, from $S_{12}$ and $A_6$,

  $$S_{13}:P\mid \equiv MC\mid \equiv (P\stackrel{SK}{⟷}MC)\left(\mathbf{Goal}\mathbf{2}\right)$$
• Step 14: 
  Using the jurisdiction rule with $S_{13}$ and $A_4$,

  $$S_{14}:P\mid \equiv (P\stackrel{SK}{⟷}MC)\left(\mathbf{Goal}\mathbf{1}\right)$$

Therefore, the goals 1–4 clearly show that the proposed protocol provides secure mutual authentication between $P_i$ and $M{C}_j$.

6.3. 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 Figure 9, Figure 10 and Figure 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.

Figure 9.

High-Level Protocol Specification Language (HLPSL) syntax of patient.

Figure 10.

HLPSL syntax of medical center.

Figure 11.

HLPSL syntax of network administrator.

Figure 12.

HLPSL syntax of session and environment.

Figure 13.

Automated Validation of Internet Security Protocols and Applications (AVISPA) analysis result using OFMC and CL-AtSe.

7. Performance Analysis

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

7.1. 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].

• $T_{bp}:$ The computation time of a bilinear pairing operation ≈ 4.211 ms.

• $T_{bp-sm}:$ The computation time of a scalar multiplication operation on bilinear pairing $\approx 1.709$ ms.

• $T_{bp-ad}:$ The computation time of a point addition operation on bilinear pairing $\approx 0.0071$ ms.

• $T_{ec-sm}:$ The computation time of a scalar multiplication operation on elliptic curve cryptography $\approx 0.442$ ms.

• $T_{ec-ad}:$ The computation time of a point addition operation on elliptic curve cryptography $\approx 0.0018$ ms.

• $T_{ec-enc}:$ The computation time of a encryption with elliptic curve cryptography $\approx 0.5102$ ms.

• $T_{ec-dec}:$ The computation time of a decryption with elliptic curve cryptography $\approx 0.7399$ ms.

• $T_h:$ The computation time of a one-way hash function operation $\approx 0.0001$ ms.

• $T_{exp}:$ The computation time of an exponentiation operation $\approx 3.886$ ms.

Table 3 shows computation costs of the proposed scheme with related schemes [25,26]. In Liu et al.’s scheme [25], a client computes $\{T=tP,T^{‘}=t{Q}_{AP}\}$ with multiplication on bilinear pairing, $\left\{I^{{}^{\prime }}\right\}$ with addition on bilinear pairing, $\left\{r\right\}$ with exponential function, $\{U=k{S}_2-v{s}_1{Q}_2\}$ with two multiplication and one addition on bilinear pairing, and $\{v,key,MA{C}_{key}\left(v\right)\}$ with hash function. Then, a application provider computes $\left\{T\right\}$ with multiplication on bilinear pairing, $\left\{I\right\}$ with addition on bilinear pairing, $\{v,key,MA{C}_{key}\left(v\right)\}$ with hash function, $\left\{r\right\}$ with one bilinear pairing operation, one multiplication on bilinear pairing, and one exponential function.

Table 3.

Computation costs of the proposed scheme with related schemes.

	Liu et al. [25]	Renuka et al. [26]	Proposed
Patient/Client	$4T_{bp-sm}+2T_{bp-ad}+T_{exp}+3T_h\approx 10.8643$ ms	$3T_{ec-sm}+10T_h\approx 1.327$ ms	$T_{ec-enc}+7T_h\approx 0.5109$ ms
Medical center	$2T_{bp-sm}+T_{bp-ad}+T_{exp}+T_{bp}+3T_h\approx 11.5863$ ms	$3T_{ec-sm}+5T_h\approx 1.3265$ ms	$T_{ec-dec}+3T_h\approx 0.7402$ ms

In Renuka et al.’s scheme [26], a user computes $\{V_i,A_i,F_i,sk\}$ with two hash functions, $\{R_i,E_i,E_s\}$ with multiplication on ECC, $\{D_i,H_i\}$ with one hash function. Moreover, in the registration phase, a server computes $H\left(B_i\right)$ and stores it in memory. After that, in authentication phase, the server extracts the $H\left(B_i\right)$. Thus, we do not include $H\left(B_i\right)$ in the operation. Then, server computes $\{I{D}_i,h(x\oplus I{D}_i),h(C_i\left|\right|T_1\left|\right|E_i\left|\right|H\left(B_i\right)),sk,H_i\}$ with one hash function, $\{E_i,R_s,E_s\}$ with multiplication on ECC.

In the proposed scheme, a patient computes $\{HP{W}_i,r_i,x_i,D_i^{*},M_{ap},M_{amc}^{*},S{K}_{ij}\}$ with hash function, $M_1$ with ECC encryption. Moreover, the medical center computes $\{M_1-r_j·P{K}_i\}$ with ECC decryption, $\{M_{ap}^{*},M_{amc},S{K}_{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.

7.2. 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 ($E{N}_{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].

Table 4.

Communication costs of the proposed scheme with related schemes.

	Liu et al. [25]	Renuka et al. [26]	Proposed
Patient/Client	$H+3G_1+T=3264$ bits	$2H+G+T=672$ bits	$E{N}_{ecc}+H+T=512$ bits
Medical center	$MAC=160$ bits	$G+H+T=512$ bits	$2H+T=352$ bits

In Liu et al.’s scheme [25], transmitted messages $\{v,U,t_c,T^{{}^{\prime }},I^{{}^{\prime }}\}$ and $\left\{MAC\right\}$. $U,T^{{}^{\prime }}$, and $I^{{}^{\prime }}$ 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.

7.3. Security Properties

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.

Table 5.

Security properties of the proposed scheme with related schemes.

	Liu et al. [25]	Renuka et al. [26]	Proposed
Impersonation attack	X	O	O
Session key disclosure attack	X	O	O
Perfect forward secrecy	X	O	O
Replay attack	O	O	O
Privileged insider attack	X	O	O
Single point of failure	X	X	O
Anonymity	O	O	O
Mutual authentication	X	O	O
Bottleneck	X	X	O

8. 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.

Author Contributions

Conceptualization, M.K.; Formal analysis, S.Y., J.L. and Y.P. (YoHan Park); Software, M.K., and J.L.; Supervision, Y.P. (YoungHo Park); Validation, S.Y., J.L., Y.P., (YoHan Park) and Y.P. (YoungHo Park); Writing—original draft, M.K.;Writing—review and editing, S.Y., Y.P., (YoHan Park) and Y.P. (YoungHo Park). All authors have read and agreed to the published version of the manuscript.

Funding

This work was supported by the Basic Science Research Program through the National Research Foundation of Korea funded by the Ministry of Science, ICT and Future Planning under Grant 2017R1A2B1002147 and in part by the BK21 Plus project funded by the Ministry of Education, Korea, under Grant 21A20131600011.

Conflicts of Interest

The authors declare no conflict of interest.