An Anonymous Authentication with Key-Agreement Protocol for Multi-Server Architecture Based on Biometrics and Smartcards

Abstract

Authentication protocols for multi-server architectures have gained momentum in recent times due to advancements in computing technologies and associated constraints. Lu et al. recently proposed a biometrics and smartcards-based authentication scheme for multi-server environment. The careful analysis of this paper demonstrates Lu et al.'s protocol is susceptible to user impersonation attacks and comprises insufficient data. In addition, this paper proposes an improved authentication with key-agreement protocol for multi-server architecture based on biometrics and smartcards. The formal security of the proposed protocol is verified using the widely accepted AVISPA (Automated Validation of Internet Security Protocols and Applications) tool to ensure that our protocol can withstand active and passive attacks. The formal and informal security analysis, and performance analysis sections determines that our protocol is robust and efficient compared to Lu et al.'s protocol and existing similar protocols.

1. Introduction

The vast expansion of internet and ubiquitous computing technologies have necessitated the authentication of every remote user. Cryptographic authentication is a secure practice of transferring credentials to determine someone, in fact, who they are proclaimed to be and providing authorization to access the services subsequently [1-2]. Typical authentication can be obtained in distinctive ways namely knowledge factors (passwords), possession factors (tokens) and inherence factors (biometrics) are some well-known methods [3]. Since Lamport’s [4] first proposed remote user password based authentication method in 1981, various improvements have been accomplished. Conversely, the shortcomings of passwords such as weak password, elusiveness, guessing attacks and so on have imposed to make passowrd-based authentication method stronger by adding smartcards. The smartcard with password based authentication methods [5-11] are widely deployed due to aspects like low cost, user-friendliness and robustness. In this method, the user is expected to insert the smartcard and enter the corresponding password in order to gain access to the system. However, research has shown that the password with smartcard based authentication methods are still vulnerable when the smartcard is stolen and the stored data is leaked out [12-15]. The ascribed limitations of password and smartcard based authentication methods have been required to add a third factor called biometrics. Biometric keys (palm print, iris, finger print, face etc.) are secure compared to the other two factors due to their uniqueness, unforgeability and non-transferability. Few modern authentication protocols have used smartcards, biometrics or both along with passwords [16-20].

Standard user authentication mechanism takes place by verifying entered credentials with the stored databases. Maintaining user database tables to verify the legitimacy of users is a hazard for application servers, which can weaken the security by leaking small amounts of information to hackers. Thus, the first idea of single server authentication without verification tables has been proposed by Hwang et al. in 1990 [21]. Numerous improvements have been proposed to the same idea, making it more complicated and costly. On the other hand, earlier authentication methods were limited to two party authentication architecture. This method is not sufficient when the number of users with varied interests and open networks keep increasing. Then again, as the number of application servers grows on, users are required to register with every server in order to avail the service, which is extremely tedious and adds the cost enormously. Parallely, users are even entailed to maintain a different key, credentials and smartcard for every application server. As a scalable solution, remote authentication protocol for multi-server architecture has been introduced by Li et al. [22] in 2001. Authentication protocol for multi-server architecture can facilitate effective solutions for above shortcomings due to the following facts:

In multi-server architecture, users can access any application server irrespective of their geographical location which makes it greatly worthwhile for various applications such as e-commerce, e-business, e-documentation, e-healthcare, etc [16] [23-25]. For instance, e-healthcare also known as telecare medical information system (TMIS) offers the health services via electronic means [24]. E-healthcare encompasses mainly three programs such as information exchange, money transaction, and medicine delivery. In general, all the aforementioned programs are handled by dissimilar servers and would be certainly a challenge for users, when they want to avail health care through internet communications. On the other hand, multi-server architecture makes it simpler by bringing all of them into one platform with a common infrastructure such as one-time registration, one smartcard and same credentials as depicted in Fig. 1. Thus, the users of multi-server architecture are beneficiary in terms of cost, efforts and time.

Fig. 1.Muli-server architecture functioning mechanism

Related works: In the past decade, several improvements have been made to the authentication protocols for multi-server architecture [16] [22-44]. In 2009, Liao et al. [32] proposed a secure dynamic ID based remote user authentication protocol for multi-server environment. Their protocol is based on one-way hash functions and exclusive-OR operations. In the same year, Hsiang et al. [28] proved that Liao et al.’s protocol is vulnerable to server spoofing attack, registration center spoofing attack, masquerade attack and insider attack. Additionally, they proposed an improved dynamic identity based mutual authentication without verification tables. However, in 2011, Sood et al. [39] showed that Hsiang et al.’s protocol is also susceptible to stolen smart card attack, replay attack and impersonation attack. Furtherly, they improved and proposed a protocol with different levels of trust between two-servers. Unfortunately, Li et al. [31] found that Sood et al.’s protocol is also prone to stolen smart card attack, leak-of-verifier attack and impersonation attack. In 2012, they put forward an efficient dynamic identity based authentication protocol with smart cards. In 2013, Pippal et al. [37] proposed a robust smartcard authentication scheme for multi-server architecture. In 2014, Xue et al. [42] demonstrated the drawbacks of Li et al.’s protocol such as eavesdropping attack, denial-of-service attack and forgery attack; and Yeh [43] shown the vulnerabilities of Pippal et al.’s [36] protocol such as server counterfeit attack, user impersonation attack and man-in-middle attack. In the same year, Xue et al. [42] proposed a lightweight dynamic pseudonym identity based authentication and key agreement protocol without verification tables for multi-server architecture; Yeh [43] proposed a provably secure multi-server based authentication scheme; and Chuang et al. [23] proposed an anonymous multi-server authenticated key agreement protocol based on trust computing using smartcards and biometrics. Later on, Mishra et al. [16] pointed out several weaknesses in Chuang et al.’s protocol and proposed a secure anonymous three factor authentication protocol. In 2015, Lu et al. [34] stated that Mishra et al.’s [16] protocol is exposed to user and server masquerading attacks, forgery attack and lacks perfect forward secrecy. Then, they proposed a biometrics and smart cards-based authentication scheme for multi-server environments. Yet in 2016, Mishra et al. [35] proved that Yeh protocol [43] contains flaws such as off-line password guessing attack, insider attack, user impersonation attack, and lack of user anonymity and further designed a provably secure multi-server authentication scheme.

Contributions of the paper: As evident in literature, most of the recently proposed multi-server authentication protocols failed to achieve several security properties while maintaining the best performance level. This paper’s keen analysis demonstrates that Lu et al.’s [34] protocol also has weaknesses such as user impersonation attacks and possession of insufficient data. In addition, this paper proposes an enhanced anonymous authentication with key agreement protocol for multi-server architecture without user verification tables based on biometrics and smartcards. 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. The formal security of the proposed protocol is verified using widely-accepted AVISPA [45] (Automated Validation of Internet Security Protocols and Applications) tool to show that the proposed scheme is secure. The security and performance analysis demonstrates that the proposed protocol is more robust and efficient than Lu et al.’s protocol and other relevant protocols.

Organization of the paper: Section 2 presents the prelimanaries. Section 3 provides the review of Lu et al.’s protocol. Section 4 crypt analyses Lu et al.’s protocol. Section 5 describes the proposed protocol. Section 6 portrays informal security analysis of the proposed protocol in detail. In Section 7, the simulation for the formal security verification of the proposed protocol using AVISPA tool. Section 8 affords performance analysis and comparison with the related protocols. At last, Section 9 concludes the paper.

 

2. Preliminaries

This section describes the fundamental preliminaries used in the proposed protocol such as public key cryptography, one-way has function, and bio-hash function.

2.1. Public Key Cryptography (PKC)

Public key cryptography or asymmetric key cryptography is a secure cryptography practice of exchanging signed messages among one-to-one. PKC uses a pair of distinctive keys called private key and public key to encrypt and decrypt the messages. The pair of keys are generated by the receiver where, public key is publicized and private key is remained private. The security of PKC primarily relies on personal secrecy means the safety of private key. The basic idea of first asymmetric encryption concept was proposed Whitfield Diffie & Martin Hellman in the year 1977 [46]. This idea works like a trapdoor one-way function, which is easy to proceed in forward direction, but hard in reverse direction [2]. Public-key algorithms are principal security components in protocols, cryptosystems and applications. Public-key algorithms are broadly categorized into three families called integer-factorization schemes, discrete logarithmic schemes and elliptic curve schemes [47]. Some public key algorithms afford digital signatures (e.g., DSA), some afford key establishment (e.g., Diffie–Hellman key exchange), and some afford both (e.g., RSA). PKC assures the fundamental properties of communication such as authenticity, confidentiality and non-repudiation. In PKC, the plaintext and ciphertext are integers; encryption locks the plaintext using public key and decryption unlocks the ciphertext using private key.

2.2. One-way hash function

A one-way hash function h: {0, 1}* {0, 1}n is an algorithm [48], which takes an arbitrary length string inputs x ∈ {0, 1}* and gives fixed length outputs h(x) ∈ {0, 1}n. The fundamental property of one-way hash function is that its outputs are very sensitive to small perturbations in inputs [16]. Hash functions are widely used in encryption algorithms along with databases to index and retrieve data items. The well-known hash functions are message-digest hash functions and secure hash algorithms. The ideal hash function has following main properties.

2.3. Bio-hash function

Biometric authentication is a technique in computer science to identify individuals on the basis of human physical characteristics such as fingerprint, palmprint, iris, face and so on. The unique nature of biometrics ensures the legitimacy of users and leads to high false rejection of valid users resulting low false acceptation [16]. Bio-hash function H(.) is a one-way hash function which takes arbitrary biometrics as input and gives fixed length output. A bio-hash function maps the biometric characteristics onto binary strings with user specific pseudo random generators. The bio-hash function obeys following properties [16] [49]:

 

3. Review of Lu et al.’s protocol

This section provides an overview of Lu et al.’s [34] biometrics and smartcards based authentication scheme for multi-server environments. Lu et al.’s protocol comprises three participants: user (Ui), authorized server (Sj), registration center (RC) and four phases: registration phase, login phase, authentication phase, and password change phase. RC initializes the system by sharing the chosen secret key PSK with Sj via a secure channel.

3.1. Registration phase

User (Ui) can register with registration center (RC) for the first time as shown below:

3.2. Login and authentication phases

In this phase, user (Ui) and server (Sj) authenticates each other, and also a session will be established between Ui and Sj as follows. Ui can launch the login request by inserting SC, and inputting IDi, PWi and BIOi as shown in Fig. 2.

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

3.3. Password changing phase

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

 

4. Weaknesses of Lu et al.’s protocol

This section cryptanalyses Lu et al.’s [34] protocol and provides the detail discussion of all security limitations. Lu et al. asserted that their protocol can withstand several renowned attacks. However, this section proves that their protocol consists few drawbacks.

Limitation 1: 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 a valid authentication credentials or be able to construct a valid authentication request message. In Lu et al.’s protocol, Ӕ can impersonate a valid user as depicted in Fig. 3.

Fig. 3.User impersonation attack on Lu et al.’s protocol

Limitation 2: Possession of insufficient data

An authentication protocol considered to be safe and secure, when the participating entities mutually authenticate each other. However, possession of insufficient data in Lu et al.’s protocol design may not accomplish important property called mutual authentication as described follows:

Since, Ui’s SC does not contain the x value, it is practically difficult to extract h(PSK) from Xi. Thus, Ui cannot construct a valid authentication request message < M1, M2 >.

 

5. The proposed protocol

This section proposes an improved biometrics and smartcards based remote mutual authentication with key agreement protocol for multi-server architecture. The proposed protocol comprises three participants: user (Ui), application server (AS), registration server (RS) and five phases: application server registration phase, user registration phase, login phase, mutual authentication with key agreement phase, and password and biometrics changing phase. The various notations used in the proposed protocol are listed in Table 1.

Table 1.Notations

5.1. Application server registration phase

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

5.2. User registration phase

A new Ui, who wants to avail the services provided by any AS must register with RS. Ui goes after the following steps to register with RS as shown in Fig. 4.

Fig. 4.User registration phase

5.3. Login phase

When an Ui wants to access the services of AS, he/she can launch the login request by inserting SC, inputs IDU, PWU and BIO.

5.4. Mutual authentication with key-agreement phase

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

Fig. 5.Login and mutual authentication with key-agreement phase

5.5. Password and biometrics changing phase

This procedure is invoked when Ui wish to update his/her existing password with new one. In this procedure, Ui can change his password over secure channel without the help of RS as follows:

5.6. Dynamic addition of application server phase

In this phase, a new application server ASnew can join the existing network by sending a registrationrequest to the RS in order to become an authorized server. The new application server’s information will be forwarded to the existing users of the network periodically using their stored IDU. The ASnew registration process consists of following steps:

 

6. Informal security analysis

Proposition 1. The proposed protocol achieves user anonymity and untraceability.

Proof. The original IDU of the Ui is protected throughout the communication of entities over insecure channels as described here. During login and authentication phase, the identity is shared via the encrypted message M2 = EPubs{IDU, SIDS, N1, M1} using Pubs. Ӕ cannot obtain the Ui’s IDU without having the knowledge of Pris. Ӕ may also try to trace the actions of users by observing the transmitting parameters. However, the proposed protocol provides another important feature called untraceability. The transmitted message M2 is dynamic for every login and does not disclose any information about Ui, due to its association with randomly chosen number N1. Consequently, the proposed protocol achieves user anonymity with untraceability.

Proposition 2. The proposed protocol is secure against replay attack.

Proof. Ӕ may try to establish a new session while impersonating a valid user by replaying the previous transmitted message < M2 >. However, the proposed protocol can withstand replay attacks using random numbers as explained here. During actual login and mutual authentication phase, AS decrypts the received message Dpris{M2} = {IDU, SIDS, N1, M1} and stores the pair {IDU, N1} in its database. If Ӕ replays the same message < M2# >, AS decrypts it compares the received {IDU, N1#} with the stored {IDU, N1}. When AS finds N1# == N1, then it can drop the request and terminate the process.

Proposition 3. The proposed protocol is secure against stolen smartcard attack.

Proof. With the hypothesis that Ӕ can read a SC stored values using various methods as discussed in [12-14], this section describes the resistance of the proposed protocol to stolen smartcard attack. Assume that Ӕ is able to read the stored parameters {EU, FU, GU, TUS, P, h(.)} on a stolen legitimate SC. Now, Ӕ may try either launching an authentication request to gain the access to AS or try deriving actual Ui’s credentials from the extracted parameters. However, Ӕ undeniably cannot perform any of above actions using these values, since all the important parameters such as EU = b ⊕ H(BIO), FU = BU ⊕ AU, GU = h(IDU || b || BU) are safeguarded with h(.), where AU = h(PWU || b) and BU = h(IDU || USK). Ӕ cannot build an authentication request < M2 > using the stolen SC due to the unavailability of IDU, PWU and BIO. At the same time guessing the IDU, PWU and forging BIO are impractical. Therefore, the proposed protocol can withstand smartcard stolen attack.

Proposition 4. The proposed protocol is secure against user impersonation attack.

Proof a. Assume a situation where Ӕ possesses a valid SC and wants to gain network access by perpetrating user impersonation attack. If Ӕ wants to impersonate a legitimate Ui, he/she requires to build a login request message < M2 >, where M2 = EPubs{IDU, SIDS, N1, M1}, M1 = h(IDU || CUS || N1). On the other hand, Ӕ should undergo login phase before making authentication request. During login phase, SC computes b = EU ⊕ H(BIO), AU = h(PWU || b), BU = FU ⊕ AU and then verifies whether the condition GU ≟ h(IDU || b || BU) holds. Unless the Ӕ enters the correct credentials, he/she cannot be allowed to further phases. Therefore, Ӕ certainly requires legitimate IDU and PWU for any furthermore computations. However, the probability of yielding correct IDU and PWU is negligible. Though the Ӕ performs guessing attacks for IDU and PWU, he/she definitely cannot forge or copy valid Ui’s BIO. Aforementioned constraints prove that our scheme is secure from user impersonation attack.

Proof b. Unlike Lu et al.’s protocol, the proposed protocol does not share much personal identifiable information of user. During login and mutual authentication phase, AS can obtain only IDU of legitimate Ui via the message M2 = EPubs{IDU, SIDS, N1, M1}. For instance, if any AS turns as Ӕ and wants to impersonate a valid Ui, he/she still requires CUS to construct M1 = h(IDU || CUS || N1). In the proposed protocol, CUS value is unique for every AS, where CUS = h(IDU || KS) and KS = h(SIDS || PSK). Moreover, CUS value is stored in the form of DUS = AU ⊕ CUS and can be extracted only after passing the true PWU and BIO of Ui.

Proposition 5. The proposed protocol is secure against application server impersonation attack.

Proof. Unlike the Lu et al.’s protocol, each AS of the proposed protocol contains unique long-term key KS which is computed based on SIDS as KS = h(SIDS || PSK), where PSK is secret key of RS. On the other hand, the key pair {Pubs, Pris} of each AS is also distinctive and Pris is known to only corresponding AS. Consider a scenario where an Ӕ captures < M2 > and tries to impersonate valid AS by responding with computed messages < M3#, M4# >. In order to execute this, CUS and N1 values are prerequisite. However, Ӕ cannot yield either of the values due to above described reasons. Though, the Ӕ perform guessing attack on N1 and compute SK# = h(CUS# || N1 || N2#), M3# = h(SK# || IDU || N2#), where CUS# and N2# are his/her own values. Upon receiving the response messages < N2#, M3# >, Ui can identify it as a malicious attempt due to the non-equivalence of messages M3# ≠ M3, where SK = h(CUS || N1 || N2#), M3 = h(SK || IDU || N2#). Thus, the proposed protocol can withstand application server impersonation attack.

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

Proof. In the proposed protocol scenario, Ӕ has the possibility of attacking on transmitted messages between Ui and AS. As clarified in proposition 1, Ӕ cannot obtain any useful information from the captured message < M2 > without Pris. Suppose the Ӕ possesses valid Ui’s IDU and wishes to send the modified parameters in the message as < M2# = EPubs{IDU, SIDS, N1#, M1#} >, then he/she definitely require CUS = h(IDU || KS), DUS = AU ⊕ CUS to compute M1. However, CUS value is unique for each Ui and AS and is unobtainable without passing AU = h(PWU || b). In similar way, if Ӕ wants to accomplish active attacks on response messages either < N2, M3 > or < M4 >, then SK = h(CUS || N1 || N2) is essential, which is again dependent mainly on CUS. Thus, the proposed protocol can endure man-in-middle attack.

Proposition 7. The proposed protocol is secure against password guessing attack.

Proof. Ӕ may try to guess the PWU using the extracted parameters stored on SC {EU, GU, FU, TUS, P, h(.)} or keep trying to login while guessing the PWU. However, Ӕ cannot validate the guessed PWU due to non-availability of parameter b. On the other hand, b value is protected with Ui’s BIO in EU = b ⊕ H(BIO) and it is believed to be impractical to forge a valid Ui’s BIO. The Ӕ definitely cannot proceed further without passing correct BIO resulting in failure of validating the guessed password using AU = h(PWU || b), FU = BU ⊕ AU, GU ≟ h(IDU || b || BU). In this way, the proposed protocol is secure against password guessing attack.

Proposition 8. The proposed protocol is secure against privileged insider attack.

Proof. In the proposed protocol scenario, during user registration phase, Ui does not submit either plain PWU or BIO to the RS. Ui submits only AU = h(PWU || b) and IDU to RS instead of original credentials, where b value is associated with H(BIO). Hence, an insider cannot obtain the original credentials of any Ui. On the other hand, the authentication of entities is being done by verifying the accuracy of received messages such as M1 ≟ h(IDU || CUS || N1). Moreover, RS does not involve in the authentication process. Therefore, the proposed ptorocol attains resistance to insider attack.

Proposition 9. The proposed protocol provides forward secrecy.

Proof. The session key of the proposed protocol is computed as SK = h(CUS || N1 || N2) and the long term private key of the server KS in CUS = h(IDU || KS) is shielded with a h(.). Note that, KS = h(SIDS || PSK) value varies from server to server and is not shared with any registered Ui. Assume that the long term key is compromised with Ӕ; still Ӕ cannot construct a valid session key due to following reason. The Ӕ would require the parameters IDU and N1, which are shared in the encrypted format using Pubs and are decryptable only with Pris. Moreover, the parameters N1 and N2 are random for each session. Therefore, the session key is considered to be safe even though the long term private key of AS is compromised.

 

7. Simulation for formal security verification using AVISPA tool

In this section, we simulate the proposed proposed using the AVISPA tool for the formal security verification [45]. 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.

7.1. Overview of AVISPA

AVISPA is a widely-accepted and used push-button tool for the automated validation of Internet security sensitive protocols and applications, which formally verifies whether a cryptographic protocol is safe or unsafe against passive and active attacks including the replay and man-in-the-middle attacks [16,36,38,50,51,52]. In AVIPSA, a security protocol is implemented using HLPSL (High Level Protocols Specification Language) [53]. 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 [54] 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 under what conditions the tested protocol is declared safe, or what conditions have been used for finding an attack, or finally why the analysis was inconclusive; PROTOCOL denotes the name of the protocol; GOAL indicates the goal of the analysis; BACKEND 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 [45]. For example, agent denotes the principal names. The intruder has always the special identifier i. public_key denotes agent’s 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 means the keys for a symmetric-key cryptosystem. text is often used as nonces, which can be also used for messages. nat denotes the natural numbers in non-message contexts. const denotes the constants. hash_func 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.

7.2. Implementation in HLPSL

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

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

Fig. 6.Role specifications in HLPSL for Ui and RS

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

Note that channel (dy) declares that the channel is for the Dolev-Yao threat model [54]. 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 [45]. 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 [45]. For example, witness(Ui, AS, ui_as_n1, N1’) declares that Ui has freshly generated random number N1 for AS. By the declaration secret({PWu.B’}, sc1, {Ui}), we mean that the information PWU and b are kept secret to Ui only, which is identified by the protocol id sc1.

In a similar way, the roles of the RS and AS of the proposed protocol are implemented and shown in Fig. 6(b) and Fig. 7(a), respectively. By the declaration, request(Ui, AS, ui_as_xu, Xu’), it is meant the AS’s acceptance of the value XU generated for AS by Ui.

Fig. 7.Role specifications in HLPSL for AS, and session, goal and environment

The roles for the session, and the goal and environment of the proposed protocol are also shown in Fig. 7(b). 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. 7(b). In the proposed protocol, we have three secrecy goals and two authentication goals. For example, the secrecy goal: secrecy_of sc1 indicates that the information PWU and b are kept secret to Ui only. The authentication goal: authentication_on as_ui_n2 denotes that the AS has freshly generated random number N2 for Ui. When Ui receives N2 from message from AS, Ui checks a strong authentication for AS based on N2.

7.3. Analysis of simulation results

The proposed protocol is simulated under the widely-accepted OFMC and CL-AtSe backends using the SPAN (Security Protocol ANimator for AVISPA) [50]. Both back-ends are chosen for an execution test and a bounded number of sessions model checking [55-56]. In OFMC backend, the depth for the search is 12 and output of the results are shown in Fig. 8. The total number of nodes searched in this case is 3510, which takes 9.25 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.09 seconds for translation. It is clear from the simulation results that the proposed protocol is secure under the test of AVISPA using OFMC and CL-AtSe backends with the bounded number of sessions.

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

 

8. Performance analysis

This section demonstrates the comparison between the proposed protocol and four other protocols regarding 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 when compared to Lu et al. and other related protocols.

8.1. Functionality comparison

In this section, the proposed protocol is compared with similar authentication protocols for multi-server architecture such as Chuang et al. [23], Mishra et al. [16], Lin et al. [33], Lu et al. [34] with respect to several security properties. The comparison of security properties between the proposed protocol and other four protocols are portrayed in Table 2. It is evident in Table 2, that all the other four similar protocols are susceptible to various security attacks whereas the proposed protocol can withstand such attacks and achieves divergent features for example no user verification tables, biometrics deployment, user anonymity, and untraceability.

Table 2.P1: User anonymity and untraceability, P2: Perfect mutual authentication, P3: Prevent replay attack, P4: Prevent man-in-middle attack, P5: Prevent stolen smartcard 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

8.2. Computational cost comparison

This section compares the proposed protocol with Chuang et al. [23], Mishra et al. [16], Lin et al. [33], Lu et al. [34] protocols in terms of computational cost. To evaluate the computational cost analysis, we give few notations for the involved actions in all the compared protocols as Th: Time complexity of a one-way hash function; Tmul: Time complexity of a point multiplication operation on elliptic curve; Tfun: Time complexity of encryption or decryption function. From the Table 3, it is evident that Chuang et al., Mishra et al., Lin et al, Lu et al. protocols, and the proposed protocol requires the computation complexity 19Th, 24Th, 15Th + 4Tmul + 6Tfun, 13Th + 2Tfun, and 12Th + 2Tfun, respectively. Therefore, the computational cost of the proposed protocol is relatively lesser than the other four protocols while accomplishing the significant security level.

Table 3.Comparison of computational cost

8.3. Communication overhead comparison

The communication overhead of the proposed protocol is compared with Chuang et al. [23], Mishra et al. [16], Lin et al. [33], Lu et al. [34] and organized in Table 4. To evaluate the communication cost of the compared protocols, this paper considers SHA-1 hash function of 160 bits length, timestamp of 32 bits length, random number of 160 bits length, 1024 bits modular prime for encryption and decryption functions and elliptic curve point of 160 bits length. Like the other similar protocols, the proposed protocol also uses 3 communication messages. In contrast, the proposed protocol requires only 1504 bits for the 3 messages. Therefore, the proposed protocol consumes less bandwidth compared to Lin et al., and Lu et al. protocols; and more compared to Chuang et al., Mishra et al. protocols.

Table 4.Comparison of communication overhead

 

9. Conclusions

This paper analyzed the recently proposed Lu et al.’s protocol for multi-server architecture and exhibited the flaws of their protocol. In addition, this paper proposed an improved anonymous authentication with key-agreement protocol for multi-server architecture based on biometrics and smartcards. The proposed protocol achieves significant features such as mutual authentication, user anonymity, no verification tables, biometric authentication, perfect forward secrecy, with less computational and communication costs. 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 built on simple encryption and decryption operations, one-way hash functions, concatenation operations and exclusive-OR operations which makes it perfectly suitable for practical applications. The formal and informal security analysis and performance analysis sections of this paper showed that our protocol is efficient compared to Lu et al.’s protocol and existing similar protocols.