Open AccessArticle

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

JoonYoung Lee

SungJin Yu

KiSung Park

YoHan Park

^2,*

and

YoungHo Park

^1,*

School of Electronics Engineering, Kyungpook National University, Daegu 41566, Korea

IT Conversions, Korea Nazarene University, Cheonan, Chungcheongnam-do 31172, Korea

Authors to whom correspondence should be addressed.

Sensors 2019, 19(10), 2358; https://doi.org/10.3390/s19102358

Submission received: 28 March 2019 / Revised: 18 May 2019 / Accepted: 20 May 2019 / Published: 22 May 2019

(This article belongs to the Special Issue Emerging IoT Technologies for Smart Environments)

Download

Browse Figures

Figure 1
System model of our protocol in multi-gateway IoT environments. "> Figure 2
Registration phase of Bae et al.’s protocol. "> Figure 3
Login and authentication phase of Bae et al.’s protocol. "> Figure 4
Password change phase of Bae et al.’s protocol. "> Figure 5
Registration phase of our proposed protocol. "> Figure 6
Login and authentication phase of our proposed protocol. "> Figure 7
Password change phase of our proposed protocol. "> Figure 8
Specification of session and environments. "> Figure 9
Specification of user. "> Figure 10
Specification of gateway. "> Figure 11
Specification of control server. "> Figure 12
The result of Automated Validation of Internet Security Protocols and Applications (AVISPA) simulation using OFMC and CL-AtSe. ">

Review Reports Versions Notes

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.

Keywords:

internet of things; multi-gateway; mutual authentication; cryptanalysis, BAN logic; AVISPA

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:

$G e n e r a t e (B I O_{i}) = < R_{i}, P_{i} >$ . This algorithm is for generating key information. It uses biometric data $B I 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.
$R e p r o d u c e (B I O_{i}^{^{'}}, P_{i}) = R_{i}$ . This algorithm reproduces the secret data $R_{i}$ . The inputs of this algorithm are a noisy biometric $B I O_{i}^{^{'}}$ and $P_{i}$ . The algorithm reproduces the secret biometric key $R_{i}$ . To recover the same $R_{i}$ , the metric space distance between $B I O_{i}$ and $B I O_{i}^{^{'}}$ 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 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

C S

is trusted.

4.1. Registration Phase

If a new user

U_{i}

or server

S_{j}

requests registration to the authentication server

C S

C S

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, respectively, and the details are as follows.

Step 1:: $S_{j}$ requests registration to the $C S$ . $S_{j}$ sends its identity $S I D_{j}$ to $C S$ through a secure channel, then $C S$ computes $S e r i n f o r_{j}$ and sends this to $S_{j}$ .
Step 2:: $U_{i}$ chooses the $I D_{i}$ , and $P W_{i}$ , computes $E n c P a s s_{i} = h (I D_{i} ‖ h (P W_{i}))$ and sends the message $(I D_{i}, E n c P a s s_{i})$ and $U I D_{i}$ , which is an anonymity value of $U_{i}$ , to $C S$ through a closed channel.
Step 3:: $C S$ receives the message from $U_{i}$ . $C S$ computes the secret information value $U s e r i n f o r_{i} = h (E n c s P a s s_{i} ‖ x)$ , stores ${U I D_{i}, U s e r i n f o r_{i}, E n c P a s s_{i}, h (*), h (x)}$ in the smartcard, and stores $U s e r i n f o r_{i}$ , $U I D_{i}$ and $s t a t u s b i t$ in the verifier table. Then, $C S$ 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

C S

. 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 $E n c P a s s_{i}^{^{'}} = h (I D_{i} ‖ h (P W_{i}))$ . Then, the smartcard checks whether $E n c P a s s_{i} \overset{?}{=} E n c P a s s_{i}^{^{'}}$ . If it is equal, $U_{i}$ generates a random number $N_{i 1}$ and computes $A_{i} = U s e r i n f o r_{i} \oplus h (x) \oplus N_{i 1}$ , $V e r u_{i} = h (h (x) ‖ N_{i 1})$ . Then, $U_{i}$ generates $T s$ to prevent a replay attack. Finally, $U_{i}$ sends the login request message ${U I D_{i}, A_{i}, V e r u_{i}, T s}$ to $S_{j}$ through a secure channel.
Step 2:: If $S_{j}$ receives the login request message, $S_{j}$ generates a random number $N_{i 2}$ and computes $B_{i} = S e r i n f o r_{j} \oplus N_{i 2}$ , $V e r s_{i} = h (h (S I D_{j} ‖ x) ‖ N_{i 2})$ . Then, $S_{j}$ sends the login request message ${U I D_{i}, A_{i}, V e r u_{i}, B_{i}, V e r s_{i}, S I D_{j}, T s}$ to $C S$ through an open channel.
Step 3:: After $C S$ receives the login request message from $S_{j}$ , $C S$ computes $T s^{^{'}} = T s + 1$ and checks $Δ T s \geq T s^{^{'}} - T s$ to see whether the login request message is legitimate. If it is valid, $C S$ computes $S e r i n f o r_{j}^{^{'}} = h (S I D_{j} ‖ x)$ , $N_{i 2}^{^{'}} = S e r i n f o r_{i}^{^{'}} \oplus B_{i}$ , $V e r s_{i}^{^{'}} = h (h (S I D_{j} ‖ x) ‖ N_{i 2}^{^{'}})$ . Then $C S$ compares $V e r s_{i} \overset{?}{=} V e r s_{i}^{^{'}}$ to check that the message from $S_{j}$ is valid. If it is equal, $C S$ retrieves $U s e r i n f o r_{i}$ from the verifier table using $U I D_{i}$ from the login request message. Then, $C S$ computes $N_{i 1}^{^{'}} = U s e r i n f o r_{i} \oplus h (x) \oplus A_{i}$ , $V e r u_{i}^{^{'}} = h (h (x) ‖ N_{i 1}^{^{'}})$ . If $V e r u_{i} \overset{?}{=} V e r u_{i}^{^{'}}$ is correct, $C S$ selects a random number $N_{i 3}$ and generates a session key $S K_{i} = h (h (A_{i} ‖ h (x)) \oplus h (N_{i 1} \oplus N_{i 2} \oplus N_{i 3}))$ . $C S$ generates time stamp $T s$ and computes $C_{i} = N_{i 1} \oplus N_{i 3} \oplus h (S I D_{j} \oplus N_{i 2})$ , $D_{i} = h (A_{i} ‖ h (x)) \oplus h (S I D_{j} \oplus N_{i 2})$ , $E_{i} = N_{i 2} \oplus N_{i 3} \oplus h (A_{i} ‖ h (x))$ . Finally, $C S$ sends an authentication message ${C_{i}, D_{i}, E_{i}, T s}$ to $S_{j}$ .
Step 4:: After $S_{j}$ receives the message from $C S$ , $S_{j}$ computes ${(N_{i 1} \oplus N_{i 3})}^{^{'}} = C_{i} \oplus h (S I D_{j} \oplus N_{i 2})$ , $h (A_{i} {| | h (x))}^{^{'}} = D_{i} \oplus h (S I D_{j} \oplus N_{i 2})$ . $S_{j}$ generates a session key $S K^{^{'}} = h (h (A_{i} {| | h (x))}^{^{'}} \oplus h (N_{i 1} \oplus N_{i 2} \oplus N_{i 3}))^{^{'}}$ . Then, $S_{j}$ computes $E_{i} = (N_{i 2} \oplus N_{i 3}) \oplus h (A_{i} ‖ h (x))$ and sends an authentication message ${E_{i}, T s}$ to $U_{i}$ .
Step 5:: After receiving the message from $S_{j}$ , $U_{i}$ computes $T s^{^{'}} = T s + 1$ and checks whether $Δ T s \geq T s^{^{'}} - T s$ . If it is correct, $U_{i}$ computes ${(N_{i 2} \oplus N_{i 3})}^{^{'}} = E_{i} \oplus h (A_{i} ‖ h (x))$ and generates a session key $S K^{^{''}} = h (h (A_{i} ‖ h (x)) \oplus h (N_{i 1} \oplus N_{i 2} \oplus N_{i 3}))^{^{'}}$ . Therefore, $U_{i}$ , $S_{j}$ , and $C S$ generate the same session key, so they can perform the authentication.

4.3. Password Change Phase

U_{i}

wants to change his/her password

P W_{i}

to a new password

P W_{i}^{n e w}

, 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 $E n c P a s s_{i} = h (I D_{i} ‖ h (P W_{i}))$ , $U s e r i n f o r_{i}^{^{'}} = h (E n c P a s s_{i} ‖ x)$ . The smartcard verifies whether $U s e r i n f o r_{i}^{^{'}} \overset{?}{=} U s e r i n f o r_{i}$ . If it is equal, the smartcard requests a new password.
Step 3:: $U_{i}$ inputs a new password $P W_{i}^{n e w}$ and generates $E n c P a s s_{i}^{n e w} = h (I D_{i} ‖ h (P W_{i}^{n e w}))$ . Then, $U_{i}$ inputs $E n c P a s s_{i}^{n e w}$ into the smartcard.
Step 4:: The smartcard computes $U s e r i n f o r_{i}^{n e w} = h (E n c P a s s_{i}^{n e w} ‖ x)$ by using $E n c P a s s_{i}^{n e w}$ . The smartcard updates $U s e r i n f o r_{i}$ to $U s e r i n f o r_{i}^{n e w}$ and replaces $U s e r i n f o 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

{U I D_{i}, A_{i}, V e r u_{i}, T s}

. According to Section 3.1, we can assume that

U_{a}

extracts the values

{U I D_{i}, U s e r i n f o r_{i}, E n c P a s s_{i}, h (x)}

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 ${U s e r i n f o r_{i}, h (x)}$ , ${A_{i}, T s}$ from the smartcard of $U_{i}$ and the previous session, respectively.
Step 2:: $U_{a}$ computes $N_{i 1} = A_{i} \oplus U s e r i n f o r_{i} \oplus h (x)$ and obtains a random nonce $N_{i 1}$ . Then $U_{a}$ computes $V e r u_{i} = h (h (x) ‖ N_{i 1})$ .
Step 3:: $U_{a}$ computes $A_{i} = U s e r i n f o r_{a} \oplus h (x) \oplus N_{a 1}$ , $V e r u_{a} = h (h (x) ‖ N_{a 1})$ . Finally, $U_{a}$ can generate a login request message ${U I D_{i}, A_{i}, V e r u_{a}, T s}$ 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}, T s}

and extracts the information

h (x)

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}, T s}$ in the previous session and extracts $h (x)$ from the smartcard of an authorized user.
Step 2:: $U_{a}$ computes $h (A_{i} ‖ h (x))$ and obtains $(N_{i 2} \oplus N_{i 3})$ . After that, $U_{a}$ computes $E_{i} = (N_{i 2} \oplus N_{i 3}) \oplus h (A_{i} ‖ h (x))$ .
Step 3:: Finally, $U_{a}$ generates authentication messages ${E_{i}, T s}$ 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_{i 1}

N_{i 2}

, and

N_{i 3}

. Furthermore, Bae et al. claimed that the attacker cannot obtain

h (x)

because the trusted party

C S

generated

h (X)

. However, we demonstrate that the attacker can compute

N_{i 1}

and

N_{i 2} \oplus N_{i 3}

and extract

h (x)

in Section 5.1 and Section 5.2. Thus, the attacker can compute

S K_{i} = h (h (A_{i} | | h (x)) \oplus h (N_{i 1} \oplus N_{i 2} \oplus N_{i 3}))

. Therefore, Bae et al.’s protocol is vulnerable to session key disclosure attacks.

5.4. Mutual Authentication

In Bae et al.’s protocol,

C S

computes

V e r s_{i}^{^{'}}

and

V e r u_{i}^{^{'}}

to authenticate legitimate

U_{i}

and

S_{j}

. However,

C S

cannot generate authentication messages for

U_{i}

and

S_{j}

. Thus,

U_{i}

and

S_{j}

receive the message from

C S

, 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

C S

to provide their services to users. Then, a new user

U_{i}

first accesses the control server, and he/she must register with

C S

. The detailed steps are illustrated in Figure 5 and described as follows.

Step 1:: $G_{j}$ requests registration to the $C S$ . $G_{j}$ selects $G I D_{j}$ and sends the value to $C S$ through a secure channel, then $C S$ computes $P I D_{j} = h (G I D_{j} ‖ h (x ‖ y))$ and sends $P I D_{j}$ to $G_{j}$ via a secure channel. $G_{j}$ stores $P I D_{j}$ in itself.
Step 2:: $U_{i}$ chooses the his/her identification $I D_{i}$ and password $P W_{i}$ and imprints biometrics $B I O_{i}$ . Then $U_{i}$ generates a random number $a_{i}$ , computes $< R_{i}, P_{i} > = G e n (B I O_{i})$ , $H I D i = h (I D_{i} ‖ a_{i}))$ , which is an anonymity value of $U_{i}$ , and $H P W_{i} = h (I D_{i} ‖ P W_{i} ‖ a_{i})$ , and sends the message ${H I D_{i}, H P W_{i}, a_{i}}$ to $C S$ through closed channel.
Step 3:: After $C S$ receives the message from $U_{i}$ , $C S$ computes the secret information value $U I_{i} = h (H I D_{i} ‖ a_{i} ‖ x)$ , $A_{i} = U I_{i} \oplus h (H P W_{i})$ , $B_{i} = h (U I_{i} ‖ A_{i})$ , and $X_{i} = h (U I_{i} ‖ x)$ . Then, $C S$ stores ${A_{i}, B_{i}, X_{i}, h (*)}$ in the smartcard, and stores $U I_{i}$ with $H I D_{i}$ in the database. Then $C S$ issues the smartcard to $U_{i}$ .
Step 4:: After receiving the smartcard from $C S$ , $U_{i}$ computes $L_{i} = h (R_{i} ‖ 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

C S

. 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 $B I O_{i}$ . The smartcard computes $R_{i} = R e p (B I O_{i}, P i)$ , $a_{i} = L_{i} \oplus h (R_{i} ‖ P W_{i}$ ), $H I D_{i} = h (I D_{i} ‖ a_{i})$ , $H P W_{i} = h (I D_{i} ‖ P W_{i} ‖ a_{i})$ , $U I_{i} = A_{i} \oplus h (H P W_{i})$ , $B_{i}^{*} = h (U I_{i} ‖ A_{i})$ . Then, the smartcard checks whether $B_{i}^{*} \overset{?}{=} 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} ‖ N_{i} ‖ G I D_{j})$ . Finally, $U_{i}$ sends the login request message ${H I 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 (G I D_{j} ‖ G I_{j} ‖ N_{j})$ . Then, $G_{j}$ sends the login request message ${H I D_{i}, C_{i}, P I D_{j}, D_{i}, V S_{j}}$ to $C S$ via an open channel.
Step 3:: After $C S$ receives the login request message from $G_{j}$ , $C S$ computes $G I_{j} = h (P I D_{j} ‖ h (x ‖ y))$ , $N_{j} = D_{i} \oplus G I_{j}$ and compares $V S_{j}^{*} \overset{?}{=} V S_{j}$ to see whether $G_{j}$ ’s login request message is legitimate. If it is equal, $C S$ retrieves $U I_{i}$ from the verifier table using $H I D_{i}$ of the login request message. Then, $C S$ computes $X_{i} = h (U I_{i} ‖ x)$ , $N_{i} = C_{i} \oplus U I_{i}, V U_{i}^{*} = h (X_{i} ‖ N_{i} ‖ G I D_{j})$ . Then $C S$ compares $V U_{i}^{*} \overset{?}{=} V U_{i}$ to check that the message from $U_{i}$ is valid. If it is valid, $C S$ generates a random number $N_{c}$ and computes $E_{i} = G I_{j} \oplus N_{c}$ , $F_{i} = G I_{j} \oplus N_{i}$ . $C S$ computes $M_{c g} = h (E_{i} ‖ G I_{j} ‖ N_{c})$ to mutually authenticate with $G_{j}$ and $M_{c u} = h (X_{i} ‖ U I_{i} ‖ N_{i})$ to authenticate with $U_{i}$ and generates a session key $S K = h (N_{i} \oplus h (N_{j} ‖ N_{c}))$ . $C S$ updates $H I D_{i}$ to $H I D_{i}^{n e w} = h (H I D_{i} ‖ N_{i} ‖ h (N_{j} ‖ N_{c}))$ and $U I_{i}$ to $U I_{i}^{n e w} = h (H I D_{i}^{n e w} ‖ N_{i} ‖ U I_{i})$ , then replaces $H I D_{i}$ and $U I_{i}$ . Finally, $C S$ sends the authentication message ${M_{c g}$ , $M_{c u}$ , $E_{i}$ , $F_{i}}$ to $G_{j}$ .
Step 4:: After $G_{j}$ receives the authentication message from $C S$ , $G_{j}$ computes $N_{c} = E_{i} \oplus G I_{j}$ , $M_{c g}^{*} = h (E_{i} ‖ G I_{j} ‖ N_{c})$ .Then, $G_{j}$ compares $M_{c g}^{*} \overset{?}{=} M_{c g}$ to verify whether the message from $C S$ is legitimate. If it is valid, $G_{j}$ computes $N_{i} = F_{i} \oplus G I_{j}$ and generates a session key $S K = h (N_{i} \oplus h (N_{j} ‖ N_{c}))$ . Then, $G_{j}$ computes $G_{i} = h (G I D_{j} ‖ N_{i})$ , $H_{i} = G_{i} \oplus h (N_{j} ‖ N_{c})$ and sends the authentication message ${H_{i}, M_{c u}}$ to $U_{i}$ .
Step 5:: After receiving the message from $G_{j}$ , $U_{i}$ computes $M_{c u}^{*} = h (X_{i} ‖ U I_{i} ‖ N_{i})$ and verifies whether $M_{c u}^{*} \overset{?}{=} M_{c u}$ . If it is valid, $U_{i}$ computes $G_{i}^{*} = h (G I D_{j} ‖ N_{i})$ , $h (N_{j} ‖ N_{c}) = H_{i} \oplus G_{i}^{*}$ and generates a session key $S K = h (N_{i} \oplus h (N_{j} ‖ N_{c}))$ . Therefore, $U_{i}$ , $S_{j}$ , and $C S$ generate the same session key, so they can perform the authentication. $U_{i}$ updates $H I D_{i}$ to $H I D_{i}^{n e w} = h (H I D_{i} ‖ N_{i} ‖ h (N_{j} ‖ N_{c}))$ and $U I_{i}$ to $U I_{i}^{n e w} = h (H I D_{i}^{n e w} ‖ N_{i} ‖ U I_{i})$ , then replaces $H I D_{i}$ and $U I_{i}$ . The smartcard updates $A_{i}^{n e w} = U I_{i}^{n e w} \oplus h (H P W), B_{i}^{n e w} = h (U I_{i}^{n e w} ‖ A_{i}^{n e w})$ , and $X_{i}^{n e w} = h (U I_{i}^{n e w} ‖ U I_{i})$ .

6.3. Password Change Phase

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 $B I O_{i}$ .
Step 2:: The smartcard computes $< R_{i}, P_{i} > = G e n (B I O_{i})$ , $a_{i} = L_{i} \oplus h (R_{i} ‖ P W_{i}$ ), $H P W_{i} = h (I D_{i} ‖ P W_{i} ‖ a_{i})$ , and $B_{i}^{*} = h (U I_{i} ‖ 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}^{n e w}$ .
Step 4:: After receiving the new password from $U_{i}$ , the smartcard computes $L_{i}^{n e w} = a_{i} \oplus h (R_{i} ‖ P W_{i}^{n e w})$ , $H P W_{i}^{n e w} = h (I D_{i} ‖ P W_{i}^{n e w} ‖ a_{i})$ , $A_{i}^{n e w} = U I_{i} \oplus h (H P W_{i}^{n e w})$ , and $B_{i}^{n e w} = h (U I_{i} ‖ A_{i}^{n e w})$ . Consequently, the smartcard updates the old information ${A_{i}, B_{i}, L_{i}}$ to new information ${A_{i}^{n e w}, B_{i}^{n e w}, L_{i}^{n e w}}$ .

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

{H I D_{i}, C_{i}, V U_{i}}

and message

{H_{i}, M_{c u}}

. However,

U_{a}

cannot compute

H I D_{i}

because

U_{a}

cannot extract a random number

a_{i}

from

H I 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_{c u}}

. 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

G I 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}, H P W_{i} = h (I D_{i} ‖ P W_{i} ‖ 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

H I D_{i} = h (I D_{i} ‖ a_{i})

. Because

H I D_{i}

is a transmitted message via a public channel,

U_{a}

can obtain this value. Therefore,

U_{i}

updates it as

H I D_{i}^{n e w} = h (H I D_{i} ‖ N_{i} ‖ h (N_{j} ‖ N_{c}))

for every session to prevent the attack of

U_{a}

. The gateway uses

P I D_{j}

, which is generated in the registration phase, instead of

G I 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,

C S

uses

H I D_{i}

to retrieve

U I_{i}

after checking message from

G_{j}

, and

H I D_{i}

updates

H I D_{i}^{n e w}

after authentication of the request message. Furthermore, an attacker disturbs the response communication to desynchronize

H I D_{i}^{n e w}

. Even if the user cannot receive the response message, the user can generate and update

H I D_{i}^{n e w}

. Thus, our proposed protocol can resist desynchronization attacks.

7.1.8. Mutual Authentication

When control server

C S

receives the login request message from gateway

G_{j}

C S

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,

C S

authenticates

G_{j}

. Furthermore,

C S

retrieves

U_{i}

from a database to an available

V S_{j}

. After that,

C S

compares

V U_{i}

and

V U_{i}^{*}

. If they are equal,

C S

authenticates

U_{i}

. Then,

C S

computes and sends the login response messages

M_{c g}

and

M_{c u}

to authenticate. After receiving

M_{c g}

from

C S

G_{j}

computes

M_{c g}^{*}

and compares

M_{c g}^{*}

and

M_{c g}

. If they are equal,

G_{j}

authenticates

C S

. Finally,

U_{i}

computes

M_{c u}^{*}

and checks whether

M_{c u}^{*} \overset{?}{=} M_{c u}

. If it is valid,

U_{i}

authenticates

C S

. Therefore,

U_{i}

G_{j}

, and

C S

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

C S

. 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 \overset{K}{\leftrightarrow} Q, P ⊲ {\{X\}}_{K}}{P |\equiv Q| \sim X}$
Nonce verification rule:

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

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

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

$\frac{P | \equiv (X, Y)}{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 C S | \equiv (N_{c}, N_{i})$ ,
Goal 2:: $G_{j} | \equiv (N_{c}, N_{i})$ ,
Goal 3:: $C S | \equiv G_{j} | \equiv (N_{i}, N_{j})$ ,
Goal 4:: $C S | \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

$M s g_{1} :$: $U_{i} \to G_{j} : {(H I D_{i}, N_{i}, x, G I D_{j})}_{U I_{i}}$
$M s g_{2} :$: $G_{j} \to C S : {(H I D_{i}, N_{i}, x, G I D_{j}, N_{j})}_{G I_{j}}$
$M s g_{3} :$: $C S \to G_{j} : {(N_{c}, N_{i}, U I_{i}, x)}_{G I_{j}}$
$M s g_{4} :$: $G_{j} \to U_{i} : {(N_{c}, N_{j}, U I_{i}, G I 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} \overset{U I_{i}}{⟷} G_{j})$
$A_{2} :$: $G_{j} | \equiv # (N_{i})$
$A_{3} :$: $C S | \equiv (G_{j} \overset{G I_{j}}{⟷} C S)$
$A_{4} :$: $C S | \equiv # (N_{j}, N_{i})$
$A_{5} :$: $G_{j} | \equiv (G_{j} \overset{G I_{j}}{⟷} C S)$
$A_{6} :$: $U_{i} | \equiv (U_{i} \overset{N_{i}}{⟷} G_{j})$
$A_{7} :$: $U_{i} | \equiv # (N_{j})$
$A_{8} :$: $C S | \equiv G_{j} \Rightarrow (C S \overset{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 $M s g_{1}$ , we can get

$S_{1} : G_{j} ⊲ {(H I D_{i}, N_{i}, x, G I 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} {(H I D_{i}, N_{i}, x, G I 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 # {(H I D_{i}, N_{i}, x, G I 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 {(H I D_{i}, N_{i}, x, G I 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 {(N_{i})}_{U I_{i}} .$
Step 6:: According to $M s g_{2}$ , we can get

$S_{6} : C S ⊲ {(H I D_{i}, N_{i}, x, G I 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} : C S | \equiv G_{j} {(H I D_{i}, N_{i}, x, G I D_{j}, N_{j})}_{G I_{j}} .$
Step 8:: From $A_{4}$ and $S_{7}$ , we apply the freshness rule to obtain

$S_{8} : C S | \equiv # {(H I D_{i}, N_{i}, x, G I 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} : C S | \equiv G_{j} | \equiv {(H I D_{i}, N_{i}, x, G I D_{j}, N_{j})}_{G I_{j}} .$
Step 10:: From $S_{9}$ , we apply the belief rule to obtain

$S_{10} : C S | \equiv G_{j} | \equiv {(N_{i}, N_{j})}_{G I_{j}} . (Goal 3)$
Step 11:: According to $M s 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 C S {(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 C S | \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 C S | \equiv {(N_{c}, N_{i})}_{G I_{j}} . (Goal 1)$
Step 16:: According to $M s g_{4}$ , we can obtain

$S_{16} : U_{i} ⊲ {(N_{c}, N_{j}, U I_{i}, G I 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}, G I 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}, G I 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}, G I 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}} . (Goal 5)$
Step 21:: From $S_{10}$ and $A_{8}$ , we apply the jurisdiction rule to obtain

$S_{21} : C S | \equiv (N_{i}, N_{j}) . (Goal 4)$
Step 22:: From $S_{15}$ and $A_{9}$ , we apply the jurisdiction rule to obtain

$S_{22} : G_{j} | \equiv (N_{c}, N_{i}) . (Goal 2)$
Step 23:: From $S_{20}$ and $A_{10}$ , we apply the jurisdiction rule to obtain

$S_{23} : U_{i} | \equiv (N_{c}, N_{i}) . (Goal 6)$

We show that the proposed protocol can provide secure mutual authentication between

U_{i}

G_{j}

, and

C S

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

$s e c r e t (A, i d, B)$ : $i d$ denotes an information A that is only known to B.
$w i t n e s s (A, B, i d, E)$ : $i d$ denotes a weakness authentication factor E that is used by A to authenticate B.
$r e q u e s t (A, B, i d, E)$ : $i d$ denotes a strong authentication factor. B requests A for E to authenticate.

8.2. Hlpsl Specifications of Our Protocol

Our protocol has three basic

r o l e s

which are denoted by entities that have been specified according to HLPSL:

U A

denotes a user,

G A

denotes a gateway, and

C S

denotes a control server. The role of

s e s s i o n

and

e n v i r o n m e n t s

are shown in Figure 8. In the

s e s s i o n

, we describe participants. In

e n v i r o n m e n t s

, intruder knowledge is defined, and four secrecy goals and four authentication goals are described. The HLPSL specifications of role

U A

are shown in Figure 9, and the details are as follows.

At transition 1,

U A

starts the registration phase with a start message in state value 0 and then updates the state from 0 to 1.

U A

sends the registration message

{H I D_{i}, H P W_{i}, a}

C S

through a closed channel. At transition 2,

U A

receives the smartcard from

C S

, then it updates the state from 1 to 2. In state value 2,

U A

generates the random number

N_{i}

, sends the login request message

{H I D_{i}, C_{i}, V U_{i}}

G A

via an insecure channel, and declares

w i t n e s s (U A, C S, u s_c s_n i, N_{i})

, which means that

N_{i}

denotes a weakness authentication factor. At transition 3,

U A

receives the login response message from

G A

. After that,

U A

changes the state value from 2 to 3, generates the session key, and declares

r e q u e s t (U A, C S, c s_u a_m c u, N_{c})

. The specifications of role

G A

and

C S

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_{m e}$ : 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 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. 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 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.

Author Contributions

Y.P. (YoungHo Park) supervised the research and contributed to manuscript organization; J.L. and S.Y. contributed to the protocol design; K.P. and Y.P. (YoHan Park) analyzed and revised the manuscript; J.L., S.Y., and K.P. performed the experiments and analyzed the protocol. J.L. and Y.P. (YoHan Park) wrote the manuscript. All authors took part in paper preparation and edition.

Funding

This work was supported by the Basic Science Research Program through the National Research Foundation of Korea funded by the Ministry of Science, ICT, and Future Planning under Grant 2017R1A2B1002147 and in part by the BK21 Plus project funded by the Ministry of Education, Korea, under Grant 21A20131600011.

Conflicts of Interest

The authors declare no conflict of interest.

References

Wu, F.; Xu, L.; Kumari, S.; Li, X.; Shen, J.; Choo, K.R.; Wazid, M.; Das, A.K. An efficient authentication and key agreement scheme for multi-gateway wireless sensor networks in IoT deployment. J. Netw. Comput. Appl. 2017, 81, 72–85. [Google Scholar] [CrossRef]
Das, A.K.; Sutrala, A.K.; Kumari, S.; Odelu, V.; Wazid, M.; Li, X. An efficient multi-gateway-based three-factor user authentication and key agreement scheme in hierarchical wireless sensor networks. Secur. Commun. Netw. 2016, 9, 2070–2092. [Google Scholar] [CrossRef] [Green Version]
Wu, Z.Y.; Lee, Y.C.; Lai, F.; Lee, H.C.; Chung, Y. A secure authentication scheme for telecare medicine information systems. J. Med. Syst. 2010, 36, 1529–1535. [Google Scholar] [CrossRef]
Chang, Y.F.; Yu, S.H.; Shiao, D.R. A uniqueness-and-anonymity-preserving remote user authentication scheme for connected health care. J. Med. Syst. 2013, 37, 9902. [Google Scholar] [CrossRef] [PubMed]
Turkanović, M.; Brumen, B.; Hölbl, M. A novel user authentication and key agreement scheme for heterogeneous ad hoc wireless sensor networks, based on the Internet of Things notion. Ad Hoc Netw. 2014, 20, 96–112. [Google Scholar] [CrossRef]
He, D.; Chen, J.; Zhang, R. A more secure authentication scheme for telecare medicine information systems. J. Med. Syst. 2012, 36, 1989–1995. [Google Scholar]
Das, A.K.; Goswami, A. A secure and efficient uniqueness-and-anonymity-preserving remote user authentication scheme for connected health care. J. Med. Syst. 2013, 37, 9948. [Google Scholar] [CrossRef] [PubMed]
Kumari, S.; Li, X.; Wu, F.; Das, A.K.; Choo, K.; Shen, J. Design of a provably secure biometrics-based multi-cloud-server authentication scheme. Future Gener. Comput. Syst. 2017, 68, 320–330. [Google Scholar] [CrossRef]
Chatterjee, S.; Roy, S.; Das, A.K.; Chattopadhyay, S.; Kumar, N. Secure biometric-based authentication scheme using chebyshev chaotic map for multi-server environment. IEEE Trans. Depend. Sec. Comput. 2018, 15, 428–442. [Google Scholar] [CrossRef]
Amin, R.; Biswas, G.P. A secure light weight scheme for user authentication and key agreement in multi-gateway based wireless sensor networks. Ad Hoc Netw. 2016, 36, 58–80. [Google Scholar] [CrossRef]
Lin, C.H.; Lai, Y.Y. A flexible biometrics remote user authentication scheme. Comput. Stand. Interfaces 2004, 27, 19–23. [Google Scholar] [CrossRef]
Dhillon, P.K.; Kalra, S. A lightweight biometrics based remote user authentication scheme for IoT services. J. Inf. Secur. Appl. 2017, 34, 255–270. [Google Scholar] [CrossRef]
Srinivas, J.; Mukhopadhyay, S.; Mishra, D. Secure and efficient user authentication scheme for multi-gateway wireless sensor networks. Ad Hoc Netw. 2017, 54, 147–169. [Google Scholar] [CrossRef]
Wu, F.; Li, X.; Sangaiah, A.K.; Xu, L.; Kumari, S.; Wu, L.; Shen, J. A lightweight and robust two-factor authentication scheme for personalized healthcare systems using wireless medical sensor networks. Future Gener. Comput. Syst. 2018, 82, 727–737. [Google Scholar] [CrossRef]
Bae, W.; Kwak, J. Smart card-based secure authentication protocol in multi-server IoT environment. Multimed. Tools. Appl. 2017, 1–19. [Google Scholar] [CrossRef]
Xu, G.; Qiu, S.; Ahmad, H.; Xu, G.; Guo, Y.; Zhang, M.; Xu, H. A multi-server two-factor authentication scheme with un-traceability using elliptic curve cryptography. Sensors 2018, 18, 2394. [Google Scholar] [CrossRef] [PubMed]
Leu, J.S.; Chen, C.F.; Hsu, K.C. Improving heterogeneous SOA-based IoT message stability by shortest processing time scheduling. IEEE Trans. Serv. Comput. 2013, 99, 1–99. [Google Scholar] [CrossRef]
Dolev, D.; Yao, A.C. On the security of public key protocols. IEEE Trans. Inf. Theory 1983, 29, 198–208. [Google Scholar] [CrossRef]
Kocher, P.; Jaffe, J.; Jun, B. Differential power analysis. In Advances in Cryptology; Springer Science+Business Media: Berlin, Germany; New York, NY, USA, 1999; pp. 388–397. [Google Scholar]
Park, Y.; Park, Y. Three-factor user authentication and key agreement using elliptic curve cryptosystem in wireless sensor networks. Sensors 2016, 16, 2123. [Google Scholar] [CrossRef]
Burnett, A.; Byrne, F.; Dowling, T.; Duffy, A. A biometric identity based signature scheme. Int. J. Netw. Secur. 2007, 5, 317–326. [Google Scholar]
Dodis, Y.; Reyzin, L.; Smith, A. Fuzzy extractors: How to generate strong keys from biometrics and other noisy data. Proc. Adv. Cryptol. 2004, 3027, 523–540. [Google Scholar]
Park, Y.; Park, K.; Lee, K.; Song, H.; Park, Y. Security analysis and enhancements of an improved multi-factor biometric authentication scheme. Int. J. Distrib. Sens. Netw. 2017, 13, 1–12. [Google Scholar] [CrossRef]
Chatterjee, S.; Roy, S.; Das, A.K.; Chattopadhyay, S.; Kumar, N.; Alavalapati, G.R.; Park, K.; Park, Y.; Park, Y. On the design of fine grained access control with user authentication scheme for telecare medicine information systems. IEEE Access 2017, 5, 7012–7030. [Google Scholar] [CrossRef]
Von Oheimb, D. The high-level protocol specification language HLPSL developed in the EU project avispa. In Proceedings of the APPSEM 2005 Workshop, Tallinn, Finland, 13–15 September 2005; pp. 1–2. [Google Scholar]
Park, K.; Park, Y.; Park, Y.; Reddy, A.G.; Das, A.K. Provably secure and efficient authentication protocol for roaming service in global mobility networks. IEEE Access 2017, 5, 25110–25125. [Google Scholar] [CrossRef]
Park, K.; Park, Y.; Park, Y.; Das, A.K. 2PAKEP: Provably secure and efficient two-party authenticated key exchange protocol for mobile environment. IEEE Access 2018, 6, 30225–30241. [Google Scholar] [CrossRef]
Yu, S.; Lee, J.; Lee, K.; Park, K.; Park, Y. Secure authentication protocol for wireless sensor networks in vehicular communications. Sensors 2018, 18, 3191. [Google Scholar] [CrossRef]
Turuani, M. The CL-Atse protocol analyser. In Proceedings of the International Conference on Rewriting Techniques and Applications (RTA), Seattle, WA, USA, 12–14 August 2006; pp. 227–286. [Google Scholar]
Basin, D.; Modersheim, S.; Vigano, L. OFMC: A symbolic model checker for security protocols. Int. J. Inf. Secur. 2005, 4, 181–208. [Google Scholar] [CrossRef]
AVISPA. Automated Validation of Internet Security Protocols and Applications. Available online: http://www.avispa-project.org/ (accessed on 11 January 2019).
SPAN: A Security Protocol Animator for AVISPA. Available online: http://www.avispa-project.org/ (accessed on 11 January 2019).
Preeti, C.; Hari, O. A secure and robuts anonymous three-factor remote user authentication scheme for multi-server environment using ECC. Comput. Commun. 2017, 110, 26–34. [Google Scholar]
Li, C.; Hwang, M.S.; Chu, Y.P. A secure and efficient communication scheme with authenticated key establishment and privacy preserving for vehicular ad hoc networks. Comput. Commun. 2008, 31, 2803–2814. [Google Scholar] [CrossRef]
Ostad-Sharif, A.; Abbasinezhad-Mood, D.; Nikooghadm, M. A robust and efficient ECC-based mutual authentication and session key generation scheme for healthcare applications. J. Med. Syst. 2019, 43, 1–22. [Google Scholar] [CrossRef]

Figure 1. System model of our protocol in multi-gateway IoT environments.

Figure 2. Registration phase of Bae et al.’s protocol.

Figure 3. Login and authentication phase of Bae et al.’s protocol.

Figure 4. Password change phase of Bae et al.’s protocol.

Figure 5. Registration phase of our proposed protocol.

Figure 6. Login and authentication phase of our proposed protocol.

Figure 7. Password change phase of our proposed protocol.

Figure 8. Specification of session and environments.

Figure 9. Specification of user.

Figure 10. Specification of gateway.

Figure 11. Specification of control server.

Figure 12. The result of Automated Validation of Internet Security Protocols and Applications (AVISPA) simulation using OFMC and CL-AtSe.

Table 1. Notations.

Notations	Meanings
$U_{i}$	i-th user
$S_{j}$	j-th server
$C S$	Control server
$I D_{i}$	Identity of $U_{i}$
$S I D_{j}$	Identity of $S_{j}$
$P W_{i}$	Password of $U_{i}$
x	Master secret key chosen by $C S$
$T s$	Timestamp
$N_{i 1}$	Random number generated by $U_{i}$ ’s smartcard
$N_{i 2}$	Random number generated by $S_{j}$
$N_{i 3}$	Random number generated by $C S$
$S K$	Common session key shared among $U_{i}$ , $S_{j}$ , and $C S$
$h (*)$	Collision-resistant one-way hash function

Table 2. The verifier table.

User-Verifier	Anonymity Value	Status-Bit
$U s e r i n f o r_{1}$	$U_{1}$	$0 / 1$
$U s e r i n f o r_{2}$	$U_{2}$	$0 / 1$
$\dots$	$\dots$	$\dots$
$U s e r i n f o r_{i}$	$U_{i}$	$0 / 1$

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
${X}_{K}$	Formula X is encrypted by the key K
$P \overset{K}{\leftrightarrow} Q$	P and Q communicate using K as the shared key
$S K$	Session key used in the current authentication session

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} (0.0095 s)$
Wu et al. [3]	2 $T_{m e}$ + 4 $T_{h}$	-	1 $T_{m e}$ + 4 $T_{h}$	3 $T_{m e}$ + 8 $T_{h} (1.57 s)$
Amin and Biswas Case-1 [10]	7 $T_{h}$	5 $T_{h}$	8 $T_{h}$	20 $T_{h} (0.01 s)$
Amin and Biswas Case-2 [10]	8 $T_{h}$	5 $T_{h}$	7 $T_{h}$	20 $T_{h} (0.01 s)$
Bae et al. [15]	5 $T_{h}$	6 $T_{h}$	10 $T_{h}$	21 $T_{h} (0.0105 s)$
Ours	1 $T_{f}$ +14 $T_{h}$	5 $T_{h}$	9 $T_{h}$	1 $T_{f}$ + 28 $T_{h} (0.07707 s)$

XOR operation is negligible compared to other operations.

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

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.

© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

Share and Cite

MDPI and ACS Style

Lee, J.; Yu, S.; Park, K.; Park, Y.; Park, Y. Secure Three-Factor Authentication Protocol for Multi-Gateway IoT Environments. Sensors 2019, 19, 2358. https://doi.org/10.3390/s19102358

AMA Style

Lee J, Yu S, Park K, Park Y, Park Y. Secure Three-Factor Authentication Protocol for Multi-Gateway IoT Environments. Sensors. 2019; 19(10):2358. https://doi.org/10.3390/s19102358

Chicago/Turabian Style

Lee, JoonYoung, SungJin Yu, KiSung Park, YoHan Park, and YoungHo Park. 2019. "Secure Three-Factor Authentication Protocol for Multi-Gateway IoT Environments" Sensors 19, no. 10: 2358. https://doi.org/10.3390/s19102358

APA Style

Lee, J., Yu, S., Park, K., Park, Y., & Park, Y. (2019). Secure Three-Factor Authentication Protocol for Multi-Gateway IoT Environments. Sensors, 19(10), 2358. https://doi.org/10.3390/s19102358

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Menu

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

Abstract

1. Introduction

2. Related Works

3. Preliminaries

3.1. Threat Model

3.2. Fuzzy Extraction

3.3. System Model

3.4. Notations

4. Review of Bae et al.’s Protocol

4.1. Registration Phase

4.2. Login and Authentication Phase

4.3. Password Change Phase

5. Cryptanalysis of Bae et al.’s Protocol

5.1. User Impersonation Attack

5.2. Server Spoofing Attack

5.3. Session Key Disclosure Attack

5.4. Mutual Authentication

6. A Secure Three-Factor Mutual Authentication Protocol

6.1. Registration Phase

6.2. Login and Authentication Phase

6.3. Password Change Phase

7. Security Analysis

7.1. Informal Security

7.1.1. User Impersonation Attack

7.1.2. Server Spoofing Attack

7.1.3. Smartcard Stolen Attack

7.1.4. Trace Attack and Anonymity

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

7.1.6. Off-Line Password Guessing Attack

7.1.7. Desynchronization Attack

7.1.8. Mutual Authentication

7.2. Ban Logic

7.2.1. Rules of Ban Logic

7.2.2. Goals

7.2.3. Idealized Forms

7.2.4. Assumptions

7.2.5. Proof Using Ban Logic

8. Formal Verification Using Avispa

8.1. Description of Avispa

8.2. Hlpsl Specifications of Our Protocol

8.3. Results of Avispa Simulation

9. Performance Analysis

9.1. Computation Cost

9.2. Communication Cost

9.3. Security Properties

10. Conclusions

Author Contributions

Funding

Conflicts of Interest

References

Share and Cite

Article Metrics

Article Access Statistics

Further Information

Guidelines

MDPI Initiatives

Follow MDPI