Rotating behind security: an enhanced authentication protocol for IoT-enabled devices in distributed cloud computing architecture

Abstract

With the continuous progress of the Internet of Things (IoT) technology, IoT devices have gradually penetrated all aspects of life. However, due to rapid data growth, IoT devices with limited memory resources cannot store massive data. Cloud computing is an Internet-centric network that can provide security services and data storage. The combination of IoT devices with cloud computing considerably promotes resource sharing, facilitates users’ access to information at any time, and provides users with corresponding cloud computing services on time. Because the information transmitted through public channels is easily intercepted, tampered with, and eavesdropped on by malicious attackers. As a result, users’ and servers’ private information are disclosed. Numerous scholars have proposed different authentication protocols in this environment to protect the communications between users and servers. Amin et al. devised a smart card based authentication protocol. Unfortunately, Kang et al. demonstrated that their protocol was insecure. Huang et al. discovered Kang et al.’s improvement also has security flaws and then designed a protocol to enhance security. In this paper, we first show that Huang et al.’s protocol cannot resist privileged insider and temporary value disclosure attacks. Afterward, we propose an enhanced protocol based on their protocol. Finally, we use formal/informal security analysis to demonstrate the security of the improved protocol. The comparison results are indicated that our protocol has lower computational and communication costs under the same security level.

1 Introduction

The Internet of Things (IoT) [1,2,3] is a network that combines different sensor devices with the Internet. Following the development of the Internet and artificial intelligence technology [4,5,6], IoT technology is progressively being used in many different fields such as vehicle [7,8,9], smart grid [10, 11], healthcare [12,13,14], smart home [15, 16], smart manufacturing, and etc. As a subset of the IoT technology, the Industrial Internet of Things (IIoT) [17] has become a synonym for smart manufacturing. With the explosion of data, memory-constrained IoT devices are challenged, and cloud/fog computing [18,19,20] comes into being.

The IoT-enabled devices in the distributed cloud computing architecture significantly promote resource sharing, facilitate users to access information anytime, and provide users with the corresponding IoT services. In a distributed cloud computing environment, messages are transmitted through open and unstable wireless channels, making them easy for malicious attackers to intercept, tamper, and eavesdrop. Authentication and key agreement (AKA) is a cryptographic primitive. AKA can be used to realize secure communication through mutual authentication between entities and negotiation of a session key. In recent years, numerous scholars have put forth various authentication protocols for IoT-enabled devices in the cloud computing environment. However, designing a secure authentication protocol in this environment is still a challenge.

In 2014, Turkanovic et al. [21] devised an IoT-based authentication protocol. Their protocol claimed lightweight and provably secure to achieve secure communications between user and sensor node. Nevertheless, Farash et al. [22] indicated that Turkanovic et al.’s protocol could not withstand man-in-the-middle (MITM) attacks and could not guarantee the anonymity of sensor node. Then, they designed a new AKA protocol. Unfortunately, Amin et al. [23] proved that Farash et al.’s protocol also had several security flaws including user impersonation and stolen smart card (SSC) attacks as well as violating anonymity. To overcome the shortcomings of their protocol, Amin et al. devised a secure AKA protocol that guaranteed the anonymity of entities. Chatterjee et al. [24] put forward a secure AKA protocol employing physical unclonable functions (PUF) in the IoT environment and purported that the protocol can withstand known attacks. Unfortunately, Braeken [25] found that Chatterjee et al.’s protocol could not resist MITM, denial of service (DoS), and replay attacks. Panda and Chattopadhyay [26] presented a secure AKA protocol using elliptic curve cryptosystems (ECC). Bao et al. [27] proposed an authentication protocol using an attribute-based signature (ABS) concept for the IIoT. The ABS used in this protocol can provide privacy-preserving authentication for IIoT. Chithaluru et al. [28] proposed a radio scheme for the IoT, which can adapt to the environment well and provide reliable communication.

In 2014, Liu et al. [29] devised an AKA protocol that used shared permissions in the cloud. Their protocol provided privacy-preserving for user and cloud server based on attributes and sharing permissions. Kalra et al. [30] designed an AKA protocol using ECC in the IoT and cloud environment. Amin et al. [31] pointed out security vulnerabilities in Xue et al.’s protocol [32] and Chuang et al.’s protocol [33]. They also devised an AKA protocol in the cloud. However, Wang et al. [34] indicated that Amin et al.’s protocol cannot withstand offline dictionary attacks and could not provide anonymity. They then designed a secure ECC-based AKA protocol. Wu et al. [35] presented a novel chaotic-based AKA protocol. Unfortunately, Wang et al. [36] indicated that Wu et al.’s protocol could not resist temporary value disclosure (TVD) and SSC attacks. Fan et al. [37] put forward an AKA protocol using radio frequency identification (RFID) technology for the cloud computing environment. He et al. [38] put forward an anonymous authentication protocol employing asymmetric cryptography without the registration authority. However, Yu et al. [39] found that He et al.’s protocol suffered from insider and DoS attacks, and designed an improvement. Irshad et al. [40] designed a new type of lightweight AKA protocol without pairings. Rangwani et al. [41] presented an enhanced AKA protocol to overcome the shortcomings in [42]. Zhou et al. [43] devised a two-factor provably secure AKA protocol. Unfortunately, Wang et al. [44] indicated that Zhou et al.’s protocol could not withstand impersonation and TVD attacks, as well as violated perfect forward secrecy (PFS). Martinez-Pelaez et al. [45] also stated that Zhou et al.’s protocol is insecure against MITM attacks and violated mutual authentication (MA). However, Yu et al. [46] demonstrated that the improved protocol [45] could not resist replay and session key disclosure (SKD) attacks as well as violated MA.

In 2020, Kang et al. [47] conducted a cryptanalysis of [31], demonstrating that their protocol was insure. Subsequently, they devised an improved AKA protocol. Wu et al. [48] also proposed an improved AKA protocol to enhance the security of [43]. Recently, Huang et al. [49] stated that [47] was unable to withstand offline password guessing (OPG) attacks and improved the protocol using lightweight operations. Some related authentication protocols in distributed cloud computing environments are summarized in Table 1. In this paper, we first analyze [49] and find some security weaknesses. Then, we based on their protocol to propose an improvement. Our contributions are summarized as follows.

• (1) We first find Huang et al.’s protocol is insecure against privileged insider and TVD attacks. In order to enhance the shortcomings of [49], we propose an improved protocol.

• (2) We use the real or random (ROR) model (formal security analysis), informal security analysis, and ProVerif to verify the security of our improved protocol. The results are indicated that our protocol is provably secure to ensure secure communication between entities.

• (3) Finally, comparing the proposed protocol with other protocols in terms of security and performance, the results are indicated that our protocol has lower computational and communication costs as well as resisting well-known attacks.

The remainder of this paper is structured as follows: we summarize the adopted methods and experiments in Sect. 2. We briefly review Huang et al.’s protocol and proved that their protocol has two security problems in Sect. 3.

In Sect. 4, we describe the details of our proposed protocol.

Results and discussion are made in Sect. 5.

We draw the conclusion in Sect. 6.

Table 1 Overview of authentication protocols

2 Methods and experiments

We adopt the same architecture of [49] in our protocol. There are three entities: User $U_i$, cloud server $S_j$, and control server TCS, where $U_i$ can obtain services from $S_j$ by using IoT devices, $S_j$ provides several services on demand of $U_i$, and TCS is in charge of $U_i$ and $S_j$ registration and authentication. Before the authentication phase, $U_i$ and $S_j$ register with TCS. After finishing this phase, legitimate $U_i$ and $S_j$ can authenticate each other and negotiate a common key with the help of TCS. Our protocol only performs two kinds of lightweight operations: hash and XOR operations.

The security of our proposed protocol is verified by (1) using ROR model for formal analysis; (2) using a verification software, ProVerif, on Lenovo desktop with Windows 10 operating system; (3) using informal security analysis for some specific security requirements. Finally, we compare other related authentication protocols with our protocol in terms of security and performance. The results are shown that our protocol is feasible and has a lower cost.

3 Review and cryptanalysis of Huang et al.’s protocol

In this section, we review Huang et al.’s protocol [49] and prove that their protocol is insecure. Their protocol includes three entities: user $U_i$, cloud server $S_j$, and control server TCS. Three phases of “registration,” “login,” and “authentication and key agreement” are briefly reviewed below. Some important symbols used in this paper are shown in Table 2.

3.1 Review Huang et al.’s protocol

Table 2 Notations

3.1.1 Registration phase

Registration of $S_j$.

• (1) $S_j$ chooses $CSID_j$ and a random number $R_j$, then though the secure channel sends ${\{CSID_j, R_j\}}$ to TCS.

• (2) After receiving ${\{CSID_j, R_j\}}$, TCS computes $TSID_j= h(CSID_{j}\parallel R_j)$, $RSID_j=h(TSID_{j}\parallel CSID_j\parallel y)$, where y is the private key that authenticates all $S_j$. Finally, TCS transmits ${\{RSID_j\}}$ to $S_j$.

• (3) After receiving ${\{RSID_j\}}$, $S_j$ stores secret parameter {$RSID_j, R_j$} in memory.

Registration of $U_i$.

• (1) $U_i$ selects $UID_{i}$, $UPW_i$, $BIO_i$, and $R_i$ to compute $RID_i= h(UID_i\parallel R_i)$, $UA_i = UPW_i\oplus h(BIO_i)$, and $UC_i=R_i\oplus UA_i$. Next, $U_i$ sends $\{UID_i, RID_i, UA_i\}$ to TCS.

• (2) After receiving $\{UID_i, RID_i, UA_i\}$ sent by $U_i$, TCS first verifies the identity of $U_i$. If $UID_i$ is not registered, TCS calculates $TD_i=h(UID_i\parallel UA_i)$, $TE_i=h(RID_i\parallel x)$, and $TF_i=TE_i\oplus UA_i$. Then, TCS stores the data ${\{TD_i,TF_i,h(.)}\}$ in smart card (SC). Finally, TCS sends SC to $U_i$.

• (3) After receiving SC, $U_i$ stores $UC_i$ in it. Finally, SC records the information ${\{UC_i,TD_i, TF_i,h(.)}\}$.

3.2 Login phase

$U_i$ puts SC into the IoT-enabled device, then enters $UID_i$, $UPW_i$, and $BIO_i$. The SC computes $UA_i= UPW_i\oplus h(BIO_i)$, $TD^*_i = h(UID_i \parallel UA_i)$, and then performs authentication by checking $TD^*_i\overset{\text {?}}{=}TD_i$. If authentication is successful, $U_i$ logs in successfully.

3.3 Authentication and key agreement phase

Mutual authentication is performed between $U_i$, $S_j$, and TCS when $U_i$ signs in.

• (1) $U_i$ generates $UN_i$ and $TS_i$, and chooses $CSID_j$. Then, $U_i$ computes $R_i=UC_i\oplus UA_i$, $RID_i=h(UID_i\parallel R_i)$, $TE_i=TF_i\oplus UA_i$, $UG_i=h(RID_i\parallel CSID_j\parallel UN_i\parallel TS_i\parallel TE_i)$, $UH_i=TE_i\oplus UN_i$, and $UJ_i=CSID_j\oplus h(TE_i\parallel UN_i)$. After that, $U_i$ sends message $M_1=\left\{ UG_i, UH_i, UJ_i,RID_i, TS_i\right\}$ to $S_j$

• (2) After receiving $M_1$, $S_j$ verifies $\vert TS_j - TS_i\vert \le \Delta T$. If the timestamp is valid, $S_j$ generates $CN_j$ and $TS_j$. Then, $S_j$ computes $CK_j = RSID_j\oplus CN_j$, $CL_j=h(CN_j\parallel RSID_j\parallel RID_i\parallel UG_i\parallel TS_j)$, and sends message $M_2=\{ CK_j, CL_j,TSID_j,UG_i,UH_i,UJ_i,RID_i,TS_i,TS_j\}$ to TCS.

• (3) After receiving $M_2$, TCS verifies $\vert TS_{SC} - TS_j\vert \le \Delta T$. If the timestamp is invalid, the session is terminated. Otherwise, TCS computes $TE_i=h(RID_i\parallel x)$, $UN_i=TF_i\oplus TD_i$, $CSID_j=UJ_i\oplus h(TE_i\parallel UN_i)$, and $UG_i^*=h(RID_i\parallel CSID_j\parallel UN_i\parallel TS_i\parallel TE_i)$. TCS checks $UG_i^* \overset{?}{=}\ UG_i$ to verify the identity of $U_i$. If the identification is successful, TCS computes $RSID_j=h(TSID_j\parallel CSID_j\parallel y)$, $CN_j=RSID_j\oplus CK_j$, and $CL_j^*=h(CN_j\parallel RSID_j\parallel RID_i\parallel UG_i\parallel TS_j)$. TCS checks $CL_j^* \overset{?}{=}\ CL_j$ to verify the identity of $S_j$. If the verification succeeds, TCS chooses $TN_{CS}$. Then, TCS computes $TP_{CS} = CN_j\oplus TN_{CS}\oplus h(UN_i\parallel TE_i\parallel UH_i)$, $TR_{CS}=UN_i\oplus TN_{CS}\oplus h(RSID_j\parallel CN_j)$, $SK_{CS}=h(UN_i\oplus CN_j\oplus TN_{CS})$, $TQ_{CS}=h((UN_i\oplus TN_{CS})\parallel SK_{CS})$, and $TV_{CS}=h((UN_i\oplus TN_{CS})\parallel SK_{CS})$. Finally, TCS sends message $M_3=\{ TP_{CS}, TR_{CS},TQ_{CS},TV_{CS}\}$ to $S_j$.

• (4) After receiving $M_3$, $S_j$ computes $CW_j=h(RSID_j\parallel CN_j)$, $UN_i\oplus TN_{CS}=TR_{CS}\oplus CW_j$, $SK_{j}=h(UN_i\oplus TN_{CS}\oplus CN_j)$, and $TV_{CS}^*=h((UN_i\oplus TN_{CS})\parallel SK_{j})$. $S_j$ verifies whether the identity of TCS is valid by checking $TV_{CS}^* \overset{?}{=}\ TV_{CS}$. If true, $S_j$ transmits message $M_4 =\{ TP_{CS}, TQ_{CS}\}$ to $U_i$.

• (5) After receiving $M_4$, $U_i$ computes $UZ_i=h(UN_i\parallel TE_i\parallel UH_i)$, $CN_j\oplus TN_{CS}=TP_{CS}\oplus UZ_i$, $SK_i=h(CN_j\oplus TN_{CS}\oplus UN_i)$, and $TQ_{CS}^*=h((CN_j\oplus TN_{CS})\parallel SK_i)$. $U_i$ verifies whether the identities of TCS and $S_j$ are valid by checking $TQ_{CS}^*\overset{?}{=}\ TQ_{CS}$. If true, the three participants $U_i$, $S_j$, and TCS establish the session key SK, where $SK=h(UN_i\oplus CN_j\oplus TN_{CS})$.

3.4 Cryptanalysis of Huang et al.’s protocol

Here, we show that their protocol [49] is insecure against (1) privileged insider and (2) TVD attacks.

3.4.1 Adversary model

D-Y [50] and C-K [51] adversarial models are well used. We follow both models to describe the attacker (A)’s capabilities

• (1) A is capable of intercepting, deleting, or eavesdropping messages transmitted in the public channel.

• (2) A is able to intercept the temporary value generated by user or cloud server in each session.

• (3) Through power analysis, A is capable of acquiring the data stored in the smart card.

• (4) A is capable of obtaining the parameters stored in the cloud server.

3.4.2 Privileged insider attacks

Assuming that A obtains the value $\{RSID_j, R_i\}$ stored in $S_j$. Then, SK is calculated as follows.

• (1) A can capture $M_2=\{ CK_j, CL_j,TSID_j,UG_i,UH_i,UJ_i,RID_i,TS_i,TS_j\}$ transmitted in the public channel, then get the values of $CN_j$ and $CW_j$, where $CN_j=CK_{j}\oplus RSID_j$ and $CW_j=h(RSID_j\parallel CN_j)$.

• (2) A can capture the message $M_3=\{ TP_{CS}, TR_{CS},TQ_{CS},TV_{CS}\}$ transmitted in the public channel, and can calculate the value $UN_i\oplus TN_{CS}$ though $UN_i\oplus TN_{CS}= TR_{CS}\oplus CW_j$.

• (3) At last, A can successfully calculate SK, where $SK=h(UN_i\oplus TN_{CS}\oplus CN_j)$.

Therefore, Huang et al.’s protocol is insecure against privileged insider attacks.

3.4.3 Temporary value conflict of interest (TVD) attacks

Assume that A can obtain the temporary value of each entity. Then, we describe the process of A successfully calculating SK in the two cases.

Case I. A can obtain $UN_i$ of $U_i$.

• (1) A can capture $M_2=\{ CK_j, CL_j,TSID_j,UG_i,UH_i,UJ_i,RID_i,TS_i,TS_j\}$ transmitted in the public channel, then get the values of $TE_i$ and $UZ_i$, where $TE_i=UH_{i}\oplus UN_i$ and $UZ_i=h(UN_i\parallel TE_i\parallel UH_i)$.

• (2) A can capture $M_3=\{ TP_{CS}, TR_{CS},TQ_{CS},TV_{CS}\}$ transmitted in the public channel, and can calculate the value $CN_j\oplus TN_{CS}$ though $CN_j\oplus TN_{CS}= TP_{CS}\oplus UZ_i$.

• (3) Finally, A can successfully calculate SK, where $SK=h(UN_i\oplus TN_{CS}\oplus CN_j)$.

Case II. A obtains $CN_j$ of $S_j$.

• (1) A can capture $M_2=\{ CK_j, CL_j,TSID_j,UG_i,UH_i,UJ_i,RID_i,TS_i,TS_j\}$ transmitted in the public channel, then get the values of $RSID_j$ and $CW_j$, where $RSID_j=CK_{j}\oplus CN_j$ and $CW_j=h(RSID_j\parallel CN_j)$.

• (2) A can capture $M_3=\{ TP_{CS}, TR_{CS},TQ_{CS},TV_{CS}\}$ transmitted in the public channel, and can calculate the value $UN_i\oplus TN_{CS}$ though $UN_i\oplus TN_{CS}= TR_{CS}\oplus CW_j$.

• (3) Finally, A can successfully calculate SK, where $SK=h(UN_i\oplus TN_{CS}\oplus CN_j)$.

In both cases, their protocol [49] cannot resist TVD attacks.

4 Proposed protocol

In this section, we followed Huang et al.’s framework [49] to propose an improvement. Note that our enhancements are marked in red for each phase depicted in Figures  1, 2, and 3.

4.1 New registration of $S_j$

The new registration of $S_j$ is shown in Fig. 1.

• (1) $S_j$ chooses $CSID_j$ and $R_j$ to calculate $RSID_j= h(CSID_{j}\parallel R_j)$. Finally, $S_j$ sends ${\{RSID_j,CSID_j\}}$ to TCS.

• (2) After TCS receives ${\{RSID_j,CSID_j\}}$, it computes $TSID_j=h(RSID_{j}\parallel CSID_j\parallel x)$. Fianlly, TCS sends $TSID_j$ to $S_j$.

• (3) After $S_j$ receives ${\{TSID_j\}}$, it computes $CZ_j=CSID_j\oplus TSID_j$. Finally, $S_j$ stores {$CZ_j$} in its memory.

Fig. 1

New registration of $S_j$

4.2 New registration of $U_i$

The new registration of $U_i$ is shown in Fig. 2.

• (1) $U_i$ chooses $UID_{i}$, $UPW_i$, $BIO_i$, and $R_i$ to compute $RID_i= h(UID_i\parallel R_i)$. Then, it sends $\{UID_i, RID_i\}$ to TCS.

• (2) After TCS receives $\{UID_i, RID_i\}$ from $U_i$, TCS verifies $UID_i$. If $UID_i$ is a registered identity, TCS rejects this registration request. Otherwise, TCS chooses $t_i$ and calculates $TB_i=h(RID_i\parallel x\parallel t_i)$. Then, TCS stores ${\{RID_i,t_i}\}$ in its database. Finally, TCS sends ${\{TB_i, t_i}\}$ to $U_i$.

• (3) $U_i$ receives ${\{TB_i, t_i}\}$ from TCS to compute $UA_i = UPW_i\oplus h(BIO_i)$, $UC_i=R_i\oplus UA_i$, $UE_{i}=h(RID_{i}\parallel UA_{i})$, $UF_{i}=TB_{i}\oplus UA_{i}$, and $UG_{i}=t_i\oplus h(UID_{i}\parallel UPW_{i}\parallel R_{i})$. Finally, $U_i$ stores ${\{UC_{i},UE_{i},UF_{i},UG_{i},h(.)}\}$ in SC.

Fig. 2

New registration of $U_i$

4.3 New login and authentication phase

The new login and authentication phase is shown in Fig. 3.

• (1) $U_{i}$ inputs $UID_{i}$, $UPW_{i}$, and $BIO_{i}$ to compute $UA_{i}=UPW_{i}\oplus h(BIO_{i})$, $UE^*_{i}=h(UID_{i}\parallel UA_{i})$. Then, $U_{i}$ checks whether $UE^*_{i}\overset{\text {?}}{=} UE_{i}$. If equal, $U_{i}$ chooses $UN_{i}$, $TS_{i}$, and $S_{j}$’s identity $CSID_j$ to compute $R_{i} =UC_{i}\oplus UA_{i}$, $RID_{i}=h(UID_{i}\parallel R_{i})$, $TB_{i}=UF_{i}\oplus UA_{i}$, $UH_{i}=h(RID_{i}\parallel CSID_{j}\parallel UN_{i}\parallel TB_{i})$, $t_i=h(UID_{i}\parallel UPW_{i}\parallel R_{i})\oplus UG_{i}$, $UJ_{i}=h(TB_{i}\parallel t_i)\oplus UN_{i}$, and $UK_{i}=CSID_{j}\oplus h(TB_{i}\parallel UN_{i}\parallel t_i)$. Finally, $U_i$ sends $M_1={\{UH_i,UJ_i,UK_i,RID_i,TS_i\}}$ to $S_j$.

• (2) After receiving $M_1$ from $U_i$, $S_j$ checks whether $\vert TS_j - TS_i\vert \le \Delta T$. If valid, $S_j$ chooses $CN_j$, and computes $TSID_{j}=CZ_{j}\oplus CSID_{j}$, $CL_{j} =h(TSID_{j})\oplus CN_{j}$, $CM_{j} =h(CN_{j}\parallel CSID_j\parallel TSID_{j}\parallel RID_i\parallel UH_i)$. Finally, $S_j$ sends $M_2={\{UH_{i},UJ_{i},UK_{i},CL_{j},CM_{j},RID_i,RSID_{j},TS_{j}\}}$ to TCS.

• (3) After receiving $M_2$, TCS checks whether $\vert TS_{CS} - TS_j\vert \le \Delta T$. If the timestamp is valid, TCS retrieves $\{t_i\}$ from its database using $RID_i$. TCS computes $TB_{i}=h(RID_i\parallel x\parallel t_i)$, $UN_i=UJ_{i}\oplus h(TB_i\parallel t_i)$, $CSID_j=UK_i\oplus h(TB_i\parallel UN_i\parallel t_i)$, and $UH^*_{i}=h(RID_i\parallel CSID_{j}\parallel UN_i\parallel TB_i)$. TCS verifies the identity of $U_i$ by comparing $UH^*_i\overset{\text {?}}{=} UH_i$. If the authentication succeeds, it means that $U_i$ is valid. Then, TCS computes $TSID_{j}=h(RSID_j\parallel CSID_{j}\parallel x)$, $CN_{j}=h(TSID_j)\oplus CL_j$, and $CM^*_j =h(CN_j\parallel CSID_j\parallel TSID_j\parallel RID_i\parallel UH_{i} )$. TCS verifies the identity of $S_j$ by comparing $CM^*_j\overset{\text {?}}{=} CM_j$. If equal, the identity of $S_j$ is valid. Then, TCS chooses $TN_{CS}$ and computes $TP_{CS}=CN_{j}\oplus TN_{CS}\oplus h(UN_{i}\parallel TB_{i}\parallel CSID_{j})$, $TR_{CS}=UN_{i}\oplus TN_{CS}\oplus h(TSID_{j}\parallel CSID_{j}\parallel CN_{j})$, $SK_{CS}=h(UN_{i}\oplus CN_{j}\oplus TN_{CS})$, $TQ_{CS}=h((CN_{j}\oplus TN_{CS})\parallel SK_{CS})$, and $TV_{CS}=h((UN_{i}\oplus TN_{CS})\parallel SK_{CS})$. Finally, TCS sends $M_3={\{TP_{CS},TR_{CS},TQ_{CS},TV_{CS}\}}$ to $S_j$.

• (4) After receiving $M_3$, $S_j$ computes $CW_{j}=h(TSID_{j}\parallel CSID_{j}\parallel CN_{j})$, $UN_{i}\oplus TN_{CS}=TR_{CS}\oplus CW_{j}$, $SK_{j}=h(UN_{i}\oplus TN_{CS}\oplus CN_{j})$, and $TV^*_{CS}=h((UN_{i}\oplus TN_{CS})\parallel SK_{j})$. If they are equal, $S_j$ successfully authenticates TCS. $S_j$ and TCS successfully authenticate each other. Finally, $S_j$ sends $M_4={\{TP_{CS},TQ_{CS}\}}$ to $U_i$.

• (5) After receiving $M_4$ from $S_j$, $U_i$ computes $UY_{i}=h(UN_{i}\parallel TB_{i}\parallel CSID_{j})$, $CN_{j}\oplus TN_{CS}=TP_{CS}\oplus UY_{i}$, $SK_{i}=h(CN_j\oplus TN_{CS}\oplus UN_i)$, and $TQ^*_{CS}=h((CN_j\oplus TN_{CS})\parallel SK_i)$. If they are not equal, the authentication fails. Otherwise, $U_i$ successfully authenticates TCS and $S_j$. Finally, $U_i$, $S_j$ and TCS achieve authentication and establish SK.

Fig. 3

New login and authentication phase

5 Results and discussion

5.1 Formal security analysis

Canetti et al. [52, 53] proposed the ROR model, which mainly judges the security of authentication protocol according to the probability that successfully breaks SK through a sequence of games. Here, we use this approach to calculate the probability of A cracking SK and prove that our protocol is secure.

5.1.1 Security model

Here, $\Pi _{U_i}^x$, $\Pi _{S_j}^y$, and $\Pi _{TCS}^z$ denote the x-th instance of user $U_i$, y-th instance of cloud server $S_j$, and z-th instance of control server TCS, respectively. A can perform the following queries to $W=\{\Pi _{U_i}^x$, $\Pi _{S_j }^y$, $\Pi _{TCS}^z\}$.

• (1) Execute(W): If A performs this query, it can obtain all transmitted messages in the previous sessions between $\Pi _{U_i}^x$, $\Pi _{S_j}^y$, and $\Pi _{TCS}^z$.

• (2) Send(W, M): If A performs this query with M to W, the oracle in W returns a response.

• (3) Hash(M): If A performs this query, it can acquire the corresponding hash value by entering a string M.

• (4) Corrupt(W): If A performs this query, it will retrieve the private data of one entity, such as long-term keys, data stored in SC, or temporary values.

• (5) Test(W): If A performs this query, a coin C is flipped. If $C=1$, A successfully guess the correct SK. If $C=0$, indicating that the coin is down, then A obtains a string with the same length of SK.

5.1.2 Security proof

Theorem 1

In the ROR model, suppose that an attacker A performs Execute, Send, Hash, Corrupt, and Test queries. Then, the advantage (probability) of A that successfully guess the correct session key (break the proposed protocol P) within the polynomial time $\xi$ is stated by $Adv_{{\mathcal {A}}}^{{\mathcal {P}}}(\xi )\le q_{{\text {send}}}/2^{l-2}+q_{{\text {hash}}}^2/2^{l-1}+2max\{C'\cdot q_{{\text {send}}}^{s'}, q_{{\text {send}}}/2^l\}$, where $q_{{\text {send}}}$ and $q_{{\text {hash}}}$ indicate the times of the Send and Hash queries, respectively, l indicates the bit length of biometric, and $C'$ and $s'$ refer to two constants.

Table 3 Simulation of oracles

Proof

Let ${\text {GM}}_i$ be the game and ${\text {Succ}}_A^{{\text {GM}}_i}(\xi )$ be the probability of A wins in ${\text {GM}}_i$. Here, we adopt a sequential six games to simulate the real execution of our protocol. The specific queries are shown in Table 3.

${\text {GM}}_0$: We start ${\text {GM}}_0$ by flipping C. In this game, no query is performed. Therefore, we have

$${\text{Adv}}_{A}^{P} (\xi ) = \left| {2\Pr \left[ {{\text{Succ}}_{A}^{{{\text{GM}}_{0} }} (\xi )} \right] - 1} \right|.$$

(1)

${\text {GM}}_1$: In ${\text {GM}}_1$, Execute query is performed in ${\text {GM}}_0$. In other words, A obtains $\{M_1, M_2, M_3, M_4\}$. Since the values $UN_i$, $CN_j$, and $TN_{CS}$ are unknown, A cannot obtain additional information to guess SK in Test query. Thus, we also have

$$\begin{aligned} {\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_1}(\xi )]={\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_0}(\xi )]. \end{aligned}$$

(2)

${\text {GM}}_2$: In ${\text {GM}}_2$, Send query is performed in ${\text {GM}}_1$. According to Zipf’s law [54], it implies

$$\begin{aligned} |{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_2}(\xi )]-{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_1}(\xi )]|\le q_{{\text {send}}}/2^{l}. \end{aligned}$$

(3)

${\text {GM}}_3$: In ${\text {GM}}_3$, Hash query is performed in ${\text {GM}}_2$ without Send query. Based on the birthday paradox, it also implies

$$\begin{aligned} |{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_3}(\xi )]-{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_2}(\xi )]|\le q_{{\text {hash}}}^2/2^{l+1}. \end{aligned}$$

(4)

${\text {GM}}_4$: In ${\text {GM}}_4$, Corrupt query is performed in ${\text {GM}}_3$. Two cases are set to analyze the security. The first case is to acquire long-term key or private value to simulate PFS and another case is to acquire the temporary value of some entity to simulate TVD attacks.

• (1) Case I (PFS): A utilizes $\Pi _{TCS}^z$ to acquire TCS’s long-term key x or $\Pi _{S_j}^y$ to get the private value.

• (2) Case II (TVD attacks): A utilizes $\Pi _{U_i}^x$, $\Pi _{S_j }^y$ or $\Pi _{TCS}^z$ to get random number.

In Case I, $\{UN_i, CN_j, TN_{CS}\}$ are also unknown. A cannot obtain additional information to guess $SK=h(UN_i\oplus CN_j\oplus TN_{CS})$ in Test query. In Case II, even if A can obtain $UN_i$, $\{CN_j, TN_{CS}\}$ are also kept secret. Thus, we can obtain

$$\begin{aligned} |{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_4}(\xi )]-{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_3}(\xi )]|\le q_{{\text {send}}}/2^{l}+q_{{\text {hash}}}^2/2^{l+1}. \end{aligned}$$

(5)

${\text {GM}}_5$: In ${\text {GM}}_5$, Corrupt query is also performed in ${\text {GM}}_4$ to simulate SSC attacks. In other words, A can access $\{UC_i, UE_i, UF_i, UG_i\}$. Similarly, with the help of the password dictionary, A attempts to guess the user’s $UPW_ i$. Because $\{UID_i,UPW_i\}$ are kept secret, A cannot calculate $UA_i=UPW_i\oplus h(BIO_i)$. Therefore, A cannot guess $UPW_ i$. The probability of A guessing l bits of biometric information is $1/2^ l$ [55]. According to Zipf’s law [54], when $q_{{\text {send}}} \le 10^6$, the probability that A can guess the password is greater than 0.5. Thus, we can obtain

$$\begin{aligned} |{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_5}(\xi )]-{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_4}(\xi )]|\le max\{C'\cdot q_{{\text {send}}}^{s'},q_{{\text {send}}}/2^l\}. \end{aligned}$$

(6)

In addition, the probability of A only correct guess c to win ${\text {GM}}_5$ is

$$\begin{aligned} {\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_5}(\xi )]=1/2. \end{aligned}$$

(7)

Therefore, We can obtain the following results

$$\begin{aligned} \begin{aligned} Adv_A^P(\xi )/2&= |{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_0}(\xi )]-1/2| \\&=|{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_0}(\xi )]-{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_5}(\xi )]| \\&=|{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_1}(\xi )]-{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_5}(\xi )] |\\&\le \sum _{i=0}^{4}|{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_{i+1}}(\xi )]-{\text{Pr }}[{\text {Succ}}_A^{{\text {GM}}_i}(\xi )]| \\&= q_{{\text {send}}}/2^{l-1}+q_{{\text {hash}}}^2/2^l+max\{C'\cdot q_{{\text {send}}}^{s'},q_{{\text {send}}}/2^l\} \end{aligned} \end{aligned}$$

(8)

As a result, we can obtain

$$\begin{aligned} Adv_{{\mathcal {A}}}^{{\mathcal {P}}}(\xi )\le q_{{\text {send}}}/2^{l-2}+q_{{\text {hash}}}^2/2^{l-1}+2max\{C'\cdot q_{{\text {send}}}^{s'},q_{{\text {send}}}/2^l\}. \end{aligned}$$

(9)

$\square$

5.2 ProVerif

ProVerif [56, 57] is an automated verification tool for analyzing and verifying authentication protocols. In this article, we utilize it to verify our protocol’s security. It mainly simulates the “Registration” and “Login and authentication” process of $U_i$, $S_j$, and TCS by executing code.

The symbol definition that ProVerif needs to use is shown in Fig. 4a. In the query operation, we mainly query whether A can obtain the correct SK and whether the protocol is correct. The six events involved in our protocol are event UserStarted(), event UserAuthed(), event ControlServerAcUser(), event ControlServerAcCloudServer(), event CloudServerAcControlServer(), event UserAcControlServer(). They, respectively, indicate that $U_i$ has started authentication, $U_i$ has completed authentication, TCS has successfully authenticated the $U_i$, TCS has successfully authenticated the $S_j$, $S_j$ has successfully authenticated the TCS, and $U_i$ has successfully authenticated the TCS. The specific queries and events required are shown in Fig. 4b.

The processes of using ProVerif to simulate $U_i$, $S_j$, and TCS are shown in Fig. 5. Here we take the ProVerif simulation TCS process as an example to describe the steps of the simulation process in detail. Among them, “UiReg” represents the $U_i$ registration phase, “SjReg” represents the $S_j$ registration phase, “TCSAuth” represents the TCS authentication phase, “new ti: bitstring” refers to the defined random number, “in(sch,(zUIDi: bitstring, zRIDi: bitstring))” refers to the TCS receives the registration request sent by the $U_i$, “out(ch,(TPcs, TRcs, TQcs, TVcs))” refers to the TCS sends messages to the $S_j$. The results of using the ProVerif authentication protocol are shown in Fig. 6. Experimental results are shown that our protocol is correct and can resist several well-known attacks, as well as each entity, can securely achieve authentication and establish SK.

Fig. 4

Definitions, queries, and events

Fig. 5

Execution process of $U_i$, $S_j$, TCS

Fig. 6

Verification result

5.3 Informal security analysis

5.3.1 Privileged insider attacks

Suppose A can obtain $CZ_j$ from the database of $S_j$. $CN_j$ cannot be calculated because A is unable to retrieve the value of $CSID_j$. Therefore, the value of $\{UN_i,CW_j,UN_{i}\oplus TN_{CS}\}$ also cannot be calculated. Thus, A cannot calculate SK, where $SK=h(UN_i\oplus TN_{CS}\oplus CN_j)$. So, privileged insider cannot break our protocol.

5.3.2 TVD attacks

Suppose A can obtain the random number for any of the entities in $U_i$ and $S_j$. If A obtains the random number $UN_i$ in $U_i$ and uses the $\{UJ_i,UK_i\}$ transmitted over the public channel, it can calculate $h(TB_{i}\parallel t_i)=UJ_{i}\oplus UN_{i}$, $CSID_{j}=UK_{i}\oplus h(TB_{i}\parallel UN_{i}\parallel t_i)$. A can then calculate $\{h(TB_{i}\parallel t_i), CSID_j\}$, but it cannot calculate $UY_{i}$ and $CN_{j}\oplus TN_{CS}$. Finally, A cannot calculate $SK_j=h(CN_j\oplus TN_{CS}\oplus UN_i)$. When the attacker obtains the random number $CN_j$ in $S_j$, the method of obtaining SK is the same as above. Therefore, our protocol is secured against to temporary value disclosure (TVD) attacks.

5.3.3 User impersonation attacks

Suppose A intercept message $M_1=\{UH_i,UJ_i,UK_i,RID_i,TS_i\}$, $M_2=\{ UH_{i},UJ_{i},UK_{i},CL_{j},CM_{j},RID_i,RSID_{j},TS_{j}\}$, $M_3=\{ TP_{CS},TR_{CS},TQ_{CS},TV_{CS}\}$, $M_4=\{TP_{CS },TQ_{CS}\}$. Because A cannot get the private value $CSID_j$, $UN_i$ and $TB_i$, so A cannot calculate the correct validation value $UH_i$, where $UH_i=h(RID_{i}\parallel CSID_{j}\parallel UN_{i}\parallel TB_{i})$. Consequently, our protocol can withstand user impersonation attacks.

5.3.4 OPG attacks

Suppose A can get the data ${\{UC_{i},UE_{i},UF_{i},UG_{i},h(.)}\}$ stored in SC and try to guess the password $UPW_i$ for $U_i$. Because A cannot obtain the biometric information $BIO_i$ of $U_i$, A cannot correctly calculate $UE_i$, where $UE_{i}=h(UID_{i}\parallel UA_{i})$ and $UA_{i}=UPW_{i}\oplus h(BIO_{i})$. Consequently, our protocol can resist offline password guessing (OPG) attacks.

5.3.5 Replay attacks

Assume that A can intercept $\{M_1, M_2, M_3, M_4\}$ over the public channel. If A resends all the messages from the previous round, our protocol checks the validity of the current timestamp. If the timestamp is invalid, the session will terminate. Consequently, our protocol is immune to replay attacks.

5.3.6 Anonymity and untraceability

We use hash operation and random value to hide $UID_i$ and $CSID_j$. During authentication, only the pseudo-identity $RID_i$ or $RSID_j$ is used to ensure the anonymity of $U_i$ and $S_j$. In addition, random numbers are differently used in each session, which also ensures that each entity is not traceable. Therefore, our protocol can ensure that entities are anonymity and untraceability.

5.4 Security and performance comparison

In this section, we will compare our protocol with five existing interrelated protocols [43, 45, 47,48,49] in terms of security and performance.

5.4.1 Security comparison

In terms of security comparison, the “$\checkmark$” means that the protocol can resist such attacks, while the “$\times$” means that it suffered from such attacks. In Table 4, it can be seen that Zhou et al.’s protocol [43] is insecure. Martinez-Pelaez et al.’ protocol [45] is susceptible to reply attacks as well as cannot achieve mutual authentication and anonymity. Kang et al.’s protocol [47] is susceptible to OPG attacks. Huang et al.’s protocol [49] cannot withstand privileged insider and TVD attacks. Our protocol and Wu et al.’s protocol [48] can withstand all attacks.

Table 4 The comparison of security

Table 5 Configuration and running time of equipment

Table 6 The comparisons of computational costs

5.4.2 Performance comparison

We only evaluate the computational and communication costs in the authentication and login phase. Our protocol performs only two operations: hash function and $\oplus$ operation. Due to the low cost of $\oplus$ and || calculation, they are usually ignored in the computational process. In addition, we carried out simulation experiments to estimate the cost of the compared protocols. We use MI8 to simulate $U_i$, Lenovo laptops to simulate $S_j$, and Lenovo desktops to simulate TCS. The specific configuration and operation time of the equipment used in the simulation experiments are shown in Table  5, where the operation time is the average of 30 operations for each piece of equipment.

The computational cost results of different protocols are shown in Table  6. We can see that Martinez-Pelaez et al. [45] used symmetric encryption and decryption in the designed protocol, which has the highest computational cost. The computational cost of Wu et al.’s protocol [48] is lower than their protocol [45]. Since we add additional steps to enhance the security, the cost of our protocol is higher than both protocols [47] and [49].

Table 7 The comparisons of communicational costs

Fig. 7

Comparisons of communication cost

In terms of communication cost, we assume that |T|, |ID|, |R|, |H|, |E| are 32, 160, 160, 256, 256 bits, respectively. Four rounds of messages are transmitted in our protocol, $M_1={\{UH_i,UJ_i,UK_i,RID_i,TS_i}\}$, $M_2=\{UH_i,UJ_i,UK_i,CL_j,CM_j,RID_i,RSID_j,TS_j\}$, $M_3=\{TP_{CS},TR_{CS},TQ_{CS},TV_{CS}\}$, $M_4={\{TP_{CS},TQ_{CS}}\}$, where $\{UH_i,CM_{j},TQ_{CS},TV_{CS}\}$ belongs to hash value, ${\{TS_i,TS_{j}}\}$ belongs to timestamp, ${\{RID_i, RSID_j}\}$ belongs to identity, and ${\{UJ_i,UK_i,CL_{j},TP_{CS},TR_{CS}}\}$ belongs to random number. Thus, the communication cost of our protocol is $2|T|+3|ID|+8|R|+6|H|=$ 3232 bits. Similarly, the communication cost in [43] is $3|ID|+15|R|+6|H|=$ 4416 bits, the communication cost in [45] is $3|T|+3|ID|+14|R|+|H|+6|E|=$ 4608 bits, the communication cost in [47] is $3|T|+3|ID|+10|R|+6|H|=$ 3712 bits, the communication cost in [48] is $3|ID|+15|R|+7|H|=$ 4672 bits, the communication cost in [49] is $3|T|+3|ID|+8|R|+6|H|=$ 3392 bits. The results are listed in Table 7 and depicted in Fig. 7. It is obvious that Wu et al.’s protocol [48] has the highest cost, followed by these protocols [43, 45, 47,48,49] and ours. In other words, our protocol has the lowest cost in communication.

In terms of security, we mainly list several common attacks, privileged insider, TVD, user impersonation, OPG, and replay attacks, and security requirements, PFS, mutual authentication, and anonymity. As shown in Table 4, we can see that only [48] and our protocol are secure. In another aspect, as shown in Tables 6, 7, and Fig. 7, the computational and communicational costs of [48] are higher than our protocol even if it is secure. Though the computational cost of our protocol is higher than the two protocols [47, 49]. However, they cannot resist some attacks. Overall, our protocol is the best authentication protocol with security and efficiency.

6 Conclusion

In this paper, we first summarize the importance of IoT-enabled devices in cloud environments and review the currently proposed AKA protocols related to these environments. Then, we have pointed Huang et al.’s protocol is insecure against privileged insider and TVD attacks. In order to solve the two security weaknesses, we have proposed an enhanced authentication protocol. Security analysis and comparisons are made to provide evidence to show our improvement is best currently.