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.

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 Figure 1. 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.

1.1. Related Works

Since Lamport [4] presented the first password authentication scheme, a large number of schemes [518] 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 [1922] 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, 2628], 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. Section 2 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.

2. Preliminaries

2.1. Elliptic Curve Diffie–Hellman Problem

Elliptic curve Diffie–Hellman problem (ECDHP): is an elliptic curve group over the prime field . P is a generator of . For given , where , solving 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 and calculates the public key .

3.1.1. User Registration Phase

This phase is executed as follows. (Step1). The user selects his identity , password , and a nonce and computes .(Step2): a smart card. CS picks a nonce and computes , , where is the current timestamp, is an integer from , and is the smart card identification number. CS stores in the database and stores {} in a smart card, where is the identity of (Step3) computes and stores in the smart cardThe user selects his identity , password , and a nonce and computes .

3.1.2. Authentication Phase

This phase is comprised of the following steps. (Step1). enters , . Then, the smart card computes , and checks if . If it holds, the smart card chooses a nonce and computes , , , , the dynamic identity , and .(Step2). CS computes , , , and and checks if . If it does not hold, the protocol aborts. Otherwise, CS retrieves from the database based on and computes and checks if . If they are equal, CS chooses a nonce and computes , , the session key , and .(Step3). computes , and checks if . If they are equal, computes and .(Step4)CS computes and checks if . If they are not equal, the protocol aborts enters , . Then, the smart card computes , and checks if . If it holds, the smart card chooses a nonce and computes , , , , the dynamic identity , and .

3.1.3. Smartcard Revocation Phase

The smart card can be revoked through the following steps. (Step1) performs step 1 of the authentication phase. sends a revocation request to CS(Step2)CS checks if and . If they are equal, CS deletes from the databasePerforms step 1 of the authentication phase. sends a revocation request to CS

After 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 tuple for each user . If the attacker compromises CS and retrieves from the database, the attacker can masquerade as the legitimate user through the following steps. (Step1)The attacker computes (Step2)The attacker chooses a nonce and computes , , , , . sends to CS

As and , CS regards the attacker as the legitimate user . The essential reason for this attack is that the secret authentication value 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 intercepts from the public channel(Step2)The attacker sends to CS

After receiving , as it is valid, CS deletes from the database. After that, the legitimate user is unable to access CS unless reregistration. The essential reason for this attack is that CS does not check the freshness of . The attacker can forge a revocation request using the intercepted .

3.2.3. Known Session-Specific Temporary Information Attack

Once the attacker compromises the nonce , he can reveal the session key through the following steps. (Step1)The attacker intercepts and from the public channel(Step2)The attacker obtains the user identity by shoulder peeping or computing , , (Step3)The attacker can obtain by compromising user’s smart card or colluding with a user(Step4)The attacker computes , .

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 Figure 1, 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 server , and the user . 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. and implement mutual authentication and negotiate a session key without the registration center involved.

4.1. Predeployment Phase

RC selects an elliptic curve group over the prime field . is a generator of . RC selects the master key . RC chooses a secure hash function and a biohashing function . RC publishes the parameters .

4.2. User Registration Phase

This phase is depicted as Figure 2. (Step1)The user chooses his identity and password , imprints his biometric , and computes , where is a nonce. delivers the message {} to RC via the reliable channel(Step2)After getting {}, RC computes ’s private key and public key , , . RC chooses an integer . RC stores the parameters {} in a smart card and publishes ’s public key {}. RC issues the smart card to in a credible manner(Step3) saves in the smart card

4.3. Cloud Server Registration Phase

This phase is depicted as Figure 3. (Step1)The cloud server delivers his identity to RC via the reliable channel(Step2)Upon getting {}, RC computes ’s private key and public key . RC publishes the parameters {}. RC issues {} to in a credible manner

4.4. Authentication Phase

This phase is depicted as Figure 4. (Step1) enters and and imprints . The smart card computes , , and checks if . If they are equal, the smart card chooses two random numbers and and computes , , , , , , . sends the message to via the public channel(Step2)Upon receiving , computes , , and checks if . If it holds, chooses a random number and computes , the session key, . sends to (Step3)After receiving , the smart card computes , and verifies if . If so, the smart card computes . sends to (Step4)Upon getting , computes and checks if . If they are equal, and achieve mutual authentication and establish a session key

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 {} and issues a new smart card to . 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) inputs and and imprints . The smart card computes , and checks if . If they are equal, ask the user to input his new password and imprint his new biometric(Step2)The smart card chooses a new nonce and computes , , and . The smart card saves and deletes , inputs and and imprints . The smart card computes , and checks if . 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.

The proposed scheme should be able to achieve the following goals.

G1:

G2:

G3:

G4:

The proposed scheme is idealized as below.

M1:

M2:

M3:

The initial assumptions of the proposed scheme are as below.

A1:

A2:

A3:

A4:

A5:

A6:

A7:

A8:

The proof is as follows.

From M1, we have

(1)

Apply Rule 1 to (1) and A1, we have

(2)

From (2), we have

(3)

Apply Rule 1 to (3) and A2, we have

(4)

Apply Rule 2 to (4) and A3, we have

(5)

Apply Rule 3 to (5) and A4, we have

(6)

From M2, we have

(7)

Apply Rule 1 to (7) and A5, we have

(8)

Apply Rule 2 to (8) and A6, we have

(9) (G1)

Apply Rule 3 to (9) and A7, we have

(10) (G2)

From M3, we have

(11)

Apply Rule1 to (11) and A1, we have

(12)

Apply Rule 2 to (14) and A3, we have

(13) (G3)

Apply Rule 3 to (15) and A8, we have

(14) (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 , and the user . , and are the -th instances of RC, , and , respectively.

(2) Queries. The adversary capability is simulated through the following queries.

Execute (). It simulates the passive attack. It returns back the transcript of messages to the adversary.

Send (). It simulates the active attack. The adversary masquerades as the instance by sending a message . The oracle processes and returns a response to the adversary.

Reveal (). It returns back ’s session key to the adversary.

Corrupt (). It returns back one or two kinds of user authentication factors to the adversary.

If , it returns back the password.

If , it returns back the data of smart card.

If , it returns back the biometric.

Corrupt (). It simulates forward secrecy. The oracle returns back the master key of or the private key of to the adversary.

Test (). It simulates the semantic security of the session key, If the instance is accepted by its partner and establishes a session key , and the adversary never makes Corrupt () or Reveal () query, we say the instance is fresh. If is fresh, the oracle tosses a coin . If , it answers . 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 () query, the adversary tries to reveal the value of . We define the advantage that adversary breaks the semantic security of the proposed scheme as

If 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. denotes the password dictionary space. and are parameters of the Zipf distribution. denotes the advantage that the adversary solves ECDHP. The adversary can make at most Execute queries, Send queries, Hash queries, and Biohashing queries in polynomial time . We have where is the length of the hash value, and is the length of the biohashing value, in terms of the Tianya password dictionary [35] of size , , .

Proof. The security of the proposed scheme is demonstrated through a series of games (), and denotes the advantage that guesses in .

: this game represents the real attack. Hence,

: the hash oracle and biohashing oracle are simulated by setting up two lists and . For a Hash query , the oracle uses to search . 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 . The biohashing oracle is simulated in the same way. There is no difference between and . Hence,

: This game is terminated when some collisions occur. (1)A collision appears in random numbers. The probability is no more than (2)A collision appears in hash values or biohashing values. The probability is no more than

Hence,

: we abort the game when has guessed (). Its advantage is no more than . Hence,

: we abort the game when has guessed user’s secret key . Its advantage is no more than . Hence,

: we abort the game when has computed having the aid of Corrupt () query. (1)If has obtained user’s password and biometric, he is able to reveal the key parameter with probability (2)If has obtained user’s password and the data of smart card, he is able to reveal the biometric with probability (3)If has obtained user’s biometric and the data of smart card, he is able to reveal the password with probability

Hence,

: in this game, the hash oracle is replaced by the private hash oracle to calculate the session key. is unavailable to . Hence,

has no difference with , unless has asked Hash query . This event is denoted by . Hence,

If has asked Hash query , when picking an item from , we can get a solution of with probability . Hence,

From (3)–(11), we have

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 if . is a signature calculated based on user private key . Only the user who has the private key can calculate a valid . In addition, the user validates the cloud server by checking if . Actually, the user authenticates the cloud server based on . In the login request, is encrypted under the key . Except the user , only the cloud server who has the secret key can compute and retrieve from and generate a valid authenticate value .

5.3.2. Session Key Agreement

The user and the cloud server generate a session key . The session key is composed of and . is generated using elliptic curve Diffie-Hellman key exchange, and it guarantees forward secrecy. 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 key . As ECDHP is intractable, only the user who knows the random number and the cloud server who has the secret key can retrieve from . Additionally, the random numbers and are involved in the login request {}. 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 on . 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 from and . The proposed scheme preserves forward secrecy.

5.3.6. Resist Session-Specific Temporary Information Attack

Suppose that the random numbers is compromised. The adversary computes . However, as is unavailable, the adversary cannot obtain .

Suppose that the random number is compromised. The adversary cannot obtain and , as is unavailable. The adversary can neither obtain or .

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 signature based on the private key to authenticate the message . Afterwards, the cloud server uses the shared session key to authenticate the message . Finally, the user uses the shared session key to authenticate the message . As the secret key and 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 messages and . If the adversary replays , as he cannot produce a valid , ultimately, the authentication fails. If the adversary replays and , 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 user , as he cannot generate a valid signature of . The other cloud servers cannot pretend to be the cloud server , as he cannot decrypt to get . 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 verification 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 is to break the password, the biometric, and the smart card at the same time. Without , 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, 2628] 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.

Table 3 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.

In 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, 2628] is 105.989 ms, 90.292 ms, 103.682 ms, and 47.189 ms, respectively.

To 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, 2628] are 4320 bits, 3296 bits, 4288 bits, and 2720 bits, respectively.

Figure 5 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.

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.

Data Availability

The data used to support the findings of this study are included within the article.

Conflicts of Interest

The authors declare no conflict of interest.

Acknowledgments

This research was funded by the National Key Research and Development Program of China (No. 2018YFB0803600 and No. 2017YFB0801903) and by the National Natural Science Foundation of China (No. 61831003 and No. 61897069).