Secure Three-Factor Authentication Protocol for Multi-Gateway IoT Environments

Abstract

Internet of Things (IoT) environments such as smart homes, smart factories, and smart buildings have become a part of our lives. The services of IoT environments are provided through wireless networks to legal users. However, the wireless network is an open channel, which is insecure to attacks from adversaries such as replay attacks, impersonation attacks, and invasions of privacy. To provide secure IoT services to users, mutual authentication protocols have attracted much attention as consequential security issues, and numerous protocols have been studied. In 2017, Bae et al. presented a smartcard-based two-factor authentication protocol for multi-gateway IoT environments. However, we point out that Bae et al.’s protocol is vulnerable to user impersonation attacks, gateway spoofing attacks, and session key disclosure, and cannot provide a mutual authentication. In addition, we propose a three-factor mutual authentication protocol for multi-gateway IoT environments to resolve these security weaknesses. Then, we use Burrows–Abadi–Needham (BAN) logic to prove that the proposed protocol achieves secure mutual authentication, and we use the Automated Validation of Internet Security Protocols and Applications (AVISPA) tool to analyze a formal security verification. In conclusion, our proposed protocol is secure and applicable in multi-gateway IoT environments.

1. Introduction

Internet of Things (IoT) provides numerous types of services through the internet to exchange data among sensors, embedded systems, and mobile devices. In recent years, IoT environments such as smart buildings, smart factories, smart homes, and smart offices are rapidly becoming a part of our life. A typical IoT architecture consists of heterogeneous micro devices and collects various types of information in real time. However, this is not efficient for practical IoT systems because the communication and computation cost can be increased when the size of IoT networks and the distance between participants are expanded [1,2]. The gateway nodes are deployed to enhance the performance, which provides the ability to communicate with each other efficiently. In a multi-gateway IoT environment, many gateway nodes are deployed and it can process the capability of large-scale IoT networks. IoT environments are also vulnerable to various attacks due to the nature of the open communication channel. Malicious attackers may attempt to insert, delete, and modify the data to obtain users’ sensitive information and masquerade as valid users. Much research has been done to resolve security problems in IoT environments. Secure mutual authentication is a primitive and essential method to provide secure communication and numerous secure mutual authentication protocols for IoT have been presented to provide various security features [2,3,4,5,6,7,8,9,10,11,12,13,14,15,16].

In 2017, Bae et al. [15] proposed a smartcard-based secure authentication protocol in multi-gateway IoT environments to reduce the computational and communication cost. However, we demonstrate that Bae et al.’s protocol is vulnerable to user impersonation, gateway spoofing, and trace and session key disclosure attacks, and does not provide anonymity and a secure mutual authentication. Then, we propose a three-factor authentication protocol that is based on the biometric information of the user, for IoT environments. To analyze the security aspects, we perform an informal security analysis and use Burrows–Abadi–Needham (BAN) logic. Furthermore, we perform a formal security verification using Automated Validation of Internet Security Protocols and Applications (AVISPA) software to check that our protocol can resist man-in-the-middle attacks and replay attacks. We compare the computation cost and security features of our proposed protocol with those of related existing protocols.

The remainder of this paper is as follows. In Section 2 and Section 3, we introduce related works and our preliminary details. In Section 4 and Section 5, we review Bae et al.’s protocol and cryptanalyze its security flaws. Then, we propose a secure three-factor mutual authentication protocol for multi-gateway IoT environments in Section 6. In Section 7, we prove that our proposed protocol provides a secure mutual authentication using BAN logic. We also perform the AVISPA simulation as a formal security verification and compare the computation cost and security properties with related protocols in Section 8 and Section 9. Finally, we conclude with the results of this paper in Section 10.

2. Related Works

Various authentication protocols in single server environments have been proposed [3,4,5]. In 2010, Wu et al. [3] presented a novel authentication protocol for the telecare medical information system (TMIS). Their protocol provides a guarantee to legitimate users. However, Debiao et al. [6] demonstrated that Wu et al.’s protocol cannot withstand several attacks such as impersonation, replay, or man-in-the-middle attacks. Debiao et al. proposed a more safe and efficient remote authentication protocol for TMIS. In 2013, Chang et al. proposed a secure authentication protocol that provided users privacy. But, in 2103, Das et al. [7] showed that their protocol cannot provide several security features and proper authentication. Furthermore, these authentication protocols are not suitable for distributed systems that consist of multiple servers, such as IoT environments, because the users who want to access the IoT services have to know as many identities and passwords as the number of servers [8,9]. In addition, the physical performance of a single server has limitations [17], and IoT environments are resource-constrained. Therefore, multi-gateway (multi-server) IoT environments are more efficient and useful than the traditional IoT structure [1,2,10,13,14,15,16].

In 2014, Turkanovic et al. [5] presented an authentication protocol for IoT environments. However, in 2016, Amin and Biswas [10] pointed out that Turkanovic et al.’s protocol does not withstand several attacks such as offline identity and password guessing, impersonation, and stolen smartcard attacks. They also demonstrated that Turkanovic et al.’s protocol has an inefficient authentication phase. Then, Amin and Biswas proposed an authentication protocol for multi-gateway wireless sensor networks. In 2017, Wu et al. [1] proved that Amin and Biswas’s protocol does not resist sensor capture, offline guessing, session key disclosure, impersonation, and desynchronization attacks. They also proved that Amind and Biswas’s protocol does not withstand user tracking attacks and does not achieve mutual authentication. Then, Wu et al. proposed a mutual authentication and key agreement protocol for multi-gateway wireless sensor network in IoT. In the same year, Srinivas et al. [13] also proved that Amin and Biswas’s protocol has security flaws. Srinivas et al. pointed out that sensor devices have low power, limited memory, and limited battery. Thereafter, Srinivas et al. proposed a more secure and efficient remote user authentication protocol for multi-gateway wireless sensor networks that are suitable for IoT environments.

In 2016, Das et al. [10] presented a three-factor multi-gateway-based user authentication protocol for wireless sensor networks. Das et al. suggested the multi-gateway environment for wireless sensor networks because the generalized wireless sensor networks can bring a lot of overhead to the gateway and have more power consumption than multi-gateway-based wireless sensor networks. They demonstrated that their protocol can withstand attacks such as sensor capture, privileged-insider, offline password guessing, and impersonation attacks. However, Wu et al. [1] pointed out that Das et al.’s protocol does not resist user tracking attacks and does not have a same session key for all three participants.

In 2018, Wu et al. [14] proposed an authentication protocol for healthcare systems in multi-gateway wireless medical sensor networks. Their protocol prevents malicious attacks such as patient tracking, insider, and offline guessing attacks. Wu et al. demonstrated that multi-gateway environments are suitable for collecting patients’ health data through wireless health sensors because the gateway in each area collects the information of patients in the area and then sends it to the doctor. They also demonstrated that their protocol is suitable for transferring data with low time and communication costs.

In 2017, Bae et al. [15] proposed a smartcard-based secure authentication protocol in multi-gateway IoT environments to reduce the computational and communication cost. However, their protocol does not resist impersonation, gateway spoofing, traceability, and session key disclosure attacks and does not guarantee secure mutual authentication and anonymity.

3. Preliminaries

In this section, we introduce a threat model for cryptanalyzing Bae et al.’s protocol, the fuzzy extraction that we use for the cryptographic system in our authentication protocol, and the system model of our protocol in multi-gateway IoT environments. Finally, we present the notations used in this paper.

3.1. Threat Model

We adopt the Dolev–Yao (DY) threat model [18] to analyze Bae et al.’s protocol and our proposed protocol. This model is popularly applied to estimate security. The general assumptions of the DY threat model are as below:

• An attacker can eavesdrop, delete, modify, or insert the transmitted messages via an insecure channel.
• An attacker can steal the smartcard or use a lost smartcard to extract the sensitive information stored in the smartcard [19].
• An attacker can perform various attacks such as trace, impersonation, smartcard lost, man-in-the-middle, replay attacks, and so on.

3.2. Fuzzy Extraction

We briefly show a description of the fuzzy extractor [20] that can extract key information from the given biometric data of users. Biometric information is weak to noises and it is hard to reproduce the actual biometrics from biometric templete in common practice. Moreover, the hash function is sensitized to input, so completely different outputs may come out. Because of these problems, we use the fuzzy extractor method [21,22], which is a type of key generating designed to convert noisy data to public information and a secret random string. The fuzzy extractor restores the original biometric information for noisy biometric data using public help information. The algorithms of the fuzzy extractor are as follows:

• $Generate\left(BI{O}_i\right)=<R_i,P_i>$. This algorithm is for generating key information. It uses biometric data $BI{O}_i$ as an input and then outputs secret key data $R_i$, which is a uniformly random string, and a public reproduction $P_i$ as a helper string.
• $Reproduce(BI{O}_i^{{}^{\prime }},P_i)=R_i$. This algorithm reproduces the secret data $R_i$. The inputs of this algorithm are a noisy biometric $BI{O}_i^{{}^{\prime }}$ and $P_i$. The algorithm reproduces the secret biometric key $R_i$. To recover the same $R_i$, the metric space distance between $BI{O}_i$ and $BI{O}_i^{{}^{\prime }}$ should be within a given error tolerance.

3.3. System Model

We introduce a system model of with our proposed protocol for multi-gateway IoT environments. The model consists of three entities: Users, Gateways, and a Control Server. The multi-gateway IoT system model is illustrated in Figure 1.

• Users: A user who wants to use the IoT service receives a smartcard from the control server to access the multi-gateway. After registration, login, and authentication, the user has access to use the IoT service. The users’ smartcard can be lost or stolen by an attacker.
• Gateways: The gateways consist of IoT environments such as smart homes, smart buildings, smart offices, and gateways. We assume that the gateway and IoT environments are connected in advance by a wireless network through a secure authentication. The performance of the gateways is approximately the performance of the server computer.
• Control Server: The control server is a trusted authentication server with sufficient computation power to compute complicated hash and exclusive functions or store security parameters. The control server stores the identities of the legitimate gateways in advance, and we assume that an attacker can never attack the control server.

3.4. Notations

Table 1. Notations.

Notations	Meanings
$U_i$	i-th user
$S_j$	j-th server
$CS$	Control server
$I{D}_i$	Identity of $U_i$
$SI{D}_j$	Identity of $S_j$
$P{W}_i$	Password of $U_i$
x	Master secret key chosen by $CS$
$Ts$	Timestamp
$N_{i1}$	Random number generated by $U_i$’s smartcard
$N_{i2}$	Random number generated by $S_j$
$N_{i3}$	Random number generated by $CS$
$SK$	Common session key shared among $U_i$, $S_j$, and $CS$
$h(*)$	Collision-resistant one-way hash function

shows the notations used in this paper.

4. Review of Bae et al.’s Protocol

In this section, we overview Bae et al.’s authentication protocol in multi-gateway IoT environments, which consists of three phases: user and server registration phase, user login and authentication phase, and password update phase. In Bae et al.’s protocol, they assumed that the authentication server $CS$ is trusted.

4.1. Registration Phase

If a new user $U_i$ or server $S_j$ requests registration to the authentication server $CS$, $CS$ issues the smartcard to $U_i$ and sends the necessary value to $S_j$. This phase and verifier table is shown in Figure 2 and

Table 2. The verifier table.

User-Verifier	Anonymity Value	Status-Bit
$Userinfo{r}_1$	$U_1$	$0/1$
$Userinfo{r}_2$	$U_2$	$0/1$
$\dots$	$\dots$	$\dots$
$Userinfo{r}_i$	$U_i$	$0/1$

, respectively, and the details are as follows.

Step 1:

$S_j$ requests registration to the $CS$. $S_j$ sends its identity $SI{D}_j$ to $CS$ through a secure channel, then $CS$ computes $Serinfo{r}_j$ and sends this to $S_j$.

Step 2:

$U_i$ chooses the $I{D}_i$, and $P{W}_i$, computes $EncPas{s}_i=h(I{D}_i\Vert h\left(P{W}_i\right))$ and sends the message $(I{D}_i,EncPas{s}_i)$ and $UI{D}_i$, which is an anonymity value of $U_i$, to $CS$ through a closed channel.

Step 3:

$CS$ receives the message from $U_i$. $CS$ computes the secret information value $Userinfo{r}_i=h(EncsPas{s}_i\Vert x)$, stores $\{UI{D}_i,Userinfo{r}_i,EncPas{s}_i,h(*),h\left(x\right)\}$ in the smartcard, and stores $Userinfo{r}_i$, $UI{D}_i$ and $statusbit$ in the verifier table. Then, $CS$ issues the smartcard to $U_i$.

4.2. Login and Authentication Phase

User $U_i$ must send a login request message to $S_j$ to use the service of server $S_j$. After receiving a request message, $S_j$ sends a login request message to control server $CS$. This phase is illustrated in Figure 3 and the following details.

Step 1:

$U_i$ inputs his/her $I{D}_i$ and $P{W}_i$ and inputs the smartcard into a smartcard reader. The smartcard computes $EncPas{s}_i^{{}^{\prime }}=h(I{D}_i\Vert h\left(P{W}_i\right))$. Then, the smartcard checks whether $EncPas{s}_i\stackrel{?}{=}EncPas{s}_i^{{}^{\prime }}$. If it is equal, $U_i$ generates a random number $N_{i1}$ and computes $A_i=Userinfo{r}_i\oplus h\left(x\right)\oplus N_{i1}$, $Ver{u}_i=h(h\left(x\right)\Vert N_{i1})$. Then, $U_i$ generates $Ts$ to prevent a replay attack. Finally, $U_i$ sends the login request message $\{UI{D}_i,A_i,Ver{u}_i,Ts\}$ to $S_j$ through a secure channel.

Step 2:

If $S_j$ receives the login request message, $S_j$ generates a random number $N_{i2}$ and computes $B_i=Serinfo{r}_j\oplus N_{i2}$, $Ver{s}_i=h\left(h\right(SI{D}_j\Vert x)\Vert N_{i2})$. Then, $S_j$ sends the login request message $\{UI{D}_i,A_i,Ver{u}_i,B_i,Ver{s}_i,SI{D}_j,Ts\}$ to $CS$ through an open channel.

Step 3:

After $CS$ receives the login request message from $S_j$, $CS$ computes $T{s}^{{}^{\prime }}=Ts+1$ and checks $\mathsf{\Delta }Ts\ge T{s}^{{}^{\prime }}-Ts$ to see whether the login request message is legitimate. If it is valid, $CS$ computes $Serinfo{r}_j^{{}^{\prime }}=h(SI{D}_j\Vert x)$, $N_{i2}^{{}^{\prime }}=Serinfo{r}_i^{{}^{\prime }}\oplus B_i$, $Ver{s}_i^{{}^{\prime }}=h\left(h\right(SI{D}_j\Vert x)\Vert N_{i2}^{{}^{\prime }})$. Then $CS$ compares $Ver{s}_i\stackrel{?}{=}Ver{s}_i^{{}^{\prime }}$ to check that the message from $S_j$ is valid. If it is equal, $CS$ retrieves $Userinfo{r}_i$ from the verifier table using $UI{D}_i$ from the login request message. Then, $CS$ computes $N_{i1}^{{}^{\prime }}=Userinfo{r}_i\oplus h\left(x\right)\oplus A_i$, $Ver{u}_i^{{}^{\prime }}=h(h\left(x\right)\Vert N_{i1}^{{}^{\prime }})$. If $Ver{u}_i\stackrel{?}{=}Ver{u}_i^{{}^{\prime }}$ is correct, $CS$ selects a random number $N_{i3}$ and generates a session key $S{K}_i=h\left(h\right(A_i\Vert h\left(x\right))\oplus h(N_{i1}\oplus N_{i2}\oplus N_{i3}))$. $CS$ generates time stamp $Ts$ and computes $C_i=N_{i1}\oplus N_{i3}\oplus h(SI{D}_j\oplus N_{i2})$, $D_i=h(A_i\Vert h\left(x\right))\oplus h(SI{D}_j\oplus N_{i2})$, $E_i=N_{i2}\oplus N_{i3}\oplus h(A_i\Vert h\left(x\right))$. Finally, $CS$ sends an authentication message $\{C_i,D_i,E_i,Ts\}$ to $S_j$.

Step 4:

After $S_j$ receives the message from $CS$, $S_j$ computes ${(N_{i1}\oplus N_{i3})}^{{}^{\prime }}=C_i\oplus h(SI{D}_j\oplus N_{i2})$, $h(A_i{\left|\right|h\left(x\right))}^{{}^{\prime }}=D_i\oplus h(SI{D}_j\oplus N_{i2})$. $S_j$ generates a session key $S{K}^{{}^{\prime }}=h\left(h\right(A_i{\left|\right|h\left(x\right))}^{{}^{\prime }}\oplus h(N_{i1}\oplus N_{i2}\oplus N_{i3}){)}^{{}^{\prime }}$. Then, $S_j$ computes $E_i=(N_{i2}\oplus N_{i3})\oplus h(A_i\Vert h\left(x\right))$ and sends an authentication message $\{E_i,Ts\}$ to $U_i$.

Step 5:

After receiving the message from $S_j$, $U_i$ computes $T{s}^{{}^{\prime }}=Ts+1$ and checks whether $\mathsf{\Delta }Ts\ge T{s}^{{}^{\prime }}-Ts$. If it is correct, $U_i$ computes ${(N_{i2}\oplus N_{i3})}^{{}^{\prime }}=E_i\oplus h(A_i\Vert h\left(x\right))$ and generates a session key $S{K}^{{}^{\prime \prime }}=h\left(h\right(A_i\Vert h\left(x\right))\oplus h(N_{i1}\oplus N_{i2}\oplus N_{i3}){)}^{{}^{\prime }}$. Therefore, $U_i$, $S_j$, and $CS$ generate the same session key, so they can perform the authentication.

4.3. Password Change Phase

If $U_i$ wants to change his/her password $P{W}_i$ to a new password $P{W}_i^{new}$, the password change phase is performed. This phase is illustrated in Figure 4 and is described as follows.

Step 1:

The $U_i$ inserts his/her smartcard into a card reader and inputs $I{D}_i$ and $P{W}_i$. Then, $U_i$ sends the $\{I{D}_i,P{W}_i\}$ to the smartcard reader through the closed channel.

Step 2:

After receiving the values from $U_i$, the smartcard computes $EncPas{s}_i=h(I{D}_i\Vert h\left(P{W}_i\right))$, $Userinfo{r}_i^{{}^{\prime }}=h(EncPas{s}_i\Vert x)$. The smartcard verifies whether $Userinfo{r}_i^{{}^{\prime }}\stackrel{?}{=}Userinfo{r}_i$. If it is equal, the smartcard requests a new password.

Step 3:

$U_i$ inputs a new password $P{W}_i^{new}$ and generates $EncPas{s}_i^{new}=h(I{D}_i\Vert h\left(P{W}_i^{new}\right))$. Then, $U_i$ inputs $EncPas{s}_i^{new}$ into the smartcard.

Step 4:

The smartcard computes $Userinfo{r}_i^{new}=h(EncPas{s}_i^{new}\Vert x)$ by using $EncPas{s}_i^{new}$. The smartcard updates $Userinfo{r}_i$ to $Userinfo{r}_i^{new}$ and replaces $Userinfo{r}_i$. Finally, the user $U_i$ changes his/her password.

5. Cryptanalysis of Bae et al.’s Protocol

We analyze the security flaws of Bae et al.’s protocol in this section. Bae et al. asserted that their proposed protocol can prevent various attacks such as user impersonation, server spoofing, and session key disclosure attacks. However, we demonstrate that their protocol does not prevent the following attacks.

5.1. User Impersonation Attack

If an attacker $U_a$ attempts to impersonate an authorized user $U_i$, $U_a$ must successfully compute a login request message $\{UI{D}_i,A_i,Ver{u}_i,Ts\}$. According to Section 3.1, we can assume that $U_a$ extracts the values $\{UI{D}_i,Userinfo{r}_i,EncPas{s}_i,h\left(x\right)\}$ from the smartcard of $U_i$ and obtains the transmitted messages over a public channel. After that, $U_a$ can impersonate the user in the following steps.

Step 1:

$U_a$ obtains $\{Userinfo{r}_i,h\left(x\right)\}$, $\{A_i,Ts\}$ from the smartcard of $U_i$ and the previous session, respectively.

Step 2:

$U_a$ computes $N_{i1}=A_i\oplus Userinfo{r}_i\oplus h\left(x\right)$ and obtains a random nonce $N_{i1}$. Then $U_a$ computes $Ver{u}_i=h(h\left(x\right)\Vert N_{i1})$.

Step 3:

$U_a$ computes $A_i=Userinfo{r}_a\oplus h\left(x\right)\oplus N_{a1}$, $Ver{u}_a=h(h\left(x\right)\Vert N_{a1})$. Finally, $U_a$ can generate a login request message $\{UI{D}_i,A_i,Ver{u}_a,Ts\}$ successfully.

5.2. Server Spoofing Attack

To obtain the sensitive information of a user, an attacker attempts to impersonate the server. Bae et al. asserted that their protocol can withstand server spoofing attacks. However, we analyze that their protocol does not resist server spoofing. First, an attacker $U_a$ obtains message $\{E_i,Ts\}$ and extracts the information $h\left(x\right)$ from the smartcard of an authorized user. Then, $U_a$ can impersonate the server by generating authentication messages in the following steps.

Step 1:

$U_a$ obtains transmitted messages $\{E_i,Ts\}$ in the previous session and extracts $h\left(x\right)$ from the smartcard of an authorized user.

Step 2:

$U_a$ computes $h(A_i\Vert h\left(x\right))$ and obtains $(N_{i2}\oplus N_{i3})$. After that, $U_a$ computes $E_i=(N_{i2}\oplus N_{i3})\oplus h(A_i\Vert h\left(x\right))$.

Step 3:

Finally, $U_a$ generates authentication messages $\{E_i,Ts\}$ successfully.

5.3. Session Key Disclosure Attack

Bae et al. demonstrated that their protocol can resist session key disclosure attacks because an attacker cannot compute the values $N_{i1}$, $N_{i2}$, and $N_{i3}$. Furthermore, Bae et al. claimed that the attacker cannot obtain $h\left(x\right)$ because the trusted party $CS$ generated $h\left(X\right)$. However, we demonstrate that the attacker can compute $N_{i1}$ and $N_{i2}\oplus N_{i3}$ and extract $h\left(x\right)$ in Section 5.1 and Section 5.2. Thus, the attacker can compute $S{K}_i=h\left(h\right(A_i\left|\right|h\left(x\right))\oplus h(N_{i1}\oplus N_{i2}\oplus N_{i3}))$. Therefore, Bae et al.’s protocol is vulnerable to session key disclosure attacks.

5.4. Mutual Authentication

In Bae et al.’s protocol, $CS$ computes $Ver{s}_i^{{}^{\prime }}$ and $Ver{u}_i^{{}^{\prime }}$ to authenticate legitimate $U_i$ and $S_j$. However, $CS$ cannot generate authentication messages for $U_i$ and $S_j$. Thus, $U_i$ and $S_j$ receive the message from $CS$, but they cannot trust the messages because they cannot check whether the attacker sends the message. Therefore, Bae et al.’s protocol does not achieve mutual authentication.

6. A Secure Three-Factor Mutual Authentication Protocol

In this section, we propose a three-factor mutual authentication protocol for multi-gateway IoT environments according to Section 3.3. The proposed protocol consists of three phases: users and gateways registration, login and authentication, and password update.

6.1. Registration Phase

First, a gateway $G_j$ must register with control server $CS$ to provide their services to users. Then, a new user $U_i$ first accesses the control server, and he/she must register with $CS$. The detailed steps are illustrated in Figure 5 and described as follows.

Step 1:

$G_j$ requests registration to the $CS$. $G_j$ selects $GI{D}_j$ and sends the value to $CS$ through a secure channel, then $CS$ computes $PI{D}_j=h(GI{D}_j\Vert h(x\Vert y))$ and sends $PI{D}_j$ to $G_j$ via a secure channel. $G_j$ stores $PI{D}_j$ in itself.

Step 2:

$U_i$ chooses the his/her identification $I{D}_i$ and password $P{W}_i$ and imprints biometrics $BI{O}_i$. Then $U_i$ generates a random number $a_i$, computes $<R_i,P_i>=Gen\left(BI{O}_i\right)$, $HIDi=h(I{D}_i\Vert a_i))$, which is an anonymity value of $U_i$, and $HP{W}_i=h(I{D}_i\Vert P{W}_i\Vert a_i)$, and sends the message $\{HI{D}_i,HP{W}_i,a_i\}$ to $CS$ through closed channel.

Step 3:

After $CS$ receives the message from $U_i$, $CS$ computes the secret information value $U{I}_i=h(HI{D}_i\Vert a_i\Vert x)$, $A_i=U{I}_i\oplus h\left(HP{W}_i\right)$, $B_i=h(U{I}_i\Vert A_i)$, and $X_i=h(U{I}_i\Vert x)$. Then, $CS$ stores $\{A_i,B_i,X_i,h(*)\}$ in the smartcard, and stores $U{I}_i$ with $HI{D}_i$ in the database. Then $CS$ issues the smartcard to $U_i$.

Step 4:

After receiving the smartcard from $CS$, $U_i$ computes $L_i=h(R_i\Vert P{W}_i)\oplus a_i$. Then $U_i$ inputs $L_i$ and $P_i$ in the smartcard.

6.2. Login and Authentication Phase

If a user $U_i$ wants to use the service of gateway $G_j$, $U_i$ must send a login request message to $G_j$. Then, $G_j$ sends a login request message to control server $CS$. The detailed steps are illustrated in Figure 6 and described as follows.

Step 1:

$U_i$ inserts the smartcard, his/her $I{D}_i$ and $P{W}_i$, and biometric $BI{O}_i$. The smartcard computes $R_i=Rep(BI{O}_i,Pi)$, $a_i=L_i\oplus h(R_i\Vert P{W}_i$), $HI{D}_i=h(I{D}_i\Vert a_i)$, $HP{W}_i=h(I{D}_i\Vert P{W}_i\Vert a_i)$, $U{I}_i=A_i\oplus h\left(HP{W}_i\right)$, $B_i^{*}=h(U{I}_i\Vert A_i)$. Then, the smartcard checks whether $B_i^{*}\stackrel{?}{=}{B}_i$ to check whether the user is legitimate. If it is valid, $U_i$ generates a random number $N_i$ and computes $C_i=U{I}_i\oplus N_i$, $V{U}_i=h(X_i\Vert N_i\Vert GI{D}_j)$. Finally, $U_i$ sends the login request message $\{HI{D}_i,C_i,V{U}_i\}$ to $G_j$ through a public channel.

Step 2:

After receiving a login request message, $G_j$ generates a random number $N_j$ and computes $D_i=G{I}_j\oplus N_j$, $V{S}_j=h(GI{D}_j\Vert G{I}_j\Vert N_j)$. Then, $G_j$ sends the login request message $\{HI{D}_i,C_i,PI{D}_j,D_i,V{S}_j\}$ to $CS$ via an open channel.

Step 3:

After $CS$ receives the login request message from $G_j$, $CS$ computes $G{I}_j=h(PI{D}_j\Vert h(x\Vert y))$, $N_j=D_i\oplus G{I}_j$ and compares $V{S}_j^{*}\stackrel{?}{=}V{S}_j$ to see whether $G_j$’s login request message is legitimate. If it is equal, $CS$ retrieves $U{I}_i$ from the verifier table using $HI{D}_i$ of the login request message. Then, $CS$ computes $X_i=h(U{I}_i\Vert x)$, $N_i=C_i\oplus U{I}_i,V{U}_i^{*}=h(X_i\Vert N_i\Vert GI{D}_j)$. Then $CS$ compares $V{U}_i^{*}\stackrel{?}{=}V{U}_i$ to check that the message from $U_i$ is valid. If it is valid, $CS$ generates a random number $N_c$ and computes $E_i=G{I}_j\oplus N_c$, $F_i=G{I}_j\oplus N_i$. $CS$ computes $M_{cg}=h(E_i\Vert G{I}_j\Vert N_c)$ to mutually authenticate with $G_j$ and $M_{cu}=h(X_i\Vert U{I}_i\Vert N_i)$ to authenticate with $U_i$ and generates a session key $SK=h(N_i\oplus h(N_j\Vert N_c\left)\right)$. $CS$ updates $HI{D}_i$ to $HI{D}_i^{new}=h(HI{D}_i\Vert N_i\Vert h(N_j\Vert N_c\left)\right)$ and $U{I}_i$ to $U{I}_i^{new}=h(HI{D}_i^{new}\Vert N_i\Vert U{I}_i)$, then replaces $HI{D}_i$ and $U{I}_i$. Finally, $CS$ sends the authentication message $\{M_{cg}$, $M_{cu}$, $E_i$, $F_i\}$ to $G_j$.

Step 4:

After $G_j$ receives the authentication message from $CS$, $G_j$ computes $N_c=E_i\oplus G{I}_j$, $M_{cg}^{*}=h(E_i\Vert G{I}_j\Vert N_c)$.Then, $G_j$ compares $M_{cg}^{*}\stackrel{?}{=}{M}_{cg}$ to verify whether the message from $CS$ is legitimate. If it is valid, $G_j$ computes $N_i=F_i\oplus G{I}_j$ and generates a session key $SK=h(N_i\oplus h(N_j\Vert N_c\left)\right)$. Then, $G_j$ computes $G_i=h(GI{D}_j\Vert N_i)$, $H_i=G_i\oplus h(N_j\Vert N_c)$ and sends the authentication message $\{H_i,M_{cu}\}$ to $U_i$.

Step 5:

After receiving the message from $G_j$, $U_i$ computes $M_{cu}^{*}=h(X_i\Vert U{I}_i\Vert N_i)$ and verifies whether $M_{cu}^{*}\stackrel{?}{=}{M}_{cu}$. If it is valid, $U_i$ computes $G_i^{*}=h(GI{D}_j\Vert N_i)$, $h(N_j\Vert N_c)=H_i\oplus G_i^{*}$ and generates a session key $SK=h(N_i\oplus h(N_j\Vert N_c\left)\right)$. Therefore, $U_i$, $S_j$, and $CS$ generate the same session key, so they can perform the authentication. $U_i$ updates $HI{D}_i$ to $HI{D}_i^{new}=h(HI{D}_i\Vert N_i\Vert h(N_j\Vert N_c\left)\right)$ and $U{I}_i$ to $U{I}_i^{new}=h(HI{D}_i^{new}\Vert N_i\Vert U{I}_i)$, then replaces $HI{D}_i$ and $U{I}_i$. The smartcard updates $A_i^{new}=U{I}_i^{new}\oplus h\left(HPW\right),B_i^{new}=h(U{I}_i^{new}\Vert A_i^{new})$, and $X_i^{new}=h(U{I}_i^{new}\Vert U{I}_i)$.

6.3. Password Change Phase

If $U_i$ wants to change his/her password, $U_i$ performs the password change phase without the help of $G_j$. The detailed steps of the password change phase are shown in Figure 7 and described as follows.

Step 1:

A legitimate user $U_i$ inserts the smartcard, his/her $I{D}_i$ and $P{W}_i$, and biometric $BI{O}_i$.

Step 2:

The smartcard computes $<R_i,P_i>=Gen\left(BI{O}_i\right)$, $a_i=L_i\oplus h(R_i\Vert P{W}_i$), $HP{W}_i=h(I{D}_i\Vert P{W}_i\Vert a_i)$, and $B_i^{*}=h(U{I}_i\Vert A_i)$. After that, the smartcard compares the $B_i^{*}$ with $B_i$ stored value. If it is equal, the smartcard requests a new password to $U_i$.

Step 3:

When $U_i$ receives the request message from smartcard, $U_i$ inputs a new password $P{W}_i^{new}$.

Step 4:

After receiving the new password from $U_i$, the smartcard computes $L_i^{new}=a_i\oplus h(R_i\Vert P{W}_i^{new})$, $HP{W}_i^{new}=h(I{D}_i\Vert P{W}_i^{new}\Vert a_i)$, $A_i^{new}=U{I}_i\oplus h\left(HP{W}_i^{new}\right)$, and $B_i^{new}=h(U{I}_i\Vert A_i^{new})$. Consequently, the smartcard updates the old information $\{A_i,B_i,L_i\}$ to new information $\{A_i^{new},B_i^{new},L_i^{new}\}$.

7. Security Analysis

We show that our proposed protocol can prevent various attacks by performing an informal analysis, as mentioned in Section 3.1. We analyze our protocol using Burrows–Abadi–Needham (BAN) logic to prove that our protocol can achieve secure mutual authentication.

7.1. Informal Security

To prove that our proposed protocol can prevent various attacks such as trace, smartcard lost, impersonation, off-line guessing, and session key disclosure attacks, we perform an informal security analysis. Additionally, we show that proposed protocol provides anonymity and a secure mutual authentication.

7.1.1. User Impersonation Attack

If a malicious attacker $U_a$ attempts to masquerade as a user $U_i$, $U_a$ can generate a login request message $\{HI{D}_i,C_i,V{U}_i\}$ and message $\{H_i,M_{cu}\}$. However, $U_a$ cannot compute $HI{D}_i$ because $U_a$ cannot extract a random number $a_i$ from $HI{D}_i$. $U_a$ cannot retrieve a random number $N_i$ because the attacker cannot know secret parameter $U{I}_i$. Thus, $U_a$ cannot compute $C_i,V{U}_i$ because $U_a$ cannot extract a random number $N_i$. Therefore, our protocol resists user impersonation attack.

7.1.2. Server Spoofing Attack

To impersonate the server, an attacker $U_a$ can generate an authentication message $\{H_i,M_{cu}\}$. However, $U_a$ cannot compute these because $U_a$ cannot know the random nonces $N_i,N_j,N_c$. Furthermore, if $U_a$ attempts to impersonate the gateway by using public parameter $GI{D}_j$, the control server compares it with the stored identities of the legitimate gateways in advance. Thus, our proposed protocol is secure against server spoofing attacks because $U_a$ cannot generate valid messages.

7.1.3. Smartcard Stolen Attack

We assume that an attacker $U_a$ can extract the values of the smartcard $\{A_i,B_i,X_i,L_i,h(*)\}$ according to Section 3.1. However, $U_a$ cannot obtain sensitive or useful information without the identity, password, and biometrics of the legitimate user because the values stored in the smartcard are safeguarded with a one-way hash function or an XOR operation of $I{D}_i,P{W}_i,HP{W}_i=h(I{D}_i\Vert P{W}_i\Vert a_i)$. Therefore, our protocol can prevent smartcard stolen attacks.

7.1.4. Trace Attack and Anonymity

In our protocol, an attacker $U_a$ cannot know the identity of the users and gateways. The user $U_i$ does not send a real identity $I{D}_i$ via the public channels. The user generates and sends a pseudonym identity $HI{D}_i=h(I{D}_i\Vert a_i)$. Because $HI{D}_i$ is a transmitted message via a public channel, $U_a$ can obtain this value. Therefore, $U_i$ updates it as $HI{D}_i^{new}=h(HI{D}_i\Vert N_i\Vert h(N_j\Vert N_c\left)\right)$ for every session to prevent the attack of $U_a$. The gateway uses $PI{D}_j$, which is generated in the registration phase, instead of $GI{D}_j$, so our protocol provides anonymity of users and gateways. In addition, the proposed protocol resists trace attacks because all messages are dynamic for every session.

7.1.5. Man-in-the-Middle Attack and Replay Attack

We assume that attacker $U_a$ knows the information transmitted via an insecure channel and information from the smartcard of $U_i$ to set up a secure channel with $G_j$. However, $U_a$ cannot generate a valid login request message, as mentioned. Furthermore, $U_a$ cannot impersonate user $U_i$ by resending the messages because the messages are refreshed with random numbers $N_i,N_j$, and $N_c$. Therefore, our proposed protocol prevents man-in-the-middle attacks and replay attacks.

7.1.6. Off-Line Password Guessing Attack

An attacker $U_a$ attempts to guess the password $P{W}_i$ of legitimate user $U_i$. If $U_a$ can guess the password, $U_a$ can compute a series of equations and compute several equations and the valid value with the guessed passwords. However, $U_a$ must know the unique biometrics of the user to compute equations. Therefore, it is impossible to guess the user’s password in our protocol.

7.1.7. Desynchronization Attack

For a desynchronization attack, an adversary disturbs the communication of the login and authentication request message. However, $CS$ uses $HI{D}_i$ to retrieve $U{I}_i$ after checking message from $G_j$, and $HI{D}_i$ updates $HI{D}_i^{new}$ after authentication of the request message. Furthermore, an attacker disturbs the response communication to desynchronize $HI{D}_i^{new}$. Even if the user cannot receive the response message, the user can generate and update $HI{D}_i^{new}$. Thus, our proposed protocol can resist desynchronization attacks.

7.1.8. Mutual Authentication

When control server $CS$ receives the login request message from gateway $G_j$, $CS$ computes $V{S}_j^{*}$ and $V{U}_i^{*}$ to authenticate user $U_i$ and $G_j$. If $V{S}_j$ and $V{S}_j^{*}$ are equal, $CS$ authenticates $G_j$. Furthermore, $CS$ retrieves $U_i$ from a database to an available $V{S}_j$. After that, $CS$ compares $V{U}_i$ and $V{U}_i^{*}$. If they are equal, $CS$ authenticates $U_i$. Then, $CS$ computes and sends the login response messages $M_{cg}$ and $M_{cu}$ to authenticate. After receiving $M_{cg}$ from $CS$, $G_j$ computes $M_{cg}^{*}$ and compares $M_{cg}^{*}$ and $M_{cg}$. If they are equal, $G_j$ authenticates $CS$. Finally, $U_i$ computes $M_{cu}^{*}$ and checks whether $M_{cu}^{*}\stackrel{?}{=}{M}_{cu}$. If it is valid, $U_i$ authenticates $CS$. Therefore, $U_i$, $G_j$, and $CS$ successfully mutually authenticate. An attacker cannot validate the message, as mentioned in Section 7.1.1 and Section 7.1.2. Moreover, the login request and response messages are refreshed for every session according to Section 7.1.4 and Section 7.1.5. Therefore, our proposed protocol provides secure mutual authentication.

7.2. Ban Logic

We perform a formal verification to check that our proposed protocol achieves a secure mutual authentication using BAN logic.

Table 3. Notations of Burrows–Abadi–Needham (BAN) logic.

Notations	Meaning
$P|\equiv X$	P believes the statement X
$\#X$	The statement X is fresh
$P⊲X$	P sees the statement X
$P|X$	P once said X
$P\Rightarrow X$	P controls the statement X
$<X{>}_Y$	Formula X is combined with formula Y
${\left\{X\right\}}_K$	Formula X is encrypted by the key K
$P\stackrel{K}{\leftrightarrow }Q$	P and Q communicate using K as the shared key
$SK$	Session key used in the current authentication session

presents the notation of BAN logic. We show the logical rules of BAN logic in Section 7.2.1. In the following sections, we show the goals, idealized forms, and assumptions of our proposed protocol. In Section 7.2.5, we show that our proposed protocol can provide mutual authentication among $U_i$, $G_j$, and $CS$. More details of BAN logic can be found in [23,24].

7.2.1. Rules of Ban Logic

We introduce rules of BAN logic as follows:

• Message meaning rule:

  $$\frac{P|\equiv P\stackrel{K}{\leftrightarrow }Q,P⊲{\left\{X\right\}}_K}{P\left|\equiv Q\right|\sim X}$$
• Nonce verification rule:

  $$\frac{P\left|\equiv \#\left(X\right),P\right|\equiv Q|\sim X}{P\left|\equiv Q\right|\equiv X}$$
• Jurisdiction rule:

  $$\frac{P\left|\equiv Q\right|⟹X,P\left|\equiv Q\right|\equiv X}{P|\equiv X}$$
• Freshness rule:

  $$\frac{P|\equiv \#(X)}{P|\equiv \#\left(X,Y\right)}$$
• Belief rule:

  $$\frac{P|\equiv \left(X,Y\right)}{P|\equiv X}$$

7.2.2. Goals

We present the following goals to prove that our protocol achieves secure mutual authentication:

Goal 1:

$G_j|\equiv CS|\equiv (N_c,N_i)$,

Goal 2:

$G_j|\equiv (N_c,N_i)$,

Goal 3:

$CS|\equiv G_j|\equiv (N_i,N_j)$,

Goal 4:

$CS|\equiv (N_i,N_j)$,

Goal 5:

$U_i|\equiv G_j|\equiv (N_c,N_i)$,

Goal 6:

$U_i|\equiv (N_j,N_c)$

7.2.3. Idealized Forms

$Ms{g}_1:$

$U_i\to G_j:{(HI{D}_i,N_i,x,GI{D}_j)}_{U{I}_i}$

$Ms{g}_2:$

$G_j\to CS:{(HI{D}_i,N_i,x,GI{D}_j,N_j)}_{G{I}_j}$

$Ms{g}_3:$

$CS\to G_j:{(N_c,N_i,U{I}_i,x)}_{G{I}_j}$

$Ms{g}_4:$

$G_j\to U_i:{(N_c,N_j,U{I}_i,GI{D}_j,x)}_{N_i}$

7.2.4. Assumptions

To achieve the BAN logic proof, we make the following assumptions about the initial state of our proposed protocol:

$A_1:$

$G_j|\equiv (U_i\stackrel{U{I}_i}{⟷}{G}_j)$

$A_2:$

$G_j|\equiv \#\left(N_i\right)$

$A_3:$

$CS|\equiv (G_j\stackrel{G{I}_j}{⟷}CS)$

$A_4:$

$CS|\equiv \#(N_j,N_i)$

$A_5:$

$G_j|\equiv (G_j\stackrel{G{I}_j}{⟷}CS)$

$A_6:$

$U_i|\equiv (U_i\stackrel{N_i}{⟷}{G}_j)$

$A_7:$

$U_i|\equiv \#(N_j)$

$A_8:$

$CS|\equiv G_j\Rightarrow (CS\stackrel{G{I}_j}{⟷}{G}_j)$

7.2.5. Proof Using Ban Logic

The following steps are the main proofs using BAN rules and assumptions:

Step 1:

According to $Ms{g}_1$, we can get

$$S_1:G_j⊲{(HI{D}_i,N_i,x,GI{D}_j)}_{U{I}_i}.$$

Step 2:

From $A_1$ and $S_1$, we apply the message meaning rule to obtain

$$S_2:G_j|\equiv U_i{(HI{D}_i,N_i,x,GI{D}_j)}_{U{I}_i}.$$

Step 3:

From $A_2$ and $S_2$, we apply the freshness rule to obtain

$$S_3:G_j|\equiv \#{(HI{D}_i,N_i,x,GI{D}_j)}_{U{I}_i}.$$

Step 4:

From $S_2$ and $S_3$, we apply the nonce verification rule to obtain

$$S_4:G_j|\equiv U_i\equiv {(HI{D}_i,N_i,x,GI{D}_j)}_{U{I}_i}.$$

Step 5:

From $S_4$, we apply the belief rule to obtain

$$S_5:G_j|\equiv U_i|\equiv {\left(N_i\right)}_{U{I}_i}.$$

Step 6:

According to $Ms{g}_2$, we can get

$$S_6:CS⊲{(HI{D}_i,N_i,x,GI{D}_j,N_j)}_{G{I}_j}.$$

Step 7:

From $A_3$ and $S_6$, we apply the message meaning rule to obtain

$$S_7:CS|\equiv G_j{(HI{D}_i,N_i,x,GI{D}_j,N_j)}_{G{I}_j}.$$

Step 8:

From $A_4$ and $S_7$, we apply the freshness rule to obtain

$$S_8:CS|\equiv \#{(HI{D}_i,N_i,x,GI{D}_j,N_j)}_{G{I}_j}.$$

Step 9:

From $S_7$ and $S_8$, we apply the nonce verification rule to obtain

$$S_9:CS|\equiv G_j|\equiv {(HI{D}_i,N_i,x,GI{D}_j,N_j)}_{G{I}_j}.$$

Step 10:

From $S_9$, we apply the belief rule to obtain

$$S_{10}:CS|\equiv G_j|\equiv {(N_i,N_j)}_{G{I}_j}.\mathbf{(}\mathbf{Goal}\mathbf{3}\mathbf{)}$$

Step 11:

According to $Ms{g}_2$, we can get

$$S_{11}:G_j⊲{(N_c,N_i,U{I}_i,x)}_{G{I}_j}.$$

Step 12:

From $A_5$ and $S_{11}$, we apply the message meaning rule to obtain

$$S_{12}:G_j|\equiv CS{(N_c,N_i,U{I}_i,x)}_{G{I}_j}.$$

Step 13:

From $A_6$ and $S_{12}$, we apply the freshness rule to obtain

$$S_{13}:G_j|\equiv \#{(N_c,N_i,U{I}_i,x)}_{G{I}_j}.$$

Step 14:

From $S_{12}$ and $S_{13}$, we apply the nonce verification rule to obtain

$$S_{14}:G_j|\equiv CS|\equiv {(N_c,N_i,U{I}_i,x)}_{G{I}_j}.$$

Step 15:

From $S_{14}$, we apply the belief rule to obtain

$$S_{15}:G_j|\equiv CS|\equiv {(N_c,N_i)}_{G{I}_j}.\mathbf{(}\mathbf{Goal}\mathbf{1}\mathbf{)}$$

Step 16:

According to $Ms{g}_4$, we can obtain

$$S_{16}:U_i⊲{(N_c,N_j,U{I}_i,GI{D}_j,x)}_{N_i}.$$

Step 17:

From $A_6$ and $S_{16}$, we apply the message meaning rule to obtain

$$S_{17}:U_i|\equiv G_j{(N_c,N_j,U{I}_i,GI{D}_j,x)}_{N_i}.$$

Step 18:

From $A_7$ and $S_{17}$, we apply the freshness rule to obtain

$$S_{18}:U_i|\equiv \#G_j{(N_c,N_j,U{I}_i,GI{D}_j,x)}_{N_i}.$$

Step 19:

From $S_{17}$ and $S_{18}$, we apply the nonce verification rule to obtain

$$S_{19}:U_i|\equiv G_j|\equiv {(N_c,N_j,U{I}_i,GI{D}_j,x)}_{N_i}.$$

Step 20:

From $S_{19}$, we apply the belief rule to obtain

$$S_{20}:U_i|\equiv G_j|\equiv {(N_c,N_j)}_{N_i}.\mathbf{(}\mathbf{Goal}\mathbf{5}\mathbf{)}$$

Step 21:

From $S_{10}$ and $A_8$, we apply the jurisdiction rule to obtain

$$S_{21}:CS|\equiv (N_i,N_j).\mathbf{(}\mathbf{Goal}\mathbf{4}\mathbf{)}$$

Step 22:

From $S_{15}$ and $A_9$, we apply the jurisdiction rule to obtain

$$S_{22}:G_j|\equiv (N_c,N_i).\mathbf{(}\mathbf{Goal}\mathbf{2}\mathbf{)}$$

Step 23:

From $S_{20}$ and $A_{10}$, we apply the jurisdiction rule to obtain

$$S_{23}:U_i|\equiv (N_c,N_i).\mathbf{(}\mathbf{Goal}\mathbf{6}\mathbf{)}$$

We show that the proposed protocol can provide secure mutual authentication between $U_i$, $G_j$, and $CS$ based on goals 1–6.

8. Formal Verification Using Avispa

We present a formal verification of our proposed protocol using the AVISPA tool based on the High-Level Protocol Specification Language (HLPSL) code [25]. AVISPA is one of the widely used verification tools to check that protocols are secure against man-in-the-middle attacks and replay attacks. Numerous studies have been simulated using the AVISPA tool [26,27,28]. We will shortly describe AVISPA and show the HLPSL specifications of our proposed protocol. Then, we will assert that the proposed protocol can resist replay and man-in-the-middle attacks through the results of the AVISPA simulation.

8.1. Description of Avispa

AVISPA performs security verification through four back-ends consisting of Constraint-Logic-based Attack Searcher (CL-AtSe) [29], On-the-Fly Model-Checker (OFMC) [30], Tree Automate-Based Protocol Analyzer (TA4SP), and SAT-Based Model-Checker (SATMC). HLPSL specification is translated into intermediate format (IF) by an hlpsl2if translator. IF is converted to the output format (OF), which is produced using the four back-ends as mentioned above. But usually, CL-Atse and OFMC are used for verification. AVISPA has several functions that are mentioned below for analyzing protocols. More details on AVISPA can be found in [31,32].

• $secret(A,id,B)$: $id$ denotes an information A that is only known to B.
• $witness(A,B,id,E)$: $id$ denotes a weakness authentication factor E that is used by A to authenticate B.
• $request(A,B,id,E)$: $id$ denotes a strong authentication factor. B requests A for E to authenticate.

8.2. Hlpsl Specifications of Our Protocol

Our protocol has three basic $roles$ which are denoted by entities that have been specified according to HLPSL: $UA$ denotes a user, $GA$ denotes a gateway, and $CS$ denotes a control server. The role of $session$ and $environments$ are shown in Figure 8. In the $session$, we describe participants. In $environments$, intruder knowledge is defined, and four secrecy goals and four authentication goals are described. The HLPSL specifications of role $UA$ are shown in Figure 9, and the details are as follows.

At transition 1, $UA$ starts the registration phase with a start message in state value 0 and then updates the state from 0 to 1. $UA$ sends the registration message $\{HI{D}_i,HP{W}_i,a\}$ to $CS$ through a closed channel. At transition 2, $UA$ receives the smartcard from $CS$, then it updates the state from 1 to 2. In state value 2, $UA$ generates the random number $N_i$, sends the login request message $\{HI{D}_i,C_i,V{U}_i\}$ to $GA$ via an insecure channel, and declares $witness(UA,CS,us\_cs\_ni,N_i)$, which means that $N_i$ denotes a weakness authentication factor. At transition 3, $UA$ receives the login response message from $GA$. After that, $UA$ changes the state value from 2 to 3, generates the session key, and declares $request(UA,CS,cs\_ua\_mcu,N_c)$. The specifications of role $GA$ and $CS$ are similar and shown in Figure 10 and Figure 11.

8.3. Results of Avispa Simulation

The results of AVISPA simulation through OFMC and CL-AtSe verification are shown in Figure 12. The OFMC and CL-AtSe back-ends check whether our proposed protocol can resist replay attacks and man-in-the-middle attacks. The OFMC verification shows that search time is 12 s for visiting 1040 nodes, and the CL-AtSe verification analyzes 3 states with 0.13 s to translate. Because the summary part of OFMC and CL-AtSe indicates that the protocol is SAFE, our proposed protocol is secure against replay and man-in-the-middle attacks.

9. Performance Analysis

In this section, we show the comparison of computation cost, communication cost, and security features among our proposed protocol and other IoT-related protocols.

9.1. Computation Cost

We compare the computational overhead between our proposed protocol and other related protocols. We define some notations for convenience of comparison.

• $T_{me}$: The times for modular exponential operation (≈0.522 s [33,34])
• $T_h$: The times for one-way hash operation (≈0.0005 s [33,34])
• $T_f$: The times for fuzzy extraction operation (≈0.063075 s [34,35])

Table 4. Computation cost of the login and authentication phase.

Protocols	User	Gateway	Control Server	Total Cost
Turkanovic et al. [5]	7$T_h$	5$T_h$	7$T_h$	19$T_h\left(0.0095s\right)$
Wu et al. [3]	2$T_{me}$ + 4$T_h$	-	1 $T_{me}$ + 4$T_h$	3$T_{me}$+ 8$T_h\left(1.57s\right)$
Amin and Biswas Case-1 [10]	7$T_h$	5$T_h$	8$T_h$	20$T_h\left(0.01s\right)$
Amin and Biswas Case-2 [10]	8$T_h$	5$T_h$	7$T_h$	20$T_h\left(0.01s\right)$
Bae et al. [15]	5$T_h$	6$T_h$	10$T_h$	21$T_h\left(0.0105s\right)$
Ours	1$T_f$+14$T_h$	5$T_h$	9$T_h$	1$T_f$+ 28$T_h\left(0.07707s\right)$

XOR operation is negligible compared to other operations.

shows the results of the comparison. In multi-gateway environments, it is important to reduce the computation cost of gateway nodes because the gateway nodes process a large amount of information. Although the total computation cost of our proposed protocol is higher than other related protocols, it is similar to [15] in terms of gateway nodes. Therefore, our proposed protocol is suitable for practical IoT environments.

9.2. Communication Cost

We have compared the communication overheads at the login and authentication phase of our proposed protocol and other related protocols in

Table 5. Communication cost.

Protocols	Communication Cost
Turkanovic et al. [5]	4000 bits
Wu et al. [3]	2368 bits
Amin and Biswas Case-1 [10]	2080 bits
Amin and Biswas Case-2 [10]	3520 bits
Bae et al. [15]	2720 bits
Ours	2400 bits

. We assume that the acknowledgment message and the one-way hash function, the timestamp, random number, and identity all are 160 bits. Additionally, we assume that the AES (Advanced Encryption Standard) key is 512 bits [33]. According to the results, our proposed protocol has more efficiency than other related protocols.

9.3. Security Properties

Table 6. Security properties.

Security Property	Turkanovic et al. [5]	Wu et al. [3]	Amin and Biswas [10]	Bae et al. [15]	Ours
User impersonation attack	x	x	o	x	o
Server spoofing attack	o	x	x	x	o
Smartcard stolen attack	x	x	x	x	o
Trace attack	x	x	x	x	o
Off-line password guessing attack	x	o	x	o	o
Replay attack	o	o	o	o	o
Man-in-the-middle attack	o	o	o	o	o
Desynchronization attack	-	-	x	-	o
Anonymity	x	x	x	o	o
Mutual authentication	x	x	o	x	o

x: does not prevent the property; o: prevents the property; -: does not concern the property.

shows the security comparisons among the proposed protocol and other related protocols based on IoT environment. Our proposed protocol can resist more attacks than other related protocols. Furthermore, our proposed protocol provides anonymity and achieves mutual authentication. Therefore, we demonstrate that the proposed protocol is more safe than other related protocols and satisfies the security requirements of IoT environments.

10. Conclusions

IoT is becoming a part of our life and helps people to easily communicate data and comfortably obtain mobile services. However, data scalability, unsolved security problems, and malicious attacks can limit the widespread extension of IoT services. The gateway nodes must process a large amount of information to provide IoT services to users. Thus, reducing the computation cost of gateways is a very important issue, and users and gateways should verify each other’s legitimacy with the aid of a control server to provide authorized and secure communication. In this paper, we demonstrated the security weaknesses of Bae et al.’s protocol. We showed that their protocol is vulnerable to user impersonation attacks, gateway spoofing attacks, session key disclosure attacks, offline password guessing attacks, and does not provide secure mutual authentication. Moreover, we proposed a multi-factor mutual authentication protocol for multi-gateway IoT environments with better security functionality than that of Bae et al.’s protocol. We also proved the security of the proposed protocol using BAN logic and the AVISPA tool.