Abstract
In a typical single-server architecture, when a user wishes to access multiple servers to obtain different services, the user needs to register with every single server. This results in multiple identities and password pairs. To eliminate the limitation of the user having to possess and remember multiple identities and password pairs, a number of multiserver authentication protocols have been proposed where a user only needs to register once. However, most existing protocols are subsequently found to be insecure and this topic remains one of the ongoing research interests. Thus, in this paper, we present a multiserver authentication key agreement protocol. We then demonstrate the security of the protocol under the random oracle model, as well as the practicality of the protocol in terms of low computation and communication costs, minimal storage requirements, and operation costs.
1. 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–4]; see Figure 1. One solution is using authentication or key agreement protocols to authenticate parties involved [5–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–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–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.
2. Preliminaries
We define the computationally hard mathematical problems.
Computational Diffie-Hellman (CDH) Problem. Given a tuple in which , , , and are the generators of , , and , respectively, the purpose of CDH problem is to compute , in which are unknown.
2.1. Security Requirements
Single Registration. For the convenience of the user, the proposed protocol for multiserver architecture should provide single registration. The user only needs to register at registration center and can freely access services.
Mutual Authentication. To protect the safety of participants, the proposed protocol should provide mutual authentication. The communicating participants should authenticate each other.
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.
3. General Architecture for Proposed Multiserver Authentication Protocol
In this section, we proposed the general architecture for multiserver authentication protocol. The protocol comprises three parties (i.e., user, server, and registration center) and three phases (i.e., user registration, server registration, and authentication). Prior to communication between a user, say , and a server, say , both parties need to register with a registration center ; see Figure 2.
The protocol is based on elliptic curve cryptosystem (ECC). chooses an elliptic curve in the finite field , where . There is an additive cyclic group which has elements in . then selects a random number as its private key and computes its public key . Table 1 describes the notations used in the remaining of this paper.
3.1. 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 1 (). The user chooses and at first and then selects a random number and computes . At last he sends to .
Step 2 (). Upon receiving the messages form , computes and . Then stores and into the Hash List and sends smart card including to through a secure channel.
Step 3. When receiving smart card form , the user stores his identity and the random number in the smart card.
3.2. 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 1 (). The server chooses and then sends to .
Step 2 (). Upon receiving the messages form , computes and sends to . At last stores and into the list.
Step 3. When receiving the messages form , stores the message .
3.3. 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.
Step 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 , and sends the message to .
Step 2 (). Upon receiving the message from , selects another secret value . Afterwards computes using ’s public key and sends to .
Step 3 (). (a)Upon receiving the message from , decrypts with its secret key, that is, . Then decrypts with its secret key, that is, .(b) computes and compares it with ; if the messages are not equal, then terminates this session. Otherwise authenticates and proceeds as per protocol specification. Then, it computes and compares it with . If they are not equal, cancels this session. Otherwise authenticates and proceeds as per protocol specification.(c) encrypts some information with ’s secret value and computes the authentication message , that is , . Finally, sends and to .
Step 4 (). (a)Upon receiving the messages from , decrypts with its secret value , that is, , and verifies the validity of . If the verification fails, cancels this session. Otherwise, authenticates and proceeds as per protocol specification.(b) computes the session key and the authentication message and encrypts some information with ’s secret value , i.e., , , . Finally, sends and to .
Step 5 ( verifies ). (a)Upon receiving the messages from , decrypts with its secret value , that is, . Since only and know the value of , compares with and cancels this session if the verification fails. Otherwise, authenticates .(b) computes the session key and verifies the validity of . If it is invalid, then cancels this session. Otherwise, authenticates and proceeds as per protocol specification.
4. Security Model and Security Proof
Prior to demonstrating the security of the protocol, we describe the model we work with.
4.1. Security Model
Similar to the approaches in [30, 31], 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, .
: the instance received correct message.
: the instance received wrong message.
: the decision has not been achieved.
Initialization: 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 .
(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.
(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:
The queried instance randomly chooses a number . If , then will receive the session key. Otherwise, randomly chooses a value and returns it back to .
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 .
4.2. 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 , and the probability of winning the game is . The series of games start from game to game
(i) Game 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 : In this game, E simulates the send- and hash-oracle-queries by accessing the Hash List. The send-queries contain five cases Send(, ), Send(, ), 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 is returned and is recorded in the Hash List. E cannot distinguish from . If the adversary E can win this game, then we can get(iii) Game Assume that in the previous games, all send- and hash-oracle-queries are executed correctly, except when a valid is queried. As discussed in Sections 3.1 and 3.2, we know that RC stores . Once E queries a valid , E obtains ’s private key . The distribution of the Hash List is restricted for any hash function; thus, the collisions may occur in hash oracle [33], or in the messages transmitted during protocol execution. and are not distinguishable; only if the above conditions occur, we can get the following.(iv) Game We consider that all the oracle queries are executed correctly in the previous games, except the authentication messages guessed by E. In other words, E executes Send and Execute() oracles and receives the corresponding correct answers: Send(, ), Send(, ), Send(, ), Send(, ), Send(, ), Execute(, ), Execute(, ). and are not distinguishable unless the oracle queries are rejected. If E wins this game, we can get the following.(v) Game In this game, we assume that all oracle queries are executed correctly in the previous games. However only if E guesses the correct private key , then the game will be terminated. If E guesses the correct , E can impersonate by selecting a secret value and computing . In the same way, E can impersonate if E correctly guesses . At the same time, if E guesses the correct private key , E can distinguish the session key from the random value, whereas E will obtain the correct hash values by guessing the hash one at a time. If E can win this game, then we can get the following.(vi) Game We embed the ECDH problem into the simulation process namely, An ECDH instance means that given the two points and , we need to compute without knowing the secret values and . We can first select a target session to challenge, and E will conduct the corresponding oracle queries. We embed the ECDH instance of and to take the place of and . Suppose that E can decrypt the MAC algorithm in the time range of .
Under these circumstances, we cannot distinguish the game from unless E can intercept or guess the correct secret values and and break the security of the underlying MAC algorithm. Thus E must compute .From the previous games, it is clear that there are no collisions on the authentication process and queries. At the same time, the authentication values and the hash value cannot be guessed correctly by the adversary E. Therefore, the previous games are independent of each other. The only way that E can win the game is to guess the value of b. Thus we know the following.
4.3. Analysis of Security Requirements
Single Registration: In this proposed protocol, the user only needs to register at registration center. When user logs in to any server in the system, the login information is sent to RC and verified by RC. Therefore, the protocol can provide single registration.
Mutual Authentication: In Section 3.3, RC, , and will authenticate each other.(i)RC authenticates and . Upon receiving message , RC decrypts it and and gets . Due to not guessing , there are only RC and computing or knowing even if E gets ’s identity . Thus, RC computes and compares it with . If they are equal, it can be said that RC authenticates . Afterwards the reason why RC authenticates is the same as that of why it authenticates . Thus it can be said that RC authenticates .(ii) and authenticate RC. Upon receiving message , decrypts and gets . Then it verifies the validity of with the value of . If it is valid, it can be said that authenticates RC. decrypts and compares with . If they are equal, it can be said that authenticates RC.(iii) and authenticate each other. computes session key and verifies on receiving message . If it is valid, it can be said that authenticates . authenticates by verifying with the same argument. If it is valid, it can be said that authenticates .
Therefore, the protocol can achieve mutual authentication.
User Anonymity: During the execution of protocol, ’s identity is only contained in messages and . While the messages are encrypted by and , respectively, that is, and , 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 . 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 session 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-in-the-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 , where is guessed by E as RC’s private key. E computes and sends to . Upon receiving the message , RC decrypts and computes where is RC’s real private key 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 and sends to RC. Upon receiving the message , RC decrypts and , 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 are encrypted by public keys. RC can find any modification by checking the equations and . are encrypted by ’s secret value, and cannot decrypt the messages once the messages are modified. are encrypted by ’s secret value, and cannot decrypt the messages once they are modified. Therefore, the protocol can resist modification attack.(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.
5. 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 encryption and decryption. Since the time complexity of an XOR operation is negligible compared to ,,, and , thus we ignore the XOR operation time.
In registration phase, computes and RC needs to compute and , which means that the computation cost is . In authentication phase, computes and performs an encryption operation in tep 1. Then carries out a decryption operation to authenticate , computes the session key using the elliptic curve point multiplication operation, and performs MAC algorithm twice to authenticate server and be server-certified in tep 5. Thus the total computation cost for user is .
, during the second and fourth step in authentication phase, needs to encrypt a message and decrypt the authentication message from RC, complete a MAC algorithm to authenticate RC, compute the session key with the elliptic curve point multiplication operation, and complete a MAC algorithm to be authenticated by . In the last step, the server completes a MAC algorithm to identify . Thus the total computation cost for server is . In the third step, RC carries out decryption operation twice to identify and . And then it encrypts a message and executes a MAC algorithm to be authenticated by . The total computation cost for server is .
From Table 2, we can see that the protocol of Sood et al. [28] fails to resist user impersonation attack and stolen card attack, the protocol of Lee et al. [27] cannot resist user impersonation attack and man-in-the-middle attack, and the protocol of Li et al. [29] is sensitive to stolen card attack and man-in-the-middle attack.
Table 3 is a comparative summary of the communication costs for the four protocols. Suppose that the secure length of ECC cryptosystem is 160 bits. Thus, we can know that the length of the encrypted data is 160 bits and the output length of the MAC is equal to the input data. Our proposed protocol’s communication cost is, therefore, 2080 bits.
6. Conclusion
In this paper, we proposed a general architecture for multiserver authentication key agreement protocol. With it, the user can subscribe many kinds of services just needing one pair of identity and passwords. We prove the architecture is secure and can provide resistance to various attacks under the random oracle model. In addition, our proposed protocol has lower computation and communication costs and good computational efficiency in terms of storage and operation cost.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
The work was supported in part by the National Natural Science Foundation of China (Nos. 61572370, 61572379, 61501333) and the fund of the Jiangsu Key Laboratory of Big Data Security & Intelligent Processing (No. BDSIP1807).