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][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][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 .
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-ofverifier 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.
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 keyagreement protocol for multi-server architecture using smartcards. Lu et al.'s protocol comprises three participants, user (U i ), authorized server (S j ), 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 j via a secure channel. The various notations used in Lu et al.'s protocol are listed in Table 1. Step 5: U i checks the freshness of the message by verifying T c −T 2 ΔT. If it holds, then U i com- If it generates positive result, then U i authenticates S j , otherwise process aborts.
Step 6: U i generates a timestamp T 3 and computes SK ij = h(n 1 || n 2 || K || X i ), Step 7: S j verifies the freshness of T 3 and M 6 ≟ h(SK ij || ID i || n 2 || T 3 ). If it holds, then the mutual authentication with key agreement process between U i and S j is completed.
Step 1: U i inserts smartcard, inputs the identity ID i , password PW i , scans the biometrics BIO i and then verifies the condition V i ≟ h(ID i || h(PW i || H(BIO i ))). If it holds, then U i is allowed to choose a new password PW i new .
Step key PSK and random number x with S j via a secure channel. When an adversary's server AE 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 i launches the authentication request < Z i , M 1 , M 2 , M 3 , T 1 > by inserting smartcard and inputting ID i , PW i and BIO i .
Step 4: U i checks the freshness of the message by computing T c −T 2 ΔT. If it holds, then U i computes n 2 = M 4 È h(n 1 || h(PW i || H(BIO i )) || X i ) and verifies M 5 ≟ h(ID i || n 1 || n 2 || K || T 2 ). It is obvious that the condition holds, consequently U i treats AE as legitimate S j .
Step 5: U i generates a timestamp T 3 and computes SK ij = h(n 1 || n 2 || K || X i ), M 6 = h(SK ij || ID i || n 2 || T 3 ). Finally, U i sends < M 6 , T 3 > to AE. Now, U i may start the communication with AE using the computed session key SK ij = h(n 1 || n 2 || K || X i ) but then is unaware of impersonation attack by AE.
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 i and h(PW i || H(BIO i )) as presented here. Assume a legitimate user who contains h(PSK) becomes an adversary AE, 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 AE capture the U i 's message < Z i , M 1 , M 2 , M 3 , T 1 > while sending to S j during authentication phase.
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 AE can impersonate a valid user as explained below.
Step 1: As enlightened in prone to server impersonation attack and man-in-middle subsections, AE can obtain U i 's personal identifiable information such as ID i and h(PW i || H(BIO i )), and possesses x and PSK values.
Step 2: Now, AE generates a random number n 1 , timestamp T 1 and computes K = h(h(PSK) || SID j )), Step 3: S j checks the freshness of the message by computing T c −T 1 ΔT. If it holds, then S j . It is obvious that all the conditions generates positive results and S j treats AE as legitimate U i and proceeds further.
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 i transmits the authentication request message < Z i , M 1 , M 2 , M 3 , T 1 > to S j over public channels. The transmitted parameter M 1 = K È ID i , where K = h((Y i È y) || SID j )) in the message < Z i , M 1 , M 2 , M 3 , T 1 > are unique for each user and static during all logins. Hence anyone can track the actions of valid users, if he/she captures M 1 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 ij = h(n 1 || n 2 || K || X i ). The involved parameters K and X i are dependent on long term secret keys, and n 1 and n 2 are random numbers. As proved in server impersonation attack, when S j 's long term secret keys x and PSK are compromised, then AE can compute K = h(h(PSK) || SID j )), X i = h(ID i || x) and derive session key SK ij = h(n 1 || n 2 || K || X i ) 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 i , M 1 , M 2 , M 3 , T 1 > and < M 4 , M 5 , T 2 > transmitted between U i and S j contains timestamps T 1 and T 2 . Upon receiving these messages S j and U i checks the validity of timestamps by computing T c −T 1 ΔT and T c −T 2 ΔT. If these holds, then only S j and U i 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 i ), 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.

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(.).

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 S = x S P sends registration request < SID S , R S > to the RS.
Step 2: RS computes K S = h(SID S || PSK), where PSK is RS's secret key for application servers and RS stores {SID S , R S , K S } in its database table T US .
Step 3: RS sends K S to AS, which can be used in further phases of authentication.

User registration phase
A new user (U i ), who wants to avail the services provided by application servers must register with registration server (RS). U i goes after the following steps to register at RS as shown in Step 1: U i chooses an identity ID U , password PW U , a number b and scans biometrics BIO and computes . U i sends a request message < PID U , A U > to RS via a secure channel.
Step 2: RS computes B U = h(PID U || USK), C US = h(PID U || K S ) and D US = A U È C US , where USK is RS's secret key for users.
Step 3: RS personalize the parameters {B U , T US , P, h(.)} on a smartcard and delivers it to U i via a secure channel.
Step 4: and stores E U , G U , F U on the received smart card after deleting B U from smartcard. Thus the smartcard finally contains the parameters {E U , G U , F U , T US , P, h(.), H(.)}.

Login phase
When a user (U i ) wants to access the services of application server (AS), he/she launches the login request by inserting smartcard (SC), and inputting ID U , PW U and BIO.
Step 1: SC !AS: If it generates negative result, the login request can be terminated. Otherwise, SC retrieves corresponding application server's D US and R S values from the table T US . Then, SC generates a random number x U and calculates R U = x U P, sends the login request message < AID U , M 1 , R U > to AS. Step 1: . If the condition holds, AS authenticates U i , otherwise the process can be terminated.
Step 2: AS ! SC: < M 2 , M 3 > AS further generates a random number N 1 and computes SK = h(R U 0 || C US || SID S || N 1 ), Step 3: If the condition holds, U i authenticates AS, otherwise the process can be terminated. Then, SC computes M 4 = h(SK || N 1 ) and sends it to AS.
Step 4: AS verifies M 4 ≟ h(SK || N 1 ) and reconfirms the authenticity of U i . Now, U i and AS can start communication with the computed session key SK.

Password and biometrics changing phase
This procedure invokes when a user (U i ) wish to update his/her existing password with new one. In this procedure, U i can change his/her password without the involvement of registration server (RS) as follows: Step 1: U i inserts smartcard SC and inputs ID U , PW U and BIO.
Step 2: . If the condition holds, U i derives C US = A U È D US for all the servers in the table T US , otherwise request can be dropped.
Step 3: U i chooses a new password PW U # and BIO # and then computes

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 i 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.
• 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).
• hXi Y : Formula X combined with the formula Y.
• Q$ K R: 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.
• Q, X 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 i and AS: • Rule 1. Message-meaning rule: In order to show that the proposed protocol provides secure mutual authentication between a node R in the cluster C i and TM, we need to achieve the following four test goals: Generic form: The generic forms of the transmitted messages between the user U i and the application server AS in the proposed protocol are given below: Note that the message M3, U i ! AS: h(h(R U ', C US , SID S , N 1 ), N 1 ) authenticates the parameters R U ', SID S , N 1 under the shared secret C US between U i and AS. Thus, for simplicity we assume that the message M3 as U i ! AS: hR U 0 ; SID S ; N 1 i C US in the generic form.
Idealized form: The arrangement of the transmitted messages between U i and AS in the proposed protocol to the idealized forms are as follows: Hypotheses: The following are the initial assumptions of the proposed protocol: • H1: U i | #(R U ), • H2: AS | #(N 1 ), • H3: 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: AS⊲ hPID U ; • From S5 and Jurisdiction rule Rule 3, we obtain, S6: U i j U i $ SK AS (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: N 1 ), from S9 and H4, we get the required goal Goal 3, as S10: AS j U i j U i $ SK AS (Goal 4) • Finally, from S10 and Jurisdiction rule Rule 3, we obtain, S11: AS j U i $ SK AS (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 i submits pseudonym identity PID U = h(ID U || b) and the real identity is guarded with a one-way hash function. During login phase, the pseudonym identity PID U is converted as anonymous in the form of AID U = PID U È R U 0 .
The identity is dynamic for every login, due to its association with a randomly chosen number x U , where R U = x U P and R U 0 = x U R S . An adversary cannot retrieve the user's pseudonym identity PID U without having the knowledge of the user's password PW U and b. Moreover, it is believed to be impossible to compute R U 0 from R U and R S 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 i sends the message < AID U , M 1 , R U > to AS. All the parameters are dynamic and does not disclose any information about U i . 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 {PID U , R U } and {N 1 } and stores the values in its database tables, respectively. Consider a scenario where an adversary acquire {AID U , M 1 , R U } or {M 2 , M 3 } or {M 4 } 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 U in the form of R U = x U P and . The random number x U always keeps the transmitting parameters as dynamic for every session. If an adversary sends < AID U , M 1 , R U > to AS, it identifies R U as previous transmitted message and drops the requested session. In the same way, N 1 helps in identifying the replay attacks of {M 2 , M 3 } and {M 4 }. 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 U and N 1 .
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 {E U , G U , F U , T US , 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 Note that the identity of user ID U is not stored on the smartcard. The adversary cannot obtain any login information using the smartcard stored parameters E U , G U , F U . At the same time guessing the real identity ID U and password PW U 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 U i , he/she requires to build a login request message < AID U , . Conversely, the adversary can barely compute two parameters R U # = x U # P and R U #0 = x U # R S by choosing his/her own random number x U # . In order to compute rest of the two parameters, adversary requires user's identity ID U and password PW U , which are unobtainable.
On the other hand, the adversary should undergo login phase before making authentication request. During login phase, SC computes b = E U È H(BIO), A U = h(PW U || b), PID U = h(ID U || b), B U = F U È A U and then verifies the condition G U ≟ h(PID U || b || B U ). Unless the adversary enters the correct credentials, he/she cannot be allowed to further phases. Therefore, the adversary certainly requires legitimate identity ID U and password PW U for any furthermore computations. However, the probability of yielding correct ID U and PW U is negligible. The adversary may also try to extract PID U from AID U = PID U È R U 0 , by guessing x U from R U = x U P and R U 0 = x U R S . 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 with the generated random number N 1 and sends < M 2 , M 3 > to U i . 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 U 0 , C US and SID J . Assume that adversary still with the generated random numbers N 1 # and x S # . Note that SID S can be obtained from the table T US in the smartcard. Upon receiving the and tallies the received M 3 # with the computed M 3 .
Here, U i identifies it as a fake response from the malicious server due to M 3 6 ¼ M 3 # 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 < AID U , M 1 , R U > initiates from SC to AS. As explained in proposition 4, adversary can modify only one parameter R U # = x U # P with the chosen random number x U # . For instance the adversary sends the modified parameter in the message as < AID U , M 1 , R U # >. Upon receiving it, AS com- 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, U i does not submit identity ID U and password PW U in plaintext form to the registration server RS. U i submits only A U = h(PW U || b) and PID U = h(ID U || 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 i by verifying the equivalence of the received message with the computed values i.e.
is not involved in the authentication process, whereas password changing phase requires RS's help. However, RS does not verify the legitimacy of U i 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 {AID U , M 1 , R U } without any modifications. Upon receiving the request, AS computes R U 0 = x S . R U , PID U = AID U È R U 0 , and compares the extracted {PID U , R U } with the stored {PID U , R U }. When AS identify the received R U is same as the stored R U (i.e. R U = = R U ), then it can reject the request without even verifying M 1 ≟ h(PID U || C US || R U || R U 0 ). 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 {AID U # , M 1 # , R U # } for multiple. Upon receiving this message, AS computes . It is obvious that the condition generates negative response due to unavailability of original C US 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(R U 0 || C US || SID S || N 1 ) and the long term private key of the server K S in C US = h(PID U || K S ) 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 U 0 = x U Á R S is dynamic due to its association with random generated number x U , 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-themiddle 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.
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 i , 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 i is provided in Fig 5. U i first receives the start signal, updates its state value from 0 to 1. The state value is maintained by the variable State. U i sends the registration request message < PID U , A U > securely to the RS during the user registration phase with the SEND() operation. U i then receives a smart card SC containing the information {B U , T US , P, h()} securely from the RS by the RECV() operation, and updates its state from 1 to 2.
In the login phase, U i sends the message < AID U , M 1 , R U > to the AS via open channel. During the mutual authentication with key-agreement phase, U i then receives the message < M 2 , M 3 > from the AS and sends reply < M 4 > 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(U i , AS, u i as x u , x u ') declares that U i has freshly generated random number x U for AS. By the declaration secret(ID u , B', PW u , s1, U i ), we mean that the information ID U , b and PW U are kept secret to U i 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(U i , AS, u i as x u , x u '), signifies the AS's acceptance of the value x U generated for AS by U i . 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 U , b and PW U are kept secret to U i only. The authentication goal: authentication_on ui_as_x denotes that the U i has freshly generated random number x for the AS, where x is only known to U i . When the AS receives x from messages of U i , the AS checks a strong authentication for U i based on x. Similarly, the other authentication goal authentication_on as_ui_n1 denotes that the AS generates a random number N 1 for U i and when U i receives N 1 from other messages from the AS, U i checks a strong authentication for the AS based on N 1 .
Analysis of simulation results. The proposed protocol is simulated under the widelyaccepted 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.  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.

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 tradeoff 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.
• T h : Time complexity of a one-way hash function

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. Lee [34] Lin [39] Chen [24] L u [ 40] Our

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.