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.

1. 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. As a consequence, these novel technologies are changing the world, again, creating new business opportunities, new applications to enhance safety, comfort, and efficiency reducing human efforts, and new ways to collect and analyse data.

Among these five emerging technologies, the IoT and cloud computing have become more and more relevant to academia and industry. In 1999 Ashton introduced the concept of IoT [1], which is defined as the connection of physical objects (devices/sensors) through the Internet [2]. Cloud computing, on the other hand, was introduced in 1961 by McCarthy [3], and 36 years later, Chellappa explained the concept in the scenario of current technology era [4], defined as a large-scale distributed computing paradigm which drives the economy of many companies based on virtualization, managed computing power, and storage focused on its core business [3].

The IoT applications are classified into the following categories [5,6]: (a) Internet of sensors (IoS), which is a network made up of sensors which collect and transmit a types of data; (b) Internet of energy (IoE), which is a network of smart grids to analyse and control the energy production, consumption, storage, and distribution; (c) machine to machine (M2M) communication is a network of devices/sensors connected through the Internet; and (d) Internet of Vehicles (IoV), which is a network of vehicles that can share information about the state of the road. Another classification is based on the communication models [7]: (a) machine-to-machine communication, which includes multiple devices/sensors connected to exchange data among them without a physical infrastructure; (b) machine-to-cloud communication, which includes devices/sensors that consume services from a cloud server for storing and processing data; and (c) machine-to-gateway communication, which includes devices/sensors that collaborate as a proxy to expand the range of the network.

In the case of cloud computing, we can find four types of deployment models offered by cloud providers. The first type is known as public cloud, where services and systems are available for anyone through an open communication channel. The second type is known as private cloud where services and systems are accessible for certain users/employees or organizations through a secure communication channel. The third type is known as community cloud where the cloud is shared by several organizations. The last type which includes a public and private cloud to share resources is known as hybrid cloud [4].

From these service platforms, cloud computing allows the interconnection of everything around us, including our vital signs, personal and sensitive data, that travel through an open communication channel to different sites [8,9,10]. This is possible because devices/sensors automatically collect a huge amount of data and stores them on cloud servers [11,12,13,14]. However, this also represents a significant disadvantage in terms of security, because large amounts of personal and sensitive data stored in a single database could be accessed without the approval of users [9].

On the other hand, the main advantage of the IoT, ubiquity, is also its main weakness, because it is also necessary to have a high and complex security protocol. According to El-Hajj et al. [6] and Ferrag et al. [5], IoT security requirements include authentication, authorization, integrity, confidentiality, non-repudiation, availability, and privacy to protect the data, nodes, and messages against attacks.

Therefore, to address the security requirements of both emerging technologies is important focus special attention on the authentication process, because it is the first line of defense against potential attackers. The goal of the authentication protocol is verifying the identity of an entity to determine that he/she or device/sensor is who or what it claims to be [5,6]. For this reason, the authentication process is a key component for secure Internet communication.

In this sense, a strong authentication protocol needs to achieve the following two aims: mutual authentication and session key agreement [15]. In addition, the authentication protocol must avoid the denial-of-service, forgery, parallel session, password guessing, replay, smart card loss, and stolen-verifier attacks [15]. In the threat model of any authentication protocol, an adversary or malicious user has the computational power to compute complex operations in low time and control the public communication channel to capture and store any messages. In general, security threats include more than thirty kinds 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.

1.1. 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.

1.2. 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.

2. 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.

2.1. Registration Phase

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

2.1.1. User Registration Sub-Phase

In this sub-phase, the user () is registered by the control server (CS). The communication between and CS is through a secure channel. The steps involved in this sub-phase are as follows:

Step 1: selects an identity , pseudo-identity , password , and nonce . Then, computes and sends the registration request message to CS were is a one-way hash function, represents concatenation operation and represents an exclusive-or operation.

Step 2: Upon receiving the registration request message , CS verifies if is valid or not. In case that is invalid, the registration process will be closed. On the other hand, computes and . Then, CS stores in a database and sends the registration response message to .

Step 3: After receiving the registration response message , computes , and , and stores in his smart card.

At this point, the user registration sub-phase is over and was registered by .

2.1.2. Cloud Server Registration Sub-phase

In this sub-phase, the server is registered by the control server . The communication between and CS is through a secure communication channel. The steps involved in this sub-phase are as follows:

Step 1: selects an identity and pseudo-identity . Then, sends the registration request message to CS.

Step 2: Upon receiving the registration request message , CS computes and . Then, stores and sends the registration response message to .

Step 3: After receives the registration response message , stores .

At this point, the cloud server registration sub-phase is over and was registered by .

2.2. Authentication Phase

This phase is divided in the following steps and the details are shown in Figure 1:

Figure 1

Authentication phase of Zhou et al.’s scheme.

Step 1: This step is invoked by , when she/he wants to get access to the service offered by . inserts his/her smart card and keys his/her and . Then, the smart card generates a random number and new pseudo-identity . After that, computes , , , , , , , and . Then, sends the authentication request message to through an open communication channel.

Step 2: This step is invoked by . After receiving the authentication request message , selects a new pseudo-identity and a random number . Then, computes , , , and . Finally, sends the authentication request message to through an open communication channel.

Step 3: This step is invoked by . Upon receiving the authentication request message , computes , , and . Then, checks if and are valid or not. If the verification process fails, closes the communication. On the other hand, computes , , and . Next, checks if and are valid or not. If the verification process fails, closes the communication. On the other hand, selects a random number and computes the session key . Later, computes , , , , , and . Finally, sends to through an open communication channel.

Step 4: This step is invoked by . Yet receiving the authentication response message , computes and . Then, checks if is correct or not. If the verification process is correct, computes and replaces with . Finally, sends to through an open communication channel.

Step 5: This step is invoked by . After receiving the authentication response message , computes and . Then, checks if . is correct or not. If the verification process is correct, computes and replaces with .

2.3. 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.

2.3.1. 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 , computed by during the user registration phase. According with Zhou et al., uses the same secret key to register users and servers, so he/she can find from , searching exhaustively all possible random number until ) to know the secret key of . This attack is possible because the attacker knows and .

2.3.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 sent from to . Under this situation, the attacker can achieve the following active attacks.

Replay Attack

The attacker can transmit the last authentication request message sent to , at any given time and from any given place, to impersonate a legitimate . The description of the attack is as follows:

Step 1: The attacker has, at-least, one authentication request message sent by to , and the attacker knows and .

Step 2: The attacker sends an authentication request message to . The message contains the same information transmitted in previous communication.

Step 3: The attacker uses , and to compute

,

,

, and

.

Step 4: After verifies the authenticity of and , computes and sends

,

, and

.

Step 5: Upon receiving the authentication response message , the attacker computes

and

.

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 . The description of the attack is presented below:

Step 1: The attacker knows , and . Thus, he/she computes

.

Step 2: The attacker recovers from computing

.

Step 3: The attacker has enough information to recover sensitive data as follows

and

.

Step 4: From this point, the attacker computes a fake authentication request message as follows:

,

,

, and

.

Step 5: The attacker sends the fake authentication request message to . After finalizes the process, sends the authentication request message to . Upon receiving the authentication request message , carries out the verification process of computing and verifying . It is obvious that, will pass the verification process because it contains the original and last .

2.4. 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.

2.4.1. Fails to Provide Mutual Authentication

The scheme proposed by Zhou et al. does not provide mutual authentication. The verifies the identity of and 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 and do not contain information which establishes a relationship between and , as evidence to the attempt of connection.

2.4.2. Fails to Protect Secret Key

In the scheme proposed by Zhou et al., the uses the same secret key to register users and servers. Moreover, the secret key is hidden by means of and ; however an attacker can recover it for three reasons.

The first reason is related with the fact that uses the same secret key to register each user and each server, increasing the possibility of finding the correct value of . The second reason is related with the fact that an attacker knows and ; this means that, each user knows two of three security parameters, decreasing the entropy to find , 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 because the attacker knows .

3. 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 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 gets access to security parameters stored in his/her . needs to insert his/her , and inputs and . Then, computes and verifies the legitimacy of . If the verification process is correct, sends the authentication request message to through an open communication channel.

Authentication is the processes by carries out the validation process of and . Moreover, verifies that both entities want to establish a secure communication.

Key agreement is the process by computes the session key for and . The session key is unique.

Mutual authentication is the process through and verifies the legitimacy of each other. In this case, sends a challenge to . If the response is correct, knows that is a member of the system.

Table 1 summarizes the notations used throughout our proposal.

Table 1

Notations of the proposed scheme.

Symbol	Description
U_i	User
S_j	Cloud server
CS	Control server
SC_i	Smart card of U_i
ID_i, SID_j, ID_CS	Identity of U_i, S_j, CS, respectively
PID_i, PSID_j	Pseudo-identity of U_i, S_j, respectively
PW_i	Password of U_i
x, y, z	Secret keys of CS. Secret keys are long integers
n_U, n_S, n_CS	Random nonce of U_i, S_j, CS, respectively
T_U, T_S, T_CS	Timestamp of U_i, S_j, CS, respectively
SK_U−S	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

3.1. Registration Phase

This phase includes user registration and server registration.

3.1.1. User Registration Sub-Phase

This sub-phase is initialized by when wants to be part of the system. The details of each step are shown in Figure 2.

Figure 2

User registration sub-phase.

Step 1: inserts his/her into a device and keys his/her and . Then, generates a random nonce , obtains the current timestamp value and computes: Equation (1) is used to compute the pseudo-identity of each user.

Step 2: After receiving the registration request message , verifies the validity of . If is valid, computes: registers by Equation (2). Equations (3) and (4) are security parameters for future authentication purpose.

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.

3.1.2. 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.

Figure 3

Server registration sub-phase.

Step 1: generates a random nonce , obtains the current timestamp value and computes: Equation (6) is used to compute the pseudo-identity of each server.

Step 2: After receiving the registration request message , verifies the validity of . If is correct, computes: registers by Equation (7). Equations (8) and (9) are security parameters for future authentication purpose.

Step 3: After receiving the registration response message , stores and .

3.2. 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.

Figure 4

Login phase.

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: Equation (10) is used to verify the legitimacy of by for getting access to security parameters provided by .

Step 3: If the verification process is correct, generates a random nonce , obtains the current timestamp value and computes:

Equations (11) and (12) contain ´s information which will be used by to verify its legitimacy. Finally, sends the user authentication request message to through an open communication channel.

Step 4: After receiving the user authentication request message , generates a random nonce , obtains the current timestamp value and computes:

Equations (13) and (14) contain ´s information which will be used by to verify its legitimacy. Equation (15) contains information about and as evidence of its connection attempt. Finally, sends the authentication request message to through an open communication channel.

3.3. 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.

Figure 5

User authentication, server authentication and evidence of connection attempt sub-phases.

3.3.1. User Authentication

Step 1: Upon receiving the authentication request message , checks the freshness of the message by means of . If the verification process is positive, computes: where is the pseudo-identity of contained in message . computed using and Equation (3).

Step 2: verifies the legitimacy of by means of as follows:

Equation (16) is used to recover from . Equation (17) is used to verify the legitimacy of using and . If the verification process is correct, continues with the next step; otherwise, finalizes the process.

Step 3: After verifying the legitimacy of , recovers as follows:

Equation (18) is used to recover from .

Step 4: computes with and using Equation (19). Then, updates in the database:

3.3.2. Server Authentication

Step 1: Upon finalizing the user authentication process, checks the freshness of the message by means of .

Step 2: If the verification process is positive, verifies the legitimacy of as follows:

Equation (20) is used to recover from , using . Then, computes Equation (21) to obtain and compares it with . If the verification process is correct, continues with the process, otherwise, finalizes the process.

Step 3: After verifying the legitimacy of , recover as follows:

Finally, Equation (22) is used to recover from .

3.3.3. Evidence of Connection Attempt

Step 1: corroborates that wants to establish a connection with as follows: in this case, has evidence of the connection attempt between and . It is important to note that, Equation (23) requires the fresh timestamp from and . Moreover, contains , and which demonstrate the interest of the two entities for establishing a secure communication.

3.4. Key Agreement Phase

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

Figure 6

Key agreement and mutual authentication phases.

3.4.1. 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.

Step 3: computes the challenge-response message for and as follows: 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, sends the authentication response message to through an open communication channel.

3.4.2. Server Session Key

Step 1: After receiving , computes and verifies the freshness of : Equation (31) is used to extract from .

Step 2: If is fresh, computes: at this point, knows the session key and the value . Finally, sends to through an open communication channel.

3.4.3. User Session Key

Step 1: Upon receiving the user authentication response message , computes and verifies the freshness of :

Step 2: If is fresh, computes: knows the session key and the value .

3.5. Mutual Authentication

Step 1: sends the challenge message to . contains as proof of his/her legitimacy and requests the response:

Step 2: Upon receiving the challenge message , computes knows that is the user who requested the user authentication by means of Equations (37) and (38). Then, sends the response to .

Step 3: Upon receiving the message , computes and verifies the legitimacy of as follows: finally, recovers the response from using Equation (39) and verifies the legitimacy of by means of Equation (40).

Step 4: replaces , , and with , , and , respectively.

3.6. 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):

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. The performance evaluation includes computational- and communication-cost comparison with Zhou et al.’s, Amin et al.’s and Xue et al.’s schemes.

4.1. Informal Cryptanalysis

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

4.1.1. User Anonymity

In our scheme, sends to instead of in clear text. Moreover, is updated after finalizing the user authentication sub-phase with and , keeping the identity of each user anonym. In consequence, when the user sends the authentication request message to , the will be different. Furthermore, an attacker cannot recover from , , or without security parameters. Therefore, the scheme provides user anonymity.

4.1.2. Off-line User Identity and Password Guessing Attack

In the case that a malicious user obtains , he/she can recover [33,34]. However, he/she cannot obtain sensitive data from because nobody knows x, y, z, and ID. From the attacker can extract which it is stored in . In this case, he/she is not capable to extract sensitive data from .

4.1.3. 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 . If a malicious user tries to extract and from or , he/she needs to recover or from Equations (3) or (4): but the attacker only know . Moreover, does not include its in any messages or shares it in clear text. Thus, the scheme resists this attack.

4.1.4. Impersonation Attack

In the case that an attacker obtains from [33,34] and 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 using but he/she cannot compute a valid and which are required to compute a valid . In consequence, the attacker cannot impersonate a legal user.

4.1.5. Replay Attack

In this attack, the malicious user needs to know previous authentication request message . However, our scheme uses random nonce and timestamp to avoid replay attack. The control server verifies the freshness of the timestamp every time.

4.2. 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].

4.2.1. Known-key Security

In our scheme, computes new session key every time the authentication is correct. This means that, uses the new random nonce , and , and its current timestamp to compute a fresh session key, avoiding the compromise of previous session keys. If the attacker knows , he/she cannot compute a valid session key without random nonce and timestamp. Even though the attacker knows past session key , he/she cannot compute the new session key by means of any type of combination.

4.2.2. Forward Secrecy

In our scheme, computes the session key without the use of secret keys , avoiding compromise its security in case that an attacker knows the secret keys. Let us suppose that, an attacker knows , 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.

4.3. Countermeasures

4.3.1. Local Protection against Malicious Users

In our scheme, verifies the legitimacy of by means of Equation (10). This mean that must be authenticated by before it computes the user authentication request message [22].

4.3.2. Mutual Authentication

In our scheme, and 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, sends a challenge to for carrying out the mutual authentication process. The response message contains which represents the fresh of the communication. Moreover, knows the same value, thus avoiding a man-in-the-middle attack.

4.3.3. Evidence of Connection Attempt

In our scheme, computes , using Equation (15), which contains information from and , making unique the value of . Then, verifies the connection attempt between and by means of Equation (23). Moreover, computes the session key using information of , and .

4.4. Security Comparison

This sub-section presents the security comparison of the proposed scheme with Zhou et al.’s scheme, Amin et al.’s scheme and Xue et al.’s schemes in terms of security properties. Table 2 lists comparative results.

Table 2

Security comparison.

Security Property	Xue et al.	Amin et al.	Zhou et al.	Our Scheme
Provide evidence of connection attempt	fails	fails	fails	success
Provide mutual authentication	fails	fails	fails	success
Provide user anonymity	fails			success
Resist impersonation attack	fails	fails	fails	success
Resist off-line user identity/password attack	fails			success
Resist privileged-insider attack	fails	fails		success
Resist replay attack			fails	success

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.

4.5. Computational-cost Comparison

This sub-section presents the performance evaluation of the proposed scheme with Zhou et al.’s scheme, Amin et al.’s scheme and Xue et al.’s scheme in terms of execution-time. The evaluation of each scheme was based on the following considerations:

T represents a hash function.

T represents an encryption/decryption operation using AES algorithm.

The execution time for T is case 1: 0.00517 ms [30] and case 2: 0.0000328 ms [32].

The execution time for T is case1: 0.02148 ms [30] and case2: 0.0214385 ms [32].

Table 3 summarizes the operations carried out by and during the registration, login and authentication phases. The execution time required by and during each phase is shown in Table 4.

Table 3

Performance comparison.

Phase		Xue et al.	Amin et al.	Zhou et al.	Our Scheme
Registration	U_i	3T_h	3T_h	3T_h	2T_h
	S_j	0T_h	0T_h	0T_h	1T_h
	CS	4T_h	4T_h	4T_h	12T_h
Login	U_i	6T_h	6T_h	6T_h	3T_h
	S_j	3T_h	1T_h	3T_h	3T_h
	CS	0T_h	0T_h	0T_h	0T_h
Authentication	U_i	3T_h	3T_h	4T_h	4T_h+3T_s
	S_j	3T_h	3T_h	4T_h	2T_h+3T_s
	CS	14T_h	10T_h	19T_h	21T_h+2T_s
Total		36T_h	30T_h	43T_h	48T_h+8T_s

Table 4

Execution-time by participant.

		Xue et al.			Amin et al.			Zhou et al.			Our
		Op	Case 1	Case 2	Op	Case 1	Case 2	Op	Case 1	Case 2	Op	Case 1	Case 2
R	U_i	3Th	0.01551	0.0000984	3Th	0.01551	0.0000984	3TH	0.01551	0.0000984	2Th	0.01034	0.0000656
	S_j	0Th	0	0	0Th	0	0	0TH	0	0	1Th	0.00517	0.0000328
	CS	4Th	0.02068	0.0001312	4Th	0.02068	0.0001312	4TH	0.02068	0.0001312	12Th	0.06204	0.0003936
L	U_i	6Th	0.03102	0.0001968	6Th	0.03102	0.0001968	6Th	0.03102	0.0001968	3Th	0.01551	0.0000984
	S_j	3Th	0.01551	0.0000984	1Th	0.00517	0.0000328	3Th	0.01551	0.0000984	3Th	0.01551	0.0000984
	CS	0Th	0	0	0Th	0	0	0Th	0	0	0Th	0	0
A	U_i	3Th	0.01551	0.0000984	3Th	0.01551	0.0000984	4Th	0.02068	0.0001312	4Th + 3Ts	0.08512	0.0644467
	S_j	3Th	0.01551	0.0000984	3Th	0.01551	0.0000984	4Th	0.02068	0.0001312	2Th + 3Ts	0.07478	0.0643811
	CS	14Th	0.07238	0.0004592	10Th	0.0517	0.000328	19Th	0.09823	0.0006232	21Th + 2Ts	0.15153	0.0435658
Total		36Th	0.18612	0.0011808	30Th	0.1551	0.000984	43Th	0.22231	0.0014104	48Th + 8Ts	0.420000	0.173082

*R = Registration phase, L = Login phase, A = Authentication phase, Op = Number of operations.

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, is the participant which computes more computational operations because we assume that has more resources than and . Moreover, computes more computational operations than because we assume that will request few connections per day; however, will receive many request for connection, considering a high volume of users it is necessary that 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 and , increasing the security of the proposed scheme.

Figure 7

Computational-cost comparison by participant.

4.6. 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.

Table 5

Communication cost comparison.

		Xue et al.			Amin et al.			Zhou et al.			Our Scheme
		Length	Case 1	Case 2	Length	Case 1	Case 2	Length	Case 1	Case 2	Length	Case 1	Case 2
R	U_i	3	384	768	2	256	512	2	256	512	2	256	512
	S_j	2	256	512	2	256	512	2	256	512	2	256	512
	CS	2	256	512	3	384	768	6	768	1536	4	512	1024
	ST		896	1792		896	1792		1280	2560		1024	2048
L	U_i	6	768	1536	5	640	1280	5	640	1280	4	512	1024
	S_j	11	1408	2816	9	1152	2304	10	1280	2560	9	1152	2304
	CS	0	0	0	0	0	0	0	0	0	0	0	0
	ST		2176	4352		1792	3584		1920	3840		1664	3328
A	U_i	0	0	0	0	0	0	0	0	0	2	256	512
	S_j	2	256	512	2	256	512	3	384	768	5	640	1280
	CS	4	512	1024	4	512	1024	6	768	1536	6	768	1536
	ST		768	1536		768	1536		1152	2304		1664	3328
	T	30	3840	7680	27	3456	6912	34	4352	8704	34	4352	8704

*R = Registration phase, L = Login phase, A = Authentication phase, ST = Subtotal, T = Total.

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.

5. 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 et al.’s, Amin et al.’s and Xue et al.’s schemes in the registration and login phases, and the computational-cost is acceptable considering the security characteristics included in the scheme. Thus, the scheme meets the security requirements for a secure IoT-based authentication scheme in cloud computing circumstance, enhancing security of previous works.