Next Article in Journal
Detection of Type, Blended Ratio, and Mixed Ratio of Pu’er Tea by Using Electronic Nose and Visible/Near Infrared Spectrometer
Next Article in Special Issue
A Strongly Unforgeable Certificateless Signature Scheme and Its Application in IoT Environments
Previous Article in Journal
Direction of Arrival Estimation in Elliptical Models via Sparse Penalized Likelihood Approach
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

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

1
School of Electronics Engineering, Kyungpook National University, Daegu 41566, Korea
2
IT Conversions, Korea Nazarene University, Cheonan, Chungcheongnam-do 31172, Korea
*
Authors to whom correspondence should be addressed.
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)

Abstract

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

1. Introduction

Internet of Things (IoT) provides numerous types of services through the internet to exchange data among sensors, embedded systems, and mobile devices. In recent years, IoT environments such as smart buildings, smart factories, smart homes, and smart offices are rapidly becoming a part of our life. A typical IoT architecture consists of heterogeneous micro devices and collects various types of information in real time. However, this is not efficient for practical IoT systems because the communication and computation cost can be increased when the size of IoT networks and the distance between participants are expanded [1,2]. The gateway nodes are deployed to enhance the performance, which provides the ability to communicate with each other efficiently. In a multi-gateway IoT environment, many gateway nodes are deployed and it can process the capability of large-scale IoT networks. IoT environments are also vulnerable to various attacks due to the nature of the open communication channel. Malicious attackers may attempt to insert, delete, and modify the data to obtain users’ sensitive information and masquerade as valid users. Much research has been done to resolve security problems in IoT environments. Secure mutual authentication is a primitive and essential method to provide secure communication and numerous secure mutual authentication protocols for IoT have been presented to provide various security features [2,3,4,5,6,7,8,9,10,11,12,13,14,15,16].
In 2017, Bae et al. [15] proposed a smartcard-based secure authentication protocol in multi-gateway IoT environments to reduce the computational and communication cost. However, we demonstrate that Bae et al.’s protocol is vulnerable to user impersonation, gateway spoofing, and trace and session key disclosure attacks, and does not provide anonymity and a secure mutual authentication. Then, we propose a three-factor authentication protocol that is based on the biometric information of the user, for IoT environments. To analyze the security aspects, we perform an informal security analysis and use Burrows–Abadi–Needham (BAN) logic. Furthermore, we perform a formal security verification using Automated Validation of Internet Security Protocols and Applications (AVISPA) software to check that our protocol can resist man-in-the-middle attacks and replay attacks. We compare the computation cost and security features of our proposed protocol with those of related existing protocols.
The remainder of this paper is as follows. In Section 2 and Section 3, we introduce related works and our preliminary details. In Section 4 and Section 5, we review Bae et al.’s protocol and cryptanalyze its security flaws. Then, we propose a secure three-factor mutual authentication protocol for multi-gateway IoT environments in Section 6. In Section 7, we prove that our proposed protocol provides a secure mutual authentication using BAN logic. We also perform the AVISPA simulation as a formal security verification and compare the computation cost and security properties with related protocols in Section 8 and Section 9. Finally, we conclude with the results of this paper in Section 10.

2. Related Works

Various authentication protocols in single server environments have been proposed [3,4,5]. In 2010, Wu et al. [3] presented a novel authentication protocol for the telecare medical information system (TMIS). Their protocol provides a guarantee to legitimate users. However, Debiao et al. [6] demonstrated that Wu et al.’s protocol cannot withstand several attacks such as impersonation, replay, or man-in-the-middle attacks. Debiao et al. proposed a more safe and efficient remote authentication protocol for TMIS. In 2013, Chang et al. proposed a secure authentication protocol that provided users privacy. But, in 2103, Das et al. [7] showed that their protocol cannot provide several security features and proper authentication. Furthermore, these authentication protocols are not suitable for distributed systems that consist of multiple servers, such as IoT environments, because the users who want to access the IoT services have to know as many identities and passwords as the number of servers [8,9]. In addition, the physical performance of a single server has limitations [17], and IoT environments are resource-constrained. Therefore, multi-gateway (multi-server) IoT environments are more efficient and useful than the traditional IoT structure [1,2,10,13,14,15,16].
In 2014, Turkanovic et al. [5] presented an authentication protocol for IoT environments. However, in 2016, Amin and Biswas [10] pointed out that Turkanovic et al.’s protocol does not withstand several attacks such as offline identity and password guessing, impersonation, and stolen smartcard attacks. They also demonstrated that Turkanovic et al.’s protocol has an inefficient authentication phase. Then, Amin and Biswas proposed an authentication protocol for multi-gateway wireless sensor networks. In 2017, Wu et al. [1] proved that Amin and Biswas’s protocol does not resist sensor capture, offline guessing, session key disclosure, impersonation, and desynchronization attacks. They also proved that Amind and Biswas’s protocol does not withstand user tracking attacks and does not achieve mutual authentication. Then, Wu et al. proposed a mutual authentication and key agreement protocol for multi-gateway wireless sensor network in IoT. In the same year, Srinivas et al. [13] also proved that Amin and Biswas’s protocol has security flaws. Srinivas et al. pointed out that sensor devices have low power, limited memory, and limited battery. Thereafter, Srinivas et al. proposed a more secure and efficient remote user authentication protocol for multi-gateway wireless sensor networks that are suitable for IoT environments.
In 2016, Das et al. [10] presented a three-factor multi-gateway-based user authentication protocol for wireless sensor networks. Das et al. suggested the multi-gateway environment for wireless sensor networks because the generalized wireless sensor networks can bring a lot of overhead to the gateway and have more power consumption than multi-gateway-based wireless sensor networks. They demonstrated that their protocol can withstand attacks such as sensor capture, privileged-insider, offline password guessing, and impersonation attacks. However, Wu et al. [1] pointed out that Das et al.’s protocol does not resist user tracking attacks and does not have a same session key for all three participants.
In 2018, Wu et al. [14] proposed an authentication protocol for healthcare systems in multi-gateway wireless medical sensor networks. Their protocol prevents malicious attacks such as patient tracking, insider, and offline guessing attacks. Wu et al. demonstrated that multi-gateway environments are suitable for collecting patients’ health data through wireless health sensors because the gateway in each area collects the information of patients in the area and then sends it to the doctor. They also demonstrated that their protocol is suitable for transferring data with low time and communication costs.
In 2017, Bae et al. [15] proposed a smartcard-based secure authentication protocol in multi-gateway IoT environments to reduce the computational and communication cost. However, their protocol does not resist impersonation, gateway spoofing, traceability, and session key disclosure attacks and does not guarantee secure mutual authentication and anonymity.

3. Preliminaries

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

3.1. Threat Model

We adopt the Dolev–Yao (DY) threat model [18] to analyze Bae et al.’s protocol and our proposed protocol. This model is popularly applied to estimate security. The general assumptions of the DY threat model are as below:
  • An attacker can eavesdrop, delete, modify, or insert the transmitted messages via an insecure channel.
  • An attacker can steal the smartcard or use a lost smartcard to extract the sensitive information stored in the smartcard [19].
  • An attacker can perform various attacks such as trace, impersonation, smartcard lost, man-in-the-middle, replay attacks, and so on.

3.2. Fuzzy Extraction

We briefly show a description of the fuzzy extractor [20] that can extract key information from the given biometric data of users. Biometric information is weak to noises and it is hard to reproduce the actual biometrics from biometric templete in common practice. Moreover, the hash function is sensitized to input, so completely different outputs may come out. Because of these problems, we use the fuzzy extractor method [21,22], which is a type of key generating designed to convert noisy data to public information and a secret random string. The fuzzy extractor restores the original biometric information for noisy biometric data using public help information. The algorithms of the fuzzy extractor are as follows:
  • 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 = ? 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 h ( x ) 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 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 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 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 = ? 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 h ( x ) A i , V e r u i = h ( h ( x ) N i 1 ) . If V e r u i = ? 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 ) ) h ( N i 1 N i 2 N i 3 ) ) . C S generates time stamp T s and computes C i = N i 1 N i 3 h ( S I D j N i 2 ) , D i = h ( A i h ( x ) ) h ( S I D j N i 2 ) , E i = N i 2 N i 3 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 N i 3 ) = C i h ( S I D j N i 2 ) , h ( A i | | h ( x ) ) = D i h ( S I D j N i 2 ) . S j generates a session key S K = h ( h ( A i | | h ( x ) ) h ( N i 1 N i 2 N i 3 ) ) . Then, S j computes E i = ( N i 2 N i 3 ) 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 T s - T s . If it is correct, U i computes ( N i 2 N i 3 ) = E i h ( A i h ( x ) ) and generates a session key S K = h ( h ( A i h ( x ) ) h ( N i 1 N i 2 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

If 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 = ? 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 U s e r i n f o r i 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 h ( x ) 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 N i 3 ) . After that, U a computes E i = ( N i 2 N i 3 ) 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 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 ) ) h ( N i 1 N i 2 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 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 ) 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 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 h ( H P W i ) , B i * = h ( U I i A i ) . 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 , 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 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 G I j and compares V S j * = ? 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 U I i , V U i * = h ( X i N i G I D j ) . Then C S compares V U i * = ? 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 N c , F i = G I j 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 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 G I j , M c g * = h ( E i G I j N c ) .Then, G j compares M c g * = ? M c g to verify whether the message from C S is legitimate. If it is valid, G j computes N i = F i G I j and generates a session key S K = h ( N i h ( N j N c ) ) . Then, G j computes G i = h ( G I D j N i ) , H i = G i 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 * = ? 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 G i * and generates a session key S K = h ( N i 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 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

If U i wants to change his/her password, U i performs the password change phase without the help of G j . The detailed steps of the password change phase are shown in Figure 7 and described as follows.
Step 1:
A legitimate user U i inserts the smartcard, his/her I D i and P W i , and biometric B I O i .
Step 2:
The smartcard computes < R i , P i > = G e n ( B I O i ) , a i = L i 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 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 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 * = ? 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:
    P | P K Q , P X K P Q X
  • Nonce verification rule:
    P # ( X ) , P Q | X P Q X
  • Jurisdiction rule:
    P Q X , P Q X P | X
  • Freshness rule:
    P | # ( X ) P | # X , Y
  • Belief rule:
    P | X , Y P | X

7.2.2. Goals

We present the following goals to prove that our protocol achieves secure mutual authentication:
Goal 1:
G j | C S | ( N c , N i ) ,
Goal 2:
G j | ( N c , N i ) ,
Goal 3:
C S | G j | ( N i , N j ) ,
Goal 4:
C S | ( N i , N j ) ,
Goal 5:
U i | G j | ( N c , N i ) ,
Goal 6:
U i | ( N j , N c )

7.2.3. Idealized Forms

M s g 1 :
U i G j : ( H I D i , N i , x , G I D j ) U I i
M s g 2 :
G j C S : ( H I D i , N i , x , G I D j , N j ) G I j
M s g 3 :
C S G j : ( N c , N i , U I i , x ) G I j
M s g 4 :
G j 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 | ( U i U I i G j )
A 2 :
G j | # ( N i )
A 3 :
C S | ( G j G I j C S )
A 4 :
C S | # ( N j , N i )
A 5 :
G j | ( G j G I j C S )
A 6 :
U i | ( U i N i G j )
A 7 :
U i | # ( N j )
A 8 :
C S | G j ( C S 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 | 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 | # ( 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 | U i ( 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 | U i | ( 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 | 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 | # ( 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 | G j | ( 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 | G j | ( 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 | 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 | # ( 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 | C S | ( 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 | C S | ( 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 | 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 | # 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 | G j | ( 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 | G j | ( 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 | ( 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 | ( 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 | ( 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 } to 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 } to 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

  1. 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]
  2. 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]
  3. 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]
  4. 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]
  5. 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]
  6. 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]
  7. 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]
  8. 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]
  9. 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]
  10. 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]
  11. Lin, C.H.; Lai, Y.Y. A flexible biometrics remote user authentication scheme. Comput. Stand. Interfaces 2004, 27, 19–23. [Google Scholar] [CrossRef]
  12. 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]
  13. 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]
  14. 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]
  15. Bae, W.; Kwak, J. Smart card-based secure authentication protocol in multi-server IoT environment. Multimed. Tools. Appl. 2017, 1–19. [Google Scholar] [CrossRef]
  16. 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]
  17. 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]
  18. Dolev, D.; Yao, A.C. On the security of public key protocols. IEEE Trans. Inf. Theory 1983, 29, 198–208. [Google Scholar] [CrossRef]
  19. 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]
  20. 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]
  21. Burnett, A.; Byrne, F.; Dowling, T.; Duffy, A. A biometric identity based signature scheme. Int. J. Netw. Secur. 2007, 5, 317–326. [Google Scholar]
  22. 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]
  23. 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]
  24. 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]
  25. 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]
  26. 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]
  27. 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]
  28. 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]
  29. 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]
  30. 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]
  31. AVISPA. Automated Validation of Internet Security Protocols and Applications. Available online: http://www.avispa-project.org/ (accessed on 11 January 2019).
  32. SPAN: A Security Protocol Animator for AVISPA. Available online: http://www.avispa-project.org/ (accessed on 11 January 2019).
  33. 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]
  34. 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]
  35. 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 1. System model of our protocol in multi-gateway IoT environments.
Sensors 19 02358 g001
Figure 2. Registration phase of Bae et al.’s protocol.
Figure 2. Registration phase of Bae et al.’s protocol.
Sensors 19 02358 g002
Figure 3. Login and authentication phase of Bae et al.’s protocol.
Figure 3. Login and authentication phase of Bae et al.’s protocol.
Sensors 19 02358 g003
Figure 4. Password change phase of Bae et al.’s protocol.
Figure 4. Password change phase of Bae et al.’s protocol.
Sensors 19 02358 g004
Figure 5. Registration phase of our proposed protocol.
Figure 5. Registration phase of our proposed protocol.
Sensors 19 02358 g005
Figure 6. Login and authentication phase of our proposed protocol.
Figure 6. Login and authentication phase of our proposed protocol.
Sensors 19 02358 g006
Figure 7. Password change phase of our proposed protocol.
Figure 7. Password change phase of our proposed protocol.
Sensors 19 02358 g007
Figure 8. Specification of session and environments.
Figure 8. Specification of session and environments.
Sensors 19 02358 g008
Figure 9. Specification of user.
Figure 9. Specification of user.
Sensors 19 02358 g009
Figure 10. Specification of gateway.
Figure 10. Specification of gateway.
Sensors 19 02358 g010
Figure 11. Specification of control server.
Figure 11. Specification of control server.
Sensors 19 02358 g011
Figure 12. The result of Automated Validation of Internet Security Protocols and Applications (AVISPA) simulation using OFMC and CL-AtSe.
Figure 12. The result of Automated Validation of Internet Security Protocols and Applications (AVISPA) simulation using OFMC and CL-AtSe.
Sensors 19 02358 g012
Table 1. Notations.
Table 1. Notations.
NotationsMeanings
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
xMaster 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.
Table 2. The verifier table.
User-VerifierAnonymity ValueStatus-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
U s e r i n f o r i U i 0 / 1
Table 3. Notations of Burrows–Abadi–Needham (BAN) logic.
Table 3. Notations of Burrows–Abadi–Needham (BAN) logic.
NotationsMeaning
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 K 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.
Table 4. Computation cost of the login and authentication phase.
ProtocolsUserGatewayControl ServerTotal 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 )
Ours1 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.
Table 5. Communication cost.
ProtocolsCommunication 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
Ours2400 bits
Table 6. Security properties.
Table 6. Security properties.
Security PropertyTurkanovic et al. [5]Wu et al. [3]Amin and Biswas [10]Bae et al. [15]Ours
User impersonation attackxxoxo
Server spoofing attackoxxxo
Smartcard stolen attackxxxxo
Trace attackxxxxo
Off-line password guessing attackxoxoo
Replay attackooooo
Man-in-the-middle attackooooo
Desynchronization attack--x-o
Anonymityxxxoo
Mutual authenticationxxoxo
x: does not prevent the property; o: prevents the property; -: does not concern the property.

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://0-doi-org.brum.beds.ac.uk/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://0-doi-org.brum.beds.ac.uk/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://0-doi-org.brum.beds.ac.uk/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 Metrics

Back to TopTop