An Enhanced Lightweight IoT-based Authentication Scheme in Cloud Computing Circumstances

With the rapid deployment of the Internet of Things and cloud computing, it is necessary to enhance authentication protocols to reduce attacks and security vulnerabilities which affect the correct performance of applications. In 2019 a new lightweight IoT-based authentication scheme in cloud computing circumstances was proposed. According to the authors, their protocol is secure and resists very well-known attacks. However, when we evaluated the protocol we found some security vulnerabilities and drawbacks, making the scheme insecure. Therefore, we propose a new version considering login, mutual authentication and key agreement phases to enhance the security. Moreover, we include a sub-phase called evidence of connection attempt which provides proof about the participation of the user and the server. The new scheme achieves the security requirements and resists very well-known attacks, improving previous works. In addition, the performance evaluation demonstrates that the new scheme requires less communication-cost than previous authentication protocols during the registration and login phases.


Introduction
Information technology has grown rapidly in the past few years, mainly developing new technologies focused on how to take advantage of the Internet. In this sense, innovations such as wireless access, high speed connection, APIs and electronic services have successfully entered the Internet arena. At the same time, researchers and computer professionals have developed new communication technologies, such as Wi-Fi, 4G, 5G, routing protocols, LTE, Bluetooth, RFID, among others, which offer broader ranges to users. In parallel, the cost of technology keeps decreasing, year by year, making Internet connectivity more accessible for everyone through smaller devices as tablets and smartphones.
On the other hand, as the Internet has become ubiquitous, faster, and increasingly accessible to non-technical communities, social networking and collaborative services, emerging technologies such as artificial intelligence, big data, cloud computing, wireless sensor networks and the Internet of Things (IoT) have appeared, enabling people to communicate and share interests in many more ways. of attacks [5]. However, the most popular attacks used for evaluating authentication protocols are man-in-the-middle, impersonation and forging, and replay attacks [5].
In recent years, authentication protocols have used cryptosystems as countermeasures to enhance security [5]. The main cryptosystems are hash functions, symmetric algorithms (AES), asymmetric algorithms (RSA, D-H, ECC), digital signatures, and ID-based cryptography; and its adoption mainly depends on the deployment, computational power and energy consumption of the device/sensor. Thus, cryptosystems that require more computational power must be implemented in device/sensor that needs high energy consumption. Therefore, we address to lightweight authentication protocols, which require low computational operations. In this way, the studies carried out by Wang et al. in 2015 [16] and 2018 [17] contribute to understanding the security requirements, adversary model, types of schemes, and evaluation criteria of lightweight authentication protocols.

Related Work
In this paper, we refer to lightweight authentication schemes which require low computational operations, such as hash functions and exclusive-OR operation. The first lightweight authentication scheme was proposed by Lamport in 1981 [18]. Lamport introduced the concept of a hash chain to authenticate remote users through an open communication channel. Lamport's scheme is feasible for practical implementation due to its low computational cost, however, the scheme requires that the server maintains a verification table making it vulnerable to steal personal data. In 1990, Hwang et al. [19] proposed a scheme without a verification table. Later, Lin et al. [20] proposed an authentication scheme based on the asymmetric ElGamal algorithm to improve the security characteristics of Li et al. in [21]. Since 1990, several authentication schemes were proposed to enhance the security of previous ones. These schemes were designed for communication between n users and a single server.
Later, Liao et al. [22] proposed an authentication scheme for a multi-server environment. Nevertheless, Liao et al.'s scheme is vulnerable to an insider attack, masquerade attack, server spoofing attack, and registration center spoofing attacks [23]. Hsiang et al. [23] proposed a new authentication scheme to resolve the security drawbacks of Liao et al.'s scheme. However, Martínez-Peláez et al. [24] demonstrated that Hsiang et al.'s scheme is insecure. Two years later, Kim et al. [25] evaluated Martínez-Peláez et al.'s scheme finding security vulnerabilities. The same year, Li et al. [26] evaluated the scheme proposed by Sood et al. [27] finding it insecure. Then, Xue et al. [28] demonstrated the security vulnerabilities of Li et al.'s scheme. Later, Amin et al. [1] proposed an authentication scheme which remedies the security drawbacks of Xue et al.'s scheme. Nonetheless, Challa et al. [29] demonstrated that Amin et al.'s scheme is vulnerable to privileged-insider and impersonation attacks.
In 2019, Zhou et al. [30] proposed a scheme based on hash function and exclusive-or operation to provide authentication on large-scale IoT and cloud computing deployment. They explained that Amin et al.'s scheme cannot resist off-line guessing attacks. They also claimed that their scheme is secure against very well-known attacks.

Contribution
In this work, we review the scheme proposed by Zhou et al. [30] and point out that the scheme has security vulnerabilities and drawbacks which make it insecure. In particular, the scheme is vulnerable to insider, replay and user impersonation attacks. Moreover, the scheme fails to provide mutual authentication and fails to protect secret keys. Therefore, the main contribution of this paper is a new version of the authentication scheme proposed by Zhou et al. which achieves the following security characteristics: mutual authentication and session key agreement. Moreover, our proposal maintains the user's anonymity against eavesdroppers and requires login phase.
On the other hand, in the security scheme of Zhou et al., neither the server or nor the user knows if the other party is a legal member of the system. For that reason, the scheme includes a new sub-phase called evidence of connection attempt which provides elements for identifying the participants of the authentication request. This sub-phase complements the authentication phase included in [30].
The rest of this paper is organized as follows: Section 2 presents the overview of Zhou et al.'s scheme, in particular registration and authentication phases, and contains the results of the security analysis carried out to the proposal of Zhou et al. based on [5,6,15]. The new proposal is explained in Section 3. Security analysis and performance evaluation are given in Section 4. Conclusions are presented in Section 5.

Review and Security Analysis of Zhou's Scheme
Firstly, we provide a brief description about the registration and authentication phases of the scheme proposed by Zhou et al. in [30]. Then, we carry out the security analysis to explain the drawbacks and vulnerabilities found in their scheme.

Registration Phase
This phase is divided in user registration and cloud server registration sub-phases.

User Registration Sub-Phase
In this sub-phase, the user (U i ) is registered by the control server (CS). The communication between U i and CS is through a secure channel. The steps involved in this sub-phase are as follows: Step 1: U i selects an identity (ID i ), pseudo-identity (PID i ), password (PW i ), and nonce (b i ). Then, U i computes HP i = h(PW i b i ) and sends the registration request message is a one-way hash function, represents concatenation operation and ⊕ represents an exclusive-or operation.
Step 2: Upon receiving the registration request message M 1 , CS verifies if ID i is valid or not. In case that ID i is invalid, the registration process will be closed. On the other hand, CS computes . Then, CS stores ID i in a database and sends the registration response message M 2 = {C 1 , C 2 , ID CS } to U i .
Step 3: After receiving the registration response message M 2 , U i computes C 1 = C * 1 ⊕ HP i , , and stores (C 1 , C 2 , C 3 , PID i , ID CS ) in his smart card. At this point, the user registration sub-phase is over and U i was registered by CS.

Cloud Server Registration Sub-phase
In this sub-phase, the server S j is registered by the control server (CS). The communication between S j and CS is through a secure communication channel. The steps involved in this sub-phase are as follows: Step 1: S j selects an identity SID j and pseudo-identity PSID j . Then, S j sends the registration request message M 3 = SID j , PSID j to CS.
Step 2: Upon receiving the registration request message M 3 , CS computes B 1 = h PSID j ID CS x and B 2 = h SID j x . Then, CS stores SID j and sends the registration response message Step 3: After S j receives the registration response message M 4 , S j stores B 1 , B 2 , SID j , PSID j , ID CS .
At this point, the cloud server registration sub-phase is over and S j was registered by CS.

Authentication Phase
This phase is divided in the following steps and the details are shown in Figure 1: Step 1: This step is invoked by U i , when she/he wants to get access to the service offered by S j . U i inserts his/her smart card and keys his/her ID i and PW i . Then, the smart card generates a random number (r U ) and new pseudo-identity PID new i . After that, U i computes b i = C 3 ⊕ h(ID i PW i ),  Step 2: This step is invoked by . After receiving the authentication request message , selects a new pseudo-identity and a random number ( ). Then,  Step 2: This step is invoked by S j . After receiving the authentication request message Step 3: This step is invoked by CS. Upon receiving the authentication request message M 6 , CS computes Step 5: This step is invoked by U i . After receiving the authentication response message is correct or not. If the verification process is correct,

Security Vulnerabilities
In this subsection, we explain the weaknesses found in the scheme proposed by Zhou et al. in [30]. The security analysis was conducted based on [5,6,15]. From these works, we performed the security analysis. In this part, we assume the following capabilities of the attacker [31,32]: • The attacker is a legal member of the system which means that he/she was registered by CS and he/she has all the security parameters.

•
The attacker can control the public communication channel giving him/her the possibility to intercept, insert, store, delete, or modify any message.

•
The attacker has high computational power connected to the public communication channel.

Insider Attack
This attack happens when a malicious user has enough knowledge to attack sensitive data or the whole system. In this scenario, the attacker knows C * 2 = h(ID i x), computed by CS during the user registration phase. According with Zhou et al., CS uses the same secret key (x) to register users and servers, so he/she can find x from C * 2 , searching exhaustively all possible random number y until h(ID i y) = C * 2 = h(ID i x) to know the secret key of CS. This attack is possible because the attacker knows ID i and C * 2 .

Man-in-the-Middle Attack
This attack happens when an attacker has control over the public communication channel providing him/her the possibility to listen the conversation between two entities. Under this scenario, the attacker can intercept the authentication request message Under this situation, the attacker can achieve the following active attacks.

Replay Attack
The attacker can transmit the last authentication request message M 5 sent to S j , at any given time and from any given place, to impersonate a legitimate U i . The description of the attack is as follows: Step 1: The attacker has, at-least, one authentication request message M 5 sent by U i to S j , and the attacker knows ID CS and x.
Step 2: The attacker sends an authentication request message M replay 5 to S j . The message contains the same information transmitted in previous communication.
Step 3: The attacker uses ID CS , x and PID i to compute Step 4: After CS verifies the authenticity of ID i and D 4 , CS computes and sends Step 5: Upon receiving the authentication response message M 8 , the attacker computes As a consequence, the attacker can launch the replay attack successfully.

User Impersonation Attack
The attacker can compute a valid authentication request message which contains the correct parameters to be authenticated by CS. The description of the attack is presented below: Step 1: The attacker knows ID CS , x and PID. Thus, he/she computes Step 2: The attacker recovers r U from D 1 computing Step 3: The attacker has enough information to recover sensitive data as follows Step 4: From this point, the attacker computes a fake authentication request message as follows: Step 5: The attacker sends the fake authentication request message M It is obvious that, D f ake 4 will pass the verification process because it contains the original ID i and last PID new i .

Security Drawbacks
In this subsection, we expose the absence of security requirements in the scheme of Zhou et al. [30]. The security analysis was conducted based on [5,6,15]. From these references, we initialized the security analysis.

Fails to Provide Mutual Authentication
The scheme proposed by Zhou et al. does not provide mutual authentication. The CS verifies the identity of U i and S j during the third step of the authentication phase; however, neither the user nor server verifies the identity of each other. Moreover, the authentication request messages M 5 and M 6 do not contain information which establishes a relationship between U i and S j , as evidence to the attempt of connection.

Fails to Protect Secret Key
In the scheme proposed by Zhou et al., the CS uses the same secret key (x) to register users and servers. Moreover, the secret key is hidden by means of C * 1 = h(PID i ID CS x) and C * 2 = h(ID i x); however an attacker can recover it for three reasons.
The first reason is related with the fact that CS uses the same secret key to register each user and each server, increasing the possibility of finding the correct value of x. The second reason is related with the fact that an attacker knows ID CS and PID i ; this means that, each user knows two of three security parameters, decreasing the entropy to find x, in polynomial time. Finally, the low execution time of the hash function makes possible to find the secret key in polynomial time, in specific, using C * 2 = h(ID i x) because the attacker knows ID i .

Proposed Scheme
In this section, we present our new version of a lightweight IoT-based authentication scheme in cloud computing circumstances. The scheme includes mutual authentication and key agreement to provide strong security for accessing any server of the cloud. The scheme consists of the following phases: Registration is the process through CS creates the security parameters of each member of the system. This phase is mandatory for users and servers. The communication among participants is through a secure channel avoiding eavesdropper.
Login is the process through U i gets access to security parameters stored in his/her SC U . U i needs to insert his/her SC U , and inputs ID i and PW i . Then, SC U computes and verifies the legitimacy of U i . If the verification process is correct, U i sends the authentication request message to S j through an open communication channel.
Authentication is the processes by CS carries out the validation process of U i and S j . Moreover, CS verifies that both entities want to establish a secure communication.
Key agreement is the process by CS computes the session key for U i and S j . The session key is unique.
Mutual authentication is the process through U i and S j verifies the legitimacy of each other. In this case, U i sends a challenge to S j . If the response is correct, U i knows that S j is a member of the system. Table 1 summarizes the notations used throughout our proposal. Table 1. Notations of the proposed scheme.

Symbol Description
Secret keys of CS. Secret keys are long integers n U , n S , n CS Random nonce of U i , S j , CS, respectively Session key between U i and S j E SK (·)/D SK (·) Symmetric encryption/decryption using SK U−S h(·) Collision free one-way hash function ⊕ Exclusive-OR operation Concatenation operation ⇒ Secure communication channel → Open communication channel

Registration Phase
This phase includes user registration and server registration.

User Registration Sub-Phase
This sub-phase is initialized by U i when wants to be part of the system. The details of each step are shown in Figure 2.
Step 3: Upon receiving the registration response message , computes: , , , , ℎ( ) computes the local user authentication parameter using Equation (5) and stores all the security parameters received from . The user registration sub-phase is over.

Cloud Server Registration
This sub-phase is initialized by each in order to be part of the system. The details of each step are shown in Figure 3.
Step 1: U i inserts his/her SC i into a device and keys his/her ID i and PW i . Then, SC i generates a random nonce (n U ), obtains the current timestamp value (T U ) and computes: (1) is used to compute the pseudo-identity of each user.
Step 2: After receiving the registration request message M 1 , CS verifies the validity of ID i . If ID i is valid, CS computes: (2). Equations (3) and (4) are security parameters for future authentication purpose.
Step 3: Upon receiving the registration response message M 2 , SC i computes: STORES PID i , C 2 , C 3 , C 4 , h(n U ) in SC i SC i computes the local user authentication parameter using Equation (5) and stores all the security parameters received from CS. The user registration sub-phase is over.

Cloud Server Registration
This sub-phase is initialized by each S j in order to be part of the system. The details of each step are shown in Figure 3.
Step 3: After receiving the registration response message , stores and . Figure 3. Server registration sub-phase.

Login Phase
Once was registered, can connect to any server of the cloud by initiating the login phase. The details are shown in Figure 4. Step 1: In order to start the authentication phase, must first complete the login phase. Firstly, inserts and keys his/her * and * .
Step 2: Then, computes and checks: Step 1: S j generates a random nonce n S , obtains the current timestamp value T S and computes: Equation (6) is used to compute the pseudo-identity of each server.
Step 2: After receiving the registration request message M 3 , CS verifies the validity of SID j . If SID j is correct, CS computes: CS registers S j by Equation (7). Equations (8) and (9) are security parameters for future authentication purpose.
Step 3: After receiving the registration response message M 4 , S j stores B 2 and B 3 .

Login Phase
Once U i was registered, U i can connect to any server of the cloud by initiating the login phase. The details are shown in Figure 4.
Step 1: In order to start the authentication phase, U i must first complete the login phase. Firstly, U i inserts SC i and keys his/her ID * i and PW * i .
Step 2: Then, SC i computes and checks: Equation (10) is used to verify the legitimacy of U i by SC i for getting access to security parameters provided by S j .
Step 3: If the verification process is correct, SC i generates a random nonce n new U , obtains the current timestamp value T new U and computes: Equations (11) and (12) contain U i´s information which will be used by CS to verify its legitimacy. Finally, U i sends the user authentication request message M 5 to S j through an open communication channel.
Step 4: After receiving the user authentication request message M 5 , S j generates a random nonce n new S , obtains the current timestamp value T new S and computes: Equations (13) and (14) contain S j´s information which will be used by CS to verify its legitimacy. Equation (15) contains information about U i and S j as evidence of its connection attempt. Finally, S j sends the authentication request message M 6 to CS through an open communication channel.
Step 3: After receiving the registration response message , stores and .

Login Phase
Once was registered, can connect to any server of the cloud by initiating the login phase. The details are shown in Figure 4. Step 1: In order to start the authentication phase, must first complete the login phase. Firstly, inserts and keys his/her * and * .

Authentication Phase
This phase is divided in three sub-phases. The details of user authentication, server authentication and evidence of connection attempt are shown in Figure 5.

User Authentication
Step 1: Upon receiving the authentication request message M 6 , CS checks the freshness of the message by means of T new U . If the verification process is positive, CS computes: where PID * i is the pseudo-identity of U i contained in message M 2 . CS computed C * 2 using PID * i and Equation (3).
Step 2: CS verifies the legitimacy of U i by means of C 1 as follows: Equation (16) is used to recover ID * i from D 1 . Equation (17) is used to verify the legitimacy of U i using ID * i and C 1 . If the verification process is correct, CS continues with the next step; otherwise, CS finalizes the process.
Step 3: After verifying the legitimacy of U i , CS recovers h n new U as follows: Equation (18) is used to recover h n new U * from D 2 .
Step 4: CS computes C new 1 with T new U and h n new U * using Equation (19). Then, CS updates C 1 in the database:

Server Authentication
Step 1: Upon finalizing the user authentication process, CS checks the freshness of the message by means of T new S .
Step 2: If the verification process is positive, CS verifies the legitimacy of S j as follows: Equation (20) is used to recover SID * j from D 3 , using PSID * j . Then, CS computes Equation (21) to obtain B * 1 and compares it with B 1 . If the verification process is correct, CS continues with the process, otherwise, CS finalizes the process.
Step 3: After verifying the legitimacy of S j , CS recover h n new S as follows: Finally, Equation (22) is used to recover h n new S * from D 4 .

Evidence of Connection Attempt
Step 1: CS corroborates that U i wants to establish a connection with S j as follows: (23) in this case, CS has evidence of the connection attempt between U i and S j . It is important to note that, Equation (23) requires the fresh timestamp from U i and S j . Moreover, D 5 contains PID i , SID j and PSID j which demonstrate the interest of the two entities for establishing a secure communication.

Key Agreement Phase
This phase is divided in three sub-phases. The details of each phase are shown in Figure 6.

Session Key Creation
In this sub-phase, computes the session key between and as follows: Step 1: generates a random nonce and computes the session key as follows: Equation 24 is used to compute the session key. The session key contains security parameters generated by , and which represents the relationship among all the participants.
Step 2: computes the verification parameters for and as follows: where and are for , while and are for . Equations (25) to (28) contain information generated by for computing the session key.

Key Agreement Phase
This phase is divided in three sub-phases. The details of each phase are shown in Figure 6.
finally, recovers the response from using Equation (39) and verifies the legitimacy of by means of Equation (40).

Password Change Phase
When wants to change or to update his/her password, he/she needs to key his/her and . Then, computes Equation (10) to verify his/her legitimacy. If the verification process is correct, keys and computes Equation (40):

Session Key Creation
In this sub-phase, CS computes the session key between U i and S j as follows: Step 1: CS generates a random nonce n new CS and computes the session key SK U−S as follows: Equation (24) is used to compute the session key. The session key contains security parameters generated by U i , S j and CS which represents the relationship among all the participants.
Step 2: CS computes the verification parameters for S j and U i as follows: where D 6 and D 7 are for S j , while D 8 and D 9 are for U i . Equations (25) to (28) contain information generated by CS for computing the session key.
Step 3: CS computes the challenge-response message for S j and U i as follows: CS computed the challenge-response message for each entity using the session key; this means that, a legitimate participant can recover the security parameters to construct the session key. Finally, CS sends the authentication response message M 7 to S j through an open communication channel.

Server Session Key
Step 1: After receiving M 7 , S j computes and verifies the freshness of M 7 : Equation (31)

User Session Key
Step 1: Upon receiving the user authentication response message M 8 , U i computes and verifies the freshness of M 8 : Step 2: If M 8 is fresh, U i computes:

Mutual Authentication
Step 1: U i sends the challenge message M 9 to S j . M 9 contains h n new CS as proof of his/her legitimacy and requests the response: Step 2: Upon receiving the challenge message M 9 , S j computes

Password Change Phase
When U i wants to change or to update his/her password, he/she needs to key his/her ID i and PW i . Then, SC i computes Equation (10) to verify his/her legitimacy. If the verification process is correct, U i keys PW new i and SC i computes Equation (40): UPDATES C 4

Security Analysis and Performance Evaluation
In this section, we carry out the security analysis and performance evaluation comparison of our proposal. The security analysis includes an informal cryptanalysis, security of session key and countermeasures to improve security.

Informal Cryptanalysis
In this sub-section, we analyse the security of our proposal using informal security analysis.

User Anonymity
In our scheme, U i sends PID i = h(T U n U ) to S j instead of ID i in clear text. Moreover, PID i is updated after finalizing the user authentication sub-phase with T new U and n new U , keeping the identity of each user anonym. In consequence, when the user sends the authentication request message to S j , the PID i will be different. Furthermore, an attacker cannot recover ID i from PID i , D 1 , or D 2 without security parameters. Therefore, the scheme provides user anonymity.

Off-line User Identity and Password Guessing Attack
In the case that a malicious user obtains SC i , he/she can recover PID i , C 2 , C 3 , C 4 , h(n U ) [33,34]. However, he/she cannot obtain sensitive data from C 2 because nobody knows x, y, z, and ID CS . From C 3 the attacker can extract PID i which it is stored in SC i . In this case, he/she is not capable to extract sensitive data from SC i .

Privileged Insider Attack
In our scheme, security parameters are personalized using data from each user or cloud server, making more complex the possibility to know secret keys of CS. If a malicious user tries to extract x and y from C 2 or C 3 , he/she needs to recover h(ID CS x) or h(ID CS y) from Equations (3) or (4): but the attacker only know PID i . Moreover, CS does not include its ID CS in any messages or shares it in clear text. Thus, the scheme resists this attack.

Impersonation Attack
In the case that an attacker obtains PID i , C 2 , C 3 , C 4 , h(n U ) from SC i [33,34] and M 5 = T new U , D 1 , PID i , D 2 the attacker cannot create a valid authentication request message by any type of combination of the security parameters. In this case, the malicious user computes D f ake 1 = C 2 ⊕ ID f ake i using ID f ake i but he/she cannot compute a valid PID i and C 3 which are required to compute a valid D 2 . In consequence, the attacker cannot impersonate a legal user.

Replay Attack
In this attack, the malicious user needs to know previous authentication request message M 5 = T new U , D 1 , PID i , D 2 . However, our scheme uses random nonce (n U ) and timestamp (T U ) to avoid replay attack. The control server verifies the freshness of the timestamp every time.

Security of Session Key
A key purpose of an authentication scheme is the establishment of a session key, so the session key should be protected against known-key security and forward secrecy [22].

Known-key Security
In our scheme, CS computes new session key every time the authentication is correct. This means that, CS uses the new random nonce n new U , n new S and n new CS , and its current timestamp T new CS to compute a fresh session key, avoiding the compromise of previous session keys. If the attacker knows M 7 = {D 6 , D 7 , D 10 , D 8 , D 9 , D 11 }, he/she cannot compute a valid session key (SK U−S ) without random nonce and CS s timestamp. Even though the attacker knows past session key SK old U−S , he/she cannot compute the new session key by means of any type of combination.

Forward Secrecy
In our scheme, CS computes the session key without the use of secret keys (x, y, z), avoiding compromise its security in case that an attacker knows the secret keys. Let us suppose that, an attacker knows (x, y, z), he/she cannot compute the correct session key because it does not contain the secret keys. Thus, the attacker cannot create a valid session key.

Local Protection against Malicious Users
In our scheme, SC i verifies the legitimacy of U i by means of Equation (10). This mean that U i must be authenticated by SC i before it computes the user authentication request message [22].

Mutual Authentication
In our scheme, U i and S j verify that each other is a legitimate user in the system and want to establish a secure communication through Equations (37) to (40). In this case, U i sends a challenge to S j for carrying out the mutual authentication process. The response message contains n new CS T new CS which represents the fresh of the communication. Moreover, U i knows the same value, thus avoiding a man-in-the-middle attack.

Evidence of Connection Attempt
In our scheme, S j computes D 5 , using Equation (15), which contains information from U i and S j , making unique the value of D 5 . Then, CS verifies the connection attempt between U i and S j by means of Equation (23). Moreover, CS computes the session key using information of U i , S j and CS.  Table 2 lists comparative results. According to Table 2, it is clear that previous works are vulnerable to different attacks and fails to provide mutual authentication between the server and the user. Moreover, previous works do not provide evidence of connection attempts. In consequence, our protocol resists very well-known attacks, provides evidences of connection attempts, mutual authentication and user anonymity. • T h represents a hash function. • T S represents an encryption/decryption operation using AES algorithm.

•
The execution time for T S is case1: 0.02148 ms [30] and case2: 0.0214385 ms [32]. Table 3 summarizes the operations carried out by U i , S j and CS during the registration, login and authentication phases. The execution time required by U i , S j and CS during each phase is shown in Table 4.  From Table 3, it is easy to see that our scheme requires more computational operations than previous works. However, it is necessary to compute the execution-time in a real scenario. For that reason, we used the execution-time described in [30] and [32] to compare the performance of each scheme. The execution-time results are shown in Table 4, and it is clear that the execution time depends on: (a) the characteristics of each device, (b) the cryptography libraries and (c) the computational load. In our scheme, CS is the participant which computes more computational operations because we assume that has more resources than U i and S j . Moreover, U i computes more computational operations than S j because we assume that U i will request few connections per day; however, S j will receive many request for connection, considering a high volume of users it is necessary that S j computes few computational operations. According with the results summarized in Table 4, the scheme with les computational operations was proposed by Amin et al. [1].
In fact, the execution time of each device must be considered as show in Table 4. The computational operations evaluated using case 2 gives better results than case 1. Under this situation, our scheme requires 40% less time which represents an acceptable performance, less than 0.1862 ms [30]. Figure 7 shows the computational-cost comparison by participant and scheme. In this case, we used the execution-time of the case 1. The main difference between our scheme and previous works is the inclusion of symmetric operations during the authentication phase. The symmetric operations are used to provide mutual authentication between U i and S j , increasing the security of the proposed scheme.

Communication-cost Comparison
In this sub-section, we compare the communication-cost of our scheme with Zhou et al.'s scheme, Amin et al.'s scheme and Xue et al.'s scheme in terms of message length. For conventional comparison, we assume two bit length cases:


Case 1: any identity, password, pseudo-identity, timestamp, random nonce, and hash output are 128 bits.  Case 2: any identity, password, pseudo-identity, timestamp, random nonce, and hash output are 256 bits.  The block length of the symmetric encryption is 128 bits. Table 5 summarizes the message length by each entity during the scheme. From Table 5, we see very clearly that our scheme requires the same message length as Zhou et al.'s scheme, 4352 bits or 8704 bits. However, our scheme provides mutual authentication and evidence of connection attempt, which requires more information to share among participants. If we pay attention phase by phase, our scheme requires less message length during the registration phase

Communication-Cost Comparison
In this sub-section, we compare the communication-cost of our scheme with Zhou et al.'s scheme, Amin et al.'s scheme and Xue et al.'s scheme in terms of message length. For conventional comparison, we assume two bit length cases: • Case 1: any identity, password, pseudo-identity, timestamp, random nonce, and hash output are 128 bits. • Case 2: any identity, password, pseudo-identity, timestamp, random nonce, and hash output are 256 bits.

•
The block length of the symmetric encryption is 128 bits. Table 5 summarizes the message length by each entity during the scheme. From Table 5, we see very clearly that our scheme requires the same message length as Zhou et al.'s scheme, 4352 bits or 8704 bits. However, our scheme provides mutual authentication and evidence of connection attempt, which requires more information to share among participants. If we pay attention phase by phase, our scheme requires less message length during the registration phase than Zhou et al.'s scheme, making our proposal more efficient. In fact, our proposal requires less message length in the login phase than previous works, making it more efficient. After achieving the performance evaluation of the proposed scheme, it is possible to confirm that the proposal has good performance.

Conclusions
In this paper, we demonstrated that Zhou et al.'s scheme is not secure against insider, replay and user impersonation attacks. Moreover, we found security drawbacks which make the scheme proposed by Zhou et al. insecure for IoT in cloud computing circumstances. As a consequence, we propose a new scheme to remedy the security vulnerabilities and drawbacks of Zhou et al.'s scheme.
The new scheme achieves mutual authentication and key agreement, providing secure access to cloud servers. Moreover, the proposal keeps the user identity anonymous against eavesdroppers, provides security for the session key and includes a challenge-response method. In addition, the new scheme includes a sub-phase called evidence connection attempt which proves to the control server any connection attempt between a user and a server.
Furthermore, our performance evaluation demonstrates that our scheme does not require high computational power or several messages to achieve security requirements. On the contrary, the proposed scheme requires less communication-cost than Zhou