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

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.


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.

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. 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. Table 1. A summary of authentication protocols.

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

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 lists the symbols used in the protocol.

S j
The jth cloud server SID j The S j 's identity U i The ith user The secret key of CS TID i U i 's pseudo identity QID j S j 's pseudo identity h(·) Hash function Gen(·), Rep(·) Fuzzy extraction function τ i , σ i Two parameters generated by the fuzzy extractor [34], where τ i is public and σ i is private. TS 1 , TS 2 , TS 3 , TS 4 Timestamps

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

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 ID i , PW i , and B i ; calculates Gen(B i ) = (σ i , τ i ) and HPW i = h(PW i σ i ); and then sends {ID i , HPW 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 TID i = h(ID i ), A 1 = h(ID CS HPW i ) ⊕ (n i ⊕ K j ), stores {TID i , HPW i } in the database, stores {A 1 , ID CS } in smart card SC, and then sends SC to U i through a secure channel. (3) After receiving message {A 1 , ID CS } sent by CS, U i calculates A 2 = h(ID i HPW i ) and then stores {A 2 , Gen(·), Rep(·), τ i } in SC.

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 SID j and random number n j and then sends {SID 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 QID j for S j , calculates A 3 = h(SID j K j ⊕ n j ), and stores {QID j , n j } in its memory. Then, CS sends {QID j , A 3 } to S j through a secure channel.

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: ; and checks the legitimacy of U i 's identity by verifying If this is valid, U i then chooses a random value r i and timestamp TS 1 and (2) After receiving U i 's message, S j checks timestamp |TS 1 − TS c | ∆T. If the timestamp is valid, S j then selects a random number r j and timestamp TS 2 . S j calcu- , and B 11 = h(SK n i ⊕ x r k r j ) and checks B 11 ? = B 11 . If the verification passes, U i then computes B 12 = h(SK r j ) and sends M 5 = {B 12 } to S j .
(6) S j computes B 12 = h(SK r j ) and checks B 12 ? = B 12 . If the verification passes, then S j stores SK for future communication.

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.

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 A are defined: (1) 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) 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) A can disclose the established session key, long-term key, and session state. (4) A can guess the user's password or identity, but A is unable to guess the user's identity or password simultaneously in polynomial time. (5) A may extract the information of a user's SC using power analysis.

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.

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, Π x U i , Π y s j , and Π z CS are the xth user, yth cloud server, and zth control server, respectively. Suppose attacker A's query capabilities include the following: and Π z CS . Execute(Z): Assuming an attacker A executes the query, they can capture messages on the open channel.
Send(Z, M): Assuming an attacker A executes the query, they transfer M to Z and receive an answer from Z.
Hash(string): Suppose an attacker A executes the query; they enter a string and obtain a hash value.
Corrupt(Z): Assuming an attacker 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(Z): Assume that an attacker A executes the query and tosses a coin C into the air. If C equals 1, A obtains SK. Otherwise, A obtains a string. Theorem 1. If A executes queries Execute(Z), Send(Z, M), Hash(string), Corrupt(Z), and Test(Z), the probability P of A cracking the protocol is Adv P 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 and s are two constants.
The following are the specific query steps in the game: GM 0 : GM 0 represents the first round of the game, which starts by flipping C. GM 0 cannot execute any queries; hence, the probability that A can break P is as follows: GM 1 : GM 1 is for the GM 0 -added Execute(Z) operation, and A can be used only when GM 1 intercepts the messages M 1 -M 5 transmitted over the open channel. Then, because the values of HPW i , r i , r j , r k and SID j cannot be obtained, A cannot obtain the session key through the Test(Z) query. Thus, GM 1 's probability is the same as GM 0 .
GM 2 : GM 2 extends GM 1 by adding the Send(Z, M) query. The probability of GM 2 is calculated using Zipf's law [39].
GM 3 : GM 3 is for the GM 2 -added Hash(string) operation and deleted Send(Z, M) operation. GM 3 's probability can be obtained using the birthday paradox.
GM 4 : In GM 4 , a security analysis on two events is conducted to testify the security of the session key. (1) A obtains CS's long-term key x; (2) 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: A with Π Z CS to obtain x of CS or use Π x U i , Π y S j to obtain private values.
(2) Temporary information disclosure attack: A utilizes Π x U i , Π y S j or Π Z CS to obtain the random number of three entities.
For the first case, even if A obtains x or some private values, they cannot calculate HPW i , r i , r j , r k , or SID j . Therefore, A cannot calculate SK, where SK = h(r i ⊕ HPW i r j r k SID j ). For the second case, even if A obtains r i but HPW i , r j , r k and SID j are private, SK is incalculable. Similarly, even if A can obtain r j or r k , SK is also incalculable. Thus, the probability of GM 4 is obtained: GM 5 : In GM 5 , A queries the parameters {A 1 , A 2 , ID CS , Gen(·), Rep(·), τ i } in the smart card by executing Corrupt(Z). This proves that our protocol can protect against offline password-guessing attacks. A attempts to guess A 2 = h(ID i HPW i ), where HPW i = h(PW i τ i ). However, ID i and HPW i are private. The probability that A can guesses l bit of biological information is 1/2 l . From Zipf's law [39], when q send ≤ 106, the probability that A can guess the password is more than 1/2. Thus, the probability of GM 5 can be obtained: GM 6 : GM 6 confirms that the protocol can prevent impersonation attacks. A queries h(r i ⊕ HPW i r j r k SID j ), and the game ends. Therefore, the probability of GM 6 can be obtained: Because A's probability of success is the same as that of failure (i.e., (1)- (2)), A's probability of obtaining the session key is From all these formulas, Consequently, we obtain

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.

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

Man-in-the-Middle Attacks
A computes SK by intercepting messages on the open channel. Let us suppose that message M 1 is intercepted and A attempts to calculate SK = h(r i ⊕ HPW i r j r k SID j ) but they cannot obtain the values of ID CS , HPW i , SID j . Therefore, 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.

Insider Attacks
Case one: Assume that a malicious attacker A obtains {QID j , n j , TID i , HPW i } stored in the CS database. They use the message on the open channel to compute r i = B 1 ⊕ h(ID CS HPW i ⊕ SID j ). However, A cannot obtain the values of ID CS , SID j , and thus, r i cannot be calculated. Similarly, because A cannot obtain the values of A 3 , SID j , A cannot calculate r j = B 4 ⊕ h(A 3 SID j ) and r k = h(HPW i r i ) ⊕ B 10 . Therefore, the session key cannot be computed using A. Therefore, our protocol can prevent insider attacks.
Case two: Assume that the attacker A is an insider of the cloud server and obtains the information A * 3 , QID 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 ⊕ HPW i r j r k SID j ). They intercepted B 4 and tried to calculate r j = B 4 ⊕ h(A 3 SID j ) but cannot calculate the value of A 3 and thus cannot obtain the value of r j . Similarly, A attempts to intercept B 6 and B 7 to calculate (r i ⊕ HPW i ) = B 6 ⊕ A 3 , and r k = h(A 3 r j SID j ) ⊕ B 7 . However, they cannot obtain the value of A 3 and thus cannot calculate (r i ⊕ HPW 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.

DDoS Attacks
During the login and authentication phase, U i sends service request message 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 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.

Masquerading Attacks
Case one: Attacker A attempts to impersonate any legitimate user, cloud server, or control server. Suppose that A obtains the information {QID j , n j , TID i , HPW i } stored in CS and intercepts the messages {M 1 , M 2 , M 3 , M 4 } on the public channel. A wants to impersonate a legitimate U i by calculating B 3 = h(TID i ID CS n i ⊕ x) ⊕ HPW i , but A cannot obtain values of ID CS and (n i ⊕ 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, A wants to impersonate a S j through B 5 = h(r j A 3 SID j ) but cannot obtain values of r j , A 3 and SID j , so they cannot pass the verification of CS. Therefore, 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.

Identity Theft Attacks
Suppose that an attacker 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 , ID CS , Gen(·), Rep(·), τ i } and try to calculate the authentication value B 3 = h(TID i ID CS n i ⊕ x) ⊕ HPW i by intercepting the information on the open channel. Because they cannot obtain PW i , τ i , they cannot calculate HPW i = h(PW i τ i ) and thus cannot successfully calculate B 3 and pass the authentication of CS. Therefore, our protocol can resist identity theft attacks.

Replay Attacks
According to our defined attacker model, an attacker 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 A transmits a previously intercepted message, the recipient rejects the request because of the invalid timestamp. Thus, the protocol is resistant to replay attacks.

Perfect Forward Secrecy
In our protocol, SK = h(r i ⊕ HPW i r j r k SID j ). Case one: Suppose that an attacker A can obtain x but SID j and HPW i cannot be computed and 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 PW i to attack. Because the user's biological information B i cannot be obtained, A cannot compute HPW i , where HPW i = h(PW i τ i ). Additionally, {r i , r j , r k , SID j } is unknown. A cannot successfully compute SK.
Case three: Assume that an attacker A can obtain the private value A * 3 of a cloud server for an attack. Because the identity SID j of the S j cannot be obtained, A cannot calculate A 3 , where A 3 = h(SID j x ⊕ n j ). Furthermore, A cannot calculate r j and r k ; here, r i = B 1 ⊕ h(ID CS HPW i ⊕ SID j ) and r k = h(A 3 r j SID j ) ⊕ B 7 . Additionally, HPW i is unknown, and A cannot successfully calculate SK.
Therefore, the proposed protocol can provide perfect forward security.

Session Key Disclosure Attacks
It is assumed that the attacker 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 ⊕ h(A 3 SID j ), r k = h(A 3 r j SID j ) ⊕ B 7 , and (r i ⊕ HPW i ) = B 6 ⊕ A 3 because they cannot obtain the values of HPW i , SID j , A 3 . Obviously, they cannot compute the session key SK = h(r i ⊕ HPW i r j r k SID j ) by intercepting the information on the public channel. Therefore, our proposed protocol can resist session key disclosure attacks.

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 ⊕ x), HPW i , r j , and A 3 cannot be obtained by an attacker A. Similarly, B 8 and B 11 are also transmitted over the open channel, but 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.

Privacy and Anonymity
An attacker A attempts to identify a user by intercepting messages on the open channel. However, in our proposed method, A can only obtain U i 's pseudo identity TID i . Thus, A cannot compute the user's real ID i . Similarly, A can only obtain the S j 's pseudo identity QID j . 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.

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 HPW i according to TID 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 = {TID i , A 1 , B 1 , B 2 , B 3 , TS 1 } 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(TID i ID CS n i ⊕ x) ⊕ HPW 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.

Integrity
Integrity is the guarantee that an attacker A cannot change the transmitted information. Even if 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 A can intercept and tamper with the messages {M 1 , M 2 , M 3 , M 4 } transmitted on the open channel. For example, A intercepts and tampers with message M 1 , where M 1 = {TID i , A 1 , B 1 , B 2 , B 3 , TS 1 }. If A tampers with TID i , CS cannot retrieve HPW i and the authentication is suspended. If A tampers with A 1 , B 1 , B 2 , B 3 , then CS calculates that B 3 is not equal to the received B 3 = h(TID i ID CS n i ⊕ x) ⊕ HPW 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.

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 ⊕ HPW i r j r k SID j ). Therefore, it can be seen that our protocol ensures confidentiality.

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.

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

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 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 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.  Figure 9. Comparative results of user computational costs [13,[17][18][19].
We used a computer with a windows 10 operating system, Intel (R) core (TM) i5-8500CPU@ 3.00GHz3.00G 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 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. 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 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|ID| + 10|s| + 6|H| + 3|T|, that of Amin et al. [13] requires 3|ID| + 8|s| + 6|H| + 3|T|, that of Martinez et al. [17] requires 3|ID| + 18|s| + |H| + 2|E| + 2|Z * p |, that of Kang et al. [19] requires 3|ID| + 10|s| + 6|H| + 3|T|, and our protocol requires 3|ID| + 15|s| + 5|H| + 3|T|. Table 7 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].   Figure 11. Comparative results of storage costs [13,[17][18][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. According to the formula W = U · I · t, the power consumption required by each device was calculated. The results are shown in Table 9 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.  Figure 12. Comparative results of energy costs [13,[17][18][19]].

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.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations
The following abbreviations are used in this manuscript:

IoT
Internet of Things ROR real-oracle random AKA authentication and key agreement DoS denial of service