# Provably Secure ECC-Based Three-Factor Authentication Scheme for Mobile Cloud Computing with Offline Registration Centre

Authors: Hongwei Luo; Feifei Wang; Guoai Xu
Journal: Wireless Communications and Mobile Computing
 (2021)

---

## Abstract

Mobile cloud computing (MCC) aims at solving the resource constrain problem of smart mobile devices. It has deeply affected the way modern humans live and work. In MCC, the authentication scheme is indispensable to prevent illegal attacks and privacy breaches. In this paper, we reveal that a recently proposed two-factor authentication scheme for MCC has limitations like stolen-verifier attack and denial of service attack. In addition, its single-server architecture is not applicable to MCC. To enhance the security, we present a provably secure three-factor authentication scheme using the elliptic curve cryptosystem (ECC). It has the merit that the user only needs to register once to access multiple servers with a pair of public and private key, and the registration center is offline in the authentication phase. Security analysis demonstrates that our scheme is immune to known attacks and provides user friendliness. Finally, performance comparisons indicate that our scheme has better security attributes and low computing and communication overheads, and it is more applicable to MCC.


---

## Body

## 1. Introduction

With the popularity of smart mobile devices, mobile Internet is becoming more and more important in our daily life and deeply affects the way modern humans live and work [1]. Mobile Internet provides high-quality telecommunication services such as voice, fax, data, image, and multimedia. We can obtain a variety of services anytime and anywhere through mobile Internet. Various mobile Internet applications include mobile payment, mobile e-commerce, and mobile entertainment are emerged. Some of these applications such as WeChat and Alipay bring tremendous convenience to people. With the continuous development of mobile Internet, the deficiency that smart mobile devices have limited storage capacity and processing power is gradually revealed. To resolve this issue, cloud computing [2] is introduced into mobile Internet; therefore, a new technology namely mobile cloud computing (MCC) [3] is produced. It aims at solving the resource constrain problem of smart mobile devices, and it can effectively increase the computing power and storage capacity of smart mobile devices.In an MCC setting, as a trusted third party, the registration center is responsible for issuing the secret key to users and cloud servers in the registration phase. In the authentication phase, the users access the resources and services deployed in distributed cloud servers via mobile and wireless networks, as shown in Figure1. Due to the openness of the communication networks, the attacker can implement various attacks such as modification, forgery, and replay. It is indispensable to develop an authentication scheme for MCC to achieve identity authentication and secure data transmission, as well as the protection of user privacy.Figure 1
The architecture of MCC.


### 1.1. Related Works

Since Lamport [4] presented the first password authentication scheme, a large number of schemes [5–18] that are applicable to different scenarios, adopt different cryptosystems, and employ different kinds of authentication factors were presented. In 2001, Li et al. [17] presented the first multiserver authentication scheme, in which the user can register once and then access multiple servers with a pair of identity and password. Some authentication schemes for MCC [19–22] have been presented in recent years. In 2015, Tsai and Lo [3] introduced an authentication scheme for MCC with offline registration center using bilinear pairing. In 2017, Feng et al. [23] introduced a three-factor mobile multiserver authentication scheme using the elliptic curve cryptosystem (ECC). Amin et al. [24] introduced a lightweight two-factor authentication scheme for MCC. However, their scheme is found to have weaknesses such as offline guessing attack [25]. In 2018, He et al. [26] pointed out that Tsai et al.’s scheme suffers from server impersonation attack. They furthermore proposed an improved scheme by using identity-based signature. Their scheme can provide better security features. In 2019, Irshad et al. [27] presented an enhanced authentication scheme for MCC using bilinear pairing. In 2019, Mo et al. [28] put forward a provably secure two-factor authentication scheme using ECC. In 2020, Li et al. [29] put forward a lattice-based password authenticated key exchange protocol, and their scheme achieves quantum resistance.


### 1.2. Motivation and Contributions

To improve the security and optimize the efficiency, we design a provably secure authentication scheme using ECC in this paper. Without public key cryptographic techniques, it is difficult to achieve user anonymity and forward secrecy [12]. By using ECC, the proposed scheme provides mutual authentication and user anonymity and establishes secure session key. Compared with the existing schemes with offline registration center using bilinear pairing [3, 26–28], our ECC-based scheme is more efficient. Our major contributions are as follows.
(1)
We prove that Mo et al.’s scheme [28] has limitations like stolen-verifier attack, denial of service attack, known session-specific temporary information attack, and its single-server architecture is not applicable to MCC(2)
We put forward a novel authentication scheme for MCC using ECC. It inherits the advantages of existing schemes such as He et al.’s scheme. It enables the user to register once and use a pair of public and private key to access multiple servers. In the authentication phase, the registration center is offline. The user interacts with the cloud server directly. It is conducive to reduce computing and communication overheads(3)
The security analysis demonstrates that the proposed scheme can resist usual attacks and preserve user friendliness. The performance comparisons show that the proposed scheme can remedy the security defects of the existing schemes and incur low computing and communication overheads. The proposed scheme is more suitable for MCC


### 1.3. Roadmap of Paper

This paper is organized as below. Section2 gives some preliminaries. Mo et al.’s scheme is cryptanalyzed in Section 3. Section 4 gives the proposed three-factor authentication scheme for MCC. Section 5 is the security analysis. Section 6 is the performance comparisons. Finally, we conclude the paper in Section 7. We summarize some notations in Table 1.Table 1
Notations.
SymbolsDescriptionRCThe registration centerUiThe userCSjThe cloud serverIDi,PWi,biUi’s identity, password, and biometricSIDjCSj’s identityPA generator of elliptic curve groupEqdi,PUBiUi’s private key and public keykj, PUBjCSj’s private key and public keySKSession key∥The string concatenation operation⊕The bitwise XOR operationH1Hash functionH2Biohashing function, it maps the biometric of user to a random string


## 1.1. Related Works

Since Lamport [4] presented the first password authentication scheme, a large number of schemes [5–18] that are applicable to different scenarios, adopt different cryptosystems, and employ different kinds of authentication factors were presented. In 2001, Li et al. [17] presented the first multiserver authentication scheme, in which the user can register once and then access multiple servers with a pair of identity and password. Some authentication schemes for MCC [19–22] have been presented in recent years. In 2015, Tsai and Lo [3] introduced an authentication scheme for MCC with offline registration center using bilinear pairing. In 2017, Feng et al. [23] introduced a three-factor mobile multiserver authentication scheme using the elliptic curve cryptosystem (ECC). Amin et al. [24] introduced a lightweight two-factor authentication scheme for MCC. However, their scheme is found to have weaknesses such as offline guessing attack [25]. In 2018, He et al. [26] pointed out that Tsai et al.’s scheme suffers from server impersonation attack. They furthermore proposed an improved scheme by using identity-based signature. Their scheme can provide better security features. In 2019, Irshad et al. [27] presented an enhanced authentication scheme for MCC using bilinear pairing. In 2019, Mo et al. [28] put forward a provably secure two-factor authentication scheme using ECC. In 2020, Li et al. [29] put forward a lattice-based password authenticated key exchange protocol, and their scheme achieves quantum resistance.


## 1.2. Motivation and Contributions

To improve the security and optimize the efficiency, we design a provably secure authentication scheme using ECC in this paper. Without public key cryptographic techniques, it is difficult to achieve user anonymity and forward secrecy [12]. By using ECC, the proposed scheme provides mutual authentication and user anonymity and establishes secure session key. Compared with the existing schemes with offline registration center using bilinear pairing [3, 26–28], our ECC-based scheme is more efficient. Our major contributions are as follows.
(1)
We prove that Mo et al.’s scheme [28] has limitations like stolen-verifier attack, denial of service attack, known session-specific temporary information attack, and its single-server architecture is not applicable to MCC(2)
We put forward a novel authentication scheme for MCC using ECC. It inherits the advantages of existing schemes such as He et al.’s scheme. It enables the user to register once and use a pair of public and private key to access multiple servers. In the authentication phase, the registration center is offline. The user interacts with the cloud server directly. It is conducive to reduce computing and communication overheads(3)
The security analysis demonstrates that the proposed scheme can resist usual attacks and preserve user friendliness. The performance comparisons show that the proposed scheme can remedy the security defects of the existing schemes and incur low computing and communication overheads. The proposed scheme is more suitable for MCC


## 1.3. Roadmap of Paper

This paper is organized as below. Section2 gives some preliminaries. Mo et al.’s scheme is cryptanalyzed in Section 3. Section 4 gives the proposed three-factor authentication scheme for MCC. Section 5 is the security analysis. Section 6 is the performance comparisons. Finally, we conclude the paper in Section 7. We summarize some notations in Table 1.Table 1
Notations.
SymbolsDescriptionRCThe registration centerUiThe userCSjThe cloud serverIDi,PWi,biUi’s identity, password, and biometricSIDjCSj’s identityPA generator of elliptic curve groupEqdi,PUBiUi’s private key and public keykj, PUBjCSj’s private key and public keySKSession key∥The string concatenation operation⊕The bitwise XOR operationH1Hash functionH2Biohashing function, it maps the biometric of user to a random string


## 2. Preliminaries

### 2.1. Elliptic Curve Diffie–Hellman Problem

Elliptic curve Diffie–Hellman problem (ECDHP):Eq is an elliptic curve group over the prime field Fp. P is a generator of Eq. For given αP,βP, where α,β∈Zq∗, solving αβP is intractable [30].


### 2.2. Adversary Model

In the light of [31], we suppose that the ability of attacker is as below.
(i)
We suppose that the attacker can block, modify, and eavesdrop the message delivered via the public channel(ii)
We suppose that the attacker is able to enumerate all pairs of identity and password subordinate to the dictionary space(iii)
We suppose that the attacker can compromise one type of authentication factor of user, i.e., smart card, password, or biometric(iv)
When evaluating three-factor secrecy, we suppose that the attacker can compromise any two types of authentication factors


## 2.1. Elliptic Curve Diffie–Hellman Problem

Elliptic curve Diffie–Hellman problem (ECDHP):Eq is an elliptic curve group over the prime field Fp. P is a generator of Eq. For given αP,βP, where α,β∈Zq∗, solving αβP is intractable [30].


## 2.2. Adversary Model

In the light of [31], we suppose that the ability of attacker is as below.
(i)
We suppose that the attacker can block, modify, and eavesdrop the message delivered via the public channel(ii)
We suppose that the attacker is able to enumerate all pairs of identity and password subordinate to the dictionary space(iii)
We suppose that the attacker can compromise one type of authentication factor of user, i.e., smart card, password, or biometric(iv)
When evaluating three-factor secrecy, we suppose that the attacker can compromise any two types of authentication factors


## 3. Analysis of Mo Et al.’s Scheme

### 3.1. Review of Mo Et al.’s Scheme

We briefly describe Mo et al.’s two-factor single-server authentication scheme for MCC [28] in this section. To initialize the system, the cloud server CS selects the master key s and calculates the public key PUB=sP.


#### 3.1.1. User Registration Phase

This phase is executed as follows.(Step1)
Ui⟶CS:IDi,Ri. The user Ui selects his identity IDi, password PWi, and a nonce ri and computes Ri=H1ri∥PWi.(Step2)
CS⟶Ui: a smart card. CS picks a nonce Ni and computes Fi=H1H1IDi∥Ni∥Ti∥SCimodv, Ai=Fi⨁Ri, where Ti is the current timestamp, v is an integer from 24,28, and SCi is the smart card identification number. CS stores IDi,Ni,Ti,SCi in the database and stores {Ai,IDS,PUB,v} in a smart card, where IDS is the identity of CS(Step3)
Ui computes Bi=ri⨁H1IDi∥Rimodv and stores Bi in the smart cardThe user Ui selects his identity IDi, password PWi, and a nonce ri and computes Ri=H1ri∥PWi.


#### 3.1.2. Authentication Phase

This phase is comprised of the following steps.(Step1)
Ui⟶CS:PIDi,Ci,Li. Ui enters IDi∗, PWi∗. Then, the smart card computes Ri∗=H1ri∥PWi∗, Bi∗=ri⨁H1IDi∗∥Ri∗modv and checks if Bi∗=Bi. If it holds, the smart card chooses a nonce r1 and computes Ci=r1P, Di=r1PUB, Ei=Ci+Di, Fi=Ai⨁Ri, the dynamic identity PIDi=IDi∗∥Fi⨁H1Ci∥Ei, and Li=H1IDi∗∥Di∥PIDi.(Step2)
CS⟶Ui:M1,M3. CS computes Di=sCi, Ei=Ci+Di, IDi∥Fi=PIDi⨁H1Ci∥Ei, and Li∗=H1IDi∥Di∥PIDi and checks if Li∗=Li. If it does not hold, the protocol aborts. Otherwise, CS retrieves IDi,Ni,Ti,SCi from the database based on IDi and computes Fi∗=H1H1IDi∥Ni∥Ti∥SCimodv and checks if Fi∗=Fi. If they are equal, CS chooses a nonce r2 and computes M1=r2P, M2=r2Ci, the session key SK=H1IDi∥IDS∥Di∥M1∥M2, and M3=H1IDi∥IDS∥Ci∥Di∥M1∥M2.(Step3)
Ui⟶CS:M4. Ui computes M2=r1M1, M3∗=H1IDi∥IDS∥Ci∥Di∥M1∥M2, and checks if M3∗=M3. If they are equal, Ui computes SK=H1IDi∥IDS∥Di∥M1∥M2 and M4=H1IDi∥IDS∥Di∥M2∥SK.(Step4)
CS computesM4∗=H1IDi∥IDS∥Di∥M2∥SK and checks if M4∗=M4. If they are not equal, the protocol abortsUi enters IDi∗, PWi∗. Then, the smart card computes Ri∗=H1ri∥PWi∗, Bi∗=ri⨁H1IDi∗∥Ri∗modv and checks if Bi∗=Bi. If it holds, the smart card chooses a nonce r1 and computes Ci=r1P, Di=r1PUB, Ei=Ci+Di, Fi=Ai⨁Ri, the dynamic identity PIDi=IDi∗∥Fi⨁H1Ci∥Ei, and Li=H1IDi∗∥Di∥PIDi.


#### 3.1.3. Smartcard Revocation Phase

The smart card can be revoked through the following steps.(Step1)
Ui performs step 1 of the authentication phase. Ui sends a revocation request PIDi,Ci,Li,revoke_request to CS(Step2)
CS checks ifLi∗=Li and Fi∗=Fi. If they are equal, CS deletes IDi,Ni,Ti,SCi from the databasePerforms step 1 of the authentication phase. Ui sends a revocation request PIDi,Ci,Li,revoke_request to CSAfter that, the smart card cannot be used to login CS. The user reregisters with CS to get a new smart card.


### 3.2. Weaknesses of Mo Et al.’s Scheme

In this section, we prove that Mo et al.’s scheme is not immune to various attacks.


#### 3.2.1. Stolen-Verifier Attack

In Mo et al.’s scheme, CS stores a tupleIDi,Ni,Ti,SCi for each user Ui. If the attacker compromises CS and retrieves IDi,Ni,Ti,SCi from the database, the attacker can masquerade as the legitimate user through the following steps.
(Step1)
The attacker computesFi=H1H1IDi∥Ni∥Ti∥SCimodv(Step2)
The attacker chooses a noncer1 and computes Ci=r1P, Di=r1PUB, Ei=Ci+Di, PIDi=IDi∥Fi⨁H1Ci∥Ei, Li=H1IDi∥Di∥PIDi. Ui sends PIDi,Ci,Li to CSAsLi∗=Li and Fi∗=Fi, CS regards the attacker as the legitimate user Ui. The essential reason for this attack is that the secret authentication value Fi is merely based on the information stored in verification table, rather than the secret key of CS.


#### 3.2.2. Denial of Service Attack

This attack is performed as follows.(Step1)
The adversary interceptsPIDi,Ci,Li from the public channel(Step2)
The attacker sendsPIDi,Ci,Li,revoke_request to CSAfter receivingPIDi,Ci,Li,revoke_request, as it is valid, CS deletes IDi,Ni,Ti,SCi from the database. After that, the legitimate user Ui is unable to access CS unless reregistration. The essential reason for this attack is that CS does not check the freshness of PIDi,Ci,Li,revoke_request. The attacker can forge a revocation request using the intercepted PIDi,Ci,Li.


#### 3.2.3. Known Session-Specific Temporary Information Attack

Once the attacker compromises the noncer1, he can reveal the session key through the following steps.
(Step1)
The attacker interceptsPIDi,Ci,Li and M1,M3 from the public channel(Step2)
The attacker obtains the user identity by shoulder peeping or computingDi=r1PUB, Ei=Ci+Di, IDi∥Fi=PIDi⨁H1Ci∥Ei(Step3)
The attacker can obtainIDs by compromising user’s smart card or colluding with a user(Step4)
The attacker computesM2=r1M1, SK=H1IDi∥IDS∥Di∥M1∥M2.


#### 3.2.4. Not Applicable to Mobile Cloud Computing

Mo et al.’s scheme adopts single server architecture. Only a single server is used to handle the access requests of users. However, in the MCC environment, a large number of users access the cloud server to obtain a variety of services using mobile devices. It is impracticable for a single server to deal with all the access requests in time. MCC aims at integrating the resources and computing power of multiple distributed servers. As depicted in Figure1, the MCC architecture usually involves multiple distributed servers. In Mo et al.’s scheme, its single-server architecture is not applicable to MCC.


## 3.1. Review of Mo Et al.’s Scheme

We briefly describe Mo et al.’s two-factor single-server authentication scheme for MCC [28] in this section. To initialize the system, the cloud server CS selects the master key s and calculates the public key PUB=sP.


### 3.1.1. User Registration Phase

This phase is executed as follows.(Step1)
Ui⟶CS:IDi,Ri. The user Ui selects his identity IDi, password PWi, and a nonce ri and computes Ri=H1ri∥PWi.(Step2)
CS⟶Ui: a smart card. CS picks a nonce Ni and computes Fi=H1H1IDi∥Ni∥Ti∥SCimodv, Ai=Fi⨁Ri, where Ti is the current timestamp, v is an integer from 24,28, and SCi is the smart card identification number. CS stores IDi,Ni,Ti,SCi in the database and stores {Ai,IDS,PUB,v} in a smart card, where IDS is the identity of CS(Step3)
Ui computes Bi=ri⨁H1IDi∥Rimodv and stores Bi in the smart cardThe user Ui selects his identity IDi, password PWi, and a nonce ri and computes Ri=H1ri∥PWi.


### 3.1.2. Authentication Phase

This phase is comprised of the following steps.(Step1)
Ui⟶CS:PIDi,Ci,Li. Ui enters IDi∗, PWi∗. Then, the smart card computes Ri∗=H1ri∥PWi∗, Bi∗=ri⨁H1IDi∗∥Ri∗modv and checks if Bi∗=Bi. If it holds, the smart card chooses a nonce r1 and computes Ci=r1P, Di=r1PUB, Ei=Ci+Di, Fi=Ai⨁Ri, the dynamic identity PIDi=IDi∗∥Fi⨁H1Ci∥Ei, and Li=H1IDi∗∥Di∥PIDi.(Step2)
CS⟶Ui:M1,M3. CS computes Di=sCi, Ei=Ci+Di, IDi∥Fi=PIDi⨁H1Ci∥Ei, and Li∗=H1IDi∥Di∥PIDi and checks if Li∗=Li. If it does not hold, the protocol aborts. Otherwise, CS retrieves IDi,Ni,Ti,SCi from the database based on IDi and computes Fi∗=H1H1IDi∥Ni∥Ti∥SCimodv and checks if Fi∗=Fi. If they are equal, CS chooses a nonce r2 and computes M1=r2P, M2=r2Ci, the session key SK=H1IDi∥IDS∥Di∥M1∥M2, and M3=H1IDi∥IDS∥Ci∥Di∥M1∥M2.(Step3)
Ui⟶CS:M4. Ui computes M2=r1M1, M3∗=H1IDi∥IDS∥Ci∥Di∥M1∥M2, and checks if M3∗=M3. If they are equal, Ui computes SK=H1IDi∥IDS∥Di∥M1∥M2 and M4=H1IDi∥IDS∥Di∥M2∥SK.(Step4)
CS computesM4∗=H1IDi∥IDS∥Di∥M2∥SK and checks if M4∗=M4. If they are not equal, the protocol abortsUi enters IDi∗, PWi∗. Then, the smart card computes Ri∗=H1ri∥PWi∗, Bi∗=ri⨁H1IDi∗∥Ri∗modv and checks if Bi∗=Bi. If it holds, the smart card chooses a nonce r1 and computes Ci=r1P, Di=r1PUB, Ei=Ci+Di, Fi=Ai⨁Ri, the dynamic identity PIDi=IDi∗∥Fi⨁H1Ci∥Ei, and Li=H1IDi∗∥Di∥PIDi.


### 3.1.3. Smartcard Revocation Phase

The smart card can be revoked through the following steps.(Step1)
Ui performs step 1 of the authentication phase. Ui sends a revocation request PIDi,Ci,Li,revoke_request to CS(Step2)
CS checks ifLi∗=Li and Fi∗=Fi. If they are equal, CS deletes IDi,Ni,Ti,SCi from the databasePerforms step 1 of the authentication phase. Ui sends a revocation request PIDi,Ci,Li,revoke_request to CSAfter that, the smart card cannot be used to login CS. The user reregisters with CS to get a new smart card.


## 3.1.1. User Registration Phase

This phase is executed as follows.(Step1)
Ui⟶CS:IDi,Ri. The user Ui selects his identity IDi, password PWi, and a nonce ri and computes Ri=H1ri∥PWi.(Step2)
CS⟶Ui: a smart card. CS picks a nonce Ni and computes Fi=H1H1IDi∥Ni∥Ti∥SCimodv, Ai=Fi⨁Ri, where Ti is the current timestamp, v is an integer from 24,28, and SCi is the smart card identification number. CS stores IDi,Ni,Ti,SCi in the database and stores {Ai,IDS,PUB,v} in a smart card, where IDS is the identity of CS(Step3)
Ui computes Bi=ri⨁H1IDi∥Rimodv and stores Bi in the smart cardThe user Ui selects his identity IDi, password PWi, and a nonce ri and computes Ri=H1ri∥PWi.


## 3.1.2. Authentication Phase

This phase is comprised of the following steps.(Step1)
Ui⟶CS:PIDi,Ci,Li. Ui enters IDi∗, PWi∗. Then, the smart card computes Ri∗=H1ri∥PWi∗, Bi∗=ri⨁H1IDi∗∥Ri∗modv and checks if Bi∗=Bi. If it holds, the smart card chooses a nonce r1 and computes Ci=r1P, Di=r1PUB, Ei=Ci+Di, Fi=Ai⨁Ri, the dynamic identity PIDi=IDi∗∥Fi⨁H1Ci∥Ei, and Li=H1IDi∗∥Di∥PIDi.(Step2)
CS⟶Ui:M1,M3. CS computes Di=sCi, Ei=Ci+Di, IDi∥Fi=PIDi⨁H1Ci∥Ei, and Li∗=H1IDi∥Di∥PIDi and checks if Li∗=Li. If it does not hold, the protocol aborts. Otherwise, CS retrieves IDi,Ni,Ti,SCi from the database based on IDi and computes Fi∗=H1H1IDi∥Ni∥Ti∥SCimodv and checks if Fi∗=Fi. If they are equal, CS chooses a nonce r2 and computes M1=r2P, M2=r2Ci, the session key SK=H1IDi∥IDS∥Di∥M1∥M2, and M3=H1IDi∥IDS∥Ci∥Di∥M1∥M2.(Step3)
Ui⟶CS:M4. Ui computes M2=r1M1, M3∗=H1IDi∥IDS∥Ci∥Di∥M1∥M2, and checks if M3∗=M3. If they are equal, Ui computes SK=H1IDi∥IDS∥Di∥M1∥M2 and M4=H1IDi∥IDS∥Di∥M2∥SK.(Step4)
CS computesM4∗=H1IDi∥IDS∥Di∥M2∥SK and checks if M4∗=M4. If they are not equal, the protocol abortsUi enters IDi∗, PWi∗. Then, the smart card computes Ri∗=H1ri∥PWi∗, Bi∗=ri⨁H1IDi∗∥Ri∗modv and checks if Bi∗=Bi. If it holds, the smart card chooses a nonce r1 and computes Ci=r1P, Di=r1PUB, Ei=Ci+Di, Fi=Ai⨁Ri, the dynamic identity PIDi=IDi∗∥Fi⨁H1Ci∥Ei, and Li=H1IDi∗∥Di∥PIDi.


## 3.1.3. Smartcard Revocation Phase

The smart card can be revoked through the following steps.(Step1)
Ui performs step 1 of the authentication phase. Ui sends a revocation request PIDi,Ci,Li,revoke_request to CS(Step2)
CS checks ifLi∗=Li and Fi∗=Fi. If they are equal, CS deletes IDi,Ni,Ti,SCi from the databasePerforms step 1 of the authentication phase. Ui sends a revocation request PIDi,Ci,Li,revoke_request to CSAfter that, the smart card cannot be used to login CS. The user reregisters with CS to get a new smart card.


## 3.2. Weaknesses of Mo Et al.’s Scheme

In this section, we prove that Mo et al.’s scheme is not immune to various attacks.


### 3.2.1. Stolen-Verifier Attack

In Mo et al.’s scheme, CS stores a tupleIDi,Ni,Ti,SCi for each user Ui. If the attacker compromises CS and retrieves IDi,Ni,Ti,SCi from the database, the attacker can masquerade as the legitimate user through the following steps.
(Step1)
The attacker computesFi=H1H1IDi∥Ni∥Ti∥SCimodv(Step2)
The attacker chooses a noncer1 and computes Ci=r1P, Di=r1PUB, Ei=Ci+Di, PIDi=IDi∥Fi⨁H1Ci∥Ei, Li=H1IDi∥Di∥PIDi. Ui sends PIDi,Ci,Li to CSAsLi∗=Li and Fi∗=Fi, CS regards the attacker as the legitimate user Ui. The essential reason for this attack is that the secret authentication value Fi is merely based on the information stored in verification table, rather than the secret key of CS.


### 3.2.2. Denial of Service Attack

This attack is performed as follows.(Step1)
The adversary interceptsPIDi,Ci,Li from the public channel(Step2)
The attacker sendsPIDi,Ci,Li,revoke_request to CSAfter receivingPIDi,Ci,Li,revoke_request, as it is valid, CS deletes IDi,Ni,Ti,SCi from the database. After that, the legitimate user Ui is unable to access CS unless reregistration. The essential reason for this attack is that CS does not check the freshness of PIDi,Ci,Li,revoke_request. The attacker can forge a revocation request using the intercepted PIDi,Ci,Li.


### 3.2.3. Known Session-Specific Temporary Information Attack

Once the attacker compromises the noncer1, he can reveal the session key through the following steps.
(Step1)
The attacker interceptsPIDi,Ci,Li and M1,M3 from the public channel(Step2)
The attacker obtains the user identity by shoulder peeping or computingDi=r1PUB, Ei=Ci+Di, IDi∥Fi=PIDi⨁H1Ci∥Ei(Step3)
The attacker can obtainIDs by compromising user’s smart card or colluding with a user(Step4)
The attacker computesM2=r1M1, SK=H1IDi∥IDS∥Di∥M1∥M2.


### 3.2.4. Not Applicable to Mobile Cloud Computing

Mo et al.’s scheme adopts single server architecture. Only a single server is used to handle the access requests of users. However, in the MCC environment, a large number of users access the cloud server to obtain a variety of services using mobile devices. It is impracticable for a single server to deal with all the access requests in time. MCC aims at integrating the resources and computing power of multiple distributed servers. As depicted in Figure1, the MCC architecture usually involves multiple distributed servers. In Mo et al.’s scheme, its single-server architecture is not applicable to MCC.


## 3.2.1. Stolen-Verifier Attack

In Mo et al.’s scheme, CS stores a tupleIDi,Ni,Ti,SCi for each user Ui. If the attacker compromises CS and retrieves IDi,Ni,Ti,SCi from the database, the attacker can masquerade as the legitimate user through the following steps.
(Step1)
The attacker computesFi=H1H1IDi∥Ni∥Ti∥SCimodv(Step2)
The attacker chooses a noncer1 and computes Ci=r1P, Di=r1PUB, Ei=Ci+Di, PIDi=IDi∥Fi⨁H1Ci∥Ei, Li=H1IDi∥Di∥PIDi. Ui sends PIDi,Ci,Li to CSAsLi∗=Li and Fi∗=Fi, CS regards the attacker as the legitimate user Ui. The essential reason for this attack is that the secret authentication value Fi is merely based on the information stored in verification table, rather than the secret key of CS.


## 3.2.2. Denial of Service Attack

This attack is performed as follows.(Step1)
The adversary interceptsPIDi,Ci,Li from the public channel(Step2)
The attacker sendsPIDi,Ci,Li,revoke_request to CSAfter receivingPIDi,Ci,Li,revoke_request, as it is valid, CS deletes IDi,Ni,Ti,SCi from the database. After that, the legitimate user Ui is unable to access CS unless reregistration. The essential reason for this attack is that CS does not check the freshness of PIDi,Ci,Li,revoke_request. The attacker can forge a revocation request using the intercepted PIDi,Ci,Li.


## 3.2.3. Known Session-Specific Temporary Information Attack

Once the attacker compromises the noncer1, he can reveal the session key through the following steps.
(Step1)
The attacker interceptsPIDi,Ci,Li and M1,M3 from the public channel(Step2)
The attacker obtains the user identity by shoulder peeping or computingDi=r1PUB, Ei=Ci+Di, IDi∥Fi=PIDi⨁H1Ci∥Ei(Step3)
The attacker can obtainIDs by compromising user’s smart card or colluding with a user(Step4)
The attacker computesM2=r1M1, SK=H1IDi∥IDS∥Di∥M1∥M2.


## 3.2.4. Not Applicable to Mobile Cloud Computing

Mo et al.’s scheme adopts single server architecture. Only a single server is used to handle the access requests of users. However, in the MCC environment, a large number of users access the cloud server to obtain a variety of services using mobile devices. It is impracticable for a single server to deal with all the access requests in time. MCC aims at integrating the resources and computing power of multiple distributed servers. As depicted in Figure1, the MCC architecture usually involves multiple distributed servers. In Mo et al.’s scheme, its single-server architecture is not applicable to MCC.


## 4. The Proposed Scheme

In this section, we put forward an ECC-based three-factor authentication scheme for MCC. It includes three kinds of participants, i.e., the registration center RC, the cloud serverCSj, and the user Ui. As a trusted third party, RC is responsible for issuing the secret key to users and cloud servers in the registration phase. In the authentication phase, RC is offline. Ui and CSj implement mutual authentication and negotiate a session key without the registration center involved.


### 4.1. Predeployment Phase

RC selects an elliptic curve groupEq over the prime field Fp. P is a generator of Eq. RC selects the master key s. RC chooses a secure hash function H1 and a biohashing function H2. RC publishes the parameters Eq,P.


### 4.2. User Registration Phase

This phase is depicted as Figure2.
(Step1)
The userUi chooses his identity IDi and password PWi, imprints his biometric bi, and computes RPWi=H1IDi∥PWi∥H2bi∥yi, where yi is a nonce. Ui delivers the message {IDi,RPWi} to RC via the reliable channel(Step2)
After getting {IDi,RPWi}, RC computes Ui’s private key di=H1IDi∥s∥RPWi and public key PUBi=diP, Wi=di⨁RPWi, Zi=H1RPWimodv. RC chooses an integer v∈24,28. RC stores the parameters {Wi,Zi,v} in a smart card and publishes Ui’s public key {IDi,PUBi}. RC issues the smart card to Ui in a credible manner(Step3)
Ui saves yi in the smart cardFigure 2
User registration phase of the proposed scheme.


### 4.3. Cloud Server Registration Phase

This phase is depicted as Figure3.
(Step1)
The cloud serverCSj delivers his identity SIDj to RC via the reliable channel(Step2)
Upon getting {SIDj}, RC computes CSj’s private key kj=H1SIDj∥s and public key PUBj=kjP. RC publishes the parameters {SIDj,PUBj}. RC issues {kj} to CSj in a credible mannerFigure 3
Cloud server registration phase of the proposed scheme.


### 4.4. Authentication Phase

This phase is depicted as Figure4.
(Step1)
Ui enters IDi∗ and PWi∗ and imprints bi∗. The smart card computes RPWi∗=H1IDi∗∥PWi∗∥H2bi∗∥yi, Zi∗=H1RPWi∗modv, and checks if Zi∗=Zi. If they are equal, the smart card chooses two random numbers r1 and r2 and computes di=Wi⊕RPWi∗, Ai=r1P, Bi=r1PUBj, Ni=r2P, Ci=H1Ai∥IDi∥Ni, Di=r1+diCi, Ei=Bi⨁IDi∥Di∥Ni. Ui sends the message Ai,Ni,Ei to CSj via the public channel(Step2)
Upon receivingAi,Ni,Ei, CSj computes Bi=kjAi, IDi∥Di∥Ni=Ei⨁Bi, Ci=H1Ai∥IDi∥Ni and checks if DiP=Ai+Ci∙PUBi. If it holds, CSj chooses a random number r3 and computes Fi=r3P, the session keySK=H1r3Ni∥Di, Li=H1SK∥Fi. CSj sends Fi,Li to Ui(Step3)
After receivingFi,Li, the smart card computes SK=H1r2Fi∥Di, Li∗=H1SK∥Fi and verifies if Li∗=Li. If so, the smart card computes Mi=H1SK∥Bi. Ui sends Mi to CSj(Step4)
Upon gettingMi, CSj computes Mi∗=H1SK∥Bi and checks if Mi∗=Mi. If they are equal, CSj and Ui achieve mutual authentication and establish a session key SKFigure 4
Authentication phase of the proposed scheme.


### 4.5. Smart Card Revocation Phase

If user’s smart card is lost or stolen, the user suspects that the data of smart card is leaked. The user reregisters with RC. RC publishes user’s new public key information {IDi,PUBinew} and issues a new smart card to Ui. Afterwards, the user’s old smart card is unable to be used to login any cloud server.


### 4.6. Password and Biometric Update Phase

This phase is executed as follows.(Step1)
Ui inputs IDi∗ and PWi∗ and imprints bi∗. The smart card computes RPWi∗=H1IDi∗∥PWi∗∥H2bi∗∥yi, Zi∗=H1RPWi∗modv and checks if Zi∗=Zi. If they are equal, ask the user to input his new password and imprint his new biometric(Step2)
The smart card chooses a new nonceyinew and computes RPWinew=H1IDi∗∥PWinew∥H2binew∥yinew, Zinew=H1RPWinewmodv, and Winew=Wi⊕RPWi∗⊕RPWinew. The smart card saves Winew,Zinew and deletes Wi,ZiUi inputs IDi∗ and PWi∗ and imprints bi∗. The smart card computes RPWi∗=H1IDi∗∥PWi∗∥H2bi∗∥yi, Zi∗=H1RPWi∗modv and checks if Zi∗=Zi. If they are equal, ask the user to input his new password and imprint his new biometric


## 4.1. Predeployment Phase

RC selects an elliptic curve groupEq over the prime field Fp. P is a generator of Eq. RC selects the master key s. RC chooses a secure hash function H1 and a biohashing function H2. RC publishes the parameters Eq,P.


## 4.2. User Registration Phase

This phase is depicted as Figure2.
(Step1)
The userUi chooses his identity IDi and password PWi, imprints his biometric bi, and computes RPWi=H1IDi∥PWi∥H2bi∥yi, where yi is a nonce. Ui delivers the message {IDi,RPWi} to RC via the reliable channel(Step2)
After getting {IDi,RPWi}, RC computes Ui’s private key di=H1IDi∥s∥RPWi and public key PUBi=diP, Wi=di⨁RPWi, Zi=H1RPWimodv. RC chooses an integer v∈24,28. RC stores the parameters {Wi,Zi,v} in a smart card and publishes Ui’s public key {IDi,PUBi}. RC issues the smart card to Ui in a credible manner(Step3)
Ui saves yi in the smart cardFigure 2
User registration phase of the proposed scheme.


## 4.3. Cloud Server Registration Phase

This phase is depicted as Figure3.
(Step1)
The cloud serverCSj delivers his identity SIDj to RC via the reliable channel(Step2)
Upon getting {SIDj}, RC computes CSj’s private key kj=H1SIDj∥s and public key PUBj=kjP. RC publishes the parameters {SIDj,PUBj}. RC issues {kj} to CSj in a credible mannerFigure 3
Cloud server registration phase of the proposed scheme.


## 4.4. Authentication Phase

This phase is depicted as Figure4.
(Step1)
Ui enters IDi∗ and PWi∗ and imprints bi∗. The smart card computes RPWi∗=H1IDi∗∥PWi∗∥H2bi∗∥yi, Zi∗=H1RPWi∗modv, and checks if Zi∗=Zi. If they are equal, the smart card chooses two random numbers r1 and r2 and computes di=Wi⊕RPWi∗, Ai=r1P, Bi=r1PUBj, Ni=r2P, Ci=H1Ai∥IDi∥Ni, Di=r1+diCi, Ei=Bi⨁IDi∥Di∥Ni. Ui sends the message Ai,Ni,Ei to CSj via the public channel(Step2)
Upon receivingAi,Ni,Ei, CSj computes Bi=kjAi, IDi∥Di∥Ni=Ei⨁Bi, Ci=H1Ai∥IDi∥Ni and checks if DiP=Ai+Ci∙PUBi. If it holds, CSj chooses a random number r3 and computes Fi=r3P, the session keySK=H1r3Ni∥Di, Li=H1SK∥Fi. CSj sends Fi,Li to Ui(Step3)
After receivingFi,Li, the smart card computes SK=H1r2Fi∥Di, Li∗=H1SK∥Fi and verifies if Li∗=Li. If so, the smart card computes Mi=H1SK∥Bi. Ui sends Mi to CSj(Step4)
Upon gettingMi, CSj computes Mi∗=H1SK∥Bi and checks if Mi∗=Mi. If they are equal, CSj and Ui achieve mutual authentication and establish a session key SKFigure 4
Authentication phase of the proposed scheme.


## 4.5. Smart Card Revocation Phase

If user’s smart card is lost or stolen, the user suspects that the data of smart card is leaked. The user reregisters with RC. RC publishes user’s new public key information {IDi,PUBinew} and issues a new smart card to Ui. Afterwards, the user’s old smart card is unable to be used to login any cloud server.


## 4.6. Password and Biometric Update Phase

This phase is executed as follows.(Step1)
Ui inputs IDi∗ and PWi∗ and imprints bi∗. The smart card computes RPWi∗=H1IDi∗∥PWi∗∥H2bi∗∥yi, Zi∗=H1RPWi∗modv and checks if Zi∗=Zi. If they are equal, ask the user to input his new password and imprint his new biometric(Step2)
The smart card chooses a new nonceyinew and computes RPWinew=H1IDi∗∥PWinew∥H2binew∥yinew, Zinew=H1RPWinewmodv, and Winew=Wi⊕RPWi∗⊕RPWinew. The smart card saves Winew,Zinew and deletes Wi,ZiUi inputs IDi∗ and PWi∗ and imprints bi∗. The smart card computes RPWi∗=H1IDi∗∥PWi∗∥H2bi∗∥yi, Zi∗=H1RPWi∗modv and checks if Zi∗=Zi. If they are equal, ask the user to input his new password and imprint his new biometric


## 5. Security Analysis

In this section, we prove the security of the proposed scheme by using the following security analysis methods.


### 5.1. BAN Logic Proof

In this section, we show that the proposed scheme preserves mutual authentication and session key agreement by using BAN logic proof. We present the notations and rules of BAN logic [32] in Table 2.Table 2
The notations and rules of BAN logic.
SymbolsDescriptionP, QA principalXA statement#XX is freshP⊲XP gets XP∣∼XX is sent by PP∣≡XP believes XP↔KQP and Q have a common secret KXKX is encrypted under K→KPK is the public key of PP⇒XP has jurisdiction over X<X>KX is merged with KMessage meaning rule (rule 1)P∣≡P↔KQ,P⊲<X>KP∣≡Q∣∼X or P∣≡→KQ,P⊲XK−1P∣≡Q∣∼XNonce-verification rule (rule 2)P∣≡#X,P∣≡Q∣∼XP∣≡Q∣≡XJurisdiction rule (rule 3)P∣≡Q⇒X,P∣≡Q∣≡XP∣≡XThe proposed scheme should be able to achieve the following goals.G1:Ui∣≡CSj∣≡Ui↔SKCSjG2:Ui∣≡Ui↔SKCSjG3:CSj∣≡Ui∣≡Ui↔SKCSjG4:CSj∣≡Ui↔SKCSjThe proposed scheme is idealized as below.M1:Ui→CSjDi=IDi,r1P,r2Pdi,r2PBiM2:CSj→Ui<Ui↔SKCSj,r3P>DiM3:Ui→CSj<Ui↔SKCSj,r1P>BiThe initial assumptions of the proposed scheme are as below.A1:CSj≡Ui↔BiCSjA2:CSj≡→PUBiUiA3:CSj≡#r1PA4:CSj≡Ui⇒r2PA5:Ui≡Ui↔DiCSjA6:Ui≡#r3PA7:Ui≡CSj⇒Ui↔SKCSjA8:CSj≡Ui⇒Ui↔SKCSjThe proof is as follows.From M1, we have(1)CSj⊲Di,r2PBiApply Rule 1 to (1) and A1, we have(2)CSj≡Ui∼Di,r2PFrom (2), we have(3)CSj≡Ui∼DiIDi,r1P,r2PdiApply Rule 1 to (3) and A2, we have(4)CSj≡Ui∼IDi,r1P,r2PApply Rule 2 to (4) and A3, we have(5)CSj≡Ui≡IDi,r2PApply Rule 3 to (5) and A4, we have(6)CSj≡r2PFrom M2, we have(7)Ui⊲<Ui↔SKCSj,r3P>DiApply Rule 1 to (7) and A5, we have(8)Ui≡CSj∼Ui↔SKCSj,r3PApply Rule 2 to (8) and A6, we have(9)Ui≡CSj≡Ui↔SKCSj(G1)Apply Rule 3 to (9) and A7, we have(10)Ui≡Ui↔SKCSj(G2)From M3, we have(11)CSj⊲<Ui↔SKCSj,r1P>BiApply Rule1 to (11) and A1, we have(12)CSj≡Ui∼Ui↔SKCSj,r1PApply Rule 2 to (14) and A3, we have(13)CSj≡Ui≡Ui↔SKCSj(G3)Apply Rule 3 to (15) and A8, we have(14)CSj≡Ui↔SKCSj(G4)


### 5.2. Formal Security Analysis

In this section, we show that the proposed scheme is provably secure under the security model introduced in [33].


#### 5.2.1. Security Model

(1) Participants. The proposed scheme involves three kinds of participants, i.e., the registration center RC, the cloud server CSj, and the user Ui. RCa,CSja, and Uia are the a-th instances of RC, CSj, and Ui, respectively.(2) Queries. The adversary capability is simulated through the following queries.Execute (CSja/Uia). It simulates the passive attack. It returns back the transcript of messages to the adversary.Send (CSja/Uia,m). It simulates the active attack. The adversary masquerades as the instance CSja/Uia by sending a message m. The oracle processes m and returns a response to the adversary.Reveal (CSja/Uia). It returns back CSja/Uia’s session key to the adversary.Corrupt (Uia,z). It returns back one or two kinds of user authentication factors to the adversary.Ifz=1, it returns back the password.Ifz=2, it returns back the data of smart card.Ifz=3, it returns back the biometric.Corrupt (RCa/CSja). It simulates forward secrecy. The oracle returns back the master key of RCa or the private key of CSja to the adversary.Test (CSja/Uia). It simulates the semantic security of the session key, If the instance CSja/Uia is accepted by its partner and establishes a session key SK, and the adversary never makes Corrupt (RCa/CSja) or Reveal (CSja/Uia) query, we say the instance CSja/Uia is fresh. If CSja/Uia is fresh, the oracle tosses a coin b. If b=1, it answers SK. Otherwise, it chooses an equal-length string and sends it to the adversary. The adversary is allowed to make this query no more than once.(3) Semantic Security. After receiving the answer from Test (CSja/Uia) query, the adversary tries to reveal the value of b. We define the advantage that adversary breaks the semantic security of the proposed scheme as
(1)AdvPakeA=2Prb′=b−1.IfAdvPakeA is negligible, the proposed scheme achieves semantic security.


#### 5.2.2. Security Analysis

Theorem 1.
As demonstrated in [34], the password distribution follows Zipf’s law. DPW denotes the password dictionary space. C′ and s′ are parameters of the Zipf distribution. AdvPECDHP denotes the advantage that the adversary A solves ECDHP. The adversary A can make at most qe Execute queries, qs Send queries, qh Hash queries, and qb Biohashing queries in polynomial time t. We have
(2)AdvPakeA≤2C′∗qss′+qs+qe2p+6qs+qh22l1+2qs+qb22l2+2qhAdvPECDHP,
wherel1 is the length of the hash value, and l2 is the length of the biohashing value, in terms of the Tianya password dictionary [35] of size DPW≈13million, C′=0.062239, s′=0.155478.Proof. The security of the proposed scheme is demonstrated through a series of gamesΦi (0≤i≤6), and Prχi denotes the advantage that A guesses b in Φi.Φ0: this game represents the real attack. Hence,
(3)AdvPakeA=2Prχ0−1.Φ1: the hash oracle and biohashing oracle are simulated by setting up two lists ΛH and ΛBH. For a Hash query H1τ, the oracle uses τ to search ΛH. If an item (τ,γ) is found, it sends back γ to the adversary. Otherwise, it returns a random number γ to the adversary and adds a new item (τ,γ) to ΛH. The biohashing oracle is simulated in the same way. There is no difference between Φ1 and Φ0. Hence,
(4)Prχ1−Prχ0=0.Φ2: This game is terminated when some collisions occur.
(1)
A collision appears in random numbers. The probability is no more thanqs+qe2/2p(2)
A collision appears in hash values or biohashing values. The probability is no more thanqh2/2l1+1+qb2/2l2+1Hence,(5)Prχ2−Prχ1≤qh22l1+1+qb22l2+1+qs+qe22p.Φ3: we abort the game when A has guessed (Di,Li,Mi). Its advantage is no more than qs/2l1. Hence,
(6)Prχ3−Prχ2≤qs/2l1.Φ4: we abort the game when A has guessed user’s secret key di. Its advantage is no more than qs/2l1. Hence,
(7)Prχ4−Prχ3≤qs/2l1.Φ5: we abort the game when A has computed di having the aid of Corrupt (Uia,z) query.
(1)
IfA has obtained user’s password and biometric, he is able to reveal the key parameter Wi with probability qs/2l1(2)
IfA has obtained user’s password and the data of smart card, he is able to reveal the biometric with probability qs/2l2(3)
IfA has obtained user’s biometric and the data of smart card, he is able to reveal the password with probability C′∗qss′Hence,(8)Prχ5−Prχ4≤qs/2l2+C′∗qss′+qs/2l1.Φ6: in this game, the hash oracle H1 is replaced by the private hash oracle H1′ to calculate the session key. H1′ is unavailable to A. Hence,
(9)Prχ6=12.Φ6 has no difference with Φ5, unless A has asked Hash query H1r3Ni∥Di. This event is denoted by Γ1. Hence,
(10)Prχ6−Prχ5≤PrΓ1.IfA has asked Hash query H1r3Ni∥Di, when picking an item from ΛH, we can get a solution of ECDHP with probability 1/qh. Hence,
(11)PrΓ1≤qhAdvPECDHP.From (3)–(11), we have
(12)AdvPakeA≤2C′∗qss′+qs+qe2p+6qs+qh22l1+2qs+qb22l2+2qhAdvPECDHP.


### 5.3. Further Security Analysis

This section demonstrates that the proposed scheme is immune to known attacks and provides various desirable security properties.


#### 5.3.1. Mutual Authentication

In our scheme, the cloud server authenticates the user by checking ifDiP=Ai+Ci∙PUBi. Di is a signature calculated based on user private key di. Only the user Ui who has the private key di can calculate a valid Di. In addition, the user validates the cloud server by checking if Li∗=Li. Actually, the user authenticates the cloud server based on Bi=r1PUBj=kjAi. In the login request, Di is encrypted under the key Bi. Except the user Ui, only the cloud server CSj who has the secret key kj can compute Bi and retrieve Di from Ei and generate a valid authenticate value Li.


#### 5.3.2. Session Key Agreement

The user and the cloud server generate a session keySK=H1r3r2P∥Di. The session key is composed of r3r2P and Di. r3r2P is generated using elliptic curve Diffie-Hellman key exchange, and it guarantees forward secrecy. Di is generated based on user’s private key, and it guarantees the resistance of session-specific temporary information attack.


#### 5.3.3. User Anonymity

In our scheme, the user identity is encrypted under the keyBi. As ECDHP is intractable, only the user who knows the random number r1 and the cloud server who has the secret key kj can retrieve IDi from Ei. Additionally, the random numbers r1 and r2 are involved in the login request {Ai,Ei}. The login requests are different in each session. Thus, the proposed scheme preserves user untraceability.


#### 5.3.4. Offline RC

In the authentication phase, the user and the cloud server can perform mutual authentication and session key agreement without the aid of RC. It reduces the number of interacted messages. Correspondingly, it helps to reduce communication and computing overheads.


#### 5.3.5. Forward Secrecy

The session key is computed based onSK=H1r3r2P∥Di∥r3PUBi. r3r2P is generated using Diffie-Hellman key exchange. Due to the intractability of ECDHP, even the attacker obtains the long-term secret, he is unable to retrieve r3r2P from Fi and Ni. The proposed scheme preserves forward secrecy.


#### 5.3.6. Resist Session-Specific Temporary Information Attack

Suppose that the random numbersr2 is compromised. The adversary computes r3Fi. However, as Bi is unavailable, the adversary cannot obtain Di.Suppose that the random numberr3 is compromised. The adversary cannot obtain Ni and Di, as Bi is unavailable. The adversary can neither obtain Di or r3Ni.As a result, the adversary cannot reveal the session key when the random number is compromised.


#### 5.3.7. Resist Forgery Attack

In our scheme, the user computes the signatureDi based on the private key di to authenticate the message Ai,Ei,Ni. Afterwards, the cloud server uses the shared session key SK to authenticate the message Fi,Li. Finally, the user uses the shared session key SK to authenticate the message Mi. As the secret key di and SK are unavailable, the adversary cannot produce a valid message.


#### 5.3.8. Resist Replay Attack

In the proposed scheme, the cloud server authenticates the user by checking the validity of the messagesAi,Ei,Ni and Mi. If the adversary replays Ai,Ei,Ni, as he cannot produce a valid Mi, ultimately, the authentication fails. If the adversary replays Fi,Li and Mi, as the random numbers selected in each session are different, the authentication fails. Hence, the proposed scheme can resist replay attack.


#### 5.3.9. Resist Insider Attack

The user cannot impersonate the cloud server without cloud server’s private key. Similarly, the cloud server cannot impersonate the user without user’s private key. The other users cannot pretend to be the userUi, as he cannot generate a valid signature of Ui. The other cloud servers cannot pretend to be the cloud server CSj, as he cannot decrypt Ei to get Di. Our scheme is resistance to insider attack.


#### 5.3.10. User Friendliness

The proposed scheme provides user friendliness. Firstly, the proposed scheme adopts multiserver architecture. The user only needs to register once to access multiple servers. Secondly, in the authentication phase, the registration center is offline, and the user can access the cloud server directly without interacting with the registration center. Thirdly, the proposed scheme supports smartcard revocation, efficiency for wrong password and biometric detection, and password and biometric update.


#### 5.3.11. Three-Factor Secrecy

The fuzzy verificationZi makes our scheme that is immune to offline guessing attack. Even if the adversary compromises two kinds of authentication factors, the other one is still unavailable. In addition, for the adversary, the only way to retrieve di is to break the password, the biometric, and the smart card at the same time. Without di, the adversary cannot impersonate the user. Hence, the proposed scheme preserves three-factor secrecy.


## 5.1. BAN Logic Proof

In this section, we show that the proposed scheme preserves mutual authentication and session key agreement by using BAN logic proof. We present the notations and rules of BAN logic [32] in Table 2.Table 2
The notations and rules of BAN logic.
SymbolsDescriptionP, QA principalXA statement#XX is freshP⊲XP gets XP∣∼XX is sent by PP∣≡XP believes XP↔KQP and Q have a common secret KXKX is encrypted under K→KPK is the public key of PP⇒XP has jurisdiction over X<X>KX is merged with KMessage meaning rule (rule 1)P∣≡P↔KQ,P⊲<X>KP∣≡Q∣∼X or P∣≡→KQ,P⊲XK−1P∣≡Q∣∼XNonce-verification rule (rule 2)P∣≡#X,P∣≡Q∣∼XP∣≡Q∣≡XJurisdiction rule (rule 3)P∣≡Q⇒X,P∣≡Q∣≡XP∣≡XThe proposed scheme should be able to achieve the following goals.G1:Ui∣≡CSj∣≡Ui↔SKCSjG2:Ui∣≡Ui↔SKCSjG3:CSj∣≡Ui∣≡Ui↔SKCSjG4:CSj∣≡Ui↔SKCSjThe proposed scheme is idealized as below.M1:Ui→CSjDi=IDi,r1P,r2Pdi,r2PBiM2:CSj→Ui<Ui↔SKCSj,r3P>DiM3:Ui→CSj<Ui↔SKCSj,r1P>BiThe initial assumptions of the proposed scheme are as below.A1:CSj≡Ui↔BiCSjA2:CSj≡→PUBiUiA3:CSj≡#r1PA4:CSj≡Ui⇒r2PA5:Ui≡Ui↔DiCSjA6:Ui≡#r3PA7:Ui≡CSj⇒Ui↔SKCSjA8:CSj≡Ui⇒Ui↔SKCSjThe proof is as follows.From M1, we have(1)CSj⊲Di,r2PBiApply Rule 1 to (1) and A1, we have(2)CSj≡Ui∼Di,r2PFrom (2), we have(3)CSj≡Ui∼DiIDi,r1P,r2PdiApply Rule 1 to (3) and A2, we have(4)CSj≡Ui∼IDi,r1P,r2PApply Rule 2 to (4) and A3, we have(5)CSj≡Ui≡IDi,r2PApply Rule 3 to (5) and A4, we have(6)CSj≡r2PFrom M2, we have(7)Ui⊲<Ui↔SKCSj,r3P>DiApply Rule 1 to (7) and A5, we have(8)Ui≡CSj∼Ui↔SKCSj,r3PApply Rule 2 to (8) and A6, we have(9)Ui≡CSj≡Ui↔SKCSj(G1)Apply Rule 3 to (9) and A7, we have(10)Ui≡Ui↔SKCSj(G2)From M3, we have(11)CSj⊲<Ui↔SKCSj,r1P>BiApply Rule1 to (11) and A1, we have(12)CSj≡Ui∼Ui↔SKCSj,r1PApply Rule 2 to (14) and A3, we have(13)CSj≡Ui≡Ui↔SKCSj(G3)Apply Rule 3 to (15) and A8, we have(14)CSj≡Ui↔SKCSj(G4)


## 5.2. Formal Security Analysis

In this section, we show that the proposed scheme is provably secure under the security model introduced in [33].


### 5.2.1. Security Model

(1) Participants. The proposed scheme involves three kinds of participants, i.e., the registration center RC, the cloud server CSj, and the user Ui. RCa,CSja, and Uia are the a-th instances of RC, CSj, and Ui, respectively.(2) Queries. The adversary capability is simulated through the following queries.Execute (CSja/Uia). It simulates the passive attack. It returns back the transcript of messages to the adversary.Send (CSja/Uia,m). It simulates the active attack. The adversary masquerades as the instance CSja/Uia by sending a message m. The oracle processes m and returns a response to the adversary.Reveal (CSja/Uia). It returns back CSja/Uia’s session key to the adversary.Corrupt (Uia,z). It returns back one or two kinds of user authentication factors to the adversary.Ifz=1, it returns back the password.Ifz=2, it returns back the data of smart card.Ifz=3, it returns back the biometric.Corrupt (RCa/CSja). It simulates forward secrecy. The oracle returns back the master key of RCa or the private key of CSja to the adversary.Test (CSja/Uia). It simulates the semantic security of the session key, If the instance CSja/Uia is accepted by its partner and establishes a session key SK, and the adversary never makes Corrupt (RCa/CSja) or Reveal (CSja/Uia) query, we say the instance CSja/Uia is fresh. If CSja/Uia is fresh, the oracle tosses a coin b. If b=1, it answers SK. Otherwise, it chooses an equal-length string and sends it to the adversary. The adversary is allowed to make this query no more than once.(3) Semantic Security. After receiving the answer from Test (CSja/Uia) query, the adversary tries to reveal the value of b. We define the advantage that adversary breaks the semantic security of the proposed scheme as
(1)AdvPakeA=2Prb′=b−1.IfAdvPakeA is negligible, the proposed scheme achieves semantic security.


### 5.2.2. Security Analysis

Theorem 1.
As demonstrated in [34], the password distribution follows Zipf’s law. DPW denotes the password dictionary space. C′ and s′ are parameters of the Zipf distribution. AdvPECDHP denotes the advantage that the adversary A solves ECDHP. The adversary A can make at most qe Execute queries, qs Send queries, qh Hash queries, and qb Biohashing queries in polynomial time t. We have
(2)AdvPakeA≤2C′∗qss′+qs+qe2p+6qs+qh22l1+2qs+qb22l2+2qhAdvPECDHP,
wherel1 is the length of the hash value, and l2 is the length of the biohashing value, in terms of the Tianya password dictionary [35] of size DPW≈13million, C′=0.062239, s′=0.155478.Proof. The security of the proposed scheme is demonstrated through a series of gamesΦi (0≤i≤6), and Prχi denotes the advantage that A guesses b in Φi.Φ0: this game represents the real attack. Hence,
(3)AdvPakeA=2Prχ0−1.Φ1: the hash oracle and biohashing oracle are simulated by setting up two lists ΛH and ΛBH. For a Hash query H1τ, the oracle uses τ to search ΛH. If an item (τ,γ) is found, it sends back γ to the adversary. Otherwise, it returns a random number γ to the adversary and adds a new item (τ,γ) to ΛH. The biohashing oracle is simulated in the same way. There is no difference between Φ1 and Φ0. Hence,
(4)Prχ1−Prχ0=0.Φ2: This game is terminated when some collisions occur.
(1)
A collision appears in random numbers. The probability is no more thanqs+qe2/2p(2)
A collision appears in hash values or biohashing values. The probability is no more thanqh2/2l1+1+qb2/2l2+1Hence,(5)Prχ2−Prχ1≤qh22l1+1+qb22l2+1+qs+qe22p.Φ3: we abort the game when A has guessed (Di,Li,Mi). Its advantage is no more than qs/2l1. Hence,
(6)Prχ3−Prχ2≤qs/2l1.Φ4: we abort the game when A has guessed user’s secret key di. Its advantage is no more than qs/2l1. Hence,
(7)Prχ4−Prχ3≤qs/2l1.Φ5: we abort the game when A has computed di having the aid of Corrupt (Uia,z) query.
(1)
IfA has obtained user’s password and biometric, he is able to reveal the key parameter Wi with probability qs/2l1(2)
IfA has obtained user’s password and the data of smart card, he is able to reveal the biometric with probability qs/2l2(3)
IfA has obtained user’s biometric and the data of smart card, he is able to reveal the password with probability C′∗qss′Hence,(8)Prχ5−Prχ4≤qs/2l2+C′∗qss′+qs/2l1.Φ6: in this game, the hash oracle H1 is replaced by the private hash oracle H1′ to calculate the session key. H1′ is unavailable to A. Hence,
(9)Prχ6=12.Φ6 has no difference with Φ5, unless A has asked Hash query H1r3Ni∥Di. This event is denoted by Γ1. Hence,
(10)Prχ6−Prχ5≤PrΓ1.IfA has asked Hash query H1r3Ni∥Di, when picking an item from ΛH, we can get a solution of ECDHP with probability 1/qh. Hence,
(11)PrΓ1≤qhAdvPECDHP.From (3)–(11), we have
(12)AdvPakeA≤2C′∗qss′+qs+qe2p+6qs+qh22l1+2qs+qb22l2+2qhAdvPECDHP.


## 5.2.1. Security Model

(1) Participants. The proposed scheme involves three kinds of participants, i.e., the registration center RC, the cloud server CSj, and the user Ui. RCa,CSja, and Uia are the a-th instances of RC, CSj, and Ui, respectively.(2) Queries. The adversary capability is simulated through the following queries.Execute (CSja/Uia). It simulates the passive attack. It returns back the transcript of messages to the adversary.Send (CSja/Uia,m). It simulates the active attack. The adversary masquerades as the instance CSja/Uia by sending a message m. The oracle processes m and returns a response to the adversary.Reveal (CSja/Uia). It returns back CSja/Uia’s session key to the adversary.Corrupt (Uia,z). It returns back one or two kinds of user authentication factors to the adversary.Ifz=1, it returns back the password.Ifz=2, it returns back the data of smart card.Ifz=3, it returns back the biometric.Corrupt (RCa/CSja). It simulates forward secrecy. The oracle returns back the master key of RCa or the private key of CSja to the adversary.Test (CSja/Uia). It simulates the semantic security of the session key, If the instance CSja/Uia is accepted by its partner and establishes a session key SK, and the adversary never makes Corrupt (RCa/CSja) or Reveal (CSja/Uia) query, we say the instance CSja/Uia is fresh. If CSja/Uia is fresh, the oracle tosses a coin b. If b=1, it answers SK. Otherwise, it chooses an equal-length string and sends it to the adversary. The adversary is allowed to make this query no more than once.(3) Semantic Security. After receiving the answer from Test (CSja/Uia) query, the adversary tries to reveal the value of b. We define the advantage that adversary breaks the semantic security of the proposed scheme as
(1)AdvPakeA=2Prb′=b−1.IfAdvPakeA is negligible, the proposed scheme achieves semantic security.


## 5.2.2. Security Analysis

Theorem 1.
As demonstrated in [34], the password distribution follows Zipf’s law. DPW denotes the password dictionary space. C′ and s′ are parameters of the Zipf distribution. AdvPECDHP denotes the advantage that the adversary A solves ECDHP. The adversary A can make at most qe Execute queries, qs Send queries, qh Hash queries, and qb Biohashing queries in polynomial time t. We have
(2)AdvPakeA≤2C′∗qss′+qs+qe2p+6qs+qh22l1+2qs+qb22l2+2qhAdvPECDHP,
wherel1 is the length of the hash value, and l2 is the length of the biohashing value, in terms of the Tianya password dictionary [35] of size DPW≈13million, C′=0.062239, s′=0.155478.Proof. The security of the proposed scheme is demonstrated through a series of gamesΦi (0≤i≤6), and Prχi denotes the advantage that A guesses b in Φi.Φ0: this game represents the real attack. Hence,
(3)AdvPakeA=2Prχ0−1.Φ1: the hash oracle and biohashing oracle are simulated by setting up two lists ΛH and ΛBH. For a Hash query H1τ, the oracle uses τ to search ΛH. If an item (τ,γ) is found, it sends back γ to the adversary. Otherwise, it returns a random number γ to the adversary and adds a new item (τ,γ) to ΛH. The biohashing oracle is simulated in the same way. There is no difference between Φ1 and Φ0. Hence,
(4)Prχ1−Prχ0=0.Φ2: This game is terminated when some collisions occur.
(1)
A collision appears in random numbers. The probability is no more thanqs+qe2/2p(2)
A collision appears in hash values or biohashing values. The probability is no more thanqh2/2l1+1+qb2/2l2+1Hence,(5)Prχ2−Prχ1≤qh22l1+1+qb22l2+1+qs+qe22p.Φ3: we abort the game when A has guessed (Di,Li,Mi). Its advantage is no more than qs/2l1. Hence,
(6)Prχ3−Prχ2≤qs/2l1.Φ4: we abort the game when A has guessed user’s secret key di. Its advantage is no more than qs/2l1. Hence,
(7)Prχ4−Prχ3≤qs/2l1.Φ5: we abort the game when A has computed di having the aid of Corrupt (Uia,z) query.
(1)
IfA has obtained user’s password and biometric, he is able to reveal the key parameter Wi with probability qs/2l1(2)
IfA has obtained user’s password and the data of smart card, he is able to reveal the biometric with probability qs/2l2(3)
IfA has obtained user’s biometric and the data of smart card, he is able to reveal the password with probability C′∗qss′Hence,(8)Prχ5−Prχ4≤qs/2l2+C′∗qss′+qs/2l1.Φ6: in this game, the hash oracle H1 is replaced by the private hash oracle H1′ to calculate the session key. H1′ is unavailable to A. Hence,
(9)Prχ6=12.Φ6 has no difference with Φ5, unless A has asked Hash query H1r3Ni∥Di. This event is denoted by Γ1. Hence,
(10)Prχ6−Prχ5≤PrΓ1.IfA has asked Hash query H1r3Ni∥Di, when picking an item from ΛH, we can get a solution of ECDHP with probability 1/qh. Hence,
(11)PrΓ1≤qhAdvPECDHP.From (3)–(11), we have
(12)AdvPakeA≤2C′∗qss′+qs+qe2p+6qs+qh22l1+2qs+qb22l2+2qhAdvPECDHP.


## 5.3. Further Security Analysis

This section demonstrates that the proposed scheme is immune to known attacks and provides various desirable security properties.


### 5.3.1. Mutual Authentication

In our scheme, the cloud server authenticates the user by checking ifDiP=Ai+Ci∙PUBi. Di is a signature calculated based on user private key di. Only the user Ui who has the private key di can calculate a valid Di. In addition, the user validates the cloud server by checking if Li∗=Li. Actually, the user authenticates the cloud server based on Bi=r1PUBj=kjAi. In the login request, Di is encrypted under the key Bi. Except the user Ui, only the cloud server CSj who has the secret key kj can compute Bi and retrieve Di from Ei and generate a valid authenticate value Li.


### 5.3.2. Session Key Agreement

The user and the cloud server generate a session keySK=H1r3r2P∥Di. The session key is composed of r3r2P and Di. r3r2P is generated using elliptic curve Diffie-Hellman key exchange, and it guarantees forward secrecy. Di is generated based on user’s private key, and it guarantees the resistance of session-specific temporary information attack.


### 5.3.3. User Anonymity

In our scheme, the user identity is encrypted under the keyBi. As ECDHP is intractable, only the user who knows the random number r1 and the cloud server who has the secret key kj can retrieve IDi from Ei. Additionally, the random numbers r1 and r2 are involved in the login request {Ai,Ei}. The login requests are different in each session. Thus, the proposed scheme preserves user untraceability.


### 5.3.4. Offline RC

In the authentication phase, the user and the cloud server can perform mutual authentication and session key agreement without the aid of RC. It reduces the number of interacted messages. Correspondingly, it helps to reduce communication and computing overheads.


### 5.3.5. Forward Secrecy

The session key is computed based onSK=H1r3r2P∥Di∥r3PUBi. r3r2P is generated using Diffie-Hellman key exchange. Due to the intractability of ECDHP, even the attacker obtains the long-term secret, he is unable to retrieve r3r2P from Fi and Ni. The proposed scheme preserves forward secrecy.


### 5.3.6. Resist Session-Specific Temporary Information Attack

Suppose that the random numbersr2 is compromised. The adversary computes r3Fi. However, as Bi is unavailable, the adversary cannot obtain Di.Suppose that the random numberr3 is compromised. The adversary cannot obtain Ni and Di, as Bi is unavailable. The adversary can neither obtain Di or r3Ni.As a result, the adversary cannot reveal the session key when the random number is compromised.


### 5.3.7. Resist Forgery Attack

In our scheme, the user computes the signatureDi based on the private key di to authenticate the message Ai,Ei,Ni. Afterwards, the cloud server uses the shared session key SK to authenticate the message Fi,Li. Finally, the user uses the shared session key SK to authenticate the message Mi. As the secret key di and SK are unavailable, the adversary cannot produce a valid message.


### 5.3.8. Resist Replay Attack

In the proposed scheme, the cloud server authenticates the user by checking the validity of the messagesAi,Ei,Ni and Mi. If the adversary replays Ai,Ei,Ni, as he cannot produce a valid Mi, ultimately, the authentication fails. If the adversary replays Fi,Li and Mi, as the random numbers selected in each session are different, the authentication fails. Hence, the proposed scheme can resist replay attack.


### 5.3.9. Resist Insider Attack

The user cannot impersonate the cloud server without cloud server’s private key. Similarly, the cloud server cannot impersonate the user without user’s private key. The other users cannot pretend to be the userUi, as he cannot generate a valid signature of Ui. The other cloud servers cannot pretend to be the cloud server CSj, as he cannot decrypt Ei to get Di. Our scheme is resistance to insider attack.


### 5.3.10. User Friendliness

The proposed scheme provides user friendliness. Firstly, the proposed scheme adopts multiserver architecture. The user only needs to register once to access multiple servers. Secondly, in the authentication phase, the registration center is offline, and the user can access the cloud server directly without interacting with the registration center. Thirdly, the proposed scheme supports smartcard revocation, efficiency for wrong password and biometric detection, and password and biometric update.


### 5.3.11. Three-Factor Secrecy

The fuzzy verificationZi makes our scheme that is immune to offline guessing attack. Even if the adversary compromises two kinds of authentication factors, the other one is still unavailable. In addition, for the adversary, the only way to retrieve di is to break the password, the biometric, and the smart card at the same time. Without di, the adversary cannot impersonate the user. Hence, the proposed scheme preserves three-factor secrecy.


## 5.3.1. Mutual Authentication

In our scheme, the cloud server authenticates the user by checking ifDiP=Ai+Ci∙PUBi. Di is a signature calculated based on user private key di. Only the user Ui who has the private key di can calculate a valid Di. In addition, the user validates the cloud server by checking if Li∗=Li. Actually, the user authenticates the cloud server based on Bi=r1PUBj=kjAi. In the login request, Di is encrypted under the key Bi. Except the user Ui, only the cloud server CSj who has the secret key kj can compute Bi and retrieve Di from Ei and generate a valid authenticate value Li.


## 5.3.2. Session Key Agreement

The user and the cloud server generate a session keySK=H1r3r2P∥Di. The session key is composed of r3r2P and Di. r3r2P is generated using elliptic curve Diffie-Hellman key exchange, and it guarantees forward secrecy. Di is generated based on user’s private key, and it guarantees the resistance of session-specific temporary information attack.


## 5.3.3. User Anonymity

In our scheme, the user identity is encrypted under the keyBi. As ECDHP is intractable, only the user who knows the random number r1 and the cloud server who has the secret key kj can retrieve IDi from Ei. Additionally, the random numbers r1 and r2 are involved in the login request {Ai,Ei}. The login requests are different in each session. Thus, the proposed scheme preserves user untraceability.


## 5.3.4. Offline RC

In the authentication phase, the user and the cloud server can perform mutual authentication and session key agreement without the aid of RC. It reduces the number of interacted messages. Correspondingly, it helps to reduce communication and computing overheads.


## 5.3.5. Forward Secrecy

The session key is computed based onSK=H1r3r2P∥Di∥r3PUBi. r3r2P is generated using Diffie-Hellman key exchange. Due to the intractability of ECDHP, even the attacker obtains the long-term secret, he is unable to retrieve r3r2P from Fi and Ni. The proposed scheme preserves forward secrecy.


## 5.3.6. Resist Session-Specific Temporary Information Attack

Suppose that the random numbersr2 is compromised. The adversary computes r3Fi. However, as Bi is unavailable, the adversary cannot obtain Di.Suppose that the random numberr3 is compromised. The adversary cannot obtain Ni and Di, as Bi is unavailable. The adversary can neither obtain Di or r3Ni.As a result, the adversary cannot reveal the session key when the random number is compromised.


## 5.3.7. Resist Forgery Attack

In our scheme, the user computes the signatureDi based on the private key di to authenticate the message Ai,Ei,Ni. Afterwards, the cloud server uses the shared session key SK to authenticate the message Fi,Li. Finally, the user uses the shared session key SK to authenticate the message Mi. As the secret key di and SK are unavailable, the adversary cannot produce a valid message.


## 5.3.8. Resist Replay Attack

In the proposed scheme, the cloud server authenticates the user by checking the validity of the messagesAi,Ei,Ni and Mi. If the adversary replays Ai,Ei,Ni, as he cannot produce a valid Mi, ultimately, the authentication fails. If the adversary replays Fi,Li and Mi, as the random numbers selected in each session are different, the authentication fails. Hence, the proposed scheme can resist replay attack.


## 5.3.9. Resist Insider Attack

The user cannot impersonate the cloud server without cloud server’s private key. Similarly, the cloud server cannot impersonate the user without user’s private key. The other users cannot pretend to be the userUi, as he cannot generate a valid signature of Ui. The other cloud servers cannot pretend to be the cloud server CSj, as he cannot decrypt Ei to get Di. Our scheme is resistance to insider attack.


## 5.3.10. User Friendliness

The proposed scheme provides user friendliness. Firstly, the proposed scheme adopts multiserver architecture. The user only needs to register once to access multiple servers. Secondly, in the authentication phase, the registration center is offline, and the user can access the cloud server directly without interacting with the registration center. Thirdly, the proposed scheme supports smartcard revocation, efficiency for wrong password and biometric detection, and password and biometric update.


## 5.3.11. Three-Factor Secrecy

The fuzzy verificationZi makes our scheme that is immune to offline guessing attack. Even if the adversary compromises two kinds of authentication factors, the other one is still unavailable. In addition, for the adversary, the only way to retrieve di is to break the password, the biometric, and the smart card at the same time. Without di, the adversary cannot impersonate the user. Hence, the proposed scheme preserves three-factor secrecy.


## 6. Performance Comparisons

The comparative analysis of our scheme and the relevant schemes [3, 26–28] is presented in this section. Our scheme and the relevant schemes are evaluated from two aspects, i.e., security properties and computation and communication overheads.Table3 presents the security analysis results of relevant schemes. The security attributes include user anonymity and three-factor secrecy, as well as the resistance of usual attacks. Besides, the characteristics of the proposed schemes and relevant schemes are also detailed in Table 3. The relevent schemes [3, 26 ,27] adopt multiserver architecture, and RC is offline in the authentication phase, while Mo et al.’s scheme adopts single-server architecture. Tsai et al.’s scheme, He et al.’s scheme, and Irshad et al.’s scheme are bilinear paring-based schemes, while Mo et al.’s scheme and our scheme are ECC-based schemes. From Table 3, we witness that the relevant schemes have more or less weaknesses, while the proposed scheme can remedy the security defects of relevant schemes and provides desirable security properties. It shows that the proposed scheme has better security than the relevant schemes.Table 3
Security features Comparisons.
Security propertiesTsai and Lo [3]He et al. [26]Irshad et al. [27]Mo et al. [28]Our schemeUser anonymity×√√√√Resist server impersonation attack×√×√√Resist offline guessing attack√√√√√Resist stolen-verifier attack√√√×√Resist denial of service attack√√√×√Resist replay attack√√√×√Resist known session-specific temporary information attack××××√Forward secrecy√√√√√Three-factor secrecy−−√−√Efficiency for wrong password and biometric detection××√√√Offline RC√√√−√Single/multi serverMultiserverMultiserverMultiserverSingle-serverMultiserverCryptography primitivesParingParingParingECCECCIn accordance with [26], the user uses a mobile device to access the cloud server, the cloud server is deployed in a personal computer, and the executing time of relevant cryptography operations is presented in Table 4. The computation costs of our scheme and the relevant schemes are evaluated as shown in Table 5. The running time of the proposed scheme is 80.379 ms. The running time of the relevant schemes [3, 26–28] is 105.989 ms, 90.292 ms, 103.682 ms, and 47.189 ms, respectively.Table 4
Executing time of some cryptography operations.
Cryptography operationsSymbolsRunning time (ms)UserServerMap-to-point hash functionTPH33.5825.493Bilinear paringTB32.7135.427Elliptic curve point multiplicationTP13.4052.165Elliptic curve point additionTA0.0810.013Exponentiation operationTE2.2490.339Hash functionTH0.0560.007Table 5
Computation costs of related schemes.
Computation costUser (ms)Server (ms)Total (ms)Tsai and Lo [3]TPH+4TP+2TA+TE+5TH (89.893)2TB+2TP+2TA+2TE+4TH (16.096)105.989He et al. [26]TPH+3TP+2TE+4TH (78.519)2TP+2TA+2TE+5TH (11.773)90.292Irshad et al. [27]1TB+4TP (86.333)2TB+3TP (17.349)103.682Mo et al. [28]3TP+TA+6TH (40.632)3TP+TA+7TH (6.557)47.189Our scheme4TP+6TH (53.956)5TP+4TH (10.853)64.809To evaluate the communication cost, we suppose that the user identity is 32 bits, the point on the elliptic curve group is 1024 bits, and the hash value is 160 bits. The login request query in [3, 26, 27] is 32 bits. As shown in Table 6, the communication cost of the proposed scheme is 3584 bits. The communication costs of the relevant schemes [3, 26–28] are 4320 bits, 3296 bits, 4288 bits, and 2720 bits, respectively.Table 6
Communication costs of related schemes.
Tsai and Lo [3]He et al. [26]Irshad et al. [27]Mo et al. [28]Our schemeCommunication cost4320 bits3296 bits4288 bits2720 bits3584 bitsFigure5 presents the comparison of total computation costs, the computation costs of user end, and the computation costs of cloud server. Figure 6 presents the communication cost comparison. In terms of the communication cost, our scheme is in third place and better than the average communication cost. In terms of the total computation cost, user’s computation cost, and server’s computation cost, the proposed scheme is second only to Mo et al.’s scheme. However, Mo et al.’s scheme has limitations like stolen-verifier attack and denial of service attack; particularly, its single-server architecture is not applicable to the mobile cloud computing environment.Figure 5
Computation cost comparisons.Figure 6
Communication cost comparison.In a nutshell, our scheme provides more security attributes and has low computation and communication costs. Among the relevant schemes, the security features of He et al.’s scheme are the closest to our scheme. However, the computation cost of our scheme is 0.72 times of He et al.’s scheme. Our scheme achieves balanced security and efficiency. Compared with the relevant schemes, our scheme is more applicable to mobile cloud computing.


## 7. Conclusion

In this paper, we demonstrate that Mo et al.’s scheme has limitations such as stolen-verifier attack and denial of service attack. Most notably, its single-server architecture is not applicable to MCC. To enhance the security, we present a provably secure ECC-based three-factor authentication scheme. Security analysis shows that our scheme is immune to known attacks and provides user friendliness. Performance comparisons indicate that our scheme provides more security attributes and incus low computation and communication cost. Our scheme is more applicable to MCC. As postquantum security has become the focus issue of researchers, we plan to use lattice-based key exchange [36] and smooth projective hash functions [37] to construct a quantum-resistant scheme at the next step.



---

*Source: 8848032-2021-05-29.xml*