A secure electronic medical record authorization system for smart device application in cloud computing environments

As cloud computing technology matures, along with an increased application of distributed networks, increasingly larger amounts of data are being stored in the cloud, and are thus available for pervasive application. At the same time, current independent medical record systems tend to be inefficient, and most previous studies in this field fail to meet the security requirements of anonymity and unlinkability. Some proposed schemes are even vulnerable to malicious impersonation attacks. The scheme proposed in this study, therefore, combines public and private clouds in order to more efficiently and securely preserve and manage electronic medical records (EMR). In this paper, a new secure EMR authorization system is proposed, which uses elliptic curve encryption and public-key encryption, providing a health care system with both public and private cloud environments with a message authentication mechanism, allowing the secure sharing of medical resources. The analysis shows that the proposed scheme prevents known attacks, such as replay attacks, man-in-the-middle attacks and impersonation attacks, and provides user anonymity, unlinkability, integrity, non-repudiation, forward and backward security.


Security requirements
In this paper, we assume the following assumptions based on the threat model mentioned in [33][34][35][36]. Therefore, the following list is the security requirements for a secure electronic medical record authorization system for smart device applications in cloud computing environments.

Mutual authentication
The message receiver should authenticate the legality of the message sender during the information transmission process. Therefore, in a secure electronic medical record authorization system for smart device applications in cloud computing environments, each party should authenticate the legality of the other party. If each other's legality of the two parties is confirmed, then it achieves mutual authentication.

User anonymity and unlinkability
Malicious attacks may also attempt to determine a person's physical location by tracing their personal mobile reader. Thus, a secure electronic medical record authorization system for smart device applications in cloud computing environments must prevent such positional tracking.

Integrity
When the message transferred through an insecure network environment, it is susceptible to the malicious attack that the attacker modifies the original message. Thus, the message received by the receiver may not the original message sent from the sender. It ensures the integrity of the transmitted data and also protects against tampering in transmission.

Non-repudiation
The message receiver must be able to verify the legality of the message sender during the information transmission process. Once the receiver confirms that the message was sent from the sender, the sender can't deny the message that he/she had sent. The sender uses his/her private key to sign the message, and the receiver can verify the digital signature from the sender.

Forward and backward security
The session key is established between the message sender and the message receiver. If it is compromised by an attacker at any point, he/she may use the session key for future communications, or use it to obtain previous messages.

Confidentiality
If the data is intercepted by a malicious attacker during transmission, the unencrypted data content will be exposed, which violates the principle of confidentiality (1) tP = P + P + · · · + P, t times.
1. Patient (P): The patient takes a smart device when they visit a doctor. They authenticate their identity with the smart device by entering their biometric password. 2. Doctor (D): The doctor verifies the EMR of the patient and the legality of the hospital's private cloud. In the EMR search phase, the doctor collects messages from both sides and then makes a professional diagnosis. 3. Hospital's private cloud (HPC): The hospital's private cloud is the cloud in which the patient's EMR is stored. It authenticates the legality of the doctor and then provides them with the correct EMR. 4. Public cloud (PC): A public cloud plays the role of generating secret keys. Every party gets a secret parameter from the public cloud during the registration phase. It stores the index of the patient's medical data during the EMR search phase. By checking the secret key given by the public cloud, the doctor can authenticate their patients. The public cloud and the private cloud form a medical union cloud. The medical union cloud achieves EMR sharing by authenticating each other.
The following is a description of the four steps process of a patient visiting a doctor: Step 1: All parties are registered to the public cloud. The public cloud calculates secret keys by n elliptic curve. The cloud then issues the secret keys to parties. The i-th Hospital's Private Cloud (HPC) The j-th Hospital's Private Cloud (HPC) Fig. 1 The architecture of the proposed distributed EMR storage and sharing scheme Step 2: The patient visits the doctor. The doctor authenticates the patient, and the patient sends their biomedical signal to the doctor.
Step 3: The doctor receives the index of the patient from the public cloud and then obtains the EMR from the hospital's private cloud.
Step 4: The doctor makes a diagnosis according to the EMR and the patient's current condition. Finally, the doctor sends the diagnosis messages to the public cloud.

Notation
The notations used in this paper are shown in Table 1.

Registration phase
All parties register in the cloud to get the secret key. The registration phase is divided into three parts which are the patient, the hospital's private cloud, and the doctor register with the public cloud.

The patient registers with the public cloud
This process consists of three steps, as shown in Fig. 2a.
Step 1: The patient selects an identity ID P and a biometric password B P . They then send both to the public cloud via a secure channel.
Step 2: When the public cloud receives the message, it selects a random number r 1 , and uses it to multiply by the generator, the elliptic group, P to compute

Insecure channel
The public cloud then sends R P1 and S P to the patient via a secure channel.
Step 3: Upon receiving the message from the public cloud, the patient verifies by using the Eq. 4 as follows: If it holds, then the patient stores (R P1 , S P ).

The hospital's private cloud registers with the public cloud
This process consists of three steps, as illustrated in Fig. 2b.
Step 1: The hospital's private cloud selects an identity ID HPC , and then sends its identity ID HPC to the public cloud via a secure channel.
Step 2: When the public cloud receives the message, it selects a random number r 2 and uses it with the generator for the elliptic group P to compute R HPC1 by using the Eq. 5. The public cloud computes S HPC by using the Eq. 6. R HPC1 and S HPC as follows: The public cloud sends R HPC1 and S HPC to the hospital's private cloud via a secure channel.
Step 3: Upon receiving the message, the hospital's private cloud verifies by using the     Eq. 7 as follows: If it holds, then the hospital's private cloud stores (R HPC1 , S HPC ).

The doctor registers with the public cloud
This process also consists of three steps, as shown in Fig. 3.
Step 1: The doctor selects an identity ID D and their doctor's certificate Cert D and s both to the public cloud via a secure channel.
Step 2: When the public cloud receives the messages, it verifies whether Cert D is legal. If Cert D is illegal, the public cloud will terminate the registration phase.
If it is legal, it selects a random number r 3 and uses it multiply by the generator for the elliptic group P to compute R D1 by using the Eq. 8, and to then compute S D by using the Eq. 9 as follows: The public cloud sends R D1 and S D to the doctor via a secure channel.
Upon receiving the message from the public cloud, the doctor verifies by using the Eq. 10 as follows: If it holds, then the doctor stores (R D1 , S D ).

Patient visiting doctor (consultation) phase
In this phase, the patient goes to the doctor for a medical consultation. They bring their smart device with them in order to first authenticate the doctor. This section describes how the patient logs into the medical system, and how they achieve authentication with the doctor. This phase consists of four steps, as shown in    The patient inputs their biometric password B P and selects a random number r 5 , and uses r 5 and P to compute R P2 by using the Eq. 11 as follows: He/She then uses the doctor's public key PUK D to encrypt (ID P ||B P ||R P1 ||R P2 ||T P1 ) into C P1 by using the Eq. 12 as follows.
The patient then uses their private key PRK P to generate their signature Sig P1 by using the Eq. 13 as follows: Finally, the patient sends C P1 , Sig P1 , T P1 to the doctor, where T P1 is the timestamp.

Fig. 4 Patient visiting doctor phase
Step 1: Upon receiving C P1 , Sig P1 , T P1 , the doctor checks if T ′ P1 − T P1 ≤ T . If T is not valid, the doctor will terminate the communication. The doctor then decrypts C P1 and verifies Sig P1 by using the Eqs. 14 and 15 as follows: He/She then uses the random number r 6 with the generator for the elliptic group P to compute R D2 , and calculate a session key by using the Eqs. 16 and 17 as follows: The doctor uses patient's public key PUK P to encrypt (ID D ||Cert D ||R D1 ||R D2 ||SEK 1 ||T D1 ) into C D1 by using the Eq. 18 as follows: then uses their private key PRK D to generate their signature Sig D1 by using the Eq. 19 as follows: Finally, the doctor sends C D1 , Sig D1 , T D1 to the patient. Where T D1 is the timestamp.
Step 2: Upon receiving C D1 , Sig D1 , T D1 , the patient checks if T ′ D1 − T D1 ≤ T . If T is not valid, the communication is terminated. The patient decrypts C D1 by using the Eq. 20 as follows: and verifies if Cert D is legal or not. And then the patient verifies Sig D1 by using the Eq. 21 as follows: The patient then calculates a session key and verifies it by using the Eq. 22 as follows: and uses the session key SEK 1 to encrypt (M SD , ID P , T P2 ) into C P2 by using the Eq. 23 as follows: Finally, the patient sends C P2 and T P2 to the doctor.
Step 3: Upon receiving (C P2 , T P2 ) , the doctor checks if the timestamp T ′ P2 − T P2 ≤ T , then decrypts C P2 via session key SEK 1 by using the Eq. 24 as follows:

EMR search phase
The purpose of this phase is to search the EMR of the patient for information relevant to the current diagnosis process. The doctor contacts the hospital's private cloud to obtain the EMR of the patient, and thus needs to be authenticated with the private cloud. This phase consists of seven steps, as shown in Fig. 5.
Step 1: The doctor uses the public key of the public cloud PUK PC to encrypt (ID P ||T D2 ||ID D ||Cert D ||ID DE ) into C D2 by using the Eq. 25 as follows: He/She then uses their private key to generate their signature Sig D2 by using the Eq. 26 as follows: Finally, the doctor sends C D2 , Sig D2 , T D2 to the public cloud.
Upon receiving C D2 , Sig D2 , T D2 , the public cloud checks if T ′ D2 − T D2 ≤ T , then the public cloud decrypts C D2 and verifies whether Cert D is legal by using the Eq. 27 : The public cloud also uses the doctor's public key to verify the signature Sig D2 by using the Eq. 28 as follows: It also verifies whether Cert D is legal. Then the public cloud searches the patient's index record in its database according to ID P and ID DE . After this, it uses the doctor's public key PUK D to encrypt (ID HPC ||ID DE ||T C ) into C C by using the Eq. 29 as follows, where ID DE is the hospital department's identity.
The public cloud then uses its private key PRK C to generate the public cloud signature Sig C by using the Eq. 30 as follows: After this, the public cloud stores (h(ID P ||ID DE ), (ID CHPC ||ID D ) ⊕ h(s)).
Finally, the public cloud sends (C C , Sig C , T C ) to the doctor.
Step 2: Upon receiving (C C , Sig C , T C ) , the doctor checks if T ′ C − T C ≤ T . The doctor then decrypts C C and verifies Sig C by using the Eqs. 31 and 32 as follows: Then the doctor uses the random number r 7 with the generator for the elliptic group P to compute R D3 by using the Eq. 33. They then use the public key of the hospital's private cloud PUK HPC to encrypt (Cert D ||T D3 ||ID D ||R D3 ||R D1 ) into C D3 by using the Eq. 34 as follows: The doctor then uses their private key to generate their signature Sig D3 by using the Eq. 35 as follows: Finally, the doctor sends (C D3 , Sig D3 , T D3 ) to the hospital's private cloud.
Step 3: It then decrypts C D3 by using the Eq. 36 as follows: and verifies whether Cert D is legal. It then verifies Sig D3 by using the Eq. 37 as follows: The private cloud then uses the random number r 8 with the generator for the elliptic group P to compute R HPC2 , and calculates a session key by using the Eqs. 38 and 39 as follows: It then uses the doctor's public key PUK D to encrypt (ID HPC ||SEK 2 ||T HPC1 ||R HPC2 ) into C HPC1 by using the Eq. 40 as follows: It uses the private cloud's own private key to generate its signature Sig HPC1 by using the Eq. 41 as follows: Finally, the private cloud sends (C HPC1 , Sig HPC1 , T HPC1 ) to the doctor.

Eqs. 42 and 43 as follows:
He/She verifies the session key by using the Eq. 44 as follows: and then use the session key SEK 2 to encrypt (ID P ||ID D ||T D4 ||Cert D ) into C D4 by using the Eq. 45 as follows: Finally, the doctor sends (C D4 , T D4 ) to the private cloud.
Step 5: Upon receiving C D4 , the private cloud checks the timestamps to determine if T ′ D4 − T D4 ≤ T , and then decrypts C D4 by using the Eq. 46 as follows: It verifies whether Cert D is legal, and then uses the session key SEK 2 to encrypt (M EMR ||T HPC2 ) into C HPC2 by using the Eq. 47 as follows: Finally, the hospital's private cloud sends (C HPC2 , T HPC2 ) to the doctor.
Step 6: When the doctor receives C HPC2 , they check the timestamp to determine if T ′ HPC2 − T HPC2 ≤ T , and then decrypt C HPC2 by using the Eq. 48 as follows:

Diagnosis phase
Once the doctor receives the patient's EMR and the sensing message M SD from the patient's smart device, the doctor uses the patient's EMR from the hospital's private cloud and the M SD to make a professional medical diagnosis. After this, they inform the patient of the diagnosis result. Figure 6 is the diagnosis phase of the proposed scheme.  = h((S D R HPC2 + r 7 (R HPC1 + h(ID HPC ||R HPC1 )PK ))||r 7 R HPC2 ), (48) (M EMR ||T HPC2 ) = D SEK 2 (C HPC2 ). First, the doctor uses the session key SEK 1 to encrypt (M DINF ||Cert D ||T D5 ) into C D5 by using the Eq. 49 as follows: Then the doctor sends (C D5 , T D5 ) to the patient.
Step 1: When the patient receives (C D5 , T D5 ) , the patient checks the timestamps to determine if T ′ D5 − T D5 ≤ T , then decrypts C D5 by using the Eq. 50 as follows: The patient then verifies that Cert D is legal.

Security analysis
This section analyzes the security issues of mutual authentication, anonymity, unlinkability, data integrity, data non-repudiation, and forward and backward security in the proposed scheme. It also analyzes the proposed scheme's security against replay attacks, man-in-the-middle attacks, and impersonation attacks.

Mutual authentication
There are four parties in the proposed scheme, namely the patient, the hospital's private cloud, the public cloud, and the doctor. This paper uses BAN logic [38] to prove that the proposed scheme achieves mutual authentication.

Goals
The following goals must be derived step by step so that all parties are able to authenticate each other. Goals are listed as G1 to G16 as follows:

Messages delivered between parties
The messages are numbered for the purposes of proving the proposed scheme, as follows:

Assumptions
The following assumptions are made to help achieve the goals:

The doctor authenticates the patient
The doctor's authentication of the patient can be proved by the assumptions and BAN logic, as follows: According to Statement 6 and Statement 8, we prove that the doctor can surely authenticate the patient by using the Eq. 15 as follows:

The doctor authenticates the hospital's private cloud
The doctor's authentication of the private cloud can be shown by the assumptions and BAN logic as follows: By M4 and the seeing rule, the following Statement 25 can be derived: By A7, A8 and the freshness rule, the following Statement 26 can be derived: By Statement 25, A12, A19, A20 and the message meaning rule, the following Statement 27 can be derived: By Statements 26 and 27, and the verification rule, the following Statement 28 can be derived: By Statement 28 and the belief rule, the following Statement 29 can be derived: By Statement 29, A24 and the jurisdiction rule, the following Statement 30 can be derived: By Statement 30 and the belief rule, the following Statement 31 can be derived: By Statement 31, A28 and the belief rule, the following Statement 32 can be derived: According to Statements 30 and 32, the doctor's authentication of the patient can be proved by using the Eq. 43 as follows:

User anonymity and unlinkability
During the patient visiting doctor (consultation) phase, the EMR search phase, and the diagnosis phase, information is transmitted via a public channel, and it is crucial that a patient's identity is secured against malicious attack. The proposed scheme encrypts these messages using public key operations by using the following Eqs. 12,18,25,29,34 and 40 as follows: and encrypts the transmitted messages by session keys by using the following Eqs. 23 and 45 as follows: Because the messages are encrypted by public keys or session keys, attackers cannot obtain a patient's identity by intercepting the messages transmitted via a public channel. In addition, all messages have timestamps that change every session, thus encrypted messages with different timestamps can be identified, ensuring that malicious attackers cannot trace users. The proposed scheme, therefore, offers user anonymity and unlinkability.

The patient visiting doctor (consultation) phase
The patient's signature Sig P1 can be verified by its public key by using the following Eqs. 13 and 15 as follows: Thus, the doctor can ensure the integrity of the messages. Meanwhile, the doctor's signature Sig D1 can be verified by its public key by using the following Eqs. 19 and 21 as follows:

Doctor
Hospital's private cloud Thus, the patient can ensure the integrity of the messages.

The EMR search phase
The doctor's signature Sig D2 can be verified by its public key by using the following Eqs. 26 and 28 as follows: Thus, the public cloud can ensure the integrity of the messages. At the same time, public cloud's signature Sig C can be verified by its public key by using the following Eqs. 30 and 32 as follows: Therefore, the doctor can ensure the integrity of the messages, while the doctor's signature Sig D3 can be verified by its public key by using the following Eqs. 35 and 37 as follows: Thus, the hospital's private cloud can ensure the integrity of the messages. The private cloud's signature Sig HPC1 can be verified by its public key by using the following Eqs. 41 and 43 as follows: Thus, the doctor can ensure the integrity of the messages. In the proposed scheme, all parties create a signature, and their authenticity is ensured by these signatures. Therefore, the proposed scheme meets the integrity requirement.

Non-repudiation
While all parties send messages, it is also important that no party can deny sending a message that they have sent. The proof of the non-repudiation offered by the proposed scheme is given in Table 2.

Forward and backward security
New random numbers are selected for session keys in every session, thus changing the session key by using the following Eqs. 17 and 39 for every session on the proposed scheme, as follows: The encryptions in the proposed scheme are changed every session because it contains time stamps which change every session. The encrypted messages, which are caculated by using the following Eqs. 12,18,23,29,34,40,45 and 47 are as follows: The timestamps in the encrypted messages and the random numbers in the session keys ensure that attackers cannot decrypt messages sent in the current session, and they cannot use messages from previous sessions as duplicate or replacement messages. For the same reason, if attackers obtain current messages, they cannot decrypt old messages. Therefore, the proposed scheme offers both forward and backward security.

Replay attack
The proposed scheme uses two forms of encryption, namely the public key operation, and the session key operation. Both are secure against replay attacks. In the public-key operation, all messages include a timestamp. The timestamps prevent replay attacks because the timestamp is different at any time, which means that encrypted messages are different for every session. The details of the public key operations which are computed by using the following Eqs. 12,18,25,29,34 and 40 are as follows: (17) SEK 1 = h((S D R P2 + r 6 (R P1 + H(ID P ||B P ||R P1 )PK ))||r 6 R P2 ), The session keys are also changed every session by the random number chosen. The session keys which are calculated by using the following Eqs. 17 and 39 are as follows: The transmitted messages also contain timestamps. So, even if an attacker intercepts previous messages and sends them back to the current session, they will fail the verification, and communication will be terminated.

Man-in-the-middle attack
For an attacker to conduct a man-in-the-middle attack, they need to intercept transmitted messages. Then they will modify the intercepted message, and send the modified message to the destination party. However, all signatures in the proposed scheme involve a timestamp, the scheme uses public-key cryptography, and public and private keys. Therefore, the public key is used to encrypt the message, and the private key is used to sign the message. An attacker cannot modify a signature while it involves a private key, and cannot modify the timestamp. Therefore, they cannot conduct a man-in-the-middle attack, as it is not possible to successfully modify a message. The signatures which are computed by using the following Eqs. 13,19,26,30,35 and 41 are listed as follows:

Impersonation attack
An impersonation attack occurs when an attacker poses as a legitimate party in order to access sensitive information.
(1) Impersonation of the patient If an attacker can impersonate a legitimate user, then they can forge a Sig P1 message to appear as if it was sent by the patient. Sig P1 is computed by using the following Eq. 13 as follows: (41) Sig HPC1 = S PRK HPC (PK ||T HPC1 ||ID HPC ).   Thus, even if the attacker knows the doctor's public key, the attacker still cannot forge Sig D2 and Sig D3 since they are signed with the doctor's private key. (4) Impersonation of the public cloud If an attacker is able to impersonate the public cloud, then they can forge a Sig C message according to the received C D2 and Sig D2 messages. Sig C is computed by using the following Eq. 30 as follows: Even if the attacker can obtain the public cloud's public key, they will still be unable to forge Sig C because it is signed with the public cloud's original private key. It is therefore impossible for malicious attackers to successfully impersonate any party in the proposed scheme.
(41) Sig HPC1 = S PRK HPC (PK ||T HPC1 ||ID HPC ).    Table 3 gives a comparison of the security attributes of the proposed scheme with those of other schemes.

Security comparison
This study found that the schemes proposed by Chiou et al. [13], Mohit et al. [14] and Li et al. [16] do not support patient anonymity and patient unlinkability, are not secure against impersonation attacks and do not support doctor unlinkability, while the proposed scheme can achieve all of these. We applied encryption and signature mechanism to protect transmitted messages, which guarantees confidentiality and integrity. Our proposed architecture is indeed applicable in real environments, which also fully ensures availability.

Computation cost
The computation cost of the proposed scheme is 12T Sign + 14T A + 6T S + 4T H , which is higher than those of other schemes because it uses both asymmetric and symmetric encryption for improved security. Although other schemes require less execution time, they do have some related flaws, as there are some security requirements that they do not meet, such as patient anonymity, patient unlinkability, and doctor unlinkability. To sum up, the proposed scheme is more secure than others. Table 4 shows the computation cost comparison.

Communication cost
The communication cost comparison is shown in Table 5. This study adopts the approach described for the Mohit et al. scheme [14] to compute the communication cost. The proposed scheme incurs a communication cost lower than those of the schemes proposed by Chiou et al. and Mohit et al. [13], and higher than those of the schemes proposed by Kumar et al. and Li et al., because the proposed scheme uses signatures in every session, which incur a greater communication cost, but enables non-repudiation. The cost of communication at each stage was analyzed in a 4G environment, with a maximum transmission speed of 100 Mbps, and in a 5G environment, with a maximum transmission speed of 20 Gbps [39].

Conclusion
EMR security is a significant issue in current distributed EMR storage and sharing schemes, as it is crucial that any system be secure against malicious attacks. The scheme proposed in this study offers secure and efficient distributed sharing of EMR data between four parties using cloud computing technology and encryption, such as public-key operation, session key operation, and elliptic curve cryptography. The proposed scheme offers patient privacy during the consultation phase, ensures message integrity and non-repudiation, achieves mutual authentication between parties, offers authentication of medical resource sharing via cloud technology, and is secure against known attacks, thus providing a convenient and secure way to store, use and share medical information resources between hospitals, ensuring more efficient use of medical information resources, and offering patients better and more timely diagnosis and treatment.