iPatient Privacy Copyright Cloud Management

Abstract

The advent and rapid rise of network technology and cloud computing have led to new opportunities for ushering in a new era in telehealth. Thanks to the Internet of Things (IoT) and advances in 5G communication, telehealth is expanding and shows no signs of slowing down. It provides patients including elderly and disabled patients with convenient and easy access to healthcare services across space and time. However, the continuous real-time transmission of health information over networks also exposes private data to the risk of being intercepted by third parties. The privacy of the primary individual patient must be managed under the protection of the patient’s anonymous key while storing, transferring, sharing, and adding privacy rights. A question arises: How can we design a secure communication environment for remote access control to personal privacy matters? The patient’s electronic medical record is protected by the patient’s private key, and our scheme provides a real anonymous design for the patient with absolute autonomy over their privacy. Each update of the cloud medical records is patient-led and performed in a secure tunnel. As a result, this study reveals that the cloud-based iPatient privacy copyright management fully controlled by an individual patient is indeed safe and effective.

1. Introduction

Personal handwritten medical records are being phased out, and electronic personal medical records are now commonplace. An iPatient, which refers to a patient-led, privacy and medical record copyright issue, is rising to the challenge of privacy security. Most medical records kept by hospitals or private clinics are viewed and distributed without the patient’s authorization. As such, many medical agencies have begun to pay attention to the importance of this issue and have begun to design a medical record database system that is centrally managed and shared. Most of the current patient privacy and medical record copyrights based on medical priority can be read by medical personnel with unlimited access only by a one-time authorization. Such privacy protection is obviously deficient. Anyone maliciously intending to obtain the privacy of others’ medical records can easily illegally obtain relevant information. Hence, how to let patients fully control their own personal privacy and medical record copyright has become an important issue in today’s privacy-sensitive information-dominated society. With the advent of the cloud computing era, most data are stored in cloud servers; therefore, we call these data management solutions “iPatient privacy copyright cloud management.”

Additionally, telehealth has received considerably increased attention. In this medical treatment approach, all the medical prescriptions, personal privacy, medical record copyright, etc., are transmitted on the public network and the data are stored in the cloud system. The main topics in this paper include the following: How to ensure telehealth visits occur in a secure transmission environment, how to securely transfer data and securely process data, and how to ensure that all actions related to patient privacy are performed with the patient’s full authorization. The management of general medical records is mainly through a secure tunnel to encrypt and decrypt data. The tunnel is constructed by a cryptographic asymmetric public key system or symmetric key agreement. Asymmetric public-key encryption and decryption methods need to maintain huge public and private key pairing creation and storage costs. Accordingly, in recent years, symmetric encryption and decryption by a session key agreement mechanism has managed privacy issues. The main point of the key agreement mechanism is to design a set of zero-knowledge-based communications. The two communication parties cannot transmit information that is derived or reversibly decrypted to obtain the private key, and also cannot reveal personal identities during the medical communication process. This paper proposes, under the above premises, an application to provide medical personal privacy and a copyright access mechanism that is managed in the cloud, where the entire process is conducted in a patient-controlled authorization environment, which can be seen in Figure 1. The paper is laid out as follows. Section 2 introduces the related work. Our protocols are found in Section 3. Security analysis is shown in Section 4. Section 5 shows performance comparisons. Section 6 illustrates the conclusions.

2. Related Work

In this study, we used a symmetric key to encrypt and decrypt all transmitted medical record copyrights. Therefore, we established a secure tunnel for all transmitted data and designed a symmetric key agreement mechanism. The key agreement was roughly divided into two parts, namely offline processing and online processing. In the case of offline processing, the user had to use a token that was unavailable to others to initialize the key agreement. Prior studies used personal identity IDs and passwords for preliminary verification, which is often referred to as the two-factor verification method [1,2].

When coupled with other auxiliary mechanisms or biological characteristics, they are often referred to as three-factor authentication [3,4]. However, new research mostly used fuzzy hashing conducting one-way exclusive pairing for biological characteristics, changing slightly each time [5,6]. Our research used fuzzy hashing plus identity anonymity; thus, it is a single-factor dynamic anonymous offline processing method [3,4,7]. Offline processing security vulnerability issues include smart card loss or brute force password cracking attacks, and many prior studies have also proposed possible vulnerabilities and solutions [8,9,10]. Alternatively, in the case of offline processing, a zero-knowledge information exchange key agreement was performed through the public network [11]. In the case of the key agreement mechanism, many scholars had proposed related agreements [8,11,12,13,14,15]. In 2002, using fingerprints as passwords and using a remote login authentication through smart cards and biometrics were common [9]. Two years later, the improperly designed communication process posed a risk of masquerade attacks even though biometrics are hard to counterfeit [16].

In 2012, a study addressed a medical information system for an integrated electronic patient record (EPR) with a one-way operation hash function as the main security mechanism. The study also reduced the time of encryption and decryption operations through multiplications [17]. However, it was still possible to carry out impersonation attacks although prior studies provided irreversible encryption and decryption operations for medical information systems. Impersonators can obtain fake user information by hacking the database [12]. In the case of user anonymity, in 2017, some scholars addressed anonymous mechanisms [3,4,7,14,15]. However, our study found that the anonymity in many studies was pseudonymous because the same alias was also easily traced to an association with the real identity. Our study will design one real untraceable anonymous agreement. As telehealth has received substantially increased attention, cloud data communication and storage security for telehealth have become quite important issues [3,18,19,20,21,22,23]. There are many possible malicious attacks in traditional communication security issues such as man-in-the-middle, spoofing, and replay attacks [23,24,25,26]. Recently, Lin [27] proposed an authorized sharing mechanism for telehealth. Several weaknesses existed in Lin’s scheme. Lin’s scheme only discussed security protocols transferring data from the data centers to the hospital and lacked a design for storage or modification. Hospitals and data centers did not know the user’s location and the real address, and consequently, they were unable to directly send communication messages. Additionally, the immutable pseudonyms were not truly anonymous and the medical record update did not establish a user-led secure channel, and data were probably at risk of being tampered with or counterfeited [27].

The main points of our study focus on the patients’ complete anonymity but fully controlled through a zero-knowledge key agreement mechanism withstanding existing malicious communication attacks. All sensitive information is processed and transmitted after the secure tunnel is established. We designed an iPatient privacy copyright cloud management system, the details of which are shown in Figure 2.

3. The Proposed Mechanism

In this section, we describe our iPatient copyright privacy cloud management protocols. We apply the patient personal biometric signal and lightweight biometric hash function to encipher the security for the patient’s private copyright. Our proposed protocol contains three phases, namely the initialization phase, registration phase, and electronic patient record sharing and updating phase. A scenario of iPatient copyright privacy cloud management is illustrated in Figure 2.

Table 1. Notations table.

Notations	Description
Bi	The biometric signal of Pi
CA	Certificate Authority
Dj	j-th Hospital Doctor/Clinic
DK (.)	Symmetric decryption function using key K
EK (.)	Symmetric encryption function using key K
EPRS	Electronic Patient Record Server
h (.)	One-way hash function
H (.)	One-way fuzzy hash function suitable for biometric
IDPi	Patient Pi’s identity
IDDj	Hospital Doctor/Clinic Dj’s identity
IDe	EPRS’s identity
Pi	i-th Patient
Ri	Electronic patient record of Pi
TCA	The secret token of CA
⊕	Exclusive-OR operation

lists the notations used in the proposed protocols.

3.1. Initialization Phase

In our mechanism, there are three roles. Each role must be registered and initialized with a certificate authority (CA) to obtain a passcode for verification. In the first phase, the electronic patient record server (EPRS) performs initial registration information with a CA, as seen in the following two stages.

Stage 1. The EPRS registers on-site the first time with a CA. The CA generates the identifier IDe for the EPRS. The CA computes the token EC = h (IDe⊕TCA), stores IDe in its CA members database, and sends message tuple {IDe, EC} to the EPRS via a secure channel.

Stage 2. The EPRS receives the message tuple {IDe, EC} from the CA, stores IDe and EC in the EPRS database, and then finishes the EPRS initialization phase.

3.2. Registration Phase

In the second phase, two roles, namely patients and remote hospital doctors or clinics, need to register at the CA. We describe these two roles separately in the following subsections.

3.2.1. Patients Registration Phase

Patients must register the first time with the CA in the prior EPRS registration phase and create patient accounts on the EPRS in the following three stages.

Stage 1. P_i keys in onsite his/her identity ID_Pi and imprints the fingerprint B_i; then, the CA obtains {ID_Pi, H (B_i)}.

Stage 2. The CA receives the message {ID_Pi, H (B_i)} from P_i and then calculates the secret token V_i = ID_Pi ⊕ H (B_i), generates a random number R_Pi, computes secret token ST_i = ID_Pi ⊕ R_Pi, computes secret token S_i = R_Pi ⊕ h (T_CA), and M₁ = R_Pi ⊕ h (ID_e ⊕ T_CA). Then, the CA stores {V_i, ST_i, S_i} to the smart card and stores the patient ID ID_Pi to its ID list table. The CA then sends the smart card back to the P_i through the secure channel and sends {ST_i, M₁} to the EPRS over the public channel.

Stage 3. The EPRS receives the message {ST_i, M₁} from the CA and then computes R_Pi = M₁ ⊕ EC, ID_Pi = ST_i ⊕ R_Pi, creates a new patient record EPR {R_i} for ID_Pi, encrypts R_i using RP_i {E_RPi (R_i)}, and stores ID_Pi, E_RPi (R_i) to EPRS’s database.

3.2.2. Remote Hospital Doctors or Clinics Registration Phase

The hospital doctors or clinics must also register the first time with the CA in the prior patient’s registration phase by the following two stages.

Stage 1. Doctor D_j registers on-site the first time with a CA. The CA generates the identifier ID_j for the D_j and then computes DC_j = h (h (ID_j) ⊕ T_CA), stores DC_j to a medical card of doctor D_j, and then sends back to the doctor D_j via a secure channel.

Stage 2. D_j receives the personal medical card from the CA and keeps the medical card on hand.

3.3. Secure Electronic Patient Record Storing, Sharing, and Updating Communication Phase

This phase involves the stages of health medical privacy creation, sharing, and storage. In our iPatient access control model, doctors or clinics have read and updated permissions, while authorized professionals have only read permissions. Only patients themselves can access the encrypted personal privacy of the cloud server. Additionally, all data stored in the cloud are also protected by the patient’s private key. All decrypted data must be transmitted in a secure tunnel established through a key agreement. Below, we show six strategies in the iPatient access control model and show the strategy diagram in Figure 3.

• The privacy of all patients is protected and stored in a cloud database via the patient’s private key.
• Anyone who wants to access patient privacy records must obtain the patient’s authorization and obtain the records of the patient via patient downloading from the cloud database.
• In the case of protecting the privacy of the cloud database, only patients can access via key agreement to establish a secure tunnel. After the tunnel is established, the transmitted data still need to be encrypted with the session key before it can be transmitted securely.
• Doctors modify, update patient records, and send them to the patient via the session key. After the patient decrypts the updated patient records, s/he will use the personal private key to encrypt them, and then encrypt them with the session key to upload them to the cloud database server. Once the cloud data server receives and decodes them with the session key, it will update them to the patient records database.
• Other authorized professionals excluding doctors can only read the patient records transmitted by the patient through the secure tunnel after they have been authenticated by the key agreement. They cannot modify or update patient records.
• Our design for iPatient is personally led and we want to establish a privacy sharing mechanism that is completely patient-led.

Below, we introduce the steps we designed. First, we perform the three-party key agreement process in order to build a secure tunnel, and then decrypt, add, and modify the medical records in a secure tunnel.

Stage 1. P_i imprints the biometric B_i and then deciphers his/her identity by ID_Pi = V_i ⊕ H (B_i), deciphers R_Pi^old = ST_i ⊕ ID_Pi, NID_Pi = ID_Pi ⊕ R_Pi^new, and generates a new random number R_Pi^new, M₁ = R_Pi^old ⊕ S_i ⊕ R_Pi^new. P_i then sends message {NID_Pi, NID_Dj, M₁} to the CA via a public channel.

Stage 2. After receiving the message from the P_i, the CA deciphers R_Pi^new = M₁ ⊕h (T_CA), ID_Pi = NID_Pi ⊕ R_Pi^new, and checks the patient identity ID_Pi from the CA’s ID table. If the legal list cannot find the ID_Pi, the request is terminated. Then, the CA calculates ID_Dj = NID_Dj ⊕ R_Pi^new, computes M₂ = R_Pi^new ⊕ h (ID_e ⊕ T_CA), M₃ = R_Pi^new ⊕ h (ID_Dj ⊕ T_CA), and then sends a request of message and parameters tuple {NID_Pi, NID_Dj, M₂} to the EPRS through the public channel. Then, the CA sends {NID_Pi, M₃} to the doctor D_j via a public channel.

Stage 3. After receiving the message {NID_Pi, NID_Dj, M₂} from the CA, the EPRS computes R_Pi^new = M₂ ⊕ EC, ID_Pi = NID_Pi ⊕ R_Pi^new, and checks ID_Pi from the EPRS database. Then, the EPRS generates a random number R_EPRS, generates secret token M₄ = R_Pi^new ⊕ R_EPRS, and then sends M₄ to doctor D_j via a public channel.

Stage 4. After receiving the message {NID_Pi, M₃} from the CA and M₄ from the EPRS, D_j computes R_Pi^new = M₃ ⊕ DC, ID_Pi = NID_Pi ⊕ R_Pi^new, generates a random number R_D, computes R_EPRS = M₄ ⊕ R_Pi^new, M₅ = R_D ⊕ R_EPRS, and then sends {M₅, NID_Pi} to the CA and {M₅} to the EPRS via a public channel. Then, D_j owns the session key SK = h (R_Pi^new ⊕ R_EPRS ⊕ R_D).

Stage 5. The EPRS receives the message {M₅} from D_j, computes R_D = M₅ ⊕ R_EPRS, and then computes session key SK = h (R_Pi^new ⊕R_EPRS ⊕ R_D).

Stage 6. The CA receives the message {M₅, NID_Pi} from doctor D_j and then sends M₅ to P_i by checking NID_Pi.

Stage 7. After receiving the message from the CA, P_i computes session key SK = h (R_Pi^new ⊕ M₅), updates secret tokens ST_i = ST_i ⊕ R_Pi^new ⊕ R_Pi^old and S_i = S_i ⊕ R_Pi^new ⊕ R_Pi^old, and then finishes key agreement.

After the key agreement process is done, the secure tunnel among P_i, the EPRS, and D_j is established. The three roles can use the same one-time session key for secure communication. Next, the patient privacy history update process under the secure channel is detailed in Stage 8 to Stage 12.

Stage 8. The EPRS uses the secret session key SK to encrypt the privacy record of the ID_pi patient, M₆ = {E_SK (E_K (R_i))}, and then sends M₆ to patient P_i.

Stage 9. P_i receives the encrypted electronic patient record {E_SK (E_K (R_i))} and decrypts E_SK (E_K (R_i)) using session key SK to obtain E_K (R_i). Then, P_i applies R_Pi^old to decipher the original R_i = D_RPi^old (E_K (R_i)) and then enciphers the original R_i with session key SK to message M₇ = E_SK (R_i). Then, P_i sends M₇ to doctor D_j.

Stage 10. The doctor D_j receives the message M₇ from P_i and deciphers the original record R_i using SK, R_i = D_SK (M₇). When the telehealth service is done, the doctor generates a new record R_i^new and then enciphers the new record R_i^new using session key SK to obtain message M₈ = E_SK (R_i^new). Then, the doctor D_j sends encrypted privacy record M₈ to P_i.

Stage 11. P_i receives the message from D_j and uses session key SK to obtain R_i^new = D_SK (M₈). Then, P_i enciphers himself the privacy record to obtain M₉ = E_SK (E_RPi^new (R_i^new)) and sends M₉ to the EPRS.

Stage 12. The EPRS receives the message M₉ from P_i and then computes M₁₀ = D_SK (M₉). The EPRS updates ID_Pi’s electronic patient record using M₁₀ {E_RPi^new (R_i^new)} and then finishes the data sharing and data update phase.

3.4. Algorithms for Key Agreement, Data Encryption/Decryption, and Updating

In this subsection, we also give another presentation to describe our protocols. We use different roles to divide the algorithms into four independent but concurrent procedures. As described from Algorithms 1–4.

Algorithm 1: Procedure of Patient Pi
1.	Bi = imprints (Pi ’s biometric)	// Input patient’s biometric
2.	IDPi = Vi ⊕ H (Bi)	// Retrieves patient’s identity
3.	RPiold = STi ⊕ IDPi	// Retrieves prior random number
4.	RPinew = Random()	// Generates a new random number
5.	NIDPi = IDPi ⊕ RPinew	// Generates new nick ID
6.	M1 = RPiold ⊕ Si ⊕ RPinew	// Replaces Si to M1 with new random number
7.	Sends { {NIDPi, NIDDj, M1}, CA }	// Sends communication message to CA
8.	while (! receive from CA) { do nothing }	// Waiting for the response from CA
9.	SK = h(RPinew⊕M5)	// Computes session key h (RPinew⊕REPRS⊕RD)
10.	STi = STi ⊕ RPinew ⊕ RPiold	// Updates secret tokens STi
11.	Si = Si ⊕ RPinew ⊕ RPiold	// Updates secret tokens Si
// The following statements for privacy data processing in secure tunnel
12.	while (! receive from EPRS) { do nothing }	// Waiting for the response from EPRS
13.	EK(Ri) = DSK(ESK(EK(Ri)))	// Deciphers message using session key SK
14.	Ri = DRPiold (EK(Ri))	// Deciphers record using private key RPiold
15.	M7 = ESK (Ri)	// Enciphers the original Ri with session key SK
16.	Sends { { M7 }, Dj }	// Sends cyber record to doctor Dj
17.	while (! receive from Dj) { do nothing }	// Waiting for the response from Dj
18.	Rinew = DSK (M8)	// Deciphers new record using session key SK
19.	M9 = ESK(ERPinew(Rinew))	// Pi enciphers privacy using private key Rinew
20.	Sends { { M9 }, EPRS }	// Sends cyber record to EPRS

Algorithm 2: Procedure of CA
1.	while (! receive from Patient Pi) { do nothing }	// Waiting for the ack from Patient Pi
2.	RPinew= M1⊕h(TCA)	// Deciphers random number
3.	IDPi= NIDPi⊕RPinew	// Retrieves patient’s ID
4.	if (! exist (IDPi)) exit()	// Checks if IDPi is illegal or not, if not exist session
5.	IDDj= NIDDj⊕RPinew	// Retrieves doctor’s ID
6.	M2= RPinew⊕h(IDe⊕TCA)	// Builds exchange message M2
7.	M3= RPinew⊕h(IDDj⊕TCA)	// Builds exchange message M3
8.	Sends { { NIDPi, NIDDj, M2 }, EPRS}	// Sends communication message to EPRS
9.	Sends { { NIDPi, M3 }, Dj }	// Sends communication message to Dj
10.	while (! (receive (M5))) { do nothing }	// Waiting for the response from Dj
11.	Sends { { M5 }, whois(NIDPi) }	// Forwards communication message to Pi

Algorithm 3: Procedure of doctor Dj
1.	while (! (receive (M3))) { do nothing }	// Waiting for the ack from CA
2.	RPinew = M3⊕DC	// Deciphers random number RPinew
3.	while (! (receive (M5))) { do nothing }	// Waiting for the ack from EPRS
4.	RD = Random()	// Generates a new random number
5.	REPRS = M4⊕RPinew	// Deciphers random number REPRS
6.	M5 = RD⊕REPRS	// Builds exchange message M5
7.	Sends { { M5, NIDPi }, CA }	// Forwards communication message to CA
8.	Sends { { M5 }, EPRS }	// Forwards communication message to EPRS
9.	SK = h(RPinew⊕REPRS⊕RD)	// Computes session key h(RPinew⊕REPRS⊕RD)
// The following statements for privacy data processing in secure tunnel
10.	while (! receive from Pi) { do nothing }	// Waiting for the response from Pi
11.	Ri = DSK(M7)	// Deciphers the original record Ri using SK
// Telehealth service
12.	Rinew   = updateRiold()	// Doctor generates a new record for Pi
13.	M8 = ESK(Rinew)	// Enciphers the Rinew with session key SK
14.	Sends { { M8 }, Pi }	// Sends cyber record to Pi

Algorithm 4: Procedure of doctor EPRS
1.	while (! (receive (M2))) { do nothing }	// Waiting for the ack {NIDPi, NIDDj, M2} from CA
2.	RPinew = M2⊕EC	// Deciphers random number RPinew
3.	IDPi = NIDPi⊕RPinew	// Retrieves patient’s ID
4.	if (! exist (IDPi)) exit()	// Checks if IDPi is illegal or not, if not exist session
5.	REPRS = Random()	// Generates a new random number
6.	M4= RPinew⊕REPRS	// Builds exchange message M5
7.	Sends { { M4 }, Dj }	// Forwards communication message to Dj
8.	while (! (receive (M5))) { do nothing }	// Waiting for the ack {M5} from Dj
9.	SK = h(RPinew⊕REPRS⊕(M5⊕REPRS))	// Computes session key h(RPinew⊕REPRS⊕RD)
// The following statements for privacy data processing in secure tunnel
10.	M6 = {ESK(EK(Ri))}	// EPRS encrypts the privacy record of the IDpi
11.	Sends { {M6}, P }	// Sends encrypted privacy of Pi to Pi
12.	while (! receive from Pi ) { do nothing }	// Waiting for the response from Pi
13.	M10 = DSK(M9)	// Decipher M9 using session key SK
14.	Updates (M10, IDPi)	// EPRS updates IDPi’s electronic patient record

4. Security Analysis

In this section, we highlight some of the attributes and well-known attack types in the encryption and decryption process of long-distance data transmission and describe, in detail, the reasons why our designed protocol can resist attacks. The defenses of user anonymity, stolen or lost smart card attack, man-in-the-middle attack, replay attack, tamper attack, insider privilege attack, verify table stolen attack, off-line password guessing attack, and known key security are illustrated as follows.

4.1. User Anonymity

In our protocol, the patient Pi uses a one-time random number as a key to wrap the patient and the clinician’s original ID in each communication. The alias ID of P_i is NID_Pi = ID_Pi ⊕ R_Pi^new, and the alias ID of D_j is NID_Dj = ID_Dj ⊕ R_Pi^new. Each time the ID is protected by a random value, it can be ensured that the ID is not derived and the malicious attacker cannot track a specific nickname. Additionally, the CA can check the ID list to verify that the user’s nickname is legal. Therefore, the mechanism we proposed can correctly implement user anonymity.

4.2. Stolen or Lost Smart Card Attack

When a user’s personal smart card is lost or stolen, a malicious attacker accessing the card can retrieve the information stored in the smart card. At this time, if the attacker cannot be detected, the attacker can use the smart card and the information in the smart card to simulate a remote legal user and pass the authentication.

In our proposed mechanism, only three parameters V_i, ST_i, and S_i are stored in the smart card. In our design, the ID is the main secret. If the user’s personal biosignal H (B_i) cannot be obtained after obtaining V_i, the ID cannot be obtained. ST_i and S_i use the updated Rp_i and CA private information to protect the ID. Therefore, it is impossible to analyze the biological characteristic B_i to analyze the ID. Therefore, when a malicious attacker steals the patient’s smart card, the attacker still cannot obtain the patient’s real identity and CA’s private key by verifying V_i. Accordingly, there is little likelihood of decryption; consequently, we confirm that the proposed mechanism can prevent a data breach from theft or lost smart card attacks.

4.3. Man-In-The-Middle Attack

The person illegally retrieving messages during the communication period is called a man-in-the-middle attack. A middleman will modify or falsify content before it is delivered to the recipient. In our proposed protocol, the key communication messages are M1, M2, and M3. The message M1 that the patient communicates with the CA is protected by the CA’s private secret T_CA. If the attacker tampers with this message, after receiving the maliciously modified message, the CA’s R_Pi^new will be incorrect. In addition, when the M2 message is modified by a malicious attack, the EPRS cannot resolve the real R_Pi^new through its privacy token EC. The message M3 transmitted from the CA to the doctor is protected by the doctor’s secret value DC_j. If the message is modified by a malicious attack, the doctor is also unable to obtain the real R_Pi^new. Regardless of whether the content of M1, M2, or M3 is maliciously modified, the final session key will be different, and a shared secret tunnel cannot be generated. Our proposed mechanism indeed resists man-in-the-middle attacks.

4.4. Replay Attack

Replay attacks can also be viewed as man-in-the-middle attacks. This type of attack does not need to modify or tamper with the communication information, but directly retransmits the original information. If the malicious attacker obtains the message sent from the user to the CA, the malicious attacker can directly replay the authentication without verifying the message. Generally, resolving this issue is offset by a timestamp. In our proposed mechanism, timestamps are replaced by dynamic parameters formed by one-time random numbers. If a malicious attacker replays the user’s messages {NIDPi, NIDDj, M1}, sending them to the certificate authority again, s/he may obtain the message M4 from the electronic medical record server. However, the malicious attacker cannot know the one-time random number RP_i^new generated by the patient and will receive the wrong message to create the wrong session key. Hence, our proposed mechanism can defend against replay attacks.

4.5. Tamper Attack

Tamper attacks can also be viewed as man-in-the-middle attacks. In our design, if a malicious attacker tampers with the communication between CA and Pi, the CA will not be able to obtain the real R_Pi^new, because M1 has been tampered with by a malicious attacker. When the CA uses the wrong IDPi*, the CA is unable to obtain the real IDPi. R_Pi^new is not actually Pi, because the message has been tampered with by a malicious attacker and the CA will reject the key agreement request. Additionally, when a malicious attacker maliciously modifies the message, {NIDPi, NIDDj, M2} is sent from the CA to the EPRS. If message M2 has been maliciously modified so that EPRS checks the EPR database, the EPRS will not find the real Ri using IDPi. As a result, the EPRS will stop the key agreement request. In short, the mechanism we propose can prevent tampering attacks.

4.6. Insider Privilege Attack

Internal privileged attacks mean that malicious attackers deliberately register as legitimate members, so they may obtain relevant authentication information. They impersonate other legitimate users, perform illegal secret authentication, and obtain the keys of certificate authorities. In our proposed protocols, the internal information available to each user will be protected in V_i, ST_i, and S_i. The secret tokens in S_i are protected by the patient’s biosignal H (B_i) and the one-time random number for updating ST_i and S_i. Hence, if internal malicious attackers obtain their own V_i, ST_i, and S_i, they cannot know the biological characteristics of the pre-impersonator, and the secret information is updated randomly in each session, so impersonation verification cannot be performed. Additionally, during the patient registration phase, CA’s secret token is hash-encrypted by a one-way hash function. Even if an internally privileged malicious attacker can easily obtain h (TCA), s/he cannot obtain the CA’s real secret token TCA. Based on the one-way hash function and the security of biological characteristics, it shows that our proposed mechanism can resist internal privilege attacks.

4.7. Verify Table Stolen Attack

The verify table refers to the list used to confirm the relevant identity in the authentication server. A malicious person can invade the authentication server. A malicious insider can steal the verification form from the certificate authority through his own authority. Then, they obtain confidential information of other users from the table to impersonate other legitimate identities. In our proposed protocols, the certificate authority only stores a list of legitimate user ID_Pi and does not store other linkable messages for the user. It only provides the electronic medical record sharing stage, allowing the certificate authority to verify the user’s identity through the ID list. As such, our proposed mechanism will not allow attackers to perform other attacks even if the verification table is stolen.

4.8. Off-Line Password Guessing Attack

Generally, for the sake of saving communication costs, the system first verifies the client information and confirms that communication content is correct before communicating with the remote site. As such, malicious attackers often use brute force offline password guessing after obtaining the smart card. In our proposed protocols, patients do not use a password to register with a certification authority during the registration phase. In the medical record sharing stage, there is a patient’s personal biometric protection communication message. The biometric signal is unique for everyone, so a malicious attacker cannot obtain the secret B_i. Additionally, the CA checks the ID list and rejects the illegal ID_Pi, so offline attacks will not obtain the real ID. We confirm that the proposed mechanism can resist offline password guessing attacks.

4.9. Known Key Secrecy

Known key secrecy is often mistaken for perfect forward secrecy because malicious users may obtain the session key or any secret information through analysis and predict the next session key or member privacy. In our proposed protocol, the session key used by patients, the EPRS, and doctors in the communication is generated by a one-time random number SK = h (R_Pi^new ⊕ R_EPRS ⊕ R_D), where the random number R_Pi^new is generated by the patient randomly. The number R_EPRS is generated by the electronic medical record server, and the random number R_D is generated by the remote doctor. These one-time random numbers are irregular. Each parameter is randomly regenerated. Consequently, even if the attacker obtains any such confidential information in this session, the attacker cannot calculate the next session key, so the proposed protocol can provide known key secrecy.

5. Performance Comparisons

In this section, we compare recent electronic medical solutions by their computational and communication costs. Comparisons of Wen et al. [7], Li et al. [12], Jung et al. [13], Wu et al. [17], Lin et al. [28], Lee et al. [29], and our method are illustrated in

Table 2. Performance comparison table.

	Phases	Registration Phase	Login/Authentication Phase	Password Change Phase	Total Cost
Schemes
Wen [7]		4Th + 2Txor	(6Th + 2Txor) + 1Tqr + 1TM	4Th + 2Txor	(14Th + 6Txor) + 1Tqr + 1TM
Lee [12]		4Th + 2Txor	12Th + 9Txor	4Th + 3Txor	(20Th + 14Txor)
Jung [13]		3Th + 2TH + 1Txor	13Th + 2TH + 9Txor	2Th + 2TH	(24Th + 10Txor)
Wu [17]		2Th + 1Txor	10Th + 1Txor + 2TM	1Th	(13Th + 2Txor) + 2TM
Lin [28]		1Th + 1Txor	9Th + 26Txor + 4TM	N/A	(9Th + 26Txor) + 4TM
Lee [29]		6Th + 1TH + 15Txor	7Th + 1TH + 13Txor	8Th + 1TH + 16Txor	(24Th + 44Txor)
Proposed		3Th + 1TH + 7Txor	6Th + 1TH + 22Txor	4Txor	(11Th + 33Txor)

T_H: Denotes execution time of biometric-hash function operation; T_h: Denotes execution time of one-way hash function operation; T_xor: Denotes execution time of XOR operation/concatenation operation; T_M: Denotes execution time of multiplication operations; T_qr: Denotes execution time of computing a square root modulo n. T_L: Denotes execution time of total lightweight computing.

, a performance comparison table, where T_H denotes the execution time of the biometric-hash function operation, T_h denotes the execution time of the one-way hash function operation, T_xor denotes the execution time of the Exclusive-OR (short for XOR) operation, T_M denotes the execution time of multiplication operations, and T_qr denotes the execution time of computing a square root modulo n. T_xor, T_h, and T_H belong to lightweight operations. According to the description of [15,23], the calculation of the XOR operation is negligible, and the T_h ≈ T_H time cost is similar.

As lightweight computing has gradually become the main issue of encryption and decryption considerations, more and more articles employ it. As the computing time of lightweight computing is relatively short, the variation in the discrepancy was found to be negligible. Even though the computing time in our paper is slightly shorter than others, this is not our focus. We emphasize that we can still avoid various well-known malicious attacks under nearly differential calculation time, implement a genuine dynamic anonymous mechanism, and employ exclusive one-single-factor input, namely reasonable biometric features, to avoid long strings of memories and inputs.

In Figure 4 and Table 2, we mainly focus on the lightweight operation, which mainly includes XOR and hash operations. Though our proposed mechanism is not the best in XOR operation performance, our hash function operation performance is the best. In the case of total cost, the operation computation time of bitwise XOR has less hash function, so our proposed mechanism uses the least cost and has better performance. As mentioned in Table 2, our login phase computation time is (6T_h + 1T_H + 22T_xor) ≈ (7T_h + 22T_xor) and the total computation time required for our proposed mechanism is (9T_h + 2T_H + 33T_xor) ≈ (11T_h + 33T_xor) relative time.

Finally, a security comparison of the proposed solution with related research for different known attacks, user anonymous, man-in-the-middle attack, replay attack, stolen or loss smart card attack, tamper attack, insider attack, verify table stolen attack, off-line password guessing attack, and known key security are shown in

Table 3. Security comparison table.

Trait	Wen [7]	Lee [12]	Jung [13]	Wu [17]	Lin [28]	Lee [29]	Proposed
T1	Yes	Yes	No	Yes	No	Yes	Yes
T2	Yes	Yes	Yes	Yes	Yes	Yes	Yes
T3	Yes	Yes	Yes	Yes	No	Yes	Yes
T4	Yes	Yes	Yes	No	Yes	Yes	Yes
T5	Yes	No	Yes	Yes	Yes	Yes	Yes
T6	Yes	Yes	Yes	Yes	Yes	Yes	Yes
T7	Yes	Yes	Yes	No	Yes	Yes	Yes
T8	Yes	No	Yes	Yes	Yes	Yes	Yes
T9	Yes	Yes	Yes	Yes	Yes	Yes	Yes
T10	No	Yes	Yes	Yes	No	Yes	Yes

T1: User anonymous. T2: Man-in-the-middle attack. T3: Replay attack. T4: Stolen or loss smart Card attack. T5: Tamper attack. T6: Insider attack. T7: Verify table stolen attack. T8: Off-line password guessing attack. T9: Known key security. T10: Lightweight computing cost.

. Based on the security analysis, we observe that the mechanism proposed in this study is to determine that it can resist known attacks, and the results are desirable.

6. Conclusions

Thanks to the Internet of Things (IoT) and advances in 5G communication, telehealth is expanding and shows no signs of slowing down. It provides patients with convenience and easy access to healthcare services across space and time. However, the continuous real-time transmission of health information over networks also exposes the patients’ privacy copyright data to the risk of a data breach. In this paper, we propose a personal electronic medical record copyright storage and transmission protection, authorization, and sharing management mechanism. The patient’s electronic medical record is protected by the patient’s private key and our protocol provides a real anonymous design for the patient possessing absolute autonomy over their privacy. Our mechanism ensures that only the certificate authority center knows the real name of the patient and the corresponding transmission location, and no one else knows it; therefore, it may achieve true anonymity. The secret token is updated every time, i.e., the pseudonym is different every time, so patients can individually control their own electronic medical records and use them safely in telehealth environments. In this study, each update of the cloud medical records is patient-led and performed in a secure tunnel. Our proposed mechanism has strict security controls over either in the telehealth process or in the storage and renewal process. As such, our proposed security analysis guarantees comprehensive security and anonymity protection during telehealth data and privacy transmission.