Mutual Authentication Protocol for D2D Communications in a Cloud-Based E-Health System.

The development of the Internet of Things (IoT) predicts several new applications, some of which are designed to be incorporated into e-health systems, and some technologies, like cloud computing and device-to-device communication (D2D), are promising for use in the support of resource-constrained devices employed in Mobile-health (m-health) and Telecare Medicine Information Systems (TMIS). In a scenario with billions of devices predicted for the IoT, it is essential to avoid performance and security problems, among others. Security is fundamental for the achievement of optimal performance regarding the sensibility of e-health shared data and, especially, the anonymity of patients and other entities, while it is also essential to consider the scarcity of bandwidth in wireless networks. This paper proposes a new mutual authentication protocol for m-health systems, which supports D2D communication, ensuring security and surpassing the performance and security of other authentication procedures reported in the literature.


Introduction
Among the several applications for the development of the Internet of Things (IoT), Electronic-health(e-health)/Mobile-health(m-health) aim at providing health services through information and communication technologies. Such applications include, for example, monitoring by sensors coupled to the body of patients and connected by a wireless body area network (WBAN), diagnosis and remote provisioning of health services to patients over public channels.
The assistance of cloud servers is an alternative to supplying the large demands of storage and processing generated by multiple medical service providers and increasing operational efficiency. In Telecare Medical Information Systems (TMIS), doctors and patients can be assisted by a cloud server; patients send a report containing the sensors' measures to the cloud server and a doctor collects the data, provides diagnosis and finally sends a diagnosis report to the cloud server. Both data exchanges are performed through public channels.
Additionally, the use of cloud servers as auxiliaries to storage and processing in e-health/m-health/TMIS requires special attention, due to the high sensitivity of the information exchanged with the cloud server and the entities involved. Information from the sensor measurements report and patient diagnosis can be crucial for saving lives and must not be accessed or modified by possible attackers.
A good example is the anonymity of entities, since the user of those systems may not be interested in having their identity disclosed. The disclosure of a patient's identity can leave it vulnerable to the action of attackers against his/her life, or the access to personal information. One of the requirements for proper functioning of e-health/m-health/TMIS and other systems for the IoT is reductions in both the consumption of computational and communication resources for energy saving and the congestion In this study, we have considered D2D communication with establishing/managing connection through the cellular infrastructure. Among its advantages are possible offloading between the mobile network and the D2D network, and efficient allocation of the spectrum if inband D2D is used [5]. Therefore, if some information collected by a sensor used by a patient is to be transmitted through a cellular network and indicates an emergency which demands rapid decision and actuation by a physician and/or a health center, D2D communications are an excellent alternative for its rapid transmission.
Moreover, regarding the protocol that uses D2D communications, D2D-based authentication protocols could be especially adapted to m-health architecture, thus reducing delays, dependency on 3GPP core network, and costs of message exchange. This issue has become more relevant because authentication protocols designed by traditional communication systems (e.g., 3GPP Evolved Packet System-Authentication and Key Agreement (EPS-AKA)) are not adequate for common requirements of 5G networks (e.g., higher data rate, low delay, low energy consumption and traffic offloading). Another important characteristic of D2D communication is possible coverage extension (see Figure 1, where a D2D-capable device outside the coverage area of the cellular network can be aided by another device inside that coverage area).

Related Work
Mohit et al. [6] and Chiou et al. [7] considered a cloud server an auxiliary entity that stores patients' data, such as measures collected from sensors coupled to their bodies. Such data are encrypted and transmitted over public channels from the entities involved with the cloud server and vice versa, after the execution of mutual authentication and the generation of a session key. The authors designed protocols based on asymmetric and symmetric cryptography composed of four phases, namely health center upload (HUP), patient upload (PUP), treatment (TP) and checkup (CP). A security analysis that was conducted revealed some issues in the protocol of Chiou et al. [7]. According to Mohit et al. [6], it fails to preserve system anonymity and security if the patient's device is lost or stolen. On the other hand, the protocol of Mohit et al. [5] fails to avoid a denial of service (DoS) attack.
Jiang et al. [8] and Li et al. [9] also developed interesting approaches. Although the protocols considered no auxiliary cloud server (the entities authenticate themselves directly with the health center server through the Internet), they were developed for e-health/m-health/TMIS, similar to our protocol. The proposal of Li et al. [9] is based on asymmetric cryptography, whereas that designed by Jiang et al. [8] is based on symmetric cryptography. Both are composed of three phases in common, namely Initialization, Registration, and Authentication. Li et al. [9] accomplished all the security objectives considered in the security analysis section of this manuscript, while Jiang et al. [8] is vulnerable to the stealing of a patient's device and involve confidentiality issues.
The protocols of Jiang et al. [10], Amin et al. [11] and Shen et al. [12] differ from those of Chiou et al. [7] and Mohit et al. [6] because they consider only the communication channel between the user (patient) and the cloud for security purposes. They also employ asymmetric cryptography based on the elliptic curves discrete logarithm problem (ECDLP) and comprise three phases, namely initialization, registration, and login/authentication. Jiang et al. [10] and Amin et al. [11] accomplished all the security objectives analyzed in this study; however, the protocol of Shen et al. [12] shows some security issues, such as lack of confidentiality and vulnerability to patient trackabillity due to loss/stealing of the patient's mobile device. Finally, the protocols of [6][7][8][9][10][11][12] would better attend m-health requirements if D2D communication was used, because they would require less processing time, use of the device's energy and band usage, reflecting in the reduction of costs.
Gunes et al. [13] proposed a hybrid model for Long Term Evolution (LTE) network-assisted D2D discovery and communication towards the integration of D2D into the 3GPP LTE architecture through the development of a device's direct discovery model and optimization of the establishment of communications. It is based on the Proximity Services (ProSe) standard developed by 3GPP and its security requirements for D2D communication. However, it does not consider m-health adapted architecture and, consequently, would need to receive modifications to guarantee the security necessary for m-health.
Zhang et al. [14] developed an m-health authentication scheme for D2D communication. Based on the ECDLP, it is a certificateless signcryption scheme (CLGSC) that considers the necessity of protecting data from eavesdropping on the relays involved in D2D communication. However, it differs from ours because it does not consider a cloud server an auxiliary in the scheme.
Our protocol uses D2D communication for e-health/m-health/TMIS for enabling the transmission of large amounts of data, such as health reports with images, sound, and video, between devices in a short-range. It can accomplish a high data rate and lower energy consumption in comparison with traditional access technologies (e.g., 3GPP LTE, according to Kar and Sanyal [15]).
The literature reports some authentication and key agreement protocols for D2D communication; however, they are not designed for m-health environments. For example, Wang and Yan [16] developed two authentication protocols for D2D, one based on the hash message authentication code (HMAC) and the other based on identity-based signatures (IBS). Hsu et al. [17] proposed a group authentication protocol for D2D based on identity-based encryption (IBE) and Diffie Hellman key exchange (DHKE).
In terms of standardization activities, 3GPP has started to standardize D2D communication for its network architecture and developed technical reports and technical specifications (TS) Sensors 2020, 20, 2072 5 of 23 (e.g., TS 33.303 [18], TS 23.303 [19] and TR 36.843 [20]), which describe security aspects, device discovery and, configuration for D2D communication. Table 1 shows a comparison among some studies relevant to the design of our protocol. Chiou et al. [7] No Yes Asymmetric Yes Mohit et al. [6] No Yes Asymmetric Yes Jiang and Lian [8] No Yes Symmetric No Li et al. [9] No Yes Asymmetric No Wang and Yan [16] Yes

Proposed Protocol
The proposed protocol is based on challenge-response and was developed as a secure and efficient mutual authentication scheme alternative, without incurring high computational and communication costs. The use of symmetric cryptography may generate security issues due to key exchanges over public channels. However, the proposed protocol does not exchange keys or real identities over insecure channels, as explained in Sections 5.4 and 5.7, and consequently, it is not affected by these problems. We also propose a D2D communication environment, which provides the chance for devices inside the 3GPP network to do data offloading and the connection to devices outside the coverage area to be connected and send their owner's health reports. Figure 1 shows the system architecture, which is composed of a health center, a cloud server, patients with and without sensors, patient's devices, doctors, the 3GPP access technology, the evolved node B (eNB) and the 3GPP evolved packet core (EPC), represented by the home subscriber server (HSS). There are two coverage domains. The first is the device's coverage domain, which is composed of devices located inside the 3GPP coverage area and of devices located outside the coverage area. Patients located outside the coverage area can access the 3GPP network relaying their data through devices located inside the coverage area. The other domain is the 3GPP domain where the doctor is located.
Patients without sensors visit the health center in order to collect identity information to be used in future mutual authentication sessions. The health center must perform mutual authentication with the cloud server prior to sending its patients' data. Patients' devices perform mutual authentication with the cloud server prior to sending the data collected from the respective sensors. Devices with direct access to the 3GPP infrastructure might use it to reach the cloud server. Those devices located outside of the coverage area can execute the mutual authentication using D2D communication, prior to sending health reports. In the second case, the other D2D devices in the path to the cloud server are used as relays. A device with a direct connection with 3GPP infrastructure might choose to send its information through D2D communication to perform data offload, which is not addressed in this work.
Finally, each doctor also has to execute mutual authentication to obtain patients' reports, evaluate their health conditions and guide them to the more suitable treatment.
The following sections detail each of the phases necessary to perform the mutual authentication of the entities considered and the cloud server. The phases are the following: registration, health center upload, patient upload, treatment and checkup. Table 2 presents the notations used in the protocol. Patients without sensors visit the health center in order to collect identity information to be used in future mutual authentication sessions. The health center must perform mutual authentication with the cloud server prior to sending its patients' data. Patients' devices perform mutual authentication with the cloud server prior to sending the data collected from the respective sensors. Devices with direct access to the 3GPP infrastructure might use it to reach the cloud server. Those devices located outside of the coverage area can execute the mutual authentication using D2D communication, prior to sending health reports. In the second case, the other D2D devices in the path to the cloud server are used as relays. A device with a direct connection with 3GPP infrastructure might choose to send its information through D2D communication to perform data offload, which is not addressed in this work.
Finally, each doctor also has to execute mutual authentication to obtain patients' reports, evaluate their health conditions and guide them to the more suitable treatment.
The following sections detail each of the phases necessary to perform the mutual authentication of the entities considered and the cloud server. The phases are the following: registration, health center upload, patient upload, treatment and checkup. Table 2 presents the notations used in the protocol.

IDx /TIDx
Real identity of entity x/ Temporary identity of entity x. k Random numbers generated in the registration phase. Rk k random number generated.

MACxy
Message Authentication Code generated from entity x to entity y.

Rx
Random number generated by entity x.

RCy
Random number generated by the cloud and sent to entity y.

Tx
Timestamp generated by entity x.

Kxy
Session key generated by entities x and y.

Symbol Description
x, y Entities: patient (P), health center (H), doctor (D), cloud server (C). ID x /TID x Real identity of entity x/ Temporary identity of entity x.
k Random numbers generated in the registration phase.
R k k random number generated.

MACxy
Message Authentication Code generated from entity x to entity y.

R x
Random number generated by entity x.

R Cy
Random number generated by the cloud and sent to entity y.

T x
Timestamp generated by entity x.

K xy
Session key generated by entities x and y.

C xy
Validator of the session key generated by x and y.

Cxy
Validator of the session key generated by x and y. EKxy /DKxy Encryption/Decryption operation that used the session key generated by x and y.
IMSIx International Mobile Subscriber Identity of device x h1 Temporary identity generation hash function. h2 MAC generation hash function. h3 Session key generation hash function. h4 Session key verifier generation hash function.
Secure channel.

Device Discovery Scheme
In order to undertake D2D communication, the devices must execute a device discovery to detect and identify devices in proximity [13]. The 3GPP technical specification TS 23303 [20] describes two models of devices discovered with no permission necessary from the User Equipment (UE) to be Secure channel.

Cxy
Validator of the session key generated by x and y. EKxy /DKxy Encryption/Decryption operation that used the session key generated by x and y. IMSIx Temporary identity generation hash function. h2 MAC generation hash function. h3 Session key generation hash function. h4 Session key verifier generation hash function.
Secure channel.

Device Discovery Scheme
In order to undertake D2D communication, the devices must execute a device discovery to detect and identify devices in proximity [13]. The 3GPP technical specification TS 23303 [20] describes two models of devices discovered with no permission necessary from the User Equipment (UE) to be discovered or with authorization required. The first model is Model A "I am here", in which devices

Device Discovery Scheme
In order to undertake D2D communication, the devices must execute a device discovery to detect and identify devices in proximity [13]. The 3GPP technical specification TS 23303 [20] describes two models of devices discovered with no permission necessary from the User Equipment (UE) to be discovered or with authorization required. The first model is Model A "I am here", in which devices broadcast some information to announce their existence and monitor if interested devices also shared their information. In the second model, Model B "Who is there?", devices work as discoverers by broadcasting the characteristics which it expects to find in the nearby devices and waiting for the response of those which are eligible to fulfill its expectations.
In this work we adopt Model A. The device discovery is executed following the solution presented in Gunes et al. [13] and the technical specification TS 23303 [20], which is described as follows.
First, as mentioned by [13], each device must prove to be authentic to the HSS, which checks if the International Mobile Subscriber Identity (IMSI) of the device matches the identity of the device registered in the database and if that device is eligible to perform D2D. If the verification passes, the devices are enabled to perform D2D communication. The authorization is stored in the eNB and refreshed at the expiration of a validity timer.
Next, it adopts a model with direct discovery among devices through a dedicated ProSe server, one of the solutions presented by [13] and based on the specifications of TS 23303 [20]. The devices detect and identify each other using Evolved Terrestrial Radio Access Network (E-UTRAN) or Wireless Local Area Network (WLAN) direct radio signals to share their identities.

Registration Phase
This phase is performed to provide the exchange of important parameters used in the next phases, which regards authentication. Each device must have its IMSI registered in the HSS. This registration occurs offline and is executed by the manufacturer.
Next, it is necessary to register the health center, patients and doctors in the cloud server. This registration occurs through a secure channel. Each entity generates k different random numbers R k and calculates a set of temporary identities, TID x = h 1 (ID x || R k ), which are individually used at each authentication session initiated by the entities. The use of real identities associated with a random number in the calculation of temporary identities guarantees its uniqueness. They send their real identity ID x , and temporary identities TID x to the cloud server, which stores the data to be used in the following phases. If all temporary identities of a certain entity are used, a new registration phase is performed. If a real identity is revoked, it is necessary to perform a special registration phase, indicating which was the identity revoked and the new equivalent identity. Only registered entities can perform the following phases.

Health Center Upload Phase (HUP)
It is considered an insecure channel for this phase. Its aim is the mutual authentication among entities to allow secure transmission of the patient's collected data, from the health center to the cloud server. The complete procedure is shown in Figure 2. The HUP phase starts when the user goes to the health center for a health inspection and receives a login and a password to access the patient's system in its mobile device. The patient can access his/her health information whenever wanted by inserting the login/password pair on his/her device.
Step 1. The health center selects a TID H and generates a random number R H . Then, it calculates MAC HC = h 2 (ID H || R H ) and sends Message 1 = (TID H , R H , MAC HC ) to the cloud server with a timestamp T H .
Step 2. After receiving Message 1 and T H from the health center, the cloud server verifies if T H is valid. If the verification fails, the procedure is terminated. Otherwise, the cloud server calculates MAC HC ' = h 2 (ID H || R H ) using the real identity of the health center received in the registration phase and If the verification fails, the procedure ends because an intruder has been detected. Otherwise, the cloud server authenticates the health center, selects a random number R CH , calculates MAC CH = h 2 (ID H || R CH ) and sends Message 2 = (MAC CH , R CH ) with a timestamp T C to the health center.
Step 3. The health center receives Message 2 and T C from the cloud server and checks if timestamp T C is valid. If the validation fails, the procedure ends. Otherwise, the health center calculates MAC CH ' = h 2 (ID H || R CH ) and verifies if MAC CH ' = MAC CH . If the verification fails, the procedure is terminated because an intruder has been detected. Otherwise, the health center authenticates the cloud server and generates the session key, K HC = h 3 (ID H || R H || R CH ) and the session key validator, C HC = h 4 (K HC ). It then uses the session key to encrypt the patient's report, M RP = E KHC (Patient Report, TID P , C HC ) and finally sends Message 3 = M RP and a new timestamp T H to the cloud server.
Step 4. The cloud server receives {Message 3, T H } and verifies T H . If the verification fails, it terminates the procedure. Otherwise, it calculates the session key K HC = h 3 (ID H || R H || R CH ) and decrypts the patient's report, (Patient Report, TID P , C HC ) = D KHC (M RP ). It then calculates C HC = h 4 (K HC ) and verifies if C HC ' = C HC . If the verification fails, it ends the procedure. Finally, the cloud server stores the patient´s report with the respective identities.
inserting the login/password pair on his/her device.
Step 1. The health center selects a TIDH and generates a random number RH. Then, it calculates MACHC = h2(IDH || RH) and sends Message 1 = (TIDH, RH, MACHC) to the cloud server with a timestamp TH.
Step 2. After receiving Message 1 and TH from the health center, the cloud server verifies if TH is valid. If the verification fails, the procedure is terminated. Otherwise, the cloud server calculates MACHC' = h2(IDH || RH) using the real identity of the health center received in the registration phase and the random number received in Message 1. It then verifies if MACHC' = MACHC. If the verification fails, the procedure ends because an intruder has been detected. Otherwise, the cloud server authenticates the health center, selects a random number RCH, calculates MACCH = h2(IDH || RCH) and sends Message 2 = (MACCH, RCH) with a timestamp TC to the health center.
Step 3. The health center receives Message 2 and TC from the cloud server and checks if timestamp TC is valid. If the validation fails, the procedure ends. Otherwise, the health center calculates MACCH' = h2(IDH || RCH) and verifies if MACCH' = MACCH. If the verification fails, the procedure is terminated because an intruder has been detected. Otherwise, the health center authenticates the cloud server and generates the session key, KHC = h3(IDH || RH || RCH) and the session key validator, CHC = h4(KHC). It then uses the session key to encrypt the patient's report, MRP = EKHC (Patient Report, TIDP, CHC) and finally sends Message 3 = MRP and a new timestamp TH to the cloud server.
Step 4. The cloud server receives {Message 3, TH} and verifies TH. If the verification fails, it terminates the procedure. Otherwise, it calculates the session key KHC = h3(IDH || RH || RCH) and decrypts the patient's report, (Patient Report, TIDP, CHC) = DKHC(MRP). It then calculates CHC = h4(KHC) and verifies if CHC' = CHC. If the verification fails, it ends the procedure. Finally, the cloud server stores the patient´s report with the respective identities.

Patient Upload Phase (PUP)
The PUP phase is performed over an insecure channel. The focus of PUP is the mutual authentication between patients and the cloud server and the generation of a session key to encrypt health information measured by the sensors attached to the user's body, prior to sending it to the cloud server. The complete procedure is shown in Figures 3 and 4. The PUP phase starts when the patient's device requests, from the sensors attached to the user's body, the health information measured and collected and stores them.
If necessary, the device discovery is performed in order to find other nearby devices as detailed in Section 4.1, based on proximity. However, first, they need to authenticate with a 3GPP network Sensors 2020, 20, 2072 9 of 23 to prove their reliability. All devices interested in performing D2D communication selects a random number R P , calculates and sends the hash of its IMSI to the HSS to be authenticated: The HSS receives each Auth p , calculates Auth' p = h 1 (IMSI p || R P ) and verifies if Auth p = Auth' p . If the verification passes, it authenticates the device. All devices authenticated by the HSS are enabled to perform D2D.
Then, the devices interested in D2D broadcast their TID Di-j to reach other devices nearby, which might demonstrate the intention of establishing a connection with them. Next, they send their own temporary identities to signalize their existence and position. Now, a device located outside the coverage area or inside the coverage area but without access to the 3GPP network can perform their authentication with the cloud server by relaying their messages through the nearby devices, until the 3GPP network is reached.
Step 1. Calculates MAC PC = h 2 (ID P || R P ) and sends Message 1 = (TID P , R P , MAC PC ) with a timestamp T P to the cloud server. A device with direct access to the 3GPP network can choose to send data directly or to perform offload through D2D communication until the cloud server is reached. Devices without the 3GPP coverage send their data through D2D communication.
Step 2. The cloud server receives Message 1 and T P and verifies if T P is valid. If the verification fails, the procedure is terminated. Otherwise, it calculates MAC PC ' = h 2 (ID P || R P ) and verifies if MAC PC ' = MAC PC . If the verification fails, the procedure is interrupted. Otherwise, the cloud server authenticates the device, selects a random number R CP , calculates MAC CP = h 2 (ID P || R CP ) and sends Message 2 = (MAC CP , R CP ) with a timestamp T C to the patient.
Step 3. After receiving Message 2 and T C from the cloud server, the patient checks if T C is valid. If the validation fails, the procedure ends. Otherwise, it calculates MAC CP ' = h 2 (ID P || R CP ) and verifies if MAC CP ' = MAC CP . If the verification fails, the procedure is terminated. Otherwise, the patient authenticates the cloud server, generates the session key K PC = h 3 (ID P || R P || R CP ) and calculates C PC = h 4 (K PC ). He/she then encrypts the sensors measures using the session key, M MS = E KPC (Sensors Measures, TID P , C PC ) and sends Message 3 = M MS with a new timestamp T P to the cloud server.
Step 4. The cloud server receives {Message 3, T P } and verifies if T P is valid. If the verification fails, it terminates the procedure. Otherwise, it calculates the session key K PC = h 3 (ID P || R P || R CP ), decrypts the sensors measures, (Sensors Measures, TID P , C PC ) = D KPC (M MS ), calculates C PC = h 4 (K CP ) and verifies if C PC ' = C PC . If the verification fails, it terminates the procedure. Otherwise, the cloud server stores the sensors' measures with the respective identities.

Treatment Phase (TP)
This phase is performed over an insecure channel. It aims at mutual authentication between the doctor and the cloud server and generation of a session key for encrypting the patient's health report and sensors' measures before they are sent to the doctor, in addition to encrypting the doctor's diagnosis before it is sent to the cloud server. The complete procedure is shown in Figure 5.
Step 1. The doctor selects one of his/her temporary identities TID D , generates a random number R D , calculates MAC DC = h 2 (ID D || R D ) and sends Message 1 = (TID D , R D , MAC DC ) with a timestamp T D to the cloud server.
Step 2. The cloud server receives {Message 1, T D } and verifies if T D is valid. If the verification fails, the procedure is terminated. Otherwise, it calculates MAC DC ' = h 2 (ID D || R D ) and verifies if MAC DC ' = MAC DC . If the verification fails, the procedure is interrupted. Otherwise, the cloud server authenticates the doctor, selects a random number R CD and calculates MAC CD = h 2 (ID D || R CD ), a session key K DC = h 3 (ID D || R D || R CD ) and C DC = h 4 (K DC ). It then uses the doctor's real identity to obtain the patient´s report and sensors' health information measures previously stored in the cloud and prepare the information to be sent to the doctor, encrypting the data with the session key calculated, M RPMS = E KHC (Patient Report, Sensors Measures, TID P , C DC ). Finally, it sends Message 2 = (MAC CD , R CD , M RPMS ) with a timestamp T C to the doctor. Step

Checkup Phase (CP)
This phase is performed over an insecure channel and aims at a new mutual authentication between the patient and the cloud server and generation of a new session key for encrypting the doctor's diagnosis before the cloud sends it to the patient. The complete procedure is shown in Figure  6.

Checkup Phase (CP)
This phase is performed over an insecure channel and aims at a new mutual authentication between the patient and the cloud server and generation of a new session key for encrypting the doctor's diagnosis before the cloud sends it to the patient. The complete procedure is shown in Figure 6.
Step 1. The patient generates a new random number R PCP , calculates MAC PCP = h 2 (ID P || R PCP ) and sends Message 1 = (TID P , R PCP , MAC PCP , Request) with a timestamp T P to the cloud server. Devices with direct access to the 3GPP network can send their data directly or use D2D communication to reach the cloud server. Devices without the 3GPP coverage must send their data through D2D communication.
Step 2. After receiving Message 1 and T P , the cloud server verifies if T P is valid. If the verification fails, the procedure is terminated. Otherwise, it calculates MAC PCP ' = h 2 (ID P || R PCP ) and verifies if MAC PCP ' = MAC PCP . If the verification fails, the procedure ends. Otherwise, it authenticates the patient, selects a random number R CCP , calculates MAC CCP = h 2 (ID P || R CCP ), generates the session key K PCP = h 3 (ID P || R PCP || R CCP ) and computes C PCP = h 4 (K PCP ). It then uses the session key to encrypt the doctor's diagnosis, M DiagP = E KPCP (Doctor's Diagnosis, TID P , C PCP ) and sends it to the patient Message 2 = (MAC CCP , R CCP , M DiagP ) with a timestamp T C .
Step 3. The patient receives {Message 2, T C } and checks if T C is valid. If the validation fails, the procedure is terminated. Otherwise, he/she calculates MAC CCP ' = h 2 (ID P || R CCP ) and verifies if MAC CCP ' = MAC CCP . If the verification fails, the procedure is interrupted. Otherwise, he/she authenticates the cloud server, generates the session key K PCP = h 3 (ID P || R PCP || R CCP ), decrypts the doctor's diagnosis, (Doctor's Diagnosis, TID P , C PCP ) = D KPCP (M DiagP ), calculates C PCP = h 4 (K PCP ) and verifies if C PCP ' = C PCP . If the verification fails, it ends the procedure. Otherwise, the patient stores the doctor's diagnosis and looks for a convenient treatment.

Security Analysis
This section presents the security objectives accomplished by the protocol. Table 3 shows a security comparison between the proposed protocol and those designed by Chiou et al. [7] and Mohit et al. [6].

Security Analysis
This section presents the security objectives accomplished by the protocol. Table 3 shows a security comparison between the proposed protocol and those designed by Chiou et al. [7] and Mohit et al. [6].

Mutual Authentication
In our protocol, each entity calculates a MAC to perform mutual authentication with the cloud server and vice versa. For example, in the HUP phase, the health center calculates MAC HC = h 2 (ID H || R H ) and sends it to the server cloud, which calculates MAC HC ' = h 2 (ID H || R H ) and verifies if MAC HC ' = MAC HC . If the verification is successful, the server cloud authenticates the health center, calculates its own MAC CH = h 2 (ID H || R CH ) and sends it to the health center, which calculates MAC CH '-h 2 (ID H || R CH ) and verifies if MAC CH ' = MAC CH . If the verification succeeds, the health center authenticates the server cloud and the mutual authentication procedure is complete. A similar procedure is performed in the PUP, TP and CP phases.

Forward/Backward Secrecy
The forward and backward secrecies are guaranteed by the use of random values (R H , R CH , R P , R CP , R D , R CD , R PC , R CPC ) newly generated in each authentication session, during the calculation of the system keys, as the one generated in the PUP phase K CP = h 3 (ID P || R P || R C ). Therefore, if an intruder discovers old system keys, it cannot use them in future authentication sessions (backward secrecy). On the other hand, if an intruder discovers future system keys, it cannot use them in past authentication sessions (forward secrecy).

Confidentiality
The system's confidentiality is guaranteed by the access control of the patient's mobile device. A possible user must insert a login and password to access his/her information in the system. Consequently, sensitive information is available only to authorized users. An authentication procedure is performed between the cloud and an entity in each phase for the generation of a session key that will encrypt the patient's data before it is exchanged on a public channel.

Non-Repudiation
At the beginning of each phase in the protocol, the entities send the cloud their temporary identities (TID H , TID P , TID D ) and a MAC calculated with their real identities (ID H , ID P , ID D ). The cloud also sends to the entities a MAC containing their real identities. Since real identities are known only by the cloud and each respective entity, a valid MAC can be generated only by them. The session keys established among the cloud and the entities also depend on their real identity, therefore, neither the cloud nor the entities can deny the message they originated.

Anonymity
Anonymity is assured only by entities' temporary identities (TID H , TID P , TID D ), while messages are exchanged on an insecure channel during the authentication procedure, which protects their real identities. The identity of the cloud server is protected because it is not used in the authentication procedure, hence, not exchanged on an insecure channel.

Non-Traceability
The use of different temporary identities and newly generated random numbers in each new authentication session generates different parameters exchanged. Therefore, outsiders cannot track patients by the parameters exchanged on a public channel.

Session Key Security
Session keys are not exchanged on a public channel but securely calculated on each side involved in the authentication. Moreover, the security of the session keys established at each phase of the protocol is guaranteed through the use of entities' real identities in the calculation, some secret information known only by the cloud server and the respective entities. For example, in HUP, the session key calculated is KHC = h 3 (IDH || RH || RCH); Consequently, an intruder cannot obtain or calculate a valid session key.

Patient's Mobile Device Loss/Stealing
The security objective is accomplished through the access control of the patient's mobile device using a login and password. The system is only accessible if a valid login and password pair is inserted. If the mobile device is stolen or lost, no unauthorized person can access the patient's system, because it would not have a valid login and password pair.

Impersonation Attack
The impersonation attack is avoided because neither the cloud server's real identity nor the entities' real identities are disclosed. Therefore, an attacker cannot impersonate them and generate a valid MAC, because its calculation depends on the entities' real identities.

Replay Attack
The replay attack is avoided because all entities involved in our protocol use different random values freshly calculated in each authentication process. Therefore, an attacker cannot forge messages using old random values.

Denial of Service (DoS)
The prevention of this attack involves the inclusion of a verification parameter in each message exchanged in the authentication phases (HUP, PUP, TP, CP). The verification parameter used in our protocol was a timestamp and its validity was verified before the recipient processed each message. Therefore, if an attacker uses an invalid timestamp, the entire procedure is interrupted in time to prevent the DoS attack.

Man-in-the-Middle Attack
No intruder can perform a man-in-the-middle attack, because the session key cannot be forged with the use of only the parameters exchanged on the insecure communication channel. The session key calculation uses the entities' real identities, which is a secret value not disclosed in the insecure channel. Table 3 data are derived from the analysis of the data presented in [6] and [7]. The protocol designed by Chiou et al. [7] does not guarantee anonymity, non-traceability, and resistance to patient's mobile device loss/stealing, which are three critical failures. First, as detected by Mohit et al. [6], in the protocol of Chiou et al. [7], the patient's real identity is sent in plain text through a public channel, which compromises its anonymity. We observed it also affects the patient's non-traceability. Second, as detected by Mohit et al. [6], the proposal of Chiou et al. [7] fails to be resistant to the patient's mobile device loss/stealing, because it does not perform access control and requests login and password to the user, which makes the system vulnerable to the access of non-authorized people and hampers its confidentiality. The protocol of Mohit et al. [6] fails to prevent DoS attack. No initial verification parameter is generated (timestamp, nonce, sequence number) to be sent with the parameters exchanged. Then, the validity of a simpler parameter is not verified before the recipient processes more complex calculations. Therefore, the protocol is vulnerable to DoS attacks, because the system of D2D devices is not robust enough to deal with message flooding. Our protocol accomplished all security objectives analyzed and can, therefore, be considered safer than those designed by Chiou et al. [7] and Mohit et al. [6].

Performance Analysis
This section addresses a performance analysis of our protocol and a comparison with those developed by Chiou et al. [7] and Mohit et al. [6]. The analysis evaluated computational, communication and energy costs and was based on the data available in [6] and [7], in parallel with their own cost evaluation. The registration phase of the protocol was not included in the analysis because it is performed over a secure channel and the focus of the comparisons was on operations executed and parameters exchanged over an insecure channel. It is considered that "n" is the number of devices executing mutual authentication with the cloud server using a traditional 3GPP network. It is also considered that "m" is the number of devices using D2D communication to perform mutual authentication with the cloud server.

Computational Cost
The execution time in seconds (s) of the operations considered is shown in Table 4. Chiou et al. [7] and Mohit et al. [6] adopted those values and performed tests with the following operational characteristics: CPU: Intel (R) Core (TM) 2 Quad Q8300, 2.50Hz; memory: 2GB; operational system: Windows 7 Professional. All four phases were analyzed and all operations executed were considered. Table 5 shows a comparison of the computational costs among our protocol and those of Chiou et al. [7], Mohit et al. [6], details of the operations performed at each phase and the total time in seconds. Table 5. Computational cost of protocols.

Chiou et al. [7]
Mohit et al. [6] Proposed Protocol Our protocol required the lowest computational cost, therefore, it performs the operations necessary in a shorter time and offers the best computational cost, due to the exclusive use of symmetric cryptography (low communication cost) for the authentication procedures. Chiou et al. [7] and Mohit et al. [6] conducted some signature operations and bilinear pairing, which incurred higher computational costs. Figure 7 confirms with a graphic representation of costs that our proposed protocol has the best performance regarding computational costs when compared to [6] and [7].

Communication Cost
The evaluation of the communication costs considered messages exchanged over an insecure channel and parameters and their respective costs in bits (see Table 6). The message exchange over an insecure channel was analyzed in each of the four common phases performed by our protocol and those of Chiou et al. [7] and Mohit et al. [6]. Table 7 shows comparisons of each phase and a comparison of the total communication cost of each protocol.

Communication Cost
The evaluation of the communication costs considered messages exchanged over an insecure channel and parameters and their respective costs in bits (see Table 6). The message exchange over an insecure channel was analyzed in each of the four common phases performed by our protocol and those of Chiou et al. [7] and Mohit et al. [6]. Table 7 shows comparisons of each phase and a comparison of the total communication cost of each protocol. Our protocol required the lowest communication cost, hence, the best communication cost, due to the reduced number of parameters exchanged and choice of small parameters to be exchanged (identities, random numbers, timestamps) and the adaptation to D2D communication that offloads part of the traffic outside the 3GPP spectrum. The proposals of Chiou et al. [7] and Mohit et al. [6] required higher communication costs, because of the exchange of some costly signature parameters. Our protocol achieved the best performance, revealed by security and performance analyses. Figure 8 shows the best performance of the proposed protocol regarding communication costs. It considers that 30% of devices perform offload and use D2D communication to execute their mutual authentication. Reducing costs in the traditional 3GPP network. Our protocol required the lowest communication cost, hence, the best communication cost, due to the reduced number of parameters exchanged and choice of small parameters to be exchanged (identities, random numbers, timestamps) and the adaptation to D2D communication that offloads part of the traffic outside the 3GPP spectrum. The proposals of Chiou et al. [7] and Mohit et al. [6] required higher communication costs, because of the exchange of some costly signature parameters. Our protocol achieved the best performance, revealed by security and performance analyses. Figure 8 shows the best performance of the proposed protocol regarding communication costs. It considers that 30% of devices perform offload and use D2D communication to execute their mutual authentication. Reducing costs in the traditional 3GPP network.

Energy Cost
Kumar et al. [21] and He et al. [22] have proposed energy cost evaluation, which considers that the maximum CPU power of devices (W) is approximately 10.88 Watts. The energy overhead was calculated as follows: ETotal = CCTotal × W, where CCTotal is the computational cost calculated and presented in Section 5.1. Table 8 and Figure 9 show the comparison of energy costs among our protocol and other protocols from [7] and [6]. Figure 9 shows that our proposed scheme has the best performance regarding energy. The energy cost directly related to the computational cost and consequently the graphic results are for both costs and are very similar.

Energy Cost
Kumar et al. [21] and He et al. [22] have proposed energy cost evaluation, which considers that the maximum CPU power of devices (W) is approximately 10.88 Watts. The energy overhead was calculated as follows: ETotal = CCTotal × W, where CCTotal is the computational cost calculated and presented in Section 5.1. Table 8 and Figure 9 show the comparison of energy costs among our protocol and other protocols from [7] and [6]. Figure 9 shows that our proposed scheme has the best performance regarding energy. The energy cost directly related to the computational cost and consequently the graphic results are for both costs and are very similar.  Finally, the good results obtained in the security and performance evaluations prove that the proposed protocol can perform better than the works of [6] and [7]. Below are some aspects compared with the above-mentioned works: a) the protocols of Chiou et al. [7] and Mohit et al. [6] are based on asymmetric cryptography, while our approach is based on symmetric cryptography, which is able to produce lower computational and communication costs; b) the security flaws of Chiou et al. [7] and Mohit et al. [6] are avoided in our protocol using access control to the patient's device, timestamps, temporary identities and freshly generated parameters in each authentication session; c) by contrast with our proposed scheme, the protocols of Chiou et al. [7] and Mohit et al. [6] do not support D2D communication, which is a promising technology for the development of ehealth systems due to the agility of data transmission it can provide. The proposed protocol was designed thinking about the criticality of the health systems that in some cases might depend on the agility of data transmission to save lives.

Formal Validation
The proposed protocol was validated using Automated Validation of Internet Security Protocols and Applications (AVISPA) [1]. This is a semi-automated validation tool that permits the verification of security robustness of authentication protocols by checking the secrecy of key parameters and the vulnerability to intruders.
AVISPA validation is made through codes written in the high-level protocol specification language (HLPSL). The message exchange of the protocol is translated to HLPSL code, where each entity is defined as a communication agent that performs roles. Each entity has its own role defined, Finally, the good results obtained in the security and performance evaluations prove that the proposed protocol can perform better than the works of [6] and [7]. Below are some aspects compared with the above-mentioned works: (a) the protocols of Chiou et al. [7] and Mohit et al. [6] are based on asymmetric cryptography, while our approach is based on symmetric cryptography, which is able to produce lower computational and communication costs; (b) the security flaws of Chiou et al. [7] and Mohit et al. [6] are avoided in our protocol using access control to the patient's device, timestamps, temporary identities and freshly generated parameters in each authentication session; (c) by contrast with our proposed scheme, the protocols of Chiou et al. [7] and Mohit et al. [6] do not support D2D communication, which is a promising technology for the development of e-health systems due to the agility of data transmission it can provide. The proposed protocol was designed thinking about the criticality of the health systems that in some cases might depend on the agility of data transmission to save lives.

Formal Validation
The proposed protocol was validated using Automated Validation of Internet Security Protocols and Applications (AVISPA) [1]. This is a semi-automated validation tool that permits the verification of security robustness of authentication protocols by checking the secrecy of key parameters and the vulnerability to intruders.
AVISPA validation is made through codes written in the high-level protocol specification language (HLPSL). The message exchange of the protocol is translated to HLPSL code, where each entity is defined as a communication agent that performs roles. Each entity has its own role defined, which contains all the parameters exchanged in the messages (States). All parameters that must remain secret are signalized and observed during the code execution. If no secret value is vulnerable to be discovered by intruders, the protocol is considered safe.
Our validation was made for each of the four phases performed over an insecure channel (HUP, PUP, TP and CP). Figure 10 presents the role for an ordinary device in the PUP phase, named Dpi in the code. Each State symbolizes the messages sent (SND) and received (RCV). Each parameter that must remain secret is signalized with a flag, such as sec_3 and sec_4 in Figure 10. The flag SecureChannel accompany an encrypted message and the parameters that are sent encrypted are signalized as secret (parameter). Figure 11 shows the role of the cloud server in PUP phase.
Sensors 2020, 19, x FOR PEER REVIEW 20 of 24 the code. Each State symbolizes the messages sent (SND) and received (RCV). Each parameter that must remain secret is signalized with a flag, such as sec_3 and sec_4 in Figure 10. The flag SecureChannel accompany an encrypted message and the parameters that are sent encrypted are signalized as secret (parameter). Figure 11 shows the role of the cloud server in PUP phase.   We use two of the AVISPA's four security evaluation backends in the validation of our proposed protocol: On-the-Fly-Model-checker (OFMC) [23] and Constraint Logic-based Attack Searcher (CL-AtSe) [24]. Figure 12 presents   the code. Each State symbolizes the messages sent (SND) and received (RCV). Each parameter that must remain secret is signalized with a flag, such as sec_3 and sec_4 in Figure 10. The flag SecureChannel accompany an encrypted message and the parameters that are sent encrypted are signalized as secret (parameter). Figure 11 shows the role of the cloud server in PUP phase.   We use two of the AVISPA's four security evaluation backends in the validation of our proposed protocol: On-the-Fly-Model-checker (OFMC) [23] and Constraint Logic-based Attack Searcher (CL-AtSe) [24]. Figure 12 presents the results of the OFMC analysis of the PUP phase, which concluded that our proposed protocol is safe.  We use two of the AVISPA's four security evaluation backends in the validation of our proposed protocol: On-the-Fly-Model-checker (OFMC) [23] and Constraint Logic-based Attack Searcher (CL-AtSe) [24]. Figure 12 presents the results of the OFMC analysis of the PUP phase, which concluded that our proposed protocol is safe.     Figure 13 shows the analysis of the PUP phase in the CL-AtSe backend and its respective results. Our proposed protocol was declared safe according to the analysis.

Conclusions
The application of e-health/m-health to the monitoring, diagnosis, and treatment of patients speeds up the provision of medical services. In many cases, the patient does not need to leave his/her home for a doctor's appointment, which facilitates access to medical advice for patients with limited mobility, the elderly or patients located in hard access areas.
The protocols analyzed showed interest in the development of efficient and safe e-health/m-health/TMIS systems for protecting patients' data and their respective identities. Our protocol showed itself to be suitable to e-health/m-health/TMIS and outperformed those of Chiou et al. [7] and Mohit et al. [6]. The protocol designed by Chiou et al. [7] does not control the access to patients' mobile devices for avoiding their system's exposure to intruders, if the device is lost or stolen, which is a problem with a simple solution. The protocol designed by Mohit et al. [6] fails to avoid the denial of service (DoS) attack. In addition, both protocols do not support D2D communication.
Furthermore, reductions in computational and communication costs are reinforced by using symmetric cryptography. Asymmetric cryptography demands more resource consumption than symmetric cryptography due to the execution of more complex operations such as elliptic curves [25]. Moreover, there are some common misconceptions such as to consider asymmetric cryptography safer than symmetric cryptography. In terms of cryptoanalysis, the length of the key and the computational work involved in breaking a cipher are essential for security evaluation. Symmetric cryptography is suitable to be used in situations in which costs must be reduced, such as for the resource-constrained devices used for m-health.
The performance and security analyses conducted confirmed that resource consumption could be reduced in our proposed solution when compared with other solutions that use asymmetric cryptography with no impact on the system's security through the use of symmetric cryptography.
Future studies include storage cost analysis and comparison with related works and development of other mutual authentication protocols based on asymmetric cryptography for cloud-based e-health systems that accomplish more security objectives, as the objectives presented by Liu et al. [26], with reduced resource consumption.
The development of authentication and authorization protocols, considering CPS (cyber physical systems) ( [27][28][29]) as well as security evaluation based on integrated systems of ambient-assisted living (AAL) and e-health (as in Rghioui et al. [30]) has also been considered. Finally, the influence of the mobility on the authentication of D2D communications ( [31][32][33]) will be explored. Funding: This research was funded by Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), which granted a scholarship to Ana Paula Golembiouski Lopes while pursuing her master degree course.

Conflicts of Interest:
The authors declare no conflict of interest.