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

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:

. This algorithm is for generating key information. It uses biometric data as an input and then outputs secret key data , which is a uniformly random string, and a public reproduction as a helper string.

. This algorithm reproduces the secret data . The inputs of this algorithm are a noisy biometric and . The algorithm reproduces the secret biometric key . To recover the same , the metric space distance between and 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.

Figure 1

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

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.

Table 1

Notations.

Notations	Meanings
U_i	i-th user
S_j	j-th server
CS	Control server
ID_i	Identity of U_i
SID_j	Identity of S_j
PW_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

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 is trusted.

4.1. Registration Phase

If a new user or server requests registration to the authentication server , issues the smartcard to and sends the necessary value to . This phase and verifier table is shown in Figure 2 and Table 2, respectively, and the details are as follows.

Figure 2

Registration phase of Bae et al.’s protocol.

Table 2

The verifier table.

User-Verifier	Anonymity Value	Status-Bit
Userinfor_1	U_1	0/1
Userinfor_2	U_2	0/1
…	…	…
Userinfor_i	U_i	0/1

requests registration to the . sends its identity to through a secure channel, then computes and sends this to .

chooses the , and , computes and sends the message and , which is an anonymity value of , to through a closed channel.

receives the message from . computes the secret information value , stores in the smartcard, and stores , and in the verifier table. Then, issues the smartcard to .

4.2. Login and Authentication Phase

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

Figure 3

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

inputs his/her and and inputs the smartcard into a smartcard reader. The smartcard computes . Then, the smartcard checks whether . If it is equal, generates a random number and computes , . Then, generates to prevent a replay attack. Finally, sends the login request message to through a secure channel.

If receives the login request message, generates a random number and computes , . Then, sends the login request message to through an open channel.

After receives the login request message from , computes and checks to see whether the login request message is legitimate. If it is valid, computes , , . Then compares to check that the message from is valid. If it is equal, retrieves from the verifier table using from the login request message. Then, computes , . If is correct, selects a random number and generates a session key . generates time stamp and computes , , . Finally, sends an authentication message to .

After receives the message from , computes , . generates a session key . Then, computes and sends an authentication message to .

After receiving the message from , computes and checks whether . If it is correct, computes and generates a session key . Therefore, , , and generate the same session key, so they can perform the authentication.

4.3. Password Change Phase

If wants to change his/her password to a new password , the password change phase is performed. This phase is illustrated in Figure 4 and is described as follows.

Figure 4

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

The inserts his/her smartcard into a card reader and inputs and . Then, sends the to the smartcard reader through the closed channel.

After receiving the values from , the smartcard computes , . The smartcard verifies whether . If it is equal, the smartcard requests a new password.

inputs a new password and generates . Then, inputs into the smartcard.

The smartcard computes by using . The smartcard updates to and replaces . Finally, the user 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 attempts to impersonate an authorized user , must successfully compute a login request message . According to Section 3.1, we can assume that extracts the values from the smartcard of and obtains the transmitted messages over a public channel. After that, can impersonate the user in the following steps.

obtains , from the smartcard of and the previous session, respectively.

computes and obtains a random nonce . Then computes .

computes , . Finally, can generate a login request message 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 obtains message and extracts the information from the smartcard of an authorized user. Then, can impersonate the server by generating authentication messages in the following steps.

obtains transmitted messages in the previous session and extracts from the smartcard of an authorized user.

computes and obtains . After that, computes .

Finally, generates authentication messages 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 , , and . Furthermore, Bae et al. claimed that the attacker cannot obtain because the trusted party generated . However, we demonstrate that the attacker can compute and and extract in Section 5.1 and Section 5.2. Thus, the attacker can compute . Therefore, Bae et al.’s protocol is vulnerable to session key disclosure attacks.

5.4. Mutual Authentication

In Bae et al.’s protocol, computes and to authenticate legitimate and . However, cannot generate authentication messages for and . Thus, and receive the message from , 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 must register with control server to provide their services to users. Then, a new user first accesses the control server, and he/she must register with . The detailed steps are illustrated in Figure 5 and described as follows.

Figure 5

Registration phase of our proposed protocol.

requests registration to the . selects and sends the value to through a secure channel, then computes and sends to via a secure channel. stores in itself.

chooses the his/her identification and password and imprints biometrics . Then generates a random number , computes , , which is an anonymity value of , and , and sends the message to through closed channel.

After receives the message from , computes the secret information value , , , and . Then, stores in the smartcard, and stores with in the database. Then issues the smartcard to .

After receiving the smartcard from , computes . Then inputs and in the smartcard.

6.2. Login and Authentication Phase

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

Figure 6

Login and authentication phase of our proposed protocol.

inserts the smartcard, his/her and , and biometric . The smartcard computes , ), , , , . Then, the smartcard checks whether to check whether the user is legitimate. If it is valid, generates a random number and computes , . Finally, sends the login request message to through a public channel.

After receiving a login request message, generates a random number and computes , . Then, sends the login request message to via an open channel.

After receives the login request message from , computes , and compares to see whether ’s login request message is legitimate. If it is equal, retrieves from the verifier table using of the login request message. Then, computes , . Then compares to check that the message from is valid. If it is valid, generates a random number and computes , . computes to mutually authenticate with and to authenticate with and generates a session key . updates to and to , then replaces and . Finally, sends the authentication message , , , to .

After receives the authentication message from , computes , .Then, compares to verify whether the message from is legitimate. If it is valid, computes and generates a session key . Then, computes , and sends the authentication message to .

After receiving the message from , computes and verifies whether . If it is valid, computes , and generates a session key . Therefore, , , and generate the same session key, so they can perform the authentication. updates to and to , then replaces and . The smartcard updates , and .

6.3. Password Change Phase

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

Figure 7

Password change phase of our proposed protocol.

A legitimate user inserts the smartcard, his/her and , and biometric .

The smartcard computes , ), , and . After that, the smartcard compares the with stored value. If it is equal, the smartcard requests a new password to .

When receives the request message from smartcard, inputs a new password .

After receiving the new password from , the smartcard computes , , , and . Consequently, the smartcard updates the old information to new information .

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 attempts to masquerade as a user , can generate a login request message and message . However, cannot compute because cannot extract a random number from . cannot retrieve a random number because the attacker cannot know secret parameter . Thus, cannot compute because cannot extract a random number . Therefore, our protocol resists user impersonation attack.

7.1.2. Server Spoofing Attack

To impersonate the server, an attacker can generate an authentication message . However, cannot compute these because cannot know the random nonces . Furthermore, if attempts to impersonate the gateway by using public parameter , 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 cannot generate valid messages.

7.1.3. Smartcard Stolen Attack

We assume that an attacker can extract the values of the smartcard according to Section 3.1. However, 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 . Therefore, our protocol can prevent smartcard stolen attacks.

7.1.4. Trace Attack and Anonymity

In our protocol, an attacker cannot know the identity of the users and gateways. The user does not send a real identity via the public channels. The user generates and sends a pseudonym identity . Because is a transmitted message via a public channel, can obtain this value. Therefore, updates it as for every session to prevent the attack of . The gateway uses , which is generated in the registration phase, instead of , 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 knows the information transmitted via an insecure channel and information from the smartcard of to set up a secure channel with . However, cannot generate a valid login request message, as mentioned. Furthermore, cannot impersonate user by resending the messages because the messages are refreshed with random numbers , and . Therefore, our proposed protocol prevents man-in-the-middle attacks and replay attacks.

7.1.6. Off-Line Password Guessing Attack

An attacker attempts to guess the password of legitimate user . If can guess the password, can compute a series of equations and compute several equations and the valid value with the guessed passwords. However, 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, uses to retrieve after checking message from , and updates after authentication of the request message. Furthermore, an attacker disturbs the response communication to desynchronize . Even if the user cannot receive the response message, the user can generate and update . Thus, our proposed protocol can resist desynchronization attacks.

7.1.8. Mutual Authentication

When control server receives the login request message from gateway , computes and to authenticate user and . If and are equal, authenticates . Furthermore, retrieves from a database to an available . After that, compares and . If they are equal, authenticates . Then, computes and sends the login response messages and to authenticate. After receiving from , computes and compares and . If they are equal, authenticates . Finally, computes and checks whether . If it is valid, authenticates . Therefore, , , and 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 , , and . More details of BAN logic can be found in [23,24].

Table 3

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

Notations	Meaning
P|≡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⇒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↔KQ	P and Q communicate using K as the shared key
SK	Session key used in the current authentication session

7.2.1. Rules of Ban Logic

We introduce rules of BAN logic as follows:

Message meaning rule:

Nonce verification rule:

Jurisdiction rule:

Freshness rule:

Belief rule:

7.2.2. Goals

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

,

,

,

,

,

7.2.4. Assumptions

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

7.2.5. Proof Using Ban Logic

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

According to , we can get

From and , we apply the message meaning rule to obtain

From and , we apply the freshness rule to obtain

From and , we apply the nonce verification rule to obtain

From , we apply the belief rule to obtain

According to , we can get

From and , we apply the message meaning rule to obtain

From and , we apply the freshness rule to obtain

From and , we apply the nonce verification rule to obtain

From , we apply the belief rule to obtain

According to , we can get

From and , we apply the message meaning rule to obtain

From and , we apply the freshness rule to obtain

From and , we apply the nonce verification rule to obtain

From , we apply the belief rule to obtain

According to , we can obtain

From and , we apply the message meaning rule to obtain

From and , we apply the freshness rule to obtain

From and , we apply the nonce verification rule to obtain

From , we apply the belief rule to obtain

From and , we apply the jurisdiction rule to obtain

From and , we apply the jurisdiction rule to obtain

From and , we apply the jurisdiction rule to obtain

We show that the proposed protocol can provide secure mutual authentication between , , and 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].

: denotes an information A that is only known to B.

: denotes a weakness authentication factor E that is used by A to authenticate B.

: denotes a strong authentication factor. B requests A for E to authenticate.

8.2. Hlpsl Specifications of Our Protocol

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

Figure 8

Specification of session and environments.

Figure 9

Specification of user.

At transition 1, starts the registration phase with a start message in state value 0 and then updates the state from 0 to 1. sends the registration message to through a closed channel. At transition 2, receives the smartcard from , then it updates the state from 1 to 2. In state value 2, generates the random number , sends the login request message to via an insecure channel, and declares , which means that denotes a weakness authentication factor. At transition 3, receives the login response message from . After that, changes the state value from 2 to 3, generates the session key, and declares . The specifications of role and are similar and shown in Figure 10 and Figure 11.

Figure 10

Specification of gateway.

Figure 11

Specification of control server.

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.

Figure 12

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

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.

: The times for modular exponential operation (≈0.522 s [33,34])

: The times for one-way hash operation (≈0.0005 s [33,34])

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

Table 4

Computation cost of the login and authentication phase.

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

XOR operation is negligible compared to other operations.

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.

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

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.

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.

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.