Advertisement
Browse Subject Areas
?

Click through the PLOS taxonomy to find articles in your field.

For more information about PLOS Subject Areas, click here.

  • Loading metrics

Open Access

Peer-reviewed

Research Article

An Enhanced Biometric Based Authentication with Key-Agreement Protocol for Multi-Server Architecture Based on Elliptic Curve Cryptography

  • Alavalapati Goutham Reddy,

    Affiliation School of Computer Science and Engineering, Kyungpook National University, Daegu, Korea

    ⨯
  • Ashok Kumar Das,

    Affiliation Center for Security, Theory and Algorithmic Research, International Institute of Information Technology, Hyderabad, India

    ⨯
  • Vanga Odelu,

    Affiliation Department of mathematics, Indian Institute of Technology, Kharagpur, India

    ⨯
  • Kee-Young Yoo

    yook@knu.ac.kr

    Affiliation School of Computer Science and Engineering, Kyungpook National University, Daegu, Korea

    ⨯

Abstract

Biometric based authentication protocols for multi-server architectures have gained momentum in recent times due to advancements in wireless technologies and associated constraints. Lu et al. recently proposed a robust biometric based authentication with key agreement protocol for a multi-server environment using smart cards. They claimed that their protocol is efficient and resistant to prominent security attacks. The careful investigation of this paper proves that Lu et al.’s protocol does not provide user anonymity, perfect forward secrecy and is susceptible to server and user impersonation attacks, man-in-middle attacks and clock synchronization problems. In addition, this paper proposes an enhanced biometric based authentication with key-agreement protocol for multi-server architecture based on elliptic curve cryptography using smartcards. We proved that the proposed protocol achieves mutual authentication using Burrows-Abadi-Needham (BAN) logic. The formal security of the proposed protocol is verified using the AVISPA (Automated Validation of Internet Security Protocols and Applications) tool to show that our protocol can withstand active and passive attacks. The formal and informal security analyses and performance analysis demonstrates that the proposed protocol is robust and efficient compared to Lu et al.’s protocol and existing similar protocols.

Citation: Reddy AG, Das AK, Odelu V, Yoo K-Y (2016) An Enhanced Biometric Based Authentication with Key-Agreement Protocol for Multi-Server Architecture Based on Elliptic Curve Cryptography. PLoS ONE 11(5): e0154308. https://doi.org/10.1371/journal.pone.0154308

Editor: Wen-Bo Du, Beihang University, CHINA

Received: February 16, 2016; Accepted: April 11, 2016; Published: May 10, 2016

Copyright: © 2016 Reddy et al. This is an open access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.

Data Availability: Data are available at FigShare. DOI: 10.6084/m9.figshare.3204307; Link: https://figshare.com/s/1601551aea604ca5cec2.

Funding: This work was supported by the BK21 Plus project (SW Human Resource Development Program for Supporting Smart Life) funded by the Ministry of Education, School of Computer Science and Engineering, Kyungpook National University, Korea (21A20131600005), and Institute for Information & communications Technology Promotion (IITP) grant funded by the Korea government (MSIP) [No. 10041145, Self-Organized Software platform (SoSp) for Welfare Devices].

Competing interests: The authors have declared that no competing interests exist.

Introduction

The swift expansion of communication technologies and handheld devices have necessitated the authentication of every remote user. Authentication process verifies the legitimacy of each user and offers the access to network resources. Password, smartcard and biometrics based authentication are the few common technologies deployed until today. The first remote user password based authentication method was proposed by Lamport [1] in 1981 for communication over insecure channels. However, password based authentication methods are elusive and prone to guessing attacks. Thus, the password with smartcard based methods have come into sight. Conversely, research has shown that password with smartcard based authentication methods are still prone to numerous attacks when the smartcard is stolen. The ascribed limitations of password and smartcard based authentication methods have imposed to install additional security methods such as biometrics. Biometric keys such as palm print, iris, finger print, face and so on are unique and secure. Biometrics with smartcards or passwords makes the authentication process very robust due to the following features [2] [3]:

  • Biometric keys are non-forgeable and non-distributable.
  • Biometric keys cannot be lost nor forgotten.
  • It is extremely difficult to guess biometric keys unlike passwords.
  • Breaking someone’s biometrics is extremely difficult.

Few authentication technologies have used smartcards or biometrics or the both along with passwords [4–23]. Earlier authentication methods were limited to single-server architecture. This architecture is not adequate when the number of users with varied interests and open networks keep increasing. On the other hand, users are required to register at every server in order to avail the services, which is extremely tedious and adds the cost enormously. As a scalable solution, multi-server architecture has been introduced, where the users can register only once at the registration server and avail the services of all associated application servers. Several authors have suggested various authentication protocols for multi-server architecture during the past decade [24–46].

In 2009, Liao et al. [38] proposed a secure dynamic ID based remote user authentication protocol for multi-server environment. In the same year, Hsiang et al. [28] presented that Liao & Wang’s protocol is prone to server and registration center spoofing attacks, insider attacks and masquerade attacks. Furthermore, they proposed an improved dynamic identity based mutual authentication without verification tables. In 2011, Sood et al. [42] proved that Hsiang et al.’s protocol is also vulnerable to impersonation attacks, stolen smart card attacks and replay attacks. In addition, they improved the weaknesses of Hsiang et al.’s protocol and proposed a protocol with different levels of trust between two-servers. In 2012, Li et al. [35] found that Sood et al.’s protocol is susceptible to impersonation attacks, stolen smart card attacks and leak-of-verifier attacks. Then, they proposed an efficient dynamic identity based authentication protocol with smart cards and claimed that it overcomes all aforementioned drawbacks. However, in 2014, Xue et al. [45] proved that Li et al.’s protocol still cannot resist forgery attacks, eavesdropping attacks, denial-of-service attacks and so on. They even put forward a lightweight dynamic pseudonym identity based authentication and key agreement protocol without verification tables for multi-server architecture. In the same year, Chuang et al. [25] proposed an anonymous multi-server authenticated key agreement protocol based on trust computing using smartcards and biometrics. Their protocol is light-weight and provides multi-server authentication with user anonymity. Later on, Mishra et al. [2] in 2014 and Lin et al. [39] in 2015 pointed out several drawbacks of Chuang et al.’s protocol and proposed a secure anonymous three factor authentication protocol. In 2015, Lu et al. [40] proved that Mishra et al.’s protocol was too vulnerable to replay attacks and contains an insecure password changing phase. They proposed a robust biometric based authentication protocol for multi-server architecture.

Contributions of the paper

Achieving several security properties while maintaining the best performance is essential for any user authentication protocol. Several recent proposed protocols fail to satisfy security and performance properties. One of such protocols is Lu et al.’s robust biometric based authentication protocol for multi-server architecture. This paper’s keen analysis demonstrates the weaknesses of Lu et al.’s protocol such as lack of user anonymity, prone to server and user impersonation attacks, man-in-middle attacks, no perfect forward secrecy and clock synchronization problems. In addition, this paper proposes an enhanced biometric based remote user authentication with key agreement protocol for multi-server architecture without user verification tables. The proposed protocol is perfectly suitable for real time applications as it accomplishes simple elliptic curve cryptography operations, one-way hash functions, concatenation operations and exclusive-OR operations. The proposed protocol is not only light-weight but also achieves all the eminent security properties such as user anonymity, mutual authentication, no verification tables, perfect forward secrecy and resistance to numerous attacks. We proved that the proposed protocol can achieve mutual authentication using BAN logic [47] and the formal security of the proposed protocol is verified using the widely accepted AVISPA tool [48] to ensure the resistance to active and passive attacks. The security and performance analysis sections demonstrates that the proposed protocol is more robust and efficient than Lu et al.’s protocol and other existing protocols.

Organization of the paper

The remainder of the paper is organized as follows: Section 2 shows the preliminaries used in this paper. Section 3 provides the review of Lu et al.’s protocol. Section 4 crypt analyses Lu et al.’s protocol. Section 5 presents the proposed protocol. Section 6 portrays formal security analysis using BAN logic and informal security analysis of the proposed protocol in detail. In Section 7, the simulation for the formal security verification of the proposed protocol using the AVISPA tool shows that the proposed protocol is secure. Section 8 affords performance analysis and comparison with the related protocols. At last, Section 9 concludes the paper.

Review of Lu et al.’s Protocol

This section provides an overview of Lu et al.’s [40] biometrics based authentication with key-agreement protocol for multi-server architecture using smartcards. Lu et al.’s protocol comprises three participants, user (Ui), authorized server (Sj), registration center (RC) and four phases, registration phase, login phase, authentication phase, and password change phase. RC initializes the system by sharing the chosen secret key PSK and random number x with Sj via a secure channel. The various notations used in Lu et al.’s protocol are listed in Table 1.

thumbnail
Download:
Table 1. Notations of Lu et al.’s protocol.

https://doi.org/10.1371/journal.pone.0154308.t001

Registration phase

User (Ui) can register at registration center (RC) for the first time as shown in Fig 1.

  1. Step 1: Ui chooses an identity IDi, password PWi and computes h(PWi || H(BIOi)). Then sends a request message < IDi, h(PWi || H(BIOi)) > to RC via a secure channel.
  2. Step 2: RC computes Xi = h(IDi || x), Vi = h(IDi || h(PWi || H(BIOi))). Then RC stores the parameters {Xi, Vi, h(PSK)} on a smartcard and delivers it to Ui via a secure channel.
  3. Step 3: Upon receiving the smartcard from RC, Ui computes Yi = h(PSK) ⊕ y, and replaces h(PSK) with Yi. Thus, the smartcard contains {Xi, Yi, Vi, h(.)}.
thumbnail
Download:
Fig 1. Registration phase of Lu et al.’s protocol.

https://doi.org/10.1371/journal.pone.0154308.g001

Login and authentication phases

In this phase, user (Ui) and server (Sj) authenticates each other, and also establishes a session between them as shown in Fig 2. Ui can launch the login request by inserting smartcard, inputs IDi, PWi and BIOi.

  1. Step 1: Smartcard computes h(PWi || H(BIOi)) and then verifies the condition Vi ≟ h(IDi || h(PWi || H(BIOi))). If it generates negative result, the login request can be terminated.
  2. Step 2: Smartcard generates a random number n1, timestamp T1 and computes K = h((Yi ⊕ y) || SIDj), M1 = K ⊕ IDi, M2 = n1 ⊕ K, M3 = K ⊕ h(PWi || H(BIOi)), Zi = h(Xi || n1 || h(PWi || H(BIOi)) || T1), and sends the request message < Zi, M1, M2, M3, T1 > to Sj.
  3. Step 3: Sj checks the freshness of the request message by verifying Tc−T1 ≤ ΔT. If it holds, then Sj computes K = h(h(PSK) || SIDj)) to retrieve IDi = K ⊕ M1, n1 = M2 ⊕ K, h(PWi || H(BIOi)) = K ⊕ M3. Now, Sj computes Xi = h(IDi || x) and verifies Zi ≟ h(Xi || n1 || h(PWi || H(BIOi)) || T1). If the condition holds, then Sj authenticates Ui, otherwise process aborts.
  4. Step 4: Sj further generates a random number n2, timestamp T2 and computes SKji = h(n1 || n2 || K || Xi), M4 = n2 ⊕ h(n1 || h(PWi || H(BIOi)) || Xi), M5 = h(IDi || n1 || n2 || K || T2). Sj sends the response < M4, M5, T2 > to Ui.
  5. Step 5: Ui checks the freshness of the message by verifying Tc−T2 ≤ ΔT. If it holds, then Ui computes n2 = M4 ⊕ h(n1 || h(PWi || H(BIOi)) || Xi) and checks M5 ≟ h(IDi || n1 || n2 || K || T2). If it generates positive result, then Ui authenticates Sj, otherwise process aborts.
  6. Step 6: Ui generates a timestamp T3 and computes SKij = h(n1 || n2 || K || Xi), M6 = h(SKij || IDi || n2 || T3). Finally, Ui sends < M6, T3 > to Sj.
  7. Step 7: Sj verifies the freshness of T3 and M6 ≟ h(SKij || IDi || n2 || T3). If it holds, then the mutual authentication with key agreement process between Ui and Sj is completed.
thumbnail
Download:
Fig 2. Login and authentication phases of Lu et al.’s protocol.

https://doi.org/10.1371/journal.pone.0154308.g002

Password changing phase

A user (Ui) can update his/her existing password with new one without the help of registration center (RC) as explained below.

  1. Step 1: Ui inserts smartcard, inputs the identity IDi, password PWi, scans the biometrics BIOi and then verifies the condition Vi ≟ h(IDi || h(PWi || H(BIOi))). If it holds, then Ui is allowed to choose a new password PWinew.
  2. Step 2: Smartcard computes Vinew ≟ h(IDi || h(PWinew || H(BIOi))) and replaces existing Vi with Vinew.

Cryptanalysis of Lu et al.’s Protocol

This section cryptanalyses Lu et al.’s [40] protocol and provides a detailed discussion of all security limitations. Lu et al. asserted that their protocol can withstand several renowned attacks while achieving important security features. Conversely, this section proves that their protocol consists of significant drawbacks.

Limitation 1: Prone to server impersonation attack

In Lu et al.’s protocol, an adversary Ӕ can impersonate as a legitimate server as elucidated here. During server registration phase of Lu et al.’s protocol, registration center RC shares the chosen secret key PSK and random number x with Sj via a secure channel. When an adversary’s server Ӕ registers with the RC, then after he/she can act as a legitimate server and access all the user’s valuable data due to the possession of common shared attributes x and PSK in following way:

  1. Step 1: During login and authentication phase, Ui launches the authentication request < Zi, M1, M2, M3, T1 > by inserting smartcard and inputting IDi, PWi and BIOi.
  2. Step 2: Upon receiving the request from Ui, Ӕ computes K = h(h(PSK) || SIDj)), IDi = K ⊕ M1, n1 = M2 ⊕ K, h(PWi || H(BIOi)) = K ⊕ M3, Xi = h(IDi || x).
  3. Step 3: Now, Ӕ generates a random number n2, timestamp T2 and computes SKji = h(n1 || n2 || K || Xi), M4 = n2 ⊕ h(n1 || h(PWi || H(BIOi)) || Xi), M5 = h(IDi || n1 || n2 || K || T2). Ӕ sends the response < M4, M5, T2 > to Ui.
  4. Step 4: Ui checks the freshness of the message by computing Tc−T2 ≤ ΔT. If it holds, then Ui computes n2 = M4 ⊕ h(n1 || h(PWi || H(BIOi)) || Xi) and verifies M5 ≟ h(IDi || n1 || n2 || K || T2). It is obvious that the condition holds, consequently Ui treats Ӕ as legitimate Sj.
  5. Step 5: Ui generates a timestamp T3 and computes SKij = h(n1 || n2 || K || Xi), M6 = h(SKij || IDi || n2 || T3). Finally, Ui sends < M6, T3 > to Ӕ.

Now, Ui may start the communication with Ӕ using the computed session key SKij = h(n1 || n2 || K || Xi) but then is unaware of impersonation attack by Ӕ.

Limitation 2: Prone to man-in-middle attack

Lu et al.’s protocol is susceptible to man-in-middle attack while disclosing user’s personal valuable data such as IDi and h(PWi || H(BIOi)) as presented here. Assume a legitimate user who contains h(PSK) becomes an adversary Ӕ, then he/she can cause possible damage to the system which is explained in the prone to user impersonation attack subsection.

  1. Step 1: Consider a scenario where Ӕ capture the Ui’s message < Zi, M1, M2, M3, T1 > while sending to Sj during authentication phase.
  2. Step 2: Ӕ can compute K = h(h(PSK) || SIDj)) and obtain IDi = K ⊕ M1, n1 = M2 ⊕ K, h(PWi || H(BIOi)) = K ⊕ M3 by using h(PSK) and openly available SIDj values.
  3. Step 3: Now Ӕ comprises Ui’s personal identifiable information such as IDi and h(PWi || H(BIOi)) which are very unique.

Limitation 3: Prone to user impersonation attack

In a remote user communication protocol, anyone shall be treated as a legitimate user of the network if he/she has valid authentication credentials or could be able to construct a valid authentication request message. In Lu et al.’s protocol, an adversary Ӕ can impersonate a valid user as explained below.

  1. Step 1: As enlightened in prone to server impersonation attack and man-in-middle subsections, Ӕ can obtain Ui’s personal identifiable information such as IDi and h(PWi || H(BIOi)), and possesses x and PSK values.
  2. Step 2: Now, Ӕ generates a random number n1, timestamp T1 and computes K = h(h(PSK) || SIDj)), M1 = K ⊕ IDi, M2 = n1 ⊕ K, M3 = K ⊕ h(PWi || H(BIOi)), Xi = h(IDi || x), Zi = h(Xi || n1 || h(PWi || H(BIOi)) || T1). Ӕ sends the request < Zi, M1, M2, M3, T1 > to Sj.
  3. Step 3: Sj checks the freshness of the message by computing Tc−T1 ≤ ΔT. If it holds, then Sj computes K = h(h(PSK) || SIDj) to retrieve IDi = K ⊕ M1, n1 = M2 ⊕ K, h(PWi || H(BIOi)) = K ⊕ M3. Then, Sj computes Xi = h(IDi || x) and verifies Zi = h(Xi || n1 || h(PWi || H(BIOi)) || T1). It is obvious that all the conditions generates positive results and Sj treats Ӕ as legitimate Ui and proceeds further.
  4. Step 4: Sj generates a random number n2, timestamp T2 and computes SKji = h(n1 || n2 || K || Xi), M4 = n2 ⊕ h(n1 || h(PWi || H(BIOi)) || Xi), M5 = h(IDi || n1 || n2 || K || T2). Sj sends the response < M4, M5, T2 > to Ӕ.
  5. Step 5: Ӕ computes n2 = M4 ⊕ h(n1 || h(PWi || H(BIOi)) || Xi) and verifies M5 ≟ h(IDi || n1 || n2 || K || T2). Now, Ӕ generates a timestamp T3 and computes SKij = h(n1 || n2 || K || Xi), M6 = h(SKij || IDi || n2 || T3). Finally, Ӕ sends < M6, T3 > to Sj.
  6. Step 6: Sj verifies the freshness of T3 and M6 ≟ h(SKij || IDi || n2 || T3). Since M6 holds, Sj completes mutual authentication and allows Ӕ to access network services.

Limitation 4: Lack of user anonymity

Lu et al. claimed that their protocol can achieve one of the important security features called user anonymity. On the contrary, this subsection shows that their protocol cannot hold user anonymity property unlike their claim. During login and authentication phase, Ui transmits the authentication request message < Zi, M1, M2, M3, T1 > to Sj over public channels. The transmitted parameter M1 = K ⊕ IDi, where K = h((Yi ⊕ y) || SIDj)) in the message < Zi, M1, M2, M3, T1 > are unique for each user and static during all logins. Hence anyone can track the actions of valid users, if he/she captures M1 value.

Limitation 5: Lack of perfect forward secrecy

Forward secrecy ensures that session key is remaining safe, even if the long term private keys of communicating parties are compromised. In Lu et al. protocol, session key is computed as SKij = h(n1 || n2 || K || Xi). The involved parameters K and Xi are dependent on long term secret keys, and n1 and n2 are random numbers. As proved in server impersonation attack, when Sj’s long term secret keys x and PSK are compromised, then Ӕ can compute K = h(h(PSK) || SIDj)), Xi = h(IDi || x) and derive session key SKij = h(n1 || n2 || K || Xi) subsequently. Therefore, Lu et al. protocol does not achieve another vital security feature called perfect forward secrecy.

Limitation 6: Prone to clock synchronization problem

Lu et al. uses timestamps to avoid replay attacks on their protocol. The messages < Zi, M1, M2, M3, T1 > and < M4, M5, T2 > transmitted between Ui and Sj contains timestamps T1 and T2. Upon receiving these messages Sj and Ui checks the validity of timestamps by computing Tc−T1 ≤ ΔT and Tc−T2 ≤ ΔT. If these holds, then only Sj and Ui proceeds further to authenticate each other. In the current world, millions of users contain computing devices due to the greater deployment of networks and technology. It is extremely difficult to synchronize the local system clocks of such a large set of communicating devices. Even a tiny difference in the time could lead to failure of authenticating users. Thus, Lu et al.’s protocol is prone to clock synchronization problem.

The Proposed Protocol

This section proposes a lightweight biometric based remote mutual authentication with key agreement protocol for multi-server architecture using elliptic curve cryptography. The proposed protocol comprises three participants: user (Ui), application server (AS), registration server (RS) and six phases: registration server initialization phase, application server registration phase, user registration phase, login phase, mutual authentication with key agreement phase, and password and biometrics changing phase. The notations used in the proposed protocol are listed in Table 2.

thumbnail
Download:
Table 2. Notations of the proposed protocol.

https://doi.org/10.1371/journal.pone.0154308.t002

Registration server initialization phase

Registration server (RS) generates following parameters in order to initialize the system.

  1. Step 1: RS chooses an elliptic curve equation E with an order n.
  2. Step 2: RS selects a base point P over E and chooses a one-way cryptographic hash function h(.).
  3. Step 3: RS publishes the information {E, P, h(.)}.

Application server registration phase

In this phase, application server (AS) sends a registration request to the registration server (RS) in order to become an authorized server. The application server registration process consists of following steps:

  1. Step 1: AS computes public key RS = xS P sends registration request < SIDS, RS > to the RS.
  2. Step 2: RS computes KS = h(SIDS || PSK), where PSK is RS’s secret key for application servers and RS stores {SIDS, RS, KS} in its database table TUS.
  3. Step 3: RS sends KS to AS, which can be used in further phases of authentication.

User registration phase

A new user (Ui), who wants to avail the services provided by application servers must register with registration server (RS). Ui goes after the following steps to register at RS as shown in Fig 3.

  1. Step 1: Ui chooses an identity IDU, password PWU, a number b and scans biometrics BIO and computes AU = h(PWU || b), PIDU = h(IDU || b). Ui sends a request message < PIDU, AU > to RS via a secure channel.
  2. Step 2: RS computes BU = h(PIDU || USK), CUS = h(PIDU || KS) and DUS = AU ⊕ CUS, where USK is RS’s secret key for users.
  3. Step 3: RS personalize the parameters {BU, TUS, P, h(.)} on a smartcard and delivers it to Ui via a secure channel.
  4. Step 4: Ui computes EU = b ⊕ H(BIO), FU = BU ⊕ AU, GU = h(PIDU || b || BU) and stores EU, GU, FU on the received smart card after deleting BU from smartcard. Thus the smartcard finally contains the parameters {EU, GU, FU, TUS, P, h(.), H(.)}.
thumbnail
Download:
Fig 3. User registration phase.

https://doi.org/10.1371/journal.pone.0154308.g003

Login phase

When a user (Ui) wants to access the services of application server (AS), he/she launches the login request by inserting smartcard (SC), and inputting IDU, PWU and BIO.

  1. Step 1: SC →AS: < AIDU, M1, RU >

SC computes b = EU ⊕ H(BIO), AU = h(PWU || b), PIDU = h(IDU || b), BU = FU ⊕ AU and then verifies the condition GU ≟ h(PIDU || b || BU). If it generates negative result, the login request can be terminated. Otherwise, SC retrieves corresponding application server’s DUS and RS values from the table TUS. Then, SC generates a random number xU and calculates RU = xU P, RU′ = xU RS, CUS = AU ⊕ DUS, AIDU = PIDU ⊕ RU′, M1 = h(PIDU || CUS || RU || RU′) and sends the login request message < AIDU, M1, RU > to AS.

Mutual authentication with key-agreement phase

In this phase, Ui and AS authenticates each other and computes a session key for further secure communication over public channels. The entire mutual authentication with key agreement phase is illustrated in Fig 4.

  1. Step 1: AS computes RU′ = xS RU, PIDU = AIDU ⊕ RU′, CUS = h(PIDU || KS) and verifies the condition M1 ≟ h(PIDU || CUS || RU || RU′). If the condition holds, AS authenticates Ui, otherwise the process can be terminated.
  2. Step 2: AS → SC: < M2, M3 >
    AS further generates a random number N1 and computes SK = h(RU′ || CUS || SIDS || N1), M2 = PIDU ⊕ N1, M3 = h(SK || PIDU || N1 || CUS || RU). AS sends < M2, M3 > to SC.
  3. Step 3: SC → AS: < M4 >
    SC computes N1 = PIDU ⊕ M2, SK = h(RU′ || CUS || SIDS || N1) and verifies the condition M3 ≟ h(SK || PIDU || N1 || CUS || RU). If the condition holds, Ui authenticates AS, otherwise the process can be terminated. Then, SC computes M4 = h(SK || N1) and sends it to AS.
  4. Step 4: AS verifies M4 ≟ h(SK || N1) and reconfirms the authenticity of Ui. Now, Ui and AS can start communication with the computed session key SK.
thumbnail
Download:
Fig 4. Mutual authentication with key-agreement phase.

https://doi.org/10.1371/journal.pone.0154308.g004

Password and biometrics changing phase

This procedure invokes when a user (Ui) wish to update his/her existing password with new one. In this procedure, Ui can change his/her password without the involvement of registration server (RS) as follows:

  1. Step 1: Ui inserts smartcard SC and inputs IDU, PWU and BIO.
  2. Step 2: SC computes b = EU ⊕ H(BIO), AU = h(PWU || b), PIDU = h(IDU || b), BU = FU ⊕ AU and then verifies the condition GU ≟ h(PIDU || b || BU). If the condition holds, Ui derives CUS = AU ⊕ DUS for all the servers in the table TUS, otherwise request can be dropped.
  3. Step 3: Ui chooses a new password PWU# and BIO# and then computes AU# = h(PWU# || b), FU# = BU ⊕ AU#, DUS# = AU# ⊕ CUS and EU# = b ⊕ H(BIO#). Ui updates the table TUS# and the parameters FU#, EU# on the smartcard. Thus the smartcard finally contains the parameters {EU#, FU#, GU, TUS#, P, h(.), H(.)}.

Security Analysis

This section exhibits the security analysis of proposed authentication protocol for multi-server architecture by describing each security feature. This analysis checks various security aspects and ensures that the proposed protocol is resistant to different attacks and certain flaws are not exhibited.

Formal security analysis using BAN logic

Formal security analysis of the proposed protocol is verified with the help of Burrows-Abadi-Needham (BAN) logic [46]. This section proves that the proposed protocol provides secure mutual authentication between a user Ui and an application server AS.

The following notations are used in formal security analysis using the BAN logic:

  • Q |≡ X: Principal Q believes the statement X.
  • #(X): Formula X is fresh.
  • Q | ⇒ X: Principal Q has jurisdiction over the statement X.
  • Q ⊲ X: Principal Q sees the statement X.
  • Q | ∼ X: Principal Q once said the statement X.
  • (X, Y): Formula X or Y is one part of the formula (X, Y).
  • ⟨X⟩Y: Formula X combined with the formula Y.
  • : Principal Q and R may use the shared key K to communicate among each other. The key K is good, in that it will never be discovered by any principal except Q and R.
  • : Formula X is secret known only to Q and R, and possibly to principals trusted by them.

In addition, the following four BAN logic rules are used to prove that the proposed protocol provides a secure mutual authentication between Ui and AS:

  • Rule 1. Message-meaning rule: and
  • Rule 2. Nonce-verification rule:
  • Rule 3. Jurisdiction rule:
  • Rule 4. Freshness-conjuncatenation rule:

In order to show that the proposed protocol provides secure mutual authentication between a node R in the cluster Ci and TM, we need to achieve the following four test goals:

  • Goal 1:
  • Goal 2:
  • Goal 3:
  • Goal 4:

Generic form: The generic forms of the transmitted messages between the user Ui and the application server AS in the proposed protocol are given below:

  • M1. Ui → AS:
  • M2. AS → Ui:
  • M3. Ui → AS:

Note that the message M3, Ui → AS: h(h(RU’, CUS, SIDS, N1), N1) authenticates the parameters RU’, SIDS, N1 under the shared secret CUS between Ui and AS. Thus, for simplicity we assume that the message M3 as Ui → AS: in the generic form.

Idealized form: The arrangement of the transmitted messages between Ui and AS in the proposed protocol to the idealized forms are as follows:

  • M1. Ui → AS:
  • M2. AS → Ui:
  • M3. Ui → AS:

Hypotheses: The following are the initial assumptions of the proposed protocol:

  • H1: Ui |≡ #(RU),
  • H2: AS |≡ #(N1),
  • H3: ,
  • H4: ,
  • H5: ,
  • H6: ,
  • H7: .

In the following, we prove the above test goals in order to show the secure authentication using the BAN logic rules and the assumptions.

  • From the message M1, we have, S1:
  • From S1, H4, and Rule 1, we get, S2:
  • From the message M2, we have, S3:
  • From S3, H3, and Rule 1, we obtain, S4:
  • From S4, H1, Rule 2, and Rule 4, we get, S5: (Goal 2)
  • From S5 and Jurisdiction rule Rule 3, we obtain, S6: (Goal 1)
  • From the message M3, we have, S7:
  • From the message S7, H4, and Rule 1, we have, S8:
  • From S8, H2, Rule 2, and Rule 4, we get, S9:
  • Since SK is computed as SK = h(h(RU’, CUS, SIDS, N1), N1), from S9 and H4, we get the required goal Goal 3, as S10: (Goal 4)
  • Finally, from S10 and Jurisdiction rule Rule 3, we obtain, S11: (Goal 3)

Informal security analysis

Proposition 1.

The proposed protocol achieves user anonymity and untraceability.

Proof.

The proposed protocol does not reveal the real identities of users throughout all the phases of communication. In the user registration phase Ui submits pseudonym identity PIDU = h(IDU || b) and the real identity is guarded with a one-way hash function. During login phase, the pseudonym identity PIDU is converted as anonymous in the form of AIDU = PIDU ⊕ RU′. The identity is dynamic for every login, due to its association with a randomly chosen number xU, where RU = xU P and RU′ = xU RS. An adversary cannot retrieve the user’s pseudonym identity PIDU without having the knowledge of the user’s password PWU and b. Moreover, it is believed to be impossible to compute RU′ from RU and RS due to the fact of ECDLP. The proposed protocol provides another important feature called untraceability. An adversary may try to trace the actions of users by observing the transmitting parameters. In the login phase, Ui sends the message < AIDU, M1, RU > to AS. All the parameters are dynamic and does not disclose any information about Ui. Thus, the proposed protocol achieves user anonymity with untraceability.

Proposition 2.

The proposed protocol is secure against replay attacks and clock synchronization problem.

Proof.

The proposed protocol adopts the method discussed in the recent protocols [2] [3] [24] [25] [36], known as deployment of random numbers to endure replay attack. During mutual authentication and key-agreement phase, AS and U obtains {PIDU, RU} and {N1} and stores the values in its database tables, respectively. Consider a scenario where an adversary acquire {AIDU, M1, RU} or {M2, M3} or {M4} and replay the same message. However, adversary definitely cannot construct a valid session due to the reason explained here. All the captured parameters are randomized by incorporating a random number xU in the form of RU = xU P and RU′ = xU RS in AIDU = PIDU ⊕ RU′, M1 = h(PIDU || CUS || RU || RU′). The random number xU always keeps the transmitting parameters as dynamic for every session. If an adversary sends < AIDU, M1, RU > to AS, it identifies RU as previous transmitted message and drops the requested session. In the same way, N1 helps in identifying the replay attacks of {M2, M3} and {M4}.

In a cryptographic authentication protocol environment, timestamps are used to protect the messages from replay attacks. Basically, timestamps will be generated from the internal clocks of computing systems and may differ from system to system known as, clock synchronization problem. Hence, in the current large network field, time stamps are not the definite solutions due to clock synchronization problems. As an alternative possible solution, the proposed protocol deploys random numbers xU and N1.

Proposition 3.

The proposed protocol is secure against stolen smart card attack.

Proof.

Reading a smartcard stored values is possible by means of power analysis and various other ways [49] [50] [51]. Assume a valid user’s smartcard is stolen by an adversary and stored parameters {EU, GU, FU, TUS, P, h(.)} on it are extracted. Now, the adversary may try to derive authentication credentials from the extracted parameters. However, adversary undeniably cannot obtain any valuable information from these values, since all the important parameters such as EU = b ⊕ H(BIO), FU = BU ⊕ AU, GU = h(PIDU || b || BU) are safeguarded with a one-way hash function, where PIDU = h(IDU || b), AU = h(PWU || b) and BU = h(PIDU || USK). Note that the identity of user IDU is not stored on the smartcard. The adversary cannot obtain any login information using the smartcard stored parameters EU, GU, FU. At the same time guessing the real identity IDU and password PWU is impractical. Aforementioned constraints proves that the proposed protocol is secure from smartcard stolen attack.

Proposition 4.

The proposed protocol is secure against user impersonation attack.

Proof.

Assume a situation where an adversary possesses a valid smartcard and wants to gain network access by perpetrating user impersonation attack. If an adversary wants to impersonate a legitimate user Ui, he/she requires to build a login request message < AIDU, M1, RU >, where RU = xU P, AIDU = PIDU ⊕ RU′, M1 = h(PIDU || CUS || RU || RU′). Conversely, the adversary can barely compute two parameters RU# = xU# P and RU#′ = xU# RS by choosing his/her own random number xU#. In order to compute rest of the two parameters, adversary requires user’s identity IDU and password PWU, which are unobtainable.

On the other hand, the adversary should undergo login phase before making authentication request. During login phase, SC computes b = EU ⊕ H(BIO), AU = h(PWU || b), PIDU = h(IDU || b), BU = FU ⊕ AU and then verifies the condition GU ≟ h(PIDU || b || BU). Unless the adversary enters the correct credentials, he/she cannot be allowed to further phases. Therefore, the adversary certainly requires legitimate identity IDU and password PWU for any furthermore computations. However, the probability of yielding correct IDU and PWU is negligible. The adversary may also try to extract PIDU from AIDU = PIDU ⊕ RU′, by guessing xU from RU = xU P and RU′ = xU RS. It is even more difficult to perform the above operation due to the fact of Elliptic Curve Diffie-Hellman Problem (ECDHP).

Proposition 5.

The proposed protocol is secure against application server impersonation attack.

Proof.

Usually, during authentication phase, AS computes M2 = PIDU ⊕ N1, SK = h(RU′ || CUS || SIDS || N1), M3 = h(SK || PIDU || N1 || CUS || RU) with the generated random number N1 and sends < M2, M3 > to Ui. Consider a scenario where an adversary’s server acts as a legitimate one and proceeds with the authentication and key agreement procedures. In order to compute session key SK, adversary must have RU′, CUS and SIDJ. Assume that adversary still proceeds with the computations RU#′ = xS# RU, M2# = PIDU# ⊕ N1#, SK# = h(RU#′ || CUS# || SIDS || N1#), M3# = h(SK# || PIDU# || N1# || CUS# || RU) with the generated random numbers N1# and xS#. Note that SIDS can be obtained from the table TUS in the smartcard. Upon receiving the response < M2#, M3# >, Ui computes N1# = PIDU ⊕ M2#, SK = h(RU′ || CUS || SIDS || N1#) and M3# = h(SK || PIDU || N1# || CUS || RU) and tallies the received M3# with the computed M3. Here, Ui identifies it as a fake response from the malicious server due to M3 ≠ M3# and terminates the session immediately. Thus, the proposed protocol can withstand application server impersonation attacks.

Proposition 6.

The proposed protocol is secure against man-in-middle attack.

Proof.

In the proposed protocol scenario, adversary has the possibility of attacking either request message or response messages as elucidated here. Authentication request message < AIDU, M1, RU > initiates from SC to AS. As explained in proposition 4, adversary can modify only one parameter RU# = xU# P with the chosen random number xU#. For instance the adversary sends the modified parameter in the message as < AIDU, M1, RU# >. Upon receiving it, AS computes RU#′ = xS RU#, PIDU# = AIDU ⊕ RU#′, CUS# = h(PIDU# || KS) and M1# = h(PIDU# || CUS# || RU# || RU#′). Finally, AS compares the received M1 with the computed M1# then apparently M1 ≠ M1#. Accordingly, AS identifies it as a malicious attack and acknowledges the user Ui. In case, the adversary wants to accomplish active attacks on response messages either < M2, M3 > or < M4 >, then session key SK = h(RU′ || CUS || SIDS || N1) value and other parameters are essential and unobtainable. Thus the proposed protocol can withstand a man-in-middle attack.

Proposition 7.

The proposed protocol is secure against password guessing attack.

Proof a.

[Offline password guessing attack]: An adversary may attempt to guess the password PWU from the extracted smart card stored parameters {EU, GU, FU, TUS, P, h(.)}. The stored parameter FU = BU ⊕ AU contains the password PWU in the form AU = h(PWU || b). An adversary can try to check the condition FU ≟ BU ⊕ AU while constantly guessing PWU. In order to execute this, adversary needs IDU and b values as well. However, IDU value is nowhere stored and b value is protected with biometrics H(BIO), which can neither be forged nor copied. The adversary may even attempt to perform the same on AIDU = PIDU ⊕ RU′ value intercepted from previous login message < AIDU, M1, RU >. To perform this, the adversary requires RU′ = xU RS. As a result, the adversary would fail to guess the correct password PWU. Therefore, the proposed protocol is secure against offline password guessing attack.

Proof b.

[Online password guessing attack]: If an adversary possesses the valid smartcard, he/ she may keep trying to login while guessing the password PWU. Unless the adversary passes valid biometrics BIO; b value cannot be retrieved from EU. Additionally, the login verification condition GU ≟ h(PIDU || b || BU) checks the correctness of all input credentials. If the adversary enters the wrong password for certain number of times, the system may abort and would not allow entering credentials for some time. In addition, it is almost impractical to guess all the required values within polynomial time.

Proposition 8.

The proposed protocol is secure against privileged insider attack and does not maintain user verification table.

Proof.

A privileged insider of the system can obtain the stored credentials of registered user and perpetrate malicious attacks subsequently. However, during user registration phase of proposed protocol, Ui does not submit identity IDU and password PWU in plaintext form to the registration server RS. Ui submits only AU = h(PWU || b) and PIDU = h(IDU || b) to RS instead of original credentials, where b is a randomly chosen number. Hence, an insider cannot obtain the original credentials of any user. In this way, the proposed protocol attains resistance to insider attacks.

In the proposed protocol, AS authenticates Ui by verifying the equivalence of the received message with the computed values i.e. M1 ≟ h(PIDU || CUS || RU || RU′). Registration server RS is not involved in the authentication process, whereas password changing phase requires RS’s help. However, RS does not verify the legitimacy of Ui during this phase. Hence, RS does not require maintaining a database to store any kind of user’s credentials. An intruder cannot be able to determine any information about users, while the servers are not maintaining user verification tables. Thus, the servers are free from investing on their storage spaces.

Proposition 9.

The proposed protocol is secure against denial-of-service attack.

An adversary may cause denial-of-service attack, when he/she intercepts a valid authentication request message and replays the same message to AS. We have taken following approaches to prove that the proposed protocol is secure against denial-of-service attack.

Proof a.

Consider a scenario where an adversary replays previous captured authentication request {AIDU, M1, RU} without any modifications. Upon receiving the request, AS computes RU′ = xS. RU, PIDU = AIDU ⊕ RU′, and compares the extracted {PIDU, RU} with the stored {PIDU, RU}. When AS identify the received RU is same as the stored RU (i.e. RU = = RU), then it can reject the request without even verifying M1 ≟ h(PIDU || CUS || RU || RU′). This procedure can be completed with just one elliptic curve point multiplication operation and one X-OR operation.

Proof b.

Assume that an adversary transmits fake requests such as {AIDU#, M1#, RU#} for multiple. Upon receiving this message, AS computes RU′ = xS · RU, PIDU = AIDU ⊕ RU′, CUS = h(PIDU || KS), and verifies M1 ≟ h(PIDU || CUS || RU || RU′). It is obvious that the condition generates negative response due to unavailability of original CUS value with adversary. Therefore, AS believes it as a malicious attack and terminates the session, which requires two hash computations and one elliptic curve point multiplication operation.

Proposition 10.

The proposed protocol provides forward secrecy.

Proof.

Forward secrecy ensures that the session key remains safe, even though the long term private keys of communicating parties are compromised. The session key of the proposed protocol is computed as SK = h(RU′ || CUS || SIDS || N1) and the long term private key of the server KS in CUS = h(PIDU || KS) is shielded with a hash function and is not possible to derive due to its one-way property. Although the long term key is compromised with an adversary; he/she still cannot construct a valid session key due to following reason. The parameter RU′ = xU · RS is dynamic due to its association with random generated number xU, which is not possible to extract due to the reason of ECDLP. Therefore, the proposed protocol provides perfect forward secrecy.

Simulation for formal security verification using AVISPA tool

In this section, we simulate the proposed protocol using the widely accepted AVISPA for the formal security verification. For this purpose, we first provide a brief background of AVISPA tool and then the implementation details. We finally analyze the simulation results reported in this section. Note that AVISPA allows to verify whether a security protocol is safe or unsafe against replay and man-in-the-middle attacks. The main goal of the formal security verification simulation is to verify whether the proposed scheme is secure against replay and man-in-the-middle attacks.

Overview of AVISPA.

AVISPA is a push-button tool for the automated validation of Internet security-sensitive protocols and applications. AVISPA is a widely-accepted and used tool to formally verify whether a cryptographic protocol is safe or unsafe against passive and active attacks including the replay and man-in-the-middle attacks [2], [52]. In AVIPSA, a security protocol is implemented using HLPSL (High Level Protocols Specification Language) [53], [54]. In HLPSL implementation, the basic roles are used for representing each participant role, and composition roles for representing scenarios of basic roles. The role system includes the number of sessions, the number of principals and the roles.

In HLPSL, an intruder (i) is modeled using the Dolev-Yao model [55] where the intruder can participate as a legitimate role. HLPSL is translated using HLPSL2IF translation to convert to the intermediate format (IF). IF is fed into one of the four backends: On-the-fly Model-Checker (OFMC), Constraint Logic based Attack Searcher (CL-AtSe), SAT-based Model-Checker (SATMC) and Tree Automata based on Automatic Approximations for the Analysis of Security Protocols (TA4SP). The detailed descriptions of these back-ends can be found in [54]. The output format (OF) is produced from IF by using one of these four back-ends. OF has the following sections [54]:

  • SUMMARY: It indicates that whether the tested protocol is safe, unsafe, or inconclusive.
  • DETAILS: It either explains under what condition the tested protocol is declared safe, or what conditions have been used for finding an attack, or finally why the analysis is inconclusive.
  • PROTOCOL: It denotes the name of the protocol.
  • GOAL: It indicates the goal of the analysis.
  • BACKEND: It represents the name of the back-end used.
  • At the end, after some comments and statistics, the trace of an attack (if any) is displayed in the standard Alice-Bob format.

There are several basic types supported in HLPSL, some of them are given below for better understanding of the implementation details in Section 7.2 [48]:

  • Agent: It denotes the principal names. The intruder has always the special identifier i.
  • Public key: It denotes agents’ public keys in a public-key cryptosystem. For example, given a public (respectively private) key pk, its inverse private (respectively public) key pr is obtained by inv(pk).
  • Symmetric key: It means the keys for a symmetric-key cryptosystem.
  • Text: It is often used as nonces. These values can be also used for messages.
  • Nat: It denotes the natural numbers in non-message contexts.
  • Const: It denotes the constants.
  • Hash_func: It represents cryptographic hash functions.

In HLPSL, for concatenation the associative “.” operator is utilized. “played_by X” declaration means that the agent named in variable X plays in the role. A knowledge declaration (generally in the top-level Environment role) is used to specify the intruder’s initial knowledge. Immediate reaction transitions are of the form X = | > Y, which relates an event X and an action Y. By the goal secrecy_of P, a variable P is kept permanently secret. Thus, if P is ever obtained or derived by the intruder, a security violation will result.

Various roles implementation in HLPSL.

We have three basic roles: user for a user Ui, registration server for the registration server RS and application server for the application server AS. Besides these roles, the roles for the session, goal and environment in HLPSL are mandatory in the implementation. We have implemented the proposed protocol for user registration phase, login phase, and mutual authentication with key-agreement phase.

The role of the initiator, Ui is provided in Fig 5. Ui first receives the start signal, updates its state value from 0 to 1. The state value is maintained by the variable State. Ui sends the registration request message < PIDU, AU > securely to the RS during the user registration phase with the SEND() operation. Ui then receives a smart card SC containing the information {BU, TUS, P, h()} securely from the RS by the RECV() operation, and updates its state from 1 to 2.

thumbnail
Download:
Fig 5. Role specification for user Ui.

https://doi.org/10.1371/journal.pone.0154308.g005

In the login phase, Ui sends the message < AIDU, M1, RU > to the AS via open channel. During the mutual authentication with key-agreement phase, Ui then receives the message < M2, M3 > from the AS and sends reply < M4 > to the AS via open channel.

Note that channel (dy) declares that the channel is for the Dolev-Yao threat model [55]. The intruder (i) can thus intercept, analyze, and/or modify messages transmitted over the open channel. witness(A, B, id, E) declaration denotes for a (weak) authentication property of A by B on E, declares that agent A is witness for the information E; this goal will be identified by the constant id in the goal section [48]. request(B, A, id, E) declaration represents a strong authentication property of A by B on E, declares that agent B requests a check of the value E; this goal will be identified by the constant id in the goal section [48]. For example, witness(Ui, AS, ui as xu, xu’) declares that Ui has freshly generated random number xU for AS. By the declaration secret(IDu, B’, PWu, s1, Ui), we mean that the information IDU, b and PWU are kept secret to Ui only, which is identified by the protocol id s1.

In a similar way, the roles of the AS and RS of the proposed protocol are implemented and shown in Figs 6 and 7, respectively. The declaration, request(Ui, AS, ui as xu, xu’), signifies the AS’s acceptance of the value xU generated for AS by Ui. The roles for the goal and environment, and the session of the proposed protocol are also shown in Figs 8 and 9, respectively. In the session role, all the basic roles including user, registrationserver and applicationserver are the instances with concrete arguments. The top-level role (environment) is always specified in the HLPSL implementation. The intruder (i) participates in the execution of protocol as a concrete session as shown in Fig 8. In the proposed protocol, we have three secrecy goals and three authentication goals. For example, the secrecy goal: secrecy of s1 indicates that the information IDU, b and PWU are kept secret to Ui only. The authentication goal: authentication_on ui_as_x denotes that the Ui has freshly generated random number x for the AS, where x is only known to Ui. When the AS receives x from messages of Ui, the AS checks a strong authentication for Ui based on x. Similarly, the other authentication goal authentication_on as_ui_n1 denotes that the AS generates a random number N1 for Ui and when Ui receives N1 from other messages from the AS, Ui checks a strong authentication for the AS based on N1.

thumbnail
Download:
Fig 6. Role specification for application server AS.

https://doi.org/10.1371/journal.pone.0154308.g006

thumbnail
Download:
Fig 7. Role specification for registration server RS.

https://doi.org/10.1371/journal.pone.0154308.g007

thumbnail
Download:
Fig 8. Role specification for the goal and environment.

https://doi.org/10.1371/journal.pone.0154308.g008

thumbnail
Download:
Fig 9. Role specification in HLPSL for the session.

https://doi.org/10.1371/journal.pone.0154308.g009

Analysis of simulation results.

The proposed protocol is simulated under the widely-accepted OFMC and CL-AtSebackends using the SPAN, the Security Protocol ANimator for AVISPA [56]. Both back-ends are chosen for an execution test and a bounded number of sessions model checking [53]. Since the AVISPA implementation of our scheme in HLPSL uses bit XOR operation, currently SATMC and TA4SP backends do not support this feature. Due to this reason, the simulation results under both SATMC and TA4SP backends becomes inconclusive, and we have ignored these results in this paper.

The following verifications are performed in the proposed protocol as in [57]:

  • Executability check on non-trivial HLPSL specifications: Due to some modelling mistakes, the protocol model sometimes cannot execute to completion. It may be then possible that the backends cannot find an attack, if the protocol model cannot reach a state where that attack can happen. Therefore, an executability test is very essential in AVISPA [54]. The executability check of the proposed protocol tells that the proposed protocol description is well matched with the designed goals as specified in Figs 5–9.
  • Replay attack check: For replay attack check, the OFMC and CL-AtSe back-ends verify if the legitimate agents can execute the specified protocol by performing a search of a passive intruder. Both backends provide the intruder the knowledge of some normal sessions between the legitimate agents. The test results reported in Fig 10 clearly indicate that the proposed protocol is secure against the replay attack.
  • Dolev-Yao model check: For the Dolev-Yao model check, the OFMC and CL-AtSe backends also check if there is any man-in-the-middle attacks possible by the intruder. In OFMC backend, the depth for the search is nine and output of the results are shown in Fig 10. Also, the total number of nodes searched is 1040, which takes 2.56 seconds. On the other hand, in CL-AtSe backend, 63 states were analyzed and out of these states, all states were reachable. Further, CL-AtSe backend took 0.05 seconds for translation and 0.01 seconds for computation. It is clear from the simulation results that the proposed protocol fulfills the design criteria and is secure under the test of AVISPA using OFMC and CL-AtSe backends with the bounded number of sessions.
thumbnail
Download:
Fig 10. The result of the analysis using OFMC and CL-AtSe backends.

https://doi.org/10.1371/journal.pone.0154308.g010

Performance Analysis

This section demonstrates the performance analysis of the proposed protocol while considering various aspects such as security, computational cost and communication overhead. The performance analysis ensures that the proposed protocol is efficient and better in every aspect compared to Lu et al. [40] and other related protocols [2] [24] [25] [34] [39].

Functionality comparison

In this subsection, the proposed protocol is evaluated in terms of security and compared with other similar authentication protocols for multi-server architecture. The comparison of security properties between Chuang et al. [25], Mishra et al. [2], Lin et al. [39], Chen et al. [24], Lu et al. [40] and the proposed protocol are portrayed in Table 3. As shown in Table 3, the proposed protocol can withstand various security attacks and accomplishes distinct features such as user anonymity, untraceability, no verification tables, and biometrics deployment.

thumbnail
Download:
Table 3. Comparison of security properties.

https://doi.org/10.1371/journal.pone.0154308.t003

Computational cost comparison

It is evident from Table 4 that the computational cost of the proposed protocol is relatively lesser compared to Lu et al.’s and other similar protocols while accomplishing the significant security level as shown in Table 3. The proposed protocol is built on simple elliptic curve cryptography operations, one-way hash functions, concatenation and exclusive-OR operations. The computations of an exclusive-OR function and concatenation operation are relatively negligible, whereas exponential operation, elliptic curve point multiplication, encryption and decryption operations consume quite more. Research has proven that there is always a trade-off between security and performance of a protocol. Usually, when the protocol becomes more secure, the computational cost becomes higher and vice versa. Contrarily, the proposed protocol succeeds to stabilize both the terms parallel. To evaluate the computational cost analysis, we give few notations for the involved actions in Chuang et al. [25], Mishra et al. [2], Lee et al. [34], Lin et al. [39], Chen et al. [24], Lu et al. [40] and the proposed protocol as shown below.

thumbnail
Download:
Table 4. Comparison of computational cost.

https://doi.org/10.1371/journal.pone.0154308.t004

  • Th: Time complexity of a one-way hash function
  • Tmul: Time complexity of a point multiplication operation on elliptic curve
  • Tfun: Time complexity of encryption or decryption function
  • Tc: Time for performing a chaotic map operation

Communication overhead comparison

The communication overhead of the proposed protocol is compared with Chuang et al. [25], Mishra et al. [2], Lin et al. [39], Chen et al. [24], Lu et al. [40] and organized in Table 5. In order to evaluate the communication cost of the compared protocols, this paper considers SHA-1 hash function of 160 bits length, random number of 160 bits length, timestamp of 32 bits length, elliptic curve point of 160 bits length and 1024 bits modular prime for encryption and decryption function. As depicted in Table 4, the proposed protocol also uses 3 communication messages like the other similar protocols. In contrast, the proposed protocol requires only 960 bits for the 3 messages. Therefore, the proposed protocol consumes less bandwidth compared to Chuang et al. [25], Mishra et al. [2], Lin et al. [39], Chen et al. [24], Lu et al. [40] protocols.

thumbnail
Download:
Table 5. Comparison of communication overhead.

https://doi.org/10.1371/journal.pone.0154308.t005

Conclusions

This paper reviewed the recently proposed Lu et al.’s protocol for multi-server architecture and demonstrated that their protocol contains several weaknesses. In addition, this paper proposed an enhanced biometric based authentication with key-agreement protocol for multi-server architecture based on elliptic curve cryptography using smartcards. The mutual authentication of the proposed protocol is proved using BAN logic and also achieved significant features such as user anonymity, no verification tables, biometric authentication, perfect forward secrecy, with less computational and communication cost. The formal security of the proposed protocol is simulated and verified using the AVISPA tool to show that the proposed protocol can withstand active and passive attacks. The proposed protocol is perfectly suitable for practical applications as it accomplishes simple elliptic curve cryptography operations, one-way hash functions, concatenation operations and exclusive-OR operations. The formal and informal security analyses and performance analysis sections of this paper showed that the proposed protocol performs better in every aspect compared to Lu et al.’s protocol and existing similar protocols.

Author Contributions

Conceived and designed the experiments: AGR AKD VO KYY. Performed the experiments: AGR AKD VO KYY. Analyzed the data: AGR AKD VO KYY. Contributed reagents/materials/analysis tools: AGR AKD VO KYY. Wrote the paper: AGR AKD VO KYY.

References

  1. 1. Lamport L. (1981). Password authentication with insecure communication. Communications of the ACM, 24(11), 770–772.
  2. 2. Mishra D., Das A. K., & Mukhopadhyay S. (2014). A secure user anonymity-preserving biometric-based multi-server authenticated key agreement scheme using smart cards. Expert Systems with Applications, 41(18), 8129–8143.
  3. 3. Li C. T., & Hwang M. S. (2010). An efficient biometrics-based remote user authentication protocol using smart cards. Journal of Network and Computer Applications, 33(1), 1–5.
  4. 4. Amin R., Islam S. H., Biswas G. P., Khan M. K., & Kumar N. (2015). An efficient and practical smart card based anonymity preserving user authentication scheme for TMIS using elliptic curve cryptography. Journal of medical systems, 39(11), 1–18.
  5. 5. Awasthi A. K., & Lal S. (2004). An enhanced remote user authentication protocol using smart cards. Consumer Electronics, IEEE Transactions on, 50(2), 583–586.
  6. 6. Chien H. Y., Jan J. K., & Tseng Y. M. (2002). An efficient and practical solution to remote authentication: smart card. Computers & Security, 21(4), 372–375.
  7. 7. Das A. K. (2013). A secure and effective user authentication and privacy preserving protocol with smart cards for wireless communications. Networking Science, 2(1–2), 12–27.
  8. 8. Fan C. I., & Lin Y. H. (2009). Provably secure remote truly three-factor authentication protocol with privacy protection on biometrics. Information Forensics and Security, IEEE Transactions on, 4(4), 933–945.
  9. 9. Goutham, R. A., Lee, G. J., & Yoo, K. Y. (2015). An anonymous ID-based remote mutual authentication with key agreement protocol on ECC using smart cards. In Proceedings of the 30th Annual ACM Symposium on Applied Computing, 169–174. 10.1145/2695664.2695666.
    • 10. Islam S. H., & Biswas G. P. (2012). An improved ID-based client authentication with key agreement scheme on ECC for mobile client-server environments. Theoretical and Applied Informatics, 24(4), 293.
    • 11. Islam S. K. (2014). Design and analysis of an improved smartcard‐based remote user password authentication scheme. International Journal of Communication Systems.
    • 12. Islam S. H., & Khan M. K. (2014). Cryptanalysis and improvement of authentication and key agreement protocols for telecare medicine information systems. Journal of medical systems, 38(10), 1–16.
    • 13. Islam S. H., & Biswas G. P. (2014). Dynamic id-based remote user mutual authentication scheme with smartcard using elliptic curve cryptography. Journal of Electronics, 31(5), 473–488.
    • 14. Islam S. H., Biswas G. P., & Choo K. K. R. (2014). Cryptanalysis of an improved smartcard-based remote password authentication scheme. Information Sciences Letters, 3(1), 35.
    • 15. Islam S. H., Khan M. K., Obaidat M. S., & Muhaya F. T. B. (2015). Provably secure and anonymous password authentication protocol for roaming service in global mobility networks using extended chaotic maps. Wireless Personal Communications, 84(3), 2013–2034.
    • 16. Islam S. H., & Biswas G. P. (2015). Cryptanalysis and improvement of a password-based user authentication scheme for the integrated EPR information system. Journal of King Saud University-Computer and Information Sciences, 27(2), 211–221.
    • 17. Islam S. H., Das A. K., & Khan M. K. (2015) "A novel biometric-based password authentication scheme for client-server environment using ECC and fuzzy extractor," International Journal of Ad Hoc and Ubiquitous Computing, In Press.
    • 18. Islam SH, Khan MK, Li X (2015) Security Analysis and Improvement of ‘a More Secure Anonymous User Authentication Scheme for the Integrated EPR Information System’. PLoS ONE 10(8): e0131368. pmid:26263401
    • 19. Lee J. K., Ryu S. R., & Yoo K. Y. (2002). Fingerprint-based remote user authentication protocol using smart cards. Electronics Letters, 38(12), 554–555.
    • 20. Lin C. H., & Lai Y. Y. (2004). A flexible biometrics remote user authentication protocol. Computer Standards & Interfaces, 27(1), 19–23.
    • 21. Mir O., van der Weide T., & Lee C. C. (2015). A secure user anonymity and authentication scheme using AVISPA for telecare medical information systems. Journal of Medical Systems, 39(9), 1–16.
    • 22. Song R. (2010). Advanced smart card based password authentication protocol. Computer Standards & Interfaces, 32(5), 321–325.
    • 23. Yang W. H., & Shieh S. P. (1999). Password authentication protocols with smart cards. Computers & Security, 18(8), 727–733.
    • 24. Chen C. T., & Lee C. C. (2015). A two‐factor authentication scheme with anonymity for multi‐server environments. Security and Communication Networks, 8(8), 1608–1625.
    • 25. Chuang M.-C., & Chen M. C. (2014). An anonymous multi-server authenticated key agreement scheme based on trust computing using smart cards and biometrics. Expert Systems with Applications, 41(4), 1411–1418.
    • 26. Das A. K., Odelu V., & Goswami A. (2015). A Secure and Robust User Authenticated Key Agreement Scheme for Hierarchical Multi-medical Server Environment in TMIS. Journal of Medical Systems, 39(9), 1–24.
    • 27. Guo D. L., & Wen F. T. (2014). Analysis and improvement of a robust smart card based-authentication scheme for multi-server architecture. Wireless Personal Communications, 78(1), 475–490.
    • 28. Hsiang H. C., & Shih W. K. (2009). Improvement of the secure dynamic ID based remote user authentication protocol for multi-server environment. Computer Standards & Interfaces, 31(6), 1118–1123.
    • 29. Huang C. H., Chou J. S., Chen Y., & Wun S. Y. (2012). Improved multi‐server authentication protocol. Security and Communication Networks, 5(3), 331–341.
    • 30. Islam S. H. (2014). A provably secure ID-based mutual authentication and key agreement scheme for mobile multi-server environment without ESL attack. Wireless Personal Communications, 79(3), 1975–1991.
    • 31. Juang W. S. (2004). Efficient multi-server password authenticated key agreement using smart cards. Consumer Electronics, IEEE Transactions on, 50(1), 251–255.
    • 32. Lee C. C., Lin T. H., & Chang R. X. (2011). A secure dynamic ID based remote user authentication protocol for multi-server environment using smart cards. Expert Systems with Applications, 38(11), 13863–13870.
    • 33. Lee C. C., Lai Y. M., & Li C. T. (2012). An improved secure dynamic ID based remote user authentication scheme for multi-server environment. International Journal of Security and Its Applications, 6(2), 203–209.
    • 34. Lee C. C., Lou D. C., Li C. T., & Hsu C. W. (2014). An extended chaotic-maps-based protocol with key agreement for multiserver environments. Nonlinear Dynamics, 76(1), 853–866.
    • 35. Li X., Xiong Y., Ma J., & Wang W. (2012). An efficient and security dynamic identity based authentication protocol for multi-server architecture using smart cards. Journal of Network and Computer Applications, 35(2), 763–769.
    • 36. Li X., Ma J., Wang W., Xiong Y., & Zhang J. (2013). A novel smart card and dynamic ID based remote user authentication scheme for multi-server environments. Mathematical and Computer Modelling, 58(1), 85–95.
    • 37. Li C. T., Lee C. C., Weng C. Y., Fa C. I. (2015). “A Secure Dynamic Identity based Authentication Protocol with Smart Cards for Multi-Server Architecture,” Journal of Information Science and Engineering, 31(6), 1975–1992.
    • 38. Liao Y. P., & Wang S. S. (2009). A secure dynamic ID based remote user authentication protocol for multi-server environment. Computer Standards & Interfaces, 31(1), 24–29.
    • 39. Lin H., Wen F., & Du C. (2015). An Improved Anonymous Multi-Server Authenticated Key Agreement Scheme Using Smart Cards and Biometrics. Wireless Personal Communications, 1–12.
    • 40. Lu Y, Li L, Yang X, Yang Y (2015) Robust Biometrics Based Authentication and Key Agreement Scheme for Multi-Server Environments Using Smart Cards. PLoS ONE, 10(5): e0126323. pmid:25978373
    • 41. Odelu V., Das A. K., & Goswami A. (2015). A Secure Biometrics-Based Multi-Server Authentication Protocol Using Smart Cards. Information Forensics and Security, IEEE Transactions on, 10(9), 1953–1966.
    • 42. Sood S. K., Sarje A. K., & Singh K. (2011). A secure dynamic identity based authentication protocol for multi-server architecture. Journal of Network and Computer Applications, 34(2), 609–618.
    • 43. Tsai J. L. (2008). Efficient multi-server authentication protocol based on one-way hash function without verification table. Computers & Security, 27(3), 115–121.
    • 44. Wang R. C., Juang W. S., & Lei C. L. (2009). User authentication protocol with privacy-preservation for multi-server environment. Communications Letters, IEEE, 13(2), 157–159.
    • 45. Xue K., Hong P., & Ma C. (2014). A lightweight dynamic pseudonym identity based authentication and key agreement protocol without verification tables for multi-server architecture. Journal of Computer and System Sciences, 80(1), 195–206.
    • 46. Yoon E. J., & Yoo K. Y. (2013). Robust biometrics-based multi-server authentication with key agreement scheme for smart cards on elliptic curve cryptosystem. The Journal of Supercomputing, 63(1), 235–255.
    • 47. Burrows M., Abadi M., & Needham R. M. (1989, December). A logic of authentication. In Proceedings of the Royal Society of London A: Mathematical, Physical and Engineering Sciences. The Royal Society (Vol. 426, No. 1871, pp. 233–271).
    • 48. AVISPA. Automated Validation of Internet Security Protocols and Applications. http://www.avispaproject.org/. Accessed on October 2015.
      • 49. Kocher P., Jaffe J., & Jun B. (1999b). Differential power analysis. In Proceedings of advances in cryptology—CRYPTO’99. LNCS (Vol. 1666, pp. 388–397).
      • 50. Messerges T. S., Dabbish E. A., & Sloan R. H. (2002b). Examining smart-card security under the threat of power analysis attacks. IEEE Transactions on Computers, 51(5), 541–552.
      • 51. Nam J, Choo K-KR, Han S, Kim M, Paik J, Won D (2015) Efficient and Anonymous Two-Factor User Authentication in Wireless Sensor Networks: Achieving User Anonymity with Lightweight Sensor Computation. PLoS ONE, 10(4): e0116709. pmid:25849359
      • 52. Armando et al. (2005). The AVISPA Tool for the Automated Validation of Internet Security protocols and Applications. In Proc. of International Conference on Computer Aided Verification (CAV'05), Scotland, UK, vol. 3576, pp. 281–285. 10.1007/11513988_27
        • 53. Basin D., Mödersheim S., & Luca V.. (2005). OFMC: A symbolic model checker for security protocols. International Journal of Information Security, 4(3), 181–208.
        • 54. Von Oheimb, D. (2005, September). The high-level protocol specification language HLPSL developed in the EU project AVISPA. In Proceedings of APPSEM 2005 workshop (pp. 1–17).
          • 55. Dolev D., & Yao A. C. (1983). On the security of public key protocols. Information Theory, IEEE Transactions on, 29(2), 198–208.
          • 56. AVISPA. SPAN, the Security Protocol Animator for AVISPA. http://www.avispa-project.org/. Accessed on December 2015.
            • 57. Lv C., Ma M., Li H., Ma J., & Zhang Y. (2013). A novel three-party authenticated key exchange protocol using one-time key. Journal of Network and Computer Applications, 36(1), 498–503.