# A Novel Multiserver Authentication Protocol with Multifactors for Cloud Service

Authors: Jian Song; Guang-song Li; Bo-ru Xu; Chuan-gui Ma
Journal: Security and Communication Networks
 (2018)

---

## Abstract

Secure and efficient authentication protocols are necessary for cloud service. Multifactor authentication protocols taking advantage of smart card, user’s password, and biometric, are more secure than password-based single-factor authentication protocols which are widely used in practice. However, most of the multiserver authentication protocols may have weak points, such as smart card loss attack, man-in-the-middle attack, anonymity, and high computation cost of authentication center. In order to overcome the above weaknesses, we propose a novel multiserver multifactor authentication protocol based on the Kerberos protocol using the extended Chebyshev chaotic mapping as a cryptographic algorithm. The proposed protocol achieves anonymity without sharing secret keys in advance and needs the user to register with the authentication center only once. Finally, we prove the security of the new protocol with BAN logic and compare it with other multifactor authentication protocols for multiserver environment. The results show that our proposed protocol is more secure and efficient and better for practical application.


---

## Body

## 1. Introduction

With the rapid developing of cloud computing [1, 2], now a variety of cloud servers have stored massive user sensitive data. When users want to access the data, they need to log on to the server through the public channel. What is more, users may have a variety of service requirements and may need to access multiple application servers in a short time. Figure 1 depicts a typical scenario for cloud service. However, in this process, an adversary could intercept, tamper, and forge the information between the user and the server through some technical means. When users access some privacy services, they do not even want other people to know their identity. In order to provide secure and efficient services for a valid user, authentication protocols were proposed [3].Figure 1
A typical scenario for cloud service.In practice, there are three basic methods to verify the identity of users:(1) what the user knows, such as user password; (2) what the user has, such as smart card; (3) the user’s unique biological information, such as fingerprint and iris. As single-factor authentication protocols are based on password which are easy to operate, scalable, and cheap, most people prefer to use this authentication scheme. Therefore, the most commonly used authentication scheme in the current network is still single-factor authentication protocols based on password [4]. However the single-factor authentication protocol has the following inherent defects: (1) the limitation of human memory capacity leads to low entropy of password selection; (2) the development of password cracking hardware and algorithm makes the efficiency of offline dictionary attack greatly improved. Moreover in a single-factor authentication protocol the server needs to store the user’s identity and the corresponding password information, even if the password information is hashed; once the server data is stolen, the user will face serious security threat [5].To solve the problem, Chang et al. [6] firstly introduced the smart card as another factor besides password into authentication schemes, which contributes to the two-factor authentication scheme. In such scheme, the users are required to know not only the correct password but also the corresponding smart card; then he/she can access to resource by interacting with the server. However, passwords might be forgotten, and smart cards might be lost or stolen. In contrast, biometric methods, such as fingerprints or iris scans, have no such drawbacks. Therefore, these years, many multifactor authentication protocols using biometric characteristic as an additional factor were proposed [7–13]. Many of these protocols are only for the single server environment. That is, when users want to access multiple servers, they have to register many times and maintain a lot of username/password pairs with the corresponding smart card, which is inefficient if each login should be unique for each server or insecure if the same login is used for multiple servers.In 2016, Amin et al. proposed a new multifactor authentication scheme for multiserver environment and claimed that it was secure for all known attacks [14]. However, in 2017, Jiang et al. found that Amin et al.’s scheme has the following security issues. (1) If the smart card was stolen, the attacker could recover the user’s ID and password. (2) If the temporary parameters of either of the two parties were leaked, the attacker could obtain the session key [15]. Then, Jiang et al. improved Amin et al.’s scheme with Rabin cryptosystem, fuzzy validation, and timestamp and verified the security of the improved scheme with ProVerif. In article [15], Jiang et al. also pointed out that Wu et al.’s scheme [16] is vulnerable to smart card loss attacks. Nevertheless, we found that, in Jiang et al.’s scheme [15], the user’s identity is hidden in a message only with the timestamp as variable. If the user’s timestamp is the same as the adversary’s, then the adversary could obtain the user’s real identity by simple XOR operations. So the scheme does not achieve anonymity. Recently, several multifactor authentication schemes have been proposed to the study of authentication and key agreement in the multiserver environment [16–19]. However, most of these schemes’ computational cost is high due to the modulus exponentiation operation, the point addition operation of elliptic curve, and so on. Thus, those schemes may not be suitable for some cloud scenarios, in which the user may access multiple servers in a short time, the user terminal only has limited computing power, the server needs to handle a large number of requests at the same time, and so on.Though multifactor authentication protocols are widely studied by many scholars, few of them are specifically for cloud service. We have taken into account the needs of cloud services and applied new technologies to design multifactor authentication for the above environment. In order to design more efficient and secure authentication protocols, the extended Chebyshev chaotic mapping [20–22] is introduced in this paper. The computational cost of extended Chebyshev polynomials is lower, compared to the traditional modular exponentiation operation and the point addition operation of elliptic curve [20–24]. Moreover, with the idea of Kerberos protocol, we propose a novel multifactor authentication protocol for the multiserver environment. In our scheme, the frequency of user accessing the authentication center is reduced, which greatly relieves the burden of the authentication center. In addition, the new protocol accomplishes security and usability features necessary for all the participants, while maintaining high efficiency.The remainder of this paper is organized as follows. The preliminaries of enhanced Chebyshev chaotic maps and fuzzy extraction are given in Section2. In Section 3, we propose a novel multifactor authentication protocol for multiserver environment. Section 4 and Section 5 present security and efficiency analyses of the new protocol. Section 6 concludes the paper.


## 2. Preliminaries

### 2.1. Enhanced Chebyshev Chaotic Maps [20–22]

The enhanced Chebyshev polynomialTn(x) is a polynomial in x of degree n and is defined by the following relation:(1)Tnx≡1,n=0xmodp,n=12x·Tn-1x-Tn-2xmodp,n≥2where x∈(-∞,+∞) and p is a large prime number.The enhanced Chebyshev polynomial satisfies the semigroup property and satisfies(2)TrTsx=Trsx=TsTrxfor s,r∈Z+.


### 2.2. Difficulty Assumptions

Enhanced Chebyshev polynomials are associated with three hard problems, which are the extended chaotic-map-based discrete logarithm problem (DLP), the computational Diffie–Hellman problem (CDHP), and the decisional Diffie–Hellman problem (DDHP), described as follows.( 1 ) Extended Chaotic-Map-Based DLP: given x,y,T(·) and p, where p is a large prime number, finding the integer r satisfying(3)y=Trxmodpis computationally infeasible.( 2 ) Extended Chaotic-Map-Based CDHP: given Tr(x), Ts(x), x, T(·), and p, where r,s≥2, x∈(-∞,+∞) and p is a large prime number, calculating (4)Trsx≡TrTsx≡TsTrxmodpis computationally infeasible.( 3 ) Extended Chaotic-Map-Based DDHP: given Tr(x), Ts(x), Tz(x), x, T(·), and p, p is a large prime number, deciding whether(5)Trsx≡Tzxmodpholds or is not computationally infeasible.


### 2.3. Fuzzy Extractor

Traditional hash functions return different outputs if their inputs are not completely the same. Thus we need some other technology to extract biometrics. According to [25], the biometrics of all persons can be retrieved as nearly uniform random bit strings R by an auxiliary string P from biometric input B with a fuzzy extractor. The extractor can recover R with the auxiliary string P even if the biometric input is B′, as long as it is very close to the original B. Thus,R can be utilized as a key stand for biometrics in a security application. Fuzzy extractor consists of two procedures (Gen, Rep).( 1 ) G e n ( B ) → { R , P }Gen is a probabilistic algorithm, which takes a biometric input B as input and outputs a random string R with length l and a public stringP.( 2 ) R e p ( B ′ , P ) → RRep is a deterministic reproduction procedure which is able to recover R from a slightly different biometric B′ and the auxiliary parameter P. That is, Rep(B′,P)=R for all B′ satisfying dis(B,B′)≤ε, where ε is an error-tolerance.


### 2.4. Adversary’s Capability

In this paper, we assume the following about a probabilistic, polynomial-time adversary to properly capture the security requirements of a multifactor biometric authentication scheme that uses smart cards during the registration phase, authentication phase, and password change phase.( 1 ) The adversary is able to have complete control over all message exchanges between the protocol participants. That is, the adversary can intercept, insert, modify, delete, and eavesdrop on messages exchanged among the two parties at will.( 2 ) The adversary can extract sensitive information from the smart card of a user through a power analysis attack.


### 2.5. Notations

Table1 lists the notation that is used throughout this paper.Table 1
Notations.
Notation Description I D X The identity of the entityX s k X The secret key of the entityX A C Authentication center S C Smart card s a / s b The master key of authentication center k 0 / T k 0 ( x ) The private/public key of authentication center k j / T k j ( x ) The private/public key of severSj P W i The password of userUi F P i The fingerprint information of userUi T i m e S e t u p The generation time ofYij l The security length parameter h ( ⋅ ) Cryptographic one-way hash function, satisfyingh:0,1∗→0,1l ∥ String concatenation ⊕ Exclusive-or operation


## 2.1. Enhanced Chebyshev Chaotic Maps [20–22]

The enhanced Chebyshev polynomialTn(x) is a polynomial in x of degree n and is defined by the following relation:(1)Tnx≡1,n=0xmodp,n=12x·Tn-1x-Tn-2xmodp,n≥2where x∈(-∞,+∞) and p is a large prime number.The enhanced Chebyshev polynomial satisfies the semigroup property and satisfies(2)TrTsx=Trsx=TsTrxfor s,r∈Z+.


## 2.2. Difficulty Assumptions

Enhanced Chebyshev polynomials are associated with three hard problems, which are the extended chaotic-map-based discrete logarithm problem (DLP), the computational Diffie–Hellman problem (CDHP), and the decisional Diffie–Hellman problem (DDHP), described as follows.( 1 ) Extended Chaotic-Map-Based DLP: given x,y,T(·) and p, where p is a large prime number, finding the integer r satisfying(3)y=Trxmodpis computationally infeasible.( 2 ) Extended Chaotic-Map-Based CDHP: given Tr(x), Ts(x), x, T(·), and p, where r,s≥2, x∈(-∞,+∞) and p is a large prime number, calculating (4)Trsx≡TrTsx≡TsTrxmodpis computationally infeasible.( 3 ) Extended Chaotic-Map-Based DDHP: given Tr(x), Ts(x), Tz(x), x, T(·), and p, p is a large prime number, deciding whether(5)Trsx≡Tzxmodpholds or is not computationally infeasible.


## 2.3. Fuzzy Extractor

Traditional hash functions return different outputs if their inputs are not completely the same. Thus we need some other technology to extract biometrics. According to [25], the biometrics of all persons can be retrieved as nearly uniform random bit strings R by an auxiliary string P from biometric input B with a fuzzy extractor. The extractor can recover R with the auxiliary string P even if the biometric input is B′, as long as it is very close to the original B. Thus,R can be utilized as a key stand for biometrics in a security application. Fuzzy extractor consists of two procedures (Gen, Rep).( 1 ) G e n ( B ) → { R , P }Gen is a probabilistic algorithm, which takes a biometric input B as input and outputs a random string R with length l and a public stringP.( 2 ) R e p ( B ′ , P ) → RRep is a deterministic reproduction procedure which is able to recover R from a slightly different biometric B′ and the auxiliary parameter P. That is, Rep(B′,P)=R for all B′ satisfying dis(B,B′)≤ε, where ε is an error-tolerance.


## 2.4. Adversary’s Capability

In this paper, we assume the following about a probabilistic, polynomial-time adversary to properly capture the security requirements of a multifactor biometric authentication scheme that uses smart cards during the registration phase, authentication phase, and password change phase.( 1 ) The adversary is able to have complete control over all message exchanges between the protocol participants. That is, the adversary can intercept, insert, modify, delete, and eavesdrop on messages exchanged among the two parties at will.( 2 ) The adversary can extract sensitive information from the smart card of a user through a power analysis attack.


## 2.5. Notations

Table1 lists the notation that is used throughout this paper.Table 1
Notations.
Notation Description I D X The identity of the entityX s k X The secret key of the entityX A C Authentication center S C Smart card s a / s b The master key of authentication center k 0 / T k 0 ( x ) The private/public key of authentication center k j / T k j ( x ) The private/public key of severSj P W i The password of userUi F P i The fingerprint information of userUi T i m e S e t u p The generation time ofYij l The security length parameter h ( ⋅ ) Cryptographic one-way hash function, satisfyingh:0,1∗→0,1l ∥ String concatenation ⊕ Exclusive-or operation


## 3. Our Proposed Authentication Protocol

For cloud service, we proposed a multifactor authentication protocol in which there are three kinds of entities: the user, the server, and the authentication center (the trusted third party), as described in Figure2.Figure 2
Network model of our protocol.The characteristics of each participant are different. In our scheme, the actual needs of all the participating entities are considered under the guarantee of security.(1) For user, the user’s anonymity is first achieved. Secondly, in multiserver environment users can access all servers only by registering one time. At the same time, considering the limitation of the user’s computing power, the user’s computational cost is low in our scheme. In addition, the user can change his/her password offline. (2) For the authentication center, taking into account the fact that authentication center needs to participate in each user’s access in existing authentication protocols for multiserver environment, our scheme designs a ticket. When the ticket is not expired, there is no need for authentication center to participate in the authentication process, which greatly reduces the burden of the authentication center. (3) For the server, in our scheme the authentication center and the server do not need to share a key in advance. Moreover, considering the different actual requirements of each application server, the expiry time of the ticket in our scheme is determined by the server.Our scheme contains four phases, namely, system setup phase (Figure3), user registration phase (Figure 4), authentication phase (Figure 5), and password change phase (Figure 6).Figure 3
System setup phase.Figure 4
User registration phase.Figure 5
Authentication phase.Figure 6
Password change phase.


### 3.1. System Setup

A C selects and computes the system parameters in offline mode. And sever Sj registers with AC through a secure channel.Step 1.
A C chooses master secret keys sa and sb. Then AC generates a random number x and a large prime number p and chooses a random number k0 as private key. Next, AC computes Tk0(x) as public key and makes the parameters (x,Tk0(x),p) known to the public.Step 2.
SeverSj selects an identity IDj and sends it to AC through secure channel. AC checks whether IDj exists in the database. If it does, AC indicates Sj to select a new identity; otherwise, AC compute skj=h(IDj∥sb) and send it to Sj through a secure channel.Step 3.
SeverSj chooses a random number kj as private key and computes Tkj(x) as public key. Finally, Sj stores (skj,kj) in its memory and makes Tkj(x) known to the public.


### 3.2. User Registration

In this phase,Ui registers with AC through secure channel and gets back a smart card SC.Step 1.
UserUi selects an identity IDi and a password PWi; then Ui inputs fingerprint information FPi through fingerprint extractor. Next, Ui gets a random bit strings Ri and an auxiliary string Pi from biometric input FPi with algorithmGen.Then, Ui chooses a high-entropy random number r and computes Li=h(IDi∥PWi∥Ri∥r) and Mi=h(h(IDi∥PWi∥r)modl)⊕Ri. Finally, Ui sends IDi and Li to AC through a secure channel.Step 2.
After receivingIDi and Li from Ui, AC checks whether IDi exists in the database. If it does, AC indicates Ui to select a new identity; otherwise, AC computes Xi=h(IDi∥sa) and Zi=Xi⊕Li; then AC stores {Zi,h(·),x,p} into SC. Finally, AC sends SC to Ui through a secure channel.Step 3.
After receivingSC from AC, Ui stores {Pi,Mi,r,l,Gen(·),Rep(·,·)} into SC. Finally, SC contains {Zi,Mi,Pi,r,l,Gen(·),Rep(·,·),h(·),x,p}.


### 3.3. Authentication

U i first logins to the SC; then Ui starts a mutual authentication process with AC to get a ticket Yij for accessing sever Sj. Next, Ui implements mutual authentication with Sj by Yij and establishes a session key ksession with Sj, where the ticket Yij has an expiry time which is determined by Sj.Step 1.
U i attaches the smart card SC and enters the identity IDi, password PWi, and fingerprint FPi. Then, SC computes Ri′=Req(FPi′,Pi′) andRi=h(h(IDi′∥PWi′∥r)modl)⊕Mi. The smart card SC rejects Ui’s login request if Ri≠Ri′; otherwise, SC chooses a random number u and computes TUi-SA=Tu(Tk0(x)), NIDij=(IDi∥IDj)·TUi-SA, Li=h(IDi∥PWi∥Ri∥r), Xi=Zi⊕Li, and Aut1=h(IDi∥IDj∥Xi∥TUi-SA∥TimeStamp1). Finally, Ui sends NIDij,Tu(x),Aut1,TimeStamp1 to AC.Step 2.
After receiving the messageNIDij,Tu(x),Aut1,TimeStamp1 from Ui, AC verifies whether TimeStamp1 is valid. If not, AC rejects Ui’s request; otherwise, AC computes TUi-SA′=Tk0(Tu(x)), IDi′∥IDj=NIDij/TUi-SA′, Xi′=h(IDi′∥sa), and h(IDi′∥IDj∥Xi′∥TUi-SA′∥TimeStamp1). Then AC terminates the session, if Aut1≠h(IDi′∥IDj∥Xi′∥TUi-SA′∥TimeStamp1); otherwise, AC computes a ticket Yij=h(IDi′∥h(IDj∥sb)∥TimeSetup), NYij=(Yij∥TimeSetup)⊕h(Xi′), and Aut2=h(IDi′∥IDj∥Xi′∥Yij∥TimeSetup∥TimeStamp2), where TimeSetup is the generation time of Yij. Finally, AC sends NYij,Aut2,TimeStamp2 to Ui.Step 3.
After receiving the messageYij,Aut2,TimeStamp2, Ui verifies whether TimeStamp2 is valid. If not, Ui terminates the session; otherwise, Ui computes Yij′∥TimeSetup′=NYij⊕h(Xi) and h(IDi∥IDj∥Xi∥Yij′∥TimeSetup∥TimeStamp2). Then Ui terminates the session, if Aut2≠h(IDi∥IDj∥Xi∥Yij′∥TimeSetup∥TimeStamp2); otherwise, Ui chooses a random number u2 and then computes TUi-Sj=Tu2(Tkj(x)), NIDij∗=(IDi∥IDj∥TimeSetup)·TUi-Sj, and Aut3=h(IDi∥IDj∥Yij′∥TUi-Sj∥TimeSetup∥TimeStamp3). Finally, Ui sends NIDij∗,Tu2(x),Aut3,TimeStamp3 to Sj.Step 4.
After receiving the messageNIDij∗,Tu2(x),Aut3,TimeStamp3, Sj verifies whether TimeStamp3 is valid. If not, Sj terminates the session; otherwise, Sj computes TUi-Sj′=Tkj(Tu2(x)) and IDi′∥IDj′∥TimeSetup′=NIDij∗/TUi-Sj′. Then Sj verifies whether IDj′=IDj and TimeSetup′ is valid. If not, Sj terminates the session; otherwise, Sj computes Yij′=h(IDi′∥skj∥TimeSetup′) and h(IDi′∥IDj∥Yij∥TUi-Sj′∥TimeSetup′∥TimeStamp3). Then Sj terminates the session, if Aut3≠h(IDi′∥IDj∥Yij∥TUi-Sj′∥TimeSetup′∥TimeStamp3); otherwise, Sj chooses a random number v and then computes ksession=Tv(Tu2(x)) and Aut4=h(IDi′∥IDj∥Yij′∥ksession∥TimeStamp4). Finally, Sj sends Tv(x),Aut4,TimeStamp4 to Ui.Step 5.
After receiving the messageTv(x),Aut4,TimeStamp4, Ui verifies whether TimeStamp4 is valid. If not, Ui terminates the session; otherwise, Ui computes ksession=Tu2(Tv(x)) and h(IDi∥IDj∥Yij∥ksession∥TimeStamp4). Then Ui terminates the session, if Aut4≠h(IDi∥IDj∥Yij∥ksession∥TimeStamp4); otherwise, Ui and Sj complete mutual authentication successfully. At this point, a session key ksession=Tu2·v(x)=Tu2(Tv(x))=Tv(Tu2(x)) has been established among Ui and Sj.After all these steps are completed, ifUi wants to access Sj again, it can be executed directly from Step 3 without AC’s participating, where the ticket Yij must be not out of date.


### 3.4. Password Change

In this phase,Ui only needs to log into SC successfully and then inputs new password PWinew and fingerprint information FPinew, without involvement of AC and Sj.Step 1.
U i inserts the smart card into a card reader and enters the identity IDi, password PWi, and fingerprint FPi.Step 2.
S C computes Ri′=Req(FPi′,Pi′) and Ri=h(h(IDi′∥PWi′∥r)modl)⊕Mi. The smart card SC rejects Ui’s login request if Ri≠Ri′; otherwise, SC indicates Ui to input new password and fingerprint information.Step 3.
U i inputs new password PWinew and fingerprint information FPinew.Step 4.
S C computes Li=h(IDi∥PWi∥Ri∥r), then chooses a random number rnew, and computes Rinew,Pinew←Gen(FPinew), Linew=h(IDi∥PWinew∥Rinew∥rnew), Minew=h(h(IDi∥PWinew∥rnew)modl)⊕Rinew, and Zinew=Zi⊕Li⊕Linew. Finally, SC updates Zi,Mi,Pi,r with Zinew,Minew,Pinew,rnew.


## 3.1. System Setup

A C selects and computes the system parameters in offline mode. And sever Sj registers with AC through a secure channel.Step 1.
A C chooses master secret keys sa and sb. Then AC generates a random number x and a large prime number p and chooses a random number k0 as private key. Next, AC computes Tk0(x) as public key and makes the parameters (x,Tk0(x),p) known to the public.Step 2.
SeverSj selects an identity IDj and sends it to AC through secure channel. AC checks whether IDj exists in the database. If it does, AC indicates Sj to select a new identity; otherwise, AC compute skj=h(IDj∥sb) and send it to Sj through a secure channel.Step 3.
SeverSj chooses a random number kj as private key and computes Tkj(x) as public key. Finally, Sj stores (skj,kj) in its memory and makes Tkj(x) known to the public.


## 3.2. User Registration

In this phase,Ui registers with AC through secure channel and gets back a smart card SC.Step 1.
UserUi selects an identity IDi and a password PWi; then Ui inputs fingerprint information FPi through fingerprint extractor. Next, Ui gets a random bit strings Ri and an auxiliary string Pi from biometric input FPi with algorithmGen.Then, Ui chooses a high-entropy random number r and computes Li=h(IDi∥PWi∥Ri∥r) and Mi=h(h(IDi∥PWi∥r)modl)⊕Ri. Finally, Ui sends IDi and Li to AC through a secure channel.Step 2.
After receivingIDi and Li from Ui, AC checks whether IDi exists in the database. If it does, AC indicates Ui to select a new identity; otherwise, AC computes Xi=h(IDi∥sa) and Zi=Xi⊕Li; then AC stores {Zi,h(·),x,p} into SC. Finally, AC sends SC to Ui through a secure channel.Step 3.
After receivingSC from AC, Ui stores {Pi,Mi,r,l,Gen(·),Rep(·,·)} into SC. Finally, SC contains {Zi,Mi,Pi,r,l,Gen(·),Rep(·,·),h(·),x,p}.


## 3.3. Authentication

U i first logins to the SC; then Ui starts a mutual authentication process with AC to get a ticket Yij for accessing sever Sj. Next, Ui implements mutual authentication with Sj by Yij and establishes a session key ksession with Sj, where the ticket Yij has an expiry time which is determined by Sj.Step 1.
U i attaches the smart card SC and enters the identity IDi, password PWi, and fingerprint FPi. Then, SC computes Ri′=Req(FPi′,Pi′) andRi=h(h(IDi′∥PWi′∥r)modl)⊕Mi. The smart card SC rejects Ui’s login request if Ri≠Ri′; otherwise, SC chooses a random number u and computes TUi-SA=Tu(Tk0(x)), NIDij=(IDi∥IDj)·TUi-SA, Li=h(IDi∥PWi∥Ri∥r), Xi=Zi⊕Li, and Aut1=h(IDi∥IDj∥Xi∥TUi-SA∥TimeStamp1). Finally, Ui sends NIDij,Tu(x),Aut1,TimeStamp1 to AC.Step 2.
After receiving the messageNIDij,Tu(x),Aut1,TimeStamp1 from Ui, AC verifies whether TimeStamp1 is valid. If not, AC rejects Ui’s request; otherwise, AC computes TUi-SA′=Tk0(Tu(x)), IDi′∥IDj=NIDij/TUi-SA′, Xi′=h(IDi′∥sa), and h(IDi′∥IDj∥Xi′∥TUi-SA′∥TimeStamp1). Then AC terminates the session, if Aut1≠h(IDi′∥IDj∥Xi′∥TUi-SA′∥TimeStamp1); otherwise, AC computes a ticket Yij=h(IDi′∥h(IDj∥sb)∥TimeSetup), NYij=(Yij∥TimeSetup)⊕h(Xi′), and Aut2=h(IDi′∥IDj∥Xi′∥Yij∥TimeSetup∥TimeStamp2), where TimeSetup is the generation time of Yij. Finally, AC sends NYij,Aut2,TimeStamp2 to Ui.Step 3.
After receiving the messageYij,Aut2,TimeStamp2, Ui verifies whether TimeStamp2 is valid. If not, Ui terminates the session; otherwise, Ui computes Yij′∥TimeSetup′=NYij⊕h(Xi) and h(IDi∥IDj∥Xi∥Yij′∥TimeSetup∥TimeStamp2). Then Ui terminates the session, if Aut2≠h(IDi∥IDj∥Xi∥Yij′∥TimeSetup∥TimeStamp2); otherwise, Ui chooses a random number u2 and then computes TUi-Sj=Tu2(Tkj(x)), NIDij∗=(IDi∥IDj∥TimeSetup)·TUi-Sj, and Aut3=h(IDi∥IDj∥Yij′∥TUi-Sj∥TimeSetup∥TimeStamp3). Finally, Ui sends NIDij∗,Tu2(x),Aut3,TimeStamp3 to Sj.Step 4.
After receiving the messageNIDij∗,Tu2(x),Aut3,TimeStamp3, Sj verifies whether TimeStamp3 is valid. If not, Sj terminates the session; otherwise, Sj computes TUi-Sj′=Tkj(Tu2(x)) and IDi′∥IDj′∥TimeSetup′=NIDij∗/TUi-Sj′. Then Sj verifies whether IDj′=IDj and TimeSetup′ is valid. If not, Sj terminates the session; otherwise, Sj computes Yij′=h(IDi′∥skj∥TimeSetup′) and h(IDi′∥IDj∥Yij∥TUi-Sj′∥TimeSetup′∥TimeStamp3). Then Sj terminates the session, if Aut3≠h(IDi′∥IDj∥Yij∥TUi-Sj′∥TimeSetup′∥TimeStamp3); otherwise, Sj chooses a random number v and then computes ksession=Tv(Tu2(x)) and Aut4=h(IDi′∥IDj∥Yij′∥ksession∥TimeStamp4). Finally, Sj sends Tv(x),Aut4,TimeStamp4 to Ui.Step 5.
After receiving the messageTv(x),Aut4,TimeStamp4, Ui verifies whether TimeStamp4 is valid. If not, Ui terminates the session; otherwise, Ui computes ksession=Tu2(Tv(x)) and h(IDi∥IDj∥Yij∥ksession∥TimeStamp4). Then Ui terminates the session, if Aut4≠h(IDi∥IDj∥Yij∥ksession∥TimeStamp4); otherwise, Ui and Sj complete mutual authentication successfully. At this point, a session key ksession=Tu2·v(x)=Tu2(Tv(x))=Tv(Tu2(x)) has been established among Ui and Sj.After all these steps are completed, ifUi wants to access Sj again, it can be executed directly from Step 3 without AC’s participating, where the ticket Yij must be not out of date.


## 3.4. Password Change

In this phase,Ui only needs to log into SC successfully and then inputs new password PWinew and fingerprint information FPinew, without involvement of AC and Sj.Step 1.
U i inserts the smart card into a card reader and enters the identity IDi, password PWi, and fingerprint FPi.Step 2.
S C computes Ri′=Req(FPi′,Pi′) and Ri=h(h(IDi′∥PWi′∥r)modl)⊕Mi. The smart card SC rejects Ui’s login request if Ri≠Ri′; otherwise, SC indicates Ui to input new password and fingerprint information.Step 3.
U i inputs new password PWinew and fingerprint information FPinew.Step 4.
S C computes Li=h(IDi∥PWi∥Ri∥r), then chooses a random number rnew, and computes Rinew,Pinew←Gen(FPinew), Linew=h(IDi∥PWinew∥Rinew∥rnew), Minew=h(h(IDi∥PWinew∥rnew)modl)⊕Rinew, and Zinew=Zi⊕Li⊕Linew. Finally, SC updates Zi,Mi,Pi,r with Zinew,Minew,Pinew,rnew.


## 4. Security Analysis

In this section, we first use the BAN logic [26] to prove that a ticket will be agreed between the user and the authentication center; moreover, a session key will be agreed between the user and the sever after performing our new protocol. Then we demonstrate that the proposed protocol can withstand various known attacks and satisfy security requirements in cloud service.


### 4.1. Notations and Logic Rules

Table2 lists the notations used in the BAN logic.Table 2
Notations in BAN logic.
Notation Description P , Q entity X , Y statements K key { X , Y } X or Y is one part of {X,Y} P ≡ X P believes X P ⊲ X P sees X P ~ X P once said X P ⇒ X P has jurisdiction over X # ( X ) X is fresh P↔KQ P and Q share a key K P ⇌ X Q P and Q share a secret X X K X is encrypted with the key K X Y X combined with YThere are 19 logical rules in BAN logic. Thenth logical rule denotes Rn(n=1,2,···,19). Some main logical rules of the BAN logic, which will be used in our analysis, are described as follows, where Γ/A means conclusion A can be deduced by precondition sets Γ.The message-meaning rule is(6)R1:P≡P↔KQ,P⊲XKP≡Q~XR3:P≡P⇌YQ,P⊲XYP≡Q~XThe nonce-verification rule is(7)R4:P≡#X,P≡Q~XP≡Q≡XThe jurisdiction rule is(8)R5:P≡Q⇒X,P≡Q≡XP≡XThe seeing rule is(9)R8:P≡P↔KQ,P⊲XKP⊲XThe freshness rule is(10)R11:P≡#XP≡#X,YThe belief rule is(11)R13:P≡X,YP≡XR14:P≡Q≡X,YP≡Q≡X


### 4.2. Formal Proof

First, our proposed protocol is transformed to the idealized form.Message 1:(12)Ui→AC:Ui⇌IDiAC,Ui⇌IDjAC,Tux,TimeStamp1XiMessage 2:(13)AC→Ui:Ui⇌IDiAC,Ui⇌IDjAC,Ui⇌YijAC,Ui⇌TimeSetupAC,TimeStamp2XiMessage 3:(14)Ui→Sj:Ui⇌IDiSj,Ui⇌IDjSj,Ui⇌TimeSetupSj,Tu2x,TimeStamp3YijMessage 4:(15)Ui→Sj:Ui⇌IDiSj,Ui⇌IDjSj,Tvx,TimeStamp4YijWe need to prove that our proposed protocol could achieve the following goals.Goal 1:(16)Ui≡Ui⇌IDiACGoal 2:(17)SA≡Ui⇌IDiACGoal 3:(18)Ui≡Ui⇌IDjACGoal 4:(19)SA≡Ui⇌IDjACGoal 5:(20)Ui≡Ui⇌YijSjGoal 6:(21)Sj≡Ui⇌YijSjGoal 7:(22)Ui≡Ui⇌IDiSjGoal 8:(23)Sj≡Ui⇌IDiSjGoal 9:(24)Ui≡Ui↔ksessionSjGoal 10:(25)Sj≡Ui↔ksessionSjThen, the following assumptions are made about the initial status of our proposed protocol.(26)A1:Ui≡#TimeStamp2A2:Ui≡#Tu2xA3:Ui≡#TimeStamp4A4:Ui≡Ui⇌XiACA5:Ui≡AC⇒Ui⇌TimeSetupACA6:Ui≡AC⇒Ui⇌IDiACA7:Ui≡AC⇒Ui⇌IDjACA8:Ui≡Sj⇒Ui⇌IDiSjA9:Ui≡Sj⇒Ui↔ksessionSjA10:AC≡#TimeStamp1A11:AC≡Ui⇌XiACA12:AC≡Sj⇌skjACA13:AC≡Ui⇒Ui⇌IDiACA14:AC≡Ui⇒Ui⇌IDjACA15:Sj≡#TimeStamp3A16:Sj≡Sj⇌skjACA17:Sj≡Ui⇒Ui⇌IDiSjA18:Sj≡Ui⇒Ui↔ksessionSjThe detailed steps are presented as follows.( 1 ) From message 1, it is easy to have the following statement:(27)S1:AC⊲Ui⇌IDiAC,Ui⇌IDjAC,Tux,TimeStamp1Xi( 2 ) By S1, A11, and R3, it is easy to obtain(28)S2:AC≡Ui~Ui⇌IDiAC,Ui⇌IDjAC,Tux,TimeStamp1( 3 ) By A10 and R11, it is easy to obtain(29)S3:AC≡#Ui⇌IDiAC,Ui⇌IDjAC,Tux,TimeStamp1( 4 ) By S2, S3, and R4, it is easy to obtain(30)S4:AC≡Ui≡Ui⇌IDiAC,Ui⇌IDjAC,Tux,TimeStamp1( 5 ) By S4and R14, it is easy to obtain(31)S5:AC≡Ui≡Ui⇌IDiACS6:AC≡Ui≡Ui⇌IDjACS7:AC≡Ui≡Tux( 6 ) By S5, S6, A13, A14, and R5, it is easy to obtain(32)S8:AC≡Ui⇌IDiACGoal2S9:AC≡Ui⇌IDjACGoal4( 7 ) From message 2, it is easy to have the following statement:(33)S10:Ui⊲Ui⇌IDiAC,Ui⇌IDjAC,Ui⇌YijAC,Ui⇌TimeSetupAC,TimeStamp2Xi( 8 ) By S10, A4, and R3, it is easy to obtain(34)S11:Ui≡AC~Ui⇌IDiAC,Ui⇌IDjAC,Ui⇌YijAC,Ui⇌TimeSetupAC,TimeStamp2( 9 ) By A1 and R11, it is easy to obtain(35)S12:Ui≡#Ui⇌IDiAC,Ui⇌IDjAC,Ui⇌YijAC,Ui⇌TimeSetupAC,TimeStamp2( 10 ) By S11, S12, and R4, it is easy to obtain(36)S13:Ui≡AC≡Ui⇌IDiAC,Ui⇌IDjAC,Ui⇌YijAC,Ui⇌TimeSetupAC,TimeStamp2( 11 ) By S13 and R14, it is easy to obtain(37)S14:Ui≡AC≡Ui⇌IDiACS15:Ui≡AC≡Ui⇌IDjACS16:Ui≡AC≡Ui⇌YijACS17:Ui≡AC≡Ui⇌TimeSetupAC( 12 ) By S14, S15, S17, A5, A6, A7, and R5, it is easy to obtain(38)S18:Ui≡Ui⇌IDiACGoal1S19:Ui≡Ui⇌IDjACGoal3S20:Ui≡Ui⇌TimeSetupAC( 13 ) By Yij=h(IDi∥skj∥TimeSetup) and A5, we can deduce that(39)S21:Ui≡AC⇒Ui⇌YijAC( 14 ) By S16, S21, and R5, it is easy to obtain(40)S22:Ui≡Ui⇌YijAC( 15 ) By S22, A12, and Yij=h(IDi∥skj∥TimeSetup), it is easy to obtain(41)S23:Ui≡Ui⇌YijSjGoal5( 16 ) In message 3, Ui sends IDi and TimeSetup encrypted by Sj’s public key to the sever Sj. As Yij=h(IDi∥skj∥TimeSetup) and IDi and TimeSetup are integrity protected by secure hash function, combining A16, we can deduce that(42)S24:Sj≡Ui⇌YijSjGoal6( 17 ) From message 3, it is easy to have the following statement:(43)S25:Sj⊲Ui⇌IDiSj,Ui⇌IDjSj,Ui⇌TimeSetupSj,Tu2x,TimeStamp3Yij( 18 ) By S24, S25, and R5, it is easy to obtain(44)S26:Sj≡Ui~Ui⇌IDiSj,Ui⇌IDjSj,Ui⇌TimeSetupSj,Tu2x,TimeStamp3( 19 ) By A15 and R11, it is easy to obtain(45)S27:Sj≡#Ui⇌IDiSj,Ui⇌IDjSj,Ui⇌TimeSetupSj,Tu2x,TimeStamp3( 20 ) By S26, S27, and R4, it is easy to obtain(46)S28:Sj≡Ui≡Ui⇌IDiSj,Ui⇌IDjSj,Ui⇌TimeSetupSj,Tu2x,TimeStamp3( 21 ) By S28 and R14, it is easy to obtain(47)S29:Sj≡Ui≡Ui⇌IDiSjS30:Sj≡Ui≡Ui⇌IDjSjS31:Sj≡Ui≡Ui⇌TimeSetupSjS32:Sj≡Ui≡Tu2x( 22 ) By S29, A17, and R5, it is easy to obtain(48)S33:Sj≡Ui⇌IDiSjGoal8( 23 ) By S32, ksession=Tv(Tu2(x)), and difficulty assumptions, we can deduce that(49)S34:Sj≡Ui≡Ui↔ksessionSj( 24 ) By S34, A18, and R5, it is easy to obtain(50)S35:Sj≡Ui↔ksessionSjGoal10( 25 ) From message 4, it is easy to have the following statement:(51)S36:Ui⊲Ui⇌IDiSj,Ui⇌IDjSj,Tvx,TimeStamp4Yij( 26 ) By S23, S36, and R5, it is easy to obtain(52)S37:Ui≡Sj~Ui⇌IDiSj,Ui⇌IDjSj,Tvx,TimeStamp4( 27 ) By A3 and R11, it is easy to obtain(53)S38:Ui≡#Ui⇌IDiSj,Ui⇌IDjSj,Tvx,TimeStamp4( 28 ) By S37, S38, and R4, it is easy to obtain(54)S39:Ui≡Sj≡Ui⇌IDiSj,Ui⇌IDjSj,Tvx,TimeStamp4( 29 ) By S39 and R14, it is easy to obtain(55)S40:Ui≡Sj≡Ui⇌IDiSjS41:Ui≡Sj≡Ui⇌IDjSjS42:Ui≡Sj≡Tvx( 30 ) By S40, A8, and R5, it is easy to obtain(56)S43:Ui≡Ui⇌IDiSjGoal7( 31 ) By S42, ksession=Tu2(Tv(x)), and difficulty assumptions, we can deduce that(57)S44:Ui≡Sj≡Ui↔ksessionSj( 32 ) By S44, A9, and R5, it is easy to obtain(58)S45:Ui≡Ui↔ksessionSjGoal9Through (Goal 1)…(Goal 10), we have proved that the user and the authentication center believe that they share a ticket, and the user and the sever believe that they share a session key.


### 4.3. Resisting Stolen/Lost Smart Card Attack

If the smart card is stolen/lost by the adversary, the adversary can extract the information{Zi,Mi,Pi,r,l,Gen(·),Rep(·,·),h(·),x,p} stored in the smart card, where Zi=h(IDi∥sa)⊕h(IDi∥PWi∥Ri∥r) and Mi=h(h(IDi∥PWi∥r)modl)⊕Ri. But, the adversary only knows the value of r. Obviously, he or she cannot obtain Ui’s identification or password. So our proposed protocol could withstand the stolen/lost smart card attack.


### 4.4. Resisting Replay Attack

In our protocol, the mechanism of timestamp is included in each message. ThenUi, Sj, and AC could detect the replay of some message by checking the freshness of the timestamp. Therefore, our new protocol can withstand the replay attack.


### 4.5. Resisting Man-in-the-Middle Attack

If the adversary carries out the man-in-the-middle attack, he or she needs to choose aTu2(x) and compute a valid Aut3. However, the adversary cannot get Yij′ and TimeSetup included in Aut3. Thus, the adversary cannot compute a valid Aut3. Similarly, the adversary cannot also compute a valid Aut4. Therefore, our new protocol can withstand the man-in-the-middle attack.


### 4.6. Mutual Authentication

Our new protocol achieves mutual authentication both betweenUi and AC and between Ui and Sj.Mutual authentication betweenUi and AC: in Step 2 of authentication phase, AC computes Xi′=h(IDi′∥sa) and checks the legitimacy of Ui by checking whether Aut1 is equal to h(IDi′∥IDj∥Xi′∥TUi-SA′∥TimeStamp1), because only Ui with the correct password and smart card has the knowledge of the secret Xi=h(IDi∥sa) and the capability of generating the valid value Aut1=h(IDi∥IDj∥Xi∥TUi-SA∥TimeStamp1). AC can ensure that Ui is really who he or she claims. In Step 3 of authentication phase, Ui checks the legitimacy of AC by checking whether Aut2 is equal to h(IDi∥IDj∥Xi∥Yij′∥TimeSetup∥TimeStamp2), because only AC with the master key sa can compute secret Xi=h(IDi∥sa) and Aut2=h(IDi′∥IDj∥Xi′∥Yij∥TimeSetup∥TimeStamp2). Ui can ensure that he or she is communicating with the real AC.Mutual authentication betweenUi and Sj: in Step 4 of authentication phase, Sj computes Yij′=h(IDi′∥skj∥TimeSetup′)and checks the legitimacy of Ui by checking whether Aut3 is equal to h(IDi′∥IDj∥Yij∥TUi-Sj′∥TimeSetup′∥TimeStamp3), because only Ui verified by AC has the knowledge of the ticket Yij and the capability of generating the valid value Aut3=h(IDi∥IDj∥Yij′∥TUi-Sj∥TimeSetup∥TimeStamp3). Sj ensured that Ui is really who he or she claims. In Step 5 of authentication phase, Ui checks the legitimacy of Sj by checking whether Aut4 is equal to h(IDi∥IDj∥Yij∥ksession∥TimeStamp4), because only Sj with the private key skj can compute the ticket Yij′=h(IDi′∥skj∥TimeSetup′) and Aut4=h(IDi′∥IDj∥Yij′∥ksession∥TimeStamp4). Ui ensured that he or she is communicating with a legitimate Sj.


### 4.7. Anonymity

In our protocol, the user’s identityIDi is involved in NIDij, NYij, and NIDij∗, which is encrypted with TUi-SA and TUi-Sj. The adversary cannot get IDi without knowing the random number u, v, and the AC’s private key k0, because TUi-SA and TUi-Sj are computationally infeasible because of the hardness of the extended chaotic-map-based CDHP. Thus the adversary cannot extract the user’s real identity IDi. Therefore, our protocol achieves user anonymity.


### 4.8. Ticket Security

If the adversary wants to get the ticketYij, he or she can only retrieve it from NYij=(Yij∥TimeSetup)⊕h(Xi′). However, through Section 4.3 we know that the attacker could not get secrecy Xi even if the smart card was lost or stolen. Thus the adversary cannot compute h(Xi′) and Yij.Moreover, the server’s identityIDj is involved in the NIDij, NYij, and NIDij∗, which is encrypted with TUi-SA and TUi-Sj. The adversary cannot get IDj, because TUi-SA and TUi-Sj are computationally infeasible because of the hardness of the extended chaotic-map-based CDHP. So though the adversary get the ticket Yij, he or she does not know which sever to access with Yij.


### 4.9. Perfect Forward Secrecy

In our protocol, the established session key isksession=Tu2·v(x)=Tu2(Tv(x))=Tv(Tu2(x)), where u2 and v are random numbers selected by the user and the sever, respectively. Previously established session keys remain secure even when the long-term keys of the server and the user are disclosed, because the adversary is computationally infeasible to calculate the session key with Tu2(x) and Tv(x) because of the hardness of the extended chaotic-map-based CDHP.


### 4.10. Security Features Comparisons

We compare the security features of the proposed protocol with those of the previous multifactor authentication protocols for multiserver environment, including Jiang et al.’s [19], Wu et al.’s [20], and Das’s [27].Table3 shows the results of the security features comparisons. From Table 3, we note that Jiang et al.’s protocol does not achieve user anonymity. Wu et al.’s and Das et al.’s protocol cannot resist stolen/lost smart card attack. Table 3 shows that our new protocol is the only one that is free from security attacks and provides anonymity and perfect forward secrecy.Table 3
Comparison of security features.
Jiang et al.[19] Wu et al.[20] Das[27] Our protocol Resisting stolen/lost smart card attack ✔ ✖ ✖ ✔ Resisting replay attack ✔ ✔ ✔ ✔ Resisting man-in-the-middle attack ✔ ✔ ✔ ✔ Mutual authentication ✔ ✔ ✔ ✔ Anonymity ✖ ✔ ✖ ✔ Perfect forward secrecy ✔ ✔ ✖ ✔


## 4.1. Notations and Logic Rules

Table2 lists the notations used in the BAN logic.Table 2
Notations in BAN logic.
Notation Description P , Q entity X , Y statements K key { X , Y } X or Y is one part of {X,Y} P ≡ X P believes X P ⊲ X P sees X P ~ X P once said X P ⇒ X P has jurisdiction over X # ( X ) X is fresh P↔KQ P and Q share a key K P ⇌ X Q P and Q share a secret X X K X is encrypted with the key K X Y X combined with YThere are 19 logical rules in BAN logic. Thenth logical rule denotes Rn(n=1,2,···,19). Some main logical rules of the BAN logic, which will be used in our analysis, are described as follows, where Γ/A means conclusion A can be deduced by precondition sets Γ.The message-meaning rule is(6)R1:P≡P↔KQ,P⊲XKP≡Q~XR3:P≡P⇌YQ,P⊲XYP≡Q~XThe nonce-verification rule is(7)R4:P≡#X,P≡Q~XP≡Q≡XThe jurisdiction rule is(8)R5:P≡Q⇒X,P≡Q≡XP≡XThe seeing rule is(9)R8:P≡P↔KQ,P⊲XKP⊲XThe freshness rule is(10)R11:P≡#XP≡#X,YThe belief rule is(11)R13:P≡X,YP≡XR14:P≡Q≡X,YP≡Q≡X


## 4.2. Formal Proof

First, our proposed protocol is transformed to the idealized form.Message 1:(12)Ui→AC:Ui⇌IDiAC,Ui⇌IDjAC,Tux,TimeStamp1XiMessage 2:(13)AC→Ui:Ui⇌IDiAC,Ui⇌IDjAC,Ui⇌YijAC,Ui⇌TimeSetupAC,TimeStamp2XiMessage 3:(14)Ui→Sj:Ui⇌IDiSj,Ui⇌IDjSj,Ui⇌TimeSetupSj,Tu2x,TimeStamp3YijMessage 4:(15)Ui→Sj:Ui⇌IDiSj,Ui⇌IDjSj,Tvx,TimeStamp4YijWe need to prove that our proposed protocol could achieve the following goals.Goal 1:(16)Ui≡Ui⇌IDiACGoal 2:(17)SA≡Ui⇌IDiACGoal 3:(18)Ui≡Ui⇌IDjACGoal 4:(19)SA≡Ui⇌IDjACGoal 5:(20)Ui≡Ui⇌YijSjGoal 6:(21)Sj≡Ui⇌YijSjGoal 7:(22)Ui≡Ui⇌IDiSjGoal 8:(23)Sj≡Ui⇌IDiSjGoal 9:(24)Ui≡Ui↔ksessionSjGoal 10:(25)Sj≡Ui↔ksessionSjThen, the following assumptions are made about the initial status of our proposed protocol.(26)A1:Ui≡#TimeStamp2A2:Ui≡#Tu2xA3:Ui≡#TimeStamp4A4:Ui≡Ui⇌XiACA5:Ui≡AC⇒Ui⇌TimeSetupACA6:Ui≡AC⇒Ui⇌IDiACA7:Ui≡AC⇒Ui⇌IDjACA8:Ui≡Sj⇒Ui⇌IDiSjA9:Ui≡Sj⇒Ui↔ksessionSjA10:AC≡#TimeStamp1A11:AC≡Ui⇌XiACA12:AC≡Sj⇌skjACA13:AC≡Ui⇒Ui⇌IDiACA14:AC≡Ui⇒Ui⇌IDjACA15:Sj≡#TimeStamp3A16:Sj≡Sj⇌skjACA17:Sj≡Ui⇒Ui⇌IDiSjA18:Sj≡Ui⇒Ui↔ksessionSjThe detailed steps are presented as follows.( 1 ) From message 1, it is easy to have the following statement:(27)S1:AC⊲Ui⇌IDiAC,Ui⇌IDjAC,Tux,TimeStamp1Xi( 2 ) By S1, A11, and R3, it is easy to obtain(28)S2:AC≡Ui~Ui⇌IDiAC,Ui⇌IDjAC,Tux,TimeStamp1( 3 ) By A10 and R11, it is easy to obtain(29)S3:AC≡#Ui⇌IDiAC,Ui⇌IDjAC,Tux,TimeStamp1( 4 ) By S2, S3, and R4, it is easy to obtain(30)S4:AC≡Ui≡Ui⇌IDiAC,Ui⇌IDjAC,Tux,TimeStamp1( 5 ) By S4and R14, it is easy to obtain(31)S5:AC≡Ui≡Ui⇌IDiACS6:AC≡Ui≡Ui⇌IDjACS7:AC≡Ui≡Tux( 6 ) By S5, S6, A13, A14, and R5, it is easy to obtain(32)S8:AC≡Ui⇌IDiACGoal2S9:AC≡Ui⇌IDjACGoal4( 7 ) From message 2, it is easy to have the following statement:(33)S10:Ui⊲Ui⇌IDiAC,Ui⇌IDjAC,Ui⇌YijAC,Ui⇌TimeSetupAC,TimeStamp2Xi( 8 ) By S10, A4, and R3, it is easy to obtain(34)S11:Ui≡AC~Ui⇌IDiAC,Ui⇌IDjAC,Ui⇌YijAC,Ui⇌TimeSetupAC,TimeStamp2( 9 ) By A1 and R11, it is easy to obtain(35)S12:Ui≡#Ui⇌IDiAC,Ui⇌IDjAC,Ui⇌YijAC,Ui⇌TimeSetupAC,TimeStamp2( 10 ) By S11, S12, and R4, it is easy to obtain(36)S13:Ui≡AC≡Ui⇌IDiAC,Ui⇌IDjAC,Ui⇌YijAC,Ui⇌TimeSetupAC,TimeStamp2( 11 ) By S13 and R14, it is easy to obtain(37)S14:Ui≡AC≡Ui⇌IDiACS15:Ui≡AC≡Ui⇌IDjACS16:Ui≡AC≡Ui⇌YijACS17:Ui≡AC≡Ui⇌TimeSetupAC( 12 ) By S14, S15, S17, A5, A6, A7, and R5, it is easy to obtain(38)S18:Ui≡Ui⇌IDiACGoal1S19:Ui≡Ui⇌IDjACGoal3S20:Ui≡Ui⇌TimeSetupAC( 13 ) By Yij=h(IDi∥skj∥TimeSetup) and A5, we can deduce that(39)S21:Ui≡AC⇒Ui⇌YijAC( 14 ) By S16, S21, and R5, it is easy to obtain(40)S22:Ui≡Ui⇌YijAC( 15 ) By S22, A12, and Yij=h(IDi∥skj∥TimeSetup), it is easy to obtain(41)S23:Ui≡Ui⇌YijSjGoal5( 16 ) In message 3, Ui sends IDi and TimeSetup encrypted by Sj’s public key to the sever Sj. As Yij=h(IDi∥skj∥TimeSetup) and IDi and TimeSetup are integrity protected by secure hash function, combining A16, we can deduce that(42)S24:Sj≡Ui⇌YijSjGoal6( 17 ) From message 3, it is easy to have the following statement:(43)S25:Sj⊲Ui⇌IDiSj,Ui⇌IDjSj,Ui⇌TimeSetupSj,Tu2x,TimeStamp3Yij( 18 ) By S24, S25, and R5, it is easy to obtain(44)S26:Sj≡Ui~Ui⇌IDiSj,Ui⇌IDjSj,Ui⇌TimeSetupSj,Tu2x,TimeStamp3( 19 ) By A15 and R11, it is easy to obtain(45)S27:Sj≡#Ui⇌IDiSj,Ui⇌IDjSj,Ui⇌TimeSetupSj,Tu2x,TimeStamp3( 20 ) By S26, S27, and R4, it is easy to obtain(46)S28:Sj≡Ui≡Ui⇌IDiSj,Ui⇌IDjSj,Ui⇌TimeSetupSj,Tu2x,TimeStamp3( 21 ) By S28 and R14, it is easy to obtain(47)S29:Sj≡Ui≡Ui⇌IDiSjS30:Sj≡Ui≡Ui⇌IDjSjS31:Sj≡Ui≡Ui⇌TimeSetupSjS32:Sj≡Ui≡Tu2x( 22 ) By S29, A17, and R5, it is easy to obtain(48)S33:Sj≡Ui⇌IDiSjGoal8( 23 ) By S32, ksession=Tv(Tu2(x)), and difficulty assumptions, we can deduce that(49)S34:Sj≡Ui≡Ui↔ksessionSj( 24 ) By S34, A18, and R5, it is easy to obtain(50)S35:Sj≡Ui↔ksessionSjGoal10( 25 ) From message 4, it is easy to have the following statement:(51)S36:Ui⊲Ui⇌IDiSj,Ui⇌IDjSj,Tvx,TimeStamp4Yij( 26 ) By S23, S36, and R5, it is easy to obtain(52)S37:Ui≡Sj~Ui⇌IDiSj,Ui⇌IDjSj,Tvx,TimeStamp4( 27 ) By A3 and R11, it is easy to obtain(53)S38:Ui≡#Ui⇌IDiSj,Ui⇌IDjSj,Tvx,TimeStamp4( 28 ) By S37, S38, and R4, it is easy to obtain(54)S39:Ui≡Sj≡Ui⇌IDiSj,Ui⇌IDjSj,Tvx,TimeStamp4( 29 ) By S39 and R14, it is easy to obtain(55)S40:Ui≡Sj≡Ui⇌IDiSjS41:Ui≡Sj≡Ui⇌IDjSjS42:Ui≡Sj≡Tvx( 30 ) By S40, A8, and R5, it is easy to obtain(56)S43:Ui≡Ui⇌IDiSjGoal7( 31 ) By S42, ksession=Tu2(Tv(x)), and difficulty assumptions, we can deduce that(57)S44:Ui≡Sj≡Ui↔ksessionSj( 32 ) By S44, A9, and R5, it is easy to obtain(58)S45:Ui≡Ui↔ksessionSjGoal9Through (Goal 1)…(Goal 10), we have proved that the user and the authentication center believe that they share a ticket, and the user and the sever believe that they share a session key.


## 4.3. Resisting Stolen/Lost Smart Card Attack

If the smart card is stolen/lost by the adversary, the adversary can extract the information{Zi,Mi,Pi,r,l,Gen(·),Rep(·,·),h(·),x,p} stored in the smart card, where Zi=h(IDi∥sa)⊕h(IDi∥PWi∥Ri∥r) and Mi=h(h(IDi∥PWi∥r)modl)⊕Ri. But, the adversary only knows the value of r. Obviously, he or she cannot obtain Ui’s identification or password. So our proposed protocol could withstand the stolen/lost smart card attack.


## 4.4. Resisting Replay Attack

In our protocol, the mechanism of timestamp is included in each message. ThenUi, Sj, and AC could detect the replay of some message by checking the freshness of the timestamp. Therefore, our new protocol can withstand the replay attack.


## 4.5. Resisting Man-in-the-Middle Attack

If the adversary carries out the man-in-the-middle attack, he or she needs to choose aTu2(x) and compute a valid Aut3. However, the adversary cannot get Yij′ and TimeSetup included in Aut3. Thus, the adversary cannot compute a valid Aut3. Similarly, the adversary cannot also compute a valid Aut4. Therefore, our new protocol can withstand the man-in-the-middle attack.


## 4.6. Mutual Authentication

Our new protocol achieves mutual authentication both betweenUi and AC and between Ui and Sj.Mutual authentication betweenUi and AC: in Step 2 of authentication phase, AC computes Xi′=h(IDi′∥sa) and checks the legitimacy of Ui by checking whether Aut1 is equal to h(IDi′∥IDj∥Xi′∥TUi-SA′∥TimeStamp1), because only Ui with the correct password and smart card has the knowledge of the secret Xi=h(IDi∥sa) and the capability of generating the valid value Aut1=h(IDi∥IDj∥Xi∥TUi-SA∥TimeStamp1). AC can ensure that Ui is really who he or she claims. In Step 3 of authentication phase, Ui checks the legitimacy of AC by checking whether Aut2 is equal to h(IDi∥IDj∥Xi∥Yij′∥TimeSetup∥TimeStamp2), because only AC with the master key sa can compute secret Xi=h(IDi∥sa) and Aut2=h(IDi′∥IDj∥Xi′∥Yij∥TimeSetup∥TimeStamp2). Ui can ensure that he or she is communicating with the real AC.Mutual authentication betweenUi and Sj: in Step 4 of authentication phase, Sj computes Yij′=h(IDi′∥skj∥TimeSetup′)and checks the legitimacy of Ui by checking whether Aut3 is equal to h(IDi′∥IDj∥Yij∥TUi-Sj′∥TimeSetup′∥TimeStamp3), because only Ui verified by AC has the knowledge of the ticket Yij and the capability of generating the valid value Aut3=h(IDi∥IDj∥Yij′∥TUi-Sj∥TimeSetup∥TimeStamp3). Sj ensured that Ui is really who he or she claims. In Step 5 of authentication phase, Ui checks the legitimacy of Sj by checking whether Aut4 is equal to h(IDi∥IDj∥Yij∥ksession∥TimeStamp4), because only Sj with the private key skj can compute the ticket Yij′=h(IDi′∥skj∥TimeSetup′) and Aut4=h(IDi′∥IDj∥Yij′∥ksession∥TimeStamp4). Ui ensured that he or she is communicating with a legitimate Sj.


## 4.7. Anonymity

In our protocol, the user’s identityIDi is involved in NIDij, NYij, and NIDij∗, which is encrypted with TUi-SA and TUi-Sj. The adversary cannot get IDi without knowing the random number u, v, and the AC’s private key k0, because TUi-SA and TUi-Sj are computationally infeasible because of the hardness of the extended chaotic-map-based CDHP. Thus the adversary cannot extract the user’s real identity IDi. Therefore, our protocol achieves user anonymity.


## 4.8. Ticket Security

If the adversary wants to get the ticketYij, he or she can only retrieve it from NYij=(Yij∥TimeSetup)⊕h(Xi′). However, through Section 4.3 we know that the attacker could not get secrecy Xi even if the smart card was lost or stolen. Thus the adversary cannot compute h(Xi′) and Yij.Moreover, the server’s identityIDj is involved in the NIDij, NYij, and NIDij∗, which is encrypted with TUi-SA and TUi-Sj. The adversary cannot get IDj, because TUi-SA and TUi-Sj are computationally infeasible because of the hardness of the extended chaotic-map-based CDHP. So though the adversary get the ticket Yij, he or she does not know which sever to access with Yij.


## 4.9. Perfect Forward Secrecy

In our protocol, the established session key isksession=Tu2·v(x)=Tu2(Tv(x))=Tv(Tu2(x)), where u2 and v are random numbers selected by the user and the sever, respectively. Previously established session keys remain secure even when the long-term keys of the server and the user are disclosed, because the adversary is computationally infeasible to calculate the session key with Tu2(x) and Tv(x) because of the hardness of the extended chaotic-map-based CDHP.


## 4.10. Security Features Comparisons

We compare the security features of the proposed protocol with those of the previous multifactor authentication protocols for multiserver environment, including Jiang et al.’s [19], Wu et al.’s [20], and Das’s [27].Table3 shows the results of the security features comparisons. From Table 3, we note that Jiang et al.’s protocol does not achieve user anonymity. Wu et al.’s and Das et al.’s protocol cannot resist stolen/lost smart card attack. Table 3 shows that our new protocol is the only one that is free from security attacks and provides anonymity and perfect forward secrecy.Table 3
Comparison of security features.
Jiang et al.[19] Wu et al.[20] Das[27] Our protocol Resisting stolen/lost smart card attack ✔ ✖ ✖ ✔ Resisting replay attack ✔ ✔ ✔ ✔ Resisting man-in-the-middle attack ✔ ✔ ✔ ✔ Mutual authentication ✔ ✔ ✔ ✔ Anonymity ✖ ✔ ✖ ✔ Perfect forward secrecy ✔ ✔ ✖ ✔


## 5. Efficiency Analysis

This section compares the efficiency of the proposed protocol with that of the previous multifactor authentication protocols for multiserver environment, including Jiang et al.’s [19], Wu et al.’s [20], and Das’s [27]. Table 4 shows separately the results of the security features comparisons and the efficiency comparisons.Table 4
Efficiency comparisons.
User Authentication center Server Computational cost Jiang et al.[19] 8 T H + T M 12 T H + T Q R 5 T H 25 T H + T M + T Q R Wu et al.[20] 11 T H + 2 T E c M 10 T H 3 T H + 2 T E c M 24 T H + 4 T E c M Das[27] 7 T H + T E c M 2 T H + T S 2 T H + T S 11 T H + T E c M + 2 T S Our protocol 6 T H + T C h e 2 T H + T C h e ∗ 4 T H + T C h e 3 T H + 2 T C h e 13 T H + 4 T C h e 5 T H + 3 T C h e ∗ ∗ The computational cost when the ticket is not expired.To simplify the presentation, the following symbols are defined.TChe,TEcM,TH,TS,TM,TQR denote the time for executing Tn(x)modp in Chebyshev polynomial using the algorithm in the literature [28], ECC point multiplication, the hash, the symmetric encryption/decryption, the modular squaring, and the computation of a square root modulo N, respectively. To be more precise, on an Intel Pentium4 2600 MHz processor with 1024 MB RAM, where n and p are 1024 bits long, TChe,TEcM,TH,TS is 21 ms, 63.1ms, 0.5ms, and 8.7ms, respectively [28, 29]. The computational time of the bit XOR operation and multiplication operation is ignored compared with the above operations.Table4 shows that our proposed protocol has better efficiency than the protocols of Wu et al. and Das et al. Although the protocol of Jiang et al. has slightly better efficiency than our proposed protocol, it cannot accomplish anonymity. Besides, as any user accesses any server, the participation of the authentication center is required. When the number of users is huge, the computational cost of the authentication center may be very high, which could cause the authentication center crashing. In our protocol, when the ticket is valid, there is no need for the authentication center to participate. What is more, the total computational cost is greatly reduced. Overall, compared with other schemes, our scheme is more in accordance with the actual application requirements while ensuring the security and efficiency.


## 6. Conclusion

In this paper, we propose a novel multiserver authentication protocol based on the extended Chebyshev chaotic map with multifactors for cloud service. In our protocol, we designed a ticket for achieving mutual authentication between the user and the server which is innovative. When the ticket is valid, there is no need for authentication center to participate in the authentication process, which further reduces the burden of the authentication center. The ticket has an expiry time which is determined by the server according to specific requirement. Compared with the Kerberos protocol, there is no need to share a secret key in advance between the authentication center and the server.Efficiency analysis shows that our protocol can resist a variety of attacks and provide the desirable security features. Compared with the existing schemes, the new protocol accomplishes various security and usability features necessary for all the participants, while maintaining relative high efficiency. Therefore, our scheme is more suitable for practical application.



---

*Source: 5432960-2018-11-19.xml*