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.
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 Figure 1. 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.
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 Section 2. 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 Table 1.
Notations and their significations.
Symbol
Signification
Ui
User (medical professional)
Idi
User’s Ui identity
pw
User’s Ui password
SNi
The sensor node
GN
Gateway node
Idsn
Identity of sensor node
CS
Cloud server
Xs
Secret key of CS
KCS−SNi
Shared session key between CS and SNi
T1,T2,T3,T4
The current time
A,B,C,D
High entropy random numbers
h
Hash function
⊕
XOR operator
||
Concatenation operator
3.1. Registration Phase
Step 1: user Ui 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 saves a,c,d,R in it smart card.
3.2. Login Phase
Sharma and Kalra’s scheme login phase contains three steps:
Step 1: user Ui inserts her/his identity Id and password pw in the smart device.
Step 2: the smart device calculates MPS=hpw‖Rbased on input pw and stored R.
Step 3: the smart device computes a′=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 user Ui, the sensor, and the gateway node have to authenticate each other mutually and produce the session key. The steps of this phase are
Step 1: the smart device calculates 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.
Step 2: after receiving user’s massage, the GN verifies the timestamp. Then, it calculates MIDSN=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 calculates IdSN′=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 of V9′=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 of V8′=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 of R1and ai. 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.
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 deduced ID′ 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 server Xs 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 Figure 3.
Step 1: the medical professional selects freely appropriate identity Idi 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 server CS picks c randomly and computes V=hMID‖Xs⊕hMPW‖c. Next, the CS saves MID and c in local database and transmits V to medical professional.
Step 3: the medical professional memorizes that information V,a,b,MID in a smart card.
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 Figure 4.
Step_Auth1: U⟶CS : V1,MID,A,IdSN,T1
Firstly, medical professional user types his/her Idiand pwi, 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,T2
After receiving user’s communication, the cloud server checks the timestamp T2−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,T3
Once the sensor node SN 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,T4
When sensor’s response is reaching to the cloud server, this last one verifies the validity of timestamp T4−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 timestamp T5−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.
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 Figure 5. Besides, they are detailed in the following.
Step_Chang1:U⟶CS:Mu
In this step, medical professional user U types in it login and password Idiand pwi . 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:Ms
After receiving user’s request the server decrypts the received message Mu′=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 and c by MID∗and c∗, respectively. Next, it computesV∗=hMID∗‖Xs⊕hMPW∗‖c∗ and Ms=ESKV∗. Finally, the server sends back to the user the message Ms.
Step_Chang3
Once the server response was received by the user, this last one decrypts the message Ms′=DSKV∗ and replaces V,a,b,and MID by V∗,a∗,b∗and MID∗ respectively.
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 (Table 2). The security of our proposed scheme is proved by both informal and formal analysis.
Security feature’s comparison.
Kumar et al. [33]
He et al [34]
Amin et al [35]
Sharma and Kalra [14]
Ours
Mutual 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.
In our proposed protocol, the session key is generated by the user and cloud server as SKey=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 captures V1, 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 is V=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 timestamp T2−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 key SKey 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 Analyses7.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 Figure 6, which details the obtained results, we can notice that our protocol is secure against many attacks. Besides, it meets the necessary security-related fundamentals.
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 including Id,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 transactions V1−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 attacker A 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⋅Tent 1A,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, and V1 if FAv1t1,rq1≤ε for a small value of ε>0. The trial model Tent 1A,RPMAPhash indicates that if the hacker is able to compute the inverse of the hash function, it can recover user’s parameters Id,Pw, and V1. 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,and SKey.
Formula 2.
If we suppose that the hash function behaves as random oracle and the attacker have intercepted the message forwarded on unsecured channel V1−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 message V1−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⋅Tent 2A,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, and V1. 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: Tent 1A,RPMAPhash.
Begin
Intercept the transmitted values V1,V4,MID,A,IdSN,T1,T4
Call reveal oracle on V4 for getting value of xMIDIdSNT4DasxMIDIdSNT4D) ←reveal1V4
Call reveal oracle on V1 for getting value of x‖Aasx‖A← reveal1V1
Calculate x'=V⊕hhIdi‖pwi‖b‖c
If (x'=?x), then
Extract the parameters V,a,b,MID from the mobile device.
Calculate hhIdi‖pwi‖b‖c=V⊕x
Call reveal oracle on input hhIdi‖pwi‖b‖c to discover {hIdipwib‖c} as (hIdipwib‖c ← reveal1(hhIdipwib‖c.
Call reveal oracle on input hIdipwib to discover Idipwib as Idipwib ← reveal1 (hIdipwib.
Ten, compute MID'=hIdi‖a
If (MID′<i>=? </i>MID), then
Accept Idi′,pwi′, and a′ as valid identity, password, and random number.
Return (true)
Else
Return (false)
End if
End.
Algorithm 2: Tent2A,RPMAPhash.
Begin
Intercept the transmitted values V1,V4,MID,A,IdSN,T1
Call reveal oracle on V4 for getting value of xMIDIdSNT4DasxMIDIdSNT4D ←reveal1V4
Call reveal oracle on V1 for getting value of x‖Aasx‖A← reveal1V1
Calculate w1=hMID‖Xs
Generate the session key Skey′=hw1MIDIdSN
Compute V4′=xMIDIdSNT4D
If (V4′=?V4), then
Accept Skey′=hw1MIDIdSN as effective user’s session key.
Return (true)
Else
Return (false)
End if
End.
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 Table 2. 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.
Comparative analysis.
Alzahrani et al [40]
Li et al. [41]
Sharma and Kalra [14]
Azrour et al. [32]
Ours
User
1TED + 11Th
2TED + 6Th
11Th
5Th
6Th
Server/gateway
7Th
6TED + 7Th
7Th
6Th+4Tpm
8Th
Sensor node
1TED + 5Th
2TED + 5Th
5Th
2Th+2Tpm
3Th
Total
2TED + 23Th
10TED + 18Th
23Th
13Th+6Tpm
17Th
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.
Data Availability
Experimental results, obtained using Scyther tool, are available and will be shared with authors at https://sites.Google.com/umi.ac.ma/azrour.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
PivotoD.WaquilP. D.TalaminiE.FinocchioC. P. S.Dalla CorteV. F.de Vargas MoresG.Scientific development of smart farming technologies and their application in Brazil201851213210.1016/j.inpa.2017.12.0022-s2.0-85042373713ViscontiP.GiannoccaroN. I.FazioR. d.StrazzellaS.CafagnaD.IoT-oriented software platform applied to sensors-based farming facility with smartphone farmer app2020931095110510.11591/eei.v9i3.2177HapsariG. I.Andriana MutiaraG.RohendiL.MuliaA.Wireless sensor network for monitoring irrigation using XBee Pro S2C2020941345135610.11591/eei.v9i4.1994ChowduryM. S. U.EmranT. B.GhoshS.IoT based real-time river water quality monitoring system201915516116810.1016/j.procs.2019.08.025Mohd YusoffZ.MuhammadZ.Mohd RaziM. S. I.RazaliN. F.HashimM. H. C.IOT-Based smart street lighting enhances energy conservation202020152810.11591/ijeecs.v20.i1.pp528-536PoushterJ.Smartphone ownership and internet usage continues to climb in emerging economies201694144JinJ.GubbiJ.MarusicS.PalaniswamiM.An information framework for creating a smart city through internet of things20141211212110.1109/jiot.2013.22965162-s2.0-84906841638HossainM. S.MuhammadG.AlamriA.Smart healthcare monitoring: a voice pathology detection paradigm for smart cities201925556557510.1007/s00530-017-0561-x2-s2.0-85021861108ParkY.-T.Emerging new era of mobile health technologies201622425325410.4258/hir.2016.22.4.2532-s2.0-84994494814MabroukiJ.AzrourM.FattahG.DhibaD.HajjajiS. E.Intelligent monitoring system for biogas detection based on the Internet of Things: mohammedia, Morocco city landfill case202141101710.26599/BDMA.2020.9020017MabroukiJ.AzrourM.DhibaD.FarhaouiY.HajjajiS. E.IoT-based data logger for weather monitoring using arduino-based wireless sensor networks with remote graphical application and alerts202141253210.26599/BDMA.2020.9020018MabroukiJ.AzrourM.FarhaouiY.El HajjajiS.FarhaouiY.Intelligent system for monitoring and detecting water quality2020vol. 81Cham, SwitzerlandSpringer International Publishing17218210.1007/978-3-030-23672-4_13MabroukiJ.AzrourM.El HajjajiS.Use of internet of things for monitoring and evaluation water’s quality: comparative study2021, In pressSharmaG.KalraS.A lightweight user authentication scheme for cloud-IoT based healthcare services201943161963610.1007/s40998-018-0146-52-s2.0-85067552578WatroR.KongD.CutiS.GardinerC.LynnC.KruusP.TinyPK: securing sensor networks with public key technologyProceedings Of the 2nd ACM Workshop on Security Of Ad Hoc and Sensor Networks2004San Diego, CA, USA5964WongK. H.ZhengY.CaoJ.WangS.A dynamic user authentication scheme for wireless sensor networks200618DasM. L.Two-factor user authentication in wireless sensor networks2009831086109010.1109/twc.2008.0801282-s2.0-62949130774XuJ.ZhuW.-T.FengD.-G.An improved smart card based password authentication scheme with provable security200931472372810.1016/j.csi.2008.09.0062-s2.0-64249125305SongR.Advanced smart card based password authentication protocol2010325-632132510.1016/j.csi.2010.03.0082-s2.0-77955312905XuX.JinZ. P.ZhangH.ZhuP.A dynamic ID-based authentication scheme based on ECC for telecare medicine information systems2014457861866YanX.LiW.LiP.WangJ.HaoX.GongP.A secure biometrics-based authentication scheme for telecare medicine information systems20133751610.1007/s10916-013-9972-12-s2.0-84883088262MishraD.MukhopadhyayS.KumariS.KhanM. K.ChaturvediA.Security enhancement of a biometric based authentication scheme for telecare medicine information systems with nonce201438511110.1007/s10916-014-0041-12-s2.0-84901726882TanZ.A user anonymity preserving three-factor authentication scheme for telecare medicine information systems20143831910.1007/s10916-014-0016-22-s2.0-84898905921YoonE.-J.KimC.Advanced biometric-based user authentication scheme for wireless sensor networks20131191836184310.1166/sl.2013.30142-s2.0-84893438606HeD.ChenC.ChanS.BuJ.VasilakosA. V.ReTrust: attack-resistant and lightweight trust management for medical sensor networks201216462363210.1109/TITB.2012.21947882-s2.0-84863512174MishraD.SrinivasJ.MukhopadhyayS.A secure and efficient chaotic map-based authenticated key agreement scheme for telecare medicine information systems2014381012010.1007/s10916-014-0120-32-s2.0-84935925341JiangQ.MaJ.LiG.LiX.Improvement of robust smart-card-based password authentication scheme201528238339310.1002/dac.26442-s2.0-84988227377ChengZ.-Y.LiuY.ChangC.-C.ChangS.-C.An improved protocol for password authentication using smart cards2012224AzrourM.OuananM.FarhaouiY.GuezzazA.Authentication Protocol for Internet of Things201953677410.1007/978-3-030-12048-1_9YeN.ZhuY.WangR.-c.MalekianR.Qiao-minL.An efficient authentication and access control scheme for perception layer of internet of things2014841617162410.12785/amis/0804162-s2.0-84894059526ChengX.ZhangZ.ChenF.Secure identity authentication of community medical internet of things2019711596611597710.1109/access.2019.2935782AzrourM.MabroukiJ.GuezzazA.FarhaouiY.New enhanced authentication protocol for Internet of Things2021411910.26599/BDMA.2020.9020010KumarP.LeeS.-G.LeeH.-J.E-SAP: efficient-strong authentication protocol for healthcare applications using wireless medical sensor networks20121221625164710.3390/s1202016252-s2.0-84863271667HeD.KumarN.ChenJ.LeeC.-C.ChilamkurtiN.YeoS.-S.Robust anonymous authentication protocol for health-care applications using wireless medical sensor networks2015211496010.1007/s00530-013-0346-92-s2.0-84922001116AminR.KumarN.BiswasG. P.IqbalR.ChangV.A light weight authentication protocol for IoT-enabled devices in distributed cloud Computing environment2018781005101910.1016/j.future.2016.12.0282-s2.0-85013449798CremersC. J. F.The scyther tool: verification, falsification, and analysis of security protocols4144182008, In press10.1007/978-3-540-70545-1_382-s2.0-48949088211KoblitzN.MenezesA. J.The random oracle model: a twenty-year retrospective2015772-358761010.1007/s10623-015-0094-22-s2.0-84942983887CoronJ.-S.PatarinJ.SeurinY.The random oracle model and the ideal cipher model are equivalent2008Berlin, GermanySpringer12010.1007/978-3-540-85174-5_12-s2.0-51849085606BellareM.RogawayP.Random oracles are practicalProceedings of the 1st ACM Conference on Computer and Communications Security1993New York, NY, USA627310.1145/168588.168596AlzahraniB. A.IrshadA.AlsubhiK.AlbeshriA.A secure and efficient remote patient-monitoring authentication protocol for cloud-IoT20203311e442310.1002/dac.4423LiX.NiuJ.KumariS.LiaoJ.LiangW.KhanM. K.A new authentication protocol for healthcare applications using wireless medical sensor networks with user anonymity20169152643265510.1002/sec.12142-s2.0-84923405290