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.

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.

Figure 1

Architecture of IoT-enabled cloud computing.

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. 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(2) Can resist offline password-guessing attacks	(1) Cannot resist insider(2) Cannot resist userimpersonation attacks
Wazid et al. [23]	(1) Can resist userimpersonation attacks(2) Provides user anonymity(3) Provides perfect forwardsecurity	-
Wu et al. [24]	(1) Can resist temporary value(2) Can resist offline passowrd-guessing attacks	(1) Cannot resist sensorcapture attacks(2) Cannot resist denialof service attacks(3) Cannot provideperfect forward security
Tsai and Lo [25]	(1) Can resist temporary valuedisclosure attacks(2) Provides perfect forwardsecurity	(1) Cannot resist serverimpersonation attacks
Irshad et al. [26]	(1) Can resist userimpersonation attacksProvides Perfectforward security	(1) Lacks userregistration andrevocation phases
Amin et al. [13]	(1) Can resist temporary valuedisclosure attacks(2) Can resist insiderattacks	(1) Cannot preventinsider attacks(2) Cannot resistimpersonation attacks
Martinez et al. [17]	(1) Can resist userimpersonation attacks(2) Can resist offline password-guessing attacks(3) Provides user anonymity	(1) Cannot preventimpersonation attacks(2) Cannot resist sessionkey exposure attacks(3) Cannot achievemutual authentication
Zhou et al. [18]	(1) Provides user anonymity(2) Can achieve mutualauthentication(3) Can resist insiderattacks	(1) Cannot prevent replayattacks(2) Cannot preventimpersonation attacks(3) Cannot preventtemporary valuedisclosure attacks(4) cannot provide perfectforward security
Kang et al. [19]	(1) Can resistimpersonation attacks(2) Can achieve mutualauthentication	(1) Cannot resist offlinepassword-guessing attacks

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

Table 2

Notations.

Notations	Meanings
S_j	The jth cloud server
SID_j	The S_j’s identity
U_i	The ith user
ID_i	U_i’s identity
PW_i	U_i’s password
B_i	U_i’s biological information
HPW_i	U_i’s pseudo password
SC	Smart card
CS	Control server
ID_CS	CS’s identity
x	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

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.

Figure 2

Information exchange process.

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.

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.

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, registers with as a legal user. The user transmits the parameters calculated by themselves to via a secure channel and finally obtains the smart card issued by . Figure 3 detail the process. The specific process is as follows:

Figure 3

User registration phase.

chooses , , and ; calculates and ; and then sends to control server through a secure channel.

checks ’s identity. If the identity is new, selects a random value and computes , , stores in the database, stores in smart card , and then sends to through a secure channel.

After receiving message sent by , calculates and then stores in .

3.3. Cloud Server Registration Phase

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

Figure 4

Cloud server registration phase.

selects its identity and random number and then sends to through a secure channel.

checks the identity of . If is unregistered, then selects a pseudo identity for , calculates , and stores in its memory. Then, sends to through a secure channel.

calculates and stores in its memory.

3.4. Login and Authentication Phase

At this phase, the control server verifies the identity of the user and cloud server . 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:

Figure 5

Login and authentication phase.

inputs and ; imprints ; computes , , ; and checks the legitimacy of ’s identity by verifying . If this is valid, then chooses a random value and timestamp and computes , , , and . Subsequently, is sent to through an open channel.

After receiving ’s message, checks timestamp . If the timestamp is valid, then selects a random number and timestamp . calculates , , and and then sends message to through an open channel.

After receiving , checks timestamp . If the verification passes, finds according to ; computes , , and ; and verifies ’s identity by checking . If valid, then indexes according to the value of ; computes , , and ; and checks . If valid, then selects computes , , , , , , and , and sends message to through an open channel.

After receiving , the cloud server checks the timestamp . If the timestamp is valid, then computes , , and , and checks . If true, sends message to through an open channel.

checks timestamp . If the verification passes, then computes , , , and and checks . If the verification passes, then computes and sends to .

computes and checks . If the verification passes, then stores 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 are defined:

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.

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.

can disclose the established session key, long-term key, and session state.

can guess the user’s password or identity, but is unable to guess the user’s identity or password simultaneously in polynomial time.

may extract the information of a user’s 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 .

The protocol comprises three parties: user, cloud server, and control server. In this model, , , and are the xth user, yth cloud server, and zth control server, respectively. Suppose attacker ’s query capabilities include the following: , , and .

: Assuming an attacker executes the query, they can capture messages on the open channel.

: Assuming an attacker executes the query, they transfer M to Z and receive an answer from Z.

: Suppose an attacker executes the query; they enter a string and obtain a hash value.

: Assuming an attacker executes the query, they obtain the private value of an entity, for example, a long-term key and temporary information of the user’s .

: Assume that an attacker executes the query and tosses a coin C into the air. If C equals 1, obtains . Otherwise, obtains a string.

If

The ROR model played . is the probability that can win –. The following are the specific query steps in the game: : represents the first round of the game, which starts by flipping C. cannot execute any queries; hence, the probability that can break P is as follows:

: is for the -added operation, and can be used only when intercepts the messages – transmitted over the open channel. Then, because the values of and cannot be obtained, cannot obtain the session key through the query. Thus, ’s probability is the same as .

: extends by adding the query. The probability of is calculated using Zipf’s law [39].

: is for the -added operation and deleted operation. ’s probability can be obtained using the birthday paradox.

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

Perfect forward security: with to obtain x of or use , to obtain private values.

Temporary information disclosure attack: utilizes , or to obtain the random number of three entities.

For the first case, even if obtains x or some private values, they cannot calculate , or . Therefore, cannot calculate , where . For the second case, even if obtains but and are private, is incalculable. Similarly, even if can obtain or , is also incalculable. Thus, the probability of is obtained:

: In , queries the parameters in the smart card by executing . This proves that our protocol can protect against offline password-guessing attacks. attempts to guess , where . However, and are private. The probability that can guesses l bit of biological information is . From Zipf’s law [39], when , the probability that can guess the password is more than . Thus, the probability of can be obtained:

: confirms that the protocol can prevent impersonation attacks. queries , and the game ends. Therefore, the probability of can be obtained:

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

From all these formulas,

Consequently, we obtain  □

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.

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

Figure 6

Definitions.

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 begins authentication, event UserAuthed() indicates that successfully authenticated, event ControlServerAcUser() represents authenticating successfully, event ControlServerAcCloudServer() represents authenticating successfully, event CloudServerAcControlServer() indicates that successfully authenticates , event UserAcControlServer() represents authenticating successfully, event UserAcCloudServer() represents authenticating successfully, and event CloudServerAcUser() represents authenticating successfully.

Figure 7a–c shows ’s, ’s, and ’s processes, respectively. Finally, Figure 8 presents the results. The first three results demonstrate that attackers cannot obtain , 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.

Figure 7

Process.

Figure 8

Results.

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

computes by intercepting messages on the open channel. Let us suppose that message is intercepted and attempts to calculate but they cannot obtain the values of . Therefore, cannot use the message on the open channel to calculate ; change any values; or successfully pass the authentication of ; thus, they cannot successfully calculate . Consequently, the proposed protocol can guard against MITM attacks.

4.3.2. Insider Attacks

Case one: Assume that a malicious attacker obtains stored in the database. They use the message on the open channel to compute . However, cannot obtain the values of , and thus, cannot be calculated. Similarly, because cannot obtain the values of , cannot calculate and . Therefore, the session key cannot be computed using . Therefore, our protocol can prevent insider attacks.

Case two: Assume that the attacker is an insider of the cloud server and obtains the information stored in it. They then try to intercept the information on the open channel and to calculate the session key . They intercepted and tried to calculate but cannot calculate the value of and thus cannot obtain the value of . Similarly, attempts to intercept and to calculate , and . However, they cannot obtain the value of and thus cannot calculate and , so they cannot successfully calculate .

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, sends service request message to . After receives , whether the timestamp is valid is checked first. If the timestamp is valid, performs the following calculation. Therefore, if attacker 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 attempts to impersonate any legitimate user, cloud server, or control server. Suppose that obtains the information stored in and intercepts the messages on the public channel. wants to impersonate a legitimate by calculating , but cannot obtain values of and . Therefore, they cannot successfully calculate the value of and cannot impersonate a legitimate user by changing to pass the verification of and thus cannot pretend to be a legitimate user.

Case two: Similarly, wants to impersonate a through but cannot obtain values of and , so they cannot pass the verification of . Therefore, cannot successfully impersonate a legal . 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 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 and try to calculate the authentication value by intercepting the information on the open channel. Because they cannot obtain , they cannot calculate and thus cannot successfully calculate and pass the authentication of . Therefore, our protocol can resist identity theft attacks.

4.3.6. Replay Attacks

According to our defined attacker model, an attacker 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 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, . Case one: Suppose that an attacker can obtain x but and cannot be computed and cannot obtain random numbers , , and . Therefore, there is no way to calculate the current or the previous , so the proposed protocol can provide perfect forward security.

Case two: Assume that an attacker A obtains the user’s password to attack. Because the user’s biological information cannot be obtained, cannot compute , where . Additionally, is unknown. cannot successfully compute .

Case three: Assume that an attacker can obtain the private value of a cloud server for an attack. Because the identity of the cannot be obtained, cannot calculate , where . Furthermore, cannot calculate and ; here, and . Additionally, is unknown, and cannot successfully calculate .

Therefore, the proposed protocol can provide perfect forward security.

4.3.8. Session Key Disclosure Attacks

It is assumed that the attacker attempts to intercept the transmission of information on the open channel. Even if the attacker intercepts the messages , they cannot compute , , and because they cannot obtain the values of . Obviously, they cannot compute the session key 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, verifies the user and cloud server through and , respectively, and and are the values of and used to verify mutual identity, respectively. Although and are transmitted over the open channel, the values of , , , and cannot be obtained by an attacker . Similarly, and are also transmitted over the open channel, but cannot obtain the values of and , 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 attempts to identify a user by intercepting messages on the open channel. However, in our proposed method, can only obtain ’s pseudo identity . Thus, cannot compute the user’s real . Similarly, can only obtain the ’s pseudo identity . cannot determine the true identity of and based on the pseudo identity, which protects the privacy of and . Therefore, our protocol can provide privacy and anonymity.

4.3.11. Traceability and Non-Repudiation

When cloud server finds that has bad behavior, it will report to , and will find the value of the user’s according to , which can be used to identify . Therefore, once a user exhibits malicious behavior, can track the user, which ensures traceability. Since the transmitted message contains the value of authenticating the user’s identity , once a legitimate user exhibits bad behavior, will verify the user’s identity according to . 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 cannot change the transmitted information. Even if 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 can intercept and tamper with the messages , transmitted on the open channel. For example, intercepts and tampers with message , where . If tampers with , cannot retrieve and the authentication is suspended. If tampers with , then calculates that is not equal to the received , which indicates that the user is not legal or is tampered with, and the authentication is suspended. Similarly, if an attacker intercepts and tampers with , 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 . 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 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.

Table 3

Comparisons of security.

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

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 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 , the protocol of Martinez et al. [17] requires , Zhou et al.’s [18] protocol requires , Kang et al.’s protocol [19] requires , and our proposed protocol requires . 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.

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	-

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

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_h	11T_h	0.0728
Ours	5T_h	13T_h	0.0936

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 to 160 bits, random number 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 , that of Amin et al. [13] requires , that of Martinez et al. [17] requires , that of Kang et al. [19] requires , and our protocol requires . 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.

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

Figure 10

Comparative results of communication costs [13,17,18,19].

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

Table 8

Voltage and current of devices.

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

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

Figure 12

Comparative results of energy costs [13,17,18,19].

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.