A General Architecture for Multiserver Authentication Key Agreement with Provable Security

1Key Laboratory of Aerospace Information Security and Trusted Computing, Ministry of Education, School of Cyber Science and Engineering, Wuhan University, Wuhan 430072, China 2Jiangsu Key Laboratory of Big Data Security & Intelligent Processing, Nanjing University of Posts and Telecommunications, Nanjing 210023, China 3Department of Information Systems and Cyber Security, e University of Texas at San Antonio, San Antonio, USA


Introduction
With the constant development in information and communications technologies (ICT) and digitization of our society, there is an increased trend of users accessing online service (e.g., electronic commerce transactions).Generally speaking, the user interacts with the remote server (e.g., service provider) in an open environment, where an adversary can intercept, modify, or delete data-in-transmit (e.g., messages and transactions between devices and users) [1][2][3][4]; see Figure 1.One solution is using authentication or key agreement protocols to authenticate parties involved [5][6][7][8][9].If the identities of both parties can be verified, then the protocol is said to provide mutual authentication.
Due to the popularity of smart cards, a number of authentication protocols for smart cards in single-server environments have been proposed [10][11][12].However, in single-server environments, a user must register on every server that the user wishes to access.This results in the need of users to maintain and ensure the security of the corresponding identities and passwords pairs.Thus, designing secure authentication protocols for smart cards in a multiserver environment has been studied by security researchers [13][14][15][16].
Once a user registered (and only once) in a multiserver setting, the user can access services from participating servers using the (one) identities and passwords pair.This benefits both users and servers, in the sense that it reduces the number of identities and password pairs for the user and the size of the verification tables for the servers.For example, in 2001, Li et al. [17] proposed a multiserver architecture based on neural networks.Later in 2003, Lin et al. [18] revealed weaknesses in Li et al. 's protocol, and the time required to train the underpinning neural network limits the utility of the protocol.Hence, Lin et at.proposed a multiserver architecture based on discrete logarithms to achieve better performance which was subsequently found to be insecure against impersonation attack [19].Juang et al. [20] also presented a protocol designed for symmetric cryptosystem, but this protocol does not provide insider attack resilience and has a high computation cost.The protocol of Chang and Lee [21] for multiserver structure requires that all participants be trusted, which may not be a realistic assumption in practice.In addition, due to the requirement for all servers to be trusted, the protocol is not secure against privileged insider attack.
In a latter work, Tsai et al. [22] presented a protocol and the authors use a one-way hash function to reduce the computation cost (since no verification table is required).However, Chen et al. [23] pointed out that Tsai et al. 's protocol is vulnerable to server spoofing attacks.In order to achieve user anonymity, Liao et al. [24] proposed a multiserver authentication protocol with dynamic identities, although it was subsequently pointed out that this protocol does not forward secrecy [25].Independently, Hsiang et al. [26] revealed other security vulnerabilities in the protocol of Liao et al. [24] (e.g., insecurity against insider attack and server spoofing attack) and proposed an improved protocol.The latter protocol was found to be insecure against server spoofing attack [27], contrary to its security claims.An improved protocol is again proposed [27].While pointing out that the (improved) protocol in [27] cannot resist impersonation attack and smart card stolen attack, the authors in [28] presented an enhanced multiserver architecture with dynamic identities.Separately, Li et al. [29] revealed that the protocol of Lee et al. [27] cannot resist server spoofing attack and the protocol of Sood et al. [28] cannot resist smart card stolen attack, prior to presenting a smart card-based protocol for a multiserver architecture.However, to achieve mutual authentication, Li et al. 's scheme requires a control server.
It is clear that most existing protocols are not able to resist a range of attacks and this is the contribution we seek to make in this paper.Specifically, we present a general secure architecture for multiserver authentication key agreement protocol.We then prove that the protocol is secure under the random oracle model.We also demonstrate that the architecture enjoys better performance, in the sense of lower computation and communication costs, minimal storage requirements, and lower operation costs.
In the next section, we describe the general architecture of the proposed multiserver authentication protocol.Then in Sections 3 and 4, we analyze the security and performance of the proposed protocol, respectively.We conclude the paper in the last section.

Preliminaries
We define the computationally hard mathematical problems.User Anonymity.To protect user's privacy, the proposed protocol should provide user anonymity.Even though the adversary can interact with the messages, he/she cannot get user's identity.
Untraceability.To provide better privacy protection, the proposed protocol for multiserver architecture should support untraceability.The adversary cannot find any relation and trace users from the messages sent by users.
Secure Session Key Agreement.To ensure the security of the messages transmitted in the continuous communication, the proposed protocol should provide a secure session key shared between the participants to encrypt messages.
Backward and Forward Secrecy.To ensure the security of the messages transmitted in the previous and future communication, the proposed protocol should provide backward and forward secrecy.Even though the adversary can get the current session key, he/she cannot get the session key generated in the previous and future session.
Resistance of Various Attacks.To withstand various attacks in the real environment, the proposed protocol for multiserver architecture should provide resistance to various attacks.  . .User Registration Phase.The user   sends the registration request    and    to  and receives a smart card including the private key in this phase.  stores the random number on the smart card, and  stores    and ℎ(   ‖ ) in the list.Figure 3 outlines the user registration phase.
Step .When receiving smart card form , the user   stores his identity    and the random number  in the smart card.
. .Server Registration Phase.The server   sends its registration request that is    to  and receives its secret key in this phase. stores    and ℎ(   ‖ ) into the list.Figure 4 outlines the server registration phase.
Step .When receiving the messages form ,   stores the message   .
. .Authentication Phase.  and   authenticate each other by means of , and transmitted messages between both parties are verified.A session key is also established between   and   .The detailed authentication phase is shown in Figure 5.

Security Model and Security Proof
Prior to demonstrating the security of the protocol, we describe the model we work with.
. .Security Model.Similar to the approaches in [30,31] (vi) Reveal(  ):  queries and obtains session key(s) of session(s) other than the target session.
(vii) Corrupt(  ,    ):  will receive   's password    , as long as the user is not associated with the target session (key).
(viii) Corrupt(  , ):  will receive   's secret value   as long as the user is not associated with the target session (key).
(ix) Test(  ): To obtain the session key,  selects a target instance and initiates this query only once.The query is answered as blow: (1) The queried instance    /   randomly chooses a number  ∈ {0, 1}.If  = 1, then  will receive the session key.Otherwise,    /   randomly chooses a value and returns it back to .
(2) In other cases, the queried instance    /   does not have the session key and returns ⊥ to adversary .
Let |  | denote the length of the Hash List and the protocol assume the intractability of the Elliptic Curve Diffie-Hellman Problem (ECDH) described below.Definition 1 Elliptic Curve Diffie-Hellman Problem (ECDH) [32]: There are two points  and  in an additive group , and it is infeasible to compute point .
. .Security Proof (AKA Security). executes all the steps in time t; hence, he can make execution within  ℎ hash-queries,   send-queries, and   execute-queries.Thus the advantage is as follows.
Proof.We demonstrate the security of the protocol using a series of games.  indicates that in the query of Test(  )  can correctly guess the value of  for each game   (0 ≤  ≤ 5), and the probability of  winning the game The series of games start from game  0 to game  5 : (i) Game  0 :  0 is a game describing the real word with random oracles.In this game, E can access the messages transmitted during authentication process by executing the oracles.If E can win this game, then we can get: (ii) Game  1 : In this game, E simulates the send-and hash-oracle-queries by accessing the Hash List.The sendqueries contain five cases: Send(  ,  1 ), Send(,  2 ), Send(  , ℎ  ), Send(  , ℎ   ), and Send(  , ℎ   ).The Hash List consists of {, ℎ()}, where  is the input of the hash function and ℎ() is the output of the value.If  is in the record, then ℎ() is the returned value.Otherwise, a value ℎ() randomly chosen from {0, 1} 160 is returned and {, ℎ()} is recorded in the Hash List.E cannot distinguish  1 from  0 .If the adversary E can win this game, then we can get: (vii) Man-in-the-Middle Attack: Based on the above analysis, we conclude that the proposed protocol can provide mutual authentication.Thus the protocol can resist man-in-the-middle attack.

Performance Analysis
In this section, we analyze the computation complexity, the resistance of various attacks, and communication cost of our architecture for multiserver authentication key agreement.And then we make the comparison with the protocols previously mentioned in the related work; they are the protocol of Sood et al. [28], the protocol of Lee et al. [27], and the protocol of Li et al. [29].Table 2 is a comparative summary of the computation costs and analysis of various attacks for the four protocols, in which  ℎ denotes the time complexity of completing a typical hash function,   denotes the time complexity of completing an elliptic curve point multiplication operation,   denotes the time complexity of completing a MAC algorithm, and   is the time complexity of executing an

Figure 1 :
Figure 1: An example model of communication between users and remote servers.

Figure 3 :Figure 4 :
Figure 3: User registration phase in the proposed protocol.

Table 1 :
Summary of notations.
1 }).  inserts the smart card into the terminal and then enters the identity    and password    .Afterwards the smart card computes the value of   ; that is,   =   ⊕ ℎ(   ‖ ).The smart card also selects a secret value    (e.g.,   or , where  is the generator in a multiplicative group and  is the generator in elliptic curve).Finally, he uses 's public key   to encrypt the secret value and user's identity, computes  1 =    (  ,    ,    , *   ), and sends the message  1 to .Step (  →  : { 2 }).Upon receiving the message from   ,   selects another secret value    .Afterwards   computes  2 =    (  ,    ,    ,  1 ) using 's public key   and sends  2 to .
(b)   computes the session key and the authentication message ℎ   and encrypts some information with   's secret value    , i.e.,  =    *    * , ℎ   =     (   ,    , ),  2 = receives a private key and a smart card from , and server   receives its private key similarly from .Participants can authenticate each other and establish a session key by executing the protocol.Once    and    obtain  and a session key is established, it can be said that the three participants authenticate each other and     =     .Adversary capabilities: The adversary  has the capability to eavesdrop, intercept, and modify the messages during the protocol execution, with the aim of obtaining the session key.(i) h() : When E executes the query with the message , RC generates a random   ∈  *  , stores (,   ) into the Hash List, and returns   to E. (ii) ExtractUser(   ): When E executes the query with the user   's identity    , RC generates   's private key and stores it in the list   .(iii) ExtractServer(   ): When E executes the query with   's identity    , RC generates   's private key and stores it in the list   .
, we assume that there are three entities in the model, namely, (protocol) participants, initialization, and the adversary capabilities respectively.Participants:The parties involved in the protocol are the user   , server   , and registration center .let    /   represent the  − ℎ instance of   /  and execute a protocol, and each instance is also known as an oracle.In general there are three states of an oracle: Accept, Reject, * .c: the  − ℎ instance received correct message.: the  − ℎ instance received wrong message.* : the decision has not been achieved.Initialization: (iv) Send(  /  , ):  sends a message  to   /  .If  is valid and received by    /   , then   /  sends a response to , while accepting the session.(v) Execute(  ,   ):    and    output the real messages transmitted in protocol process.
(   ,    , ℎ(   ‖ )), even though E intercepts the messages, as long as he cannot get RC's private key  or server   's secret value    , E cannot get    .Untraceability: During the execution of protocol, the user generates a random secret value    to compute message  1 =    (  ,    ,    ).According to the protocol, we know that user will randomly generate secret values at each execution.Thus the adversary cannot find any relation from the messages sent by   and also cannot trace users.Therefore, the protocol can provide untraceability.Secure Session Key Agreement:   and   compute the key  = (   ,    ) independently.  checks the validity of  by verifying ℎ   , where ℎ   is encrypted by   's private key    .  checks the validity of  by verifying ℎ   , where ℎ   is encrypted by   's private key    .The valid  can be used in the future communication.Therefore, the proposed protocol is able to provide secure session key agreement.Backward and Forward Secrecy: Assume that E knows the current .Owing to the session key  = (   ,    ), where the secret values    and    are randomly selected by   and   .Different    and    are selected with the execution of protocol, and each session key is independent; thus, even if the current session key is known by E, he cannot know the previous and coming session key.Resistance of Various Attacks: We will show that the protocol can withstand insider attack, off-line password guessing attack, user impersonation attack, server spoofing attack, modification attack, stolen card attack, and man-inthe-middle attack.The details are shown as follows.(i) Insider Attack: In registration phase,   sends {   , ℎ(   ‖ )} to RC. Suppose that an insider attacker can get user's information; however, obviously the password    is not in plain text.Thus the adversary cannot get correct password from the messages.In addition, RC stores {   , ℎ(   ‖ )} in a list, and the insider attacker cannot get password from the list.Therefore, the protocol can resist the insider attack.(ii) Off-line Password Guessing Attack: Assume that the adversary steals user's smart card and can extract the information {   ,   , } by the side channel attack, where   = ℎ(   ‖ ) ⊕ ℎ(   ‖ ),  is RC's private key.The adversary can guess the password  *   .However, E cannot verify the correctness from   because the password is protected by the secure hash function and RC's private key .Therefore, the protocol can resist off-line password guessing attack.(iii) User Impersonation Attack: E wants to impersonate   ; he should send message   to   and be verified by RC.E selects two random numbers as his identity   and his secret value   .Then E computes   = ℎ(  ‖  and compares it with   .However, E does not know RC's private key .Thus RC cannot authenticate the impersonated user and the protocol can resist user impersonation attack.(iv) Server Spoofing Attack: E wants to impersonate   ; he should send legal message   to RC and be verified by RC.E selects two random numbers as his identity   and his secret value   .Then E computes   = ℎ(  ‖  * ), where  * is guessed as RC's private key.E computes   =    (  ,   ,   ,  1 ) and sends   to RC. Upon receiving the message   , RC decrypts   and  1 , then computes ℎ( *   ‖ ), and compares it with   .However, E does not know RC's private key .Thus RC cannot authenticate the server and the protocol can resist server spoofing attack.(v) Stolen Card Attack: Assume that the adversary steals user's smart card and can extract the information {   ,   , } by the side channel attack, where   = ℎ(   ‖ ) ⊕ ℎ(   ‖ ),  is RC's private key.The adversary can guess the password  *   .However, E cannot verify the correctness from   because the password is protected by the secure hash function and RC's private key .Therefore, the protocol can resist stolen cards attack.(vi) Modification Attack: According to the authentication phase, we know that authentication messages { 1 ,  2 } are encrypted by public keys.RC can find any modification by checking the equations   = ℎ(   ‖ ) and   = ℎ(   ‖ ).{ 1 , ℎ  , ℎ   } are encrypted by   's secret value, and   cannot decrypt the messages once the messages are modified.{ 2 , ℎ   , } are encrypted by   's secret value, and   cannot decrypt the messages once they are modified.Therefore, the protocol can resist modification attack.
* ), where  * is guessed by E as RC's private key.E computes   =    (  ,   ,   ) and sends   to   .Upon receiving the message  2 , RC decrypts   and computes ℎ(  ‖ ) where  is RC's real private key