An Authentication Protocol for the Medical Internet of Things

: The progress in biomedical sensors, Internet of Things technologies, big data, cloud computing, and artiﬁcial intelligence is leading the development of e-health medical systems, offering a range of new and innovative services. One such service is remote patient monitoring, where medical professionals are able to collect and examine a patient’s medical data remotely. Of course, in these systems, security and privacy are of utmost importance and we need to verify the identities of system users before granting them access to sensitive patient-related data. To this end, several authentication protocols have been recently designed speciﬁcally for e-health systems. We survey several of these protocols and report on ﬂaws and shortcomings we discovered. Moreover, we propose an authentication protocol that enables a medical professional and the network of sensors used by a patient to authenticate each other and share a cryptographic key to be used for security in a communication session. The protocol also enables the dynamic assignment of patients to doctors in order to control access to patients’ data. We perform a security analysis of the protocol both formally, using the ProVerif protocol analysis tool, and informally, demonstrating its security features. We show that our protocol achieves mutual authentication, secret key establishment, forward secrecy, and anonymity. In terms of performance, the protocol is computationally lightweight, as it relies on symmetric key cryptography. This is demonstrated by comparing the computational cost of our protocol (in terms of execution time) with that of other similar protocols.


Introduction
An aging population and an increasing number of persons living with multiple chronic conditions are factors currently exerting pressure on healthcare systems worldwide [1]. There is a growing need for healthcare staff and for efficient and effective systems to support them. This need is even more critical during emergency conditions such as those present during the COVID-19 pandemic. The digital transformation in the healthcare sector offers ways to improve the quality of medical services and to support medical staff. It provides a spectrum of solutions commonly referred to as "digital health" or "eHealth" [2]. For instance, assisted living technologies [1] make use of biomedical sensors [3], internet connectivity, and software applications to monitor health conditions of patients while they are at home. Sensors collect real-time medical data that are sent to medical centers to be stored in Electronic Health Records (EHRs) for analysis by doctors, possibly with the help of AI-based decision support systems. Thus, treatment can be decided, emergencies can be avoided and the need for hospitalization reduced, alleviating pressure on medical facilities and staff. The objective is to enable patients to live independently while receiving quality healthcare services at home.
have not been previously reported. These weaknesses may lead to attacks that compromise security. We demonstrate several of these attacks. This paper is organized in five sections starting with the introduction. In Section 2, we survey the state-of-the-art in authentication protocols for the MIoT and present some weaknesses that we discovered in these protocols. This is followed by the presentation of our own protocol in Section 3 and its performance and security analysis in Section 4. Finally, the paper is concluded in Section 5.

Previous Work
Communication in MIoT can be classified into intra-BAN, inter-BAN, and beyond BAN [12]. Intra-BAN communication takes place between sensor nodes in the WBAN, including the sink. Inter-BAN communication is between sinks in different WBANs, possibly through relay nodes or access points. Finally, beyond-BAN communication occurs with remote parties in the cloud.
Security issues in intra-BAN communications overlap those in sensor networks [13]. There are, however, some characteristics that are particular to intra-BAN networks, based on the fact that they are composed of nodes placed in or on a human body. For instance, in these networks, physiological signals can be used for authentication and key agreement [14]. Similarly, security issues in inter-BAN and beyond-BAN communications overlap those in IoT networks [9]. However, inter-BAN and beyond-BAN networks have special features and requirements since they are used in medical applications. These applications involve three parties: patient, doctor, and medical center (server). They deal with medical data which are of sensitive nature requiring privacy policies. Furthermore, patients need to be dynamically assigned to doctors and access to patients' data must be controlled. Hence, a security mechanism for medical applications must take all these factors into account. Our authentication protocol focuses on beyond-BAN communication. We therefore survey protocols with the same scope and exclude protocols dealing solely with inter-BAN and intra-BAN communication such as the one developed by Das et al. [15].

Protocols
Authentication protocols for beyond-BAN communication differ in the following aspects: • Security objectives besides authentication, e.g., key establishment, forward secrecy [16], etc. • Communicating parties, i.e., the roles involved in a protocol session. • Support for real-time communication. • Design logic, cryptographic operations (encryption, hashing, etc.), and execution steps.
In the work of Yeh [17], an authentication and key establishment protocol is designed with three communicating parties: sensor node, gateway (called local processing unit) and server. There is no mention of medical professionals connecting to the server. Therefore, it is implicitly assumed that doctors will read patients' data in the offline mode, i.e., there is no possibility of monitoring a patient in real time. The protocol uses Elliptic Curve Cryptography (ECC) [18] whose computational cost is around an order of magnitude higher than symmetric encryption [19,20]. We will therefore limit our attention to protocols using symmetric cryptography.
Gope and Hwang [20] designed an authentication and key establishment protocol between a user U, a gateway G and a sensor node SN, where user anonymity is targeted. In their terminology, a gateway is actually a "server-class" device that connects users to multiple clusters of sensors. Traffic between sensors in a cluster and an external party passes through a sink node, called the cluster head. The protocol uses only two mathematical operations: secure hashing and XOR. However, the protocol does not account for the case where readings from multiple sensors are aggregated, e.g., by the cluster head. Furthermore, we discovered a serious flaw that lets an intruder, at one session, know the key established in the previous session, as will be detailed in Section 2.2.2.
The authentication protocol by Li et al. [21] is designed for three communication parties: the medical professional (user U), the gateway node G of the patient's WBAN and a single sensor in the WBAN. The protocol targets user and sensor anonymity with respect to the intruder. It uses hashing and symmetric encryption/decryption, where a single key is shared between multiple parties. This use of keys means that the compromise of a single key compromises communication with all users or sensor nodes. Furthermore, users are required to register themselves at the patient's WBAN gateway node, i.e., a doctor responsible for N patients will have to register N times which is impractical. We also note that the gateway G stores no information about users, it therefore has no means of differentiating between users for access control purposes.
A study by Sharma and Kalra [22] proposed a mutual authentication and key establishment protocol between a user U who is a medical professional, a patient's WBAN gateway node G, and a single sensor in the WBAN. The protocol aims to achieve forward secrecy and user anonymity with respect to the intruder. The only mathematical operations used are XOR and hashing. The sensor's ID is sent in clear text in the first message from the user U to the gateway G, and therefore sensor anonymity is not achieved. Furthermore, an intruder monitoring a doctor's messages will relate the doctor's identity to a sensor's identity which can be linked to a patient's identity by monitoring the gateway. Moreover, the gateway does not store information related to specific users and therefore is unable to differentiate between users leading to infeasibility of access control. Finally, the gateway stores only the value of a long-term secret key K which is used to create secrets shared with users and sensors. Therefore, if the value of K is compromised, the security of all communications is also compromised.
The paper by Xu et al. [23] presents a protocol between a server, an access point (acting as WBAN gateway), and a single sensor node. There is no mention of the authentication process between a medical professional and the server. The protocol uses only hashing and XOR operations, its goal is to provide mutual authentication and session key establishment between the server and the sensor node while preserving forward secrecy. A single longterm sever key k ser is used for communications with all sensor nodes. Therefore, if k ser is compromised, the whole network is compromised, and no procedure is given to renew k ser . A later work by Park et al. [24] found the protocol vulnerable to node capture attacks where an intruder may capture a sensor node and read plain text values stored in it. The proposed solution is to encrypt values stored in sensors using keys derived from a user's ID and password. However, sensor nodes are not usually equipped with user interfaces for login purposes, and a remote login requires the design of yet another protocol. Moreover, the proposed protocol fails to achieve forward secrecy. This is because it computes session keys K s as a hash value, and all inputs to the hash function can be easily computed if the server key k ser is known.
Shin and Kwon [25] developed an authentication protocol that is executed between user U, a gateway G and a sensor node SN. A gateway is actually a "server-class" device, and sensors are grouped into clusters, where a cluster may be the WBAN of a patient. The protocol uses only hashing and XOR operations, and three-factor authentication of users. Zhu et al. [26] analyzed the protocol and discovered that it fails to provide forward secrecy and may also be vulnerable to offline password-guessing and desynchronization attacks. Desynchronization occurs when a shared variable, between two or more parties, has a different value at each party. This may be due to incomplete sessions, which we discuss in Section 2.2.5. Zhu et al. also proposed a modified version of the protocol, which we discuss in Sections 2.2.1, 2.2.2 and 2.2.5.
A lightweight mutual authentication and key agreement protocol is presented by Soni and Singh [27]. It is executed between patients and servers in medical centers, so that a patient's data can be securely stored on a server. The protocol uses hashing and XOR. It is, however, vulnerable to offline password-guessing attacks and does not mention authentication of doctors to servers or how to implement access control policies.
The work by Shreya et al. [28] presents a mutual authentication and key agreement protocol between a user (doctor), medical cloud server, and IoT gateway. The gateway collects data from medical sensors to be read by medical staff. The protocol uses symmetric encryption/decryption, hashing, and XOR operations. However, it is vulnerable to offline password guessing. Furthermore, if a single secret session key is known by the intruder, he will be able to obtain all previous and future session keys, as we report in Section 2.2.2.

Discovered Weaknesses
In the following, we present weaknesses discovered in the surveyed protocols, and we group these weaknesses according to their root cause. We use h(·), ⊕, and , to denote cryptographic hash functions, the XOR operation, and the concatenation operation, respectively. Furthermore, discovered attacks on surveyed protocols which are presented in the current section, in addition to the analysis presented in Section 2.1 are summarized in Table 1. Table 1. Summary of the analysis of surveyed authentication protocols.

Protocol Comments
Yeh [17] ⇒ If an intruder knew the value of one session nonce, he will be able to compute values of nonces in other sessions.
Gope and Hwang [20] ⇒ Communication with a single sensor per session (no support for data aggregation). ⇒ Attack: value of previous session's key can be known. ⇒ Off-line password attack is possible. ⇒ Desynchronization is possible.
Li et al. [21] ⇒ Single key shared with all users. ⇒ No differentiation between users leads to infeasibility of access control. ⇒ Doctors have to register themselves with each patient. ⇒ Off-line password attack is possible.
Sharma and Kalra [22] ⇒ Sensor's anonymity is not achieved. ⇒ No differentiation between users leads to infeasibility of access control. ⇒ Single key shared with all users.
Xu et al. [23] ⇒ Communication with a single sensor per session (no support for data aggregation). ⇒ Single key shared with all users. ⇒ If an intruder knew the value of one session nonce, he will be able to compute values of nonces in other sessions.
Park et al. [24] ⇒ Sensor nodes are required to provide a local login interface to users, which is impractical. ⇒ Protocol fails to achieve forward secrecy.
Shin and Kwon [25] ⇒ Protocol fails to provide forward secrecy. ⇒ Protocol is vulnerable to desynchronization attacks.
Soni and Singh [27] ⇒ Offline password-guessing attack is possible. ⇒ No mention of authentication for doctors.
Zhu et al. [26] ⇒ Attack against anonymity is possible. ⇒ Denial of service attack against sensors is possible. ⇒ Off-line password attack is possible. ⇒ Desynchronization is possible.
Shreya et al. [28] ⇒ Offline password-guessing attack is possible. ⇒ If a secret session key is known, all previous and future session keys can be known.

The Use of XOR for Secrecy
In various reviewed protocols, when a secret value x needs to be sent, it is XORed with a key K or a hash value h(m), i.e., it is sent as x ⊕ K or x ⊕ h(m). This is secure as long as multiple secret values x 1 , x 2 , . . . x i , . . . are XORed with a random or pseudo-random stream of keys such as in the Vernam or RC4 ciphers [18]. If, on the other hand, multiple values are XORed with the same key (or hash value), then secrecy is compromised. Consider, for instance, the case where we need to send two secret values x 1 and x 2 , and they are sent as c 1 = x 1 ⊕ K and c 2 = x 2 ⊕ K, respectively. Now an intruder sees c 1 and c 2 and performs the operation c 1 ⊕ c 2 = x 1 ⊕ x 2 . If the intruder knows x 1 , he can easily compute x 2 , and vice versa, without having to know the key. In fact, in the case of more than two plain text messages, if the intruder knows only one of them, he can easily compute all the other ones. A protocol with this weakness is the one by Yeh [17], where the message M 1 = h(K i bs i ) ⊕ N i is sent in each session by sensor i. The value N i , which is a nonce freshly generated each session, is secret. It is, therefore, XORed with the hash value, which is constant an all sessions. Therefore, if the intruder is able to know the value of one nonce, he will be able to compute the values of all other nonces. Another example is the protocol by Xu et al. [23]. At the start of the authentication session between a sensor node and the server, a secret nonce r is sent encrypted by the server key K ser . All nonces from all sensors in all sessions are sent encrypted by the same key K ser . Therefore, if the intruder was able to know the value of a single nonce, she can easily compute all other values.
We discovered that the improper use of XOR for encryption leads to an attack against anonymity in the work of Zhu et al. [26]. The protocol attempts to hide the identity of users using pseudonyms. During a session, the pseudonym is sent in clear text inside messages and is used to identify the user in the current session. At the end of each session, user U i is assigned a new pseudonym PID 1 i to be used in the next session. Therefore, an intruder reading two messages sent in different sessions will not be able to decide if these messages have the same sender or not, since the pseudonym is changed in each session. For this scheme to work, PID 1 i should be sent secretly. Otherwise, the intruder will be able to relate the current pseudonym with the next one, and having a dynamic pseudonym will be useless. In fact, PID 1 i is sent secretly by XORing it with a secret value privately known by the user. In the following, we demonstrate a multi-session attack, which enables an attacker to relate a value of the pseudonym to the next one. We use subscript i for user U i and superscripts 1 and 2 to denote two consecutive sessions, e.g., PID 1 i and PID 2 i are the pseudonyms secretly sent to user U i in some session and the next one, respectively. Values that do not change from one session to another are written without superscripts. We focus on the last message to be received by U i in a session. This message contains two fields: p 1 i and T 1 , where T 1 is a timestamp that is sent in clear text. Knowing that , the intruder can execute the computation: Then, after the next session, the intruder can i . Therefore, knowing PID 1 i , the intruder will know PID 2 i . In fact, PID 1 i is sent in clear text during the next session and this way the intruder will be able to know that the sequence of pseudonyms PID 1 i , PID 2 i , . . . belongs to the same user. This attack is possible even though the intruder does not know the value of H ID i which is secretly assigned to the user during registration to the system.

Missing Secrecy of some Messages
In some protocols, values that should be secret are sent as clear text. For instance, in the protocol by Gope and Hwang [20], a user U is assigned a sequence number TS UG which is updated at the end of the authentication session by a new value TS new UG . Therefore, at the end where K UG is a secret key shared between U and G, ID U is the user's hidden identity and N U is a secret nonce. This way TS new UG is kept secret from intruders. Furthermore, G generates a session key SK and sends it to U secured inside the message SK = h(K UG ID U N U ) ⊕ SK. If an intruder knew TS new UG , he can easily compute TS ⊕ TS new UG = h(K UG ID U N U ) now the intruder can compute the session key SK = SK ⊕ h(K UG ID U N U ). In fact, this attack will take place since at the start of session i + 1, U will send TS UG in clear text to G (TS new UG of session i is TS UG of session i + 1). This way at the start of session i + 1 the intruder will able to know the session key of the previous session i.
Furthermore, in the protocol by Zhu et al. [26], a gateway G sends requests to some sensor S j . In the request, a value NG j is sent in clear text to the sensor, and if the value is above some threshold, the sensor will not respond to the request. The idea is to save the sensor's resources according to some protocol logic. The problem is that NG j is not encrypted nor protected against modification. Hence, an intruder can easily read and modify (e.g., increment) its value without being detected, thereby executing a successful denial of service attack.
In the work by Shreya et al. [28], the session key is computed as The first three hash values can be known by the intruder using publicly sent messages. In Step 7 of the protocol's description, the message Mg 10 = CID Mg 3 is sent in clear text over the channel from gateway node to user node, where . Obviously, this enables the intruder to know the current values of h(CID), h(RN 1 ), and h(RN 2 ). The value SK EN = ID N S k does not change from one session to another. Therefore, if the intruder was able to know the value of a single session key SK, he will be able to compute h( . The intruder will therefore be able to compute all previous and future session keys provided that he knows the message Mg 10 of these sessions.

Ambiguous Definition of Anonymity
Anonymity is defined as the inability of an observer to link an action to the identity of an agent (a communicating party) [29]. An action in our setting is mostly the sending or receiving of a message and the observer is either an honest communicating party or the intruder. Therefore, for instance, sender anonymity is an inability to link the sent message to the identity of an agent. Here, the observer may be the intruder but it may also be the agent receiving the message. Another example is relationship anonymity [30] which involves both the sending and receiving of a message. Therefore, we may know which agent sent a message and which one received it but we are unable to know who is communicating with who. Various published authentication protocols claim to provide anonymity [22], yet they fail to clarify what type of anonymity they mean and with respect to which observer.

Smart Cards Vulnerable to Offline Password Guessing
Humans are authenticated based on what they know (e.g., a password), what they have (e.g., a smart card), or what they are (e.g., a biometric) [18]. We can combine two or three of the aforementioned authentication factors to have two-factor or three-factor authentication, respectively. The purpose is to avoid known weaknesses when relying on passwords only, especially given that humans tend to choose passwords that they can easily remember, which are generally low-entropy and vulnerable to dictionary attacks. Some of the protocols we have reviewed use smart cards for authenticating users to servers in a way that is vulnerable to offline password-guessing attacks. In these attacks, the intruder guesses a password and is able to verify the correctness of their guess offline, i.e., without communicating with the server. They are thus more serious attacks than online password guessing in which the server is alerted with each unsuccessful login attempt and may disable the user account after a predetermined number of failed logins. In the following discussion, we assume that the intruder has access to the user's smart card and biometric information (if used by the protocol) and is trying to guess the user's passwords.
In the protocol by Gope and Hwang [20], the user inputs an ID and password to the smart card which verifies the password and sends a login request to the server only when the password is correct. Hence, an intruder can execute multiple offline password-guessing attempts and immediately know if the guess is correct or not by monitoring whether the smart card sends a message or not. The same argument applies to both the protocol by Zhu et al. [26] and the one by Li et al. [21], where the smart card does not communicate with the server unless the login attempt is a valid one. The main cause in all the previous cases is that the verification of the user's identity is made by the smart card without communicating with the server. An intruder in possession of the smart card is able to access its storage in order to read values, execute code, and read the code's output even under the assumption of tamper-resistant cards [31]. It is therefore necessary not to store clear-text data or code on the smart card that will enable the intruder to decide the correctness of a guessed password.

Renewal of Some Values Each Session
Some cryptographic keys are long-term, i.e., they are used for a period of time that spans multiple sessions, others are ephemeral, i.e., they are established in a session to be used in this session only. Prior to running any authentication sessions, long-term keys need to be preloaded into communicating devices using a secure channel. Thereafter, these keys are used in cryptographic operations to securely establish session keys. Long-term keys are not renewed at each session but every n sessions. Usually, they also need to be renewed using special communication steps. This is particularly important in unreliable networks where message loss may occur. Assume we need to renew a long-term key K AB between nodes A and B and the new key is K AB . One of the nodes, say A, updates K AB and sends a message m to B, which should update K AB upon receiving m. If m is lost, A and B will be desynchronized since A will store K AB , while B will still have K AB . Therefore, the renewal process must ensure that, by its end, both agents will agree on the value of the key, either new or old. In the case of session keys, this problem is not a major issue because when the session key could not be established for any reason, A and B can just start a new session as long as they agree on the values of long-term keys.
The protocol by Gope and Hwang [20] renews long-term keys in the communication steps of each session. An example is the key K gs shared between the network's gateway G and a sensor S. This key is used to encrypt the session key SK when it is sent from G to S. The sensor S renews K gs , then sends its last message m l in the current session to G. After receiving this message, G renews the value of K gs and now the new value will be used in the next session. Therefore, if m l is lost or blocked by the intruder, G and S will end up having different values of K gs . This situation will make future sessions impossible.
Moreover, Zhu et al. [26] propose a protocol that avoids desynchronization of the values of a variable PID shared between a user U and a gateway G. Their solution to the desynchronization problem is to save a copy of the old value of PID at the gateway. This way, at the next session, if U uses the old value, G will still be able to recognize it. However, in their protocol, the communication between G and a sensor node S is not protected against desynchronization. The value of a secret X sj shared between G and S is updated at G overriding the old value, then G sends a message m to S. Upon receiving m , S updates its own copy of X js . The message m contains the value of a counter NG j that is stored at G and incremented by an amount (value n j ) each time G sends message m . Another counter N j is kept at the sensor S, and, upon receiving NG j , S computes the value N = (NG j − N j )/n j . Then, S updates X js N times and sets N j = NG j . This way, even if the intruder blocked m multiple times, S will be able to re-synchronize its values with G. As we mentioned in Section 2.2.2, the problem is that NG j is not encrypted nor protected against modification. Therefore, an intruder can easily change its value and desynchronize G and S.

Our Protocol Design
In this section, we present our protocol for mutual authentication between a doctor (or healthcare professional) and the IoT gateway that relays a patient's data to the cloud. Therefore, we focus on beyond-BAN communications. Besides authentication, We aim to achieve the following objectives: 1.
Fresh session key establishment.
We assume the presence of an active intruder I able to perform the following actions [18]: Such an intruder is capable of executing many types of attacks [10], such as reflection attacks, replay attacks, etc. This is a common model where it is assumed that the intruder has total control over the network.

Network Architecture
The network environment where the protocol runs is depicted in Figure 1. This setting is used, for instance, in applications where doctors need real-time access to data collected from patients. Data are examined by doctors for purposes of diagnosis or follow-ups. We identify the following principals that take part in protocol execution:

•
The doctor (or healthcare professional) identified by U, for user. • The doctor's smart card device, given identification D.  A smart card device (identified by D) is used at the doctor's side to enable doctors to log in from any machine as long as it is equipped with a smart card reader. Furthermore, using a smart card, we are able to implement three-factor authentication: possession of the smart card, biometric recognition, and knowledge of a secret password. Moreover, by executing the protocol with the WBAN's gateway, instead of a single sensor, we enable the monitoring of several sensors in a single session since the gateway may aggregate traffic from multiple sensors. This is beneficial in medical settings where a doctor needs to check values of multiple physiological parameters. In addition to the previous advantages, our protocol gives the server S the ability to dynamically assign patients to doctors. Therefore, S may grant a doctor the right to read a patient's data collected by the gateway from sensor nodes, or it may revoke this right, as will be explained in Sections 3.2 and 3.3. Finally, the protocol uses symmetric cryptographic algorithms [18] as they are more efficient than asymmetric ones in terms of computational cost, storage, and energy [19]. Algorithms with a small footprint are preferable in our situation since gateways and smart card devices are usually resource-limited devices. The use of symmetric cryptography implies that, initially, values of secret keys need to be shared offline or via a secure channel. In the following sections, we present the initialization process, followed by the description of the authentication steps. Then, we demonstrate how to renew long-term secret keys and passwords. We will make use of the symbols listed in Table 2.

Initialization and Registration
During initialization, both the doctor and the patient are required to register with the server S. To initialize a doctor's smart card device D, the doctor registers at the server S as user U by choosing an identification I U , and a secret password P U . At the same time, the doctor's biometric template data B U , such as a fingerprint or facial image, is captured. The server now computes the value of a key K U = h(I U h(P U H(B U ))). In this computation, h(·) is a cryptographic hash function, e.g., MD5, and H(·) is a biohash function [32,33]. A biohash is a one-way function used for Biometric Template Protection (BTP) [34], i.e., given the function's output H(B U ), it is unfeasible to obtain the biometric template B U . Moreover, the biohash function has two properties that make its use advantageous. First, it uses a random value as a parameter. The advantage is that if the intruder knew the value H(B U ), another function H (·) could be constructed with a different value of the random parameter, and we will obtain a different output for the same biometric template, i.e., H(B U ) = H (B U ). Second, the output H(B U ) is invariant with respect to rotation, translation or scaling of the captured biometric image [33].
The server, then, generates a secret key K DS and the following code and data are loaded on D: • Code: A cryptographic hash algorithm h(·), a bio-hash algorithm H(·), an encryption algorithm e(·, ·), and a decryption algorithm d(·, ·). • Data: A device identifier D, and the encrypted value {K DS } K U . As a user record, server securely stores D, I U , K DS . At the patient's side, patient A registers at the server S, when being provided with the necessary sensors needed for remote monitoring. Sensors are attached to A's body, and they form a WBAN where one sensor node will act as IoT gateway. The gateway is loaded with an identity G and a secret key K GS that is shared with S. The patient's record at the server securely stores the tuple G, I A , K GS , thereby associating the identity G of the gateway to that of the patient (I A ).
The initialization phase is finalized by the server S assigning patients to doctors. When a doctor U finishes registration, S loads the value L i=1 G i , N Si K DS into the doctor's smart card D. Each tuple G i , N Si represents an assignment to a patient (gateway G i ), so that the doctor is now authorized to monitor the patient's data. Each nonce N Si , generated by S, is a unique identifier for this assignment. It also serves as indicator that the assignment is still current, and as defense against replay attacks, as will be shown in the description of authentication steps. All tuples are also saved in the doctor's record on the server S, so that the server keeps record of which patient is assigned to which doctor. We note that all data exchanged during registration with the server are assumed to be communicated via secure channels. By the end of the registration phase, we have the following configuration: • The server's user record stores D, The server's patient record stores G, The doctor's smart card device D stores h(·), H(·), e(·, ·), d(·, ·), D, The patient's IoT gateway G stores G, K GS

Authentication Steps
When the initialization phase has been completed, authentication can be executed. This starts with a doctor U inserting their smart card device D in a reader and entering their ID I U and password P U . Furthermore, their biometric B U is captured. The smart card computes the value of the key K U = h(I U h(P U H(B U ))) and is able to obtain the value of K DS if K U = K U . Consequently, the list of gateway ID's L i=1 G i , N Si is obtained by decrypting the corresponding cipher text, and the doctor is prompted to choose one of their patients to monitor. Then, a sequence of communication steps is executed between the smart card device D, the server S and the IoT gateway G on the patient's body. These steps are shown in Figure 2. Interaction between protocol parties is also illustrated in Figure 3. and verifies that the first field in the decrypted message is D. Now the server checks the set of stored values L i=1 G i , N Si to verify that the doctor is authorized to monitor the gateway G and also to check N S for freshness. If all checks are successful, S executes step 2.
In step 2, S sends the message m 2 = {G D N D } K GS to G, where the values G, D, and N D are those previously received in m 1 . When G receives m 2 , it decrypts it, and verifies that the first field is its own identity. Then it proceeds to step 3 where it generates a fresh nonce N G and sends the message m 3 = G {G D N G N D } K GS to S. When S receives message m 3 , it reads the first field of the message (G) to choose the right key K GS . Then, it uses K GS to decrypt {G D N G N D } K GS and verifies that the first field in the decrypted message is G and that N D is the one previously sent in m 2 . It then proceeds to step 4.

A G S D U
After patient's registration, the patient's ID is linked to gateway G at server.
U inserts smart card into reader Provides ID (I U ), password (P U ) and biometric (B U ) Chooses G when prompted D performs the following: In step 4, S generates a session key K DG and sends the message It is worth noting that if the data requested by the doctor is already stored at the server, then only steps 1 and 4 are executed to achieve mutual authentication between doctor and server. This case is beneficial when a doctor needs to review a patient's historical data that have been previously collected in past sessions. The differentiation between a request for current real-time data and a request for historical data is left as an application implementation issue since it will not affect the abstract data structure of messages.

Renewal of Passwords and Keys
A doctor U may wish to change their password P U . In this case, U inserts the smart card device D into a reader and supplies the old values of the ID, password and biometric: I U , P U , and B U , respectively. The smart card computes the value of the key K U = h(I U h(P U H(B U ))) and decrypts {K DS } K U to obtain K DS . Now the user is prompted to enter the new password P U and the smart card computes the value of a new key K U = h(I U h(P U H(B U ))), which is used to encrypt K DS . The encrypted value {K DS } K U is stored on the smart card instead of the old one. Furthermore, the long-term keys K DS and K GS are used during some time period: an epoch. At the end of an epoch, these two keys are renewed by the server. The new ones (K DS and K GS ), which are generated by the server, will be used in the newly starting epoch. At the doctor's side (smart card device D), m 4 , sent from S to D is modified to include K DS : Upon receiving m 4 , D updates its storage to replace K DS by K DS . Furthermore, to confirm receiving the new key, D replies with another message: When S receives m 6 , it decrypts it using K DS and checks the value of the nonce N D for equality with the one received in message m 1 . If the two values are equal, S replaces the stored value K DS with K DS . At the patient's side, m 5 , sent from S to the IoT gateway G, is modified to include K GS : m 5 = G D N G N D K DG K GS K GS . Upon receiving m 5 , G updates its storage to replace K GS by K GS . Furthermore, to confirm receiving the new key, G replies with another message: When S receives m 7 , it decrypts it using K GS and checks the value of the nonce N G for equality with the one received in message m 3 . If the two values are equal, S replaces the stored value K GS with K GS .

Revocation of Smart Card Device
Sometimes, there is a need to revoke the rights of a smart card device D. For instance, this may be the case if a doctor lost the smart card or if the card was stolen. In this case, at the request of the doctor, a new smart card device D is issued according to the steps detailed in Section 3.2. The new card D will be loaded with a new key K DS , and the old card's identity D and key K DS will be added to a revocation list on the server to indicate their invalidity.

Analysis of Protocol
In this section, we analyze the performance of our proposed authentication protocol. We start by enumerating its features in comparison to the surveyed protocols, then we compare its computational cost to other protocols of similar objectives. We also demonstrate its suitability for smart card devices, with respect to storage requirements. Then, we provide an informal argument about its security, followed by a demonstration of the attacks it resists. Finally, we present a formal security analysis using the protocol verification tool ProVerif [35].

Features and Comparison with Previous Works
Our protocol has the following functional features: F1: Mutual authentication between patient's IoT gateway and server. F2: Mutual authentication between doctor and server. F3: Support for both real-time monitoring of patient's data and offline reading of data from server. F4: Ability to monitor multiple sensors in a single session. F5: Support for dynamic assignment of patient's to doctors. F6: Support for the implementation of an access control policy at the server. Table 3 compares the surveyed protocols with respect to each one of these features. The symbol '_' in a table cell means that the feature (table column) is not applicable for the protocol (table row). Table 3 deals with functional features only, security features are summarized in Table 1. Yeh [17] yes no no no _ _ Gope and Hwang [20] yes yes no no _ _ Li et al. [21] yes yes no no no no Sharma and Kalra [22] yes yes no no no no Xu et al. [23] yes no no no _ _ Park et al. [24] yes no no no _ _ Shin and Kwon [25] yes yes no no _ _ Soni and Singh [27] yes no no yes _ _ Zhu et al. [26] yes yes no no _ _ Shreya et al. [28] yes yes yes yes possible possible Our protocol yes yes yes yes yes yes

Performance Analysis
The computational cost of a security protocol is estimated as the time it takes to execute the mathematical operations of a single protocol run [36]. Since we focus on protocols using symmetric cryptography, these operations are symmetric encryption/decryption and secure hashing. The execution time of a hash function is almost equal to that of symmetric encryption or decryption [19], we denote this time by T f . In Table 4, we compare the computational cost of our protocol with other ones, all during authentication steps. For each protocol, we count the number of operations performed by the protocol's entities (user, server, etc.) and multiply this number by T f .
In Table 4, the symbol '_' in a cell means that this particular protocol does not have the entity indicated by the column. For instance, the protocol by Xu et al. does not have a user role. We also note that we use our notation to describe various protocol roles. For instance, in the protocol by Gope and Hwang, a gateway in their notation is equivalent to our server role. Our protocol In terms of storage requirements, we focus on the resource-constrained devices involved in the protocol. Namely, these are the IoT gateway G and the smart card device D. We assume the size of a single data block (key, cipher text, nonce, . . . ) to be 256 bits (32 bytes). This estimate is based on sizes of data blocks in well-known algorithms. For instance, the Advanced Encryption Standard (AES) has a maximum key length of 256 bits and a cipher block size of 128 bits. The patient's IoT gateway G stores the pair G, K GS , whose size is 64 bytes, which can be easily accommodated in a device of this class. On the other hand, data stored on the doctor's smart card device are: . Their estimated total size is 64 + 64 × L bytes. Smart card devices are equipped with EEPROM storage whose size typically fall in the range between 8 KBytes and 64 Kbytes [37,38]. Thus, the space is enough to accommodate values of L (number of patients assigned to doctor) in the three digit range. Of course, this is more than needed for all practical purposes.

Informal Security Analysis
In this section, we argue that our protocol achieves its desired security objectives, where each objective is discussed in a separate section.

Authentication
Message m 1 can be constructed only by an agent that knows K DS . To obtain K DS , the agent must possess the smart card and must know K U . The key K U is not stored but must be constructed from the user's credentials (ID, password, and biometric). Therefore, m 1 can only be sent after achieving three-factor authentication. Even if an intruder has possession of the smart card and the user's biometric, he will have to guess the password in order to construct K U and hence obtain K DS . To test their guess, the intruder needs to communicate with the server since there is no way of knowing the correctness of their guess offline. By limiting the number of failed logins, we can greatly reduce the intruder's probability of guessing the correct password.
Replay attacks are prevented using nonces. For instance, the server S knows that message m 1 is current from the nonce N S . Furthermore, mutual authentication is achieved by the use of nonces as challenges. Therefore, by message m 1 , server S is assured of the identity of D (and consequently U), since only an agent that knows K DS (and consequently K U ) could have sent m 1 . Similarly, by message m 4 , D is assured of the identity of S, since only an agent that knows K DS could have sent m 4 containing the same nonce N D that was sent inside m 1 in the current session. A similar argument applies to the mutual authentication between S and G.

Session Key
The session key K DG is guaranteed to be fresh by the use of the two nonces N D and N G . It is also secret by its inclusion in encrypted messages. The session key is randomly generated by the server each session and its secrecy is dependent on the secrecy of the long-term keys K DS and K GS .

Forward Secrecy
Assume the long-term keys K DS and K GS were known by the intruder. In this case, the session keys of the current epoch will be revealed to the intruder. However, in any previous epochs the session keys will still keep their secrecy.

Relationship Anonymity
The intruder will not be able to know which doctor U is communicating with which patient A. This is because no direct communication exists between them; each communicates with the server. Furthermore, by monitoring messages only, the intruder is not able to relate messages to users (doctors) or patients since this information is not sent inside messages. In fact, the only identities sent are those of the smart card device D and the gateway G, and it is inside the server that the link is made between D and a doctor's identity, and between G and a patient's identity. However, the intruder may be able to deduce this link (D to doctor or G to patient), for instance, by surveying a doctor while using a smart card D and reading messages sent by D. Nonetheless, this does not constitute a successful attack against relationship anonymity. In particular, no message contains both D and G in clear text.

Access Control
A doctor is allowed access only to designated patients. When a doctor U asks for access to patient A i 's gateway (G i ), the server checks U's record to verify that U has the right to monitor G i . This implies that the doctor has authorization to monitor the data of all sensors communicating with G i . If a more detailed approach is preferred, a doctor may be assigned a role according to specialization. Then, this role determines what data (sensors) the doctor is authorized to monitor. For instance, a cardiologist may be allowed to monitor a different set of sensors than an internist. To implement this role-based access control, we need to modify messages m 2 and m 3 to replace the identity D with the pair D, R , where R is the doctor's role. Furthermore, in this case, the gateway G, will need to implement and access control list specifying which role has authorization to monitor which sensors.

Resistance to Common Attacks
Our protocol resists impersonation attacks by replaying messages due to the use of fresh nonces. It also provides protection in case of smart card loss due to the use of threefactor authentication. Moreover, an intruder cannot mount an offline password-guessing attacks since all of the doctor's credentials are checked online by the server.
Verification results demonstrate that our protocol satisfies its security objectives.

Implementation Issues and Limitations
The first step toward the implementation of our protocol is the investigation of its integration with current implementations of eHealth systems. To facilitate this integration, it is beneficial to adopt an Authentication as a Service (AaaS) framework [40]. Then, we need to investigate the storage requirements in terms of code and data for all protocol entities. This represents no problem at the server where there is no lack of resources. However, the gateway and smart card device are usually resource-limited devices and storage requirements need to be carefully computed. This was performed in Section 4.2, where we analyzed the protocol's performance. Finally, our protocol uses lightweight symmetric cryptography that is easily implemented on resource-limited devices since it does not have extensive computational requirements and thus save energy and resources.
With respect to limitations, our protocol uses a single server which may constitute a bottleneck in communication affecting the system's scalability. It also constitutes a single point of failure. Therefore, as a future research direction, the possibility of having multiple servers should be investigated. Of course, this necessitates synchronizing data between servers, with all the details involved in such a process. Moreover, currently, the patient's IoT gateway is not selective in sending sensors' data to the server. As future work, the gateway should be able to send data only from a subset of sensors in the WBAN. This subset may be determined, for instance, by the specialty of the doctor currently reading the data. This issue falls within the design of an access control policy for doctors.

Conclusions and Future Work
We presented an authentication protocol for remote health monitoring within the MIoT. The protocol is lightweight, secure, and avoids the security weaknesses found in similar previously published protocols. It provides a method to grant authorizations to doctors to monitor specific patients. The communication with the sensors at the patient's side is performed through the IoT gateway which enables the doctor to monitor multiple sensors with a single connection. This is possible because the gateway acts as a sink in the WBAN and is able to aggregate traffic from groups of sensors. Both the security and performance analyses confirm the suitability of our protocol for use in MIoT.
As future work, we may consider having multiple servers instead of a single one. This will increase the system's capacity to handle more traffic, and help improve reliability by avoiding interruptions in case a single server fails. Moreover, access control policies implemented on the server may be investigated. In this regard, there are two main issues: policy design and policy enforcement. A policy is designed to achieve some security objective and is based on some model of system objects (components, files, etc.), system subjects (users, processes, etc.), and actions (read, delete, etc.). It is interesting to see how to design such policies for standard Electronic Health Records (EHRs) [41]. Moreover, implementations of these policies need to be tested in order to make sure that all policy rules are enforced. This is of extreme importance in the medical field where data are sensitive and patient privacy is protected by law.