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

Abstract

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 ($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 $\left(I{D}_i\right)$, pseudo-identity $\left(PI{D}_i\right)$, password $\left(P{W}_i\right)$, and nonce $\left(b_i\right)$. Then, $U_i$ computes $H{P}_i=h\left(P{W}_i\parallel b_i\right)$ and sends the registration request message $M_1=\left\{I{D}_i,PI{D}_i\right\}$ to CS were $h(·)$ is a one-way hash function, $\parallel$ represents concatenation operation and $\oplus$ represents an exclusive-or operation.

Step 2: Upon receiving the registration request message $M_1$, CS verifies if $I{D}_i$ is valid or not. In case that $I{D}_i$ is invalid, the registration process will be closed. On the other hand, $CS$ computes $C_1^{*}=h\left(PI{D}_i\parallel I{D}_{CS}\parallel x\right)$ and $C_2^{*}=h\left(I{D}_i\parallel x\right)$. Then, CS stores $I{D}_i$ in a database and sends the registration response message $M_2=\left\{C_1,C_2,I{D}_{CS}\right\}$ to $U_i$.

Step 3: After receiving the registration response message $M_2$, $U_i$ computes $C_1=C_1^{*} \oplus H{P}_i$, $C_2=C_2^{*} \oplus h\left(I{D}_i\parallel H{P}_i\right)$ and $C_3=b_i \oplus h\left(I{D}_i\parallel P{W}_i\right)$, and stores $\left(C_1,C_2,C_3,PI{D}_i,I{D}_{CS}\right)$ in his smart card.

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

2.1.2. Cloud Server Registration Sub-phase

In this sub-phase, the server $\left(S_j\right)$ is registered by the control server $\left(CS\right)$. 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 $\left(SI{D}_j\right)$ and pseudo-identity $\left(PSI{D}_j\right)$. Then, $S_j$ sends the registration request message $M_3=\left\{SI{D}_j,PSI{D}_j\right\}$ to CS.

Step 2: Upon receiving the registration request message $M_3$, CS computes $B_1=h\left(PSI{D}_j\parallel I{D}_{CS}\parallel x\right)$ and $B_2=h\left(SI{D}_j\parallel x\right)$. Then, $CS$ stores $SI{D}_j$ and sends the registration response message $M_4=\left\{B_1,B_2,I{D}_{CS}\right\}$ to $S_j$.

Step 3: After $S_j$ receives the registration response message $M_4$, $S_j$ stores $\left(B_1,B_2,SI{D}_j,PSI{D}_j,I{D}_{CS}\right)$.

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

2.2. 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 $I{D}_i$ and $P{W}_i$. Then, the smart card generates a random number $\left(r_U\right)$ and new pseudo-identity $\left(PI{D}_i^{new}\right)$. After that, $U_i$ computes $b_i=C_3\oplus h\left(I{D}_i\parallel P{W}_i\right)$, $H{P}_i=h\left(P{W}_i\parallel b_i\right)$, $C_1^{*}=C_1\oplus H{P}_i$, $C_2^{*}=C_2\oplus h\left(I{D}_I\parallel H{P}_I\right)$, $D_1=C_1^{*}\oplus r_U$, $D_2=h\left(PI{D}_i\parallel I{D}_{CS}\parallel r_U\right)\oplus I{D}_i$, $D_3=C_2^{*}\oplus h\left(I{D}_i\parallel H{P}_i\right)\oplus PI{D}^{new}\oplus h\left(r_U\parallel I{D}_i\right)$, and $D_4=h\left(I{D}_i\parallel PI{D}_i\parallel PI{D}_i^{new}\parallel r_U\parallel D_3\right)$. Then, $U_i$ sends the authentication request message $M_5=\left\{PI{D}_i, D_1, D_2, D_3,D_4\right\}$ to $S_j$ through an open communication channel.

Step 2: This step is invoked by $S_j$. After receiving the authentication request message $M_5$, $S_j$ selects a new pseudo-identity $\left(PSI{D}_j^{new}\right)$ and a random number $\left(r_S\right)$. Then, $S_j$ computes $D_5=B_1\oplus r_S$, $D_6=h\left(r_S\parallel PSI{D}_j\parallel I{D}_{CS}\right)\oplus SI{D}_j$, $D_7=B_2\oplus PSI{D}_j^{new}\oplus h\left(r_S\parallel SI{D}_j\right)$, and $D_8=h\left(SI{D}_j\parallel PSI{D}_j\parallel PSI{D}_j^{new}\parallel r_S\parallel D_7\right)$. Finally, $S_j$ sends the authentication request message $M_6=\left\{PI{D}_i, D_1, D_2, D_3, D_4, PSI{D}_j, D_5, D_6, D_7, D_8\right\}$ to $CS$ through an open communication channel.

Step 3: This step is invoked by $CS$. Upon receiving the authentication request message $M_6$, $CS$ computes $r_U=D_1\oplus h\left(PI{D}_i\parallel I{D}_{CS}\parallel x\right)$, $I{D}_i=D_2\oplus h\left(r_U\parallel PI{D}_i\parallel I{D}_{CS}\right)$, and $PI{D}_i^{new}=D_3\oplus h\left(I{D}_i\parallel x\right)\oplus h\left(r_U\parallel I{D}_i\right)$. Then, $CS$ checks if $I{D}_i$ and $D_4$ are valid or not. If the verification process fails, $CS$ closes the communication. On the other hand, $CS$ computes $r_S=D_5\oplus h\left(PSI{D}_j\parallel I{D}_{CS}\parallel x\right)$, $SI{D}_j=D_6\oplus h\left(r_S\parallel PSI{D}_j\parallel I{D}_{CS}\right)$, and $PSI{D}_j^{new}=D_7\oplus h\left(SI{D}_j\parallel x\right)\oplus h\left(r_S\parallel SI{D}_j\right)$. Next, $CS$ checks if $SI{D}_j$ and $D_8$ are valid or not. If the verification process fails, $CS$ closes the communication. On the other hand, $CS$ selects a random number $\left(r_{CS}\right)$ and computes the session key $S{K}_{CS}=h\left(r_U\oplus r_S\oplus r_{SC}\right)$. Later, $CS$ computes $D_9=h\left(PSI{D}_j^{new}\parallel I{D}_{CS}\parallel x\right)\oplus h\left(r_S\parallel PSI{D}_j^{new}\right)$, $D_{10}=h\left(PSI{D}_j^{new}\parallel r_S\parallel PSI{D}_j\right)\oplus \left(r_U\oplus r_{CS}\right)$, $=h\left(S{K}_{CS}\parallel D_9\parallel D_{10}\parallel h\left(SI{D}_j\parallel x\right)\right)$, $D_{12}=h\left(PI{D}_i^{new}\parallel I{D}_{cs}\parallel x\right)\oplus h\left(r_U\parallel PI{D}_i^{new}\right)$, $D_{13}=h\left(PI{D}_i^{new}\parallel r_U\parallel PI{D}_i\right)\oplus \left(r_S\oplus r_{SC}\right)$, and $D_{14}=h\left(S{K}_{CS}\parallel D_{12}\parallel D_{13}\parallel h\left(I{D}_i\parallel x\right)\right)$. Finally, $CS$ sends $M_7=\left\{D_9,D_{10},D_{11},D_{12},D_{13},D_{14}\right\}$ to $S_j$ through an open communication channel.

Step 4: This step is invoked by $S_j$. Yet receiving the authentication response message $M_7$, $S_j$ computes $\left(r_U\oplus r_{CS}\right)=D_{10}\oplus h\left(PSI{D}_j^{new}\parallel r_S\parallel PSI{D}_j\right)$ and $S{K}_S=h\left(r_S\oplus r_U\oplus r_{CS}\right)$. Then, $S_j$ checks if $D_{11}$ is correct or not. If the verification process is correct, $S_j$ computes $B_1^{new}=D_9\oplus h\left(r_S\parallel PSI{D}_j^{new}\right)$ and replaces $B_1, PSI{D}_j$ with $B_1^{new}, PSI{D}_j^{new}$. Finally, $S_j$ sends $M_8=\left\{D_{12},D_{13},D_{14}\right\}$ to $U_i$ through an open communication channel.

Step 5: This step is invoked by $U_i$. After receiving the authentication response message $M_8$, $U_i$ computes $\left(r_S\oplus r_{SC}\right)=D_{13}\oplus h\left(PI{D}_i^{new}\parallel r_U\parallel PI{D}_i\right)$ and $S{K}_U=h\left(r_U\oplus r_S\oplus r_{CS}\right)$. Then, $U_i$ checks if $D_{14}$. is correct or not. If the verification process is correct, $U_i$ computes $C_i^{new}=D_{12}\oplus h\left(r_U\parallel PI{D}_i^{new}\right)\oplus H{P}_i$ and replaces $C_1, PI{D}_i$ with $C_1^{new}, PI{D}_i^{new}$.

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 $C_2^{*}=h\left(I{D}_i\parallel x\right)$, computed by $CS$ during the user registration phase. According with Zhou et al., $CS$ uses the same secret key $\left(x\right)$ to register users and servers, so he/she can find $x$ from $C_2^{*}$, searching exhaustively all possible random number $y$ until $h\left(I{D}_i\parallel y\right)=C_2^{*}=h(I{D}_i\parallel x$) to know the secret key of $CS$. This attack is possible because the attacker knows $I{D}_i$ and $C_2^{*}$.

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 $M_5=\left\{PI{D}_i, D_1, D_2, D_3,D_4\right\}$ sent from $U_i$ to $S_j$. 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 $I{D}_{CS}$ and $x$.

Step 2: The attacker sends an authentication request message $M_5^{replay}$ to $S_j$. The message contains the same information transmitted in previous communication.

Step 3: The attacker uses $I{D}_{CS}$, $x$ and $PI{D}_i$ to compute

$C_1^{*}=h\left(PI{D}_i\parallel I{D}_{CS}\parallel x\right)$,

$r_U=D_1\oplus h\left(PI{D}_i\parallel I{D}_{CS}\parallel x\right)$,

$I{D}_i=D_2\oplus h\left(r_U\parallel PI{D}_i\parallel I{D}_{CS}\right)$, and

$PI{D}_i^{new}=D_3\oplus h\left(I{D}_i\parallel x\right)\oplus h\left(r_U\parallel I{D}_i\right)$.

Step 4: After $CS$ verifies the authenticity of $I{D}_i$ and $D_4$, $CS$ computes and sends

$D_{12}=h\left(PI{D}_i^{new}\parallel I{D}_{cs}\parallel x\right)\oplus h\left(r_U\parallel PI{D}_i^{new}\right)$,

$D_{13}=h\left(PI{D}_i^{new}\parallel r_U\parallel PI{D}_i\right)\oplus \left(r_S\oplus r_{SC}\right)$, and

$D_{14}=h\left(S{K}_{CS}\parallel D_{12}\parallel D_{13}\parallel h\left(I{D}_i\parallel x\right)\right)$.

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

$\left(r_S\oplus r_{SC}\right)=D_{13}\oplus h\left(PI{D}_i^{new}\parallel r_U\parallel PI{D}_i\right)$ and

$S{K}_U=h\left(r_U\oplus r_S\oplus r_{CS}\right)$.

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 $I{D}_{CS}$, $x$ and $PID$. Thus, he/she computes

$C_1^{*}=h\left(PI{D}_i\parallel I{D}_{CS}\parallel x\right)$.

Step 2: The attacker recovers $r_U$ from $D_1$ computing

$r_U=D_1\oplus h\left(PI{D}_i\parallel I{D}_{CS}\parallel x\right)$.

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

$I{D}_i=D_2\oplus h\left(r_U\parallel PI{D}_i\parallel I{D}_{CS}\right)$ and

$PI{D}_i^{new}=D_3\oplus h\left(I{D}_i\parallel x\right)\oplus h\left(r_U\parallel I{D}_i\right)$.

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

$D_1^{fake}=C_1^{*}\oplus r_U^{fake}$,

$D_2^{fake}=h\left(PI{D}_i^{new}\parallel I{D}_{CS}\parallel r_U^{fake}\right)\oplus I{D}_i$,

$D_3^{fake}=C_2^{*}\oplus PI{D}_i^{fake}\oplus h\left(r_U^{fake}\parallel I{D}_i\right)$, and

$D_4^{fake}=h\left(I{D}_i\parallel PI{D}_i^{new}\parallel PI{D}_i^{fake}\parallel r_U^{fake}\parallel D_3^{fake}\right)$.

Step 5: The attacker sends the fake authentication request message $M_5^{fake}=\left\{PI{D}_i^{new}, D_1^{fake},D_2^{fake}, D_3^{fake},D_4^{fake}\right\}$ to $S_j$. After $S_j$ finalizes the process, $S_j$ sends the authentication request message $M_6=\left\{PI{D}_i^{new}, D_1^{fake},D_2^{fake}, D_3^{fake},D_4^{fake},PSI{D}_j,D_5,D_6,D_7,D_8\right\}$ to $CS$. Upon receiving the authentication request message $M_6$, $CS$ carries out the verification process of $D_4^{fake}$ computing $h\left(I{D}_i\parallel PI{D}_i^{new}\parallel PI{D}_i^{fake}\parallel r_U^{fake}\parallel D_3^{fake}\right)$ and verifying $D_4^{fake} ?=h\left(I{D}_i\parallel PI{D}_i^{new}\parallel PI{D}_i^{fake}\parallel r_U^{fake}\parallel D_3^{fake}\right)$. It is obvious that, $D_4^{fake}$ will pass the verification process because it contains the original $I{D}_i$ and last $PI{D}_i^{new}$.

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

2.4.2. Fails to Protect Secret Key

In the scheme proposed by Zhou et al., the $CS$ uses the same secret key $\left(x\right)$ to register users and servers. Moreover, the secret key is hidden by means of $C_1^{*}=h\left(PI{D}_i\parallel I{D}_{CS}\parallel x\right)$ and $C_2^{*}=h\left(I{D}_i\parallel x\right)$; 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 $I{D}_{CS}$ and $PI{D}_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\left(I{D}_i\parallel x\right)$ because the attacker knows $I{D}_i$.

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 $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 $S{C}_U$. $U_i$ needs to insert his/her $S{C}_U$, and inputs $I{D}_i$ and $P{W}_i$. Then, $S{C}_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. Notations of the proposed scheme.

Symbol	Description
$U_i$	User
$S_j$	Cloud server
$CS$	Control server
$S{C}_i$	Smart card of $U_i$
$I{D}_i, SI{D}_j, I{D}_{CS}$	Identity of $U_i$, $S_j$, $CS$, respectively
$PI{D}_i, PSI{D}_j$	Pseudo-identity of $U_i$, $S_j$, respectively
$P{W}_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
$S{K}_{U-S}$	Session key between $U_i$ and $S_j$
$E_{SK}(·)/D_{SK}(·)$	Symmetric encryption/decryption using $S{K}_{U-S}$
$h(·)$	Collision free one-way hash function
$\oplus$	Exclusive-OR operation
$\parallel$	Concatenation operation
$\Rightarrow$	Secure communication channel
$\to$	Open communication channel

summarizes the notations used throughout our proposal.

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 $U_i$ when wants to be part of the system. The details of each step are shown in Figure 2.

Step 1: $U_i$ inserts his/her $S{C}_i$ into a device and keys his/her $I{D}_i$ and $P{W}_i$. Then, $S{C}_i$ generates a random nonce $\left(n_U\right)$, obtains the current timestamp value $\left(T_U\right)$ and computes:

$$PI{D}_i=h\left(T_U\parallel n_U\right)$$

(1)

$$U_i\Rightarrow CS:M_1=\left\{I{D}_i,PI{D}_i\right\}$$

Equation (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 $I{D}_i$. If $I{D}_i$ is valid, $CS$ computes:

$$C_1=h\left(I{D}_i\parallel PI{D}_i\right)$$

(2)

$$C_2=h\left(PI{D}_i\parallel h\left(I{D}_{CS}\parallel x\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)\oplus h\left(I{D}_{CS}\parallel x\right)\oplus h\left(I{D}_{CS}\parallel y\right)$$

(3)

$$C_3=h\left(I{D}_i\parallel PI{D}_i\parallel h\left(I{D}_{CS}\parallel x\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)\oplus PI{D}_i\oplus h\left(x\parallel y\right)$$

(4)

$$STORES C_1 in a database$$

$$CS\Rightarrow U_i: M_2=\left\{C_2, C_3\right\}$$

$CS$ registers $U_i$ by Equation (2). Equations (3) and (4) are security parameters for future authentication purpose.

Step 3: Upon receiving the registration response message $M_2$, $S{C}_i$ computes:

$$C_4=h\left(I{D}_i\parallel P{W}_i\parallel h\left(n_U\right)\right)$$

(5)

$$STORES PI{D}_i,C_2,C_3,C_4,h\left(n_U\right) in S{C}_i$$

$S{C}_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.

3.1.2. 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 1: $S_j$ generates a random nonce $n_S$, obtains the current timestamp value $T_S$ and computes:

$$PSI{D}_j=h\left(T_S\parallel n_S\right)$$

(6)

$$S_j\Rightarrow CS:M_3=\left\{SI{D}_j,PSI{D}_j\right\}$$

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 $SI{D}_j$. If $SI{D}_j$ is correct, $CS$ computes:

$$B_1=h\left(SI{D}_j\parallel PSI{D}_j\right)$$

(7)

$$B_2=h\left(PSI{D}_j\parallel h\left(I{D}_{CS}\parallel z\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)\oplus h\left(I{D}_{CS}\parallel z\right)\oplus h\left(I{D}_{CS}\parallel y\right)$$

(8)

$$B_3=h\left(SI{D}_j\parallel PSI{D}_j\parallel h\left(I{D}_{CS}\parallel z\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)\oplus PSI{D}_j\oplus h\left(z\parallel y\right)$$

(9)

$$STORES B_1 in a database$$

$$CS\Rightarrow S_j:M_4=\left\{B_2,B_3\right\}$$

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

3.2. 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 $S{C}_i$ and keys his/her $I{D}_i^{*}$ and $P{W}_i^{*}$.

Step 2: Then, $S{C}_i$ computes and checks:

$$C_4^{*}=h\left(I{D}_i^{*}\parallel P{W}_i^{*}\parallel h\left(n_U\right)\right) ?=C_4$$

(10)

Equation (10) is used to verify the legitimacy of $U_i$ by $S{C}_i$ for getting access to security parameters provided by $S_j$.

Step 3: If the verification process is correct, $S{C}_i$ generates a random nonce $n_U^{new}$, obtains the current timestamp value $T_U^{new}$ and computes:

$$D_1=C_2\oplus I{D}_i$$

(11)

$$D_2=C_3\oplus h\left(T_U^{new}\parallel I{D}_i\right)\oplus h\left(n_u^{new}\right)$$

(12)

$$U_i\to S_j:M_5=\left\{T_U^{new},D_1,PI{D}_i,D_2\right\}$$

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_S^{new}$, obtains the current timestamp value $T_S^{new}$ and computes:

$$D_3=B_2\oplus SI{D}_j$$

(13)

$$D_4=B_3\oplus h\left(T_S^{new}\parallel SI{D}_j\right)\oplus h\left(n_S^{new}\right)$$

(14)

$$D_5=h\left(PI{D}_i\parallel T_U^{new}\parallel SI{D}_j\parallel PSI{D}_j\parallel T_S^{new}\right)$$

(15)

$$S_j\to CS:M_6=\left\{T_U^{new},D_1,PI{D}_i,D_2,T_S^{new},D_3,PSI{D}_j,D_4,D_5\right\}$$

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.

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.

3.3.1. User Authentication

Step 1: Upon receiving the authentication request message $M_6$, $CS$ checks the freshness of the message by means of $T_U^{new}$. If the verification process is positive, $CS$ computes:

$$C_2^{*}=h{\left(PI{D}_i^{*}\parallel h\left(I{D}_{CS}\parallel x\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)}^{*}\oplus h\left(I{D}_{CS}\parallel x\right)\oplus h\left(I{D}_{CS}\parallel y\right)$$

where $PI{D}_i^{*}$ is the pseudo-identity of $U_i$ contained in message $M_2$. $CS$ computed $C_2^{*}$ using $PI{D}_i^{*}$ and Equation (3).

Step 2: $CS$ verifies the legitimacy of $U_i$ by means of $C_1$ as follows:

$$\begin{gathered} D_1=C_2^{*}\oplus I{D}_i \\ {D}_1=h{\left(PI{D}_i^{*}\parallel h\left(I{D}_{CS}\parallel x\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)}^{*}\oplus h\left(I{D}_{CS}\parallel x\right)\oplus h\left(I{D}_{CS}\parallel y\right)\oplus I{D}_i \\ I{D}_i^{*}=h{\left(PI{D}_i^{*}\parallel h\left(I{D}_{CS}\parallel x\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)}^{*}\oplus h\left(I{D}_{CS}\parallel x\right)\oplus h\left(I{D}_{CS}\parallel y\right)\oplus D_1 \end{gathered}$$

(16)

$$C_1^{*}=h\left(I{D}_i^{*}\parallel PI{D}_i\right) ?=C_1$$

(17)

Equation (16) is used to recover $I{D}_i^{*}$ from $D_1$. Equation (17) is used to verify the legitimacy of $U_i$ using $I{D}_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\left(n_U^{new}\right)$ as follows:

$$h{\left(n_U^{new}\right)}^{*}=h{\left(I{D}_i^{*}\parallel PI{D}_i^{*}\parallel h\left(I{D}_{CS}\parallel x\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)}^{*}\oplus PI{D}_i^{*}\oplus h\left(x\parallel y\right)\oplus h{\left(T_U^{new}\parallel I{D}_i^{*}\right)}^{*}\oplus D_2$$

(18)

Equation (18) is used to recover $h{\left(n_U^{new}\right)}^{*}$ from $D_2$.

Step 4: $CS$ computes $C_1^{new}$ with $T_U^{new}$ and $h{\left(n_U^{new}\right)}^{*}$ using Equation (19). Then, $CS$ updates $C_1$ in the database:

$$C_1^{new}=h\left(I{D}_i\parallel h\left(T_U^{new}\parallel C_1\parallel h\left(n_U^{new}\right)\right)\right)$$

(19)

3.3.2. Server Authentication

Step 1: Upon finalizing the user authentication process, $CS$ checks the freshness of the message by means of $T_S^{new}$.

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

$$\begin{gathered} D_3=B_2\oplus SI{D}_j \\ {B}_2=h{\left(PSI{D}_j^{*}\parallel h\left(I{D}_{CS}\parallel z\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)}^{*}\oplus h\left(I{D}_{CS}\parallel z\right)\oplus h\left(I{D}_{CS}\parallel y\right)\oplus SI{D}_j \\ SI{D}_j^{*}=h{\left(PSI{D}_j^{*}\parallel h\left(I{D}_{CS}\parallel z\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)}^{*}\oplus h\left(I{D}_{CS}\parallel z\right)\oplus h\left(I{D}_{CS}\parallel y\right)\oplus D_3 \end{gathered}$$

(20)

$$B_1^{*}=h\left(SI{D}_j^{*}\parallel PSI{D}_j^{*}\right) ?=B_1$$

(21)

Equation (20) is used to recover $SI{D}_j^{*}$ from $D_3$, using $PSI{D}_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\left(n_S^{new}\right)$ as follows:

$$h{\left(n_S^{new}\right)}^{*}=h{\left(SI{D}_j^{*}\parallel PSI{D}_j^{*}\parallel h\left(I{D}_{CS}\parallel z\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)}^{*}\oplus PSI{D}_j^{*}\oplus h\left(z\parallel y\right)\oplus h\left(T_S^{new}\parallel SI{D}_j^{*}\right)\oplus D_4$$

(22)

Finally, Equation (22) is used to recover $h{\left(n_S^{new}\right)}^{*}$ from $D_4$.

3.3.3. Evidence of Connection Attempt

Step 1: $CS$ corroborates that $U_i$ wants to establish a connection with $S_j$ as follows:

$$D_5^{*}=h{\left(PI{D}_i^{*}\parallel T_U^{new}\parallel SI{D}_j^{*}\parallel PSI{D}_j^{*}\parallel T_S^{new}\right)}^{*} ?=D_5$$

(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 $PI{D}_i$, $SI{D}_j$ and $PSI{D}_j$ 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.

3.4.1. 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_{CS}^{new}$ and computes the session key $S{K}_{U-S}$ as follows:

$$S{K}_{U-S}=h\left(h\left(n_U^{new}\right)\oplus h\left(n_S^{new}\right)\oplus h\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)\right)$$

(24)

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:

$$D_6=B_2\oplus h\left(T_S^{new}\parallel SI{D}_j\right)\oplus T_{CS}^{new}$$

(25)

$$D_7=h\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)\oplus h\left(SI{D}_j\parallel T_{CS}^{new}\right)\oplus h\left(n_U^{new}\right)$$

(26)

$$D_8=C_2\oplus h\left(T_U^{new}\parallel I{D}_i\right)\oplus T_{CS}^{new}$$

(27)

$$D_9=h\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)\oplus h\left(I{D}_i\parallel T_{CS}^{new}\right)\oplus h\left(n_S^{new}\right)$$

(28)

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:

$$D_{10}=E_{SK}\left(h\left(n_{CS}^{new}\right)\oplus h\left(SI{D}_j\parallel PSI{D}_j\parallel B_2\right)\right)$$

(29)

$$D_{11}=E_{SK}\left(h\left(n_{CS}^{new}\right)\oplus h\left(I{D}_i\parallel PI{D}_i\parallel C_2\right)\right)$$

(30)

$$CS\to S_j:M_7=\left\{D_6,D_7,D_{10},D_8,D_9,D_{11}\right\}$$

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

3.4.2. Server Session Key

Step 1: After receiving $M_7$, $S_j$ computes and verifies the freshness of $M_7$:

$$T_{CS}^{new*}=B_2\oplus h\left(T_S^{new}\parallel SI{D}_j\right)\oplus D_6$$

(31)

Equation (31) is used to extract $T_{CS}^{new*}$ from $D_6$.

Step 2: If $M_7$ is fresh, $S_j$ computes:

$$h{\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)}^{*}\oplus h{\left(n_U^{new}\right)}^{*}=h\left(SI{D}_j\parallel T_{CS}^{new}\right)\oplus D_7$$

(32)

$$S{K}_{U-S}^{*}=h\left(h{\left(n_U^{new}\right)}^{*}\oplus h\left(n_S^{new}\right)\oplus h{\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)}^{*}\right)$$

$$h{\left(n_{CS}^{new}\right)}^{*}=h\left(n_{CS}^{new}\right)\oplus h\left(SI{D}_j\parallel PSI{D}_j\parallel B_2\right)=D_{S{K}^{*}}\left(D_{10}\right)$$

(33)

$$S_j\to U_i:M_8=\left\{D_8,D_9,D_{11}\right\}$$

at this point, $S_j$ knows the session key $\left(S{K}_{U-S}^{*}\right)$ and the value $h{\left(n_{CS}^{new}\right)}^{*}$. Finally, $S_j$ sends $M_8$ to $U_i$ through an open communication channel.

3.4.3. User Session Key

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

$$T_{CS}^{new*}=C_2\oplus h\left(T_U^{new}\parallel I{D}_i\right)\oplus D_8$$

(34)

Step 2: If $M_8$ is fresh, $U_i$ computes:

$$h{\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)}^{*}\oplus h{\left(n_S^{new}\right)}^{*}=h\left(I{D}_i\parallel T_{CS}^{new}\right)\oplus D_9$$

(35)

$$S{K}_{U-S}^{*}=h\left(h\left(n_U^{new}\right)\oplus h{\left(n_S^{new}\right)}^{*}\oplus h{\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)}^{*}\right)$$

$$D_{S{K}^{*}}\left(D_{11}\right)=h\left(n_{CS}^{new}\right)\oplus h\left(I{D}_i\parallel PI{D}_i\parallel C_2\right)=h{\left(n_{CS}^{new}\right)}^{*}$$

(36)

$U_i$ knows the session key and the value $h{\left(n_{CS}^{new}\right)}^{*}$.

3.5. Mutual Authentication

Step 1: $U_i$ sends the challenge message $M_9$ to $S_j$. $M_9$ contains $h\left(n_{CS}^{new}\right)$ as proof of his/her legitimacy and requests the response:

$$U_i\to S_j:M_9=\left\{E_{SK}\left(h\left(n_{CS}^{new}\right)\parallel serverValue\left(challenge\right)\right)\right\}$$

Step 2: Upon receiving the challenge message $M_9$, $S_j$ computes

$$h{\left(n_{CS}^{new}\right)}^{*}\parallel serverValue\left(challenge\right)=D_{SK}\left(M_9\right)$$

(37)

$$h{\left(n_{CS}^{new}\right)}^{*}?=h\left(n_{CS}^{new}\right)$$

(38)

$$S_j\to U_i:M_{10}=\left\{E_{SK}\left(serverValue\left(h\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)\oplus h\left(n_U^{new}\right)\right)\right)\right\}$$

$S_j$ knows that $U_i$ is the user who requested the user authentication by means of Equations (37) and (38). Then, $S_j$ sends the response to $U_i$.

Step 3: Upon receiving the message $M_{10}$, $U_i$ computes and verifies the legitimacy of $S_j$ as follows:

$$h{\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)}^{*}\oplus h\left(n_U^{new}\right)=serverValue\left(h\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)\oplus h\left(n_U^{new}\right)\right)=D_{SK}\left(M_{10}\right)$$

(39)

$$h{\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)}^{*}?=h\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)$$

(40)

finally, $U_i$ recovers the response from $M_{10}$ using Equation (39) and verifies the legitimacy of $S_j$ by means of Equation (40).

Step 4: $U_i$ replaces $PI{D}_i$, $h\left(n_U\right)$, and $C_4=h\left(I{D}_i\parallel P{W}_i\parallel h\left(n_U\right)\right)$ with $PI{D}_i^{new}=\left(h\left(T_U^{new}\parallel h\left(I{D}_i\parallel PI{D}_i\right)\parallel n_U^{new}\right)\right)$, $h\left(n_U^{new}\right)$, and $C_4^{new}=h\left(I{D}_i\parallel P{W}_i\parallel h\left(n_U^{new}\right)\right)$, respectively.

3.6. Password Change Phase

When $U_i$ wants to change or to update his/her password, he/she needs to key his/her $I{D}_i$ and $P{W}_i$. Then, $S{C}_i$ computes Equation (10) to verify his/her legitimacy. If the verification process is correct, $U_i$ keys $P{W}_i^{new}$ and $S{C}_i$ computes Equation (40):

$$C_4^{new}=h\left(I{D}_i\parallel P{W}_i^{new}\parallel h\left(n_u\right)\right)$$

(41)

$$UPDATES C_4$$

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, $U_i$ sends $PI{D}_i=h\left(T_U\parallel n_U\right)$ to $S_j$ instead of $I{D}_i$ in clear text. Moreover, $PI{D}_i$ is updated after finalizing the user authentication sub-phase with $T_U^{new}$ and $n_U^{new}$, keeping the identity of each user anonym. In consequence, when the user sends the authentication request message to $S_j$, the $PI{D}_i$ will be different. Furthermore, an attacker cannot recover $I{D}_i$ from $PI{D}_i$, $D_1$, or $D_2$ 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 $S{C}_i$, he/she can recover $PI{D}_i,C_2,C_3,C_4,h\left(n_U\right)$ [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 $PI{D}_i$ which it is stored in $S{C}_i$. In this case, he/she is not capable to extract sensitive data from $S{C}_i$.

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 $CS$. If a malicious user tries to extract $x$ and $y$ from $C_2$ or $C_3$, he/she needs to recover $h\left(I{D}_{CS}\parallel x\right)$ or $h\left(I{D}_{CS}\parallel y\right)$ from Equations (3) or (4):

$$C_2=h\left(PI{D}_i\parallel h\left(I{D}_{CS}\parallel x\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)\oplus h\left(I{D}_{CS}\parallel x\right)\oplus h\left(I{D}_{CS}\parallel y\right)$$

$$C_3=h\left(I{D}_i\parallel PI{D}_i\parallel h\left(I{D}_{CS}\parallel x\right)\parallel h\left(I{D}_{CS}\parallel y\right)\right)\oplus PI{D}_i\oplus h\left(x\parallel y\right)$$

but the attacker only know $PI{D}_i$. Moreover, $CS$ does not include its $I{D}_{CS}$ 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 $PI{D}_i,C_2,C_3,C_4,h\left(n_U\right)$ from $S{C}_i$ [33,34] and $M_5=\left\{T_U^{new},D_1,PI{D}_i,D_2\right\}$ 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_1^{fake}=C_2\oplus I{D}_i^{fake}$ using $I{D}_i^{fake}$ but he/she cannot compute a valid $PI{D}_i$ and $C_3$ which are required to compute a valid $D_2$. 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 $M_5=\left\{T_U^{new},D_1,PI{D}_i,D_2\right\}$. However, our scheme uses random nonce $\left(n_U\right)$ and timestamp $\left(T_U\right)$ 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, $CS$ computes new session key every time the authentication is correct. This means that, $CS$ uses the new random nonce $\left(n_U^{new}\right)$, $\left(n_S^{new}\right)$ and $\left(n_{CS}^{new}\right)$, and its current timestamp $\left(T_{CS}^{new}\right)$ to compute a fresh session key, avoiding the compromise of previous session keys. If the attacker knows $M_7=\left\{D_6,D_7,D_{10},D_8,D_9,D_{11}\right\}$, he/she cannot compute a valid session key $\left(S{K}_{U-S}\right)$ without random nonce and $CS’s$ timestamp. Even though the attacker knows past session key $\left(S{K}_{U-S}^{old}\right)$, he/she cannot compute the new session key by means of any type of combination.

4.2.2. Forward Secrecy

In our scheme, $CS$ computes the session key without the use of secret keys $\left(x,y,z\right)$, avoiding compromise its security in case that an attacker knows the secret keys. Let us suppose that, an attacker knows $\left(x,y,z\right)$, 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, $S{C}_i$ verifies the legitimacy of $U_i$ by means of Equation (10). This mean that $U_i$ must be authenticated by $S{C}_i$ before it computes the user authentication request message [22].

4.3.2. 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 $\left(n_{CS}^{new}\parallel T_{CS}^{new}\right)$ which represents the fresh of the communication. Moreover, $U_i$ knows the same value, thus avoiding a man-in-the-middle attack.

4.3.3. 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$.

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

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.

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_h represents a hash function.
• T_S represents an encryption/decryption operation using AES algorithm.
• The execution time for T_h is case 1: 0.00517 ms [30] and case 2: 0.0000328 ms [32].
• The execution time for T_S is case1: 0.02148 ms [30] and case2: 0.0214385 ms [32].

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$

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. 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, $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.

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

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.

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.