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.

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 Sections 2 and 3, we introduce related works and our preliminary details. In Sections 4 and 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 Sections 8 and 9. Finally, we conclude with the results of this paper in Section 10.

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.

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.

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.

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 BIO i as an input and then outputs secret key data R i , which is a uniformly random string, and a public reproduction P i as a helper string. • Reproduce(BIO i , P i ) = R i . This algorithm reproduces the secret data R i . The inputs of this algorithm are a noisy biometric BIO i and P i . The algorithm reproduces the secret biometric key R i . To recover the same R i , the metric space distance between BIO i and BIO i should be within a given error tolerance.

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. Table 1 shows the notations used in this paper. Random number generated by S j N i3

Notations
Random number generated by CS SK Common session key shared among U i , S j , and CS h( * ) Collision-resistant one-way hash function

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

Registration Phase
If a new user U i or server S j requests registration to the authentication server CS, CS issues the smartcard to U i and sends the necessary value to S j . This phase and verifier table is shown in Figure 2 and Table 2, respectively, and the details are as follows.  Step 1: S j requests registration to the CS. S j sends its identity SID j to CS through a secure channel, then CS computes Serin f or j and sends this to S j . Step 2: U i chooses the ID i , and PW i , computes EncPass i = h(ID i ||h(PW i )) and sends the message (ID i , EncPass i ) and U ID i , which is an anonymity value of U i , to CS through a closed channel.

Login and Authentication Phase
User U i must send a login request message to S j to use the service of server S j . After receiving a request message, S j sends a login request message to control server CS. This phase is illustrated in Figure 3 and the following details.   Step 1: U i inputs his/her ID i and PW i and inputs the smartcard into a smartcard reader.
The smartcard computes EncPass i = h(ID i ||h(PW i )). Then, the smartcard checks whether . Then, U i generates Ts to prevent a replay attack. Finally, U i sends the login request message {U ID i , A i , Veru i , Ts} to S j through a secure channel.
Step 2: If S j receives the login request message, S j generates a random number N i2 and computes Step 3: After CS receives the login request message from S j , CS computes Ts = Ts + 1 and checks ∆Ts ≥ Ts − Ts to see whether the login request message is legitimate. If it is valid, Then CS compares Vers i ? = Vers i to check that the message from S j is valid. If it is equal, CS retrieves Userin f or i from the verifier table using U ID i from the login request message. Then, If Veru i ? = Veru i is correct, CS selects a random number N i3 and generates a session key ). CS generates time stamp Ts and computes Step 4: After S j receives the message from CS, ) and sends an authentication message {E i , Ts} to U i .
Step 5: After receiving the message from S j , U i computes Ts = Ts + 1 and checks whether ∆Ts ≥ Ts − Ts. If it is correct, . Therefore, U i , S j , and CS generate the same session key, so they can perform the authentication.

Password Change Phase
If U i wants to change his/her password PW i to a new password PW new i , 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 ID i and PW i . Then, U i sends the {ID i , PW i } to the smartcard reader through the closed channel.

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.

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 ID i , A i , Veru i , Ts}. According to Section 3.1, we can assume that U a extracts the values {U ID i , Userin f or i , EncPass 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 {Userin f or i , h(x)}, {A i , Ts} from the smartcard of U i and the previous session, respectively.

Server Spoofing Attack
To obtain the sensitive information of a user, an attacker attempts to impersonate the server. Bae et al. asserted that their protocol can withstand server spoofing attacks. However, we analyze that their protocol does not resist server spoofing. First, an attacker U a obtains message {E i , Ts} and extracts the information h(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 , Ts} in the previous session and extracts h(x) from the smartcard of an authorized user.
Step 3: Finally, U a generates authentication messages {E i , Ts} successfully.

Session Key Disclosure Attack
Bae et al. demonstrated that their protocol can resist session key disclosure attacks because an attacker cannot compute the values N i1 , N i2 , and N i3 . Furthermore, Bae et al. claimed that the attacker cannot obtain h(x) because the trusted party CS generated h(X). However, we demonstrate that the attacker can compute N i1 and N i2 ⊕ N i3 and extract h(x) in Sections 5.1 and 5.2. Thus, the attacker can ). Therefore, Bae et al.'s protocol is vulnerable to session key disclosure attacks.

Mutual Authentication
In Bae et al.'s protocol, CS computes Vers i and Veru i to authenticate legitimate U i and S j . However, CS cannot generate authentication messages for U i and S j . Thus, U i and S j receive the message from CS, but they cannot trust the messages because they cannot check whether the attacker sends the message. Therefore, Bae et al.'s protocol does not achieve mutual authentication.

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.

Registration Phase
First, a gateway G j must register with control server CS to provide their services to users. Then, a new user U i first accesses the control server, and he/she must register with CS. The detailed steps are illustrated in Figure 5 and described as follows.
Step 1: G j requests registration to the CS. G j selects GID j and sends the value to CS through a secure channel, then CS computes PID j = h(GID j ||h(x||y)) and sends PID j to G j via a secure channel. G j stores PID j in itself.
Step 2: U i chooses the his/her identification ID i and password PW i and imprints biometrics BIO i .
Then U i generates a random number a i , computes < R i , P i >= Gen(BIO i ), H IDi = h(ID i ||a i )), which is an anonymity value of U i , and HPW i = h(ID i ||PW i ||a i ), and sends the message {HID i , HPW i , a i } to CS through closed channel.
Step 3: After CS receives the message from U i , CS computes the secret information value

Login and Authentication Phase
If a user U i wants to use the service of gateway G j , U i must send a login request message to G j . Then, G j sends a login request message to control server CS. The detailed steps are illustrated in Figure 6 and described as follows.      Figure 6. Login and authentication phase of our proposed protocol.
Step 1: U i inserts the smartcard, his/her ID i and PW i , and biometric BIO i . The smartcard computes Then, the smartcard checks whether B * i ? = 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 ⊕ N i , VU i = h(X i ||N i ||GID j ). Finally, U i sends the login request message {HID i , C i , VU 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 = GI j ⊕ N j , VS j = h(GID j ||GI j ||N j ). Then, G j sends the login request message {HID i , C i , PID j , D i , VS j } to CS via an open channel.
Step 3: After CS receives the login request message from G j , CS computes GI j = h(PID j ||h(x||y)), N j = D i ⊕ GI j and compares VS * j ? = VS j to see whether G j 's login request message is legitimate. If it is equal, CS retrieves U I i from the verifier table using H ID i of the login request message. Then, CS computes X i = h(U I i ||x), = VU i to check that the message from U i is valid. If it is valid, CS generates a random number N c and computes E i = GI j ⊕ N c , F i = GI j ⊕ N i . CS computes M cg = h(E i ||GI j ||N c ) to mutually authenticate with G j and M cu = h(X i ||U I i ||N i ) to authenticate with U i and generates a session key Step 4: After G j receives the authentication message from CS, G j computes N c = E i ⊕ GI j , M * cg = h(E i ||GI j ||N c ).Then, G j compares M * cg ? = M cg to verify whether the message from CS is legitimate. If it is valid, G j computes N i = F i ⊕ GI j and generates a session key Step 5: After receiving the message from G j , and generates a session key SK = h(N i ⊕ h(N j ||N c )). Therefore, U i , S j , and CS generate the same session key, so they can perform the authentication.

Password Change Phase
If U i wants to change his/her password, U i performs the password change phase without the help of G j . The detailed steps of the password change phase are shown in Figure 7 and described as follows.
Step 1: A legitimate user U i inserts the smartcard, his/her ID i and PW i , and biometric BIO i .
Step 2: The smartcard computes < R 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 PW new i .
Step 4: After receiving the new password from U i , the smartcard computes L new  Figure 7. Password change phase of our proposed protocol.

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.

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.

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 {HID i , C i , VU i } and message {H i , M cu }. However, U a cannot compute H ID i because U a cannot extract a random number a i from H ID 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 , VU i because U a cannot extract a random number N i . Therefore, our protocol resists user impersonation attack.

Server Spoofing Attack
To impersonate the server, an attacker U a can generate an authentication message {H i , M cu }. However, U a cannot compute these because U a cannot know the random nonces N i , N j , N c . Furthermore, if U a attempts to impersonate the gateway by using public parameter GID 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.

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 ID i , PW i , HPW i = h(ID i ||PW i ||a i ). Therefore, our protocol can prevent smartcard stolen attacks.

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 ID i via the public channels. The user generates and sends a pseudonym identity H ID i = h(ID i ||a i ). Because H ID i is a transmitted message via a public channel, U a can obtain this value. Therefore, U i updates it as H ID new i = h(H ID i ||N i ||h(N j ||N c )) for every session to prevent the attack of U a . The gateway uses PID j , which is generated in the registration phase, instead of GID 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.

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.

Off-Line Password Guessing Attack
An attacker U a attempts to guess the password PW 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.

Mutual Authentication
When control server CS receives the login request message from gateway G j , CS computes VS * j and VU * i to authenticate user U i and G j . If VS j and VS * j are equal, CS authenticates G j . Furthermore, CS retrieves U i from a database to an available VS j . After that, CS compares VU i and VU * i . If they are equal, CS authenticates U i . Then, CS computes and sends the login response messages M cg and M cu to authenticate. After receiving M cg from CS, G j computes M * cg and compares M * cg and M cg . If they are equal, G j authenticates CS. Finally, U i computes M * cu and checks whether M * cu ? = M cu . If it is valid, U i authenticates CS. Therefore, U i , G j , and CS successfully mutually authenticate. An attacker cannot validate the message, as mentioned in Sections 7.1.1 and 7.1.2. Moreover, the login request and response messages are refreshed for every session according to Sections 7.1.4 and 7.1.5. Therefore, our proposed protocol provides secure mutual authentication.

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 CS. More details of BAN logic can be found in [23,24]. Table 3. Notations of Burrows-Abadi-Needham (BAN) logic.

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

Rules of Ban Logic
We introduce rules of BAN logic as follows:

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

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

Proof Using Ban Logic
The following steps are the main proofs using BAN rules and assumptions: Step 1: According to Msg 1 , we can get Step 2: From A 1 and S 1 , we apply the message meaning rule to obtain Step 3: From A 2 and S 2 , we apply the freshness rule to obtain Step 4: From S 2 and S 3 , we apply the nonce verification rule to obtain Step 5: From S 4 , we apply the belief rule to obtain Step 6: According to Msg 2 , we can get Step 7: From A 3 and S 6 , we apply the message meaning rule to obtain Step 8: From A 4 and S 7 , we apply the freshness rule to obtain Step 9: From S 7 and S 8 , we apply the nonce verification rule to obtain Step 10: From S 9 , we apply the belief rule to obtain Step 11: According to Msg 2 , we can get Step 12: From A 5 and S 11 , we apply the message meaning rule to obtain Step 13: From A 6 and S 12 , we apply the freshness rule to obtain Step 14: From S 12 and S 13 , we apply the nonce verification rule to obtain Step 15: From S 14 , we apply the belief rule to obtain Step 16: According to Msg 4 , we can obtain Step 17: From A 6 and S 16 , we apply the message meaning rule to obtain Step 18: From A 7 and S 17 , we apply the freshness rule to obtain Step 19: From S 17 and S 18 , we apply the nonce verification rule to obtain Step 20: From S 19 , we apply the belief rule to obtain Step 21: From S 10 and A 8 , we apply the jurisdiction rule to obtain Step 22: From S 15 and A 9 , we apply the jurisdiction rule to obtain Step 23: From S 20 and A 10 , we apply the jurisdiction rule to obtain We show that the proposed protocol can provide secure mutual authentication between U i , G j , and CS based on goals 1-6.

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.

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

Hlpsl Specifications of Our Protocol
Our protocol has three basic roles which are denoted by entities that have been specified according to HLPSL: U A denotes a user, GA denotes a gateway, and CS denotes a control server. The role of session and environments are shown in Figure 8. In the session, we describe participants. In environments, intruder knowledge is defined, and four secrecy goals and four authentication goals are described. The HLPSL specifications of role 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 {HID i , HPW i , a} to CS through a closed channel. At transition 2, U A receives the smartcard from CS, 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 {HID i , C i , VU i } to GA via an insecure channel, and declares witness(U A, CS, us_cs_ni, N i ), which means that N i denotes a weakness authentication factor. At transition 3, U A receives the login response message from GA. After that, U A changes the state value from 2 to 3, generates the session key, and declares request(U A, CS, cs_ua_mcu, N c ). The specifications of role GA and CS are similar and shown in Figures 10 and 11

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.

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

•
T me : The times for modular exponential operation (≈0.522 s [33,34]) • T h : The times for one-way hash operation (≈0.0005 s [33,34]) • T f : The times for fuzzy extraction operation (≈0.063075 s [34,35]) Table 4 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.

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.

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. x: does not prevent the property; o: prevents the property; -: does not concern the property.

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.