1 Introduction

Wireless communications have become a very attractive and interesting sector for the provision of electronic services. Mobile networks are available almost anytime and anywhere, and the popularity of wireless handheld devices is high. The services offered are strongly increasing because of the wide range of the users’ needs [1]. With the rapid development of mobile networks, many mobile services are available online such as mobile banking, mobile government, mobile learning, mobile online game and so on. It is obvious that in future wireless protocols and communication environments (networks), security will play a key role in transmitted information operations [1]. As mobile devices bring a lot of convenience in our daily life, the security issues, how to authenticate mobile users in insecure communication networks, have become a hot research topic. To authenticate the identity of remote users in a public environment, the password-based authentication protocol was proposed in the first place. The first remote password-based authentication protocol for the insecure communication was proposed by Lamport [2] in 1981. In 2000, Hwang and Li [3] pointed out Lamport’s protocol is vulnerable to the risks of interpolation attacks since the server must store the verifiers of users’ passwords. Thus, Hwang and Li proposed a remote user authentication protocol using smart cards, which is based on ElGamal [4] public key cryptosystem. Since then, in order to lessen the communication and computation costs and remove the security issues, large number of smart card-based authentication protocols designed for single-server environment had been proposed [512]. However, it is difficult and bothersome for a user to remember numerous various identities and passwords when using single-server authentication protocol to login and access different remote servers. Therefore, Lee and Chang [13] proposed a user identification and key distribution protocol based on the difficulty of factorization and hash function, and agree with the multi-server environment. The user only needs to register at the registration center once and can access all the authorized services in remote servers. After that, much research devoted to the study of authentication of multi-server environments has been proposed [1421].

From 2001, Li et al.’s [15] remote user authentication protocol based on the neural networks was found to spend too time and cost since users need large memory to store public parameters for authentication. After that, many protocols were continuously proposed to improve the previous ones. In 2008, Tsai [22] uses the nonce and one-way hash function to propose an efficient multi-server authentication protocol without a verification table. Because of low computation costs, Tsai’s protocol is very suitable to be used in the distributed networks.

The aforementioned protocols are based on static ID which an adversary might intercept the login ID from the public network and use it to trace the legal user. In 2009, Liao and Wang [23] first proposed a dynamic ID-based remote user authentication protocol for multi-server environment. However, Hsiang and Shih [24] found that Liao et al.’s protocol is vulnerable to insider attack, masquerade attack, server spoofing attack, registration center spoofing attack, and is not reparable. Moreover, Liao et al.’s protocol cannot provide mutual authentication. Therefore, Hsiang et al. proposed an improved protocol to solve these problems. In 2011, Sood et al. [25] pointed out Hsiang et al.’s protocol is still susceptible to replay attack, impersonation attack and stolen smart card attack. Besides, the password change phase of their protocol is incorrect. Sood et al. proposed a secure dynamic identity based authentication protocol claimed to achieve user’s anonymity and be against various attacks. Recently, Li et al. [26] discovered Sood et al.’s protocol still suffers leak-of-verifier attack, stolen smart card attack and impersonation attack. Furthermore, the authentication and session key agreement phase of Sood et al.’s protocol is not correct since the control server has no way to know the real identity of the user. In 2012, Liao et al. [27] present a novel pairing-based remote user authentication protocol for multi-server environment. The proposed scheme provided a more secure key distribution based on self-certified public keys (SCPKs) among the service servers, the protocol based on elliptic curve cryptosystem is more secure and efficient. However, through careful analyses, we find that Liao et al.’s protocol is still susceptible to the trace attack. Besides, Liao et al.’s protocol is inefficient since each service server has to update its ID table periodically. In this paper, we propose an improved protocol to solve these weaknesses. By enhancing the security, the improved protocol is well suited for the practical environment.

The rest of the paper is organized as follows. In Sect. 2, a brief review of Liao et al.’s protocol is presented. The security flaws and weaknesses of Liao et al’s protocol are shown in Sect. 3. Our architecture and the improved protocol is proposed in Sect. 4. Section 5 makes the security analysis of the proposed protocol and Sect. 6 compares the performance and functionality of the proposed protocol with the related protocols. The conclusion is given in Sect. 7.

2 Review of Liao et al.’s protocol

The notations used in this paper are listed in Table 1.

Table 1 The notations used in this paper

In this section, we review Liao et al.’s self-certified public key-based authentication protocol for multi-server environment. The details of mathematics of computation, including bilinear pairings, the related computational problems, BLS short signature protocols and self-certified public key (SCPK) cryptosystems can be referred to [2730]. There are five phases in Liao et al.’s protocol. These phases are explained in the following paragraphs. First, all needed parameters are generated by a key generator center (KGC) which is impersonated by the registration server RS. Next, the registration server RS chooses a random number \(s_{RS}\in Z_{q}^{*}\) keeping as the system private key and computes Pub \(_{RS}=s_{RS}\in P\) as the system public key, where \(P\) is a generator of the group \(G_{1}\). Finally, two hash functions \(H(\cdot )\) and \(h(\cdot )\) are selected by the registration server RS. The public parameters and functions, Params = \(\{ \hat{e}, G_{1}, \,G_{2}, q, P, Pub_{RS}, H(\cdot ),h(\cdot )\}\), are published.

2.1 Server registration phase

When a service server \(\textit{SS}_{j}\) joined in the multi-server environment, the service server \(SS_{j}\) first generates a random number \(v_{j}\in Z_{q}^{*}\) and submits \(V_{j}=v_{j}\cdot P\) along with the identity \(\textit{SID}_{j}\) to the registration server RS. Then the registration server RS generates a random number \(w_{j} \in Z_{q}^{*}\) and performs the following computations

$$\begin{aligned} W_j&= V_j +w_j \cdot P \\ \hat{S}_j&= (h({\textit{SID}_j \vert \vert W_j})\cdot S_{RS} +w_j)\,\hbox {mod}\, q \end{aligned}$$

After that, the registration server RS issues the values \(s_{j}\) and \(W_{j}\) to the service server SS \(_{j}\). Finally, the private key \(s_{j}\) = (\(s_{j}\) + \(v_{j})\) mod \(q\) is computed by the service server \(SS_{j}\), and the service server \(SS_{j}\) computes the following equation to check the validity of the received values

$$\begin{aligned} Pub_j=s_j \cdot P=h({\textit{SID}_j \vert \vert W_j})\cdot Pub_{RS} +W_j \end{aligned}$$
(1)

Now the service server has his own private key \(s_{j}\)and public key \(Pub_{j}\) after the service registration phase.

2.2 User registration phase

When the user \(U_{i}\) wants to access the services provided by the multi-server system, he/she has to register the registration server RS by submitting the related information. Next, the registration server RS issues the smart card containing some secret information to the user \(U_{i}\) over a secure channel. The process of user registration phase is depicted as follows.

U1.:

\(U_{i} \quad \rightarrow \) \(RS:\{\textit{ID}_{i}, \textit{HPW}_{i}\}\) The user \(U_{i}\)chooses a password \(PW_{i}\) and a random value \(b_{i}\in Z_{q}^{*}\). Next the user \(U_{i}\)uses the password salting mechanism to calculate \(\textit{HPW}_{i}=h\)(\(PW_{i}\vert \vert b_{i})\cdot P\). Then the user \(U_{i}\) sends \(\{\textit{ID}_{i},\textit{HPW}_{i}\}\) to the registration server RS.

U2.:

\(RS \rightarrow \) \(U_{i}\): the smart card containing \(\{\textit{ID}_{i},\,Reg_{IDi},\,Pub_{RS},\,h(\cdot ),\,H(\cdot )\}\) After receiving \(\{H\!(\textit{ID}_{i}),\,\textit{HPW}_{i}\}\), the registration server RS checks if ID format is valid and if \(\textit{ID}_{i}\) has already existed in the database. If both of them are correct, the registration server RS calculates \(\textit{QID}_i =H({\textit{ID}_i}),\textit{DID}_i =({T_i s_{RS}})\cdot \textit{QID}_i \hbox {and}Reg_{IDi} =\textit{DID}_i \oplus s_{RS}\cdot \textit{HPW}_i, \text{ where }T_i \in Z_q^*\) denotes the current registration time generated by the registration server. Finally, the registration server RS issues the smart card containing \(\{{\textit{I}D}_{i},\,Reg_{IDi},\,Pub_{RS},H(\cdot ),\,h(\cdot )\}\) to the user \(U_{i}\) over a secure channel. At the same time, the registration server RS maintains an ID table which includes \(\{{\textit{I}D}_{i},\,T_{i}\}\). After that, the service servers received the updated entries periodically over globaly a secure channel.

U3.:

Upon receiving the smart card containing \(\{{ ID}_{i},\, Reg_{IDi},\, Pub_{RS},\,H(\cdot ),\,h(\cdot )\}\), the user \(U_{i}\) stores them with \(b\) in the smart card.

2.3 Login phase

After completing the registration phase, the user \(U_{i}\) can use the smart card issued by the registration server RS to login to the service server \(SS_{j}\).

L1.:

\(U_{i}\rightarrow \) the smart card: \(\{\textit{ID}_{i},\,\textit{PW}_{i}\}\) The user \(U_{i}\) inserts the smart card into the card reader and then enters his/her identity \(\textit{ID}_{i}\) and password \(\textit{PW}_{i}\). The smart card generates a random number \(r_{i}\in Z_{q}^{*}\) and calculates \(R_{i}\) = \(r_{i}\cdot P\). The smart card then computes \(\textit{DID}_i =Reg_{IDi} \oplus h(\textit{PW}_i \vert \vert b_i)\cdot Pub_{RS} ,\,\textit{QID}_i =H({\textit{ID}_i}),\,Mi=r_i\cdot \textit{ QID}_i,\,d_{ij}\,=h({\textit{ID}_i \vert \vert {\textit{SID}_j} \vert \vert }M_i \vert \vert R_i)\text{ and }\, B_{ij} =({r_i +d_{ij} })\cdot \textit{ DID}_i\).

L2.:

\(U_{i}\rightarrow SS_{j}:\{\textit{ID}_{i},\,M_{i},\,B_{ij},\,R_{i}\}\) Finally, the user \(U_{i}\) with the smart card sends the login request \({\{}\textit{ID}_{i},\,M_{i},\,B_{ij},R_{i}{\}}\) to the service server \(SS_{j}\).

2.4 Verification phase

V1.:

Upon receiving the login request \(\{\textit{ID}_{i},\,M_{i},\,B_{ij},\,R_{i}\}\), the service server \(SS_{j}\) checks if \({ ID}_{i}\) is valid. If it is not valid, terminate this session; otherwise, the corresponding registration time \(T_{i}\)can be obtained from the corresponding entry of the registration table.

V2.:

After obtaining the registration time \(T_{i}\), the service server \(\textit{SS}_{j}\) computes \(\textit{QID}_{i} = H(\textit{ID}_{i})~\hbox {and}\,d_{ij} = h(\textit{ID}_{i}\vert \vert \textit{SID}_{j}\vert \vert M_{i}\vert \vert R_{i})\). Next, the service server \(SS_{j}\) checks if the following equation can hold:

$$\begin{aligned} \hat{e}<\!\!B_{ij} ,P\!>=\hat{e}<\!\!M_i +d_{ij}\cdot \textit{QID}_i,\,T_i \cdot Pub_{RS}\!\!> \end{aligned}$$
(2)

If it holds, the service server \(SS_{j}\) accepts the login request; otherwise, terminate this session.

V3.:

\(SS_{j} \quad \rightarrow \quad U_{i}: (Auth_{ji}, \,K_{ji},\, R_{j})\) Then the service server \(SS_{j}\) generates a random point \(R_{j}= r_{j}\cdot P\), the temporary key \(TK_{ji}=r_{j}\cdot R_{i}\), the shared secret key \(K_{ji} = s_{j} \cdot R_{i}\) and \(Auth_{ji} = h(\textit{ID}_{i}\vert \vert K_{ji}\vert \vert R_{j})\). Next, the service server \(SS_{j}\) sends (\(Auth_{ji}\), \(K_{ji}\), \(R_{j})\) to the user \(U_{i}\).

V4.:

\(U_{i} \quad \rightarrow \,SS_{j} : Auth_{ij}\) After receiving the responses (\(Auth_{ji}, \,K_{ji},\, R_{j})\), the user \(U_{i}\) computes \(Pub_j =h( {\textit{SID}_j \vert \vert W_j})\cdot Pub_{RS} +W_j\) based on SCPK as the public key of the service server \(SS_{j}\). Then the temporary key \(TK_{ij} = r_{i}\cdot R_{j}\) and the shared secret key \(K_{ij}\) = \(r_{i}\cdot Pub_{j}\) are also computed by the user \(U_{i}\). Next the user \(U_{i}\) checks if the computed \(h(\textit{ID}_{i}\vert \vert K_{ij}\vert \vert R_{j})\) is equal to the received \(Auth_{ji}\). If they are equal, the user \(U_{i}\) computes \(Auth_{ij}~=~h(\textit{ID}_{i}\vert \vert K_{ij}\vert \vert R_{i}\vert \vert R_{j})\) and sends it to the service server \(SS_{j}\).

V5.:

Upon receiving \(Auth_{ij}\), the service server \(SS_{j}\) checks if the computed \(h(\textit{ID}_{i}\vert \vert K_{ji}\vert \vert R_{i}\vert \vert R_{j})\) is equal to the received \(Auth_{ij}\). If they are equal, the two parties can compute the session key \(SK = h(\textit{ID}_{i}\vert \vert T_{ij})\).

2.5 Password change phase

If the user \(U_{i}\) wants to change his/her password, the user \(U_{i}\) has to input his/her identity \(\textit{ID}_{i}\), original password \(PW_{i}\) and new password \(PW_{new}\). Then the following process will be performed by the user \(U_{i}\) and the registration server RS.

P1.:

The user \(U_{i}\) first generates a random number \(n_i \in Z_q^*\) and calculates \(N_{i} = n_{i} \cdot P\)

P2.:

\(U_{i} \quad \rightarrow \) RS: \(\{\textit{ID}_{i},\, \textit{CID}_{i},\,N_{i}\}\) Second, the user U\(_{i}\) computes \(\textit{DID}_{i} =Reg_{IDi}\,\oplus h(PW_{i}\vert \vert b_{i})\cdot Pub_{RS}\hbox { and}\textit{CID}_{i}~=~\textit{DID}_{i}\,\oplus \,n_{i}\,\cdot Pub_{RS}\). Then the user send a password change request \(\{\textit{ID}_{i},\,\textit{CID}_{i},\, N_{i}\}\) to the registration server RS.

P3.:

\(RS\rightarrow \quad U_{i}:\{V_{1}\}\) Upon receiving the password update request \(\{ \textit{ID}_{i},\,\textit{CID}_{i},\,N_{i}\}\), the registration server checks the ID table to verify the validity of the user’s identity. If the validity of the user’s identity is confirmed, the registration server RS computes QID = \(H(\textit{ID}_{i})\) and \(\textit{DID}_{i} = \textit{CID}_{i}\oplus s_{RS}N_{i}\) to obtain \(\textit{DID}_{i}\). Then the registration server RS checks if \(\hat{e}<\!\textit{DID}_{i}, P\!\!> = \hat{e}< \textit{QID}_{i}, \,T_{i} Pu_{RS}\!\!>\). If it holds, the registration server RS sends \(V_{1 }\) to \(U_{i}\) by computing \(V_{1 }=h(i_{i}\vert \vert s_{RS}N_{i})\).

P4.:

\(U_{i} \quad \rightarrow RS:\{V_{2},\, V_{3}\}\) After receiving \(V_{1}\), the user \(U_{i}\) compares \(V_{1 }\)with the computed \(h(\textit{DID}_{i}\vert \vert n_{i}Pub_{RS})\) to confirm the legality of the registration server RS. If the legality of the registration server RSis confirmed, the user \(U_{i}\) sends \(V_{2 }\) and \(V_{3 }\) to RS by computing \(\textit{HPW}_{new}=h(PW_{new}\vert \vert b_{i}), V_{2} = \textit{HPW}_{new}\oplus (n_{i}Pub_{RS})\) and \(V_{3}=h(\textit{DID}_{i}\vert \vert n_{i}Pub_{RS}\vert \vert \textit{HPW}_{new})\).

P5.:

\(RS\rightarrow \quad U_{i}: \{V_{4}\}\) Upon receiving the message (\(V_{2}, \,V_{3})\), the registration server RS computes \(V_{2}\oplus (s_{RS}N_{i})\) to extract \(\textit{HPW}_{new}\). Then the user \(U_{i}\) compares the received \(V_{3}\) with the computed \(h(\textit{DID}_{i}\vert \vert s_{RS}N_{i}\vert \vert \textit{HPW}_{new})\). If they are equal, the legality of the user \(U_{i}\)is confirmed. Finally, the registration server \(Reg_{ID_i}^{new} = \textit{DID}_{i}\oplus (s_{RS}\textit{HPW}_{new})\) and sends \(V_{4}\) to the user \(U_{i}\) by computing \(V_{4} = Reg_{\textit{ID}_i }^{new} \oplus (s_{RS}N_{i})\).

P6.:

After receiving \(V_{4}\), the user \(U_{i}\) computes \(V_{4}\oplus (n_{i}Pub_{RS})\) to extract \(Reg_{\textit{ID}_i }^{new}\). Finally, the smart card of the user \(U_{i}\) replaces the original \(Reg_{\textit{ID}i}\) with \(Reg_{\textit{ID}_i}^{new}\).

3 Cryptanalysis of Liao et al.’s protocol

In this section, we will show that Liao et al’s protocol is vulnerable to the trace attack and spoofing server attack. According to Liao et al.’s scheme mentioned above, they claimed that their scheme can resist to a variety of attacks, save the computation cost and be applied well to the user with mobile devices. However, Liao et al.’s scheme causes some weaknesses in the following discussion.

To evaluate the security of smart card-based user authentication scheme, we first define the threat model which an attacker may have the following capability [31]: an attacker has total control over the communication channel between the mobile user and the remote server. That is the attacker may intercept, insert, delete or modify any message in the channel.

3.1 Trace attack

In the login phase of Liao et al.’s protocol, the user \(U_{i}\) sends the login messages containing the user’s identity ID \(_{i}\) to service server SS \(_{j }\) without any protection. Since the user’s identity ID \(_{i}\) is sent over an open communication channel, an attacker may intercept the message using the assumed capability. With the user’s identity ID \(_{i}\), an attacker can trace it to know what kind of services the user accesses, how long the user logins into the system. Since the service server may have the system log recording what the user did, the user’s privacy may be leaked. Furthermore, an attacker may trace the user’s location according to the user’s IP address. The trace attack seriously invades the user’s privacy and can be utilized to commit real crimes such as kidnappings.

3.2 A burden to update ID table

To authenticate newly added users, the entries \(\{\textit{ID}_{i},\,T_{i}\}\) added to the ID table should be sent to all the service servers periodically over a secure channel. However, if a new user want to access the service, the update may not be completed, thus the authentication of the new user will fail. Besides, every time the update of the ID table needs to build secure channels between the services servers and the registration server, it is an inefficient and inconvenient way to maintain a verification mechanism.

3.3 Lack of a pre-authentication in the smart card

In login phase, when user inputs his/her identity ID \(_{i}\) and password PW \(_{i}\) into the smart card, there is no verification of identity ID \(_{i}\) and password PW \(_{i}\). The smart card will submit the login request to the service server. However, the login message may be false because of an unexisting identity, an incorrect password or both. This will increase trivial burdens on the service servers having to verify the certainly failed login messages. Furthermore, it may be utilized by an attacker to launch a DoS attack.

4 The proposed protocol

In this section, we propose an improved efficient and secure protocol to avoid the security vulnerabilities and inefficiencies of Liao et al.’s protocol. Also there are three entities in our protocol, i.e., the user (\(U_{i})\), the service provider server (SS \(_{j})\) and the register server (RS). RS chooses the master secret key \(s_{RS}\in Z_{q}^{*}\) and keeps it as the system private key and computes Pub \(_{RS}=s_{RS}\in P \)as the system public key, where \(P\) is a generator of the group \(G_{1}\). Subsequently, RS generates a random value \(T\) as a registration token. Next, two hash functions \(H(\cdot )\) and \(h(\cdot )\) are selected by the registration server RS. The public parameters and functions, Params = \(\{ \hat{e},\,G_{1},\, G_{2},\, q, \,P,\, T, Pub_{RS},\, H(\cdot ),\,h(\cdot )\}\), are published. The proposed protocol also has five phases. Figure 2 illustrates detailed steps of the login phase and the verification phase.

We first depicted the conceptual architecture implemented in the proposed protocol. The architecture is illustrated as Fig. 1.

Fig. 1
figure 1

The login and verification of the proposed protocol

The smart phone is equipped with a micro SD card which is issued by the registration server. The secret parameters are burned into the micro SD card and will be automatically cleared if the card is removed from the smart phone. The details of our protocol are as the following.

4.1 Server registration phase

For each service provider server \(SS_{j}\) joined in the multi-server environment, the service provider server \(SS_{j}\) first generates a random value \(v_{j}\in Z_{q}^{*}\). Then the service provider server \(SS_{j}\) computes \(V_{j}=v_{j}\cdot P\) and submits \(V_{j}\) along with the identity \(SID_{j}\) to the registration server RS. Next, the registration server RS generates a random value \(w_{j}\in Z_{q}^{*}\) and performs the following computations

$$\begin{aligned} W_j&= V_j +w_j \cdot P \\ \hat{S}_j&= (h({\textit{SID}_j \vert \vert W_j })\cdot s_{RS} +w_j)\hbox {mod} q \end{aligned}$$

After that, the registration token \(T, \check{s}_{j}\)and \(W_{j}\) is issued to the service server \(SS_{j}\) by the registration server RS. Finally, the private key \(s_{j} = (\check{s}_{j}+v_{j})\) mod \(q\) is computed by the service server \(SS_{j}\), and the service server \(SS_{j}\) checks the validity of the received values by computing the following equation

$$\begin{aligned} Pub_j =s_j \cdot P=h( {\textit{SID}_j \vert \vert W_j})\cdot Pub_{RS} +W_j \end{aligned}$$
(3)

Now the service server has his own private key \(s_{j}\), public key \(Pub_{j}\) and the registration token \(H(T)\) after the service registration phase.

4.2 User registration phase

If the user \(U_{i}\) wants to access the services provided by the multi-server system, he/she has to submit the related information to register the registration server RS. Next, the registration server RS issues the smart card containing some secret information to the user \(U_{i}\) over a secure channel. The process of user registration phase is depicted as follows.

U1.:

\(U_{i} \quad \rightarrow RS: \{H\!(\textit{ID}_{i}),\,\textit{HPW}_{i}\}\) The user \(U_{i}\) chooses a password \(PW_{i}\) and a random value \(b_{i}\in Z_{q}^{*}\). Next the user \(U_{i }\) uses the password salting mechanism to calculate \(\textit{HPW}_{i}=h(\textit{PW}_{i}\vert \vert b_{i})\cdot P\). Then the user \(U_{i}\) sends \(\{H(\textit{ID}_{i}),\, \textit{HPW}_{i}\}\) to the registration server RS.

U2.:

\(RS\rightarrow \quad U_{i}\): the smart card containing \({\{}Auth_{i}, \,T\cdot H(\textit{ID}_{i}),\, Reg_{\textit{ID}i}, \, Pub_{RS},h(\cdot ), H(\cdot ){\}}\) After receiving \(\{H(\textit{ID}_{i}), \textit{HPW}_{i}\}\), the registration server RS checks if \(H(\textit{ID}_{i})\) has already existed in the database. If it is not registered, the registration server RS calculates \(\textit{DID}_{i}=s_{RS}H(\textit{ID}_{i})\) and \(Reg_{IDi}= \textit{DID}_{i}\oplus s_{RS} \textit{HPW}_{i}\) and \(Auth_{i}= T\cdot H(\textit{ID}_{i})\). Finally, the registration server RS issues the smart card containing \(\{ Auth_{i},\,Reg_{\textit{ID}i},\,Pub_{\textit{RS}}, \,H(\cdot ), h(\cdot )\}\) to the user \(U_{i}\) over a secure channel. At the same time, the registration server RS maintains the database which records \(H(\textit{ID}_{i})\).

U3.:

Upon receiving the smart card containing\({\{}Auth_{i},\, Reg_{\textit{ID}\!i},\,Pub_{RS},\, H(\cdot ),h(\cdot ){\}}\), the user \(U_{i}\) stores them with \(b_{i }\) and \(\textit{CID}_{i}=h(\textit{ID}_{i})\oplus h(PW_{i}\vert \vert b_{i})\) in the smart card.

4.3 Login phase

After completing the registration phase, the user \(U_{i}\) can use the smart card issued by the registration server RS to login to the service server \(SS_{j}\). The detailed processes of login and verification are shown in Fig. 2 and are depicted as follows.

L1.:

\(U_{i}\rightarrow \) the smart card: \(\{\textit{ID}_{i},\,PW_{i}\}\) The user \(U_{i}\) inserts the smart card into the card reader and then enters his/her identity \(\textit{ID}_{i}\) and password \(PW_{i}\). The smart card computes s\(\textit{CID}_{i}^{*}=h(\textit{ID}_{i})\oplus h(PW_{i}\vert \vert b_{i})\) and checks if \(\textit{CID}_{i}^{*} = \textit{CID}_{i}\). If they are not equal, terminate this session.

L2.:

If CID \(_{i}^{*}\)= CID \(_{i}\), the smart card generates two random numbers \(x \) and \(r_{i}\ni Z_{q}^{*}\) and calculates \(R_{i}=r_{i}\cdot P\). The smart card then computes \(\textit{DID}_{i} = Reg_{IDi}\oplus h(PW_{i}\vert \vert b_{i})\cdot Pub_{RS},\, \textit{QID}_{i}=H(\textit{ID}_{i}),\,C_{m} = x \cdot H(\textit{ID}_{i}),\,xAuth_{i} = x\cdot Auth_{i},\, Mi = xr_{i}\cdot QID_{i},\, d_{ij}=h(xH(\textit{ID}_{i})\vert \vert SID_{j}\vert \vert M_{i}\vert \vert R_{i})\) and \(B_{ij} = x(r_{i}+d_{ij})\cdot \textit{DID}_{i}\).

L2.:

\(U_{i}\rightarrow SS_{j}: \{xAuth_{i},\,C_{m},\,M_{i},\,B_{ij},\,R_{i}\}\) Finally, the user \(U_{i}\) with the smart card sends the login request \({\{}xAuth_{i},\, C_{m},M_{i},\,B_{ij}, R_{i}{\}}\) to the service server \(SS_{j}\).

Fig. 2
figure 2

The conceptual architecture of the proposed protocol

4.4 Verification phase

V1.:

Upon receiving the login request \(\{ xAuth_{i},\, C_{m},\, M_{i},\,B_{ij}, R_{i}\}\), the service server \(SS_{j}\) computes \( xAuth_{i}^{*} = TC_{m}\) to check if \( xAuth_{i}^{*} = xAuth_{i}\). If it is not valid, terminate this session.

V2.:

If \(xAuth_{i}^{*} = xAuth_{i}\), then the service server \(SS_{j}\) computes \(d_{ij}=h(C_{m}\vert \vert S\textit{ID}_{j}\vert \vert M_{i}\vert \vert R_{i})\). Next, the service server \(SS_{j}\) checks if the following equation can hold:

$$\begin{aligned} \hat{e}<\!\!B_{ij} ,P\!>=\hat{e}<\!M_i +xd_{ij}\cdot \textit{QID}_i ,pub_{RS} \!\!> \end{aligned}$$
(4)

If it holds, the service server \(SS_{j}\) accepts the login request; otherwise, terminate this session.

V3.:

\(SS_{j} \quad \rightarrow \quad U_{i}: \{Auth_{ji},\, K_{ji},\, R_{j}\}\) Then the service server SS \(_{j}\) generates a random point \(R_{j }\)= \(r_{j}P\), the temporary key TK \(_{ji }=r_{j}R_{i}\), the shared secret key \(K_{ji}=s_{j}R_{i }\)and Auth \(_{ji }= h(C_{m}\vert \vert K_{ji}\vert \vert R_{j})\). Next, the service server SS \(_{j}\) sends (Auth \(_{ji}\), \(K_{ji}\),\( R_{j})\) to the user \(U_{i}\).

V4.:

\(U_{i} \quad \rightarrow SS_{j} : Auth_{ij}\) After receiving the responses (Auth \(_{ji}\), \(K_{ji}\),\( R_{j})\), the user \(U_{i}\) computes Pub \(_{j}=h\)(SID \(_{j}\vert \vert W_{j})\) Pub \(_{RS}+W_{j}\) based on SCPK as the public key of the service server SS \(_{j}\). Then the temporary key TK \(_{ij }=r_{i}R_{j}\) and the shared secret key \(K_{ij}\) = \(r_{i}\) Pub \(_{j}\) are also computed by the user \(U_{i}\). Next the user \(U_{i}\) checks if the computed \(h\)(xH(ID \(_{i})\vert \vert K_{ij}\vert \vert R_{j})\) is equal to the received Auth \(_{ji}\). If they are equal, the user \(U_{i}\) computes Auth \(_{ij }= h\)(ID \(_{i}\vert \vert K_{ij}\vert \vert R_{i}\vert \vert R_{j})\) and sends it to the service server SS \(_{j}\).

V5.:

Upon receiving Auth \(_{ij}\), the service server SS \(_{j}\) checks if the computed \(h(\textit{ID}_{i}\vert \vert K_{ji}\vert \vert R_{i}\vert \vert R_{j})\) is equal to the received \(Auth_{ij}\). If they are equal, the two parties can compute the session key \(SK = h( xH(\textit{ID}_{i})\vert \vert T_{ij})\).

4.5 Password change phase

If the user \(U_{i}\) wants to change his/her password, the user \(U_{i}\) has to input his/her identity ID \(_{i}\), original password PW \(_{i}\) and new password PW \(_{new}\). Then the following process will be performed by the \(U_{i}\) and the registration server RS.

P1.:

\( U_{i }\rightarrow \) the smart card: \(\{\textit{ID}_{i},\,PW_{i}\}\) The user \(U_{i}\) inserts the smart card into the card reader and then enters his/her identity ID \(_{i}\) and password PW \(_{i}\). The smart card computes \(\textit{CID}_{i}^{*}=h(\textit{ID}_{i})\oplus h(PW_{i}\vert \vert b_{i})\) and checks if C\(\textit{ID}_{i}^{*} = \textit{CID}_{i}\). If they are not equal, terminate this session.

P2.:

If they are equal, the smart card generates a random number \(n_{i}\in Z_{q}^{*}\) and calculates \(N_{i }=n_{i}\cdot P\).

P2.:

\(U_{i} \quad \rightarrow RS:\{H(\textit{ID}_{i}),\,\textit{NID}_{i},\,N_{i}\}\) Second, the user \(U_{i}\) computes \(\textit{DID}_{i} = Reg_{\textit{ID}i}\oplus h(PW_{i}\vert \vert b_{i}) Pub_{RS}\hbox { and } \textit{NID}_{i}= \textit{DID}_{i}\oplus n_{i} Pub_{RS}\). Then the user send a password change request \(\{H(\textit{ID}_{i}),\,\textit{NID}_{i},\, N_{i}\}\) to the registration server RS.

P3.:

RS \(\rightarrow \quad U_{i}: \{V_{1}\}\) Upon receiving the password change request \(\{H(\textit{ID}_{i}),\, \textit{NID}_{i},\, N_{i}\}\), the registration server RS checks the database to verify the validity of the user’s identity \(H\)(ID \(_{i})\). If the validity of the user’s identity is confirmed, the registration server RS computes \( \textit{QID}_{i} = H(\textit{ID}_{i})\) and \(\textit{DID}_{i} = \textit{NID}_{i}\oplus s_{RS}N_{i}\) to obtain DID \(_{i}\). Then the registration server RS checks if \(\hat{e}< \!\textit{DID}_{i},\, P\!> = \hat{e} < \textit{QID}_{i},\, Pub_{RS}\!>\). If it holds, the registration server RS sends \(V_{1}\) to \(U_{i}\) by computing \(V_{1 }=h(\textit{DID}_{i}\vert \vert s_{RS}N_{i})\).

P4.:

\(U_{i} \quad \rightarrow RS: \{V_{2},\,V_{3}\}\) After receiving \(V_{1}\), the user \(U_{i}\)compares \(V_{1}\)with the computed \(h(\textit{DID}_{i}\vert \vert n_{i} Pub_{RS})\) to confirm the legality of the registration server RS. If the legality of the registration server RS is confirmed, the user \(U_{i}\)sends \(V_{2}\)and \(V_{3}\)to RS by computing \(\textit{HPW}_{new}=h(PW_{new}\vert \vert b_{i}),\, V_{2} = \textit{HPW}_{new}\oplus (n_{i} Pub_{RS})\) and \(V_{3}=h(\textit{DID}_{i}\vert \vert n_{i} Pub_{RS}\vert \vert \textit{HPW}_{new})\).

P5.:

RS \(\rightarrow \quad U_{i}: \{V_{4}\}\) Upon receiving the message (\(V_{2}\), \(V_{3})\), the registration server RS computes \(V_{2}\oplus (s_{RS}N_{i})_{ }\)to extract HPW \(_{new}\). Then the user \(U_{i}\) compares the received \(V_{3}\) with the computed \(h(\textit{DID}_{i}\vert \vert s_{RS}N_{i}\vert \vert \textit{HPW}_{new})\). If they are equal, the legality of the user \(U_{i }\)is confirmed. Finally, the registration server \(Reg_{ID_i}^{new} = \textit{DID}_{i}\oplus (s_{RS} \textit{HPW}_{new})\) and sends \(V_{4}\) to the user \(U_{i}\) by computing \(V_{4} = Reg_{\textit{ID}_i }^{new} \oplus (s_{RS}N_{i})\).

P6.:

After receiving \(V_{4}\), the user \(U_{i}\) computes \(V_{4}\oplus (n_{i} Pub_{RS})\) to extract \(Reg_{ID_i}^{new} \, \hbox {and}\,\textit{CID}_{new} = h( ID_{i})\oplus h( PW_{new}\vert \vert b_{i})\). Finally, the smart card of the user \(U_{i}\) replaces the original \( Reg_{\textit{IDi}}\) and CID \(_{i}\) with \(Reg_{\textit{ID}_i }^{new} \) and CID \(_{new}\), respectively.

5 Security analysis

The proposed protocol is based on Liao et al.’s protocol, however, we add some countermeasures to resist the described attack and improve the efficiency and security of the original protocol. In the following paragraphs, we will explain how the weaknesses are eliminated.

5.1 Resist to the trace attack

The improved protocol no longer sends the identity directly and clearly. Nevertheless, the identity is mingled with a secret and then is encrypted by the service server’s public key. For example, the login message \(C_{m} = \{ x\cdot H( \textit{ID}_{i})\oplus H(T)\}\) is sent to the service server \(SS_{j}\). Therefore, each time the service server will receive the different login messages of the same user Ui. Moreover, only the service server corresponding to the public key being used to encrypt can decrypt the login messages using the corresponding private key.

5.2 Release from updating ID table

Instead of using ID table to authenticate the registered user, the registration server issues a smart card containing a specific token \(H(T)\) to the registered user. Also the service servers registered the registration server will have the same tokens. Therefore, the service server can use the token to identify if the user can access the system. If the token is stolen by an attacker ID \(_{e}\), he/she still cannot forge a login request to pass the authentication. Since he/she has no knowledge of the system secret key \(s_{RS}\), he/she cannot compute \(\textit{DID}_{e}=s_{RS}\cdot H(\textit{ID}_{e})\). Hence, he/she cannot compute a correct \(B_{ej}\) to pass the authentication.

5.3 Pre-authentication in the smart card

In our improved protocol, the smart card issued by the registration server contains the authentication code Auth \(_{i }\)which is composed of registered user’s identity and password. Since there is no way to get any information of the user’s identity and password, an attacker has to guess these two unknown values simultaneously. Therefore, it is infeasible to launch an off-line password attack for an attacker. Having an authentication code in the smart card, the user has to pass the pre-authentication before sending a login request to the service server.

6 Performance analysis of proposed scheme

Since the mobile devices have the limited computing capability and energy resources, the proposed protocol should be taken wireless communication, computation cost and communication cost into consideration. Moreover, evaluation focuses on the client rather than the server, since the server is regarded as a powerful device. For convenience to evaluate the computational cost, we define computation notations as follows.

  • \( TG_{e}\): Time to execute a bilinear map operation, \(\hat{e} :G_{1}\!\times G_{1} \rightarrow \!G_{2}\).

  • \( TG_{mul}\): Time to execute point scalar multiplication on the group\( \,G_{1}\).

  • \( TG_{H}\): Time to execute a map-to-point hash function \(H(\cdot )\).

  • \( TG_{add}\): Time to execute point addition on the group \(G1\).

  • \(T_{h}\): Time to execute a one-way hash function \(h(\cdot )\).

Since the time of executing the XOR operation and the modular multiplication operation is relatively less, their computation cost is neglected here. Tables 2 and 3 list the experimental data for related pairing-based operations. The computation cost on the user side is presented as Table 2. In [32], the processor on the user side (i.e., smart card) has the maximum clock speeds of 36 MHz and equips a five-stage pipeline 2 KB instruction cache, 256 KB flash memory and 16 KB RAM.

Table 2 The computation cost of the user’s smart card
Table 3 The computation cost of the server

The computation cost on the server side is presented as Table 3. The processor of the server has the maximum clock speed of 3 GHz with 512 MB RAM. The operating system runs Windows XP.

We focus on the computation cost of the login and authentication phase. The proposed protocol needs \(7TG_{mul} + TG_{H} + TG_{add} + 7T_{h}\) online computations on the user side, and requires \(2TG_{e}+ 5TG_{mul} + TG_{add} + 2T_{h}\) computations on the server side. The computation time of the login and authentication phase of the user is 1.027 seconds which is almost close to the time needed by Liao et al.’s protocol. However, the improved protocol can resist to the trace attack which will invade the user’s privacy seriously. Besides, it removes the burden of updating ID tables of the service server. The cryptanalysis of multi-server related protocols is presented as Table 4. The performance analysis in this section is based on software; software approaches could be a good choice since they have low cost and require a short development time. The low values of performance are a forbidden factor for possible software implementation. On the other hand, hardware alternatives could be selected for implementing crypto-processors architectures. Both Application Specific Integrated Circuits (ASICs) and Field Programmable Gate Arrays (FPGAs) can support high data rates, although such designs are more time consuming and expensive compared with the software alternative. The details can be referred in [33].

Table 4 Cryptanalysis of multi-server related protocols

7 Conclusion

In recent years, many studies try to propose a secure and efficient remote user authentication scheme. Nevertheless, most of the proposed schemes were found to be insecure, and the improved scheme was proposed later. After studying the recent improved schemes, we proposed the more secure and efficient scheme in this paper. Our proposed scheme can satisfy all the security features needed for achieving secure password authentication in multi-server environments, as compared with the previously proposed schemes. We present a cryptanalysis of a recently proposed Liao et al.’s scheme and showed that their scheme is vulnerable to the trace attack and inefficient in maintaining an ID table. We have specified and analyzed the proposed anonymous remote user authentication protocol for multi-server architecture using smart cards which is very effective to thwart various attacks. In addition, in comparison with the previously proposed schemes, our improved scheme uses nearly the same operations in its implementation. Security and performance analysis proveS that the proposed scheme is more secure and practical. In the future work, we will implement the proposed protocol using a secure combination of a smart phone and a micro SD card.