Rotating behind Security: A Lightweight Authentication Protocol Based on IoT-Enabled Cloud Computing Environments

Abstract

With the rapid development of technology based on the Internet of Things (IoT), numerous IoT devices are being used on a daily basis. The rise in cloud computing plays a crucial role in solving the resource constraints of IoT devices and in promoting resource sharing, whereby users can access IoT services provided in various environments. However, this complex and open wireless network environment poses security and privacy challenges. Therefore, designing a secure authentication protocol is crucial to protecting user privacy in IoT services. In this paper, a lightweight authentication protocol was designed for IoT-enabled cloud computing environments. A real or random model, and the automatic verification tool ProVerif were used to conduct a formal security analysis. Its security was further proved through an informal analysis. Finally, through security and performance comparisons, our protocol was confirmed to be relatively secure and to display a good performance.

1. Introduction

The Internet of things (IoT) [1,2,3,4] is the “Internet connected by all things”. It is the combination of networks and various sensing devices and compose a huge network that can interconnect users and everything whenever and wherever. The emergence of IoT has driven the development of many industries, such as transportation, agriculture, medical treatment, and artificial intelligence [5,6,7]. It has since made significant advancements and can connect various devices with limited resources, and massive amounts of data can be shared through the Internet.

Cloud computing [8,9] can connect a large number of resources, such as computation, software, and storage resources, to compose a large virtually shared resource pool [10]. Its core idea is to continuously lower the processing load of user terminals by increasing the processing capacity of the “cloud”, allowing users to exploit the “cloud’s” strong computing processing capacity on demand. With cloud computing, users can access applications on any device that can connect to the Internet [11]. The progress of cloud computing technology has penetrated all aspects of people’s lives and significantly increased the level of convenience during daily life.

In real life, the resource, computing, and communication capabilities of IoT devices are limited. To address these limitations, cloud computing, as a key technology, provides an efficient platform for effectively analyzing, managing, and storing the data generated by IoT devices. Mobile devices allow users to access the cloud server resources at any time from any location. Figure 1 shows the architecture of IoT-enabled cloud computing. This architecture has three entities: control server, user, and cloud server. The cloud server provides the services requested by users conveyed through user IoT devices. The control server is a trusted organization that authorizes users and the cloud server and creates system parameters during the registration phase. In addition, when users intend to obtain the cloud server service, the control server monitors the authentication process, and with help from the control server, the three parties can consult a session key, which the user uses to obtain and enjoy the service of the cloud server.

Motivation

In IoT-enabled cloud computing environments [12,13,14,15], information is transmitted to the public channel, which is open and unprotected, and users are vulnerable to attackers when obtaining services, resulting in privacy data disclosure issues. Therefore, when users want to obtain cloud services, they must complete identity authentication and establish a key to protect the information from disclosure and tampering. At present, some scholars also use quick response (QR) codes [16] to solve these problems. Many scholars proposed authentication protocols [13,17,18,19] for this environment. However, these protocols typically have security problems, such as an inability to provide perfect forward security, suffering from man-in-the-middle (MITM) and temporary value disclosure attacks. In addition, the power of IoT devices is limited, and reducing the calculation of such devices is necessary.

In this paper, we designed a lightweight authentication protocol to solve the above problems. Both formal and informal security analyses were conducted to verify the security of our protocol. Through security and performance comparisons, our protocol demonstrated a good performance and satisfied the security requirements in IoT-enabled cloud computing environments.

The remainder of this paper is organzed as follows. Section 2 discusses related work. Section 3 presents our protocol in detail. Section 4 introduces a safety analysis. Section 5 presents some security and performance comparisons, and Section 6 presents our conclusions.

2. Related Work

This section reviews authentication and key agreement (AKA) protocols [13,17,18,19,20,21,22,23,24,25,26] applied in IoT, cloud computing, and IoT-enabled cloud computing environments. A summary of existing protocols is shown in

Table 1. A summary of authentication protocols.

Protocols	Advantages	Shortcomings
Turkanovic et al. [22]	(1) Provides user anonymity (2) Can resist offline password- guessing attacks	(1) Cannot resist insider (2) Cannot resist user impersonation attacks
Wazid et al. [23]	(1) Can resist user impersonation attacks (2) Provides user anonymity (3) Provides perfect forward security	-
Wu et al. [24]	(1) Can resist temporary value (2) Can resist offline passowrd- guessing attacks	(1) Cannot resist sensor capture attacks (2) Cannot resist denial of service attacks (3) Cannot provide perfect forward security
Tsai and Lo [25]	(1) Can resist temporary value disclosure attacks (2) Provides perfect forward security	(1) Cannot resist server impersonation attacks
Irshad et al. [26]	(1) Can resist user impersonation attacks Provides Perfect forward security	(1) Lacks user registration and revocation phases
Amin et al. [13]	(1) Can resist temporary value disclosure attacks (2) Can resist insider attacks	(1) Cannot prevent insider attacks (2) Cannot resist impersonation attacks
Martinez et al. [17]	(1) Can resist user impersonation attacks (2) Can resist offline password- guessing attacks (3) Provides user anonymity	(1) Cannot prevent impersonation attacks (2) Cannot resist session key exposure attacks (3) Cannot achieve mutual authentication
Zhou et al. [18]	(1) Provides user anonymity (2) Can achieve mutual authentication (3) Can resist insider attacks	(1) Cannot prevent replay attacks (2) Cannot prevent impersonation attacks (3) Cannot prevent temporary value disclosure attacks (4) cannot provide perfect forward security
Kang et al. [19]	(1) Can resist impersonation attacks (2) Can achieve mutual authentication	(1) Cannot resist offline password-guessing attacks

. Turkanovic et al. [22] designed an AKA scheme for IoT environments, which are dedicated to the identity authentication of users in wireless sensor networks. However, Wazid et al. [23] testified that Turkanovic et al.’s scheme [22] was unable to prevent insider and user impersonation attacks. Subsequently, Wu et al. [24] designed an AKA protocol and declared that it could prevent many common attacks. Unfortunately, Sadri et al. [27] indicated that Wu et al.’s protocol was unable to resist sensor capture and denial of service attacks (DoS) and was, thus, unable to provide perfect forward security.

Tsai and Lo [25] designed an anonymous AKA scheme for cloud computing environments. They use bilinear pairing to design the scheme, and without the assistance of a control server, users can directly obtain the services of the distributed cloud server. However, He et al. [28] proved that their scheme cannot resist server impersonation attacks. Irshad et al. [26] designed an AKA scheme using a bilinear pairing method. Unfortunately, Xiong et al. [29] verified that Irshad et al.’s [26] lacked user registration and revocation phases. Xiong et al. [29] designed an enhanced scheme and claimed that it can prevent many common attacks.

Amin et al. [13] also designed a protocol applicable to distributed cloud computing environments. However, Challa et al. [30] testified that their protocol cannot prevent insider and impersonation attacks. Martinez et al. [17] designed a lightweight AKA scheme for cloud computing environments. Unfortunately, Yu et al. [31] determined that the scheme cannot prevent impersonation and session key exposure attacks or achieve mutual authentication. Zhou et al. [18] proposed a lightweight AKA scheme. However, Wang et al. [32] proved that their protocol cannot provide perfect forward security and cannot prevent replay, impersonation, and temporary value disclosure attacks. Kang et al. [19] designed a protocol suitable for IoT-enabled cloud computing environments, which supports the authentication of IoT devices. However, Huang et al. [33] verified that it was unable to resist offline password-guessing attacks.

3. The Proposed Protocol

This section introduces our protocol. It includes three phases: (1) user registration, (2) cloud server registration, and (3) login and authentication. The following subsections describe each in detail.

Table 2. Notations.

Notations	Meanings
$S_j$	The jth cloud server
$SI{D}_j$	The $S_j$’s identity
$U_i$	The ith user
$I{D}_i$	$U_i$’s identity
$P{W}_i$	$U_i$’s password
$B_i$	$U_i$’s biological information
$HP{W}_i$	$U_i$’s pseudo password
$SC$	Smart card
$CS$	Control server
$I{D}_{CS}$	$CS$’s identity
x	The secret key of $CS$
$TI{D}_i$	$U_i$’s pseudo identity
$QI{D}_j$	$S_j$’s pseudo identity
$h(·)$	Hash function
$Gen(·),Rep(·)$	Fuzzy extraction function
${\tau }_i,{\sigma }_i$	Two parameters generated by the fuzzy extractor [34], where ${\tau }_i$ is public and ${\sigma }_i$ is private.
$T{S}_1,T{S}_2,T{S}_3,T{S}_4$	Timestamps

lists the symbols used in the protocol.

3.1. System Model

Our IoT-enabled cloud computing model includes three entities, namely user, cloud server, and control server. The information exchange between each entity is shown in Figure 2.

(1)

User: The user can use IoT devices to obtain cloud server services. We allow the user to be an untrusted entity, which means that they may be a legitimate user but may obtain services or launch attacks maliciously.

(2)

Cloud server: The cloud server provides the services requested by users conveyed through user IoT devices. It is a semi-trusted entity, in the sense that it may misbehave on its own but does not conspire with either of the participants.

(3)

Control server: The control server is responsible for registering users and cloud server, assisting users and cloud server in completing authentication and in establishing a session key in the login and authentication phase. It is a semi-trusted entity, in the sense that it may misbehave on its own but does not conspire with either of the participants.

The purpose of our protocol is to realize mutual authentication and to establish a session key between the user and cloud server with the help of the control server. Figure 2 shows the exchange of information. The specific process is referred to in Section 3.4 (Login and Authentication Phase).

3.2. User Registration Phase

At this phase, $U_i$ registers with $CS$ as a legal user. The user transmits the parameters calculated by themselves to $CS$ via a secure channel and finally obtains the smart card issued by $CS$. Figure 3 detail the process. The specific process is as follows:

(1)

$U_i$ chooses $I{D}_i$, $P{W}_i$, and $B_i$; calculates $Gen\left(B_i\right)=({\sigma }_i,{\tau }_i)$ and $HP{W}_i=h(P{W}_i\Vert {\sigma }_i)$; and then sends $\{I{D}_i,HP{W}_i\}$ to control server $CS$ through a secure channel.

(2)

$CS$ checks $U_i$’s identity. If the identity is new, $CS$ selects a random value $n_i$ and computes $TI{D}_i=h\left(I{D}_i\right)$, $A_1=h(I{D}_{CS}\Vert HP{W}_i)\oplus (n_i\oplus K_j)$, stores $\{TI{D}_i,HP{W}_i\}$ in the database, stores $\left\{A_1,I{D}_{CS}\right\}$ in smart card $SC$, and then sends $SC$ to $U_i$ through a secure channel.

(3)

After receiving message $\{A_1,I{D}_{CS}\}$ sent by $CS$, $U_i$ calculates $A_2=h(I{D}_i\Vert HP{W}_i)$ and then stores $\{A_2,Gen(·),Rep(·),{\tau }_i\}$ in $SC$.

3.3. Cloud Server Registration Phase

At this phase, cloud server $S_j$ needs to register with $CS$ as a legal entity. It sends its own parameters to $CS$ via a secure channel, obtains the parameters calculated by the $CS$, and stores them in its own memory. Figure 4 shows specific the process. The specific process is as follows:

(1)

$S_j$ selects its identity $SI{D}_j$ and random number $n_j$ and then sends $\{SI{D}_j,n_j\}$ to $CS$ through a secure channel.

(2)

$CS$ checks the identity of $S_j$. If $S_j$ is unregistered, then $CS$ selects a pseudo identity $QI{D}_j$ for $S_j$, calculates $A_3=h(SI{D}_j\Vert K_j\oplus n_j)$, and stores $\{QI{D}_j,n_j\}$ in its memory. Then, $CS$ sends $\{QI{D}_j,A_3\}$ to $S_j$ through a secure channel.

(3)

$S_j$ calculates $A_3^{*}=A_3\oplus SI{D}_j$ and stores $\{A_3^{*},QI{D}_j\}$ in its memory.

3.4. Login and Authentication Phase

At this phase, the control server $CS$ verifies the identity of the user $U_i$ and cloud server $S_j$. After verification, the three establish a common session key for future communication. The specific process is shown in the Figure 5. The specific process is as follows:

(1)

$U_i$ inputs $I{D}_i$ and $P{W}_i$; imprints $B_i$; computes $Rep(B_i,{\tau }_i)={\sigma }_i$, $HP{W}_i=h(P{W}_i\Vert {\tau }_i)$, $A_2^{\prime }=h(I{D}_i\Vert HP{W}_i)$; and checks the legitimacy of $U_i$’s identity by verifying $A_2^{\prime }\stackrel{?}{=}{A}_2$. If this is valid, $U_i$ then chooses a random value $r_i$ and timestamp $T{S}_1$ and computes $(n_i\oplus x)=A_1\oplus h(I{D}_{CS}\Vert HP{W}_i)$, $B_1=r_i\oplus h(I{D}_{CS}\Vert HP{W}_i\oplus SI{D}_j)$, $B_2=SI{D}_j\oplus h(I{D}_{CS}\Vert HP{W}_i)$, and $B_3=h(TI{D}_i\Vert I{D}_{CS}\Vert n_i\oplus x)\oplus HP{W}_i$. Subsequently, $M_1=\{TI{D}_i,A_1,B_1,B_2,B_3,T{S}_1\}$ is sent to $S_j$ through an open channel.

(2)

After receiving $U_i$’s message, $S_j$ checks timestamp $|T{S}_1-T{S}_c|\leqq \Delta T$. If the timestamp is valid, $S_j$ then selects a random number $r_j$ and timestamp $T{S}_2$. $S_j$ calculates $A_3=SI{D}_j\oplus A_3^{*}$, $B_4=r_j\oplus h(A_3\Vert SI{D}_j)$, and $B_5=h(r_j\Vert A_3\Vert SI{D}_j)$ and then sends message $M_2=\{M_1,QI{D}_j,B_4,B_5,T{S}_2\}$ to $CS$ through an open channel.

(3)

After receiving $M_2$, $CS$ checks timestamp $|T{S}_2-T{S}_c|\leqq \Delta T$. If the verification passes, $CS$ finds $HP{W}_i$ according to $TI{D}_i$; computes $SI{D}_j=B_2\oplus h(I{D}_{CS}\Vert HP{W}_i)$, $r_i=B_1\oplus h(I{D}_{CS}\Vert HP{W}_i\oplus SI{D}_j)$, and $B_3^{\prime }=h(TI{D}_i\Vert I{D}_{CS}\Vert n_i\oplus x)\oplus HP{W}_i$; and verifies $U_i$’s identity by checking $B_3^{\prime }\stackrel{?}{=}{B}_3$. If valid, $CS$ then indexes $n_j$ according to the value of $QI{D}_j$; computes $A_3=h(SI{D}_j\Vert x\oplus n_j)$, $r_j=B_4\oplus h(A_3\Vert SI{D}_j)$, and $B_5^{\prime }=h(r_j\Vert A_3\Vert SI{D}_j)$; and checks $B_5^{\prime }\stackrel{?}{=}{B}_5$. If valid, $CS$ then selects $r_k,T{S}_3$ computes $SK=h(r_i\oplus HP{W}_i\Vert r_j\Vert r_k\Vert SI{D}_j)$, $B_6=(r_i\oplus HP{W}_i)\oplus A_3$, $B_7=h(A_3\Vert r_j\Vert SI{D}_j)\oplus r_k$, $B_8=h(r_j\Vert r_k\Vert SK\Vert T{S}_3)$, $(n_i\oplus x)=A_1\oplus h(I{D}_{CS}\Vert HP{W}_i)$, $B_9=h(n_i\oplus x\Vert SI{D}_j)\oplus r_j$, and $B_{10}=h(HP{W}_i\Vert r_i)\oplus r_k$, $B_{11}=h(SK\Vert n_i\oplus x\Vert r_k\Vert r_j)$ and sends message $M_3=\{B_6,B_7,B_8,B_9,B_{10},B_{11},T{S}_3\}$ to $S_j$ through an open channel.

(4)

After receiving $M_3$, the cloud server checks the timestamp $|T{S}_3-T{S}_c|\leqq \Delta T$. If the timestamp is valid, $S_j$ then computes $(r_i\oplus HP{W}_i)=B_6\oplus A_3$, $SK=h(r_i\oplus HP{W}_i\Vert r_j\Vert r_k\Vert SI{D}_j)$, and $B_8^{\prime }=h(r_j\Vert r_k\Vert SK\Vert T{S}_3)$, and checks $B_8\stackrel{?}{=}{B}_8$. If true, $S_j$ sends message $M_4=\{B_9,B_{10},T{S}_4\}$ to $U_i$ through an open channel.

(5)

$U_i$ checks timestamp $|T{S}_4-T{S}_c|\leqq \Delta T$. If the verification passes, $U_i$ then computes $r_j=h(n_i\oplus x\Vert SI{D}_j)\oplus B_9$, $r_k=h(HP{W}_i\Vert r_i)\oplus B_{10}$, $SK=h(r_i\oplus HP{W}_i\Vert r_j\Vert r_k\Vert SI{D}_j)$, and $B_{11}^{\prime }=h(SK\Vert n_i\oplus x\Vert r_k\Vert r_j)$ and checks $B_{11}^{\prime }\stackrel{?}{=}{B}_{11}$. If the verification passes, $U_i$ then computes $B_{12}=h(SK\Vert r_j)$ and sends $M_5=\left\{B_{12}\right\}$ to $S_j$.

(6)

$S_j$ computes $B_{12}^{\prime }=h(SK\Vert r_j)$ and checks $B_{12}^{\prime }\stackrel{?}{=}{B}_{12}$. If the verification passes, then $S_j$ stores $SK$ for future communication.

4. Security Analysis

This section presents an informal security analysis and describes a formal analysis using ProVerif and the real or random (ROR) model. The subsections introduce these topics.

4.1. Attacker Model

We define the attacker’s ability based on the C-K model [35], which is an extension of the D-Y model [36]. The following features of an attacker $\mathcal{A}$ are defined:

(1)

$\mathcal{A}$ is assumed to be capable of blocking, modifying, and eavesdropping on messages transmitted on the open channel. It has complete control over communications between the various participants.

(2)

$\mathcal{A}$ can be a malicious insider on the control server and can obtain the content stored in the control server by the user or cloud server.

(3)

$\mathcal{A}$ can disclose the established session key, long-term key, and session state.

(4)

$\mathcal{A}$ can guess the user’s password or identity, but $\mathcal{A}$ is unable to guess the user’s identity or password simultaneously in polynomial time.

(5)

$\mathcal{A}$ may extract the information of a user’s $SC$ using power analysis.

4.2. Formal Security Analysis

We use the ROR model and the automated verification tool ProVerif to conduct a formal security analysis to testify that the protocol is secure and correct.

4.2.1. ROR Model

The protocol security is demonstrated using the ROR model [4,37]. The security is verified by calculating the probability of session key $SK$.

The protocol comprises three parties: user, cloud server, and control server. In this model, ${\mathsf{\Pi }}_{U_i}^x$, ${\mathsf{\Pi }}_{s_j}^y$, and ${\mathsf{\Pi }}_{CS}^z$ are the xth user, yth cloud server, and zth control server, respectively. Suppose attacker $\mathcal{A}$’s query capabilities include the following: $Z={\mathsf{\Pi }}_{U_i}^x$, ${\mathsf{\Pi }}_{S_j}^y$, and ${\mathsf{\Pi }}_{CS}^z$.

$Execute\left(Z\right)$: Assuming an attacker $\mathcal{A}$ executes the query, they can capture messages on the open channel.

$Send(Z,M)$: Assuming an attacker $\mathcal{A}$ executes the query, they transfer M to Z and receive an answer from Z.

$Hash\left(string\right)$: Suppose an attacker $\mathcal{A}$ executes the query; they enter a string and obtain a hash value.

$Corrupt\left(Z\right)$: Assuming an attacker $\mathcal{A}$ executes the query, they obtain the private value of an entity, for example, a long-term key and temporary information of the user’s $SC$.

$Test\left(Z\right)$: Assume that an attacker $\mathcal{A}$ executes the query and tosses a coin C into the air. If C equals 1, $\mathcal{A}$ obtains $SK$. Otherwise, $\mathcal{A}$ obtains a string.

Theorem 1.

If $\mathcal{A}$ executes queries $Execute\left(Z\right)$, $Send(Z,M)$, $Hash\left(string\right)$, $Corrupt\left(Z\right)$, and $Test\left(Z\right)$, the probability P of $\mathcal{A}$ cracking the protocol is $Ad{v}_{\mathcal{A}}^{\mathcal{P}}\left(\xi \right)\le q_{send}/2^{l-2}+3q_{hash}^2/2^{l-1}+2max\{c^{\prime }·q_{send}^{s^{\prime }},q_{send}/2^l\}$. Here, $q_{send}$ refers to the numbers of times the queries executed, $q_{hash}$ is the execution time of the hash function, l is the bit length of biological information [38], and $c^{\prime }$ and $s^{\prime }$ are two constants.

Proof. 

The ROR model played $G{M}_0,G{M}_1,G{M}_2,G{M}_3,G{M}_4$. $Suc{c}_A^{G{M}_i}\left(\xi \right)$ is the probability that $\mathcal{A}$ can win $G{M}_0$–$G{M}_4$. The following are the specific query steps in the game: $G{M}_0$: $G{M}_0$ represents the first round of the game, which starts by flipping C. $G{M}_0$ cannot execute any queries; hence, the probability that $\mathcal{A}$ can break P is as follows:

$$Ad{v}_{\mathcal{A}}^{\mathcal{P}}\left(\xi \right)=|2Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_0}\left(\xi \right)\right]-1|.$$

(1)

$G{M}_1$: $G{M}_1$ is for the $G{M}_0$-added $Execute\left(Z\right)$ operation, and $\mathcal{A}$ can be used only when $G{M}_1$ intercepts the messages $M_1$–$M_5$ transmitted over the open channel. Then, because the values of $HP{W}_i,r_i,r_j,r_k$ and $SI{D}_j$ cannot be obtained, $\mathcal{A}$ cannot obtain the session key through the $Test\left(Z\right)$ query. Thus, $G{M}_1$’s probability is the same as $G{M}_0$.

$$Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_1}\left(\xi \right)\right]=Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_0}\left(\xi \right)\right].$$

(2)

$G{M}_2$: $G{M}_2$ extends $G{M}_1$ by adding the $Send(Z,M)$ query. The probability of $G{M}_2$ is calculated using Zipf’s law [39].

$$|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_2}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_1}\left(\xi \right)\right]|\le q_{send}/2^l.$$

(3)

$G{M}_3$: $G{M}_3$ is for the $G{M}_2$-added $Hash\left(string\right)$ operation and deleted $Send(Z,M)$ operation. $G{M}_3$’s probability can be obtained using the birthday paradox.

$$|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_3}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_2}\left(\xi \right)\right]|\le q_{hash}^2/2^{l+1}.$$

(4)

$G{M}_4$: In $G{M}_4$, a security analysis on two events is conducted to testify the security of the session key. (1) $\mathcal{A}$ obtains $CS$’s long-term key x; (2) $\mathcal{A}$ obtains the temporary information. This demonstrates that our protocol can guarantee perfect forward security and prevent temporary information disclosure attacks.

(1)

Perfect forward security: $\mathcal{A}$ with ${\mathsf{\Pi }}_{CS}^Z$ to obtain x of $CS$ or use ${\mathsf{\Pi }}_{U_i}^x$, ${\mathsf{\Pi }}_{S_j}^y$ to obtain private values.

(2)

Temporary information disclosure attack: $\mathcal{A}$ utilizes ${\mathsf{\Pi }}_{U_i}^x$, ${\mathsf{\Pi }}_{S_j}^y$ or ${\mathsf{\Pi }}_{CS}^Z$ to obtain the random number of three entities.

For the first case, even if $\mathcal{A}$ obtains x or some private values, they cannot calculate $HP{W}_i,r_i,r_j,r_k$, or $SI{D}_j$. Therefore, $\mathcal{A}$ cannot calculate $SK$, where $SK=h(r_i\oplus HP{W}_i\Vert r_j\Vert r_k\Vert SI{D}_j)$. For the second case, even if $\mathcal{A}$ obtains $r_i$ but $HP{W}_i,r_j,r_k$ and $SI{D}_j$ are private, $SK$ is incalculable. Similarly, even if $\mathcal{A}$ can obtain $r_j$ or $r_k$, $SK$ is also incalculable. Thus, the probability of $G{M}_4$ is obtained:

$$|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_4}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_3}\left(\xi \right)\right]|\le q_{send}/2^l+q_{hash}^2/2^{l+1}.$$

(5)

$G{M}_5$: In $G{M}_5$, $\mathcal{A}$ queries the parameters $\{A_1,A_2,I{D}_{CS},Gen(·),Rep(·),{\tau }_i\}$ in the smart card by executing $Corrupt\left(Z\right)$. This proves that our protocol can protect against offline password-guessing attacks. $\mathcal{A}$ attempts to guess $A_2=h(I{D}_i\Vert HP{W}_i)$, where $HP{W}_i=h(P{W}_i\Vert {\tau }_i)$. However, $I{D}_i$ and $HP{W}_i$ are private. The probability that $\mathcal{A}$ can guesses l bit of biological information is $1/2^l$. From Zipf’s law [39], when $q_{send}\le 106$, the probability that $\mathcal{A}$ can guess the password is more than $1/2$. Thus, the probability of $G{M}_5$ can be obtained:

$$|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_5}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_4}\left(\xi \right)\right]|\le max\{C^{\prime }·q_{send}^{s^{\prime }},q_{send}/2^l\}$$

(6)

$G{M}_6$: $G{M}_6$ confirms that the protocol can prevent impersonation attacks. $\mathcal{A}$ queries $h(r_i\oplus HP{W}_i\Vert r_j\Vert r_k\Vert SI{D}_j)$, and the game ends. Therefore, the probability of $G{M}_6$ can be obtained:

$$|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_6}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_5}\left(\xi \right)\right]|\le q_{hash}^2/2^{l+1}.$$

(7)

Because $\mathcal{A}$’s probability of success is the same as that of failure (i.e., (1)–(2)), $\mathcal{A}$’s probability of obtaining the session key is

$$Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_6}\left(\xi \right)\right]=1/2.$$

(8)

From all these formulas,

$$\begin{array}{cc}\hfill 1/2Ad{v}_{\mathcal{A}}^{\mathcal{P}}\left(\xi \right)& =\left|Pr\right[Suc{c}_{\mathcal{A}}^{G{M}_0}\left(\xi \right)]-1/2|\hfill \\ \hfill & =|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_0}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_6}\left(\xi \right)\right]|\hfill \\ \hfill & =|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_1}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_6}\left(\xi \right)\right]|\hfill \\ \hfill & \le \sum _{i=0}^5|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_{i+1}}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_i}\left(\xi \right)\right]|\hfill \\ \hfill & =q_{send}/2^{l-1}+3q_{hash}^2/2^l+max\{c^{\prime }·q_{send}^{s^{\prime }},q_{send}/2^l\}\hfill \end{array}$$

(9)

Consequently, we obtain

$$Ad{v}_{\mathcal{A}}^{\mathcal{P}}\left(\xi \right)\le q_{send}/2^{l-2}+3q_{hash}^2/2^{l-1}+2max\{c^{\prime }·q_{send}^{s^{\prime }},q_{send}/2^l\}.$$

(10)

 □

4.2.2. ProVerif

ProVerif [40,41] is a powerful and appropriate tool for analyzing and verifying protocol security. We use it to verify our protocol’s security.

(1)

Some functions and queries are also defined, as shown in Figure 6a,b.

(2)

Figure 6c shows the defined events and queries. Among them, we define eight queries. The first three queries prove the session key’s security, while the other five queries prove the protocol’s correctness. In addition, we also defined eight events. Event UserStarted() indicates that $U_i$ begins authentication, event UserAuthed() indicates that $U_i$ successfully authenticated, event ControlServerAcUser() represents $CS$ authenticating $U_i$ successfully, event ControlServerAcCloudServer() represents $CS$ authenticating $S_j$ successfully, event CloudServerAcControlServer() indicates that $S_j$ successfully authenticates $CS$, event UserAcControlServer() represents $U_i$ authenticating $CS$ successfully, event UserAcCloudServer() represents $U_i$ authenticating $S_j$ successfully, and event CloudServerAcUser() represents $CS$ authenticating $U_i$ successfully.

(3)

Figure 7a–c shows $U_i$’s, $S_j$’s, and $CS$’s processes, respectively. Finally, Figure 8 presents the results. The first three results demonstrate that attackers cannot obtain $SK$, and the last five outcomes demonstrate that the protocol is correct and reasonable. Therefore, our protocol can successfully pass the verification of ProVerif and prevent common attacks.

4.3. Informal Security Analysis

In this subsection, an informal analysis is adopted to demonstrate the common security requirements of the proposed protocol.

4.3.1. Man-in-the-Middle Attacks

$\mathcal{A}$ computes $SK$ by intercepting messages on the open channel. Let us suppose that message $M_1$ is intercepted and $\mathcal{A}$ attempts to calculate $SK=h(r_i\oplus HP{W}_i\Vert r_j\Vert r_k\Vert SI{D}_j)$ but they cannot obtain the values of $I{D}_{CS},HP{W}_i,SI{D}_j$. Therefore, $\mathcal{A}$ cannot use the message $\{B_1,B_2,B_4,B_7\}$ on the open channel to calculate $r_i,r_j,r_k,B_3,B_5$; change any values; or successfully pass the authentication of $CS$; thus, they cannot successfully calculate $SK$. Consequently, the proposed protocol can guard against MITM attacks.

4.3.2. Insider Attacks

Case one: Assume that a malicious attacker $\mathcal{A}$ obtains $\{QI{D}_j,n_j,TI{D}_i,HP{W}_i\}$ stored in the $CS$ database. They use the message on the open channel to compute $r_i=B_1\oplus h(I{D}_{CS}\Vert HP{W}_i\oplus SI{D}_j)$. However, $\mathcal{A}$ cannot obtain the values of $I{D}_{CS},SI{D}_j$, and thus, $r_i$ cannot be calculated. Similarly, because $\mathcal{A}$ cannot obtain the values of $A_3,SI{D}_j$, $\mathcal{A}$ cannot calculate $r_j=B_4\oplus h(A_3\Vert SI{D}_j)$ and $r_k=h(HP{W}_i\Vert r_i)\oplus B_{10}$. Therefore, the session key cannot be computed using $\mathcal{A}$. Therefore, our protocol can prevent insider attacks.

Case two: Assume that the attacker $\mathcal{A}$ is an insider of the cloud server and obtains the information $A_3^{*},QI{D}_j$ stored in it. They then try to intercept the information on the open channel and to calculate the session key $SK=h(r_i\oplus HP{W}_i\Vert r_j\Vert r_k\Vert SI{D}_j)$. They intercepted $B_4$ and tried to calculate $r_j=B_4\oplus h(A_3\Vert SI{D}_j)$ but cannot calculate the value of $A_3$ and thus cannot obtain the value of $r_j$. Similarly, $\mathcal{A}$ attempts to intercept $B_6$ and $B_7$ to calculate $(r_i\oplus HP{W}_i)=B_6\oplus A_3$, and $r_k=h(A_3\Vert r_j\Vert SI{D}_j)\oplus B_7$. However, they cannot obtain the value of $A_3$ and thus cannot calculate $(r_i\oplus HP{W}_i)$ and $r_k$, so they cannot successfully calculate $SK$.

By analyzing these two situations, we can prove that our protocol can resist insider attacks.

4.3.3. DDoS Attacks

During the login and authentication phase, $U_i$ sends service request message $M_1=\{TI{D}_i,A_1,B_1,B_2,B_3,T{S}_1\}$ to $S_j$. After $S_j$ receives $M_1$, whether the timestamp is valid is checked first. If the timestamp is valid, $S_j$ performs the following calculation. Therefore, if attacker $\mathcal{A}$ wants to launch DDoS attacks, it must be within a valid time, and it is not possible in this protocol to deny a service only by sending a huge service request. Therefore, the protocol is immune to this attack.

4.3.4. Masquerading Attacks

Case one: Attacker $\mathcal{A}$ attempts to impersonate any legitimate user, cloud server, or control server. Suppose that $\mathcal{A}$ obtains the information $\{QI{D}_j,n_j,TI{D}_i,HP{W}_i\}$ stored in $CS$ and intercepts the messages $\{M_1,M_2,M_3,M_4\}$ on the public channel. $\mathcal{A}$ wants to impersonate a legitimate $U_i$ by calculating $B_3=h(TI{D}_i\Vert I{D}_{CS}\Vert n_i\oplus x)\oplus HP{W}_i$, but $\mathcal{A}$ cannot obtain values of $I{D}_{CS}$ and $(n_i\oplus x)$. Therefore, they cannot successfully calculate the value of $B_3$ and cannot impersonate a legitimate user by changing $B_3$ to pass the verification of $CS$ and thus cannot pretend to be a legitimate user.

Case two: Similarly, $\mathcal{A}$ wants to impersonate a $S_j$ through $B_5=h(r_j\Vert A_3\Vert SI{D}_j)$ but cannot obtain values of $r_j,A_3$ and $SI{D}_j$, so they cannot pass the verification of $CS$. Therefore, $\mathcal{A}$ cannot successfully impersonate a legal $S_j$. It can be concluded that the proposed protocol can resist impersonation attacks.

To sum up, our protocol can resist masquerading attacks.

4.3.5. Identity Theft Attacks

Suppose that an attacker $\mathcal{A}$ obtains the user’s smart card and tries to impersonate a legitimate user to establish a session with the cloud server and the control server. They obtain $\{A_1,A_2,I{D}_{CS},Gen(·),Rep(·),{\tau }_i\}$ and try to calculate the authentication value $B_3=h(TI{D}_i\Vert I{D}_{CS}\Vert n_i\oplus x)\oplus HP{W}_i$ by intercepting the information on the open channel. Because they cannot obtain $P{W}_i,{\tau }_i$, they cannot calculate $HP{W}_i=h(P{W}_i\Vert {\tau }_i)$ and thus cannot successfully calculate $B_3$ and pass the authentication of $CS$. Therefore, our protocol can resist identity theft attacks.

4.3.6. Replay Attacks

According to our defined attacker model, an attacker $\mathcal{A}$ can forward the intercepted message to the receiver on the open channel and prove that they are a legitimate entity if the receiver authenticates the message. However, each transmitted message has a timestamp. If $\mathcal{A}$ transmits a previously intercepted message, the recipient rejects the request because of the invalid timestamp. Thus, the protocol is resistant to replay attacks.

4.3.7. Perfect Forward Secrecy

In our protocol, $SK=h(r_i\oplus HP{W}_i\Vert r_j\Vert r_k\Vert SI{D}_j)$. Case one: Suppose that an attacker $\mathcal{A}$ can obtain x but $SI{D}_j$ and $HP{W}_i$ cannot be computed and $\mathcal{A}$ cannot obtain random numbers $r_i$, $r_j$, and $r_k$. Therefore, there is no way to calculate the current $SK$ or the previous $SK$, so the proposed protocol can provide perfect forward security.

Case two: Assume that an attacker A obtains the user’s password $P{W}_i$ to attack. Because the user’s biological information $B_i$ cannot be obtained, $\mathcal{A}$ cannot compute $HP{W}_i$, where $HP{W}_i=h(P{W}_i\Vert {\tau }_i)$. Additionally, $\{r_i,r_j,r_k,SI{D}_j\}$ is unknown. $\mathcal{A}$ cannot successfully compute $SK$.

Case three: Assume that an attacker $\mathcal{A}$ can obtain the private value $A_3^{*}$ of a cloud server for an attack. Because the identity $SI{D}_j$ of the $S_j$ cannot be obtained, $\mathcal{A}$ cannot calculate $A_3$, where $A_3=h(SI{D}_j\Vert x\oplus n_j)$. Furthermore, $\mathcal{A}$ cannot calculate $r_j$ and $r_k$; here, $r_i=B_1\oplus h(I{D}_{CS}\Vert HP{W}_i\oplus SI{D}_j)$ and $r_k=h(A_3\Vert r_j\Vert SI{D}_j)\oplus B_7$. Additionally, $HP{W}_i$ is unknown, and $\mathcal{A}$ cannot successfully calculate $SK$.

Therefore, the proposed protocol can provide perfect forward security.

4.3.8. Session Key Disclosure Attacks

It is assumed that the attacker $\mathcal{A}$ attempts to intercept the transmission of information on the open channel. Even if the attacker intercepts the messages $M_1-M_5$, they cannot compute $r_j=B_4\oplus h(A_3\Vert SI{D}_j)$, $r_k=h(A_3\Vert r_j\Vert SI{D}_j)\oplus B_7$, and $(r_i\oplus HP{W}_i)=B_6\oplus A_3$ because they cannot obtain the values of $HP{W}_i,SI{D}_j,A_3$. Obviously, they cannot compute the session key $SK=h(r_i\oplus HP{W}_i\Vert r_j\Vert r_k\Vert SI{D}_j)$ by intercepting the information on the public channel. Therefore, our proposed protocol can resist session key disclosure attacks.

4.3.9. Mutual Authentication

In the login and authentication phase, $CS$ verifies the user and cloud server through $B_3$ and $B_5$, respectively, and $B_8$ and $B_{11}$ are the values of $U_i$ and $S_j$ used to verify mutual identity, respectively. Although $B_3$ and $B_5$ are transmitted over the open channel, the values of $(n_i\oplus x)$, $HP{W}_i$, $r_j$, and $A_3$ cannot be obtained by an attacker $\mathcal{A}$. Similarly, $B_8$ and $B_{11}$ are also transmitted over the open channel, but $\mathcal{A}$ cannot obtain the values of $r_k$ and $SK$, and thus, the protocol cannot break by changing the authentication value. Hence, our protocol can provide mutual authentication.

4.3.10. Privacy and Anonymity

An attacker $\mathcal{A}$ attempts to identify a user by intercepting messages on the open channel. However, in our proposed method, $\mathcal{A}$ can only obtain $U_i$’s pseudo identity $TI{D}_i$. Thus, $\mathcal{A}$ cannot compute the user’s real $I{D}_i$. Similarly, $\mathcal{A}$ can only obtain the $S_j$’s pseudo identity $QI{D}_j$. $\mathcal{A}$ cannot determine the true identity of $U_i$ and $S_j$ based on the pseudo identity, which protects the privacy of $U_i$ and $S_j$. Therefore, our protocol can provide privacy and anonymity.

4.3.11. Traceability and Non-Repudiation

When cloud server finds that $U_i$ has bad behavior, it will report to $CS$, and $CS$ will find the value of the user’s $HP{W}_i$ according to $TI{D}_i$, which can be used to identify $U_i$. Therefore, once a user exhibits malicious behavior, $CS$ can track the user, which ensures traceability. Since the transmitted message $M_1=\left\{TI{D}_i,A_1,B_1,B_2,B_3,T{S}_1\right\}$ contains the value of authenticating the user’s identity $B_3$, once a legitimate user exhibits bad behavior, $CS$ will verify the user’s identity according to $B_3=h(TI{D}_i\Vert I{D}_{CS}\Vert n_i\oplus x)\oplus HP{W}_i$. If the verification is passed, this indicates that the bad behavior is indeed sent by the user, and the user cannot deny it. Therefore, non-repudiation is guaranteed.

4.3.12. Integrity

Integrity is the guarantee that an attacker $\mathcal{A}$ cannot change the transmitted information. Even if $\mathcal{A}$ is able to successfully tamper with the information, the system will detect and discover that the information has been modified.

It is assumed that an attacker $\mathcal{A}$ can intercept and tamper with the messages $\{M_1,M_2$, $M_3,M_4\}$ transmitted on the open channel. For example, $\mathcal{A}$ intercepts and tampers with message $M_1$, where $M_1=\left\{TI{D}_i,A_1,B_1,B_2,B_3,T{S}_1\right\}$. If $\mathcal{A}$ tampers with $TI{D}_i$, $CS$ cannot retrieve $HP{W}_i$ and the authentication is suspended. If $\mathcal{A}$ tampers with $A_1,B_1,B_2,B_3$, then $CS$ calculates that $B_3^{\prime }$ is not equal to the received $B_3=h(TI{D}_i\Vert I{D}_{CS}\Vert n_i\oplus x)\oplus HP{W}_i$, which indicates that the user is not legal or $M_1$ is tampered with, and the authentication is suspended. Similarly, if an attacker intercepts and tampers with $\{M_2,M_3,M_4\}$, all three entities will be checked accordingly. Therefore, the proposed protocol can ensure the integrity of information.

4.3.13. Confidentiality

From the Section 4.3.2 (Insider Attacks) and Section 4.3.4 (Masquerading Attacks), it can be seen that the attacker cannot obtain $SK=h(r_i\oplus HP{W}_i\Vert r_j\Vert r_k\Vert SI{D}_j)$. Therefore, it can be seen that our protocol ensures confidentiality.

5. Security and Performance Comparison

We compared the protocols of Amin et al. [13], Martinez et al. [17], Zhou et al. [18], and Kang et al. [19] in terms of performance and security. The specific comparison results are described in the following subsection.

5.1. Security Comparison

This subsection compares the five protocols in terms of security. Specifically, indicates that the security characteristics are met, and × indicates that they are not met. In addition, S1–S8 are defined as follows: S1: Perfect forward secrecy; S2: Man-in-the-middle attack; S3: Mutual authentication; S4: Impersonation attack; S5: Replay attack; S6: Temporary value disclosure attack; S7: Offline password-guessing attack; and S8: Insider attack.

Table 3. Comparisons of security.

Security Properties	[13]	[17]	[18]	[19]	Ours
S1	✓	✓	×	✓	✓
S2	×	✓	✓	✓	✓
S3	✓	×	✓	✓	✓
S4	×	×	×	✓	✓
S5	✓	×	×	✓	✓
S6	✓	✓	×	✓	✓
S7	✓	✓	✓	×	✓
S8	×	✓	✓	✓	✓

lists the security results. From Table 3, Zhou et al.’s [18] scheme was unable to provide perfect forward security and cannot prevent replay, user and server impersonation, and temporary value disclosure attacks. The protocol of Kang et al. [19] cannot resist offline password-guessing attacks; Amin et al.’s [13] protocol cannot prevent insider or impersonation attacks; and the protocol of Martinez et al. [17] was unable to prevent impersonation or replay attacks, or even enable mutual authentication. The proposed protocol can evidently prevent many common attacks.

5.2. Performance Comparison

We calculated the time required by the user and server. To estimate the user’s computing cost, we developed an app that uses the Java pairing library, signature library, and symmetric encryption/decryption function to calculate the running time of various operations. We used smart phones produced by different manufacturers to imitate the user. We ran various operations on the following mobile phones ten times and used the average value as the reference time.

Table 4. The computational costs of complex operations.

Operations	Symbolic	D1 (ms)	D2 (ms)	D3 (ms)	Server (Cloud, Contorl)
Symmetric Decryption	$T_{de}$	0.04125	0.2	0.2	0.1347
Symmetric Encryption	$T_{en}$	0.2	0.0392	0.0591	4.7
Hash function	$T_h$	0.00103	0.00251	0.00102	0.0052
Fuzzy function	$T_f$	0.05665	0.143	0.00561	-

lists the results of various operations on different mobile phones. D1 is a Huawei Mate 30 mobile phone with a harmony operating system, Huawei Kirin 990 processor, and 8G running memory; D2 is a Redmi Note 9 Pro mobile phone with an Android operating system, Qualcomm Snapdragon 750 g CPU, and 8G of RAM; and D3 represents a Oneplus phone with an Android operating system, Snapdragon 865 processor, and 8G running memory.

Table 5. Comparative results of user computational costs.

Protocols	User	D1 (ms)	D2 (ms)	D3 (ms)
Amin et al. [13]	$9T_h$	0.0093	0.0226	0.0092
Martinez et al. [17]	$11T_h+T_{de}$	0.0526	0.2275	0.2112
Zhou et al. [18]	$10T_h$	0.0103	0.0251	0.0102
Kang et al. [19]	$8T_h$	0.0082	0.0201	0.0082
Ours	$T_f+10T_h$	0.0697	0.1681	0.0158

and Figure 9 present the comparative results of the client calculation costs of the five protocols. Table 5 shows that the protocol of Amin et al. [13] requires $9T_h$, the protocol of Martinez et al. [17] requires $11T_h+T_{de}$, Zhou et al.’s [18] protocol requires $10T_h$, Kang et al.’s protocol [19] requires $8T_h$, and our proposed protocol requires $T_m+10T_h$. Although we are not as good as Amin et al. [13], Zhou et al. [18], and Kang et al. [19] in terms of performance, we are better than them in terms of security.

We used a computer with a windows 10 operating system, Intel (R) core (TM) [email protected] processor, and 8 GB memory, to simulate the server’s computational costs. IntelliJ idea software version 2019.3 was used for development. It is based on the Java pairing library, signature library, and symmetric encryption/decryption function. Various operations were run 10 times on this computer, and the average value was used as the reference time. Table 4 lists the results.

Table 6. Comparative results of server computational costs.

Protocols	Cloud Server	Control Server	Total (ms)
Amin et al. [13]	$4T_h$	$10T_h$	0.0728
Martinez et al. [17]	$6T_h+2T_{de}+T_{en}$	$34T_h+2T_{en}$	14.5774
Zhou et al. [18]	$7T_h$	$20T_h$	0.1404
Kang et al. [19]	$3T_h$	$11T_h$	0.0728
Ours	$5T_h$	$13T_h$	0.0936

shows the comparison results. As shown in Table 6, the time required for our proposed protocol was only four hashes more than Kang et al.’s [19] and Amin et al.’s [13] protocols, that is, 0.0208 ms.

To calculate the communication cost, we set the length of one-way hash H as 256 bits, timestamp T to 32 bits, string s to 160 bits, identity $ID$ to 160 bits, random number $Z_p^{*}$ to 160 bits, and encryption operation E to 256 bits. In addition, assume that the fuzzy extractor needs to store 8 bits. From this definition, the protocol of Zhou et al. [18] can be concluded to require $3\left|ID\right|+10\left|s\right|+6\left|H\right|+3\left|T\right|$, that of Amin et al. [13] requires $3\left|ID\right|+8\left|s\right|+6\left|H\right|+3\left|T\right|$, that of Martinez et al. [17] requires $3\left|ID\right|+18\left|s\right|+\left|H\right|+2\left|E\right|+2|Z_p^{*}|$, that of Kang et al. [19] requires $3\left|ID\right|+10\left|s\right|+6\left|H\right|+3\left|T\right|$, and our protocol requires $3\left|ID\right|+15\left|s\right|+5\left|H\right|+3\left|T\right|$.

Table 7. Comparisons in terms of communication and storage costs.

Protocols	Number of Rounds	Communication Costs (Bits)	Storage Costs (Bits)	Security
Amin et al. [13]	5	3680	1152	Insecure
Martinez et al. [17]	6	6016	1664	Insecure
Zhou et al. [18]	4	4448	2112	Insecure
Kang et al. [19]	2	4000	1278	Cannot resist offline password guessing attack
Ours	5	4544	1320	Provable secruity

and Figure 10 present the detailed comparison results. Evidently, our protocol has a lower communication cost than that of Martinez et al. [17], although the communication cost is higher than that of the other three protocols. Our protocol also provides higher security; their protocols have been proven to have various security problems. Therefore, our proposed protocol is secure, has a relatively good performance, and is suitable for cloud computing environments.

For the storage costs, we consider the parameters required to store each entity in each entity in the registration phase. The number of numbers required for various parameters is the same as discussed above. The comparison results are shown in Figure 11. It can be seen from the figure that our storage cost is slightly higher than the protocols of Amin et al. [13] and Kang et al. [19].

In terms of energy costs, due to the strong computing power and good performance of the server, we do not consider its energy cost. We use “ampere” APP to measure the current and voltage of each mobile phone the three devices during operation, and the results are shown in the

Table 8. Voltage and current of devices.

Devices	U (V)	I (mA)
D1	4.08	531
D2	610	3.58
D3	508	4.08

. According to the formula $W=U·I·t$, the power consumption required by each device was calculated. The results are shown in

Table 9. Energy costs.

Protocols	D1 (uJ)	D2 (uJ)	D3 (uJ)
Amin et al. [13]	20.148	49.354	19.068
Martinez et al. [17]	113.957	496.814	437.74
Zhou et al. [18]	22.315	54.813	21.14
Kang et al. [19]	17.751	43.894	16.996
Ours	151.004	367.097	32.748

and Figure 12. The energy costs are different for different devices. It can be seen from the figure that, although our protocol is not the best, it is better than that of Martinez et al. [17] and our protocol is secure.

6. Conclusions and Disscussion

IoT-enabled cloud computing environment is an open environment, and its main threat is data leakage. Because a large number of customers’ privacy data are stored on the cloud server, once the data is leaked, it will lead to not only the disclosure of trade secrets, intellectual property rights, and personal privacy but also a devastating blow to the enterprise. In addition, the communication information of various entities is transmitted on the open channel. Attackers can launch attacks by intercepting the information on the open channel. Moreover, from Table 1, we can know that most of the existing schemes have been attacked, such as man in the middle attack, simulation attack, etc.

In this paper, we propose a protocol to solve the security problem in this environment. To verify the security, an informal security analysis was conducted, and the ProVerif and ROR models were adopted for formal security analysis. Finally, the protocol’s security and performance were measured against those of other protocols. The proposed protocol can be concluded to satisfy basic security requirements. Therefore, our protocol is more suitable for this environment.