# New Efficient and Secured Authentication Protocol for Remote Healthcare Systems in Cloud-IoT

Authors: Mourade Azrour; Jamal Mabrouki; Rajasekhar Chaganti
Journal: Security and Communication Networks
 (2021)

---

## Abstract

Recently, Internet of Things and cloud computing are known to be emerged technologies in digital evolution. The first one is a large network used to interconnect embedded devices, while the second one refers to the possibility of offering infrastructure that can be used from anywhere and anytime. Due to their ability to provide remote services, IoT and cloud computing are actually integrated in various areas especially in the healthcare domain. However, the user private data such as health data must be secured by enhancing the authentication methods. Recently, Sharma and Kalra projected an authentication scheme for distant healthcare service-based cloud-IoT. Then, authors demonstrated that the proposed scheme is secure against various attacks. However, we prove in this paper that Sharma and Kalra’s protocol is prone to password guessing and smart card stolen attacks. Besides, we show that it has some security issues. For that reason, we propose an efficient and secured authentication scheme for remote healthcare systems in cloud-IoT. Then, we prove informally that our projected authentication scheme is secure against multiple attacks. Furthermore, the experimental tests done using Scyther tool show that our proposed scheme can withstand against known attacks as it ensures security requirements.


---

## Body

## 1. Introduction

The Internet of Things (IoT) and cloud computing are revolutionizing many industries such as health and transportation. The IoT is a large network that interconnects objects, computers, and human individuals. These devices are able to sense, process, and communicate data from one end to another one. In addition, cloud computing is a system that allows the customers to access computing resources via the network. The cloud computing provider ensures the protection of a given number of servers that can be used according to the customer needs. Indeed, IoT's growth has been particularly dynamic and has truly revolutionized human personal and professional daily activities. Some of the IoT areas include agricultural [1–4], industrial [5], education [6], healthcare [7–9], and environmental fields [10–13].Remote patient monitoring relies on computer systems that retrieve health information from individuals in one location and communicate it digitally to health professionals in another location for assessment and advice, as shown in Figure1. With this kind of service, healthcare provider can continue processing patient's medical data even if the patient stays at home or care facility and reduces the patient readmission rates.Figure 1
Internet of Thing and healthcare system.The question of health is systematically at the heart of the human race's concern, even though there are technological advancements in health treatment. Recently, healthcare has taken on great significance, as witnessed by the most recent coronavirus epidemic. Indeed, in areas where the epidemic is spreading, it is increasingly wise to monitor people remotely using health monitoring technology. A variety of monitoring platforms which allow collecting a large volume of healthcare data at the site of treatment, such as patient's vital signs, patient's weight, heart rate, blood pressures, blood glucose, blood O2 levels, and electrocardiographs, can be used to monitor the patient's health.Because of the performance and computing limitations of IoT equipment in handling the massive volume of collected data, it may be appropriate to employ a cloud service to overcome such challenges. Nevertheless, this approach will require warranty of confidentiality, integrity, and security of exchanged data. Subsequently, data are only accessible by authorized entities.The commonly used solution to assure the confidentiality of data is using such authentication protocols. Hence, Sharma and Kalra [14] proposed a trivial authentication protocol for cloud-IoT-based healthcare system. Formerly, they demonstrated that their proposed protocol is efficient, trivial, and secured against various attacks including DoS attack, man in the middle attack, offline password guessing attack, user impersonation attack, replay attack, and parallel session attack. Authors also use AVISPA tool to evaluate their protocol formally. In this research work, we demonstrated that Sharma and Kalra’s scheme poses security vulnerabilities, in particular vulnerable to password guessing attacks. Moreover, some private values described in the protocol are not very secured; it can be obtained basically by any attacker. With the aim to improve the security of cloud-IoT-based healthcare, we propose a new efficient and secured authentication protocol. After proving theoretically that our protocol can resist against various attack, we have done simulation tests under Scyther tool. The obtained results confirm that our scheme can deal against famous attacks, and it guarantees security requirements.The remaining part of the paper is organized as follows. Related works have been debated in Section2. Section 3 is reserved for reviewing Sharma and Kalra’s protocol. In Section 4, weaknesses of Sharma and Kalra’s protocol are discussed. Our proposed efficient and secured authentication scheme is presented in Section 5. In Section 6, informal and formal analyses are detailed. Section 7 provides the performance and comparative analysis. In Section 8, we conclude our paper.


## 2. Related Works

Due to the quick growth and development of various new technologies, personal security, the system for controlling access and the procedures for checking the authenticity of data are gaining significance everyday, particularly since the birth of the IoT. As a consequence, in this section, we discuss some authentication protocols that have been previously presented in literature.Watro et al. [15] proposed a secured authentication scheme based on RSA for WSNs. Wong et al. [16] proposed authentication scheme that is funded on one way hash functions. This protocol was considered to be secure against many possible attacks, including replay attack, man-in-the-middle attack, forgery attack, and key impersonation attack. Nonetheless, this protocol is proved prone to insider attack and man-in-the-middle attack. As result, Das et al. [17] planned an enhance protocol for gaining more security. Moreover, Xu et al. [18] and Song [19] proposed independently two authentication protocols in 2009 and 2010, respectively. The two proposed protocols are both based on RSA cryptography.Based on elliptic curve cryptography (ECC), Xu et al. [20] proposed mutual authentication and key convention scheme as a solution of computational problem. Then, he demonstrated that the proposed protocol guarantees confidentiality by using a dynamic identity. Hence, Yan et al. [21] proposed a user authentication system based on biometric detection. However, this protocol cannot resist against replay attacks and is not able to guarantee user anonymity. Furthermore, Mishra et al. proved that Yan's protocol is vulnerable against offline password guessing attacks. Based on those issues, Mishra et al. [22] suggested a new reinforced biometric authentication protocol that uses random digits. Afterword, Tan [23] proposed three-factor mutual authentication protocol.Yoon and Kim [24] presented user authentication protocol based on a biometric parameter to enhance security of wireless sensors’ networks. The proposed scheme is demonstrated secure against some attacks such as DoS attack and sensor impersonation attack.In 2012, He et al. [25] proposed an authentication protocol, which is efficient for actual medical applications that are based on sensor network. Nevertheless, the scheme is prone to forgery attack and password guessing attack. In addition, it is not capable to offer forward privacy service. In 2014, Mishra et al. [26] rely on chaotic map computation for presenting an authentication and key exchanging protocol for healthcare information organisms. However, this scheme is vulnerable to against password guessing attack.In 2015, Jiang et al. [27] proved that the protocol proposed by Chen et al. [28] is not secured against password guessing attack. Consequently, with the goal to resolve this issue, Jiang et al. projected a different authentication scheme. Nonetheless, the planned solution is still vulnerable to password guessing and user impersonation attack.In 2019, Azrour et al. [29] demonstrated that Ye et al.’s [30] protocol is not secured and it has some security issues. In the same year, Cheng et al. [31], based on elliptical curve cryptography and biometrics, proposed a public node identity authentication scheme for numerous categories of devices. In 2020, Azrour et al. [32] proposed a new authentication protocol for IoT devices. Then, authors proved formally and informally that their protocol is efficient and can resist against several attacks.


## 3. Evaluation of Sharma and Kalra’s Protocol

In the present section, we present a brief review of three main phases of Sharma and Kalra’s scheme, namely, registration, login, and authentication phases. Used notations and their significations are described in Table1.Table 1
Notations and their significations.
SymbolSignificationUiUser (medical professional)IdiUser’sUi identitypwUser’sUi passwordSNiThe sensor nodeGNGateway nodeIdsnIdentity of sensor nodeCSCloud serverXsSecret key of CSKCS−SNiShared session key between CS andSNiT1,T2,T3,T4The current timeA,B,C,DHigh entropy random numbershHash function⊕XOR operator||Concatenation operator


### 3.1. Registration Phase

Step 1: userUi selects her/his identity Id, password pw, and arbitrary number R. He/she computes MPS=hpw‖Rand sends Id,MPSto the server via secured channel.Step 2: server checks received Id. If it exists in database, the server requests a new Id. In other case, the server computes=HMPS‖Id, b=AId‖K, c=HK⊕HMPS‖b, and d=b⊕HMPS‖a. Afterwards, server sends back to user a,c, and d.Step 3: user savesa,c,d,R in it smart card.


### 3.2. Login Phase

Sharma and Kalra’s scheme login phase contains three steps:Step 1: userUi inserts her/his identity Id and password pw in the smart device.Step 2: the smart device calculatesMPS=hpw‖Rbased on input pw and stored R.Step 3: the smart device computesa′=HMPS‖Id and compares its value with stored a. In this case, it equals the login phase which is a success.


### 3.3. Authentication Phase

In this phase, the userUi, the sensor, and the gateway node have to authenticate each other mutually and produce the session key. The steps of this phase areStep 1: the smart device calculatesb=d⊕HMPS‖a and HK=c⊕HMPS‖b. It generates timestamp T1 and computes V1=Id⊕HHK‖T1. Then, it chooses random Ni and computes V2=N⊕Hb‖T1 and V3=HV1‖V2‖Ni‖T1. Next, it transfers this message to gateway node (GN) V1,V2,V3,T1,IdSN.Step 2: after receiving user’s massage, the GN verifies the timestamp. Then, it calculatesMIDSN=IdSN⊕HHK‖z2. It generates random numberNj, which is used for computing V4=HXGN−SN‖T1‖T2⊕Nj and V5=HIdSN‖V4‖T1‖T2‖Nj. The GN then communicates this message V1,V2,V3,T1,T2,MIDSN,V4,V5 to the SN.Step 3: upon receiving GN message, the SN verifies the timestamp. Then, it calculatesIdSN′=MIdSN⊕HHK‖T2, XGN−SN′=IdSN, and Nj′=V4⊕HXGN−SN′‖T1‖T2. Formerly, it checks V5′=HIdSN‖V4‖T1‖T2‖Nj′. If it is correct, the GN is authenticated. Next, SN computes Id′=V1⊕HHK‖T1, b′=HId‖K, and Ni′=V2⊕Hb′‖T1. Then, it checks the validity of V3′=HV1‖V2‖Ni′‖T1. If it is ok, the user was authenticated. Therefore, the SN computes its parameters V6, V7, V8, and V9 that will be sent to GN. V6=Nj′⊕Hb′‖T3, V7=Ni′⊕HXGN−SN′‖T3, V8=HV6‖b′‖T3, and V9=HV7‖XGN−SN′‖T3.Step 4: once the GN receives SN response, it verifies the timestamp. Then, it checks the correctness ofV9′=HV7‖XGN−SN′‖T3. It computes ′=V7⊕HXGN−SN′‖T3, Sk=HNi′⊕Nj, and V10=HSk‖V6‖V8‖T3‖T4. Next, the GN sends to the user this message: V6,V8,V10,T3,T4.Step 5: in this step, the user verifies the validity of timestamp. Then, he/she checks the authenticity ofV8′=HV6‖b′‖T3 and calculates Nj′=V6⊕Hb′‖T3 and Sk=HNi⊕Nj′. Finally, the user checks the correctness of V10′=HSk‖V6‖V8‖T3‖T4.


## 3.1. Registration Phase

Step 1: userUi selects her/his identity Id, password pw, and arbitrary number R. He/she computes MPS=hpw‖Rand sends Id,MPSto the server via secured channel.Step 2: server checks received Id. If it exists in database, the server requests a new Id. In other case, the server computes=HMPS‖Id, b=AId‖K, c=HK⊕HMPS‖b, and d=b⊕HMPS‖a. Afterwards, server sends back to user a,c, and d.Step 3: user savesa,c,d,R in it smart card.


## 3.2. Login Phase

Sharma and Kalra’s scheme login phase contains three steps:Step 1: userUi inserts her/his identity Id and password pw in the smart device.Step 2: the smart device calculatesMPS=hpw‖Rbased on input pw and stored R.Step 3: the smart device computesa′=HMPS‖Id and compares its value with stored a. In this case, it equals the login phase which is a success.


## 3.3. Authentication Phase

In this phase, the userUi, the sensor, and the gateway node have to authenticate each other mutually and produce the session key. The steps of this phase areStep 1: the smart device calculatesb=d⊕HMPS‖a and HK=c⊕HMPS‖b. It generates timestamp T1 and computes V1=Id⊕HHK‖T1. Then, it chooses random Ni and computes V2=N⊕Hb‖T1 and V3=HV1‖V2‖Ni‖T1. Next, it transfers this message to gateway node (GN) V1,V2,V3,T1,IdSN.Step 2: after receiving user’s massage, the GN verifies the timestamp. Then, it calculatesMIDSN=IdSN⊕HHK‖z2. It generates random numberNj, which is used for computing V4=HXGN−SN‖T1‖T2⊕Nj and V5=HIdSN‖V4‖T1‖T2‖Nj. The GN then communicates this message V1,V2,V3,T1,T2,MIDSN,V4,V5 to the SN.Step 3: upon receiving GN message, the SN verifies the timestamp. Then, it calculatesIdSN′=MIdSN⊕HHK‖T2, XGN−SN′=IdSN, and Nj′=V4⊕HXGN−SN′‖T1‖T2. Formerly, it checks V5′=HIdSN‖V4‖T1‖T2‖Nj′. If it is correct, the GN is authenticated. Next, SN computes Id′=V1⊕HHK‖T1, b′=HId‖K, and Ni′=V2⊕Hb′‖T1. Then, it checks the validity of V3′=HV1‖V2‖Ni′‖T1. If it is ok, the user was authenticated. Therefore, the SN computes its parameters V6, V7, V8, and V9 that will be sent to GN. V6=Nj′⊕Hb′‖T3, V7=Ni′⊕HXGN−SN′‖T3, V8=HV6‖b′‖T3, and V9=HV7‖XGN−SN′‖T3.Step 4: once the GN receives SN response, it verifies the timestamp. Then, it checks the correctness ofV9′=HV7‖XGN−SN′‖T3. It computes ′=V7⊕HXGN−SN′‖T3, Sk=HNi′⊕Nj, and V10=HSk‖V6‖V8‖T3‖T4. Next, the GN sends to the user this message: V6,V8,V10,T3,T4.Step 5: in this step, the user verifies the validity of timestamp. Then, he/she checks the authenticity ofV8′=HV6‖b′‖T3 and calculates Nj′=V6⊕Hb′‖T3 and Sk=HNi⊕Nj′. Finally, the user checks the correctness of V10′=HSk‖V6‖V8‖T3‖T4.


## 4. Weaknesses of Sharma and Kalra’s Protocol

In this section, we demonstrate that user authentication scheme for cloud-IoT-based healthcare services suggested by Sharma and Kalra is defenceless against offline password guessing attacks, and it has some security issues.


### 4.1. User Password Guessing Attack

Sharma and Kalra proved that their protocol can resist against offline password guessing attack even if the smart card is stolen. In opposition to this, we can prove her that an adversary can guess user’s password. To do that, he/she has to steal the user’s smart card and then recover the value ofR1andai. Afterword, the adversary runs the dictionary attack to guess the correct password. As it is clear in Figure 2, adversary selects a guessed password from passwords dictionary. Then, he/she computes the value of MPS″←hpw‖R1 and the value of hMPS″‖Idi; if the second value equals ai, the guessed password is correct. Otherwise, the adversary selects another password until discovering the correct one.Figure 2
Algorithm for guessing password offline.


### 4.2. Impersonation Attack

Sharma and Kalra demonstrated that their proposed protocol can resist against numerous attacks including impersonation attack. However, in this section, we demonstrate that the user impersonation attack is still operative in Sharma and Kalra’s authentication scheme. Accept that an adversary has obtained the contents of a smartcard. He/she can execute the pervious attack to get user’s parameters (login and password); then, he/she makes a forged authentication request.The pirate inserts stolen smart card. Next, he/she enters the deducedID′ and Pw′. Subsequent, the smart device computes the values of MPS′=hPw′R and a′=HMPS′Id′. Then, it verifies if a′=?a. The equality will be true because the guessed parameters are verified in the previous attack. Afterward, the smart device will execute the authentication phase. It computes b′=d⊕HMPS′a′ and HK=c⊕HMPS′b′. It generates timestamp T1 and computes V1=Id⊕HHK‖T1. Then, it chooses random Ni and computes V2=N⊕Hb‖T1 and V3=HV1‖V2‖Ni‖T1. Next, it transfers this message to gateway node (GN) <V1,V2,V3,T1,IdSN.The remainder of the protocol will run normally. The gateway node and sensor node will authenticate the pirate as the valid user and then share with them the session key successfully. Therefore, the pirate can execute user impersonation attack successfully if he has stolen the smart card contents.


### 4.3. Other Security Issues

Authentication phase is an essential and main phase in all authentication protocols. Indeed, it is a step that assures verification of user identity, allowing authorization and constructing session keys. In healthcare field, it is a key for establishing a secured connection with the remote server and for protecting patient private data. Therefore, it must receive much importance. In our cryptanalysis of Sharma and Kalra authentication protocol for cloud-IoT-based healthcare service, we have observed that there are double serious mistakes. Initially, the sensor node utilizes value of K which is the secret master key of gateway node (GN). Normally, the secret master key of gateway node is a private key. Accordingly, it must be a secret and should not be known to anyone. Otherwise, all systems are at risk and all secret messages will be discovered by any attacker. Secondly, authors propose that the secret shared between the gateway node and sensor node (SNi) is XGN−SNi which is computed as XGN−SNi=hIdSNi. However, the value of IdSNi is clearly (not encrypted or hashed) in the first message sent by user Ui to gateway node (GN). Consequently, if an adversary intercepts this message, he can get easily IdSNi. Then, he is able to compute XGN−SNi.


## 4.1. User Password Guessing Attack

Sharma and Kalra proved that their protocol can resist against offline password guessing attack even if the smart card is stolen. In opposition to this, we can prove her that an adversary can guess user’s password. To do that, he/she has to steal the user’s smart card and then recover the value ofR1andai. Afterword, the adversary runs the dictionary attack to guess the correct password. As it is clear in Figure 2, adversary selects a guessed password from passwords dictionary. Then, he/she computes the value of MPS″←hpw‖R1 and the value of hMPS″‖Idi; if the second value equals ai, the guessed password is correct. Otherwise, the adversary selects another password until discovering the correct one.Figure 2
Algorithm for guessing password offline.


## 4.2. Impersonation Attack

Sharma and Kalra demonstrated that their proposed protocol can resist against numerous attacks including impersonation attack. However, in this section, we demonstrate that the user impersonation attack is still operative in Sharma and Kalra’s authentication scheme. Accept that an adversary has obtained the contents of a smartcard. He/she can execute the pervious attack to get user’s parameters (login and password); then, he/she makes a forged authentication request.The pirate inserts stolen smart card. Next, he/she enters the deducedID′ and Pw′. Subsequent, the smart device computes the values of MPS′=hPw′R and a′=HMPS′Id′. Then, it verifies if a′=?a. The equality will be true because the guessed parameters are verified in the previous attack. Afterward, the smart device will execute the authentication phase. It computes b′=d⊕HMPS′a′ and HK=c⊕HMPS′b′. It generates timestamp T1 and computes V1=Id⊕HHK‖T1. Then, it chooses random Ni and computes V2=N⊕Hb‖T1 and V3=HV1‖V2‖Ni‖T1. Next, it transfers this message to gateway node (GN) <V1,V2,V3,T1,IdSN.The remainder of the protocol will run normally. The gateway node and sensor node will authenticate the pirate as the valid user and then share with them the session key successfully. Therefore, the pirate can execute user impersonation attack successfully if he has stolen the smart card contents.


## 4.3. Other Security Issues

Authentication phase is an essential and main phase in all authentication protocols. Indeed, it is a step that assures verification of user identity, allowing authorization and constructing session keys. In healthcare field, it is a key for establishing a secured connection with the remote server and for protecting patient private data. Therefore, it must receive much importance. In our cryptanalysis of Sharma and Kalra authentication protocol for cloud-IoT-based healthcare service, we have observed that there are double serious mistakes. Initially, the sensor node utilizes value of K which is the secret master key of gateway node (GN). Normally, the secret master key of gateway node is a private key. Accordingly, it must be a secret and should not be known to anyone. Otherwise, all systems are at risk and all secret messages will be discovered by any attacker. Secondly, authors propose that the secret shared between the gateway node and sensor node (SNi) is XGN−SNi which is computed as XGN−SNi=hIdSNi. However, the value of IdSNi is clearly (not encrypted or hashed) in the first message sent by user Ui to gateway node (GN). Consequently, if an adversary intercepts this message, he can get easily IdSNi. Then, he is able to compute XGN−SNi.


## 5. Our Proposed Scheme

In this section, we present our new efficient and secured authentication protocol for remote healthcare systems in cloud-IoT. The proposed scheme entails five phases, including system setup phase, new sensor registration phase, user registration phase, login and authentication phase, and password changing phase.


### 5.1. System Setup Phase

In this phase, the superadmin chooses secret key of cloud serverXs and one way hash function h. Finally, the server publishes h and saves its private key secretly.


### 5.2. New Sensor Registration Phase

To implement a newly connected sensor node (SNi) in an already functioning healthcare system, the cloud server has to randomly select both specific Idsn and KCS−SNi as the identification and unique key of the added sensor, respectively. The gateway subsequently uploads Idsn and SK=hIdsn‖KCS−SNidata to the sensor memory before running it. In addition, it saves Idsn and HSK=SK⊕hXs‖IdSN in its local database for eventual future utilization.


### 5.3. User Registration Phase

In order to create a count in the cloud server, a medical professional has to perform registration steps with the cloud server. The details of this phase are illustrated in Figure3.Step 1: the medical professional selects freely appropriate identityIdi and suitable password pwi. Afterword, he picks arbitrarily two numbers a and b. Next, he calculates MID=hIdi‖a and MPW=hIdiib. The two last values are transferred to the cloud server using a secured canal.Step 2: the cloud serverCS picks c randomly and computes V=hMID‖Xs⊕hMPW‖c. Next, the CS saves MIDand c in local database and transmits V to medical professional.Step 3: the medical professional memorizes that informationV,a,b,MID in a smart card.Figure 3
Registration phase.


### 5.4. Login and Authentication Phase

Once medical professional has accomplished successfully the registration process, he can connect to any sensor node. For doing that, the medical professional must accomplish the login phase by inserting his smart card. Subsequently, the authentication phase is executed. After successful login and authentication, the medical professional is allowed to interact with medical sensor nodes in real time. The steps of login and authentication phase are described below and are depicted in Figure4.Step_Auth1:U⟶CS : V1,MID,A,IdSN,T1Firstly, medical professional user types his/herIdiandpwi, and the smart card verifies user’s identity by checking MID=?hIdi‖a. If it is not OK, the process stops. Otherwise, the smart card picks randomly an integer A. Then, it computes x=V⊕hhIdipwib‖c and V1=hx‖A. Subsequently, it sends to the cloud server this message V1,MID,A,IdSN,T1.Step_Auth2:CS⟶SN : V2,B,MID,T2After receiving user’s communication, the cloud server checks the timestampT2−T1≤T. Then, it computes w1=hMID‖Xs and verifies if V1=?hw1‖A. In the case it is validate, the cloud server generates randomly an integer B. Hence, it calculates w2=HSK⊕hIdsn‖Xs, HID=hMID‖IdSN, and V2=hHID‖w2‖T2‖B Finally, the cloud server forwards this message to the sensor node V2,B,MID,T2.Step_Auth3:SN⟶CS: V3,C,HID,IdSN,T3Once the sensor nodeSN obtains the message sent by CS. First of all, it checks the authenticity of timestamp T3−T2≤ΔT. Next, it calculates the value of HID′=hMID‖IdSN. Then, it checks whether V2=?hHID′‖SK‖T2‖B is valid or not. If it is OK, the sensor node SN chooses random integer C and computes V3=hMIDIdSN|SK|T3‖C which is sent back to the cloud server with other values V3,C,HID,IdSN,T3.Step_Auth4:CS⟶U: V4,D,IdSN,T4When sensor’s response is reaching to the cloud server, this last one verifies the validity of timestampT4−T3≤ΔT. Subsequently, it checks if V3=?hMID‖w2‖T3‖C is correct or not. In the case that it is reasonable, and the cloud server picks randomly an integer D. At that moment, it computes V4=hw1MIDIdSNT4‖D and the session key SKey=hw1‖MID‖IdSN. After that, the cloud server sends back the response to the medical professional user V4,D,IdSN,T4}.Step_Auth5:After reception of cloud server reply, the medical professional user checks the correctness of the timestampT5−T4≤ΔT. Hence, it authenticates the cloud server’s message by checking if V4=?hxMIDIdSN‖T4‖D is true or false. In the case that it is OK, the medical professional user generates the session key SKey=hxMIDIdSN.Figure 4
Login and authentication phase.


### 5.5. Password Changing Phase

Naturally, our proposed authentication protocol gives to the medical professional user the possibility to alter his/her password spontaneously. This operation can be completed in a public channel. The steps of this phase are illustrated in Figure5. Besides, they are detailed in the following.Step_Chang1:U⟶CS:MuIn this step, medical professional userU types in it login and password Idiandpwi . Afterwards, he/she verifies MID=?hIdi‖a. If it is all right, the user selects freely his/her new password pwi∗ and chooses two arbitrary numbers a∗and b∗. Next, he/she computes MID∗=hIdi‖a∗ and MPW∗=hIdi|pwi∗b∗|. Finally, he/she encrypts the message Mu=ESKMPWMPW∗MIDMID∗V which will be sent to the cloud server.Step_Chang2:⟶U:MsAfter receiving user’s request the server decrypts the received messageMu′=DSKMPWMPW∗MIDMID∗V. Then, it checks whether V=?hMID‖Xs⊕hMPW‖c is correct or not. If it is OK, the server selects randomly c∗. Then, it replaces MID andc by MID∗andc∗, respectively. Next, it computesV∗=hMID∗‖Xs⊕hMPW∗‖c∗ and Ms=ESKV∗. Finally, the server sends back to the user the message Ms.Step_Chang3Once the server response was received by the user, this last one decrypts the messageMs′=DSKV∗ and replaces V,a,b,and MID by V∗,a∗,b∗andMID∗ respectively.Figure 5
Password changing phase.


## 5.1. System Setup Phase

In this phase, the superadmin chooses secret key of cloud serverXs and one way hash function h. Finally, the server publishes h and saves its private key secretly.


## 5.2. New Sensor Registration Phase

To implement a newly connected sensor node (SNi) in an already functioning healthcare system, the cloud server has to randomly select both specific Idsn and KCS−SNi as the identification and unique key of the added sensor, respectively. The gateway subsequently uploads Idsn and SK=hIdsn‖KCS−SNidata to the sensor memory before running it. In addition, it saves Idsn and HSK=SK⊕hXs‖IdSN in its local database for eventual future utilization.


## 5.3. User Registration Phase

In order to create a count in the cloud server, a medical professional has to perform registration steps with the cloud server. The details of this phase are illustrated in Figure3.Step 1: the medical professional selects freely appropriate identityIdi and suitable password pwi. Afterword, he picks arbitrarily two numbers a and b. Next, he calculates MID=hIdi‖a and MPW=hIdiib. The two last values are transferred to the cloud server using a secured canal.Step 2: the cloud serverCS picks c randomly and computes V=hMID‖Xs⊕hMPW‖c. Next, the CS saves MIDand c in local database and transmits V to medical professional.Step 3: the medical professional memorizes that informationV,a,b,MID in a smart card.Figure 3
Registration phase.


## 5.4. Login and Authentication Phase

Once medical professional has accomplished successfully the registration process, he can connect to any sensor node. For doing that, the medical professional must accomplish the login phase by inserting his smart card. Subsequently, the authentication phase is executed. After successful login and authentication, the medical professional is allowed to interact with medical sensor nodes in real time. The steps of login and authentication phase are described below and are depicted in Figure4.Step_Auth1:U⟶CS : V1,MID,A,IdSN,T1Firstly, medical professional user types his/herIdiandpwi, and the smart card verifies user’s identity by checking MID=?hIdi‖a. If it is not OK, the process stops. Otherwise, the smart card picks randomly an integer A. Then, it computes x=V⊕hhIdipwib‖c and V1=hx‖A. Subsequently, it sends to the cloud server this message V1,MID,A,IdSN,T1.Step_Auth2:CS⟶SN : V2,B,MID,T2After receiving user’s communication, the cloud server checks the timestampT2−T1≤T. Then, it computes w1=hMID‖Xs and verifies if V1=?hw1‖A. In the case it is validate, the cloud server generates randomly an integer B. Hence, it calculates w2=HSK⊕hIdsn‖Xs, HID=hMID‖IdSN, and V2=hHID‖w2‖T2‖B Finally, the cloud server forwards this message to the sensor node V2,B,MID,T2.Step_Auth3:SN⟶CS: V3,C,HID,IdSN,T3Once the sensor nodeSN obtains the message sent by CS. First of all, it checks the authenticity of timestamp T3−T2≤ΔT. Next, it calculates the value of HID′=hMID‖IdSN. Then, it checks whether V2=?hHID′‖SK‖T2‖B is valid or not. If it is OK, the sensor node SN chooses random integer C and computes V3=hMIDIdSN|SK|T3‖C which is sent back to the cloud server with other values V3,C,HID,IdSN,T3.Step_Auth4:CS⟶U: V4,D,IdSN,T4When sensor’s response is reaching to the cloud server, this last one verifies the validity of timestampT4−T3≤ΔT. Subsequently, it checks if V3=?hMID‖w2‖T3‖C is correct or not. In the case that it is reasonable, and the cloud server picks randomly an integer D. At that moment, it computes V4=hw1MIDIdSNT4‖D and the session key SKey=hw1‖MID‖IdSN. After that, the cloud server sends back the response to the medical professional user V4,D,IdSN,T4}.Step_Auth5:After reception of cloud server reply, the medical professional user checks the correctness of the timestampT5−T4≤ΔT. Hence, it authenticates the cloud server’s message by checking if V4=?hxMIDIdSN‖T4‖D is true or false. In the case that it is OK, the medical professional user generates the session key SKey=hxMIDIdSN.Figure 4
Login and authentication phase.


## 5.5. Password Changing Phase

Naturally, our proposed authentication protocol gives to the medical professional user the possibility to alter his/her password spontaneously. This operation can be completed in a public channel. The steps of this phase are illustrated in Figure5. Besides, they are detailed in the following.Step_Chang1:U⟶CS:MuIn this step, medical professional userU types in it login and password Idiandpwi . Afterwards, he/she verifies MID=?hIdi‖a. If it is all right, the user selects freely his/her new password pwi∗ and chooses two arbitrary numbers a∗and b∗. Next, he/she computes MID∗=hIdi‖a∗ and MPW∗=hIdi|pwi∗b∗|. Finally, he/she encrypts the message Mu=ESKMPWMPW∗MIDMID∗V which will be sent to the cloud server.Step_Chang2:⟶U:MsAfter receiving user’s request the server decrypts the received messageMu′=DSKMPWMPW∗MIDMID∗V. Then, it checks whether V=?hMID‖Xs⊕hMPW‖c is correct or not. If it is OK, the server selects randomly c∗. Then, it replaces MID andc by MID∗andc∗, respectively. Next, it computesV∗=hMID∗‖Xs⊕hMPW∗‖c∗ and Ms=ESKV∗. Finally, the server sends back to the user the message Ms.Step_Chang3Once the server response was received by the user, this last one decrypts the messageMs′=DSKV∗ and replaces V,a,b,and MID by V∗,a∗,b∗andMID∗ respectively.Figure 5
Password changing phase.


## 6. Informal and Formal Analyses

In this section, we will analyze the security of our proposed protocol against numerous security attacks. As well as, we present its security properties, including mutual authentication, data integrity, user anonymity, session key exchanging, and forward secrecy (Table2). The security of our proposed scheme is proved by both informal and formal analysis.Table 2
Security feature’s comparison.
Kumar et al. [33]He et al [34]Amin et al [35]Sharma and Kalra [14]OursMutual authentication✓✓✓✓✓Data integrity✓✓✓✓✓No verification table✗✗✓✓✓Session key exchanging✓✓✓✓✓DoS attack✓✓✓✓✓Perfect forward secrecy✗✗✗✓✓Off-line password guessing attack✗✗✗✗✓Replay attack✗✗✗✓✓Insider attack✗✗✗✓✓✓: secured against attack. ✗: not secured against attack.


### 6.1. Informal Analyses

#### 6.1.1. Session Key Exchanging

In our proposed protocol, the session key is generated by the user and cloud server asSKey=hxMIDIdSN, where x=V⊕hhIdipwi|b‖c=hMID‖Xs. Thanks to the reason that Xs and MID are secret, and the session key cannot be known at the end of login and authentication phase except for the medical professional user and the cloud server. As a result, we can say that the proposed scheme guarantees session key secrecy.


#### 6.1.2. Mutual Authentication

In a public unsecured channel, each entity has authenticated each other before authentic communication takes place. So, owing to the advantages of mutual authentication in a network environment, our planned protocol reassures mutual authentication. Hence, the cloud server authenticates both the medical professional user and the sensor node. To verify users authenticity in Step 2, the server checks the correctness of receivedV1. For checking the sensor identity, in Step 4, the cloud server verifies the exactness of V3=?hMID‖w2‖T3‖C. Additionally, the medical professional user is able to authenticate the cloud server identity in Step 5, through examination of the legitimacy of V4=?hxMID|IdSN‖T4‖D. Hereafter, in Step 3, the sensor node also authenticates cloud servers’ message by checking the accuracy of V2=?hHID′‖SK‖T2‖B.


#### 6.1.3. Data Integrity

It is very essential, while forwarding information between the various IoT terminals, to ensure that the data are correct and belong to the authenticated sender. Besides, it is very indispensable to ensure that the data have not been falsified by the authorities during the transfer by invoking fraudulent acts or forgery attacks. In the proposed protocol, if we suppose that an attacker capturesV1, V2, V3, or V4. Then, he tries to alter their values. However, the receivers will detect this modification using the timestamp. In addition, the modification timestamps will be identified since the timestamps are embedded into V1, V2, V3, and V4.


#### 6.1.4. DoS Attack

Our proposed authentication protocol can resist against DoS attack. Accordingly, the user is able to know if her/his message has passed the authentication phase or not, especially, after getting server’s response which can be validated or rejected message. With goals to verify the freshness of received message, our protocol uses timestamps. Furthermore, arbitrary numbers are produced in every stage and in every session. Besides, since the duplicated messages are unacceptable, the attacker is not able to perform the DoS attack. Thus, our suggested method can resist against DoS attack.


#### 6.1.5. No Verification Table

According to the proposed protocol, the confidential information of each user, including the password, is not stored by the cloud server or the sensors. In case an attacker succeeds in the hacking cloud server or node, he/she would not be actually capable of obtaining the password checking data. Therefore, the hacker will not be able to retrieve any authenticating details.


#### 6.1.6. Off-Line Password Guessing Attack

Assume that an attacker has got the smart card. Then, he/she extracts all stored parameters in it. If he/she wants to guess the password, he/she cannot, since the only value that contains password isV=hMID‖Xs⊕hMPW‖c. Therefore, the attacker has to know the value of Xs and Idi. However, Idi is encrypted using one-way hash function, and Xs is server’s private key. Consequently, we can conclude that our proposed scheme is secure against offline password guessing attack.


#### 6.1.7. Replay Attack

Assume that an adversary replays the old message to the server. In our proposed protocol, the cloud server discovers that this message is not fresh. Originally, the cloud server checks the validity of timestampT2−T1≤ΔT; in the case that it is noted valid, the session stops. The same thing happens after receiving sensor node’s message T4−T3≤ΔT. The sensor node and user use T3−T2≤ΔT and T5−T4≤ΔT, respectively, to check the newness of cloud server’s message. Consequently, our proposed protocol can withstand against replay attack.


#### 6.1.8. Insider Attack

Our proposed scheme can resist against privileged insider attack. Assume that a malicious or pirate has an access the registration data {MID,c }. Even if we have those data, the attacker can neither guess the password nor initiate any kind of counterfeit attack. Furthermore, he/she must fight the secrecy of one way hash function if he/she wants to have just the user Id. On the contrary, for initiating impersonation attack, the attacker must have access to cloud server’s secret key. Consequently, our proposed protocol can resist against privileged insider attack.


#### 6.1.9. Perfect Forward Secrecy

In our proposed protocol, the session keySKey is computed as SKey=hw1MIDIdSN, where w1=hMID‖Xs. The session key contains server’s secret key Xs and users MID that depend on user’s encrypted Idi. In other words, the session key SKey depends on secure parameters which are not accessible to the attacker. Consequently, our proposal assures perfect forward secrecy.


## 6.1. Informal Analyses

### 6.1.1. Session Key Exchanging

In our proposed protocol, the session key is generated by the user and cloud server asSKey=hxMIDIdSN, where x=V⊕hhIdipwi|b‖c=hMID‖Xs. Thanks to the reason that Xs and MID are secret, and the session key cannot be known at the end of login and authentication phase except for the medical professional user and the cloud server. As a result, we can say that the proposed scheme guarantees session key secrecy.


### 6.1.2. Mutual Authentication

In a public unsecured channel, each entity has authenticated each other before authentic communication takes place. So, owing to the advantages of mutual authentication in a network environment, our planned protocol reassures mutual authentication. Hence, the cloud server authenticates both the medical professional user and the sensor node. To verify users authenticity in Step 2, the server checks the correctness of receivedV1. For checking the sensor identity, in Step 4, the cloud server verifies the exactness of V3=?hMID‖w2‖T3‖C. Additionally, the medical professional user is able to authenticate the cloud server identity in Step 5, through examination of the legitimacy of V4=?hxMID|IdSN‖T4‖D. Hereafter, in Step 3, the sensor node also authenticates cloud servers’ message by checking the accuracy of V2=?hHID′‖SK‖T2‖B.


### 6.1.3. Data Integrity

It is very essential, while forwarding information between the various IoT terminals, to ensure that the data are correct and belong to the authenticated sender. Besides, it is very indispensable to ensure that the data have not been falsified by the authorities during the transfer by invoking fraudulent acts or forgery attacks. In the proposed protocol, if we suppose that an attacker capturesV1, V2, V3, or V4. Then, he tries to alter their values. However, the receivers will detect this modification using the timestamp. In addition, the modification timestamps will be identified since the timestamps are embedded into V1, V2, V3, and V4.


### 6.1.4. DoS Attack

Our proposed authentication protocol can resist against DoS attack. Accordingly, the user is able to know if her/his message has passed the authentication phase or not, especially, after getting server’s response which can be validated or rejected message. With goals to verify the freshness of received message, our protocol uses timestamps. Furthermore, arbitrary numbers are produced in every stage and in every session. Besides, since the duplicated messages are unacceptable, the attacker is not able to perform the DoS attack. Thus, our suggested method can resist against DoS attack.


### 6.1.5. No Verification Table

According to the proposed protocol, the confidential information of each user, including the password, is not stored by the cloud server or the sensors. In case an attacker succeeds in the hacking cloud server or node, he/she would not be actually capable of obtaining the password checking data. Therefore, the hacker will not be able to retrieve any authenticating details.


### 6.1.6. Off-Line Password Guessing Attack

Assume that an attacker has got the smart card. Then, he/she extracts all stored parameters in it. If he/she wants to guess the password, he/she cannot, since the only value that contains password isV=hMID‖Xs⊕hMPW‖c. Therefore, the attacker has to know the value of Xs and Idi. However, Idi is encrypted using one-way hash function, and Xs is server’s private key. Consequently, we can conclude that our proposed scheme is secure against offline password guessing attack.


### 6.1.7. Replay Attack

Assume that an adversary replays the old message to the server. In our proposed protocol, the cloud server discovers that this message is not fresh. Originally, the cloud server checks the validity of timestampT2−T1≤ΔT; in the case that it is noted valid, the session stops. The same thing happens after receiving sensor node’s message T4−T3≤ΔT. The sensor node and user use T3−T2≤ΔT and T5−T4≤ΔT, respectively, to check the newness of cloud server’s message. Consequently, our proposed protocol can withstand against replay attack.


### 6.1.8. Insider Attack

Our proposed scheme can resist against privileged insider attack. Assume that a malicious or pirate has an access the registration data {MID,c }. Even if we have those data, the attacker can neither guess the password nor initiate any kind of counterfeit attack. Furthermore, he/she must fight the secrecy of one way hash function if he/she wants to have just the user Id. On the contrary, for initiating impersonation attack, the attacker must have access to cloud server’s secret key. Consequently, our proposed protocol can resist against privileged insider attack.


### 6.1.9. Perfect Forward Secrecy

In our proposed protocol, the session keySKey is computed as SKey=hw1MIDIdSN, where w1=hMID‖Xs. The session key contains server’s secret key Xs and users MID that depend on user’s encrypted Idi. In other words, the session key SKey depends on secure parameters which are not accessible to the attacker. Consequently, our proposal assures perfect forward secrecy.


## 6.1.1. Session Key Exchanging

In our proposed protocol, the session key is generated by the user and cloud server asSKey=hxMIDIdSN, where x=V⊕hhIdipwi|b‖c=hMID‖Xs. Thanks to the reason that Xs and MID are secret, and the session key cannot be known at the end of login and authentication phase except for the medical professional user and the cloud server. As a result, we can say that the proposed scheme guarantees session key secrecy.


## 6.1.2. Mutual Authentication

In a public unsecured channel, each entity has authenticated each other before authentic communication takes place. So, owing to the advantages of mutual authentication in a network environment, our planned protocol reassures mutual authentication. Hence, the cloud server authenticates both the medical professional user and the sensor node. To verify users authenticity in Step 2, the server checks the correctness of receivedV1. For checking the sensor identity, in Step 4, the cloud server verifies the exactness of V3=?hMID‖w2‖T3‖C. Additionally, the medical professional user is able to authenticate the cloud server identity in Step 5, through examination of the legitimacy of V4=?hxMID|IdSN‖T4‖D. Hereafter, in Step 3, the sensor node also authenticates cloud servers’ message by checking the accuracy of V2=?hHID′‖SK‖T2‖B.


## 6.1.3. Data Integrity

It is very essential, while forwarding information between the various IoT terminals, to ensure that the data are correct and belong to the authenticated sender. Besides, it is very indispensable to ensure that the data have not been falsified by the authorities during the transfer by invoking fraudulent acts or forgery attacks. In the proposed protocol, if we suppose that an attacker capturesV1, V2, V3, or V4. Then, he tries to alter their values. However, the receivers will detect this modification using the timestamp. In addition, the modification timestamps will be identified since the timestamps are embedded into V1, V2, V3, and V4.


## 6.1.4. DoS Attack

Our proposed authentication protocol can resist against DoS attack. Accordingly, the user is able to know if her/his message has passed the authentication phase or not, especially, after getting server’s response which can be validated or rejected message. With goals to verify the freshness of received message, our protocol uses timestamps. Furthermore, arbitrary numbers are produced in every stage and in every session. Besides, since the duplicated messages are unacceptable, the attacker is not able to perform the DoS attack. Thus, our suggested method can resist against DoS attack.


## 6.1.5. No Verification Table

According to the proposed protocol, the confidential information of each user, including the password, is not stored by the cloud server or the sensors. In case an attacker succeeds in the hacking cloud server or node, he/she would not be actually capable of obtaining the password checking data. Therefore, the hacker will not be able to retrieve any authenticating details.


## 6.1.6. Off-Line Password Guessing Attack

Assume that an attacker has got the smart card. Then, he/she extracts all stored parameters in it. If he/she wants to guess the password, he/she cannot, since the only value that contains password isV=hMID‖Xs⊕hMPW‖c. Therefore, the attacker has to know the value of Xs and Idi. However, Idi is encrypted using one-way hash function, and Xs is server’s private key. Consequently, we can conclude that our proposed scheme is secure against offline password guessing attack.


## 6.1.7. Replay Attack

Assume that an adversary replays the old message to the server. In our proposed protocol, the cloud server discovers that this message is not fresh. Originally, the cloud server checks the validity of timestampT2−T1≤ΔT; in the case that it is noted valid, the session stops. The same thing happens after receiving sensor node’s message T4−T3≤ΔT. The sensor node and user use T3−T2≤ΔT and T5−T4≤ΔT, respectively, to check the newness of cloud server’s message. Consequently, our proposed protocol can withstand against replay attack.


## 6.1.8. Insider Attack

Our proposed scheme can resist against privileged insider attack. Assume that a malicious or pirate has an access the registration data {MID,c }. Even if we have those data, the attacker can neither guess the password nor initiate any kind of counterfeit attack. Furthermore, he/she must fight the secrecy of one way hash function if he/she wants to have just the user Id. On the contrary, for initiating impersonation attack, the attacker must have access to cloud server’s secret key. Consequently, our proposed protocol can resist against privileged insider attack.


## 6.1.9. Perfect Forward Secrecy

In our proposed protocol, the session keySKey is computed as SKey=hw1MIDIdSN, where w1=hMID‖Xs. The session key contains server’s secret key Xs and users MID that depend on user’s encrypted Idi. In other words, the session key SKey depends on secure parameters which are not accessible to the attacker. Consequently, our proposal assures perfect forward secrecy.


## 7. Formal Analyses

### 7.1. Security Examination Using Scyther

In this section, we initially clarify the usefulness of Scyther tool [36], which was useful for formal security examination of our proposed scheme. Formerly, we showed gained outcomes by using this tool. Absolutely, it is software for automatically checking of security protocols. It is based on a reverse analysis method. The requests correspond to the knowledge of the participants (source and destination) and also to the wishes of a possible hacker. Symmetric and asymmetric encryption, hash functions, and encryption keys are also embedded in Scyther.Our planned protocol is then written in the security protocol description language (SPDL). This specification allows us to specify different roles of the medical professional user, the cloud server, and the sensor node. In each role, event sequences are embedded including sending, receiving, declarations, and complaints. According to Figure6, which details the obtained results, we can notice that our protocol is secure against many attacks. Besides, it meets the necessary security-related fundamentals.Figure 6
Experimental test results.


### 7.2. Security Verification Using Random Oracle Model

Actually, the random oracle model is used for formal security analysis. In this analysis, we verify that a given attacker is not in measure to recover important secret values includingId,Pw,V1Idi, and session key SKey. In our study, the similar procedure presented in [37–39] is adopted. The random oracle is detailed in the following.Reveal: it produces the input of a hash function; letλ be absolutely from a specified hash output ψ, where ψ=fλ.Formula 1.
Let us suppose that an attacker has stool user’s smart device; in addition, he has the knowledge about the transactionsV1−V4,T1−T4,IdSN,MID that has been transmitted over an untrusted network. While, h is the hash function that is understood as a random oracle, and the introduced protocol is secured against the attacker to retrieve the Id,Pw,V1, and the session key SKey of legitimate user U.Proof.
Suppose that the attackerA has obtained user’s parameters Id and Pw by using smart card data V,a,b,MID and the intercepted messages V1−V4,T1−T4,IdSN,MID, and the tentative algorithm Tent1A,RPMAPhash defines the possibility of achievement Ach1 for Exp1A,RPMAPhash by means of the following specified function:(1)Ach1=Pb⋅Tent1A,RPMAPhash=1−1.
PbE denotes the probability for a given event E. In this experiment, we define the advantageous condition as FAv1t1,rq1=MaxAAch1, where Max is determined based on totally adversaries taking the execution time t1 and rq1 is the total maximum requests transmitted to the reveal oracle. Our presented protocol is secure against the adversary to discover Id,Pw, andV1 if FAv1t1,rq1≤ε for a small value of ε>0. The trial model Tent1A,RPMAPhash indicates that if the hacker is able to compute the inverse of the hash function, it can recover user’s parameters Id,Pw, andV1. Nevertheless, it is impossible to determine the reverse of this one-way hash function in polynomial period, such that FAv1t1,rq1≤ε for a small value of ε>0. Accordingly, we can say that our proposed scheme is safe from the attacker for obtaining Id,Pw,V1,andSKey.Formula 2.
If we suppose that the hash function behaves as random oracle and the attacker have intercepted the message forwarded on unsecured channelV1−V4,T1−T4,IdSN,MID, the attacker may not be able to calculate user's session key SKey.Proof.
If an attacker that intercepts the transferred messageV1−V4,T1−T4,IdSN,MID tries to generate user’s session key SKey, the probability of achievement Ach1 in this calculation is defined by the tentative algorithm Tent2A,RPMAPhash as(2)Ach2=Pb⋅Tent2A,RPMAPhash=1−1.
PbEdenotes the probability for a given event E. In this experiment, we define the advantageous function as FAv2t2,rq2=MaxAAch2, where Max is determined based on totally adversaries taking the execution time t1 and rq1 is the total maximum requests transmitted to the reveal oracle. Our presented protocol is secure against the adversary to discover SKey if FAv2t2,rq2≤ε for a small value of ε>0. The trial model Tent2A,RPMAPhash indicates that if the hacker is able to compute the inverse of the hash function, it can recover user’s parameters Id,Pw, andV1. Nevertheless, it is impossible to determine the reverse of this one-way hash function in legal period, such that FAv2t2,rq2≤ε for a small value of ε>0. Accordingly, we can close that our proposed scheme is safe from the attacker for computing SKey (Algorithm 1 and 2 ).Algorithm 1:Tent1A,RPMAPhash.
Begin(1)
Intercept the transmitted valuesV1,V4,MID,A,IdSN,T1,T4(2)
Call reveal oracle onV4 for getting value of xMIDIdSNT4DasxMIDIdSNT4D) ←reveal1V4(3)
Call reveal oracle onV1 for getting value of x‖Aasx‖A← reveal1V1(4)
Calculatex' =  V⊕hhIdi‖pwi‖b‖c(5)
If (x'=?x), then(6)
Extract the parametersV,a,b,MID from the mobile device.(7)
CalculatehhIdi‖pwi‖b‖c=V⊕x(8)
Call reveal oracle on inputhhIdi‖pwi‖b‖c to discover {hIdipwib‖c} as (hIdipwib‖c ← reveal1(hhIdipwib‖c.(9)
Call reveal oracle on inputhIdipwib to discover Idipwib as Idipwib ← reveal1 (hIdipwib.(10)
Ten, compute MID' = hIdi‖a(11)
If(MID′<i>=? </i>MID), thenAcceptIdi′,pwi′, and a′ as valid identity, password, and random number.Return (true)(12)
ElseReturn (false)(13)
End ifEnd.Algorithm 2:Tent2A,RPMAPhash.
Begin(14)
Intercept the transmitted valuesV1,V4,MID,A,IdSN,T1(15)
Call reveal oracle onV4 for getting value of xMIDIdSNT4DasxMIDIdSNT4D ←reveal1V4(16)
Call reveal oracle onV1 for getting value of x‖Aasx‖A← reveal1V1(17)
Calculatew1=hMID‖Xs(18)
Generate the session keySkey′=hw1MIDIdSN(19)
ComputeV4′=xMIDIdSNT4D(20)
If (V4′=?V4), thenAcceptSkey′=hw1MIDIdSN as effective user’s session key.Return (true)(21)
ElseReturn (false)(22)
End ifEnd.


## 7.1. Security Examination Using Scyther

In this section, we initially clarify the usefulness of Scyther tool [36], which was useful for formal security examination of our proposed scheme. Formerly, we showed gained outcomes by using this tool. Absolutely, it is software for automatically checking of security protocols. It is based on a reverse analysis method. The requests correspond to the knowledge of the participants (source and destination) and also to the wishes of a possible hacker. Symmetric and asymmetric encryption, hash functions, and encryption keys are also embedded in Scyther.Our planned protocol is then written in the security protocol description language (SPDL). This specification allows us to specify different roles of the medical professional user, the cloud server, and the sensor node. In each role, event sequences are embedded including sending, receiving, declarations, and complaints. According to Figure6, which details the obtained results, we can notice that our protocol is secure against many attacks. Besides, it meets the necessary security-related fundamentals.Figure 6
Experimental test results.


## 7.2. Security Verification Using Random Oracle Model

Actually, the random oracle model is used for formal security analysis. In this analysis, we verify that a given attacker is not in measure to recover important secret values includingId,Pw,V1Idi, and session key SKey. In our study, the similar procedure presented in [37–39] is adopted. The random oracle is detailed in the following.Reveal: it produces the input of a hash function; letλ be absolutely from a specified hash output ψ, where ψ=fλ.Formula 1.
Let us suppose that an attacker has stool user’s smart device; in addition, he has the knowledge about the transactionsV1−V4,T1−T4,IdSN,MID that has been transmitted over an untrusted network. While, h is the hash function that is understood as a random oracle, and the introduced protocol is secured against the attacker to retrieve the Id,Pw,V1, and the session key SKey of legitimate user U.Proof.
Suppose that the attackerA has obtained user’s parameters Id and Pw by using smart card data V,a,b,MID and the intercepted messages V1−V4,T1−T4,IdSN,MID, and the tentative algorithm Tent1A,RPMAPhash defines the possibility of achievement Ach1 for Exp1A,RPMAPhash by means of the following specified function:(1)Ach1=Pb⋅Tent1A,RPMAPhash=1−1.
PbE denotes the probability for a given event E. In this experiment, we define the advantageous condition as FAv1t1,rq1=MaxAAch1, where Max is determined based on totally adversaries taking the execution time t1 and rq1 is the total maximum requests transmitted to the reveal oracle. Our presented protocol is secure against the adversary to discover Id,Pw, andV1 if FAv1t1,rq1≤ε for a small value of ε>0. The trial model Tent1A,RPMAPhash indicates that if the hacker is able to compute the inverse of the hash function, it can recover user’s parameters Id,Pw, andV1. Nevertheless, it is impossible to determine the reverse of this one-way hash function in polynomial period, such that FAv1t1,rq1≤ε for a small value of ε>0. Accordingly, we can say that our proposed scheme is safe from the attacker for obtaining Id,Pw,V1,andSKey.Formula 2.
If we suppose that the hash function behaves as random oracle and the attacker have intercepted the message forwarded on unsecured channelV1−V4,T1−T4,IdSN,MID, the attacker may not be able to calculate user's session key SKey.Proof.
If an attacker that intercepts the transferred messageV1−V4,T1−T4,IdSN,MID tries to generate user’s session key SKey, the probability of achievement Ach1 in this calculation is defined by the tentative algorithm Tent2A,RPMAPhash as(2)Ach2=Pb⋅Tent2A,RPMAPhash=1−1.
PbEdenotes the probability for a given event E. In this experiment, we define the advantageous function as FAv2t2,rq2=MaxAAch2, where Max is determined based on totally adversaries taking the execution time t1 and rq1 is the total maximum requests transmitted to the reveal oracle. Our presented protocol is secure against the adversary to discover SKey if FAv2t2,rq2≤ε for a small value of ε>0. The trial model Tent2A,RPMAPhash indicates that if the hacker is able to compute the inverse of the hash function, it can recover user’s parameters Id,Pw, andV1. Nevertheless, it is impossible to determine the reverse of this one-way hash function in legal period, such that FAv2t2,rq2≤ε for a small value of ε>0. Accordingly, we can close that our proposed scheme is safe from the attacker for computing SKey (Algorithm 1 and 2 ).Algorithm 1:Tent1A,RPMAPhash.
Begin(1)
Intercept the transmitted valuesV1,V4,MID,A,IdSN,T1,T4(2)
Call reveal oracle onV4 for getting value of xMIDIdSNT4DasxMIDIdSNT4D) ←reveal1V4(3)
Call reveal oracle onV1 for getting value of x‖Aasx‖A← reveal1V1(4)
Calculatex' =  V⊕hhIdi‖pwi‖b‖c(5)
If (x'=?x), then(6)
Extract the parametersV,a,b,MID from the mobile device.(7)
CalculatehhIdi‖pwi‖b‖c=V⊕x(8)
Call reveal oracle on inputhhIdi‖pwi‖b‖c to discover {hIdipwib‖c} as (hIdipwib‖c ← reveal1(hhIdipwib‖c.(9)
Call reveal oracle on inputhIdipwib to discover Idipwib as Idipwib ← reveal1 (hIdipwib.(10)
Ten, compute MID' = hIdi‖a(11)
If(MID′<i>=? </i>MID), thenAcceptIdi′,pwi′, and a′ as valid identity, password, and random number.Return (true)(12)
ElseReturn (false)(13)
End ifEnd.Algorithm 2:Tent2A,RPMAPhash.
Begin(14)
Intercept the transmitted valuesV1,V4,MID,A,IdSN,T1(15)
Call reveal oracle onV4 for getting value of xMIDIdSNT4DasxMIDIdSNT4D ←reveal1V4(16)
Call reveal oracle onV1 for getting value of x‖Aasx‖A← reveal1V1(17)
Calculatew1=hMID‖Xs(18)
Generate the session keySkey′=hw1MIDIdSN(19)
ComputeV4′=xMIDIdSNT4D(20)
If (V4′=?V4), thenAcceptSkey′=hw1MIDIdSN as effective user’s session key.Return (true)(21)
ElseReturn (false)(22)
End ifEnd.


## 8. Performance and Comparative Analysis

This section details the results of the performance analysis of our protocol. In the first place, we display the performance of our proposed protocol in point of view of the ability to resist against security attacks. Secondly, our protocol is compared to other related ones according to the computational complexity. Hence, the results of the first comparison are illustrated in Table2. As it is very clear, we can realize that our protocol can resist against various attacks, and it is able to guarantee several security requirements including perfect forward secrecy, session key exchange, and mutual authentication.As we have mentioned above, the calculation charges of our proposed scheme is compared to other correlated protocols specifically Alzahrani et al. [40], Li et al. [41], Azrour et al. [32], and Sharma and Kalra [14]. In this calculation, very weedy procedures such as string concatenation operation and XoR procedure are ignored. The sign Th personifies the time charge of one way hash operation, whereas TED characterizes the time complexity of symmetric key operations and Tpm denotes the computational charge of elliptic curve point multiplication.In our protocol, the medical professional user calculates 6Th and the cloud server computes 8Th, while the sensors node calculates 3Th. Consequently, the whole calculation complexity of our scheme is only 17Th. As displayed in Table 3, one can remark that our scheme is based only on one-way hash functions which do not consume much time if it is compared to the symmetric key operations. In case we compare the number of time that Th uses, we will find that our protocol uses only 17. Hence, we confirm that our proposed protocol is appropriate for remote healthcare applications based one cloud-IoT.Table 3
Comparative analysis.
Alzahrani et al [40]Li et al. [41]Sharma and Kalra [14]Azrour et al. [32]OursUser1TED + 11Th2TED + 6Th11Th5Th6ThServer/gateway7Th6TED + 7Th7Th6Th + 4Tpm8ThSensor node1TED + 5Th2TED + 5Th5Th2Th + 2Tpm3ThTotal2TED + 23Th10TED + 18Th23Th13Th + 6Tpm17Th


## 9. Conclusions

Modern technologies are currently having a great impact on the healthcare world. Thus, healthcare professionals can have access to patient confidential data online, which mandates strong authentication protocols for home patient monitoring. So, it is necessary to consider a lightweight authentication scheme to guarantee secure communication between the healthcare system-based cloud-IoT. In the present study, we firstly demonstrated that the protocol proposed by Sharma and Kalra is vulnerable and exposes some security issues. Then, we have proposed our authentication protocol to mitigate the prior work vulnerable issues. Afterwards, we have demonstrated informally that our protocol can resist against various attacks and can provide security requirement. In addition, the simulation done under Scyther tools confirms that our protocol is formally secured and meets security fundamentals.



---

*Source: 5546334-2021-05-08.xml*