An Anonymous Authenticated Key Agreement Scheme for Telecare Medical Information Systems

Abstract

With the rapid development of information technology from one side and the experience of the COVID-19 pandemic from the other side, people presently prefer to access healthcare services remotely. Telecare Medical Information System (TMIS) provides more flexible, faster, and more convenient e-healthcare services available to all people, particularly those who lack access to physicians due to their geographical restrictions. However, due to the sensitivity of medical information, preventing unauthorized access to patient data and preserving patient privacy is crucial. In this paper, we propose an authenticated key agreement scheme for TMIS to preserve the privacy of the patient’s identity from all internal (even the health server and the physician) and external entities. Moreover, the physician’s identity is kept secret from all external entities. Formal and informal security analysis of the proposed scheme indicates that it is secure against all attacks in the context.

1. Introduction

The TMIS uses various technologies, including communication networks and computer science, to provide extensive medical services related to remote consultations. Providing TMIS is an innovative invention that can save many lives. With TMIS, patients can use medical advice on-site, even at home, saving both the patient’s time and money. In addition, the recent worldwide spread of diseases, such as COVID-19, has made remote services a priority for users. Currently, TMIS is undergoing rapid development and includes three main parties: medical staff, users/patients, and medical servers. A server in the TMIS is responsible for registering patients, physicians, nurses, laboratories, etc., as well as issuing medical smart cards for patients. Patient’s medical information, such as body temperature, blood pressure, blood sugar, etc., is maintained on the server. By registering the TMIS, physicians can access the server’s medical data. Maintaining a secure data-transfer process is particularly important due to the sensitivity of medical data [1,2,3].

Due to the advancement of engineering knowledge in various fields, many sensitive tasks that humans directly perform are now handled by engineering systems. An example of this is the use of the Internet of Things (IoT) to monitor a person’s health, receive information from the patient, and send it to the physician [4]. Several features are crucial in this field. It is first necessary to design a reliable communication system so that data are correctly recorded and sent to the physician. Patient health can be compromised by changes in the exchanged data or by blocking data transfer. However, a person’s medical data are considered confidential information, and a patient is usually interested in keeping them private and not sharing them with a third party. Hence, to design an application system, it is necessary to maintain the anonymity of the patients while authenticating them as legitimate patients. Considering the abovementioned issues and the importance of secure communication in various TMIS, so far, scholars have proposed several solutions achieving the following security goals and operational features in their mind:

• The confidentiality of data is protected against external attackers and the server.
• For data exchange, the Internet serves as the communication platform.
• Authentication is performed on each device connected to the network as part of the protocol.
• Data integrity is verified by the physician.
• A central core (server) of the system is responsible for registering new entities (for example, physicians and patients) and assisting them with authentication and key agreement.
• Patient Identity (ID) is protected from external attackers.

Motivation. Medical information is usually considered to be of great importance, and many patients, especially office holders, politicians, and celebrities, are very sensitive about their privacy and the confidentiality of their medical data. For example, disclosing their illness to neighbors, colleagues, and the press can jeopardize their jobs and social status. They are worried about the disclosure of their disease information not only by external attackers but also by health system employees, including privileged insiders with special access to the database of the health system and even the treating physician himself. So, they may prefer even the treating physician not to be informed of their true identity. The proposed scheme of this article provides not only the privacy of the patient but also the privacy of the doctors (physicians) so that the patient identity is not disclosed to any entity inside the medical system or outside it. In addition, the identity of the doctors is also kept confidential from the eyes of entities outside the system.

Our Contribution. In the context of privacy in TMIS systems, all previous studies aim to provide anonymity and unlinkability of the patient against the external adversary. In this paper, we propose an authenticated key agreement scheme that extends the domain of privacy for the TMIS in two aspects.

(1) The patient ID is protected not only against external adversaries but also from internal entities, including the physician and even the medical server.

(2) The physician identity is also protected against external attackers.

Paper Outline. The rest of this article is organized as follows. A brief review of related work is provided in Section 2. In Section 3, the system model and prerequisites of elliptic curve cryptography are introduced. Then, the details of the proposed protocol are explained in Section 4. The formal and informal security analysis is reviewed in Section 5, and the efficiency analysis of the proposed scheme is given in Section 6. Finally, the paper is concluded in Section 7.

2. Related Work

Many research studies have been conducted on authentication and key agreement schemes in medical systems in recent years. Several anonymous authentication schemes for Wireless Body Area Networks (WBANs) are presented in [5]. As part of this study, the Network Manager (NM) database is used to store authentication data, which is stored in a protected and secure location. This scheme has the disadvantage that it does not consider any authentication services between the local server and body sensors, and the authentication occurs only between the mobile device as the patient data recorder and other entities, such as the server [6].

An authentication protocol for healthcare systems that use wireless sensor networks is described in [7]. This protocol allows legitimate users to modify passwords without consulting trusted authorities and revoke invalid network nodes. However, the analysis of this scheme has demonstrated that it does not provide forward secrecy and has a high computational cost that does not correspond to real-life scenarios.

A protocol is proposed in [8] to improve the authentication scheme proposed in [9]. A key objective of this scheme is to ensure user anonymity and prevent password-guessing and replay attacks. This scheme does not provide data integrity and key freshness, as shown in [10].

The authors of the paper [11] propose a secure and lightweight authentication scheme using Wireless Multimedia Sensor Networks (WMSN) for remote patient monitoring. To ensure forward secrecy, the proposed scheme uses a hash function mechanism and a pseudonymous ID solution to ensure user anonymity. This study is vulnerable to offline dictionary attacks and has a flaw in the password change phase [12].

A mechanism for secure authentication and key agreement between resource-constrained medical devices is proposed in [13]. Despite its efficiency in terms of computational overhead and run time, the protocol has some security vulnerabilities. During all sessions, the same key is used for communication, so if revealed, then the security of the system collapses completely [14].

In paper [15], a lightweight and efficient authentication protocol for WMSNs is proposed, which meets the basic security requirements and prevents attackers from tracking users. The protocol described in [15] does not provide integrity, and its computational overhead is relatively high [11].

A healthcare system architecture is introduced in [16], followed by a protocol designed to maintain anonymity and conduct mutual authentication for mobile phone users to record sensor data. It has been claimed by the designers of this protocol that it is resistant to known attacks. However, several shortcomings of this design have been discussed in [17]. The studies in [17] show that this protocol is vulnerable to password-guessing and impersonation attacks.

Although Ref. [17] proposes a remote user authentication protocol for WMSNs, but Refs. [11,12] have shown that it may not be as secure as claimed, and it lacks forward secrecy, has a flaw in the password change phase, and is insecure against insider, desynchronization, and offline dictionary guessing attacks.

A WMSN authentication protocol using symmetric keys is proposed in [18]. The proposed protocol in this study has a small computational overhead. It has been concluded in [15] that the protocol described in [18] is vulnerable against offline password-guessing and secret key disclosure attacks, in addition to the sensor node capture attacks [19].

In paper [20], a lightweight Radio-Frequency Identification (RFID) authentication protocol is proposed. The paper claims that the protocol can effectively prevent the disclosure of sensitive medical information. However, the study presented in [21] demonstrates that this scheme is unable to meet all security requirements and is susceptible to secret key disclosure, impersonation, and tracking attacks. It is also shown that the protocol does not ensure the anonymity of the tag.

The authors of the paper [21] propose a lightweight and secure authentication protocol for RFID systems that will increase security and privacy in medical IoT systems. Security analysis of the proposed scheme demonstrates its resistance to desynchronization, replay, tag/reader impersonation, and tracking attacks. In paper [22] shows that the protocol has serious security flaws through key disclosure and tracking attacks.

A lightweight authentication scheme is described in [23], designed for sensors attached to clothing. This scheme allows users to authenticate wearable devices and portable terminals and creates a session key between them. This scheme does not consider the connection between the cloud server and the mobile phone [24]. The use of a biometric factor as one of the authentication factors is proposed in [25]. This scheme was developed to overcome shortcomings in the protocol described in [26]. The authors claimed that this scheme enhances security while maintaining computational efficiency in comparison to other protocols. However, the protocol proposed in [27] is insecure against sensor compromised and insider attacks [27]. An authentication scheme for anti-counterfeit drugs using the IoT is proposed in [28], which is used to verify the authenticity of medicinal items. Near-field communication (NFC) is used in this scheme, which makes it suitable for mobility. In [29], it was shown that this scheme could not resist denial-of-service attacks and eavesdropping.

The authors of the paper [30] first addressed the security requirements of Body Sensor Networks (BSN). Following that, a secure medical care system based on the IoT has been introduced using BSN. It fails to consider the user anonymity and is susceptible to password-guessing and man-in-the-middle attacks [19].

An improved method for creating a mutual authentication scheme for telehealth care systems for patient monitoring is described in [31]. Also, revocation and re-registration of users are considered when a smart device is lost or stolen. As shown in [32], this scheme has several disadvantages, including sensor node capture attacks and a lack of forward secrecy.

The authors of the paper [33] describe a protocol that allows users to access cloud services anonymously. The goal is to provide a solution that allows users to be confirmed by the central system, allowing them to use the services while keeping their profile hidden simultaneously. Simulated results indicate that it has a low computational cost compared to other anonymous authentication schemes. Based on the investigation carried out by the authors of this study, it is apparent that in the proposed protocol of [34], the two points of the elliptic curve are multiplied together, while the multiplication of points is not defined in the elliptic curve, and as a result, the proposed protocol is incorrect.

A lightweight anonymous authentication scheme is presented in [34]. To verify the authenticity of a user before accessing cloud services, anonymous mutual authentication is provided between the user and the server. Cloud users or service providers are evicted from cloud environments if any misbehavior occurs after successful mutual authentication by a third party with a reliable revocation mechanism. Upon review of the proposed protocol, the author of this study finds that, contrary to the authors’ assertions, user anonymity is not respected in the mentioned protocol.

In paper [35], a privacy-preserving protection scheme for patients is proposed. It assumes that all major entities in the healthcare system (such as sensors, gateways, and application providers) are unreliable. The suggested scheme utilizes a Privacy-Preserving Deep Neural Network (PPDNN) to enable secure and privacy-preserving data transmission and storage. In the proposed scheme, end-to-end privacy is claimed to be protected against both internal and external threats. While maintaining patients’ anonymity, this scheme provides mutual authentication between the main entities so that only authorized users can access the patient’s real identity and their location and health care records. Based on simulation results, the protocol proposed in this study is secure against attacks such as impersonation, duplication, modification, and man-in-the-middle. However, the author of this paper has reviewed the protocol and found that although the confidentiality of the user ID is taken into account, the physician’s user ID is not hidden and can be identified through wiretapping. To solve this problem in our research, in the proposed scheme, the IDs of the physician and the patient are encrypted in all stages of information exchange, and it is not possible to access them.

Chen proposes an anonymous authentication and key agreement scheme based on elliptic curve cryptography that uses a temporary identity to protect patient privacy [36]. To use medical services, a new user must first send his/her information, including username and password, to the server over a secure channel. After checking the received information, the server provides the user with a smart card containing the patient information, which is used in the following stages of communication and contains the patient information. As a next step, the authentication protocol must be implemented to communicate between the patient and the server. Patient information, including usernames, passwords, and biometric data, is input into the smart device, and if the input data are confirmed, a message with the patient information is sent to the server. Simulation results indicate that the proposed protocol is secure against replay attacks, man-in-the-middle attacks, and denial-of-service attacks.

An authentication scheme for patient and physician medical systems is described in [37]. This scheme leverages time stamps to prevent replay attacks. The proposed protocol provides the patient with an intelligent device that records the patient information and sends it to the physician, and the authentication operation takes place between this device and the server. Since the patient’s biometric data are not used, a password-guessing attack can be conducted if the device is lost. Even though the proposed protocol allows the patient to change the password, this is not a safe process [38].

The proposed protocol in [39] only considers the authentication between the patient and the server. The proposed protocol allows the attacker to impersonate the physician or patient. This makes it vulnerable to spoofing attacks [38].

Another research conducted in paper [40] presents a lightweight and anonymity-preserving user authentication scheme for IoT-based healthcare systems. A combination of elliptic curve cryptosystem and hash functions are used to achieve the desired security and privacy properties. The suggested scheme is designed to minimize the communication and computation costs for both the user and the server. Furthermore, the scheme provides anonymity and unlikability to the user using an anonymous identifier and a non-invertible hash function. The security and performance of the suggested scheme are evaluated and compared with existing schemes. The results indicate that the suggested scheme is more secure and efficient than existing schemes.

Moreover, Ref. [37] presents an Identity-Based Anonymous Three-Party Authenticated Protocol (IBATPAP) for IoT infrastructure. The suggested IBATPAP protocol is designed to provide secure authentication and access control in IoT environments. It is based on a three-party authentication model, which consists of a trusted authority, a service provider, and a user. The suggested protocol provides identity-based authentication, as well as anonymity for the user, and is resilient against various attacks. The suggested protocol is analyzed for security, and its performance is evaluated using various security metrics. The results show that the suggested protocol provides strong security and performance guarantees.

In another study by [41], an attempt has been made to design a secure scheme for exchanging information between the patient and the doctor using three factors: biometric factor, smart card, and storing sensitive identity information using Physical Unclonable Function (PUF) technology. But [42] shows that the designed protocol has weaknesses, including being vulnerable to impersonation attacks and DoS attacks. In

Table 1. Comparison of reviewed papers (P1: Resistance against Denial-of-Service Attack, P2: Resistance against Man-in-the-Middle Attack, P3: Resistance against Modification Attack, P4: Resistance against Replay Attack, P5: Resistance against Impersonation Attack, P6: Forward Secrecy, P7: Shared key Generation, P8: Untraceability, P9: Anonymity of Patient against Internal Entities, P10: Anonymity of Patient against External Attacker, and P11: Mutual Authentication), (√: the security feature is satisfied, and -: security feature is not satisfied).

Ref.	P1	P2	P3	P4	P5	P6	P7	P8	P9	P10	P11
[5]	-	√	√	√	√	√	√	√	-	√	√
[7]	√	√	-	√	√	-	√	√	-	√	√
[8]	-	√	√	√	√	√	√	-	-	√	√
[11]	-	-	-	√	√	√	√	√	-	√	√
[13]	-	√	√	√	√	√	√	√	-	√	√
[15]	-	√	√	√	√	-	√	√	-	√	√
[16]	-	√	√	√	-	√	-	√	-	√	√
[17]	-	√	-	√	√	-	√	-	-	-	√
[18]	√	-	-	√	√	-	√	-	-	√	√
[20]	√	-	-	√	-	√	√	-	-	-	√
[21]	-	-	-	√	√	√	√	-	-	-	√
[23]	√	√	-	√	√	-	√	√	-	√	√
[25]	√	-	-	√	√	-	√	√	-	-	√
[28]	-	√	-	√	√	-	√	-	-	√	√
[30]	-	√	√	√	√	-	√	-	-	-	√
[31]	√	√	√	√	√	-	√	√	-	√	√
[35]	-	√	√	√	√	-	√	√	-	√	√
[39]	-	-	√	√	√	-	√	-	-	√	√
[40]	√	√	√	-	√	-	-	-	-	√	√
[37]	-	√	-	√	-	-	√	√	-	√	√
[41]	-	√	√	√	-	√	√	√	-	√	√
[43]	-	-	√	√	√	-	√	-	-	√	√
Our	√	√	√	√	√	√	√	√	√	√	√

, the characteristics of the discussed articles are reviewed.

3. Preliminaries

In this section, first, we introduce the system model and the typical entities involved in the TMIS systems. Then, we recall preliminaries from the elliptic curve cryptography.

3.1. System Architecture

Figure 1 shows a general overview of the desired architecture. TMIS contains the following entities. Server: It is responsible for registering physicians and patients and, after anonymous authentication of each member, allowing them to access the service. Physician: Authenticated by the server, the physician will access the medical information of an anonymous patient and prescribe medicine and treatment. To securely send medical history or documents to the physician, the patient and physician must agree on a key. Patient: The patient will be able to send his information to the physician after anonymous authentication by the server. The patient identity is hidden from attackers, physicians, and even the server. As we will see in Section 5, in our proposed scheme, in order to provide anonymity of the patient against the medical server, we replace this server with two non-colluding entities called supervisor and gateway.

3.2. Elliptic Curve Cryptography

An elliptic curve E over the prime field $GF\left(p\right)$ is defined as the set of all points $(x,y)$∈${\mathbb{Z}}_p$×${\mathbb{Z}}_p$ that fulfill the equation $y^2=x^3+ax+b$ mod p, where $a,b$∈${\mathbb{Z}}_p$ and $4a^3+27b^2\ne$ 0 mod p. These points, together with a unique point, called the point at infinity, with a special point addition operator, form an abelian additive group. Over this group, the elliptic curve discrete logarithm problem (ECDLP) and the elliptic curve Diffie–Hellman (ECDH) problem are defined, and both are assumed to be computationally intractable. This assumption brings about public-key cryptographic applications for elliptic curves.

ECDLP: Given the two points P and $Q=xP$, where x∈${\mathbb{Z}}_p$, over the elliptic curve E, the ECDL problem is to find x.

ECDH Problem: Given the three points P and $Q_1=xP$, and $Q_2=yP$, where $x,y\in {\mathbb{Z}}_p$, over the elliptic curve E, the ECDH problem is to find $xyP$.

4. The Proposed Scheme

In this section, we describe the details of the proposed authenticated key agreement for TMIS. In general, the goal is to develop a protocol for authenticating and establishing a key agreement for remote medical care system that preserves privacy, in the sense that the identity of the patient is kept hidden from all internal and external entities, and the identity of the physician is hidden from external attackers. In the design of our proposed protocol, we inspire the idea of using an entity called supervisor from [35]. Also, the use of pseudonyms is borrowed from the research [40]. The proposed protocol utilizes an anonymous identifier, different for each session, to identify the user and let him use the system and services. It is impossible to authenticate the patient directly, so a supervisor is used instead. The physician can only confirm the authenticity of the patient with the help of the gateway and does not have access to any other information.

Table 2. Symbols used in the proposed protocol.

Symbol	Description
$PI{D}_P^n$	The nth pseudonym for the patient P
$R_P^n$	The nth random number generated by patient P
$\tau$	Time to send the message
$I{D}_P,I{D}_G,I{D}_D,I{D}_S$	The identity of patient, gateway, physician and supervisor
$X_P^n,P_P^n$	The nth private key and public key pair for the patient P
$P_G,P_D,P_S$	The public key of gateway, physician and supervisor
$X_G,X_D,X_S$	The private key of gateway, physician and supervisor
G	A generator of the group G of the elliptic curve elements
E	The group of elliptic curve points of prime order q
$V_{SP}^0$	The secret generated by the supervisor and shared by the patient
$V_{PS}^0$	The secret generated by the patient and shared by the supervisor
$V_{SG}$	The secret generated by the supervisor and shared by the gateway
$V_{GS}$	The secret generated by the gateway and shared by the supervisor
$V_{DG}$	The secret generated by the physician and shared by the gateway
$V_{GD}$	The secret generated by the gateway and shared by the physician
$h(·):{\{0,1\}}^{*}$→${\mathbb{Z}}_q^{*}$	A cryptographic hash function
⊕	XOR operation
‖	Concatenation of two strings
$\mathsf{\Delta }$	Maximum allowed time difference between sending and receiving messages
Left(x)	The left half part of string x

contains the symbols that appeared in the proposed method.

4.1. Setup Phase

In the setup phase, all entities agree on a common generator of the group of elliptic curve points, denoted by G. In this case, the public key is equal to $Pu=XG$, where Pu ∈{$P_P^n,P_G,P_D,P_S$} and the corresponding private key is X∈{$X_P^n,X_G,X_D,X_S$}. We proceed with the registration step. In general, the proposed scheme consists of two phases: registration and authentication. During the registration phase, the necessary information for each party is generated and stored for later use. Then, in the authentication stage, the stored information is utilized to verify the authenticity of each party, thus allowing them to communicate with one another. The registration process consists of three steps including (1) patient registration in the supervisor, (2) gateway registration in the supervisor, and (3) physician registration in the gateway. The steps of the proposed scheme are explained below.

4.2. Registration Phase

The registration is performed through secure channels between the two involved entities.

Registration of a Physician at the Gateway In this step, as shown in Figure 2, the physician with the identity $I{D}_D$, chooses a random $X_D$∈_R${\mathbb{Z}}_q^{*}$ as his private key and computes the corresponding public key $P_D$ = $X_D$G. Then he computes the long-term key to be shared by the gateway as $V_{DG}$ = $h(X_D$‖$P_G$) and sends the pair ($V_{GD},I{D}_D$) to the gateway through a secure channel. The gateway stores $V_{DG}$ and $I{D}_D$, and reciprocally computes $V_{DG}$ = $h(X_G$‖$P_D)$ and sends it back to the physician. Finally, the physician stores $V_{GD}$.

Registration of a Patient at the Supervisor In this step, as shown in Figure 3, two secrets $V_{PS}^0$ and $V_{SP}^0$ are exchanged between the patient and the supervisor, which are used for authentication in the next step. Also, at this stage, the supervisor saves the patient’s anonymous identity $I{D}_P$. The anonymous identifier helps the patient to use the system without being identified.

Registration of the Supervisor at the Gateway In this step, as shown in Figure 4, two secrets, $V_{SG}$ and $V_{GS}$, are exchanged between the supervisor and the gateway, which will be used for authentication in the next steps. With the help of the supervisor, the gateway will be able to confirm that the patient is using the system services.

4.3. Authentication and Shared Key Generation

The general architecture of the proposed authenticated key agreement scheme including registeration, authentication and session key generation steps has been illustrated in Figure 5. The details of the authentication and session key agreement has been shown in Figure 6 and is described below.

Step 1: The patient first saves the current time ${\tau }_1$, then generates a new random $R_P^{n+1}$${\in }_R$${\mathbb{Z}}_q^{*}$ to let the supervisor update the anonymous identifier ${PID}_P^{n+1}$ = ${ID}_P$⨁$R_P^{n+1}$ in the next steps (each anonymous identifier is used only once). If the patient uses a fixed public key in all stages, the patient identity can be recognized in general, so at this stage the patient generates a new public and private key to use in the current session, i.e., it chooses $X_P^n$∈_R${\mathbb{Z}}_q^{*}$ as his nth private key and computes $P_P^n$ = $X_P^{n}G$ as the corresponding public key. In order to be able to send confidential messages between the patient and the supervisor, as well as between the patient and the gateway, two shared keys $K_{PS}^n$ and $K_{PG}^n$ is created, which are obtained by multiplying the patient’s nth private key by the public keys of the supervisor and the gateway and passing it through the hash function. In order to enable the supervisor to authenticate the patient, the $V_{SP}^0$ stored in the registration stage and $R_P^{n+1}$ are encrypted by $K_{PS}^n$ as $data3$ = ($V_{SP}^0$‖$R_P^{n+1}$) ⨁$K_{PS}^n$. Moreover, the current anonymous patient identity $PI{D}_P^n$ along with his desired physician identity $I{D}_D$ is encrypted by the key $K_{PS}^n$ as $data1=(PI{D}_P^n$‖$I{D}_D$) ⨁$K_{PG}^n$. Finally, the $data1,data2$, and $data3$, along with the time of sending the message, ${\tau }_1$, and the nth public key of the patient, $P_P^n$, are sent to the gateway.

Step 2: The gateway extracts the current time $\tau$, then the time delay between sending and receiving the message is calculated as ${\tau }_2$ − ${\tau }_1$. If this value is longer than a desired threshold $\mathsf{\Delta }$, the gateway aborts. Otherwise, it computes the shared key $K_{PG}^n$ = $h(X_G{P}_P^n$) and decrypts $data1$ to obtain the patient’s anonymous identity $PI{D}_P^n$ and the physician identity $I{D}_D$. It checks the integrity of ${\tau }_1$, $I{D}_D$ and $K_{PG}^n$ through $data2$. Considering that the gateway is not able to directly authenticate the patient, it uses the supervisor to confirm the service to the alleged patient. For this purpose, it computes $data4$ = $h(V_{SG}$‖${\tau }_3$‖$data3$‖$P_P^n$‖$PI{D}_P^n$ ) and sends it along with $data3$, $P_G$, $P_P^n$, $PI{D}_P^n$, ${\tau }_3$ to the supervisor.

Step 3: After receiving the message from the gateway, the supervisor first examines the time of sending the message and then, using the shared key $V_{SG}$, verifies the freshness and the authenticity of $data4$. Moreover, using its private key and the public key of the patient, it produces the shared key $K_{PG}^n$ he needs to decrypt the received $data3$ as $V_{SP}^{0\prime }$‖$R_P^n$ = $data3$⨁$K_{PS}^n$. If $V_{SP}^{0\prime }$ equals the pre-shared $V_{SP}^0$, then it authenticates the patient and computes and stores his new anonymous identity as $PI{D}_P^{n+1}$ = $I{D}_P$⨁$R_P^{n+1}$. Finally, it sends a true message to the gateway indicating patient confirmation.

Step 4: The gateway first checks the freshness of the received message $m_3$ by checking if ${\tau }_6$−${\tau }_5$ < $\mathsf{\Delta }$, where ${\tau }_6$ is the time it received $m_3$, then, it generates the $data5$ and compares it with the received $data5$ to check the integrity of $m_5$ received from supervisor. Then, it sends a communication request message $m_4$ = ($data6$, $P_6$, $Request$, ${\tau }_7$), where $data6$ = $h(V_{DG}$‖$Request$‖${\tau }_7$) to the physician with identity $I{D}_D$.

Step 5: The physician first checks the time of receiving the message $m_4$ and then authenticates the gateway through recomputing $data6$ using the pre-shared key $V_{DG}$. If the draft information is correct, he sends a message $m_5$ containing the preparation for data exchange along with the information required for authentication to the gateway as $m_5$ = ($data7,P_D,ready$, ${\tau }_9$), where $data7=h(V_{GD}$‖$ready$‖${\tau }_9$).

Step 6: After receiving the notification of readiness from the physician and checking the time of the sent message as well as authenticating the physician, the gateway sends the messages $m_6$ and $m_7$ about the start of the session to the patient and physician, respectively. Here, as in the previous steps, the information about the time of sending the message is also sent along with the information required for authentication.

Step 7: Finally, based on the information received from the gateway, the physician and the patient will generate the shared session key $K_S$ = $h(P_P^n$‖$P_D$‖$P_G$‖$K_{PD}^n$), where $K_{PD}^n$ = $h(X_P^n{P}_D$) = $h(X_D{P}_P^n$) and will be able to exchange data with each other.

5. Security Analysis

This section shows that the proposed anonymous authenticated key agreement scheme provides the claimed security requirements. First, it is informally shown that the proposed scheme resists the attacks known in the context and provides security features such as anonymity and unlinkability. Then, the ProVerif tool is employed to formally and automatically verify the security properties of the proposed protocol.

5.1. Informal Security Analysis

In this section, we intuitively investigate the security features of the proposed authenticated key agreement scheme. These features include patient anonymity, physician anonymity, untraceability, resistance to well-known attacks such as man-in-the-middle, impersonation, replay, message modification, and eavesdropping.

Resistance to the Impersonation Attack: In this type of attack, the attacker impersonates herself as a valid entity, such as a patient, physician, gateway, or supervisor. In the proposed scheme, the patient and supervisor have two pre-shared symmetric keys $V_{SP}^0$ and $V_{PS}^0$. Also, the supervisor with the gateway and the gateway with the physician pre-share some symmetric keys. Moreover, a pair of entities, such as the patient and the gateway, who do not already have a shared key, can create a shared key using the Diffie–Hellman elliptic curve method as $K_{PG}^n=h\left(X_P^n{P}_G\right)=h\left(X_G{P}_P^n\right)$, where $X_P^n$ is the short-term private key of the patient and $P_P^n=X_P^{n}G$ is his corresponding public key, and $X_G$ is the long-term private key of the gateway and $P_G=X_{G}G$ is its corresponding public key.

The messages sent from each entity to the desired receiver are accompanied by the keyed hash, the key to which is the common key of the receiver and the sender so that its authenticity can be verified in the receiver. In addition, placing the time stamp inside the MAC also guarantees the freshness of the messages. Because the attacker does not have the common key of the receiver and the sender of the messages, it cannot create a valid MAC for his messages and cannot convince the receiver to accept it. Therefore, the proposed scheme is safe against impersonation attacks.

Resistance to the Replay Attack: In this attack, the adversary eavesdrops and stores some messages of the sessions of the protocol and later tries to reuse them to impersonate some entity involved in the protocol. However, all the exchanged messages $m_1$, $m_2$, …, $m_7$ incorporate timestamps, and the receiver of these messages checks the freshness of the received message by checking if the message has been received within a permitted delay time $\mathsf{\Delta }$. Therefore, the proposed scheme is secure against replay attacks.

Resistance to the Denial-of-Service (DoS) Attack: Suppose an adversary tries to launch a DoS attack by sending a new message $m_1$. The only part of $m_1$ that the adversary cannot compute is $dat{a}_3$, which includes the long-term key $V_{SP}^0$ pre-shared by the supervisor and the patient. Therefore, the gateway cannot authenticate the sender of m₁ by itself and must forward it to the supervisor who initially authenticate the origin of data₃. Since the adversary does not know $V_{SP}^0$, it cannot generate valid $dat{a}_3=(V_{SP}^0$‖$R_P^{n+1}$) ⨁$K_{PS}^n$. So the DoS attack is prevented by supervisor in Step 3 of the protocol. On the other hand, to pass the consistency checks done by the gateway over data₁ and data₂ in Step 2, the adversary is obliged to completely perform the computations of Step 1, including computing new short-term keys $X_P^n$, $P_P^n$, $K_{PS}^n$, $K_{PG}^n$ as well as $dat{a}_1$, $dat{a}_2$ and $dat{a}_3$. These computations impose more overhead on the adversary compared to the computations done by the gateway in Step 2. Therefore, the proposed scheme is not vulnerable to DoS attacks.

Resistance to the Message Modification Attack: In this attack, the adversary tries to modify some messages such that valid entities accept the modified messages. In the proposed scheme, any modification can be detected by the receiver, as the integrity of all messages $m_1$, $m_2$, …, $m_7$ is guaranteed by a keyed hash function, where the key used in the hash is a key shared between the valid sender and receiver of that message.

Resistance to the Eavesdropping Attack: All messages sent over the line are one of the five types of hash values, timestamps, public keys, pseudo-identities (such as $PI{D}_P^n$), and data XOR-ed with the shared key of the receiver and sender. Therefore, listening to the channel does not reveal any useful information to the attacker.

Resistance to the Tracking Attack: To check the patient traceability, first note that the only message the patient sends is $m_1$, which contains $data1=(PI{D}_P^n$‖$I{D}_D$) ⨁$K_{PG}^n$, $data2=h(K_{PG}^n$‖${\tau }_1$‖$I{D}_D$), $data3=(V_{SP}^0$‖$R_P^{n+1}$) ⨁$K_{PS}^n,P_p^n$ and ${\tau }_1$. The $K_{PG}^n$ and $K_{PS}^n$ are updated in each session independently of the previous session. Therefore, the values of $m_1$ are completely independent from one session to another, and the eavesdropping attacker is unable to distinguish whether the users participating in two sessions are the same or not. Therefore, the traceability of the patient is maintained. Moreover, as the doctor identity, $I{D}_D$, is protected by XORing through the one-time key $K_{PG}^n$, the eavesdropper cannot distinguish if the same physician is contacted in two sessions or not.

Resistance to the Man-in-the-Middle Attack: In the proposed protocol, each pair of valid receivers and senders of the messages $m_1$, $m_2$, …, $m_7$ have a common symmetric key, which is used to verify the authenticity of the message and the authenticity of the sender at the receiver. In addition, the freshness of all messages is guaranteed due to the use of a time stamp. Therefore, the attacker cannot block a message in the middle of the way and replace his desired message or a previously eavesdropped message.

Patient Anonymity: In the proposed protocol, the patient identifies himself anonymously and only to the supervisor. For this purpose, the patient proves that he has a common key with the supervisor, say $V_{SP}^0$, by sending $data3=(V_{SP}^0$‖$R_P^{n+1}$) ⨁$K_{PS}^n$ through the gateway to the supervisor. Thus, the supervisor, although sure that the patient is the same patient who shared the $V_{SP}^0$ key with him during the registration phase (since the patient’s real identity was not registered during the registration phase), is not informed of the patient’s real identity. On the other hand, the gateway can only access the patient’s pseudo-Identity, $PI{D}_P^n$, by decrypting $data1=(PI{D}_P^n$‖$I{D}_D$) ⨁$K_{PG}^n$. However, this disposable pseudo-ID does not reveal any information about the patient’s true identity at the gateway. The only information the doctor acquires about the patient is his short-term public key, the $PI{D}_P^n$, which has been implicitly confirmed by the gateway and the supervisor. So, the doctor does not obtain the true identity of the patient. The external attacker information is less than the gateway and supervisor information, so the patient identity remains confidential from the external attacker point of view. Therefore, neither internal entities nor external attackers will be able to understand the patient identity.

Physician Anonymity: The doctor identity, $I{D}_D$, is encrypted with the common key of the patient and the gateway as $data1=(PI{D}_P^n$‖$I{D}_D$) ⨁$K_{PG}^n$ and then is sent over the channel. It is only the gateway that is able to decrypt $data1$ and know the identity of the doctor. The external attacker cannot decrypt $data1$, and therefore, the identity of the doctor remains hidden from the external attacker.

5.2. Formal Security Analysis Using ProVerif Tool

To verify the security of the proposed protocol against known attacks such as replay, message modification, impersonation, and offline password-guessing attacks, and to check the security properties such as patient anonymity and Perfect Forward Secrecy (PFS) property, we use the ProVerif tool as one of the most powerful automatic cryptographic protocol verification tools. In Figure 7, the first result is related to the confidentiality of the session key, whose confidentiality has been proven. The second to fifth results show the resistance of the proposed protocol against the offline password-guessing attack. The sixth result is an injection correspondence claim, which confirms the resistance of the proposed protocol against replay, impersonation, injection, and message modification attacks. Finally, the last case shows the anonymity of the patient.

In Figure 8, to show that the proposed protocol provides the PFS property, we first use the command $\left((!P)\right|(!S)\left|(!GA)\right|(!D)\left|(phase1;out(puCh,(X_D,X_G,X_S,I{D}_P)))\right)$, in which we reveal the long-term key information to the attacker and then check the confidentiality of the session key. The result of ProVerif execution for this option confirms the PFS property for the session key between the patient and the physician.

6. Efficiency Analysis

To check the efficiency of the proposed scheme, in this section, the number of calculations required for each entity has been checked. In the proposed method, the four operations of random number generation, XOR operation, hash function evaluation, and scalar multiplication are used in different steps. The calculation of execution time of each of the functions has been calculated realistically in various research, including in the articles [35,44]. The execution time of each mathematical operation based on two different processors is shown in

Table 3. Execution time.

Operation	Description	Execution Time on NanoPi	Execution Time on Intel Core-i7
${\mathrm{T}}_{RN}$	The execution time of random generation	Negligible	Negligible
${\mathrm{T}}_{XOR}$	The execution time of XOR operation	Negligible	Negligible
${\mathrm{T}}_{hash}$	The execution time of SHA256 (64 bytes)	2.4 $\mathsf{\mu }$s	447 ns
${\mathrm{T}}_{mul}$	The execution time of ECC point	475 $\mathsf{\mu }$s	46 $\mathsf{\mu }$s
${\mathrm{T}}_{add}$	The execution time of point addition operation (SECP 160R1)	2 $\mathsf{\mu }$s	192 ns
${\mathrm{T}}_{ENC}$	The execution time of public-key encryption -160bit ECDSA (SECP 160R1)	600 $\mathsf{\mu }$s	61 $\mathsf{\mu }$s
${\mathrm{T}}_{DEC}$	The execution time of public-key decryption -160bit ECDSA (SECP 160R1)	2100 $\mathsf{\mu }$s	228 $\mathsf{\mu }$s

with symbols $T_{RN}$, $T_{XOR}$, $T_{hash}$ and $T_{mul}$.

In the proposed scheme at the registration stage, the patient will have one ${\mathrm{T}}_{XOR}$, two ${\mathrm{T}}_{RN}$ and one ${\mathrm{T}}_{hash}$ time for execution, and the doctor requires one ${\mathrm{T}}_{XOR}$ and six ${\mathrm{T}}_{XOR}$. Of course, it should be noted that the registration stage is often done offline or in turn, so the execution time of the scheme is less important.

In the authentication and information exchange stage, the patient uses 4 XOR, one XOR, 6 hash functions, and four multiplications. The supervisor uses one XOR, one random number generation, three hash functions, and one multiplication. The multiplication, which in the proposed scheme is responsible for creating a connection between different entities, uses one XOR, eight hash functions, and one multiplication in the total steps, and finally, the doctor runs 4 multiplications and one multiplication.

In calculating the execution time of the schemes, two processors, NanoPi and Core i7-4702MQ, have been investigated. Considering that the Core i7 processor is a professional processor, it is used in entities that perform more calculations, so it is assumed that the gateway and supervisor are implemented with Core i7-4702MQ. On the other hand, the doctor and the patient will not need a powerful processor and, for example, they should be able to communicate with the system and receive medical services with hardware such as mobile phones, so the assumption that these two entities use the NanoPi processor is a realistic assumption. The number of calculations required by each of the entities is shown in

Table 4. Computation overhead of the proposed scheme.

Phase	Computation Overhead	Computation Time
Registration
Patient	1 × ${\mathrm{T}}_{XOR}$ + 2 × ${\mathrm{T}}_{RN}$ + 1 × ${\mathrm{T}}_{hash}$	2.4 $\mathsf{\mu }$s
Physician	1 × ${\mathrm{T}}_{XOR}$ + 6 × ${\mathrm{T}}_{hash}$	2.4 $\mathsf{\mu }$s
Authentication and data transmission
Patient	4 × ${\mathrm{T}}_{XOR}$ + 1 × ${\mathrm{T}}_{RN}$ + 6 × ${\mathrm{T}}_{hash}$ + 4 × ${\mathrm{T}}_{mul}$	1900 $\mathsf{\mu }$s
Supervisor	3 × ${\mathrm{T}}_{XOR}$ + 1 × ${\mathrm{T}}_{RN}$ + 3 × ${\mathrm{T}}_{hash}$ + 1 × ${\mathrm{T}}_{mul}$	47.341 $\mathsf{\mu }$s
Gateway	1 × ${\mathrm{T}}_{XOR}$ + 8 × ${\mathrm{T}}_{hash}$ + 1 × ${\mathrm{T}}_{mul}$	49.576 $\mathsf{\mu }$s
Physician	4 × ${\mathrm{T}}_{XOR}$ + 1 × ${\mathrm{T}}_{mul}$	475 $\mathsf{\mu }$s

.

Calculating the energy required for data exchange is another parameter that is useful in comparing the efficiency of schemes provided by different researchers. Using more bits in information exchange means more energy is needed to send information. In

Table 5. Comparison of the related schemes (CM: Cluster Member, SC: Smart Card, MD: Mobile Device, CH: Cluster Head, CC: Communication Cost).

$\mathbf{Scheme}$	$\mathbf{CM}/\mathbf{SC}/\mathbf{MD}$	$\mathbf{CH}/\mathbf{Server}$	$\mathbf{CC} \left(\mathbf{bits}\right)$
[45]	5${\mathrm{T}}_{hash}$	9${\mathrm{T}}_{hash}$	1856
[46]	4${\mathrm{T}}_{hash}$	2${\mathrm{T}}_{hash}$	1728
[35]	6${\mathrm{T}}_{hash}$	6${\mathrm{T}}_{mul}$ + 2${\mathrm{T}}_{hash}$ + 2${\mathrm{T}}_{add}$ + 2${\mathrm{T}}_{ENC}$ + 1${\mathrm{T}}_{DEC}$	7040
Proposed	6${\mathrm{T}}_{hash}$ + 4${\mathrm{T}}_{mul}$	11${\mathrm{T}}_{hash}$ + 2${\mathrm{T}}_{mul}$	6208

, different schemes presented by different researchers are compared with the proposed scheme. It is necessary to explain that the results of the article of [44] were used to check the schemes of other researchers.

In Table 5, ${\mathrm{T}}_{add}$, ${\mathrm{T}}_{Mul}$, ${\mathrm{T}}_{ENC}$, ${\mathrm{T}}_{DEC}$, and ${\mathrm{T}}_{hash}$ are the execution times of point addition operation, EC point multiplication, public-key encryption, public-key decryption, hash operation, and symmetric encryption/decryption, respectively. In Table 5, for the proposed method, the information related to the patient is written in column CM, and the sum of the computational complexity of the gate and supervisor is written in column CH.

As can be seen in Table 5, although the proposed protocol has many features, such as being resistant to all types of attacks, and the structure of the proposed scheme is designed in such a way that patient information remains completely private, the computation overhead required for each entity, compared to most other protocols, is a small amount and this feature indicates that this protocol can be implemented with cheap processors. On the other hand, the number of sent and received bits has been calculated in order to check the energy consumption. It is important to note that usually, in other research, it is assumed that the information is sent to the physician by the sensor, considering that the sensors usually depend on the energy of small batteries to receive the patient information and recharge the battery can be a challenging task for the patient.

Sending and receiving less information saves energy and is of great importance in the efficiency of the scheme, but in the proposed scheme, information is sent by the patient to the physician, and for this purpose, the patient usually uses a computer or mobile phone. Moreover, other entities, such as the gateway and supervisor, are connected to the city electricity, so there is no energy consumption challenge in the proposed scheme, and the proposed method can be properly implemented. In addition, based on

Table 6. Details of the communication overhead of the proposed scheme in bits.

m1	m2	m3
data1 = 256 b	data3 = 256 b	data5 = 256 b
data2 = 256 b	data4 = 256 b	data6 = 128 b
data3 = 256 b	${\mathrm{P}}_G$ = 320 b	${\mathrm{P}}_s$ = 320  b
${\mathrm{P}}_p^n$ = 320 b	${\mathrm{PID}}_p^n$ = 128 b	True= 32 b
${\mathrm{t}}_1$ = 32 b	${\mathrm{t}}_3$ = 32 b	${\mathrm{t}}_5$ = 32 b
m4	m5	m6
data7 = 256 b	data8 = 256 b	data9 = 256 b
d${\mathrm{P}}_G$ = 320 b	${\mathrm{P}}_D$= 320 b	data6 = 128 b
Request = 32 b	Ready = 32 b	${\mathrm{P}}_G$ = 320 b
${\mathrm{t}}_7$ = 32 b	${\mathrm{t}}_9$ = 32 b	${\mathrm{P}}_D$ = 320 b
		Start = 32 b
		${\mathrm{t}}_{11}$ = 32 b
m7
data10 = 256 b
${\mathrm{P}}_G$ = 320 b
${\mathrm{P}}_p^n$ = 320 b
Start = 32 b
${\mathrm{t}}_{11}$ = 32 b

, the number of bits sent by the patient through message $m_1$ is equal to 1120 bits, and the number of bits through message $m_6$ is equal to 1088 bits. Based on the source [47], the average energy sent and received is 4.28 $\mathsf{\mu }$J/bit and 2.36 $\mathsf{\mu }$J/bit, respectively, which means The consumption is 2567 microjoules, which is a small number considering the capacity of today’s batteries, which shows that this scheme can be easily used in the implementation of sensor-dependent systems.

Table 7. Checking the energy consumption on the sensor/patient side (Communication Cost: CC, Energy Consumption: EC, assuming MICA2 sensor board with 3 V and 8 mA).

$\mathbf{Scheme}$	$\mathbf{CC}\mathbf{on}\mathbf{the}\mathbf{Sensor}/\mathbf{Patient}$	$\mathbf{EC}\mathbf{for}\mathbf{Communication}$	$\mathbf{EC}\mathbf{for}\mathbf{Computations}$	$\mathbf{Total}\mathbf{Energy}\mathbf{Consumption}$
[45]	Transmit data: 384 an Receive data: 672	3.23 mJ	0.446 mJ	3.676 mJ
[35]	Transmit data: 544 and Receive data: 384	3.23 mJ	0.533 mJ	3.673 mJ
Proposed scheme	Transmit data: 1120 and Receive data: 1088	7.36 mJ	0.045 mJ	7.405 mJ

shows a more detailed comparison of the energy consumption on the patient side between several studies with the proposed protocol. It is worth mentioning that in other studies reviewed in this table, the sensor receives the patient information and sends it to the physician.

As shown in Table 7, the energy consumption on the patient side in the proposed scheme is more than the schemes proposed in other research, which is due to the implementation of a method in which all patient information remains confidential. However, as mentioned earlier, in the proposed scheme, due to the use of the computer on the patient side in order to send information to the physician, low energy consumption is not a high priority.

7. Conclusions

Maintaining confidentiality and establishing secure communication in a public channel are two challenges of using online medical services. This research proposes a security protocol that protects the identity of the physician against external entities and the identity of the patient from all entities involved in the protocol, thus ensuring privacy. In the proposed scheme, the patient messages are first checked by a supervisor, and if approved, the gateway sends the messages to the physician. The physician is unaware of the patient identity, but the patient knows the physician identity. The reason for this design is to allow treatment services for patients who prefer to remain anonymous, even to the doctors. Another feature of the proposed scheme is that, compared to the authentication and key agreement schemes that use extra hardware such as Physical Unclonable Functions (PUFs), our scheme requires the patient and the doctor only to have a smart-phone or laptop. With the widespread use of smart-phones and laptops, it does not impose extra costs on patients and doctors at all. In addition, formal analysis and informal investigation of the proposed scheme show that it is secure against a variety of attacks in the context.