Security and Communication Networks

Security and Communication Networks / 2020 / Article

Research Article | Open Access

Volume 2020 |Article ID 2523834 | 14 pages | https://doi.org/10.1155/2020/2523834

Efficient Hierarchical Authentication Protocol for Multiserver Architecture

Academic Editor: José María de Fuentes
Received23 Aug 2019
Revised14 Nov 2019
Accepted22 Jan 2020
Published24 Mar 2020

Abstract

The multiserver architecture authentication (MSAA) protocol plays a significant role in achieving secure communications between devices. In recent years, researchers proposed many new MSAA protocols to gain more functionality and security. However, in the existing studies, registered users can access to all registered service providers in the system without any limitation. To ensure that the system can restrict users that are at different levels and can access to different levels of service providers, we propose a new lightweight hierarchical authentication protocol for multiserver architecture using a Merkle tree to verify user’s authentication right. The proposed protocol has hierarchical authentication functionality, high security, and reasonable computation and communication costs. Moreover, the security analysis demonstrates that the proposed protocol satisfies the security requirements in practical applications, and the proposed protocol is provably secure in the general security model.

1. Introduction

Rapid advances in wireless communication technologies bring convenience to our lives. With an increasing number of users and services, the single-server architecture authentication protocols can no longer meet people’s various requirements [1]. Multiserver architecture authentication (MSAA) protocols have emerged and been widely used in the Internet of things, wireless sensor networks, smart grid, cloud computing, and mobile payment. Because MSAA protocols have better properties than single-server architecture authentication protocols [2, 3], it becomes a hot spot in current research.

However, due to the openness of the multiserver environment, an adversary can easily control communication channels and carries out many types of attacks such as intercept, modify, replay, and delay messages between multiple parties. For defending these attacks, researchers proposed many authentication protocols for the multiserver architecture that are using cryptographic methods to secure communication between different parties. New protocols also have lower computation and communication costs than the previous protocols. Currently, MSAA protocols can be divided into two types by whether it involves the registration center at the authentication phase. The first type is MSAA protocols with the involving at the authentication phase (MSAA1) [1, 2, 411], and the second type is MSAA protocols without involving at the authentication phase (MSAA2) [1223]. In MSAA1 protocols, verifies every mutual authentication process, which makes it a bottleneck in MSAA1 protocols. The communication cost in MSAA1 protocols is significantly increased compared to MSAA2 protocols. To address these drawbacks, researchers proposed many MSAA2 protocols which have more efficiency and security than the existing MSAA1 protocols [14].

Currently, hierarchical authentication functionality is missing in the existing MSAA2 protocols. When a user registered at , he/she can authenticate with all registered service providers [24] and access to their services. However, there are many different users and service providers in this system, and the user’s level is different from each other, and low-level users should not successfully authenticate with high-level service providers and access to their services. Besides, there should be some high-level service providers only providing service for some particular users such as VIP users. In general, the MSAA protocols with the hierarchical authentication functionality will have flexibility in managing user authentication rights and access capabilities. The hierarchical authentication functionality has been achieved in the MSAA1 protocol [2, 4]. In the MSAA1 protocol, an is required at the authentication phase. Therefore, can verify the user’s authentication rights to determine whether he/she can access to service providers that are at a particular level. However, MSAA1 protocols have several drawbacks such as unreasonable communication cost that we showed earlier, making the whole system inefficient. Suppose we apply the existing MSAA2 protocols to the above environment; there should be multiple s to manage users and service providers at different levels. Users and service providers need to store various certificates from different s. The missing of hierarchical authentication functionality in the existing MSAA2 protocols motivates us to design a new lightweight hierarchical authentication protocol for multiserver architecture.

The proposed protocol uses a self-constructed Merkle tree to achieve hierarchical authentication functionality. In the proposed protocol, a session key is established between service providers and users without involving ; this significantly reduces communication cost and makes the authentication process faster. The proposed protocol can meet the security requirements of the multiserver architecture and is provably secure in general security model.

The remainder of this paper is organized as follows. Section 2 discusses the related work. Section 3 describes preliminaries. In Section 4, we show the details of the proposed protocol. Section 5 gives out the formal security proof of the proposed protocol. Section 6 presents a comparison of the proposed protocol with other related protocols on security, computation, and communication costs. Section 7 concludes the paper.

Li et al. [1] proposed a new multiserver architecture authentication (MSAA) protocol for cloud computing based on the identity-based model. Shao and Chin [4] proposed an authentication protocol for multiserver architecture but failed to resist the server spoofing and the impersonation attacks. He and Wang [5] constructed the first genuinely three-factor authentication protocol for the multiserver architecture, but their protocol is vulnerable to the known session-specific temporary information attack and impersonation attack. Odelu et al. [6] proposed an improved protocol to solve the security drawbacks in [5]. Xie et al. [7] proposed a two-factor authentication protocol. However, Xie’s protocol cannot resist the lost smart card attack and the offline dictionary guessing attack. To address the drawbacks, Chandrakar and Om [8] proposed a new security-enhanced three-factor protocol. Feng et al. [9] proposed an enhanced biometrics-based authentication protocol that can provide user anonymity. Amin et al. [10] proposed a lightweight authentication protocol that has lower computational and communication costs. Cui et al. [11] proposed an efficient protocol that only uses nonce, exclusive-OR operation, and one-way hash function; their protocol greatly reduces the computation cost. However, in this kind of protocol, they all need the help of an online registration center to achieve mutual authentication, which increases the communication cost.

In order to solve the drawbacks in the first type protocol, Choi et al. [12] proposed the first MSAA protocol without the online registration center. Tseng et al. [13] proposed a list-free ID-based authentication protocol using bilinear pairings for the multiserver architecture. However, Tseng et al. [13] cannot provide credentials privacy and untraceability for users. Recently, Odelu et al. [14] and He et al. [15] proposed new protocols that reduce the computation and communication costs. Irshad et al. [16] found protocol in [17] cannot achieve desired security goals. Therefore, they proposed an improved multiserver authentication protocol for distributed mobile cloud computing services. Afterward, Xiong et al. [18] found protocol in [16] has unreasonable computation cost, so they proposed an enhanced protocol for distributed mobile cloud. At the same time, Xiong et al. [19] proposed a new lightweight anonymous authentication protocol to reduce computation and communication costs. Barman et al. [25] used fuzzy commitment approach to secure the information stored on personal device. Kumari et al. [20] proposed a concept of the fuzzy extractor to provide the proper matching of biometric patterns. Xu et al. [21] proposed a new protocol that provides untraceability. Jiang et al. [22] performed a security analysis to the protocol in [17], pointing out that it is vulnerable to the impersonation attack. Chatterjee et al. [23] proposed a biometric-based protocol using the chaotic map and enhanced the security for multiserver architecture. We summarize techniques, advantages, and disadvantages that the existing protocols used in Table 1.


ProtocolTechniqueAdvantageDisadvantage

[1]Identity-basedLightweight and efficientCannot provide user anonymity
[4]Identity-basedProvides user anonymity, resists server spoofing attack and impersonation attack, etc.Cannot resist server spoofing attack and impersonation attacks
[5]Biometrics-basedFirst truly three-factor authenticated schemeCannot resist known session-specific temporary attack and the impersonation attack
[6]Biometrics-basedProvides secure authentication and resists passive and active attacksNeeds registration center online for authentication
[7]Identity-basedSecurity enhanced and supports smart card revocation and password update without centralized storageCannot resist the lost smart card attack and the offline dictionary guessing attack
[8]Biometrics-basedEfficient in terms of computation cost, communication cost, and resists smart card storage costHigh maintenance cost
[9]Biometrics-basedIncurs low overhead, suitable for deployment at mobile devicesNeeds registration center online for authentication
[10]Two-factor-basedSecurity enhanced, lightweight, and efficientNeeds registration center online for authentication
[11]Identity-basedResists the server spoofing attackNeeds registration center online for authentication
[12]Identity-basedDoes not need registration center online for authenticationCannot provide hierarchical authentication
[13]Identity-basedProvides black/white list-free and simple revocation mechanismCannot provide credentials privacy and untraceability
[14]Identity-basedProvides SK-security and strong credentials’ privacyCannot provide hierarchical authentication
[15]Identity-basedUses the self-certified public key cryptography and has lower computation and communication costsCannot provide hierarchical authentication
[16]Two-factor-basedResists server spoofing attack, desynchronization attack, and denial-of-service attackCannot provide hierarchical authentication
[17]Two-factor-basedReduces authentication processing time required by communication and computation between cloud service providers and traditional trusted third-party serviceCannot resist service provider impersonation attack and has no user revocation facility
[18]Biometrics-basedProvides three-factor security, user revocation, and reregistrationCannot provide hierarchical authentication
[19]Biometrics-basedUser anonymity, perfect forward secrecy, and resistance to desynchronization attackCannot provide hierarchical authentication
[21]Two-factor-basedProvides user untraceability and perfect forward securityCannot provide hierarchical authentication
[23]Biometric-basedUses chaotic map to improve efficiencyCannot provide hierarchical authentication

3. Preliminaries

In this section, we introduce preliminaries of the proposed protocol.

Let and be an additive cyclic group and a multiplicative cyclic group, both of them have a large prime order q. Let denote a bilinear map. Suppose P is a generator of , is a generator of . A bilinear map has the following properties:(i)Bilinearity: for all and for all , (ii)Computability: there exists an algorithm that can successfully compute for all (iii)Nondegeneracy: there exists such that , where 1 is the identity element of

We list the hard problems that we used in the proposed protocol as follows:(i)Discrete logarithm (DL) problem: given an element , it is hard to compute such that (ii)Computational Diffie–Hellman (CDH) problem: given two elements , it is hard to compute , where a and b are unknown and randomly chosen from (iii)Modified Bilinear Inverse Diffie–Hellman with k value (k-mBIDH) problem [12]: given k elements and elements each of them is in , it is hard to compute , where and τ and η are two unknown elements in

A security system parameter generator used in the proposed protocol is introduced below.

: the system parameter generator takes a security parameter n and outputs system parameters, a bilinear map, an elliptic curve, a multiplicative group, etc. Intuitively, the system parameters will be publicly known.

The notations used in the proposed protocol are listed in Table 2.


NotationDescription

The registration center
The user
The service provider
The adversary
The identity of user
The identity of service provider
The password of a user
The user’s personal biometrics
The biometric key
eThe private key expire parameter
Random numbers from
The session key
Concatenation operation
The authentication right tree
The authentication right tree on service provider side
The authentication right parameters
The node of the authentication right tree
The subnode of
The fuzzy-extractor generation procedure
The deterministic reproduction procedure
Secure one-way hash functions
ID revocation list

4. The Proposed Protocol

4.1. RC Initialization Phase

Registration center runs the generation function which takes a security parameter and outputs parameters as follows:(1) chooses two bilinear map groups and with a prime order q, the generator and , where is a bilinear map.(2) chooses cryptographic hash functions , , , .(3) chooses a random number as the master key, computes the corresponding public key , and constructs an authentication right tree as Figure 1. The detail of the tree will be described in Section 4.5. Finally, publishes .

4.2. User Registration Phase

If a user wants to register with the registration center , the following steps will be executed. The main steps are provided in Table 3.(1) sends his/her identity to via a secure channel.(2) selects an authentication parameter and computes the ’s private key , where e is the expire date of the private key and is an authentication right tree. chooses a parameter and sends to via a secure channel.(3) computes using the fuzzy-extractor generation procedure [26], where is a biometric key, is a public reproduction parameter, and is his/her personal biometrics. computes and uses the widely implemented fuzzy-verifier technique [27, 28] to compute , where pw is his/her password and is the integer that defines in [27]. Finally, stores on its mobile device, where t is the threshold in fuzzy extractor, is the probabilistic generation procedure for outputting , and , is the deterministic reproduction procedure that can recover and from a new personal biometrics input.


Mobile user Registration center

Computes private key and selects
Computes , and stores

4.3. Service Provider Registration Phase

If a service provider wants to register with the , the following steps will be executed. The main steps are provided in Table 4.(1) sends his/her identity to via a secure channel.(2) computes the private key for and sends to him via a secure channel, where is an authentication right tree for service provider. We will describe the detail of in Section 4.5.(3)Finally, saves .


Service provider Registration center

Computes
Stores

4.4. User and Service Provider Authentication Phase

In this part, we show the mutual authentication phase between a user and a service provider without involving . The main steps are provided in Table 5.(1)First, inputs his/her biometrics , identity and password into his/her mobile device. Mobile device computes and and verifies the validity of inputted biometrics and password by computing . If it holds, mobile device retrieves ’s private key by computing and temporarily saves . Then, selects a temporary session secret , calculates , and computes , by using the identity of . Next, computes, , and . Finally, sends the login message to .(2)After receiving , checks whether is in ; if is not in , retrieves using his/her private key as . retrieves by computing . computes , where , and verifies . If both are equal, is allowed to authenticate with . Then, selects a temporary session secret , then he/she calculates and computes , and session key is set as . Finally calculates and sends the message to .(3)Upon receiving , computes and and checks whether and are equal. If both are not equal, aborts the session. Otherwise, confirms as a valid service provider and sets as session key between and .


Mobile user Service provider


Retrieves , computes , , and accepts/rejects
Computes , checks , and accepts/rejects

4.5. Tree Construction and Verification

The proposed protocol uses an authentication right tree to store user’s and service provider’s hierarchical authentication information. is a Merkle hash tree that was introduced by Merkle [29] in 1998. Merkle hash tree is a digital signature scheme that only uses a conventional encryption function to compute the digital signature, making it extremely efficient. In 2009, Satoshi proposed a peer-to-peer electronic cash system, as known as bitcoin [30]. Bitcoin system stores transactions in Merkle hash tree, which saves disk space, and this method can be used to verify transactions in each block. Therefore, we use a Merkle hash tree to construct our authentication right tree. In this part, we will show how we construct an authentication tree and how to verify a user’s authentication right based on the rules of Merkle hash tree.

4.5.1. Tree Construction

First, we introduce the construction of the authentication right tree as Figure 1. An authentication tree contains the information of n different levels. The first level is the lowest level in the system, and the level is the highest level in the system. Node denotes a user that has the authentication right which is from the first level to level. Value stored in node is computed from the hash values of its left child node and right child node as . The calculation of node as is different from other nodes. If a user is at the first level, is embed in his/her private key, and he/she can only access to first level service providers in this system. If user is at level, is embed in his/her private key, and he/she can access to service providers which are from first to levels. The right child node is an intermediate variable, which prepares for calculating . Value stored in node is computed from the hash values of its left leaf node and right leaf node as . Leaf node and are two 160-bit random strings that are stored on user and service provider separately. If a user is at level, number i is stored in the last bits, and the first bits should be a random string.

4.5.2. Tree Stored on Service Provider

The authentication right tree stored on the service provider has a little different from . Service provider uses to verify user’s authentication right. The scale of stored on each service provider is based on the level of service provider. As we mentioned above, level is the highest level in the system. If service provider is at level, he/she only provides service for level user, so he/she only needs to save the authentication right tree as Figure 2. If service provider is at the level, he/she can provide service for user that is from to level. Therefore, he/she needs to save to and to as Figure 3, where the symbol “?” denotes the node that service provider does not have.

4.5.3. Authentication Right Verification

When an level user wants to access a level service provider, where , user sends to service provider, and when service provider received authentication parameter , he/she checks the last bits of to get user’s level and finds . Service provider computes the value of as and the value of as . Then service provider verifies user’s authentication right by calculating . If the equation holds, service provider continues. Otherwise, he/she aborts the session. For instance, if a level user wants to access to a level service provider, user sends to service provider, and when service provider received authentication parameter , he/she checks the last bits of to get user’s level and finds . Service provider computes and . Service provider verifies user’s authentication right by calculating . If the equation holds, service provider continues. Otherwise, he/she aborts the authentication.

4.6. The User Revocation and Reregistration Phase

Revocation and reregistration has been used in many protocols [31, 32]. In this part, we describe user revocation and reregistration. When a user lost his/her smart card, he/she needs to reregister. submits his/her personal information to , and then, verifies ’s personal information and checks the expire date of the private key . If has already expired, issues a new private key with a new expire date. If has not expired, issues a new ID and a new private key with the same expire date as the lost smart card. adds the lost to its ID revocation list and board casts to all service providers. After received , service providers save it into their local storage.

5. Security Proof

In this section, we analyze the security of our protocol. First, we present a security model for our protocol, which is based on Bellare–Rogaway (BR) model [33] and CK-adversary model [34], and we use Zipf’s law [35] to enhance the security of the base model. Second, we show that the security of the proposed protocol is based on the hardness of mathematical problems. Third, we show that our protocol satisfies security requirements.

5.1. Security Model

We propose a security model for the proposed protocol based on literature studies [5, 15, 27, 33, 36]. There are and at the authentication phase of the proposed protocol. The security of the proposed protocol is defined by a game played between an adversary and a challenger . Let denote the lth instance of the participant of , respectively. In this game, we describe the capabilities of that is defined in the literature [27] as follows:(i) can enumerate offline all the items in the Cartesian product within polynomial time, where and denote the password space and the identity space, respectively(ii) has the capability of somehow learning the victim’s identity when evaluating security strength (but not privacy provisions) of the protocol(iii) is in full control of the communication channel between the protocol participants(iv) may either (i) learn the password of a legitimate user via malicious card reader or (ii) extract the sensitive parameters in the card memory by side-channel attacks, but cannot achieve both(v) can learn previous session keys(vi) has the capability of learning server’s longtime private keys only when evaluating the resistance to eventual failure of the server (e.g., forward secrecy)

can issue queries to and get answers from it as follows:(i): at any time, issues query where can be any string, and picks a random number and stores into list , where and . Finally, sends to .(ii)ExtractUID (): issues queries of user identity , and generates users private key and stores into list .(iii)ExtractSID : issues queries of service provider’s identity , and generates service provider’s private key and stores into list .(iv)Send : issues query of the message m, and runs the protocol and returns the result to .(v)SKReveal : issues query, and returns the session key produced in to .(vi)CorruptUID : issues the query of user’s identity , and returns user’s private key to .(vii)CorruptSID : issues the query of service provider’s identity , and returns service provider’s private key to .(viii)Test : when issues the query, flips a random coin . If , sends session key in to ; otherwise, , and picks a random number with the same length of session key and sends it to .

After issuing the queries above, outputs , where is about the coin b produced in Test -query. violates the authentication key agreement (AKA) of the proposed protocol , if can guess b correctly. We define ’s advantage in attacking the proposed protocol as .

Definition 1. (AKA-Secure). The proposed protocol is authentication key agreement secure (AKA-Secure) if is negligible for any polynomial-time adversary .
violates the mutual authentication of the proposed protocol , if can generate a legal login message or a legal response message. Let and denote the events that generates a legal login message and a legal response message. We define the advantage of attacking the mutual authentication of the proposed protocol as .

Definition 2. (MA-Secure). The proposed protocol is mutual authentication secure (MA-Secure) if is negligible for any polynomial-time adversary .

5.2. Proof of Security

In this part, we show the proposed protocol for multiserver architecture is AKA-secure and MA-secure in the security model we described above.

Lemma 1. No polynomial-time adversary can forge a legal login message with a nonnegligible probability ϵ.

Proof. Suppose the adversary forges a legal login message with a nonnegligible probability ϵ. We show there is a challenger who can solve the discrete logarithm (DL) problem with a nonnegligible probability.
Given an instance of the DL problem, the aim of challenger is to compute , and sends the system parameters to . randomly selects and answers ’s queries according to the following description:(i): maintains a list initialized empty. Upon receiving the query , checks if exists in . If yes, sends to ; otherwise, randomly picks and stores in then sends to , where .(ii)ExtractUID : maintains a list initialized empty. When receiving the query , checks if exists in then send to ; otherwise, executes the operations as follows:(1)If , sets and stores into , into (2)Otherwise if , randomly selects , sets , and stores in , in (iii)ExtractSID : maintains a list initialized empty. When receiving the query , checks if exists in . If yes, send to ; otherwise, randomly picks and computes . stores into , into and sends to .(iv)Send : checks if and are equal; if yes, aborts the game; otherwise, operates according to protocol .(v)SKReveal : after received the query, sends session key produced in to .(vi)CorruptUID : searches for in and returns to .(vii)CorruptSID : searches for in and returns to .(viii)Test : randomly picks a number with the same length of session key and sends it to .At last, outputs a legal login message corresponding to user’s identity . If , aborts the game. Based on the forking lemma [37], can output another legal login message . Because the login messages is legal, we get the following two equations, is computed by rising to the power of a random number chose by :Based on the two equations above, we get the following equations: outputs as the solution to the given DL problem. The probability that can solve the DL problem is described as follows:(i): dose not abort in the any Send-queries(ii): outputs a legal login request(iii): and are equalLet l denote the number of bits in biometric data, and denote the number of Send-queries and -queries executed in the game, and are the Zipf’s parameters [35], and l is the length of biometric information. We can get , , and .
Therefore, the nonnegligible probability that can solve the DL problem is given byThis contradicts with the hardness of the DL problem. Therefore, we get that no polynomial-time adversary against the proposed MSAA protocol can forge a legal login message with a nonnegligible probability.

Lemma 2. No polynomial-time adversary can forge a legal response message with a nonnegligible probability.

Proof. Suppose the adversary forges a legal response message with a nonnegligible probability . We show there is a challenger who can solve the k-mBIDH problem with a nonnegligible probability.
Given an instance of the k-mBIDH problem, the aim of challenger is to compute ; he picks a random number and computes , and sends the system parameters to . randomly selects and answers ’s queries according to the following description:(i): maintains a list initialized empty. Upon receiving the query , checks if exists in . If yes, sends to ; otherwise, randomly picks and stores in then sends to , where .(ii)ExtractUID : maintains a list initialized empty. When receiving the query , checks if exists in and then sends to ; otherwise, randomly picks and computes . stores in , in and sends to .(iii)ExtractSID : maintains a list initialized empty. When receiving the query , checks if exists in and then sends to ; otherwise, executes the operations as follows:(1)If , sets and stores into , into (2)Otherwise if , randomly selects , sets , and stores in , in (iv)Send : checks if and are equal; if yes, aborts the game; otherwise, operates according to the proposed protocol .Finally, outputs a response message corresponding to identity . outputs as the solution of k-mBIDH problem. The probability that can solve the k-mBIDH problem is described as follows:(i): dose not abort in any Send-queries(ii): C outputs a legal response message(iii): and are equalLet , and denote the number of Response-query, -query, and -query in the game. We can get , , and . Therefore, the nonnegligible probability that can solve the k-mBIDH problem is given byThis contradicts with the hardness of the k-mBIDH problem. Therefore, we get that no polynomial-time adversary against the proposed MSAA protocol can forge a legal response message with a nonnegligible probability.

Theorem 1. The proposed protocol is MA-secure if the DL problem and the k-mBIDH problem are hard.

Proof. Based on Lemmas 1 and 2, we get no polynomial-time adversary can forge a legal login message or a legal response message if the DL problem and the k-mBIDH problem are hard. Therefore, we get the proposed protocol is MA-secure.

Theorem 2. The proposed protocol is AKA-secure if the CDH problem is hard.

Proof. Suppose guesses b correctly in -query with a nonnegligible probability ϵ, then can solve the CDH problem with a nonnegligible probability.
Let denote the event that gets the correct session key. Since the probability that correctly guesses the value b is at least , we can get .
Let and denote the events that uses in the Test-query to a user’s instance and a service provider’s instance, respectively. Let denote the event that can violate the user to service provider authentication. We get the following two equations:Since , we getWe get the probability as follows:According to the proof of Lemma 1, we get is negligible. However, is nonnegligible, suppose that where . Given an instance of the CDH problem, computes with a nonnegligible probability . Therefore, can use to solve the CDH problem with a nonnegligible probability. This contradicts with the hardness of the CDH problem. Therefore, we can conclude that the proposed protocol is AKA-secure if the CDH problem is hard.

5.3. Security Requirements Analysis

We briefly show the proposed protocol satisfies the security requirements as follows:(i)Single registration: according to the specification of the proposed protocol, a user registers at the registration center once, and he/she can log into registered service providers, which is at a specific level. Therefore, the proposed protocol can provide single registration.(ii)Mutual authentication: two lemmas described above show that the adversary against the proposed protocol cannot produce a valid login or response message. Then, and can authenticate with the participant by checking the legality of the received response message and login message, respectively. Therefore, the proposed protocol can support mutual authentication.(iii)User anonymity: according to the proposed protocol, the user’s identity is only in the message . To get , adversary needs to compute from , and it turns out the adversary need to solve the k-mBIDH problem. Then, we know that the proposed protocol can provide user anonymity as long as k-mBIDH problem is hard.(iv)Untraceability: according to the proposed protocol, user generates a new random number to compute . Due to the randomness of , adversary cannot find any relation of messages sent by the user and cannot trace the user’s behavior. Therefore, the proposed protocol can provide untraceability.(v)Session key agreement: according to the proposed protocol, both two participants calculate session key , which can be used in future communications. Therefore, the proposed protocol can provide session key agreement.(vi)Perfect forward secrecy: assume the adversary steals both private keys of the user and the service provider. We also assume that the adversary intercepts sent between the user and the service provider. Using the service provider’s private key, the adversary can compute . To get session key , the adversary must to compute where . Thus, adversary must solve the CDH problem. Then, the proposed protocol can provide the perfect forward secrecy, since the CDH problem is hard.(vii)No smart card lose attack [20]: assume the adversary steals the user’s device. By using the side-channel attack, the adversary can extract the data . The adversary can guess password , but he/she cannot verify its correctness because we have implemented the fuzzy-verifier technique [27, 28]. The adversary cannot get the user’s password, so he cannot get the user’s private key . Therefore, adversaries cannot impersonate the user to the service provider, and the proposed protocol can resist smart card lose attack.(viii)No password verifier table: according to the proposed protocol, both two participants need to store their private keys, and the registration center needs no password verifier table. Thus, the proposed protocol provides no password verifier table.(ix)No online registration center: according to the proposed protocol, two participants can authenticate with each other without the help of the registration center. Thus, the proposed protocol does not need an online registration center.(x)Hierarchical authentication: this security requirement only satisfied by the proposed protocol. The hierarchical information is embedded in the user’s private key, when authentication is with a service provider, service provider will check the user’s authentication right by computing whether the equation holds.(xi)The resistance of various attacks: the proposed protocol can resist the insider attack, the replay attack, the man-in-the-middle attack, etc. We briefly describe it as follows:(1)Temporary information attack: if the adversary gets the temporary information , he/she has no ability to derive the user’s secret key from because the exponential of is composed of two values: one is session temporary secret and other is the private key of the user . Therefore, the proposed protocol is secure against temporary information attack.(2)Insider attack: suppose an insider in the system gets the user’s information . The adversary can guess a password . However, he/she cannot verify its correctness because user’s password is protected by the secure hash function and the biometric key . Thus, the insider cannot get user’s password, and the proposed protocol withstands the insider attack.(3)User impersonation attack [38, 39]: according to the proof of Lemma 1, we conclude that no adversary can forge a legal login message without the user’s private key. Thus, the service provider can find out about the attack by verifying the validity of the received login message. Therefore, the proposed protocol can resist the user impersonation attack.(4)Server spoofing attack: according to the proof of Lemma 2, we know that no adversary can generate a legal response message without the service provider’s private key. Therefore, users can find out about the attack by verifying the validity of the received response message. Therefore, the proposed protocol can resist the server spoofing attack.(5)Modification attack: according to the proof of Lemma 1, we know that is a digital signature of the login message and no polynomial-time adversary can forge a legal one. The service provider can find any modification by checking if the equation and holds. Besides is the message authentication code of the response message under the key . The user can find out about any modification of the response message because the hash function is secure. Therefore, the proposed protocol can resist the modification attack.(6)Replay attack: according to the proposed protocol, both two participants generate new random number and , which are involved in the login message and the response message. Due to the freshness of , the user and the service provider can find the replay of messages by checking the validity of the received message. Therefore, the proposed protocol resists the replay attack.(7)Man-in-the-middle attack: based on the above description, we conclude that the proposed protocol provides mutual authentication between two participants. Therefore, the proposed protocol can resist the man-in-the-middle attack.

5.4. Security Comparison

In this part, we compare the security of the proposed protocol with other multiserver architecture protocols in Table6. We introduce a new independent criterion, which is based on a widely adopted standard [40, 41] as follows:C1 (no password verifier table): the server does not need to maintain a database for storing user passwords or some derived values of user passwords.C2 (password friendly): the password is memorable and can be chosen freely and changed locally by the user.C3 (no password exposure): the password cannot be derived by the privileged administrator of the server.C4 (no smart card loss attack): the scheme is free from smart card loss attack, i.e., unauthorized users getting a victim’s card should not be able to easily change the password of the smart card, recover the victim’s password by using online, offline or hybrid guessing attacks, or impersonate the user to login to the system, even if the smart card is obtained and/or secret data in the smart card are revealed.C5 (resistance to known attacks): the scheme resists various kinds of basic/sophisticated attacks, including offline password guessing attack, replay attack, parallel session attack, desynchronization attack, stolen verifier attack, impersonation attack, key control, unknown key share attack, and known key attack.C6 (sound repairability): the scheme provides smart card revocation with good repairability, i.e., a user can revoke her card without changing her identity.C7 (provision of key agreement): the client and the server can establish a common session key for secure data communications during the authentication process.C8 (no clock synchronization): the scheme is not prone to the problems of clock synchronization and time delay, i.e., the server needs not to synchronize its time clock with these time clocks of all input devices used by smart cards, and vice versa.C9 (timely typo detection): the user will be timely notified if she inputs a wrong password by mistake when login.C10 (mutual authentication): the user and server can verify the authenticity of each other.C11 (user anonymity): the scheme can protect user identity and prevent user activities from being traced.C12 (forward secrecy): the scheme provides the property of perfect forward secrecy.C13 (hierarchical authentication): when a server authenticates with a user, it checks the user’s authentication right. If the user authentication right belongs to the server authentication level, the authentication is successful. Otherwise, the authentication request is denied.


Protocol roundsComputation costCommunication costStorage costSecurity requirements
User sideServer sideUser sideServer sideC1C2C3C4C5C6C7C8C9C10C11C12C13

Odelu et al. [14]3