Abstract

Investigating the security pitfalls of cryptographic protocols is crucial to understand how to improve security. At ICCCS’17, Wu and Xu proposed an efficient smart-card-based password authentication scheme for cloud computing environments to cope with the vulnerabilities in Jiang et al.’s scheme. However, we reveal that Wu-Xu’s scheme actually is subject to various security flaws, such as offline password guessing attack and replay attack. Besides security, user friendly is also another great concern. In 2017, Roy et al. found that in most previous two-factor schemes a user has to manage different credentials for different services and further suggested a user-friendly scheme which is claimed to be suitable for multiserver architecture and robust against various attacks. In this work, we show that Roy et al.’s scheme fails to achieve truly two-factor security and shows poor scalability. At FGCS’18, Amin et al. pointed out that most of existing two-factor schemes are either insecure or inefficient for mobile devices due to the use of public-key techniques and thus suggested an improved protocol by using only light-weight symmetric key techniques. Almost at the same time, Wei et al. also observed this issue and proposed a new scheme based on symmetric key techniques with formal security proofs in the random oracle model. Nevertheless, we point out that both Amin et al.’s and Wei et al.’s schemes cannot achieve the claimed security goals (including the most crucial goal of “truly two-factor security”). Our results invalidate any use of the scrutinized schemes for cloud computing environments.

1. Introduction

With the emerging paradigm of cloud computing and Internet of Things (IoT), various services are provided over the cloud and accessed by users from IoT-enable devices (e.g., mobile phones and smart watches). As cloud-based services can be accessed anytime and anywhere just with a connection to the Internet and IoT-enable devices are generally of resource-constrained nature, it is important and challenging to protect users and cloud servers from severe security threats, such as fraudulence, eavesdropping, and falsification, posed either by external attackers or malicious internal entities. To guarantee that the resources and services can only be accessed by legitimate parties, user authentication plays an important part in securing electronic transactions by acquiring collaborative evidence. In 2011, Hao et al. [1] suggested the first two-factor authentication scheme that is based on password and smart cards for the cloud computing environments. This initial work has brought about a number of enhanced proposals [29] with each different in terms of security [10], anonymity [11], usability [12], and efficiency [13].

Without loss of generality, we consider the most common client-server architecture in which two participants (i.e., a server and a user ) get involved in two-factor authentication [14]. User holds a memorable password and a smart card stored with some initial security parameters, and server only needs to keep some secret key material of the system. Since there is no need to keep a table with password-related verification information on the server side, the server is free from the threat of password dataset leaks and ameliorated from the burden of maintaining a large password dataset. This feature that makes this type of schemes rather desirable, considering that there are incessant leakages of password databases from large websites[15]. The most important security goal of this kind of schemes is the so-called “two-factor security” [16]. This security concept essentially means that only the user who has the smart card and knows the correct password can be verified by the server.

Most of existing two-factor schemes (e.g, [5, 8, 23]) for cloud computing are built on the basis of generic two-factor schemes like [3, 24]. Nevertheless, past research [20, 2527] have, again and again, proved that designing a smart-card-based password authentication scheme that can attain “two-factor security” is a tough task. In 2009, Xu et al. [28] developed a smart-card-based password authentication scheme relying on the intractability of computational Diffie-Hellman problem, and stated that their scheme is able to support “two-factor security” under the hypothesis that smart cards can be tampered. In addition, their scheme was “proved secure” in the random oracle model. However, later on Sood et al. [29] found that Xu et al.’s scheme cannot resist against user impersonation attack if the parameters kept in the smart cards can be extracted, invalidating Xu et al.’s claim of ensuring “two-factor security”. In 2010, Song [30] independently found this severe flaw in Xu et al.’s scheme. Furthermore, Song presented an improvement to counter the problem emerged in Xu et al.’s scheme.

In 2012, Chen et al. [31] pointed out that various security drawbacks still existed in both Sood et al.’s [29] and Song’s [30] schemes. More specifically, Sood et al.’s scheme is susceptible to server impersonation attack and Song’s scheme suffers from offline password guessing attack, in case the attacker can obtain those sensitive information kept in the smart card. Chen et al. [31] also put forward an improved scheme and argued that their scheme is robust under the condition that the sensitive data in smart card has been revealed by the attacker. It should be noted that recent rapid developments in side-channel attacks have proved that the sensitive information stored in general commercial smart cards could be extracted by power analysis or reverse engineering [32, 33]. Based on a weak yet realistic assumption, Chen et al.’s scheme [31] appears very practical.

However, soon after Chen et al.’s scheme [31] was presented, Ma et al. [20] figured out that it is susceptible to exactly the same problem (i.e., prone to offline password guessing attack and no supply of forward secrecy) with the original scheme (i.e., Song’s scheme [30]). Based on their past experience of protocol design and analysis, for the first time Ma et al. [20] suggested three generic principles for designing a secure and efficient two-factor protocol, namely, the public-key principle, the forward secrecy principle, and the security-usability balance principle. Unfortunately, none of the two-factor authentication protocols mentioned above can satisfy all these three design principles and, moreover, as we illustrate, all the schemes studied in this work fail to comply with at least one of these principles.

In 2017, Wu and Xu [17] also observed that previous schemes (e.g., [30, 31]) are vulnerable to various security loopholes (e.g., user impersonation attack and insider attack) and also suggested an enhanced scheme. Wu-Xu argued that their new scheme not only eradicates the security pitfalls being overlooked in previous schemes but also maintains strengths of previous schemes. Notwithstanding their claims, we will show that this scheme still has several serious defects being overlooked: it cannot withstand offline password guessing attack if the data in smart card can be revealed, which means that the primary goal of “truly two-factor security” cannot be satisfying; it is subject to replay attack; it ensures no timely typo detection.

Later on, Roy et al. [19] found that, in Tsai-Lo’s scheme [34], a user has to manage different credentials for different services and further suggested a user-friendly scheme which is claimed to be suitable for multiserver architecture and robust against various attacks. Therefore, this protocol shows a good application potential in multiserver cloud computing environments. In this work, we show that Roy et al.’s scheme fails to achieve truly two-factor security and cannot preserve user untraceability. We observe that the first failure of Roy et al.’s scheme is due in large part to the noncompliance with Ma et al.’s [20] security-usability tradeoff principle. Our attacks highlight the necessity of being aware of basic protocol design principles.

In 2018, Amin et al. [21] pointed out that previous schemes (e.g., [3537]) are vulnerable to various security loopholes (e.g., off-line password guessing attack, insider attack and user impersonation attack) and also developed a new scheme for distributed cloud computing environments. Amin et al. argued that their new scheme not only eradicates the security pitfalls being overlooked in previous schemes but also maintains strengths of previous schemes. Notwithstanding their claims, we will show that this scheme still has several serious defects being overlooked: it cannot withstand offline password guessing attack if the data in smart card can be revealed, which means that the primary goal of “truly two-factor security” cannot be satisfied with; it provides no forward secrecy; it ensures no user untraceability.

Very recently, Wei et al. [23] observed that most of previous schemes (e.g., [3640]) only provided some heuristic security arguments and little attention has been paid to the formal treatment of protocol security. Unsurprisingly, most of them are vulnerable to various security loopholes. Thus, they suggested an enhanced scheme for cloud computing without using computation-expensive public key operations. They employed a new cryptographic primitive called authenticated encryption scheme which can guarantee both message confidentiality and integrity, and showed that their new scheme can be provably secure in the random oracle model. Though this scheme is armed with a formal proof, we will show that this scheme still has several serious defects being overlooked: it cannot achieve the primary goal of “truly two-factor security”; it provides no forward secrecy; it ensures no user untraceability.

The remainder of the paper is organized as follows: we revisit Wu-Xu’s scheme in Section 2; we describe the security loopholes of Roy et al.’s scheme in Section 3; Amin et al.’s scheme is scrutinized in Section 4 and Wei et al.’s scheme is cryptanalyzed in Section 5. Finally, we conclude the paper in Section 6.

2. Revisiting Wu-Xu’s Scheme

2.1. Review Wu-Xu’s Scheme

In this section, we briefly review the chaotic-map based authentication scheme for cloud computing proposed by Wu and Xu [17] in ICCCS 2017. Their scheme consists of four phases: initialization, registration, authentication, and password change. For ease of presentation, we will follow the notations in Wu-Xu’s scheme as closely as possible and summarize the notations in Table 1.

2.1.1. Registration Phase

At the very start, the server generates a random positive integer and a symmetric key cryptosystem with and and then selects a secret key , and two one-way hash functions and .

Step R1. chooses her identity , and , then computes

Step R2. .

Step R3. selects a random number , computes and , and stores , , , , and into the smart card.

Step R4. : A smart card containing , .

Step R5. computes and stores into the card.

2.1.2. Login and Mutual Authentication Phase

When wants to login, the following operations will be performed:

Step 1. inserts the smart card into card reader and inputs and .

Step 2. Smart card computes .

Step 3. Smart card selects two random integers and and computes , , , , , .

Step 4. Smart card.

Step 5. On receiving the message from smart card, decrypts and gets and and then computes , .

Step 6. decrypts to obtain , , and , then checks if and . If all above verifications are correct, proceeds. Otherwise, the login request is interrupted.

Step 7. chooses three random integers , and and computes , , , , , , and , where is server-side session key.

Step 8. .

Step 9. Smart card calculates and obtains , , , and by decrypting . Smart card further computes and checks . If they are not equal, aborts the communication. Otherwise, smart card computes and replaces with .

2.2. Cryptanalysis of Wu-Xu’s Scheme

In this section, the security loopholes of Wu-Xu’s scheme [17] will be pointed out. More specifically, it is prone to offline password guessing attack and suffers from replay attack, which makes this scheme unpractical for real use. Before giving the detailed security analysis, we first define the various adversary models for smart-card-based password authentication.

2.2.1. Adversary Models

To analyze the security provisions of password-based authentication schemes using smart cards, generally three assumptions about the attacker’s capabilities are made since the landmark work of Yang et al. [24], and we summarize them as follows:

Assumption 1. The malicious attacker is able to eavesdrop, delete, insert, modify, or block any transcripts communicated in the public channel. That is to say, the communication channel between the common users and the server can be completely manipulated by . This well complies with the standard adversary model that is widely accepted for distributed computing [41].

Assumption 2. The malicious attacker can somehow get the victim user’s smart card and use side-channel attack techniques to acquire sensitive security parameters from the card memory, which is reasonable according to the recent research developments in side-channel attacks [32, 33].

Assumption 3. User’s password space is very constrained and the malicious attacker can offline enumerate it. To be user-friendly, most protocols (e.g., the ones in [3, 24, 4244]) enable the users to select their own password at will in the initial process of registration or later process of password change. Because human beings are incapable of memorizing random strings, instead they are likely to choose passwords that relate to their personal lives or short strings for convenience. As a result, these human-generated passwords are often very weak and belong to a small dictionary [4547].

Note that the nontamper resistant assumption about smart cards are conditional, i.e., under the conditions that smart cards have somehow been in the possession of the attacker for a relatively long time (e.g., at least a few days), which should be sufficient for launching a side-channel attack; the user is not on the scene; otherwise the user will observe the attack, for side-channel attacks generally need special instruments and professional/particular operations. This is why smart cards are superior to memory sticks, even though nontamper assumption about smart cards has been made: memory sticks are nontamper resistant unconditional. See more explications in [48].

Obviously, if both Assumptions 2 and 3 hold simultaneously, then an attacker (without any other assumptions/abilities) can successfully impersonate a victim user and any scheme is trivially insecure. Therefore, it is widely regarded that attackers should not be granted to obtain a victim user’s smart card as well as his password [3, 24, 49].

In [17], Wu and Xu reported that their scheme is secure under the above three assumptions. For example, they stated that their scheme can withstand offline password guessing attacks even if the security parameters in smart card have been extracted. However, contrary to their claims, we will illustrate that this scheme is still vulnerable to offline guessing as well as other pitfalls. Based on the above listed assumptions, we cryptanalyze the security provisions of Wu-Xu’s scheme in the following and assume that can extract the secret data stored in ’s smart card, and can also eavesdrop the messages exchanged between the parties.

2.2.2. Offline Password Guessing Attack

It is known that password-based authentication schemes are apt to be subject to two kinds of attacks regarding guessing [16, 25], i.e., offline password guessing and online password guessing, due to the limited size of the password space. Among them, the online guessing is relatively easy to detect due to the abnormal, large number of login requests issued by the attacker against the victim account within a short duration, and thus it can be countered by rate-limiting [50].

It is worth noting that when targeted online password guessing [47] is considered, attackers will no longer need to launch a large number of login attempts to try candidate passwords. Instead, targeted online password guessing attacks are rather effective and, as reported by Wang et al. [47], the attacker can have an over 20% of success rate within 100 login attempts against normal users, if has obtained some personal information (e.g., name, birthday) of the victim user. As a quick response to the results of [47], the US Digital identity guideline NIST 800-63B [51] has been revised and the following sentence was removed: “online guessing can be readily addressed by throttling the rate of login attempts permitted” (see more details in [52, 53]). Further, NIST 800-63B proposed four countermeasures such as CAPTCHA, exponential time delay, and risk-based authentication (see Section 5.2.2 of [51]).

In contrast, offline password guessing attack cannot be easily detected. In this attack, the attacker first attempts to look for some pieces of information that can be exploited as the comparison target of his password guesses and then locally determines the exactly correct password by repeatedly testing all the candidates. Since this attack is executed without online communication with the server, there is no means for the server to detect and thwart. In all, no matter in trawling or targeted online guessing, needs to interact with the server and there is the possibility that may be detected, but in offline password guessing there is no such possibility. Consequently, offline password guessing is a more serious threat if password-related information has been leaked.

Wu and Xu [17] claimed that an attacker is unable to, in an offline manner, determine a user’s password even if the sensitive data has been revealed from user’s smart card. However, the following attacking procedure illustrates that this claim is not tenable. Suppose that ’s smart card is lost/stolen and the attacker obtains it. Then extracts the content by using the methods introduced in [33]. The following procedure describes our proposed offline password guessing attack:

Step 1. choose a pair from the identity space and dictionary space , respectively.

Step 2. computes , where is revealed from ’s smart card.

Step 3. computes , where is recovered from ’s smart card.

Step 4. calculates , where is eavesdropped from the open channel.

Step 5. decrypts by using to obtain , where is eavesdropped from the open channel.

Step 6. calculates .

Step 7. examines the authenticity of pair by verifying if .

Step 8. returns to Step 1 of this procedure until the right pair of is obtained or all pairs in are exhausted.

It is obvious that the above procedure is with a time complexity of , where , , and denote the execution time of modular exponentiation, hash, and XOR operation, respectively. Based on the results reported in [16, 54], the offline password guessing attack is able to be carried out in seconds on a common computer, for in practice the size of identity space and the size of dictionary space are rather limited and could try all the possible passwords through an offline method [20, 49]. All in all, an type II attacker can guess within polynomial time bound; it follows that our suggested attack is indeed effective.

2.2.3. Replay Attack

Resistance to replay attack is a very basic security goal of any cryptographic protocol [16, 24]. However, Wu-Xu’s scheme fails to achieve this goal. More specifically, Wu-Xu’s scheme employs random numbers but not timestamps to achieve the freshness of messages. Yet, this scheme has only two protocol flows, making it inherently vulnerable to replay attack. As is well known, any two-flow random number based scheme is unable to achieve explicit authentication while resisting replay attack, because can simply replay the first message of a successful protocol run to impersonate the legitimate user, and the server can never know whether the replayed message is fresh or not unless the server maintains a table of all received messages. However, maintaining a table of all received messages is practically undesirable. In all, replay attack is quite realistic against Wu-Xu’s scheme.

3. Revisiting of Roy Et Al.’s Scheme

3.1. Review of Roy Et Al.’s Scheme

In this section, we first concisely review Roy et al.’s scheme [19] proposed in 2017. This scheme is an improvement over Tsai-Lo’s scheme [34] and aims to attain forward secrecy that is lacked in Tsai-Lo’s scheme. Roy et al.’s protocol involves three participants, i.e., the mobile user (), the cloud server (), and registration center (). There are five phases in their scheme: registration, login, authentication and key establishment, password change, and revocation of mobile device. The notations and initial system parameters employed in Roy et al.’s scheme are same as employed in the scheme of Wu-Xu (see Table 1).

3.1.1. Mobile User Registration

Step 1. chooses her identity , password , biometrics , and two 128-bit random numbers and .

Step 2. produces and computes the masked password .

Step 3. .

Step 4. selects an 1024-bit master secret key for server . also selects an 1024-bit random number for each and pair.

Step 5. computes , , and as the pseudoidentity of .

Step 6. selects a unique and random temporary identity for and saves server key-plus-id combinations in mobile device of .

Step 7. A mobile device contains .

Step 8. computes , , , , and for .

Finally, stores , , , s, s, and s into her own mobile device, and deletes s, , and s from the mobile device.

3.1.2. Cloud Server Registration

Step 1. chooses her identity .

Step 2. .

Step 3. provides the master secret key to each .

Step 4. For all s, the saves the credentials (for ) in database of , and also stores in the database of .

Finally, saves pair in its own database, where is the serial number of ’s mobile device.

3.1.3. Login Phase

When wants to login to , the following operations shall be executed:

Step L1. inputs her identity , password , and biometrics into her own mobile device. computes with through the fuzzy extractor reproduction procedure and generates with the stored parameter , .

Step L2. computes and checks whether . An equality indicates that is legal.

Step L3. calculates . also generates using the device parameter .

Step L4. selects an 128 bit random number , generates the current timestamp , and then computes:

, , , , and .

Step L5. .

3.1.4. Authentication Phase

In this phase, and mutually authenticate each other and establish a session key. Since this phase is unrelated to our discussions, we omit it.

3.2. Flaws in Roy Et Al.’s Scheme

Recall that the three assumptions listed in Section 3 are also clearly made in Roy et al.’s scheme. However, we observe that this scheme still remains feasible for an attacker to offline guess a user’s password. This means that the primary goal of “truly two-factor security” cannot be satisfied. In addition, the scheme cannot provide forward secrecy and sound scalability.

3.2.1. Offline Password Guessing Attack

Noting that Roy et al.’s scheme [19] is originally a three-factor one, here we are only interested in its two-factor version by assuming that the third factor (i.e., the biometric) has been known to . This is realistic as users’ biometrics are constant during their lives, and how to protect user biometric template is still an open issue [55]. We find that this scheme cannot achieve truly two-factor security: it is subject to two types of offline password guessing attack. This in turn indicates that it cannot achieve truly three-factor security.

Type-I Attack. . Suppose ’s biometric and the secret parameters , stored in the smart card are somehow obtained by . At this point, can find out ’s identity and password as follows:

Step 1. Guesses ’s identity and password from dictionary space and .

Step 2. Computes , , where is extracted from the smart card.

Step 3. Computes , where is extracted from the smart card.

Step 4. Checks the validity of by comparing the calculated with the extracted .

Step 5. Repeats Steps 1~4 until finds the correct pair of .

The time complexity of this attack is [3, 16]. Generally, it is only needed to calculate the biohashing function once; thus can be ignored in practice. According to the running time in [16], may complete the above attacking procedure within 17.6 days on a Laptop. This issue arises due to the inherent “usability-security tension”: to achieve local password change (i.e., C-2 in [3]) and timely typo detection (i.e., C-9 in [3]); there is an explicit password verifier stored in ’s smart card, yet this verifier leads to a Type-I offline password attack.

To eliminate this security issue without loss of usability, a promising countermeasure is to adopt the “fuzzy-verifier” technique [20] and store in ’s smart card, where specifies/confines the capacity of pair, . As a result, even if gets , she can not figure out the correct from the above attack, because there will be candidate pairs that make in Step 4. To further identify the exactly correct pair, needs to interact with the server, and we can adopt the “honeywords” technique [3, 56] to confine ’s advantage to a very limited value.

Type-II Attack. . In the above attack, does not need the protocol messages. In this attack, we assume that can somehow obtain user’s smart card and extract its secret parameters and also can eavesdrop the login messages , from the public channel. Now, can offline guess ’s password and identity simultaneously as follows:

Step 1. Guesses the value of , from dictionary space and .

Step 2. Computes , , where is extracted from the smart card.

Step 3. Computes .

Step 4. Computes .

Step 5. Computes .

Step 6. Checks the correctness of by comparing if the computed equals the intercepted .

Step 7. Repeats Steps 1~6 of the above procedure until find the correct value of .

The time complexity of the above attacking procedure is , and may complete the procedure within 44 days on a Laptop. In comparison, the Type-I attack is more practical.

3.2.2. No Forward Secrecy

A scheme that supports forward secrecy ensures that even after the long-term private key(s) of one or more participants were leaked, previously agreed session keys remain secure [27]. This is important, especially when considering the serious situations of today’s clouds like the compromise of cloud servers (e.g., [15]).

If an attacker has obtained the server ’s long-term key from the breached server and intercepted the messages that are exchanged between and ’s authentication process from the public channel. is able to figure out the session key using the following method:

Step 1. computes and

Step 2. computes , , ;

Step 3. calculates the session key .

With the session key computed, the entire session will be no secret to .

3.2.3. Poor Scalability

In Roy et al.’s scheme, the user side stores all the cloud servers (i.e., , ) related information: and for . This means that when a new server arrives, all the users have to reregister with the registration center . This shows poor scalability. Similarly, the server side stores all the users (i.e., , ) related information: the credentials (for ) in database of . This means that when a new user arrives, all the servers have to reregister with the registration center .

4. Revisiting Amin Et Al.’s Scheme

In 2018, Amin et al. [21] pointed out that previous schemes (e.g., [3537]) are vulnerable to various security loopholes and developed a new scheme for distributed cloud computing environments. However, here we show that this scheme still has several serious defects being overlooked (i.e., offline password guessing attack, no forward secrecy, and no user untraceability).

4.1. Review Amin Et Al.’s Scheme
4.1.1. Cloud Server Registration Phase

The registration phase is partitioned into two parts: cloud server registration and user registration. When the cloud server registers, chooses her identity , a random nonce , and sends to . Upon getting ’s registration request, the control server computes , , and sends to over a secure channel. Finally, keeps the secret data in a secure place (e.g., a usb-key).

4.1.2. User Registration Phase

When the user registers, she first prefers an identity , password , and 2 random nonces . Then, she computes , , , and sends to the securely. Once getting , conducts the following steps:

Finally, stores the parameters in the smartcard and delivers the smartcard for through a private communication channel. Then, stores in the card, where . Finally, the smartcard stores .

4.1.3. Login Phase

first inputs the smartcard into a card reader and keys and on the reader. Then, calculates

Then, the card reader checks whether . If , it means that and . Then, produces a 128 bit random nonce and computes

where is the identity of the cloud server from which by wants to login. Then, sends the login request to publicly.

4.1.4. Authentication Phase

This phase is to achieve mutual authentication and key agreement among , , and .

Step 1. first verifies whether , where is the cloud server’s current timestamp and is the allowed transmission delay time. If the equality is not true, rejects the connection; otherwise, generates a 128 bit random nonce and computesThen, sends , to the over a public channel.

Step 2. On getting login messages, first checks whether , where is the cloud server’s current timestamp and the expected delay time for transmission. If the equality is not true, rejects the connection; otherwise, computesThen, checks whether . If , deems as legal; otherwise, rejects the connection. Then, computesOnce again, checks . If , deems as legal; otherwise, it rejects the connection. Then, selects a 128 bit random nonce and computeswhere is the agreed session key. Then, sends to .

Step 3. On getting the reply from , calculatesThen, verifies or not and if , rejects the connection, and then sends to publicly.

Step 4. On getting , calculatesThen, verifies and if , it demonstrates the authenticity of and . Finally, mutual authentication are attained among , and . Now, and share the same session key , and they can exchange sensitive information subsequently using .

4.1.5. Password Change Phase

This phase is performed locally: not interacting with the server. When wants to update her password, she provides and after inputting the smartcard. Then, executes the operations:

The smartcard verifies . If , user is asked to enter a new password and calculates

Finally, substitutes with , respectively, in the card.

4.2. Cryptanalysis of Amin Et Al.’s Scheme

Recall that the three assumptions listed in Section 2.2.1 are also clearly made in Amin et al.’s scheme [21]. However, we observe that this scheme still remains feasible for an attacker to offline guess a user’s password. This means that the primary goal of “truly two-factor security” cannot be satisfying. In addition, the scheme cannot provide forward secrecy and user untraceability.

4.2.1. Offline Password Guessing Attack

We find Amin et al.’s scheme cannot achieve truly two-factor security: it is subject to two types of offline password guessing attack when the smart card factor is compromised.

Type-I Attack. . Suppose the secret parameters , stored in ’s smart card are somehow obtained by . At this point, can find out ’s identity and password as follows:

Step 1. Guesses ’s identity and password from dictionary space and .

Step 2. Computes , where is extracted from the smart card.

Step 3. Computes ;

Step 4. Computes , where is extracted from the smart card.

Step 5. Computes ;

Step 6. Computes ;

Step 7. Checks the validity of by comparing the computed with which is extracted from card.

Step 8. Repeats Steps 1~7 until determine the right pair of .

The time complexity of this attack is [3, 16]. According to the running time in [16], may complete the above attacking procedure within 35.2 days on a Laptop. This issue arises due to the inherent “usability-security tension”: to achieve local password change (i.e., C-2 in [3]) and timely typo detection (i.e., C-9 in [3]); there is an explicit password verifier = stored in ’s smart card, yet this verifier leads to a Type-I offline password attack.

To tackle this security issue while not losing usability, a viable countermeasure is to adopt the “fuzzy-verifier” technique [20] and keep in ’s smart card, where confines the capacity of pair, . As a result, even if obtains , she can not identify the correct from the above attack, because there will be candidate pairs that make in Step 4. To further identify the exactly correct pair, needs to interact with the server, and we can adopt the “honeywords” technique [3, 56] to confine ’s advantage to a very limited value.

Type-II Attack. . In the above attack, does not need the protocol messages. In this attack, we assume that can somehow obtain user’s smart card and extract its secret parameters and can also eavesdrop the login messages , from the public channel. Now, can offline guess ’s password and identity simultaneously as follows:

Step 1. Guesses the value of , from dictionary space and .

Step 2. Computes , where is extracted from the smart card.

Step 3. Computes ;

Step 4. Computes .

Step 5. Computes ;

Step 6. Computes ;

Step 7. Checks the correctness of by comparing if the computed equals the intercepted .

Step 8. Repeats Steps 1~7 of the above procedure until the correct value of is found.

The time complexity of the above attacking procedure is , and may complete the procedure within 26.4 days on a Laptop. In comparison, the Type-I attack is more practical. Amin et al. noted that user’s mobile devices and IoT sensors are generally of “low memory, low power, and battery and network limitations” [21], and thus they prefer to only use lightweight symmetric key techniques to achieve robust security. It is just this motivation that makes their scheme vulnerable to the Type-II offline password guessing attack. And the rationales can be found in [20, 57].

4.2.2. No Forward Secrecy

A scheme that supports forward secrecy ensures that even after the long-term private key(s) of one or more participants was(were) leaked, previously agreed session keys remain secure [27]. This is important, especially when considering the serious situations of today’s clouds like the compromise of cloud servers (e.g., [15]).

If an attacker has obtained the cloud server ’s long-term key from the breached server and intercepted the messages ; that are exchanged between and ’s authentication process from the public channel. is able to figure out the session key using the following method:

Step 1. computes ;

Step 2. computes ;

Step 3. computes ;

Step 4. calculates the session key .

With the session key computed, the entire session will be no secret to . This vulnerability is due to a result of violating the “forward secrecy principle” given in [20]: public-key technique is necessary to attain forward secrecy and at least two exponential operations (or point multiplications in ECC) are needed at the server side.

4.2.3. No User Untraceability

As revealed in [22], in the context of user authentication, there are two types of user anonymity: the basic one, i.e., user identity-protection which requires that the attacker is unable to get the target user’s real identity from eavesdropping the protocol messages; the advanced one, i.e., user untraceability which guarantees that the attacker is unable to neither figure out the target user’s identity nor determine whether two conversations are come from the same (unknown) user from eavesdropping the protocol messages. Therefore, most schemes (e.g., [4, 35, 39, 5862]) that aim to preserve user anonymity attempt to fulfil the latter advanced notion of user anonymity. However, in Amin et al.’s scheme [21], the pseudoidentity is sent in every login request. Thus, the attacker can track all the login activities through this static pesudoidentity .

5. Revisiting Wei Et Al.’s Scheme

In 2018, Wei et al. [23] observed that most of previous schemes (e.g., [3640]) only provided some heuristic security arguments and little attention has been to the formal treatment of protocol security. Accordingly, they employed an authenticated encryption scheme to construct a new two-factor scheme that can provide provable security in the random oracle model. Though this scheme is armed with a formal proof, we will show that this scheme still has several serious defects being overlooked: it cannot achieve the primary goal of “truly two-factor security”; it provides no forward secrecy; it ensures no user untraceability.

5.1. Review Wei Et Al.’s Scheme

There are three phases in et al.’s scheme: registration, authentication and key exchange, and password update.

5.1.1. Registration Phase

When the user registers, she first prefers an identity , password , and a random nonces ; then calculates and sends to the gateway node via a secure channel. On receiving , computes and . also selects ’s pseudoidentity and keeps the item in its database. Finally, produces a smart card with security parameters and sends to the card via a trusted channel. Then, adds the random number into the card.

5.1.2. Authentication and Key Exchange Phase

aims to access the service from the cloud server , executes the authentication and key exchange phase with and as follows.(1) inserts her card into the card reader, keys her identity , and password . The card computes and gets . Then, the card calculates a key , where is the current timestamp in ’s system. The card also selects a random nonce and encrypts using an authenticated encryption scheme to obtain . Finally, the card transmits the message to .(2)Upon receiving at time , verifies whether or not, where stands for the largest time interval allowed for the transmission delay. If the check passes, retrieves ’s real identity in the database using and calculates . then decrypts and recovers . If the decryption fails, the connection is rejected; otherwise, is verified by . calculates a key , where is the current timestamp at . Then, encrypts using an authenticated encryption scheme to obtain . Finally, transmits to the server .(3)On getting at time , the server verifies if . If it is true, calculates and decrypts and calculates . If the decryption fails, the connection is rejected; otherwise, computes , where is the current timestamp at . Then, selects a random number and encrypts using to get . transmits to . Finally, calculates the session key and accepts .(4)On getting at time , checks if . If it holds, calculates and decrypts . If the decryption does not fail, deems the session as valid and computes .

Finally, and share the common session key .

5.1.3. Password Updating Phase

This phase is executed when aims to update her password with a new one. Because this phase has little relevance with the following cryptanalysis, we omit it.

5.2. Cryptanalysis of Amin Et Al.’s Scheme

Recall that the three assumptions listed in Section 2.2.1 are also clearly made in Wei et al.’s scheme [23]. Though this scheme enjoys many desirable attributes such as rigorous security model and the introduction of an authenticated encryption scheme (i.e., Hoang et al.’s AEZ [63]), we now show its defects.

5.2.1. Offline Password Guessing Attack

We find Amin et al.’s scheme cannot achieve truly two-factor security: it is subject to Type-II offline password guessing attack as illustrated in Section 4.2.1.

Type-II Attack. . In this attack, we assume that can somehow obtain user’s smart card and extract its secret parameters and also can eavesdrop the login messages from the public channel. Now, can offline guess ’s password and identity simultaneously as follows:

Step 1. Guesses the value of , from dictionary space and .

Step 2. Computes , where is extracted from the smart card.

Step 3. Computes , where is extracted from the smart card.

Step 4. Computes ;

Step 5. Decrypts with ;

Step 6. If the above decryption succeeds, it indicates that and are correct and terminate.

Step 7. Repeats Steps 1~5 of the above procedure until find the correct value of .

The time complexity of the above attacking procedure is , and may finish the attack within 26.4 days on a common PC. In comparison, the Type-I attack is more realistic. Wei et al. noted that user’s mobile devices and IoT sensors are generally resource-constrained and made an attempt to design a secure and efficient scheme “without using computation-expensive public key operations” [23]. It is just this motivation that makes their scheme vulnerable to the Type-II offline password guessing attack. And the rationales are referred to [20, 57].

5.2.2. No Forward Secrecy

As with Amin et al.’s scheme [21], Wei et al.’s scheme also only employs symmetric key techniques and thus violates the “forward secrecy principle” proposed in [20], and see more in Section 4.2.2. We now show the details.

If an attacker has obtained the cloud server ’s long-term key from the breached server and intercepted the messages that are exchanged among , , and ’s authentication process from the public channel, is able to figure out the session key using the following method:

Step 1. computes ;

Step 2. decrypts using to obtain =;

Step 3. calculates ;

Step 4. decrypts using to obtain = ;

Step 5. calculates the session key .

5.2.3. No User Un-Traceability

As with Amin et al.’s scheme [21], Wei et al.’s scheme also only employs the pseudo-identity technique to preserve user anonymity, and this breaches the “anonymity principle” proposed in [22]: under the non-tamper resistant assumption of smart cards, public-key primitives are necessary for achieving user un-traceability for two-factor user authentication schemes. In Wei et al.’s scheme [21], the static pseudo-identity is sent in every login request. Thus, the attacker can track all the login activities through this static pesudo-identity .

6. Conclusion

A large amount of efforts have been devoted to the design of smart-card-based password authentication scheme, yet it still remains an open challenge to devise an efficient, secure, and privacy-preserving scheme under the assumption that smart cards can be tampered. Very recently, Wu-Xu, Roy et al., Amin et al., and Wei et al. made four other attempts. However, through careful analysis we show that all of them still have several serious drawbacks being overlooked (see Table 2), and most these drawbacks are due to violation of basic protocols design principles (e.g., [3, 20]). Taking our attacks in mind, we are considering designing an efficient two-factor scheme with provable security.

Data Availability

Data sharing is not applicable to this article as no new data was created or analyzed in this study.

Disclosure

Part of this paper was presented at the 4th International Conference on Cloud Computing and Security (ICCCS 2018) [14].

Conflicts of Interest

The authors declare that no conflicts of interest exist.

Acknowledgments

This research was in part supported by the National Key Research and Development Plan under Grant No. 2016YFB0800600, by the National Natural Science Foundation of China under Grant No. 61802006, by the National Key Research and Development Plan under Grant No. 2017YFB1200700, and by China Postdoctoral Science Foundation under Grant No. 2018M640026.