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.
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.
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.
3.1. Registration Phase
Step 1: user selects her/his identity , password , and arbitrary number . He/she computes and sends to 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 , , , and . Afterwards, server sends back to user , and . Step 3: user saves in it smart card.
3.2. Login Phase
Sharma and Kalra’s scheme login phase contains three steps: Step 1: user inserts her/his identity and password in the smart device. Step 2: the smart device calculates based on input pw and stored R. Step 3: the smart device computes and compares its value with stored . In this case, it equals the login phase which is a success.
3.3. Authentication Phase
In this phase, the user , 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 and . It generates timestamp and computes . Then, it chooses random and computes and . Next, it transfers this message to gateway node (GN) . Step 2: after receiving user’s massage, the GN verifies the timestamp. Then, it calculates It generates random number, which is used for computing and . The GN then communicates this message to the SN. Step 3: upon receiving GN message, the SN verifies the timestamp. Then, it calculates , , and . Formerly, it checks . If it is correct, the GN is authenticated. Next, SN computes , , and . Then, it checks the validity of . If it is ok, the user was authenticated. Therefore, the SN computes its parameters , , , and that will be sent to GN. , , , and . Step 4: once the GN receives SN response, it verifies the timestamp. Then, it checks the correctness of . It computes , , and . Next, the GN sends to the user this message: . Step 5: in this step, the user verifies the validity of timestamp. Then, he/she checks the authenticity of and calculates and . Finally, the user checks the correctness of .
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 . 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 and the value of ; if the second value equals , the guessed password is correct. Otherwise, the adversary selects another password until discovering the correct one.
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 and . Subsequent, the smart device computes the values of and . Then, it verifies if . 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 and . It generates timestamp and computes . Then, it chooses random and computes and . Next, it transfers this message to gateway node (GN) <.
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 () is which is computed as . However, the value of is clearly (not encrypted or hashed) in the first message sent by user to gateway node (GN). Consequently, if an adversary intercepts this message, he can get easily . Then, he is able to compute .
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 and one way hash function . Finally, the server publishes and saves its private key secretly.
5.2. New Sensor Registration Phase
To implement a newly connected sensor node () in an already functioning healthcare system, the cloud server has to randomly select both specific and as the identification and unique key of the added sensor, respectively. The gateway subsequently uploads and data to the sensor memory before running it. In addition, it saves and 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 and suitable password . Afterword, he picks arbitrarily two numbers and . Next, he calculates and . The two last values are transferred to the cloud server using a secured canal. Step 2: the cloud server picks randomly and computes . Next, the saves and in local database and transmits to medical professional. Step 3: the medical professional memorizes that information in a smart card.
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: : Firstly, medical professional user types his/her , and the smart card verifies user’s identity by checking . If it is not OK, the process stops. Otherwise, the smart card picks randomly an integer . Then, it computes and . Subsequently, it sends to the cloud server this message . Step_Auth2: : After receiving user’s communication, the cloud server checks the timestamp . Then, it computes and verifies if . In the case it is validate, the cloud server generates randomly an integer . Hence, it calculates , , and Finally, the cloud server forwards this message to the sensor node . Step_Auth3: : Once the sensor node obtains the message sent by CS. First of all, it checks the authenticity of timestamp . Next, it calculates the value of . Then, it checks whether is valid or not. If it is OK, the sensor node chooses random integer and computes which is sent back to the cloud server with other values . Step_Auth4: : When sensor’s response is reaching to the cloud server, this last one verifies the validity of timestamp . Subsequently, it checks if is correct or not. In the case that it is reasonable, and the cloud server picks randomly an integer . At that moment, it computes and the session key . After that, the cloud server sends back the response to the medical professional user }. Step_Auth5: After reception of cloud server reply, the medical professional user checks the correctness of the timestamp . Hence, it authenticates the cloud server’s message by checking if is true or false. In the case that it is OK, the medical professional user generates the session key .
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:: In this step, medical professional user types in it login and password . Afterwards, he/she verifies . If it is all right, the user selects freely his/her new password and chooses two arbitrary numbers and . Next, he/she computes and . Finally, he/she encrypts the message which will be sent to the cloud server. Step_Chang2: : After receiving user’s request the server decrypts the received message . Then, it checks whether is correct or not. If it is OK, the server selects randomly . Then, it replaces by , respectively. Next, it computes and . Finally, the server sends back to the user the message . Step_Chang3 Once the server response was received by the user, this last one decrypts the message and replaces by respectively.
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.
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 as , where . Thanks to the reason that and 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 received. For checking the sensor identity, in Step 4, the cloud server verifies the exactness of . Additionally, the medical professional user is able to authenticate the cloud server identity in Step 5, through examination of the legitimacy of . Hereafter, in Step 3, the sensor node also authenticates cloud servers’ message by checking the accuracy of .
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 , , , or . 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 , , , and .
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 . Therefore, the attacker has to know the value of and . However, is encrypted using one-way hash function, and 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 ; in the case that it is noted valid, the session stops. The same thing happens after receiving sensor node’s message . The sensor node and user use and , 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 {,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 is computed as , where . The session key contains server’s secret key and users that depend on user’s encrypted . In other words, the session key 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 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.
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 Idi, and session key . 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 .
Formula 1. Let us suppose that an attacker has stool user’s smart device; in addition, he has the knowledge about the transactions that has been transmitted over an untrusted network. While, is the hash function that is understood as a random oracle, and the introduced protocol is secured against the attacker to retrieve the , and the session key of legitimate user U.
Proof. Suppose that the attacker has obtained user’s parameters Id and Pw by using smart card data and the intercepted messages , and the tentative algorithm defines the possibility of achievement for by means of the following specified function: denotes the probability for a given event E. In this experiment, we define the advantageous condition as , where Max is determined based on totally adversaries taking the execution time and is the total maximum requests transmitted to the reveal oracle. Our presented protocol is secure against the adversary to discover if for a small value of . The trial model indicates that if the hacker is able to compute the inverse of the hash function, it can recover user’s parameters . Nevertheless, it is impossible to determine the reverse of this one-way hash function in polynomial period, such that for a small value of . Accordingly, we can say that our proposed scheme is safe from the attacker for obtaining .
Formula 2. If we suppose that the hash function behaves as random oracle and the attacker have intercepted the message forwarded on unsecured channel , the attacker may not be able to calculate user's session key .
Proof. If an attacker that intercepts the transferred message tries to generate user’s session key , the probability of achievement in this calculation is defined by the tentative algorithm asdenotes the probability for a given event E. In this experiment, we define the advantageous function as , where Max is determined based on totally adversaries taking the execution time and is the total maximum requests transmitted to the reveal oracle. Our presented protocol is secure against the adversary to discover if for a small value of . The trial model indicates that if the hacker is able to compute the inverse of the hash function, it can recover user’s parameters . Nevertheless, it is impossible to determine the reverse of this one-way hash function in legal period, such that for a small value of . Accordingly, we can close that our proposed scheme is safe from the attacker for computing (Algorithm 1 and 2 ).
|
|
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 personifies the time charge of one way hash operation, whereas characterizes the time complexity of symmetric key operations and denotes the computational charge of elliptic curve point multiplication.
In our protocol, the medical professional user calculates 6 and the cloud server computes 8, while the sensors node calculates 3. Consequently, the whole calculation complexity of our scheme is only 17. 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 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.
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.