A Provable and Secure Patient Electronic Health Record Fair Exchange Scheme for Health Information Systems

Abstract

In recent years, several hospitals have begun using health information systems to maintain electronic health records (EHRs) for each patient. Traditionally, when a patient visits a new hospital for the first time, the hospital’s help desk asks them to fill in relevant personal information on a piece of paper and verifies their identity on the spot. This patient will find that many of her personal electronic records are in many hospital’s health information systems that she visited in the past, and each EHR in these hospital’s information systems cannot be accessed or shared between these hospitals. This is inconvenient because this patient will again have to provide their personal information. This is time-consuming and not practical. Therefore, in this paper, we propose a practical and provable patient EHR fair exchange scheme for each patient. In this scheme, each patient can securely delegate the information system of a current hospital to a hospital certification authority (HCA) to apply migration evidence that can be used to transfer their EHR to another hospital. The delegated system can also establish a session key with other hospital systems for later data transmission, and each patient can protect their anonymity with the help of the HCA. Additionally, we also provide formal security proofs for forward secrecy and functional comparisons with other schemes.

1. Introduction

In recent years, many research topics have arisen to make human life more convenient. An electronic health record (EHR) is an integrated personal medical record in health information systems. Many countries implement their own health information systems to help manage each patient’s activities and keep track of their health. We can imagine a scenario in which a patient (let us call her Alice) plans to go to a new hospital and sees a doctor. In this situation, she may have to fill in her personal medical information another time when she attends a new hospital. In addition, if her doctor needs to know her medical treatment history from other hospitals, how she provides these records securely to her doctor needs to be considered. These problems are especially urgent. Our proposed scheme ensures the ease and security of data access and migration. Our approach proposes a practical and provable patient EHR fair exchange scheme with session key establishment for health information systems. Patients cannot only delegate the migration of their personal EHR to a desired hospital system from their current hospital health information system but also protect their privacy. Our mechanism provides secure data storage and the secure transfer of authorized information to a designated location. This study has two limitations. First, we assume that each patient’s EHR record is well defined and appropriate for each healthcare facility. The process of electronic health information record transmission at each hospital provider is easily done by implementing our proposed scheme for secure encrypted transmission without considering issues such as different forms or file names or a lack of formatting details. Second, each facility will transfer or link the patient’s EHR to other facilities through patient consent or under a national policy when the patient requires better care at those facilities.

Summarizing all problems, we propose a high-level practical and provable patient EHR fair exchange scheme with key agreement for health information systems. Not only could a patient delegate the health information systems of the current hospital to migrate their personal EHR to the desired hospital system, but they can also keep their privacy. Our mechanism provides data storage and the secure transfer of authorized information to designated locations. What information can be authorized is beyond the scope of this study to determine. For example, whether COVID-19 patient privacy concerning patients’ names, identities, and genetic sequences can be transmitted to different hospitals is beyond this study’s scope. The mechanism presented here could guarantee data transfer and storage safely and securely. What is more, our scheme also provides a formal security proof in a random oracle model under chosen-ciphertext security.

This paper is organized as follows. Section 2 introduces related works. Section 3 deploys security definitions. Section 4 shows our proposed method. Section 5 describes our security analysis. Section 6 provides a security proof. Finally, Section 7 presents our conclusions.

2. Related Works

In this section, we surveyed some articles [1,2,3,4]. In [1], the author only mentioned how EHRs are used and managed. The author also talked about the EHR format that followed the definition of HL7 [5] and that performed well-known protocols to encode each patient’s EHR from TCP/IP, MIME, HTTP(S), and SOAP.

In [2], the authors discussed several security requirements, such as EHR storage security, malicious code prevention, protected access right management, and other aspects to protect the health information system. However, they did not provide a practical scheme that would allow a patient to migrate their EHR to a health information system. We can imagine a scenario where a hospital only adopts the above simple protocols to develop its own health information system without any security mechanism. Additionally, it is not feasible for each patient to perform their own EHR exchange under this scheme.

On the other hand, in [5], the authors suggested that each patient’s health records (or files) could be portably stored on a flash disk. This idea is appealing but is currently difficult to implement. There are many security issues to be handled, including portable device security and patient medical file access rights. However, more security mechanisms are needed to solve these kinds of security issues, which are beyond the scope of this research.

In addition, various patient authentication schemes of e-health systems have been proposed [6,7,8,9,10]. In [6,7], the schemes suffered a user impersonation attack and did not offer session key establishment with a formal security proof. The authors in [8,9,10] did not provide session key establishment with a forward secrecy proof. In [11,12], the authors each proposed a framework with a patient-centric access right in a blockchain environment. However, they did not provide a practical mechanism for each patient to perform EHR migration exchange securely.

Additionally, many studies are now examining the importance of personal privacy and data authorization. For example, the prevalence of COVID-19 has made many patients reluctant to disclose information about their infection, but government healthcare units want to control the trajectory of tracking these patients. A method of providing improvements in these mechanisms is the main motivation and purpose of our study. Therefore, in this paper, we emphasize providing a secure, simple, and complete mechanism for authorizing data transfer during personal information migration and demonstrate that our approach is secure and effective in practice through a professional information security authentication model.

Hence, we summarize and list here seven kinds of security attack when a patient attempts to migrate their personal information data through a traditional authentication model:

• Replay Attack Resistance: A malicious attacker intercepts the parameters used in the mutual authentication transaction successfully. They can then forward these parameters again to impersonate one party to communicate with other parties during the mutual authentication transaction and vice versa.
• Resist User Impersonation: A malicious attacker impersonates some party by replaying the intercepted signatures or random variables to other parties engaged in the mutual authentication transaction.
• Mutual Authentication: Without mutual authentication with other e-health systems, an attacker can pretend as a fake system to let other patients register and login. Then, patient’s EHRs information cannot be stored securely in this storage location.
• Data Security Problem: An attacker intercepts the parameters, including ciphertext, successfully during the mutual authentication transaction, and they may then decrypt the intercepted ciphertext by adopting these intercepted parameters.
• Session Key Establishment with Forward Secrecy: Each party communicates a temporary symmetric key for data transmission after performing mutual authentication successfully. If the session key is easy to guess or derive by an attacker successfully without forward secrecy, then this attacker can derive the used session keys before the next mutual authentication phase.
• EHR Fair Exchange Problem: If there is packet loss or data loss during the EHR migration transaction, a patient’s EHR can be lost when they attended a desired hospital. At this time, without their personal EHR, the e-health system of this hospital can delay their medical treatment in this situation.
• Patient’s Anonymity Protection: During the EHR migration transaction, if a patient’s EHR identity information is not protected well, then it could be exposed and intercepted by an attacker. Additionally, the patient’s EHR information may be misused by an attacker further.

Our contribution is to offer an efficient provable and practical patient EHR fair exchange scheme so that each patient can migrate their personal EHR securely from one hospital to another and provides solutions to the above seven problems. We designed a secure patient EHR exchange protocol that can be integrated into the e-health information system of each hospital. The proposed scheme could also guarantee convenience, rapidity, and integrity. We constructed a high-level practical and provable patient EHR fair exchange scheme with key agreement for the health information system. A patient could not only delegate the current hospital’s health information systems to migrate their personal EHR to the desired hospital system, but also keep their privacy. Additionally, our scheme demonstrates a formal security proof with light-weight computation for both authentication parties.

3. The Proposed Scheme

Our proposed scheme contains three stages: the migration registration phase, the EHR migration phase, and the data recovery phase.

3.1. Preliminary

In this subsection, we provide some definitions in our proposed scheme.

• n: A large prime number that forms a finite primes field with an order less than n.
• l: A security parameter that defines the hashed messages’ length.
• V: The current medical organization.
• W: The patient’s desired medical organization.
• U: A patient making an authentication request with a server V in a health information system.
• S: A server that accepts the registration of the patient request, the login request, and the password modification request in the health information system of hospital V.
• $UI{D}_i$: A patient’s real identity computed from social security numbers, where $i\in \left\{U\right\}$ in the certification.
• $I{D}_i$: A registration local identity that can link the $UI{D}_i$ of user $i\in \left\{U\right\}$.
• $H_1$, $H_2$: Two secure hash functions that each maps $Z_n^{*}\to {\{0,1\}}^l$ with collision-resistance and outputs the same l-bits hash strings.
• $p{w}_U$: A initial password that is chosen by a server V when a patient U has remotely registered on the server for the first time.
• $E_{k_i}$: A symmetric key encryption function for the party i under the symmetric key $k_i$, where $i\in \{U,V\}$.
• $D_{k_i}$: A symmetric key decryption function for the party i under the symmetric key $k_i$, where $i\in \{U,V\}$.
• $AS{E}_{p{k}_i}$: An asymmetric key encryption function for the party i, where $i\in \{U,V\}$.
• $AS{D}_{s{k}_i}$: An asymmetric key decryption function for the party i, where $i\in \{U,V\}$.
• $EH{R}_i$: A patient electronic health record (EHR) in one hospital organization, where $i\in U$.
• $Bi{o}_i$: A biometric information value that is chosen uniformly from the party i, where $i\in \left\{U\right\}$.
• $Date$: A patient EHR migration limitation date period.
• $Cer{t}_i$: A migration certification of the party i with $I{D}_i$ registration and public keys for this $I{D}_i$, where $i\in \{U,V\}$.
• $HCA$: A hospital certification authority (HCA) that helps the patient to generate the patient migration permission signature to another hospital or medical center in the public key infrastructure (PKI).
• $Agre{e}_{i->j}$: A patient-delegated EHR migration agreement document whereby the patient agrees that its own patient files can migrate from current hospital i to the desired one j, where $i,j\in \{V,W\}$.

3.2. The Migration Registration Phase

Before starting this phase, a patient (U) forwards $(UI{D}_U,I{D}_U)$ to a hospital certification authority ($HCA$) for migration certification registration with a secure channel. After receiving this identity $(UI{D}_U,I{D}_U)$, the HCA keeps this link information and generates $Cer{t}_i$ certification with $I{D}_i$ for EHR migration and forwards this $Cer{t}_i$ to the patient U.

When U performs this phase with the server V of the current hospital, U forwards a patient migration registration request to a server (V). After receiving this request, the server V forwards this request to the $HCA$ to help U obtain the permission signature from $HCA$. V first prepares two hash functions: one is $H_1$, and the other is $H_2$, where $H_1:Z_n^{*}\to {\{0,1\}}^l$ and $H_2:Z_n^{*}\to {\{0,1\}}^l$.

• First, U has prepared their biometric value $Bi{o}_U$ and computed a random value $r_{B_U}$ with a random number $r_U^{\prime \prime }\in Z_n^{*}$, where $r_{B_U}=r_U^{\prime \prime }\oplus H_1\left(Bi{o}_U\right)$. After the above is computed successfully, they forward their identity $I{D}_U$, which is computed from $H_1(r_U^{\prime \prime }\left|\right|UI{D}_U)$ and encrypted via real identity cipher-text $C_{HCA}=A{E}_{p{k}_{HCA}}(r_U^{″},Bi{o}_U,UI{D}_U,I{D}_U,Cer{t}_U,EH{R}_U\oplus r_U^{″})$ with public key $p{k}_U$ and their certificate $cer{t}_U$ with their biometric information $r_{B_U}$, to the server V. It also generates the applicant-delegated migration signature $S_U$, where the signature $S_U$ is to be the $Si{g}_U(Agre{e}_{V->W},UI{D}_U,I{D}_U,EH{R}_U\oplus r_U^{″})$ with the registration identity $I{D}_U$, real identity $UI{D}_U$, and EHR migration delegated agreement $Agre{e}_{V->W}$ with final ciper-text $EH{R}_U\oplus r_U^{\prime \prime }$. U then prepares the random number $r_V^{\prime \prime }$, where $r_V^{\prime \prime }=r_V\oplus r_{B_U}$, and forwards these files to the server V with $(r_V^{\prime \prime },C_{HCA},S_U,Cer{t}_U,Agre{e}_{V->W})$.
• After V receives these messages, it can check the $S_U$ with the above messages and forward the $C_{HCA}$ to the $HCA$. When $HCA$ has received this message with $S_U$, it can decrypt $C_{HCA}$ to obtain all parameters. First, it can fetch the random value $r_V^{\prime \prime }\oplus r_{B_U}=r_V$ and verify the signature $S_U$ with other parameters. If they are valid, it saves these files for data recovery usage. It then generates $S_{HCA}$, which is $Si{g}_{HCA}(S_U,Date,I{D}_U)$. Finally, it returns ($S_{HCA},H_1((r_V+1)\left|\right|r_{HCA}),(r_V+1)\oplus r_{HCA},Date,I{D}_U,S_U$) to the server V.
• V receives this message tuple, where one is ($S_{HCA},H_1\left((r_V+1)\right|r_{HCA})$) and the other is ($(r_V+1)\oplus r_{HCA},Date,I{D}_U,S_U$), and it can verify the signature $S_{HCA}$ with the above parameters and compute $r_{HCA}=(r_V+1)\oplus (r_V+1)\oplus r_{HCA}$. When the above messages are valid, V returns $H_1(r_{HCA}+1)$ and forwards it back to the server $HCA$. In addition, it also generates a signature $Si{g}_V(S_{HCA},S_U,Agre{e}_{V->W})$ as the receipt $S_V$ and finishes this phase after forwarding $S_V$ and $S_{HCA}$. We demonstrate in the Figure 1.

3.3. The EHR Migration Phase

In this phase, the server V will behave according to the delegated agreement file $Agre{e}_{V->W}$ with the signature $S_U$, and it prepares these messages as follows.

• First, it selects a random $r_V^{*}$ and computes $C_V=A{E}_{p{k}_W}\left(r_V^{*}\right)$. It then forms the message tuple ($C_V,S_U,S_{HCA},EH{R}_U\oplus r_U^{\prime \prime },Date$) for the server of the desired migration hospital W. When the system of W has received this migration agreement from V, it verifies this message tuple and decrypts $C_V$ to obtain the challenge random number. If all signatures and parameters are valid, it generates the response random number $r_W^{*}\oplus H_2(r_V^{*}+1)$ and returns it to the server V.
• When V receives $r_W^{*}\oplus H_2(r_V^{*}+1)$, it decrypts it with $r_V^{*}+1$. If it is valid, it can obtain $r_W^{*}$ and computes the response random number $H_2((r_W^{*}+1)\oplus r_U^{″}),(r_W^{*}+1)\oplus r_U^{\prime \prime }$ for the server of hospital W. Finally, W receives $H_2(r_W^{*}+1\oplus r_U^{″}),(r_W^{*}+1)\oplus r_U^{\prime \prime }$ from V. It also verifies the message to check if it was returned by the real V. If true, it decrypts $(r_W^{*}+1)\oplus r_U^{\prime \prime }$ to obtain $r_U^{\prime \prime }$, computes the session key $ss{k}_{V,W}=H_1((r_W^{*}+1)\left|\right|(r_V^{*}+1))$, and decrypts $EH{R}_U\oplus r_U^{\prime \prime }$ to fetch the patient’s EHR file $EH{R}_U$ with the random $r_U^{\prime \prime }$.
• After performing mutual authentication successfully, V can also use the session key $ss{k}_{V,W}$ to generate an cihper-text, such as $E_{ss{k}_{V,W}}\left(EH{R}_U\right)$, for the rest of the data transmission of the patient U’s EHR. Figure 2 shows the scenario of this phase.

3.4. The Data Recovery Phase

In this phase, if there is some network packet loss or EHR data loss of the patient U after they have performed the EHR migration phase, then the e-health system of the hospital W cannot obtain the full U’s personal EHR, so U can ask the $HCA$ to deal with this situation.

• First, when a patient migrating to a hospital W that does not receive the $EH{R}_U$ from the server V after querying the system of hospital W, then U can ask $HCA$ to resolve the situation with some evidence $Si{g}_V(S_{HCA},S_U,Agre{e}_{V->W})$ with signatures $S_{HCA}$, $S_U$ and $Agre{e}_{V->W}$. After verifying the above signatures successfully, $HCA$ can fetch the $EH{R}_U\oplus r_U^{\prime \prime }$ to the server of hospital W with $A{E}_{p{k}_W}\left(r_U^{″}\right)$.
• W can then decrypt $A{E}_{p{k}_W}\left(r_U^{″}\right)$ to obtain $r_U^{\prime \prime }$ and fetches the patient’s EHR file $EH{R}_U$ from the above $EH{R}_U\oplus r_U^{\prime \prime }$ by applying ⊕ with $r_U^{\prime \prime }$. At this time, this situation is solved with $HCA$’s help if needed. This phase’s scenario shows in the Figure 3.

4. Security Assumptions

4.1. Secure Digital Signature

In this scheme, we define a secure digital signature. In the beginning, we have that $Sig(·)$ is a signature generation function that inputs a message m with a signer’s secret key $s{k}_i$ and outputs a signature $S_i$. We also assert this signature function is based on the RSA factoring hard problem or the discrete logarithm problem. We can then input a signature such as $S_i$ with the signer’s public key $p{k}_i$ into the verification function $Ver(·)$ and see what the output is. If the output is 1, then we can confirm the signature $S_i$ is valid and signed by the signer i. In this scheme, we also assumed that the signature building block is under the RSA problem. If there is an attacker, we assume it as ${\mathcal{F}}^{*}$. If ${\mathcal{F}}^{*}$ can make a forged l + 1 signature called $S_{i,j+1}^{\prime }$ of some user $i\in \{U,V,HCA\}$ in at most lsignature queries, and this signature can pass the verification $Ver(p{k}_i,S_{i,j+1}^{\prime })$ successfully with non-negligible probability $\epsilon$, then ${\mathcal{F}}^{*}$ can be used to break the RSA factoring problem. Thus,

$$Pr[S_{i,j+1}^{\prime }⟵{\mathcal{F}}^{*}\left(Sig(s{k}_i,·),Ver(p{k}_i,·),i\in \{U,V,HCA\}\right)|Ver\left(S_{i,j+1}^{\prime }\right)=1]\ge \epsilon .$$

(1)

4.2. Unforgeability

In this scheme, we define the secure digital signature scheme in the above. First, we define an attacker ${\mathcal{F}}^{*}$, whose ability is to forge a signature that can be verified successfully through the $Ver(·)$ verification function with non-negligible probability ${\epsilon }^{\prime }$. We also define a simulator $\mathcal{D}$ that adopts ${\mathcal{F}}^{*}$’s ability to break the underlying hard problem (such as the RSA factoring problem) in the above secure signature scheme. After $\mathcal{D}$ is given the environment parameters $G(·)$, it can start the protocol simulation with ${\mathcal{F}}^{*}$. ${\mathcal{F}}^{*}$ can make the signature queries to the $\mathcal{D}$. $\mathcal{D}$ will also output the signature back according to the received input m from ${\mathcal{F}}^{*}$ on some user i. After this simulation, if ${\mathcal{F}}^{*}$ generates a forged signature $S_{i,j+1}^{\prime }$, the verification result of $S_{i,j+1}^{\prime }$ is valid. We then have

$$\begin{array}{c}\hfill Pr\left[{\mathcal{D}}^{{\mathcal{F}}^{*}⟶S_{i,j+1}^{\prime }}\right|Use{S}_{i,j+1}^{\prime }\mathrm{to}\mathrm{solve}\mathrm{the}\mathrm{RSA}\mathrm{factoring}\mathrm{problem}]\ge \\ \hfill Pr[S_{i,j+1}^{\prime }⟵{\mathcal{F}}^{*}\left(Sig(s{k}_i,·),Ver(p{k}_i,·),i\in \{U,V,HCA\}\right)|Ver(p{k}_i,S_{i,j+1}^{\prime })=1]\ge {\epsilon }^{\prime }.\end{array}$$

(2)

In fact, if there is no attack ${\mathcal{F}}^{*}$ that can make a forged signature pass the verification successfully with non-negligible probability $\epsilon$, then we cannot use ${\mathcal{F}}^{*}$ to solve the RSA factoring problem with non-negligible ${\epsilon }^{\prime }$ probability.

Lemma 1

(Unforgeability). First, we define $Sig$, which is a secure digital signature function and equips two secure hash functions, $H_1$ and $H_2$, which can be replaced with two random oracles functions $R{O}_1$ and $R{O}_2$. In our proposed EHR scheme, we also define our proposed EHR scheme with unforgeability (Unf), which satisfies the following situations. In other words, if $Sig$ is $(t^{\prime },{\epsilon }^{\prime })$ and unforgeable, then

$$\begin{array}{c}\hfill Ad{v}_{{\mathcal{F}}^{*},Si{g}^{H_1,H_2,R{O}_1,R{O}_2}}^{Unf}(\theta ,t^{\prime })\le \frac{1}{2·I^3·q_s}+{\epsilon }^{\prime },\end{array}$$

(3)

where $t^{\prime }$ is the maximum total experiment time, including an adversary execution time, I is an upper bound on the number of parties, at most signature oracle $q_s$, and ${\epsilon }^{\prime }$ is taken over the coin flip of our EHR scheme.

4.3. Indistinguishability

We define an attacker $\mathcal{A}$ on the experiment $\mathbf{EXP}$ of our symmetric encryption/decryption functions ($\mathbf{SE}$), which is a game controlled by the simulator $\mathcal{S}$. We also define two pseudo-random hash functions (${\omega }_1$ and ${\omega }_2$), which are satisfied with the property we call “indistinguishability” ($\mathbf{Ind}$), due to which the attacker $\mathcal{A}$ can make a hash query to ${\omega }_1$ and ${\omega }_2$ on the message $M^{\prime }$, which is chosen by $\mathcal{A}$. These functions act as real functions as our hash functions ($H_1$ and $H_2$), where $i\in \{U,V\}$. The simulator also can switch this function pair to respond to each query made by $\mathcal{A}$ during the simulation rounds of the above experiment. Finally, the simulator $\mathcal{S}$ is given a challenge message target M chosen by the $\mathcal{A}$.

At this time, $\mathcal{S}$ makes a coin flip on b. If $b=0$, $\mathcal{S}$ randomly chooses $({\omega }_1,{\omega }_2)$ to generate the hashed value of M and return it to $\mathcal{A}$. Otherwise, $\mathcal{S}$ forwards M to $(H_1,H_2)$ to ask for the hash value. $\mathcal{A}$’s goal is to guess correctly the hashed value that is from $({\omega }_1,{\omega }_2)$ or $(H_1,H_2)$ with non-negligibility probability.

Lemma 2

(Indistinguishability). In this lemma, our symmetric encryption/decryption functions satisfy the indistinguishably property if there is no attacker $\mathcal{A}$ that can guess the hashed value from the chosen (M) with more than $\frac{1}{2}$ with negligible probability ${\epsilon }^{*}$ under the $t^{*}$ polynomial time bound. That is,

$$|Pr[b^{\prime }⟵{\mathcal{F}}^{({\omega }_1,{\omega }_2,H_1,H_2)}\left(M\right)|b=b^{\prime }]-\frac{1}{2}|\le \epsilon .$$

Therefore, we concluded that

$$Ad{v}_{\mathcal{A},\mathbf{SE}}^{Ind}(\theta ,t^{*})\le \frac{1}{2}+{\epsilon }^{*}.$$

4.4. Indistinguishable-Chosen Cipher-Text Attack (Ind-CCA)

In this scheme, we define our proposed asymmetric encryption/decryption function ($\mathbf{ASE}$), which satisfies the semantic security in the following definitions.

First, we define an attacker $\mathcal{A}$ that can ask encryption/decryption queries in our scheme, respectively. However, the attacker $\mathcal{A}$ can also make an encryption query to the chosen message that we define as $M^{\prime }$. The attacker $\mathcal{A}$ can then also make a decryption query to the decryption oracle, whose task is to decrypt the cipher-text sent $\mathcal{A}$. Next, we define $Game$, which is the simulation of our proposed scheme that can equip many different oracles, and oracles can answer back to the adversary depending on the attacker’s input messages. We also define some oracles, such as the encryption oracle $A{E}_{p{k}_T}(·,\theta )$ with the security parameter $\theta$. This encryption oracle can generate the ciphertext according to the received input $M_b$, where $b\in \{0,1\}$. In addition, we also model the decryption oracle that receives the cipher-text C from the attacker $\mathcal{A}$ and returns the final decrypted message M to the attacker $\mathcal{A}$. In the following, we consider two situations involving $\mathcal{A}$.

Phase 1: In this phase, the attacker $\mathcal{A}$ can make the decryption and encryption queries on a chosen message (call it $M^{\prime }$). I.e., if $\mathcal{A}$ makes an encryption query on the input message $M^{\prime }$, then $C^{\prime }⟵A{E}_{p{k}_T}(M^{\prime },\theta )$ returns to $\mathcal{A}$. At this time, $\mathcal{A}$ can also make the decryption query on cipher-text $C^{\prime }$, and the simulator will then forward this $C^{\prime }$ to the decryption oracle and return the final message $M^{\prime }$ back to the $\mathcal{A}$. Additionally, $\mathcal{A}$ can also make other kinds of queries, such as a hash query to the hash oracles.

Challenge: In this phase, if $\mathcal{A}$ has performed training on the above encryption/ decryption query many times, then, in the following challenge phase, the attacker $\mathcal{A}$ will choose a challenge message pair $(M_0^{*},M_1^{*})$ for the simulator for game playing. The simulator then will toss the coin on b after it receives this message pair. If the final output b is 1, then we can have $C^{*}⟵A{E}_{p{k}_T}(M_b^{*},\theta )$. Otherwise, we have $C^{*}⟵A{E}_{p{k}_T}(M_{1-b}^{*},\theta )$. After the attacker $\mathcal{A}$ has asked the cipher-text on the chosen target messages $(M_0^{*},M_1^{*})$, the only restriction is that the $\mathcal{A}$ cannot ask the decryption oracle on the target message $(M_0^{*},M_1^{*})$ with the input cipher-text $C^{*}$. This query can make the simulation fail due to the simulator cannot be able to tell the answer of cipher-text $C^{*}$. Except in the above query, $\mathcal{A}$ can make other kinds of queries on different messages.

Lemma 3.

In this lemma, we model the above actions as the game simulation steps, which we played with the attacker $\mathcal{A}$.

$$\begin{array}{c}\\ \begin{array}{c}Gam{e}_{\mathcal{A},ASE}^{Ind-CCA-b}\left(\theta \right)\hfill \\ \mathbf{Phase}\mathbf{1}.\hfill \\ T\in \{U,V\},\{M_0,M_1\}⟵{\mathcal{A}}^{AS{E}_{p{k}_T}(·,\theta ),AS{D}_{s{k}_T}(·,\theta ),H_1(·),H_2(·)}\hfill \\ \mathbf{Challenge}\mathbf{Phase}.\hfill \\ b\in \{0,1\},C^{*}⟵AS{E}_{p{k}_T}(M_b^{*},\theta ),\hfill \\ b^{\prime }⟵{\mathcal{A}}^{AS{E}_{p{k}_T}(·,\theta )}(C^{*},M_0^{*},M_1^{*})\hfill \\ Return{b}^{\prime }.\hfill \end{array}\hfill \end{array}$$

The advantage function of the adversary that ${\mathcal{A}}_{ASE}^{Ind-CCA}(·,\theta )$ is defined as $Ad{v}_{\mathcal{A},ASE}^{Ind-CCA}\left(\theta \right)=|Pr[Gam{e}_{\mathcal{A},ASE}^{Ind-CCA-1}\left(\theta \right)=1]-Pr[Gam{e}_{\mathcal{A},ASE}^{Ind-CCA-0}\left(\theta \right)=1]|<\frac{1}{2}\left|Pr[Gam{e}_{\mathcal{A},ASE}^{Ind-CCA-1}\left(\theta \right)=1]\right|\le {\epsilon }^{\prime }.$

4.5. Partner Function

In this definition, we define the partner function. We assume that there is an instance ${\mathsf{\Pi }}_i^k$ whose action is the same as player i in the k-th session, where $i,j\in \{U,V\}$ and $k\in N$, where N is the number for total players. Let the partner function be the instance of player j (call it ${\mathsf{\Pi }}_j^{k^{\prime }}$) in the $k^{\prime }$-th session, where $i,j\in \{U,V\}$ and $k^{\prime }\in N$. At this time, the instances ${\mathsf{\Pi }}_i^k$ and ${\mathsf{\Pi }}_j^{k^{\prime }}$ believe that each side is the real player $i,j\in \{U,V\}$ in the $k,k^{\prime }\in N$ session, respectively. At this time, we can say that two instances ${\mathsf{\Pi }}_i^k$ and ${\mathsf{\Pi }}_j^{k^{\prime }}$ are partnered if the following statements are true:

• ${\mathsf{\Pi }}_i^k$’s session identity is the same as the session identity of ${\mathsf{\Pi }}_j^{k^{\prime }}$.
• $p_i$ is the partner of ${\mathsf{\Pi }}_j^{k^{\prime }}$ in the session $k^{\prime }$ of ${\mathsf{\Pi }}_j^{k^{\prime }}$.
• $p_j$ is the partner of ${\mathsf{\Pi }}_i^k$ in the session k of ${\mathsf{\Pi }}_i^k$.

4.6. Freshness

In this definition, we define freshness. We assume that there is an instance where ${\mathsf{\Pi }}_i^k$ is “fresh” if it satisfies the following conditions.

• ${\mathsf{\Pi }}_i^k$ has not been queried the reveal query $Reveal(i,k)$.
• There is a partner ${\mathsf{\Pi }}_j^{k^{\prime }}$ that is matched to partner ${\mathsf{\Pi }}_i^k$ by the partner function, and ${\mathsf{\Pi }}_i^k$ has not been queried the reveal query $Reveal(j,k^{\prime })$.
• The partner of ${\mathsf{\Pi }}_i^k$ is not the inside attacker during communication in the instance of the player j.

4.7. Forward Secrecy (FS)

Our proposed two factor patient authentication scheme is forward secrecy (FS) if $\mathcal{A}$ cannot compromise the past information, even if they have sent $Corrupt\left(i\right)$ (or $Corrupt\left(j\right)$) to the player i, where $i,j\in \{U,V\}$.

Theorem 1.

First, we assume that $ASE$ is an indistinguishable-CCA (Ind-CCA) secure asymmetric encryption/decryption scheme and equips two secure hash functions, $H_1$ and $H_2$, which we can be replaced with two random oracle (RO) functions, respectively. We also assume that our proposed patient electronic health record exchange scheme (PEHRES) that is forward secure (FS) and unforgeable (Unf) also satisfies the following situations. In other words, if our proposed scheme is secure, then

$$\begin{array}{c}\hfill Ad{v}_{PEHRES}^{FS,Unf,Ind-CCA}(\theta ,t)\le \frac{1}{2}(I^2{q}_h{q}_e{q}_s\left(Ad{v}_{ASE,\mathcal{D},C_{HCA}^{*}}^{Ind-CCA}(\theta ,t^{\prime })\right)+1)+\\ \hfill \frac{1}{2}(I^2{q}_h{q}_e\left(Ad{v}_{ASE,\mathcal{D},C_V^{*}}^{Ind-CCA}(\theta ,t^{\prime })\right)+1)+\\ \hfill \frac{1}{2}({\left(I{q}_h\right)}^{2}Ad{v}_{\mathcal{A},SE}^{Ind}(\theta ,t^{*})+1)+\left(I^3{q}_s\right)Ad{v}_{Sig,\mathcal{S},\mathcal{F}}^{Unf}(\theta ,t^{*})+\epsilon ,t\le t^{\prime }+t^{*},\end{array}$$

(4)

where t is the total execution time, $t^{\prime }$ is the maximum total experiment time including an adversary execution time, $t^{*}$ is the maximum total time to guess the real session key, I is an upper bound on the number of parties, with at most $q_e$ encryption queries at most $q_s$ decryption oracles, and $q_h$ is an upper bound on the number of $H_1$ and $H_2$ queries in the experiment, where ε is a negligible advantage.

5. Security Analysis

In this section, we provide security analysis and functional analysis of our proposed scheme.

5.1. Replay Attack Resistance

In this EHR migration phase, we adopt random values $r_U^{\prime \prime }$, $r_V^{*}$, and $r_W^{*}$ as our authentication challenge numbers. We assume an attacker can capture authentication messages among the protocol communication and may replay these captured messages to the server W to impersonate the patient U. First, the server V will check that this message was used before in some session before communicating with the server W. Hence, the server V will also check that one of these messages $r_U^{\prime \prime }$, $r_V^{*}$, and $r_W^{*}$ was used before. If one of them was used, then it would close this session and save the record as the replay attack from V.

5.2. Resist User Impersonation Attack

In this proposed scheme, the adversary cannot replay any authentication message without the user U’s biometric information $Bi{o}_U$, and it also cannot guess the random number $r_U^{\prime \prime }$ successfully to impersonate the server V. Additionally, the adversary does not have the non-negligible probability to forge the patient’s signature to the server V. In addition, the server V also checks the signature $S_U$ to authenticate the patient U’s identity in the migration registration phase. Thus, the adversary cannot have non-negligible probability to forge U’s signature $S_U$ under the RSA factoring problem. Therefore, our scheme can resist user impersonation attacks.

5.3. Provide Mutual Authentication

In the EHR migration phase, a patient U can delegate the server V to perform the EHR migration exchange with the system of the desired hospital W. Server V can perform the challenge response with the server of W, and they both communicate a session key for later usage after successful authentication. During the authentication rounds, V and W can check the freshness of random numbers ($r_U^{\prime \prime }$, $r_V^{*}$, and $r_W^{*}$). If one of them is to be replayed, V or W would find out and deny this session with the other party. Finally, it would close this phase and record that there was a replay attack in this EHR migration phase.

5.4. Provide Data Security

In the EHR migration phase, all random numbers are generated by these two parties and drop off when the authentication between them is successful. In addition, not only are $r_U^{\prime \prime }$, $r_V^{*}$, and $r_W^{*}$ verified by these two parties V and W, but also they can also be response messages to confirm their respective identities.Hence, the adversary cannot have a non-negligible probability to replace each of these messages to pass the authentication process. In the data recovery phase, $r_U^{\prime \prime }$ is used to encrypt the patient’s EHR, and the adversary does not have a non-negligible probability to obtain a patient’s EHR, under the assumption that the symmetric encryption/decryption function is indistinguishable for the adversary in a polynomial time bound.

5.5. Session Key Establishment

In the EHR migration phase, the server V and the server W can also communicate a common session key after they perform challenge-response authentication with each other successfully. Not only can this session key be used for later communication, but it can also provide for symmetric encryption/decryption usage. In the appendix, we provide a formal security proof of the session key.

5.6. Forward Secrecy Proof

In the EHR migration phase, a patient can delegate the server V to authenticate with the desired server of hospital W. They can then build the session key after successful authentication. In fact, they can use this session key to communicate with each other to transfer the patient U’s EHRs or update the patient U’s EHR. With this property, the system can reduce the communication bits and improve the efficiency of data transmission. In the appendix, we also provide a formal secrecy proof of the session key.

5.7. EHR Fair Exchange

In the EHR migration phase, if W does not receive the U’s EHR from the V or if U’s EHR is broken, then the patient U can perform the data recovery request to the $HCA$ and ask the $HCA$ for help to solve this situation by providing the above signatures and V’s receipt to $HCA$. If the above signatures are valid, $HCA$ performs the data recovery phase and forwards the encrypted patient’s EHR to the system of the hospital W. Finally, the server of hospital W can also obtain the patient U’s EHR under the help of $HCA$.

5.8. Offline Trusted Third Party

In the proposed scheme, we assume that there is a $HCA$ and that it generates the patient’s EHR migrating signature with a delegation document and performs data recovery. Here we can assume that the on-line device of the $HCA$ can generate the signature after verifying the request party’s signature in the migration registration phase. Only if there is a request coming in the data recovery phase would the $HCA$ be on-line and solve this situation after verifying the request party’s evidence, including the registration signatures and the related signatures. From the above setting, our trusted third party would not stay on-line all the time and just appears when it is needed. Additionally, only the $HCA$ knows the link information $(UI{D}_U,I{D}_U)$ of the patient U. Therefore, the patient can prevent their real identity from being disclosed during the EHR migration transaction.

From the above security analysis properties, we take [10] as a reference and make comparisons with schemes from [6,7,8,9,10]. In the following, we provide some security analysis definitions for security comparison (

Table 1. Security comparison.

Attributes						Ours
A1	Y	Y	Y	Y	Y	Y
A2	N	N	Y	Y	Y	Y
A3	Y	Y	Y	Y	Y	Y
A4	N	N	N	N	N	Y
A5	Y	Y	Y	Y	N	Y
A6	Y	N	N	N	N	Y
A7	N	N	N	N	N	Y
A8	N	N	N	N	N	Y

A1: Replay Attack Resistance; A2: Resist User Impersonation Attack; A3: Provide Mutual Authentication, A4: Provide Data Security; A5: Session Key Establishment, A6: Forward Secrecy Proof; A7: EHR Fair Exchange, A8: Offline Trusted Third Party.

).

5.9. Efficiency Comparisons

In this section, we evaluate our proposed scheme’s efficiency. First, we assume that our scheme’s parameter p is of 1024 bits for security consideration. We assume that H is the computation time of one hashing operation, $Exp$ is the computation time of one modular exponential operation in a 1024 bit module, M is the computation time of one modular multiplication in a 1024 bit module, $E{C}_M$ is the computation time of a number over an elliptic curve, and $E{C}_P$ is the computation time of a bilinear pairing operation of two elements over an elliptic curve in [13,14,15]. We also let $Sig$, $ASE$, $ADE$, $SE$, and $SD$ be the signature operation time, the asymmetric encryption time, the asymmetric decryption time, the symmetric encryption time, and the symmetric decryption time, respectively. We assume that our proposed scheme can be implemented on an elliptic curve over a 163-bit field and has the same security level of a 1024 bit public key crypto-system such as RSA or the Diffile-Hellman cryptosystem. We also assume that $Exp=8.24E{C}_M$ for the ARM CPU to the processor in 200 Mhz [15]. We also determine certain relations from the following: $Exp\approx 240M=600H\approx 3E{C}_P$, and $E{C}_A\approx 5M$ in [16,17,18,19,20,21,22].

Based on [23], a public key encryption/decryption operation time in an elliptic curve is approximately 1$E{C}_A$ and $1E{C}_M+1E{C}_A$, respectively. Therefore, our proposed scheme total computation time cost is about $9H+3Sig+14\oplus +2ASE+1ADE\approx 60.075M+14\oplus$. Due to the different properties of the above schemes, we omitted the efficiency comparisons and found some currently survey papers [11,24] that have the same functional properties as our proposed scheme.

In [11], the authors proposed a dynamic consent model of health data sharing using blockchain technology. They combine the consent representation models (DUO) and ADA-M [24] to let patients control their EHR sharing to match the request query with full access rights. Their method is designed for building an EHR platform but is not a practical mechanism for patients exchanging their EHRs with a formal security proof in a blockchain environment. In [12], the authors proposed an EHR with a patient-centric access right framework model by using blockchain technology. We think that this is a good idea for building health information exchange systematic modules with blockchain in the future, but they do not offer a practical solution for EHR migration currently, even in a blockchain environment. Our proposed scheme is established by the functional block such as the signature functions with other authentication functions. In future work, our proposed scheme could functionally add a smart contract function to generate a verifiable functional patient EHR block in blockchain network. Hence, our proposed scheme could be used in blockchain and non-blockchain environments.

In the efficiency evaluation of our scheme, we used a desktop with Ubuntu 20.04 with Intel(R) Core(TM) i7-8700 CPU @ 3.20 GHz CPU and 15 GB memory. The simulation experiment was carried out using GO language, and the standard “crypto/elliptic” library was used. We simulated every phase 20 times, shown in Figure 4, Figure 5 and Figure 6.

In the future, we will discuss the forged HCA problem [25] and other applications such as neural network environments for COVID-19 patients [26] exchanging their EHRs. We hope to have a good solution to the above problems.

6. Security Proof

In this section, we continue to demonstrate what an adversary is and its probability. We model the $Game$, our scheme simulation steps, and the related oracle responses.

An adversary (call it $\mathcal{S}$) can control all communication messages in this scheme. The adversary can obtain related information by sending oracles. A $Game$ is the simulation of our proposed scheme, which can equip all kinds of oracles, and oracles can reply back according to the adversary’s questions. There is also another adversary (call it $\mathcal{S}$) that controls the simulation and takes $\mathcal{A}$’s ability to break the hard problem defined in the security definition.

Let $Game$ be a “game”, the simulation of our scheme, where the adversary $\mathcal{A}$ can ask queries to the oracles, and the oracles can answer back to the adversary. The following are query types that an adversary can make in the game.

• Send query $Send(i,k,M)$(or $Send(j,k^{\prime },M)$): this query models an adversary that can send message M to the authentication party i(or j), where $i,j\in \{U,V\}$ in the k- (or $k^{\prime }$)-th session, where k and $k^{\prime }$ are two different session numbers in N.
• Reveal query $Reveal(i,k)$(or $Reveal(j,k)$): this query is used to model a situation that exposes a session key of ${\mathsf{\Pi }}_i^k\left(or{\mathsf{\Pi }}_j^{k^{\prime }}\right)$ to an adversary, where $i,j\in \{U,V\}$ and $k,k^{\prime }\in N$ in the k(or $k^{\prime }$)-the session.
• Encryption query: this query is used to model that an adversary can obtain a ciphertext $C^{\prime }$ on the input of a chosen message $M^{\prime }$.
• Decryption query: this query is used for modelling an adversary that can obtain a plain-text $M^{\prime }$ on the input of a cipher-text $C^{\prime }$.
• Corrupt query $Corrupt\left(i\right)$(or $Corrupt\left(j\right)$): this query is used to expose the private key of the player $p_i$(or $p_j$) to the adversary, where $i,j\in \{U,V\}$.
• Hash query: this query depends on what the input is; the simulator then returns the related output to the attacker.
• Test query $Test(i,k)$: this query is used to define the advantage of an adversary. When the adversary $\mathcal{A}$ has finished all of the above queries to the oracle, they can make this test query on an instance ${\mathsf{\Pi }}_i^k$(or ${\mathsf{\Pi }}_j^{k^{\prime }}$) to the simulator. At this time, the simulator will flip a coin b. If b is 1, then the real session key is $ss{k}_{i,j}^k$. Otherwise, it returns a random string chosen uniformly from ${\{0,1\}}^{*}$. The adversary is only allowed to ask for the “fresh” instance of a player in the above simulation.

Proof of Theorem 1.

First, we assume that there is an adversary $\mathcal{A}$ that attempts to attack our patient EHR exchange scheme ($PEHRES$) in the forward secure sense. We then let $dis$ be the event at which $\mathcal{A}$ can distinguish at least one ciphertext in $PEHRES$ with non-negligible probability. At the same time, we also let $forge$ be the event at which the adversary $\mathcal{D}$ can forge the signature of our $PES$ with non-negligible probability. We assume that

$$P{r}_{\mathcal{A}}[b=b^{\prime }]\le P{r}_{\mathcal{A}}[b=b^{\prime }\wedge \overline{dis}\wedge \overline{forge}]+P{r}_{\mathcal{A}}\left[dis\right]+P{r}_{\mathcal{A}}\left[forge\right],$$

where b and $b^{\prime }$ are coin flips chosen by the simulator and the attacker $\mathcal{A}$, respectively.

We also assume that

$$P{r}_{{\mathcal{F}}^{*}}\left[forge\right]\le P{r}_{{\mathcal{F}}^{*}}[{\mathcal{F}}^{*}\to S_U^{*}|Ver\left(S_U^{*}\right)=1]+P{r}_{{\mathcal{F}}^{*}}[{\mathcal{F}}^{*}\to S_{HCA}^{*}|Ver\left(S_{HCA}^{*}\right)=1],$$

where $S_U^{*}$ and $S_{HCA}^{*}$ are signatures forged by the attacker ${\mathcal{F}}^{*}$, respectively. We then use three lemmas to complete this security proof in the following.

Lemma 4.

We assume that there is no event such that the attacker $\mathcal{A}$ can distinguish the ciphertext $C^{*}$ with non-negligible probability

$$P{r}_{\mathcal{A}}\left[dis\right]\le \frac{1}{2}(I^2{q}_h{q}_e{q}_s\left(Ad{v}_{ASE,\mathcal{D},C_{HCA}^{*}}^{Ind-CCA}(\theta ,t^{\prime })\right)+1)+\frac{1}{2}(I^2{q}_h{q}_e\left(Ad{v}_{ASE,\mathcal{D},C_V^{*}}^{Ind-CCA}(\theta ,t^{\prime })\right)+1),$$

in the polynomial time bound $t^{\prime }$ under the above Ind-CCA security definition with $q_h$ hash queries, at most $q_e$ encryption queries, and at most $q_s$ decryption queries, respectively.

Proof of Lemma 4.

We assume that $Pr\left[dis\right]$ is a non-negligible probability in the simulation game. We can then construct an attacker $\mathcal{D}$ whose work is to distinguish the cipher-text under the Ind-CCA encryption/decryption scheme. There is also an attacker $\mathcal{F}$ whose goal is to break the encryption/decryption of our proposed scheme $SE$. Next, we construct $\mathcal{D}$ as the simulator that simulates the attacking environment in which $\mathcal{F}$ can mount its attack. First, $\mathcal{D}$ simulates an encryption oracle $S{E}_{p{k}_i}(·,\theta )$, where $i\in \{U,V\}$, and generates the $C^{\prime }$ to the attacker $\mathcal{F}$ on the plain-texts ($M^{\prime }$) chosen by the attacker $\mathcal{D}$ in the selected instance ${\mathsf{\Pi }}_{i^{*}}^k$, where the partner of ${\mathsf{\Pi }}_{i^{*}}^k$ is $p_{j^{*}}$. In addition, $\mathcal{D}$ also simulates the decryption oracle to answer the decryption query issued by the attacker $\mathcal{D}$. We consider the following steps. First, $\mathcal{D}$ prepares all hash functions, including $H_1$ and $H_2$, two hash functions with collision-resistance. It also generates the instances $i^{*},j^{*}⟵[1,\dots ,I-1]$ of each player i, where $i\in \{U,V\}$. It can make the above two hash queries $l^{*}$ times, where $l^{*}⟵[1,\dots ,q_h]$.

Hash query

In this hash query phase, the simulator also responds to all kinds of hash queries in each stage.

• In the migration registration phase, the simulator generates the corresponding hashed value to U and V. It prepares the $H_1\left(Bi{o}_U\right)$ for the patient U as the registration token. At the same time, the simulator chooses $r_U^{″}$ and makes the ciphertext $C_{HCA}=(r_U^{\prime \prime },Bi{o}_U,UI{D}_U,Cer{t}_U,I{D}_U,EH{R}_U\oplus r_U^{\prime \prime })$ for $\mathcal{F}$.
• Next, the simulator has to simulate the signature $S_U$ and $S_{HCA}$ from the signing oracle. It then forwards ($S_U$, $S_{HCA}$) to $\mathcal{F}$. The simulator then computes $Si{g}_V(S_{HCA},S_U,Agre{e}_{V->W})$ as the response receipt of the instance of player V.
• In the EHR migration phase, the simulator can simulate the hashed values $H_2(r_V^{*}+1)$ and $H_2((r_W^{*}+1)\oplus r_U^{\prime \prime })$ to $\mathcal{F}$, which forwards $r_V^{*}+1$, $(r_W^{*}+1)$, and $r_U^{″}$ as challenge random numbers.

Phase 1

• In the migration registration phase, the attacker $\mathcal{F}$ can issue the encryption query on the chosen message $M^{\prime }=(r_U^{\prime \prime },Bi{o}_U,UI{D}_U,Cer{t}_U,I{D}_U,EH{R}_U\oplus r_U^{\prime \prime })$. $\mathcal{D}$ can then forward this $M^{\prime }$ to the encryption oracle and pass the final result $C^{\prime }$ to the $\mathcal{F}$.
• The attacker $\mathcal{F}$ can issue the decryption query on the ciphertext $C^{\prime }$. $\mathcal{D}$ can then forward this $C^{\prime }$ to the decryption oracle and pass the final message $M^{\prime }=(r_U^{\prime \prime },Bi{o}_U,UI{D}_U,Cer{t}_U,I{D}_U,EH{R}_U\oplus r_U^{\prime \prime })$ from the oracle output to the $\mathcal{F}$.
• In the EHR migration phase, the attacker $\mathcal{F}$ can ask for the $M^{\prime \prime }=r_V^{*}$ encryption result $C_V^{″}$ and the decryption result of $M^{″}$. $\mathcal{D}$ can forward $C_V^{″}$ and $M^{″}$ to the attacker $\mathcal{F}$.

Challenge

• In this phase, $\mathcal{D}$ can generate the ciphertext $C_{HCA}^{*}$ by querying the asymmetric encryption oracle $AS{E}_{p{k}_T}(M_b^{*},\theta )$ with the coin flip b on the target message pair $(M_0^{*},M_1^{*})$ chosen by the attacker $\mathcal{F}$. If b=1, C is computed from $AS{E}_{p{k}_T}(M_1^{*},\theta )$, where $T\in \{U^{*},V^{*}\}$. Otherwise, it returns the ciphertext $C^{*}$ to $\mathcal{F}$, where $C_{HCA}^{*}⟵AS{E}_{p{k}_T}(M_0^{*},\theta )$. The only restriction is that $\mathcal{F}$ cannot ask for the decryption query on the ciphertext $C_{HCA}^{*}$. On the other hand, we also consider that the ciphertext $C_V^{*}$ is the same situation. We also set up the target message pair $(M_0^{**},M_1^{**})$ chosen by the attacker $\mathcal{F}$. If $b^{\prime }$=1, C is computed from $AS{E}_{p{k}_T}(M_1^{**},\theta )$, where $T\in \left\{W^{*}\right\}$. Otherwise, it returns the ciphertext $C_V^{*}$ to $\mathcal{F}$, where $C_V^{*}⟵AS{E}_{p{k}_T}(M_0^{**},\theta )$.
• We assume that this event $dis$ happens with respect to the instance ${\mathsf{\Pi }}_{i^{*}}^{l^{*}}$ of the player i, where its partner player is $p_{j^{*}}$. At this time, $\mathcal{F}$ finally outputs its own guessing bit $b^{\prime }$. Otherwise, the system stops this authentication stage and aborts this simulation.

Finally, $\mathcal{F}$ has a set with instances of players $i^{*}$ and $j^{*}$ with $q_h$ total hash queries , at most $q_e$ encryption queries, and $q_s$ decryption queries. At this time, $\mathcal{D}$ does not fail in the simulation environment with $\mathcal{F}$’s correct guessing, where $b=b^{\prime }$ has non-negligible probability. The following equation will then hold:

$$\begin{array}{c}\hfill Ad{v}_{ASE,\mathcal{D},C_{HCA}^{*}}^{Ind-CCA}(\theta ,t^{\prime })\le \\ \hfill \frac{1}{I^2{q}_h{q}_e{q}_s}(Pr[Gam{e}_{ASE,\mathcal{F}}^{Ind-CCA-1}\left(\theta \right)=1]-Pr[Gam{e}_{ASE,\mathcal{F}}^{Ind-CCA-0}\left(\theta \right)=1])=\\ \hfill \frac{1}{I^2{q}_h{q}_e{q}_s}(Pr[Gam{e}_{ASE,\mathcal{F}}^{Ind-CCA-1}\left(\theta \right)=1]-(1-Pr[Gam{e}_{ASE,\mathcal{F}}^{Ind-CCA-1}\left(\theta \right)=1]))=\\ \hfill \frac{1}{I^2{q}_h{q}_e{q}_s}(2\left(Pr[Gam{e}_{ASE,\mathcal{F}}^{Ind-CCA-1}\left(\theta \right)=1]\right)-1).\end{array}$$

(5)

In the ciphertext $C_V^{*}$ simulation game, we have the same simulation as above. Therefore, we omitted the simulation, but we also conclude that

$$\begin{array}{c}\hfill Ad{v}_{ASE,\mathcal{D},C_V^{*}}^{Ind-CCA}(\theta ,t^{\prime })\le \frac{1}{I^2{q}_h{q}_e}(2\left(Pr[Gam{e}_{ASE,\mathcal{F}}^{Ind-CCA-1}\left(\theta \right)=1]\right)-1)\end{array}$$

(6)

We then can summarize the total probability as follows:

$$\begin{array}{c}\hfill P{r}_{\mathcal{A}}\left[dis\right]\le Pr[Gam{e}_{ASE,\mathcal{F}}^{Ind-CCA-1}\left(\theta \right)=1]\le \\ \hfill \frac{1}{2}(I^2{q}_h{q}_e{q}_s\left(Ad{v}_{ASE,\mathcal{D},C_{HCA}^{*}}^{Ind-CCA}(\theta ,t^{\prime })\right)+1)+\frac{1}{2}(I^2{q}_h{q}_e\left(Ad{v}_{ASE,\mathcal{D},C_V^{*}}^{Ind-CCA}(\theta ,t^{\prime })\right)+1).\end{array}$$

(7)

□

Lemma 5.

Before we prove this lemma, we assume that there is no attacker $\mathcal{A}$ that can guess the real session key in the event that the ciphertext $C^{*}$ generated by the symmetric encryption (SE) functions cannot be distinguished by $\mathcal{A}$ correctly with non-negligible probability. We then have

$$P{r}_{\mathcal{A}}[b=b^{\prime }\wedge \overline{dis}\wedge \overline{forge}]\le \frac{1}{2}({\left(I{q}_h\right)}^{2}Ad{v}_{\mathcal{A},SE}^{Ind}(\theta ,t^{*})+1),$$

in the polynomial time $t^{*}$ under the random oracle (RO) assumption with total $q_h$ hash queries.

Proof of Lemma 5.

In this proof, we construct another simulator $\mathcal{C}$ that also simulates the attacking environment for $\mathcal{A}$ mounting its attack. Finally, if $\mathcal{A}$ can guess the real session key successfully with the non-negligible property, then we can use $\mathcal{A}$ to break the random oracle assumption.

• First, we assume that $\mathcal{C}$ is given the system parameters $(G,g,q,H_1,H_2,t_{i^{*}},t_{j^{*}})$. It starts to choose public key/secret key pairs for all parties except for $p_{i^{*}}$ and $p_{j^{*}}$. Next, $\mathcal{C}$ selects other protocol parameters such as ($i^{*},j^{*})⟵[1,...,I-1]$ and $t_1,t_2⟵[1,...,q_h]$. At this time, we also let the target identities $i^{*}$ and $j^{*}$ be the instances of the patient U and the system V, respectively.
• After the above environment is set up completely, $\mathcal{C}$ starts to simulate the following oracle queries and related hash functions.
• First, $\mathcal{C}$ sets parameters $(i,j,r_i,r_j,A{E}_{p{k}_T}(M_b,\theta ))$, where $r_i,r_j$ are two random numbers, and $H_1$,$H_2$ are these two collision-resistance hash functions. In addition, $\mathcal{C}$ adopts $\theta$ as the security parameter. First, $\mathcal{C}$ prepares two nonce challenge numbers $r_i$ and $r_j$ in the $t_1$-th and $t_2$-th session, respectively.
• During this simulation, for each query issued from $\mathcal{A}$, $\mathcal{C}$ answers it as follows:
• It takes $(i,j,H_1,H_2,{\omega }_1,{\omega }_2,r_i,r_j)$ as its input and responds to each $Send$ query in the instance ${\mathsf{\Pi }}_i^k$ in the k-th session on the message M, where ${\omega }_1$ and ${\omega }_2$ are two pseudo-random functions with the same length of the hash oracles $H_1$ and $H_2$, respectively.

□

Hash Query

In this hash query phase, the simulator can answer all kinds of harsh queries in each stage, as follows:

• In the migration registration phase, the simulator also computes the initial biometric information value ($r_{B_U}\oplus H_1\left(Bi{o}_U\right)$) for the patient U and keeps them in the oracle simulation database. If the $\mathcal{A}$ makes the hash query on ($r_V+1\left|\right|r_{HCA}$) and $r_{HCA}+1$, $\mathcal{C}$ also forwards them to the hash oracle and returns the response hashed value to $\mathcal{A}$.
• In the EHR migration phase, $\mathcal{A}$ asks for the $r_V^{*}+1$, $(r_W^{*}+1)\oplus r_U^{\prime \prime }$, and $(r_W^{*}+1)\left|\right|(r_V^{*}+1)$ hash values of the $H_2$ function, and $\mathcal{C}$ also forwards them to the hash oracle and lets the hash oracle generate the corresponding hash values to $\mathcal{A}$.
• If $\mathcal{C}$ receives the $Corrupt\left(i\right)$ query, then it returns the private key to $\mathcal{A}$. If $\mathcal{C}$ receives the $Reveal\left(i\right)$ query, it checks if $i\ne i^{*}$ or $j\ne j^{*}$, then $\mathcal{D}$ computes the session key $ss{k}_{i,j}=H_1\left({\omega }_1(r_W^{*}+1)\right)\left|\right|{\omega }_2\left((r_V^{*}+1)\right))$, where $r_W^{*}+1$ and $r_V^{*}+1$ are chosen from ${\omega }_1$ and ${\omega }_2$ functions, respectively. On the other hand, if $i=i^{*}$, $j=j^{*}$, and $t_1=t_2=l$, then $\mathcal{C}$ computes $H_1((r_W^{*}+1)\left|\right|(r_V^{*}+1))$ as the session key $ss{k}_{i,j}$ and delays this key in the response in the $Test$ query.
• If the adversary $\mathcal{A}$ has finished the above queries, it can make the $Test$ query to $\mathcal{C}$. At this time, $\mathcal{C}$ will check the instance session and player to see if $i=i^{*}$ and $j=j^{*}$, and $\mathcal{C}$ then tosses a coin b to answer the session key. If b=0, then it computes $ss{k}_{i,j}=H_1((r_W^{*}+1)\left|\right|(r_V^{*}+1))$. Otherwise, it computes $ss{k}_{i,j}⟵{\{0,1\}}^{*}$ from the random pseudo-random function.

Finally, if $\mathcal{C}$ answers the $Test$ query for ${\mathsf{\Pi }}_{i^{*}}^{t_1}$ and ${\mathsf{\Pi }}_{j^{*}}^{t_2}$ by using $(Z_n^{*},H_1,H_2,{\omega }_1,{\omega }_2)$, and $\mathcal{A}$ does not fail in guessing $b^{\prime }$, then $\mathcal{A}$ answers the session key depending on its coin flip $b^{\prime }$. We can have -4.6cm0cm

$$\begin{array}{cc}\hfill Ad{v}_{\mathcal{C},\mathcal{A},SE}^{H_1,H_2,{\omega }_1,{\omega }_2}(\theta ,t)=& \\ \hfill Pr[\mathcal{C}(Z_n^{*},H_1,H_2,{\omega }_1,{\omega }_2)=1|ss{k}_{i,j}=H_1((r_W^{*}+1)\left|\right|(r_V^{*}+1)\left)\right)\left)\right]-& \\ \hfill Pr[\mathcal{C}(Z_n^{*},H_1,H_2,{\omega }_1,{\omega }_2)=1|ss{k}_{i,j}⟵{\{0,1\}}^{*},t\in Z_q^{*}]\le & \\ \hfill \frac{1}{{\left(I{q}_h\right)}^2}(Pr[\mathcal{A}(·)=1|ss{k}_{i^{*},j^{*}}\mathrm{is}\mathrm{real}\mathrm{in}Test\mathrm{query}]-Pr[\mathcal{A}(·)=1|ss{k}_{i^{*},j^{*}}\mathrm{is}\mathrm{random}Test\mathrm{query}])\le & \\ \hfill \frac{1}{{\left(I{q}_h\right)}^2}(2P{r}_{\mathcal{A}}[b=b^{\prime }\wedge \overline{dis}\wedge \overline{forge}]-1).\end{array}$$

(8)

Finally, we could conclude that

$$P{r}_{\mathcal{A}}[b=b^{\prime }\wedge \overline{dis}\wedge \overline{forge}]\le \frac{1}{2}({\left(I{q}_h\right)}^{2}Ad{v}_{\mathcal{C},\mathcal{A},SE}^{H_1,H_2,{\omega }_1,{\omega }_2}(\theta ,t)+1).$$

(9)

Lemma 6.

Before we prove Lemma 1, we assume that there is no event such that the attacker ${\mathcal{F}}^{*}$ can forge the signature $S_U$ of patient U with non-negligible probability

$$P{r}_{\mathcal{F}}\left[forge\right]\le \left(I^3{q}_s\right(Ad{v}_{Sig,\mathcal{S},\mathcal{F}}^{Unf}(\theta ,t^{*}),$$

in the polynomial time bound $t^{*}$ under the above Ind-CCA security definition with $q_h$ hash queries, at most $q_e$ encryption queries, and at most $q_s$ decryption queries, respectively.

Proof of Lemma 6.

In this lemma proof, we start to prove our above Lemma 1 (*lm1). To start the proof of Lemma 1 (*lm1), we defined the Game as the simulation game that runs as the proposed protocol controlled by the simulator $\mathcal{S}$. We define Game as follows.

$$\begin{array}{c}{\mathbf{Game}}_{\mathcal{A},Sig}^{Unf}(\theta ,t)\hfill \\ \mathbf{Phase}\mathbf{1}.\hfill \\ \mathcal{F}⟵{\left\{M\right\}}^l\hfill \\ S_i⟵{\mathcal{F}}^{Sig(s{k}_i,M_i),R{O}_1,R{O}_2,H_1,H_2}(\theta ,t)\hfill \\ \mathbf{Challenge}\mathbf{Phase}.\hfill \\ i\in \{U,HCA\},M^{*}⟵\mathcal{F}\left(M\right),\hfill \\ \mathrm{Loop}j=1\mathrm{to}l\hfill \\ S_{i,j}^{\prime }⟵{\mathcal{F}}^{Sig\left(s{k}_i\right)}(\theta ,t)\left(M^{*}\right)\hfill \\ \mathrm{If}(\mathrm{Ver}\left(S_{i,j+1}^{\prime }\right)==1\mathrm{and}{S}_{i,j+1}^{\prime }\notin S_{i,j}).\hfill \\ \mathrm{Break}\hfill \\ \mathrm{Return}{S}_{i,j+1}^{\prime }.\hfill \\ \mathrm{else}\mathrm{if}(j<=l)\hfill \\ \mathrm{goto}\mathrm{Loop}\hfill \end{array}$$

We first define the simulator $\mathcal{S}$ as the simulator that is given in the RSA factoring problem, and we assume there is an attacker $\mathcal{F}$ whose goal is to forge a valid signature on the $Sig$ function block.

The simulator $\mathcal{S}$ first chooses the security parameter l with the message space $M^l$. The $\mathcal{S}$ also selects two collision-resistance hash functions that map from $Z_n^{*}⟶\{0,1\}$ and two hash oracles $R{O}_1$ and $R{O}_2$, respectively. After setting up the system parameter, the $\mathcal{S}$ simulates each phase in the proposed EHR scheme. In the migration registration phase, the attacker $\mathcal{F}$ can impersonate the patient U to ask for U’s signature request $S_U$ on the desired message. When $\mathcal{S}$ has received this request, it takes the message as input and outputs the signature $S_U$ with the help of the above secure digital signature function $Sig$. It then returns this $S_U$ back to the $\mathcal{F}$. The $\mathcal{F}$ can also continue to ask the hospital certification center $HCA$’s signature on the received signature $S_{HCA}$ of patient P. It also receives the message tuple $(S_U,Date,I{D}_U)$ and outputs the signature $S_{HCA}$ back to $\mathcal{F}$. In addition, it is the same situation when $\mathcal{F}$ asks the signature of V. The $\mathcal{S}$ also returns $S_V$ back to $\mathcal{F}$.

In these phases, the $\mathcal{F}$ will make the signature request in the above situation. The $\mathcal{S}$ starts the Challenge phase and forwards the message $M_i$, where $i\in \{U,V,HCA\}$. The $\mathcal{F}$ can forge l+1 signatures $S_{i,j}^{\prime }$, where $S_{i,j+1}^{\prime }\notin S_{i,j}⟵Sig(s{k}_i,M^{*})$, where $i\in \{U,V,HCA\}$ and $j=1\sim l$ after l signature queries. Finally, this forged signature also passes the verification $Ver\left(S_{i,j+1}^{\prime }\right)$ successfully. We then can use $\mathcal{F}$ ’s ability to find a solution to the RSA factoring problem. Thus, we have

$$\begin{array}{cc}\hfill Ad{v}_{Sig,\mathcal{S},\mathcal{F}}^{Unf}(\theta ,t^{*})\ge & \left|Pr\right[S_{i,j+1}^{\prime }⟵{\mathcal{F}}_{Sig}^{Unf}\left(M^{*}\right),Ver(S_{i,j+1}^{\prime }=1)\left]\right|\hfill \\ \hfill =& \frac{1}{I^3{q}_s}\left(Pr[S_{i,j+1}^{\prime }⟵{\mathcal{F}}_{Sig}^{Unf}\left(M^{*}\right),Ver(S_{i,j+1}^{\prime }=1)]\right).\hfill \end{array}$$

(10)

Finally, we could conclude that

$$P{r}_{\mathcal{F}}\left[forge\right]\le \left(I^3{q}_s\right)Ad{v}_{Sig,\mathcal{S},\mathcal{F}}^{Unf}(\theta ,t^{*}).$$

□

After summarizing the above three lemmas, we can conclude that $\frac{1}{2}(I^2{q}_h{q}_e{q}_s\left(Ad{v}_{SE,\mathcal{D},C_{HCA}^{*}}^{Ind-CCA}(\theta ,t^{\prime })\right)+1)+\frac{1}{2}(I^2{q}_h{q}_e\left(Ad{v}_{SE,\mathcal{D},C_V^{*}}^{Ind-CCA}(\theta ,t^{\prime })\right)+1)+$$\frac{1}{2}({\left(I{q}_h\right)}^{2}Ad{v}_{\mathcal{A},SE}^{Ind}(\theta ,t^{*})+1)+\left(I^3{q}_s\right)Ad{v}_{Sig,\mathcal{S},\mathcal{F}}^{Unf}(\theta ,t^{*})$.

7. Conclusions

We propose a practical and provable patient EHR fair exchange scheme with key agreement for e-health information systems. Not only does our scheme offer a solution for the seven problems described in Section 2, when a patient attempts to migrate their personal information data to another hospital, but they can also maintain their anonymity during the data migration transaction. In addition, Table 1 shows a security and functional comparison with other related papers. It is obvious that our proposed scheme guarantees convenience, rapidity, and integrity.

Our mechanism provides secure data storage and the secure transfer of authorized information to designated locations. What information can be authorized, for example, whether COVID-19 patient privacy concerning patients’ names, identities, and genetic sequences can be transmitted to different hospitals, is beyond this study’s scope. This study guarantees secure data transfer and storage. Our scheme also provides a formal security proof in the random oracle model under chosen-ciphertext security. Our approach focuses on the security and privacy protection of patient EHRs rather than on the design of electronic health systems. It not only serves as a high-level functional module for integrity but also provides an efficient and contactless data transfer method that allows for medical data aggregation and protects patient anonymity, especially relevant in the context of the global COVID-19 pandemic. In the future, we will extend our scheme to be applicable for COVID-19 patient EHR exchange in a neural network environment.