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

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.

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 (U), authorized server (S), 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 S via a secure channel. The various notations used in Lu et al.’s protocol are listed in Table 1.

Table 1

Notations of Lu et al.’s protocol.

Ui	An user
Sj	Authorized server
RC	Registration center
IDi	Identity of Ui
PWi	Password of Ui
BIOi	Biometrics of Ui
x, y	Private keys of RC and Ui
PSK	A secure key chosen by RC for Sj
h(.)	A secure one-way hash function
H(.)	A bio-hash function
⊕	An exclusive-OR operation
||	The concatenation operation

Registration phase

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

Fig 1

Registration phase of Lu et al.’s protocol.

Step 1: U chooses an identity ID, password PW and computes h(PW || H(BIO)). Then sends a request message < ID, h(PW || H(BIO)) > to RC via a secure channel.

Step 2: RC computes X = h(ID || x), V = h(ID || h(PW || H(BIO))). Then RC stores the parameters {X, V, h(PSK)} on a smartcard and delivers it to U via a secure channel.

Step 3: Upon receiving the smartcard from RC, U computes Y = h(PSK) ⊕ y, and replaces h(PSK) with Y. Thus, the smartcard contains {X, Y, V, h(.)}.

Login and authentication phases

In this phase, user (U) and server (S) authenticates each other, and also establishes a session between them as shown in Fig 2. U can launch the login request by inserting smartcard, inputs ID, PW and BIO.

Fig 2

Login and authentication phases of Lu et al.’s protocol.

Step 1: Smartcard computes h(PW || H(BIO)) and then verifies the condition V ≟ h(ID || h(PW || H(BIO))). If it generates negative result, the login request can be terminated.

Step 2: Smartcard generates a random number n1, timestamp T1 and computes K = h((Y ⊕ y) || SID), M1 = K ⊕ ID, M2 = n1 ⊕ K, M3 = K ⊕ h(PW || H(BIO)), Z = h(X || n1 || h(PW || H(BIO)) || T1), and sends the request message < Z, M1, M2, M3, T1 > to S.

Step 3: S checks the freshness of the request message by verifying T−T1 ≤ ΔT. If it holds, then S computes K = h(h(PSK) || SID)) to retrieve ID = K ⊕ M1, n1 = M2 ⊕ K, h(PW || H(BIO)) = K ⊕ M3. Now, S computes X = h(ID || x) and verifies Z ≟ h(X || n1 || h(PW || H(BIO)) || T1). If the condition holds, then S authenticates U, otherwise process aborts.

Step 4: S further generates a random number n2, timestamp T2 and computes SK = h(n1 || n2 || K || X), M4 = n2 ⊕ h(n1 || h(PW || H(BIO)) || X), M5 = h(ID || n1 || n2 || K || T2). S sends the response < M4, M5, T2 > to U.

Step 5: U checks the freshness of the message by verifying T−T2 ≤ ΔT. If it holds, then U computes n2 = M4 ⊕ h(n1 || h(PW || H(BIO)) || X) and checks M5 ≟ h(ID || n1 || n2 || K || T2). If it generates positive result, then U authenticates S, otherwise process aborts.

Step 6: U generates a timestamp T3 and computes SK = h(n1 || n2 || K || X), M6 = h(SK || ID || n2 || T3). Finally, U sends < M6, T3 > to S.

Step 7: S verifies the freshness of T3 and M6 ≟ h(SK || ID || n2 || T3). If it holds, then the mutual authentication with key agreement process between U and S is completed.

Password changing phase

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

Step 1: U inserts smartcard, inputs the identity ID, password PW, scans the biometrics BIO and then verifies the condition V ≟ h(ID || h(PW || H(BIO))). If it holds, then U is allowed to choose a new password PW.

Step 2: Smartcard computes V ≟ h(ID || h(PW || H(BIO))) and replaces existing V with V.

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

Step 1: During login and authentication phase, U launches the authentication request < Z, M1, M2, M3, T1 > by inserting smartcard and inputting ID, PW and BIO.

Step 2: Upon receiving the request from U, Ӕ computes K = h(h(PSK) || SID)), ID = K ⊕ M1, n1 = M2 ⊕ K, h(PW || H(BIO)) = K ⊕ M3, X = h(ID || x).

Step 3: Now, Ӕ generates a random number n2, timestamp T2 and computes SK = h(n1 || n2 || K || X), M4 = n2 ⊕ h(n1 || h(PW || H(BIO)) || X), M5 = h(ID || n1 || n2 || K || T2). Ӕ sends the response < M4, M5, T2 > to U.

Step 4: U checks the freshness of the message by computing T−T2 ≤ ΔT. If it holds, then U computes n2 = M4 ⊕ h(n1 || h(PW || H(BIO)) || X) and verifies M5 ≟ h(ID || n1 || n2 || K || T2). It is obvious that the condition holds, consequently U treats Ӕ as legitimate S.

Step 5: U generates a timestamp T3 and computes SK = h(n1 || n2 || K || X), M6 = h(SK || ID || n2 || T3). Finally, U sends < M6, T3 > to Ӕ.

Now, U may start the communication with Ӕ using the computed session key SK = h(n1 || n2 || K || X) 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 ID and h(PW || H(BIO)) 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.

Step 1: Consider a scenario where Ӕ capture the U’s message < Z, M1, M2, M3, T1 > while sending to S during authentication phase.

Step 2: Ӕ can compute K = h(h(PSK) || SID)) and obtain ID = K ⊕ M1, n1 = M2 ⊕ K, h(PW || H(BIO)) = K ⊕ M3 by using h(PSK) and openly available SID values.

Step 3: Now Ӕ comprises U’s personal identifiable information such as ID and h(PW || H(BIO)) 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.

Step 1: As enlightened in prone to server impersonation attack and man-in-middle subsections, Ӕ can obtain U’s personal identifiable information such as ID and h(PW || H(BIO)), and possesses x and PSK values.

Step 2: Now, Ӕ generates a random number n1, timestamp T1 and computes K = h(h(PSK) || SID)), M1 = K ⊕ ID, M2 = n1 ⊕ K, M3 = K ⊕ h(PW || H(BIO)), X = h(ID || x), Z = h(X || n1 || h(PW || H(BIO)) || T1). Ӕ sends the request < Z, M1, M2, M3, T1 > to S.

Step 3: S checks the freshness of the message by computing T−T1 ≤ ΔT. If it holds, then S computes K = h(h(PSK) || SID) to retrieve ID = K ⊕ M1, n1 = M2 ⊕ K, h(PW || H(BIO)) = K ⊕ M3. Then, S computes X = h(ID || x) and verifies Z = h(X || n1 || h(PW || H(BIO)) || T1). It is obvious that all the conditions generates positive results and S treats Ӕ as legitimate U and proceeds further.

Step 4: S generates a random number n2, timestamp T2 and computes SK = h(n1 || n2 || K || X), M4 = n2 ⊕ h(n1 || h(PW || H(BIO)) || X), M5 = h(ID || n1 || n2 || K || T2). S sends the response < M4, M5, T2 > to Ӕ.

Step 5: Ӕ computes n2 = M4 ⊕ h(n1 || h(PW || H(BIO)) || X) and verifies M5 ≟ h(ID || n1 || n2 || K || T2). Now, Ӕ generates a timestamp T3 and computes SK = h(n1 || n2 || K || X), M6 = h(SK || ID || n2 || T3). Finally, Ӕ sends < M6, T3 > to S.

Step 6: S verifies the freshness of T3 and M6 ≟ h(SK || ID || n2 || T3). Since M6 holds, S 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, U transmits the authentication request message < Z, M1, M2, M3, T1 > to S over public channels. The transmitted parameter M1 = K ⊕ ID, where K = h((Y ⊕ y) || SID)) in the message < Z, 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 SK = h(n1 || n2 || K || X). The involved parameters K and X are dependent on long term secret keys, and n1 and n2 are random numbers. As proved in server impersonation attack, when S’s long term secret keys x and PSK are compromised, then Ӕ can compute K = h(h(PSK) || SID)), X = h(ID || x) and derive session key SK = h(n1 || n2 || K || X) 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 < Z, M1, M2, M3, T1 > and < M4, M5, T2 > transmitted between U and S contains timestamps T1 and T2. Upon receiving these messages S and U checks the validity of timestamps by computing T−T1 ≤ ΔT and T−T2 ≤ ΔT. If these holds, then only S and U 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 (U), 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.

Table 2

Notations of the proposed protocol.

Ui	An ith user
AS	Application server
RS	Registration server
IDU	Identity of Ui
PWU	Password of Ui
b	A number chosen by Ui for registration
IDS	Identity of AS
USK	A secure key chosen by RS for Ui
PSK	A secure key chosen by RS for AS
xU, xS, N1	Random numbers chosen by Ui and AS
h(.)	A secure one-way hash function
H(.)	A bio-hash function
⊕	An exclusive-OR operation
||	The concatenation operation

Registration server initialization phase

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

Step 1: RS chooses an elliptic curve equation E with an order n.

Step 2: RS selects a base point P over E and chooses a one-way cryptographic hash function h(.).

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:

Step 1: AS computes public key R = x P sends registration request < SID, R > to the RS.

Step 2: RS computes K = h(SID || PSK), where PSK is RS’s secret key for application servers and RS stores {SID, R, K} in its database table T.

Step 3: RS sends K to AS, which can be used in further phases of authentication.

User registration phase

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

Fig 3

User registration phase.

Step 1: U chooses an identity ID, password PW, a number b and scans biometrics BIO and computes A = h(PW || b), PID = h(ID || b). U sends a request message < PID, A > to RS via a secure channel.

Step 2: RS computes B = h(PID || USK), C = h(PID || K) and D = A ⊕ C, where USK is RS’s secret key for users.

Step 3: RS personalize the parameters {B, T, P, h(.)} on a smartcard and delivers it to U via a secure channel.

Step 4: U computes E = b ⊕ H(BIO), F = B ⊕ A, G = h(PID || b || B) and stores E, G, F on the received smart card after deleting B from smartcard. Thus the smartcard finally contains the parameters {E, G, F, T, P, h(.), H(.)}.

Login phase

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

Step 1: SC →AS: < AID, M1, R >

SC computes b = E ⊕ H(BIO), A = h(PW || b), PID = h(ID || b), B = F ⊕ A and then verifies the condition G ≟ h(PID || b || B). If it generates negative result, the login request can be terminated. Otherwise, SC retrieves corresponding application server’s D and R values from the table T. Then, SC generates a random number x and calculates R = x P, R′ = x R, C = A ⊕ D, AID = PID ⊕ R′, M1 = h(PID || C || R || R′) and sends the login request message < AID, M1, R > to AS.

Mutual authentication with key-agreement phase

In this phase, U 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.

Fig 4

Mutual authentication with key-agreement phase.

Step 1: AS computes R′ = x R, PID = AID ⊕ R′, C = h(PID || K) and verifies the condition M1 ≟ h(PID || C || R || R′). If the condition holds, AS authenticates U, otherwise the process can be terminated.

Step 2: AS → SC: < M2, M3 >

AS further generates a random number N1 and computes SK = h(R′ || C || SID || N1), M2 = PID ⊕ N1, M3 = h(SK || PID || N1 || C || R). AS sends < M2, M3 > to SC.

Step 3: SC → AS: < M4 >

SC computes N1 = PID ⊕ M2, SK = h(R′ || C || SID || N1) and verifies the condition M3 ≟ h(SK || PID || N1 || C || R). If the condition holds, U authenticates AS, otherwise the process can be terminated. Then, SC computes M4 = h(SK || N1) and sends it to AS.

Step 4: AS verifies M4 ≟ h(SK || N1) and reconfirms the authenticity of U. Now, U and AS can start communication with the computed session key SK.

Password and biometrics changing phase

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

Step 1: U inserts smartcard SC and inputs ID, PW and BIO.

Step 2: SC computes b = E ⊕ H(BIO), A = h(PW || b), PID = h(ID || b), B = F ⊕ A and then verifies the condition G ≟ h(PID || b || B). If the condition holds, U derives C = A ⊕ D for all the servers in the table T, otherwise request can be dropped.

Step 3: U chooses a new password PW# and BIO# and then computes A# = h(PW# || b), F# = B ⊕ A#, D# = A# ⊕ C and E# = b ⊕ H(BIO#). U updates the table T# and the parameters F#, E# on the smartcard. Thus the smartcard finally contains the parameters {E#, F#, G, T#, 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 U 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⟩: 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 U 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 C 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 U and the application server AS in the proposed protocol are given below:

M1. U → AS:

M2. AS → U:

M3. U → AS:

Note that the message M3, U → AS: h(h(R’, C, SID, N1), N1) authenticates the parameters R’, SID, N1 under the shared secret C between U and AS. Thus, for simplicity we assume that the message M3 as U → AS: in the generic form.

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

M1. U → AS:

M2. AS → U:

M3. U → AS:

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

H1: U |≡ #(R),

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(R’, C, SID, 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 U submits pseudonym identity PID = h(ID || b) and the real identity is guarded with a one-way hash function. During login phase, the pseudonym identity PID is converted as anonymous in the form of AID = PID ⊕ R′. The identity is dynamic for every login, due to its association with a randomly chosen number x, where R = x P and R′ = x R. An adversary cannot retrieve the user’s pseudonym identity PID without having the knowledge of the user’s password PW and b. Moreover, it is believed to be impossible to compute R′ from R and R 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, U sends the message < AID, M1, R > to AS. All the parameters are dynamic and does not disclose any information about U. Thus, the proposed protocol achieves user anonymity with untraceability.

Proposition 2

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

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 {PID, R} and {N1} and stores the values in its database tables, respectively. Consider a scenario where an adversary acquire {AID, M1, R} 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 x in the form of R = x P and R′ = x R in AID = PID ⊕ R′, M1 = h(PID || C || R || R′). The random number x always keeps the transmitting parameters as dynamic for every session. If an adversary sends < AID, M1, R > to AS, it identifies R 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 x and N1.

Proposition 3

The proposed protocol is secure against stolen smart card attack.

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 {E, G, F, T, 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 E = b ⊕ H(BIO), F = B ⊕ A, G = h(PID || b || B) are safeguarded with a one-way hash function, where PID = h(ID || b), A = h(PW || b) and B = h(PID || USK). Note that the identity of user ID is not stored on the smartcard. The adversary cannot obtain any login information using the smartcard stored parameters E, G, F. At the same time guessing the real identity ID and password PW 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.

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 U, he/she requires to build a login request message < AID, M1, R >, where R = x P, AID = PID ⊕ R′, M1 = h(PID || C || R || R′). Conversely, the adversary can barely compute two parameters R# = x# P and R#′ = x# R by choosing his/her own random number x. In order to compute rest of the two parameters, adversary requires user’s identity ID and password PW, which are unobtainable.

On the other hand, the adversary should undergo login phase before making authentication request. During login phase, SC computes b = E ⊕ H(BIO), A = h(PW || b), PID = h(ID || b), B = F ⊕ A and then verifies the condition G ≟ h(PID || b || B). Unless the adversary enters the correct credentials, he/she cannot be allowed to further phases. Therefore, the adversary certainly requires legitimate identity ID and password PW for any furthermore computations. However, the probability of yielding correct ID and PW is negligible. The adversary may also try to extract PID from AID = PID ⊕ R′, by guessing x from R = x P and R′ = x R. 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.

Usually, during authentication phase, AS computes M2 = PID ⊕ N1, SK = h(R′ || C || SID || N1), M3 = h(SK || PID || N1 || C || R) with the generated random number N1 and sends < M2, M3 > to U. 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 R′, C and SID. Assume that adversary still proceeds with the computations R′ = x R, M2 = PID ⊕ N1, SK = h(R′ || C || SID || N1), M3 = h(SK || PID || N1 || C || R) with the generated random numbers N1 and x. Note that SID can be obtained from the table T in the smartcard. Upon receiving the response < M2, M3 >, U computes N1 = PID ⊕ M2, SK = h(R′ || C || SID || N1) and M3 = h(SK || PID || N1 || C || R) and tallies the received M3 with the computed M3. Here, U 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.

In the proposed protocol scenario, adversary has the possibility of attacking either request message or response messages as elucidated here. Authentication request message < AID, M1, R > initiates from SC to AS. As explained in proposition 4, adversary can modify only one parameter R# = x# P with the chosen random number x. For instance the adversary sends the modified parameter in the message as < AID, M1, R# >. Upon receiving it, AS computes R#′ = x R#, PID# = AID ⊕ R#′, C# = h(PID# || K) and M1# = h(PID# || C# || R# || R#′). 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 U. In case, the adversary wants to accomplish active attacks on response messages either < M2, M3 > or < M4 >, then session key SK = h(R′ || C || SID || 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 PW from the extracted smart card stored parameters {E, G, F, T, P, h(.)}. The stored parameter F = B ⊕ A contains the password PW in the form A = h(PW || b). An adversary can try to check the condition F ≟ B ⊕ A while constantly guessing PW. In order to execute this, adversary needs ID and b values as well. However, ID 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 AID = PID ⊕ R′ value intercepted from previous login message < AID, M1, R >. To perform this, the adversary requires R′ = x R. As a result, the adversary would fail to guess the correct password PW. 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 PW. Unless the adversary passes valid biometrics BIO; b value cannot be retrieved from E. Additionally, the login verification condition G ≟ h(PID || b || B) 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.

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, U does not submit identity ID and password PW in plaintext form to the registration server RS. U submits only A = h(PW || b) and PID = h(ID || 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 U by verifying the equivalence of the received message with the computed values i.e. M1 ≟ h(PID || C || R || R′). 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 U 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.

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

Assume that an adversary transmits fake requests such as {AID, M1, R} for multiple. Upon receiving this message, AS computes R′ = x · R, PID = AID ⊕ R′, C = h(PID || K), and verifies M1 ≟ h(PID || C || R || R′). It is obvious that the condition generates negative response due to unavailability of original C 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.

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(R′ || C || SID || N1) and the long term private key of the server K in C = h(PID || K) 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 R′ = x · R is dynamic due to its association with random generated number x, 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 U, 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, U is provided in Fig 5. U first receives the start signal, updates its state value from 0 to 1. The state value is maintained by the variable State. U sends the registration request message < PID, A > securely to the RS during the user registration phase with the SEND() operation. U then receives a smart card SC containing the information {B, T, P, h()} securely from the RS by the RECV() operation, and updates its state from 1 to 2.

Fig 5

Role specification for user U.

In the login phase, U sends the message < AID, M1, R > to the AS via open channel. During the mutual authentication with key-agreement phase, U 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 U has freshly generated random number x for AS. By the declaration secret(IDu, B’, PWu, s1, Ui), we mean that the information ID, b and PW are kept secret to U 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 x generated for AS by U. 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 ID, b and PW are kept secret to U only. The authentication goal: authentication_on ui_as_x denotes that the U has freshly generated random number x for the AS, where x is only known to U. When the AS receives x from messages of U, the AS checks a strong authentication for U based on x. Similarly, the other authentication goal authentication_on as_ui_n1 denotes that the AS generates a random number N1 for U and when U receives N1 from other messages from the AS, U checks a strong authentication for the AS based on N1.

Fig 6

Role specification for application server AS.

Fig 7

Role specification for registration server RS.

Fig 8

Role specification for the goal and environment.

Fig 9

Role specification in HLPSL for the session.

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.

Fig 10

The result of the analysis using OFMC and CL-AtSe backends.

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.

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.

Table 3

Comparison of security properties.

Security property	Chuang [25]	Mishra [2]	Lin [39]	Chen [24]	Lu [40]	Our
P1	No	No	No	Yes	No	Yes
P2	Yes	Yes	No	Yes	Yes	Yes
P3	Yes	Yes	Yes	Yes	Yes	Yes
P4	No	No	Yes	Yes	No	Yes
P5	No	No	Yes	Yes	Yes	Yes
P6	No	No	Yes	Yes	No	Yes
P7	No	No	Yes	Yes	No	Yes
P8	Yes	Yes	No	Yes	Yes	Yes
P9	No	Yes	No	Yes	Yes	Yes
P10	Yes	Yes	Yes	Yes	Yes	Yes
P11	Yes	Yes	No	Yes	Yes	Yes
P12	Yes	Yes	No	Yes	No	Yes
P13	Yes	Yes	Yes	Yes	No	Yes

P1: User anonymity and untraceability, P2: Perfect mutual authentication, P3: Prevent replay attack, P4: Prevent man-in-middle attack, P5: Prevent stolen smart card attack, P6: Prevent user impersonation attack, P7: Prevent server impersonation attack, P8: Prevent insider attack, P9: Prevent denial-of-service attack, P10: Prevent password guessing attack, P11: No user verification table, P12: Prevent clock synchronization problem, P13: Perfect forward secrecy

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.

Table 4

Comparison of computational cost.

Phase	Chuang [25]	Mishra [2]	Lee [34]	Lin [39]	Chen [24]	Lu [40]	Our
Login	3Th	7Th	2Th+2Tc	5Th+1Tfun	3Th	5Th	5Th+2Tmul
Authentication+key-agreement	16Th	17Th	12Th+4Tc	10Th+4Tmul+5Tfun	16Th	13Th	8Th+1Tmul
Total	19Th	24Th	14Th+6Tc	15Th+4Tmul+6Tfun	19Th	18Th	13Th+3Tmul

T: Time complexity of a one-way hash function

T: Time complexity of a point multiplication operation on elliptic curve

T: Time complexity of encryption or decryption function

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

Table 5

Comparison of communication overhead.

Feature	Chuang [25]	Mishra [2]	Lin [39]	Chen [24]	Lu [40]	Our
Number of messages	3	3	3	3	3	3
Number of bits	1280	1280	2528	1280	1216	960

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.