A Robust and Effective Smart-Card-Based Remote User Authentication Mechanism Using Hash Function

Abstract

In a remote user authentication scheme, a remote server verifies whether a login user is genuine and trustworthy, and also for mutual authentication purpose a login user validates whether the remote server is genuine and trustworthy. Several remote user authentication schemes using the password, the biometrics, and the smart card have been proposed in the literature. However, most schemes proposed in the literature are either computationally expensive or insecure against several known attacks. In this paper, we aim to propose a new robust and effective password-based remote user authentication scheme using smart card. Our scheme is efficient, because our scheme uses only efficient one-way hash function and bitwise XOR operations. Through the rigorous informal and formal security analysis, we show that our scheme is secure against possible known attacks. We perform the simulation for the formal security analysis using the widely accepted AVISPA (Automated Validation Internet Security Protocols and Applications) tool to ensure that our scheme is secure against passive and active attacks. Furthermore, our scheme supports efficiently the password change phase always locally without contacting the remote server and correctly. In addition, our scheme performs significantly better than other existing schemes in terms of communication, computational overheads, security, and features provided by our scheme.

1. Introduction

In recent years, the remote user authentication using smart cards has become an important research area in computer science. In remote user authentication, communicating parties are verified as to whether they are genuine and trustworthy and the users are authenticated by a remote server before allowing access to services. Several password-based schemes (e.g., [1–3]) or biometric-based schemes (e.g., [4–6]) have been proposed for remote user authentication problem. An idle password-based remote user authentication scheme using smart cards needs to satisfy the following requirements [2]:(i)not maintaining verification tables;(ii)user’s ability to freely choose and update password;(iii)resistance to password disclosure to the server;(iv)prevention of masquerade attacks;(v)resistance to replay, modification, parallel session, and stolen-verifier attacks;(vi)an easy-to-remember password;(vii)low communication cost and computation complexity;(viii)achieving mutual authentication between login users and remote servers;(ix)resistance to guessing attacks even if the smart card is lost or stolen by attackers;(x)session key agreement;(xi)resistance to insider attacks;(xii)prevention of smart card security breach attacks.

The majority of the proposed password-based remote user authentication schemes are either computationally expensive or vulnerable to different known attacks. Some comprehensive surveys on password-based remote user authentication schemes could be found in [7, 8]. Das et al. [9] proposed a dynamic ID and password-based remote user authentication scheme using smart cards, which uses the efficient hash function and bitwise XOR operations. However, Wang et al. [10] showed that Das et al.’s scheme is vulnerable to different attacks and it does not achieve mutual authentication property and does not resist impersonating remote server attack. Wang et al. then proposed an enhancement of their scheme using smart cards. Later, Khan et al. [11] analyzed the security of Wang et al.’s scheme and they showed that Wang et al.’s scheme has several weaknesses, for example, it does not provide anonymity of a user during authentication, the user has no choice in choosing his/her password, it is vulnerable to insider attack, it has no provision for revocation of lost or stolen smart card, and, finally, it does not provide session key agreement. In order to remedy these security weaknesses, Khan et al. also proposed an enhanced password-based remote user authentication scheme using smart cards.

In 2012, Sonwanshi et al. [3] proposed a password-based remote user authentication scheme using the smart card, which uses only the one-way hash function and bitwise XOR operation. However, in 2013, Das et al. [12] showed that their scheme is vulnerable to the offline password guessing attack and stolen smart card attack. In addition, Das et al. showed that their scheme fails to protect strong replay attack. In 2013, Lee and Liu [13] proposed a password-based authentication and key agreement scheme, which uses the public-key cryptosystem and one-way hash function. Lee-Liu’s scheme is expensive in computation as it requires expensive modular exponentiation operations. Lee-Liu’s scheme supports session key security and protects against parallel session attack, password guessing attack, privileged insider attack, replay attack, and man-in-the-middle attack. Their scheme also provides user's anonymity property. In 2013, Das and Bruhadeshwar [14] showed that Lee-Liu’s scheme has two security weaknesses: (1) it has design flaws in authentication phase and (2) it has design flaws in password change phase. In order to withstand these flaws found in Lee-Liu’s scheme, they proposed an improved and effective password-based remote user authentication scheme. However, Das-Bruhadeshwar’s scheme [14] is also computationally costly as it requires expensive modular exponentiation operations. Recently, in 2013, Jiang et al. [15] proposed a secure password-based remote user authentication scheme without pairings for multiserver architecture. However, their scheme uses ECC (elliptic curve cryptography) cryptosystem and hash function. Due to expensive ECC point addition and scalar multiplication operations, their scheme is also expensive.

In this paper, we propose a new robust and secure password-based remote user authentication scheme using the one-way hash function and bitwise XOR operation only. The rest of this paper is organized as follows. In Section 2, we give a mathematical background on the one-way hash function, which will be helpful for describing and analyzing our scheme. In Section 3, we propose our new robust and secure password-based remote user authentication scheme. In Section 4, we analyze our scheme under different possible attacks using both the informal and formal security analysis. In Section 5, we perform the simulation for the formal security analysis using the widely accepted AVISPA (Automated Validation of Internet Security Protocols and Applications) tool to ensure that our scheme is secure against passive and active attacks. In Section 6, we compare the performance of our scheme with the recently proposed password-based remote user authentication schemes [3, 13–15]. Finally, we conclude the paper in Section 7.

2. Mathematical Preliminaries

In this section, we discuss the properties of one-way hash function for describing and analyzing our scheme.

A hash function is a one-way function, which takes an arbitrary-length binary string input and outputs a fixed-length (e.g., -bit) binary string, called the message digest or hash value . In addition, it has the following important properties [16].(i) can be applied to a data block of all sizes.(ii)For any given input , it is relatively easy to compute the hash value , which enables easy implementation in software and hardware.(iii)Output length of is fixed.(iv)One-way property: from a given hash value and the given hash function , it is computationally infeasible to derive the input .(v)Weak-collision resistance property: for any given input , finding any other input , with , such that is computationally infeasible.(vi)Strong-collision resistance property: finding a pair of inputs , with , such that is also computationally infeasible.

An example of such a one-way function is SHA-1 [17], which has the above desired properties. At present, the National Institute of Standards and Technology (NIST) does not recommend SHA-1 for top secret documents. In 2011, Manuel [18] showed the collision attacks on SHA-1. Quark [19] is a family of cryptographic hash functions, which is designed for extremely resource-constrained environments like sensor networks and radiofrequency identification tags. Like most one-way hash functions, Quark can be used as a pseudorandom function, a message authentication code, a pseudorandom number generator, a key derivation function, and so forth. Quark performs better than the SHA-1 hash function. Thus, Quark can be used for the one-way function. However, in this paper, as in [14, 20, 21], we can use SHA-2 as the secure one-way hash function in order to achieve top security, whereas we use only 160 bits from the hash digest output of SHA-2 in our scheme and other schemes.

3. The Proposed Scheme

In this section, we propose a new remote user authentication scheme using password, which is based on smart card. For this purpose, we first discuss the threat model used in our scheme. We then discuss the various phases related to our scheme.

3.1. Notations

For describing and analyzing our scheme, we use the notations listed as follows: : user, : remote server, : identity of user , : password of user , : permanent secret key only known to the remote server , : secret number only known to the user , : current system timestamp of an entity , : random nonce generated by an entity , : secure one-way collision-resistant hash function, : data concatenating with data , : bitwise XOR operation of and .

3.2. Threat Model

In our scheme, we make use of the Dolev-Yao threat model [22]. In this model, two communicating parties communicate over an insecure channel. Any adversary (attacker or intruder) can thus eavesdrop on the transmitted messages over the public insecure channel and he/she has the ability to modify, delete, or change the contents of the transmitted messages. Usually, the smart card issued to a user is equipped with tamper-resistant device. However, in this paper, we still assume that once a user’s smart card is stolen or lost, the attacker will know all the sensitive information stored in the smart card’s memory by monitoring the power consumption of the smart card [23, 24].

3.3. Motivation

The majority of the proposed password-based remote user authentication schemes are either computationally expensive or vulnerable to different known attacks [7, 8]. Though Sonwanshi et al.’s scheme [3] is very efficient due to usage of one-way hash function and bitwise XOR operations, Das et al. [12] showed that their scheme is vulnerable to the offline password guessing attack and stolen smart card attack. In addition, Das et al. showed that their scheme fails to protect strong replay attack. Lee-Liu’s scheme [13] is expensive in computation as it requires expensive modular exponentiation operations. Further, Das and Bruhadeshwar [14] showed that Lee-Liu’s scheme has security weaknesses. In order to withstand the flaws found in Lee-Liu’s scheme, they proposed an improved and secure password-based remote user authentication scheme. However, Das-Bruhadeshwar’s scheme [14] is also computationally costly as it requires expensive modular exponentiation operations as in Lee-Liu’s scheme [13]. The recently proposed Jiang et al.’s scheme [15] uses ECC cryptosystem and hash function. Due to expensive ECC point addition and scalar multiplication operations, their scheme is also expensive, though their scheme is secure against different attacks. Thus, we feel that there is a great need to propose a new robust and secure password-based remote user authentication scheme which will satisfy the requirements listed in Section 1. Our scheme withstands the security flaws found in Sonwanshi et al.’s scheme [3] and it is also very efficient as our scheme relies only on lightweight operations like the one-way hash computations and bitwise XOR operations.

3.4. Different Phases

In this section, we describe the four phases related to our scheme, namely, the registration phase, the login phase, the authentication phase, and the password change phase. In the registration phase, a user needs to register to access services from a remote server . After registering, the server will issue a smart card containing important information stored in the smart card’s memory. In the login phase, if the user wants to access services from the server , the user needs to login to the system providing his/her identity and password with the help of his/her smart card issued by the registration server. In the authentication phase, the server authenticates the user and the user also authenticates the server . After mutual authentication between and , both and establish a secret common session key shared between them so that they communicate securely using that established key in future.

3.4.1. Registration Phase

This phase consists of the following steps.

Step R1. The user first selects his/her own secret identity and chooses a strong (not low-entropy or weak) password .

Step R2. then generates a secret -bit number randomly, which is kept secret to only.

Step R3. then computes the masked password using , , and as and sends the registration request message to the registration remote server via a secure channel.

Step R4. After receiving the registration request message in Step R3, the server generates a -bit secret number randomly, which is kept secret to only.

Step R5. then computes and . further computes and as in [20]. Here is a random and temporary identity for the user , which is used instead of the permanent identity to achieve the user anonymity.

Step R6. Finally, issues a smart card containing the information and sends it to the user via a secure channel.

After receiving the smart card from , stores the secret number into the smart card’s memory. The summary of the registration phase is given in Table 1.

Table 1 

Summary of the registration phase of our scheme.

3.4.2. Login Phase

In this phase, the following steps are executed.

Step L1. first inserts his/her smart card into a card reader of the specific terminal. then inputs his/her identity and password .

Step L2. computes the masked password as using the secret number stored in its memory. then computes and checks if the condition holds. If this condition holds, passes password verification and the next step is executed. Otherwise, this phase terminates immediately.

Step L3. computes and . generates a -bit random nonce and then computes , where is the current system timestamp, and . sends the login request message to the server via a public channel.

The summary of the login phase is given in Table 2.

Table 2 

Summary of the login phase of our scheme.

3.4.3. Authentication Phase

After receiving the login request message from the user , the server checks the format of and then finds the entry in its maintained ID database table. If it is found, performs Case 1; otherwise, proceeds to Case 2.

Case 1. Consider the following.
Step A1. checks the validity of the timestamp in the received message by the condition , where is the current system timestamp of and the expected transmission delay. If this condition is satisfied, computes , using its own secret number . After that computes then verifies the condition whether holds. If it does not hold, rejects the login request message and this phase terminates immediately.

In order to protect the man-in-the-middle attacks and the replay attacks, we can adopt the same strategy as in [4, 20]. The server stores the pair , where , in its database. Suppose the server receives the next login request message from the user or an attacker. first checks the validity of the timestamp and if it is valid, it further computes , using its own secret number . After that computes, say, . If , it ensures that the login request message is a replay one. Otherwise, updates with in its database. Thus, it is noted that the timestamp and random nonces are used together to defend the replay and man-in-the-middle attacks.

Step A2. generates a random nonce and then computes , where is the current system timestamp of the server , , where is a random and temporary identity generated by , and . then sends the authentication request message to the user via a public channel.

Step A3. After receiving the message in Step A2, checks the validity of the timestamp in the received message with the condition , where is the current system timestamp of and the expected transmission delay. If this condition does not hold, the phase terminates immediately. Otherwise, computes further computes and checks the condition . If it does not hold, this phase terminates immediately. Otherwise, on the other hand, updates and with and , respectively, in its memory.

Step A4. computes and sends the authentication acknowledgment message to the server via a public channel. also computes a secret session key shared between and as .

Step A5. After receiving the authentication acknowledgment message from the user in Step A4, computes and verifies whether the condition holds. If it holds, authenticates the user and also computes the same secret session key shared with as . Thus, after successful authentication, both and can communicate securely using the established secret session key.

Case 2. This case remains almost the same as Case 1 except the following in Step A6.

Step A6. is obtained by computing instead of in Step L3 of the login phase. The smart card of the user in this case only needs to update with without changing in Step A3.

The summary of the authentication phase is given in Table 3.

Table 3 

Summary of the authentication phase of our scheme.

3.4.4. Password Change Phase

To enhance security, a user needs to change his/her password. Let want to change his/her password with a new password . For this phase, the following steps are executed by the smart card of the user without contacting the remote server .

Step P1. first inserts his/her smart card into a card reader of the specific terminal and then inputs identity and provides old password .

Step P2. then computes masked password using the secret number stored in its memory and . checks if the condition holds. If it does not hold, the old password verification fails and this phase terminates immediately. Otherwise, asks the user to input his/her chosen strong (high-entropy) password , where .

Step P3. computes further computes and .

Step P4. Finally, updates with , with , with , and with in its memory.

Thus, it is clear that our scheme provides efficient password change phase in order to change the password of a user at any time locally and correctly without further contacting the remote server .

4. Security Analysis of the Proposed Scheme

In this section, we first show the correctness of our proposed scheme. We then provide informal and formal security analysis to show that our scheme is secure against various known attacks.

4.1. Correctness

In Theorem 1, we provide the correctness of our scheme.

Theorem 1. The proposed scheme always establishes the correct secret session key between the user and the server during the authentication phase after the successful mutual authentication between them.

Proof. During the authentication phase of our scheme, in Steps A4 and A5, after the successful mutual authentication the user and the server compute a secret session key between them. Note that, in Step A4, computes the secret session key shared between and as , where and . Thus, .
On the other side, the server in Step A5 computes the secret session key shared with as , where and . As a result, . Hence, the theorem follows.

4.2. Informal Security Analysis

In this section, through the informal security analysis we show that our scheme has the ability to defend the various known attacks, which are discussed in the following subsections.

4.2.1. Replay Attack

Suppose an attacker intercepts the login request message during the login phase, where and , and starts a new session with the message . According to our policy, the server stores the pair , where , in its database. first checks the validity of the timestamp and if it is valid, it further computes , using its own secret number . After that computes, say, . If , it ensures that the login request message is a replay one. Since the transmission delay time is short, even if the attacker replays the same login request message during that time, our scheme prevents this as a replay message due to verification of random nonce attached to the message with that in the stored database. As a result, both the timestamp and random nonce together help to defend strongly the replay attack in our scheme.

4.2.2. Man-in-the-Middle Attack

Suppose an attacker intercepts the login request message during the login phase, where and . In order to make success in the man-in-the-middle attack, the attacker has to change and properly so that the server can authenticate the message successfully. Assume that the attacker uses a timestamp and wants to change and to and , respectively. However, for the attacker needs to know both and which are unknown to that attacker. As pointed out in [20], the probability of guessing an identity composed of exact characters is approximately . Thus, to correctly know and from , the attacker has to guess both and at the same time using and the probability of guessing both composed of exact characters and composed of bits bits in our scheme) at the same time becomes approximately . If , then this probability is approximately , which is very negligible. As a result, the attacker does not have any ability to succeed in this attack and, hence, our scheme is secure against the man-in-the-middle attack.

4.2.3. Impersonation Attack

In this attack, the purpose of an attacker is to impersonate the remote server or a legal user in order to cheat the other party. Suppose an attacker intercepts the login request message during the login phase and wants to start a new session. In order to start a new session, the attacker has to modify both and . However, as discussed in Section 4.2.2, to change the attacker has to guess/know both and , which are unknown to the attacker. Thus, the probability of guessing both composed of exact characters and composed of bits bits in our scheme) at the same time becomes approximately , which is also very negligible. Hence, our scheme prevents the impersonation attack.

4.2.4. Stolen Smart Card Attack

In this attack, we assume that the smart card of a legal user is lost or stolen by an attacker. Then the attacker can extract all the secret information from the memory of the stolen or lost smart card of the user using the power analysis attacks [23, 24]. Note that and . The attacker can derive . In order to know the secret information of the server , the attacker needs to guess both and . The probability of guessing both composed of exact characters and composed of bits bits in our scheme) at the same time becomes approximately , which is very negligible. Again, to derive the password composed of characters, the attacker needs to also guess using . Thus, the probability of guessing both composed of exact characters and composed of exact characters at the same time becomes approximately , which is also negligible. Hence, our scheme prevents the stolen smart card attack.

4.2.5. Password Guessing Attack

In this attack, we consider both offline and online password guessing attacks. As in Section 4.2.4, we assume that the smart card of a legal user is lost or stolen by an attacker and all the secret information stored in the memory of the smart card is known to the attacker. Still then the attacker can not guess correctly the password of offline, which is evident from Section 4.2.4.

Suppose the attacker intercepts all the transmitted messages during the login phase and and during the authentication phase. However, none of these messages involves the password of the user . As a result, these messages will not be helpful to the attacker to obtain of online. Thus, our scheme is secure against both offline and online password guessing attacks.

4.2.6. Denial-of-Service Attack

Note that, in our scheme, the smart card of a legal user stores and for the previous and the latest random identities, respectively. Thus, the corruption of the message during the authentication phase is not possible by an attacker and, hence, our scheme prevents the denial-of-service attack.

4.2.7. User Anonymity

In our scheme, all the transmitted messages include the identity of a legal user indirectly and it is protected by the one-way secure hash function . Due to the collision-resistant property of , it is computationally infeasible for an attacker to derive .

Even if we assume that the smart card of a legal user is lost or stolen by an attacker and all the secret information stored in the memory of the smart card is known to the attacker, from and from the intercepted login request message the attacker can compute . Again, is protected by the one-way secure hash function . Due to the collision-resistant property of , it is computationally infeasible for an attacker to derive . Hence, our scheme preserves the user anonymity property.

4.2.8. Mutual Authentication

During the authentication phase, after receiving the authentication request message from the server , the smart card of a legal user computes and checks the condition . If it holds, authenticates the server and then only sends the authentication acknowledgment message to the server . After that the server also computes and verifies whether the condition holds. If it holds, authenticates the user . Hence, the mutual authentication is always performed in our scheme.

4.2.9. Session Key Security

After mutual authentication, the smart card of a legal user computes the secret session key shared between and as . The server also computes the secret session key shared with the user as , where and . It is also evident from Theorem 1 that . In order to compute the secret key from all the transmitted messages during the login and authentication phases, an attacker has to guess/derive correctly composed of exact characters, of bits, and and , each composed of bits at the same time, and, thus, the probability of deriving this secret key is approximately , which is very negligible. As a result, our scheme also provides the session key security.

4.3. Formal Security Analysis

For the formal security analysis, we follow the formal definition of a one-way hash function given in Definition 2.

Definition 2 (one-way hash function [25, 26]). A one-way collision-resistant hash function is a deterministic function that takes the input as an arbitrar-length binary string and outputs a binary string of fixed length . We formalize an adversary ’s advantage in finding collision in the following manner: where denotes the probability of an event and denotes that the pair is selected randomly by . The adversary is allowed to be probabilistic and the probability in the advantage is computed over the random choices made by the adversary with the execution time . The hash function is called collision resistant, if , for any sufficiently small .

We then define the following random oracle for our formal security analysis.(i)Reveal. This random oracle will unconditionally output the input from the corresponding hash value .

In Theorems 3 and 4, we show that our scheme is secure against an adversary for deriving the secret number of the server and the password of a user .

Theorem 3. Under the assumption that a one-way hash function closely behaves like a random oracle, the proposed scheme is provably secure against an adversary for deriving the secret number of the server .

Proof. We follow the same proof presented in [14, 27, 28]. In this proof, we construct an adversary such that he/she can derive the secret number of the server correctly. For this purpose, the adversary runs the experiment, , for our robust and effective smart-card-based remote user authentication scheme, say, REUAS given in Algorithm 1.
We now define the success probability for as . Then the advantage of becomes , where the maximum is taken over all with the execution time and the number of queries made to the oracle. We call that our scheme is provably secure against the adversary for deriving the secret number of the server , if , for any sufficiently small .
Consider the experiment provided in Algorithm 1. According to this experiment, if the adversary has the ability to invert the hash function , then only he/she can derive the secret number of the server and win the game. However, according to Definition 2, it is a computationally infeasible (hard) problem for inverting a one-way hash function . Since , for any sufficiently small , we have , as it is dependent on the former. As a result, the adversary does not have any ability to derive the secret number of the server .

(1)   Eavesdrop the login request message 𝑁𝐼𝐷∗𝑖,𝑀2,𝑀3,𝑇𝑐 during the login phase,     where 𝑀2=𝑀1⊕𝑅𝑐⊕𝑇𝑐 =ℎ(𝐼𝐷𝑖‖𝑋𝑠)⊕𝑅𝑐⊕𝑇𝑐 and 𝑀3=ℎ(𝐼𝐷∗𝑖‖𝑅𝑐‖𝑇𝑐). (2)   Call 𝑅𝑒𝑣𝑒𝑎𝑙 oracle on input 𝑀3 to retrieve the information 𝐼𝐷𝑖, 𝑅𝑐 and 𝑇𝑐 as (𝐼𝐷′𝑖‖𝑅′𝑐‖𝑇′𝑐) ←𝑅𝑒𝑣𝑒𝑎𝑙(𝑀3). (3)   Using the retrieved information 𝑅′𝑐 and 𝑇′𝑐, compute 𝑢= 𝑀2⊕𝑅′𝑐⊕𝑇′𝑐, which needs to be ℎ(𝐼𝐷𝑖‖𝑋𝑠). (4)   Call 𝑅𝑒𝑣𝑒𝑎𝑙 oracle on the computed input 𝑢 to retrieve the secret number 𝑋𝑠 of the     server 𝑆𝑗 as (𝐼𝐷𝑖′′‖𝑋′𝑠) ←𝑅𝑒𝑣𝑒𝑎𝑙(𝑢). (5)   if  𝐼𝐷′𝑖=𝐼𝐷𝑖′′  then (6)     Accept 𝑋′𝑠 as the correct secret number 𝑋𝑠 of the server 𝑆𝑗. (7)    return 1 (Success) (8)   else (9)   return 0 (Failure) (10) end if

Algorithm 1 

𝐸𝑋𝑃1^{𝐻𝐴𝑆𝐻}_{𝒜,𝑅𝐸𝑈𝐴𝑆}.

Theorem 4. Under the assumption that a one-way hash function closely behaves like a random oracle, the proposed scheme is provably secure against an adversary for deriving the password of a user , even if the smart card of   is lost or stolen by that adversary.

Proof. We need to construct an adversary such that he/she can derive the password of the user correctly after extracting the information stored in the stolen or lost smart card of . For this purpose, the adversary runs the experiment, , which is provided in Algorithm 2.
Similar to the experiment given in Algorithm 1, we also define the success probability for as and the advantage of as , where the maximum is taken over all with the execution time and the number of queries made to the oracle. Our scheme is then provably secure against the adversary for deriving the password of the user , if , for any sufficiently small .
Now, consider the experiment provided in Algorithm 2. After extracting all the secret information from the memory of the stolen or lost smart card of the user , the adversary can derive the password of the user and win the game, if he/she has the ability to invert the one-way hash function . Since inverting the one-way hash function is computationally infeasible, that is, , for any sufficiently small , we have , as it is dependent on the former. Hence, our scheme is provably secure against an adversary for deriving the password of a user , even if the smart card of is lost or stolen by that adversary.

(1) Extract all the secret information (𝑟𝑖,𝑒𝑖,𝑇𝐷𝑖,𝐷𝑖,𝐾) from the memory of the stolen or lost smart  card 𝐶𝑖 of the user 𝑈𝑖 using the power analysis attacks [23, 24]. (2) Call 𝑅𝑒𝑣𝑒𝑎𝑙 oracle on input 𝑟𝑖 in order to retrieve 𝐼𝐷𝑖 and 𝑅𝑃𝑊𝑖 as (𝐼𝐷′𝑖,𝑅𝑃𝑊′𝑖) ←𝑅𝑒𝑣𝑒𝑎𝑙(𝑟𝑖). (3) Call 𝑅𝑒𝑣𝑒𝑎𝑙 oracle on input 𝑅𝑃𝑊′𝑖 to retrieve 𝐼𝐷𝑖, 𝐾 and 𝑃𝑊𝑖 as (𝐼𝐷𝑖′′‖𝐾′′‖𝑃𝑊′𝑖) ←𝑅𝑒𝑣𝑒𝑎𝑙(𝑅𝑃𝑊′𝑖). (4) if (𝐼𝐷′𝑖=𝐼𝐷𝑖′′) and (𝐾=𝐾′′) then (5)  Accept 𝑃𝑊𝑖′′ as the correct password 𝑃𝑊𝑖 of the user 𝑈𝑖. (6)  return 1 (Success) (7) else (8)  return 0 (Failure) (9) end if

Algorithm 2 

𝐸𝑋𝑃2^{𝐻𝐴𝑆𝐻}_{𝒜,𝑅𝐸𝑈𝐴𝑆}.

5. Formal Security Verification Using AVISPA Tool

In this section, through the simulation results for the formal security verification using the widely accepted AVISPA tool [20, 21, 27, 28] we show that our scheme is secure against passive and active attacks.

AVISPA (Automated Validation of Internet Security Protocols and Applications) is considered as a push-button tool for the automated validation of Internet security-sensitive protocols and applications [29]. AVISPA has four different back-ends that implement a variety of state-of-the-art automatic analysis techniques. The back-ends are the On-the-Fly Model-Checker (OFMC), Constraint Logic based Attack Searcher (CL-AtSe), SAT-based Model-Checker (SATMC), and Tree Automata based on Automatic Approximations for the Analysis of Security Protocols (TA4SP). The protocols to be analyzed under the AVISPA tool require specifying them in a language, called HLPSL (High Level Protocols Specification Language), which is a role-oriented language. The specification in HLPSL is first translated into a low-level specification by a translator, which is called the hlpsl2if. hlpsl2if generates a specification in an intermediate format, which is known as the intermediate format (IF). The output format (OF) of AVISPA is generated using one of the four back-ends: OFMC, CL-AtSe, STAMC, and TA4SP. The analysis of the OF is made as follows. The first printed section, called SUMMARY, indicates whether the protocol is safe or unsafe or whether the analysis is inconclusive. DETAILS is the second section, which explains under what condition the protocol is declared safe, what conditions have been used for finding an attack, or finally why the analysis was inconclusive. The remaining sections, called PROTOCOL, GOAL, and BACKEND, represent the name of the protocol, the goal of the analysis, and the name of the back-end used, respectively. Finally, at the end of the analysis, after some possible comments and the statistics, the trace of the attack (if any) is also printed in the usual Alice-Bob format. One can find more details on HLPSL in [29].

5.1. Specifying Our Scheme

We have implemented our scheme for the formal security verification for the registration phase, the login phase, and the authentication phase using the HLPSL language. We have two basic roles: one for alice, which represents the participant as the user , and another for bob, which represents the remote server . The role of the initiator, the user , is shown in Algorithm 3. In this role, first receives the start signal, changes its state value from to , and then sends the registration request message securely to the server using the symmetric key shared between and via the operation. During the registration phase, the user then receives a smart card containing the information securely from by the operation. The type declaration in HLPSL specification declares that the channel is for the Dolev-Yao threat model [1]. In this role, agent represents a principal name. The intruder is always assumed to have the special identifier . symmetric_key represents a key for a symmetric-key cryptosystem. text is often used as nonce. This value can be also used for messages. nat type represents the natural numbers in nonmessage contexts, whereas const represents a constant. hash_func represents cryptographic hash functions. function also represents functions on the space of messages. In HLPSL, it is assumed that the intruder cannot invert hash functions (in essence, that they are one way). The space of legal messages is defined as the closure of the basic types. For example, given a message Msg and an encryption key Key, _ denotes the symmetric/public-key encryption. The associative “” operator is used for concatenation. The “played_by A” declaration tells that the agent named in variable will play a specific role. A knowledge declaration (generally in the top-level Environment role) is used to specify the intruder’s initial knowledge. Immediate reaction transitions have the form , which relate an event and an action . This means that whenever we take a transition that is labeled in such a way so as to make the event predicate true, we must immediately (i.e., simultaneously) execute action . If a variable remains permanently secret, it is expressed by the goal secrecy_of V. Thus, if is ever obtained or derived by the intruder, a security violation will result.

role alice (𝑈𝑖,  𝑆𝑗: agent,    𝑆𝐾𝑢𝑖𝑠𝑗: symmetric_key,    % 𝐻 is hash function    𝐻: hash_func,    Snd, Rcv: channel(dy)) % 𝑈𝑖 is the user; 𝑆𝑗 is the server played_by 𝑈𝑖 def = local State: nat,  𝐼𝐷𝑖, 𝑁𝐼𝐷𝑖, 𝑃𝑊𝑖, 𝑅𝑃𝑊𝑖, 𝑅𝑖: text,  % 𝐾 is a secret number to 𝑈𝑖  % 𝑋𝑠 is a secret number to 𝑆𝑗  𝑇𝑐, 𝑅𝑐, 𝑇𝑠, 𝑅𝑠, 𝐾, 𝑋𝑠: text,  𝑁𝐼𝐷𝑖1,   𝑁𝐼𝐷𝑖2: text,  ADD: hash_func,  𝑀1, 𝑀2, 𝑀3, 𝑀4, 𝑀5, 𝑀6, 𝑀7,  𝑀8, 𝑀9, 𝑀10, 𝑀11, 𝑀12, 𝑀13, 𝑀14: text const alice_bob_tc, bob_alice_ts,  alice_bob_rc, bob_alice_rs,  subs1, subs2: protocol_id init State:= 0 transition % Registration phase (1) State = 0 ∧ Rcv(start) =∣>  State′:= 1 ∧  𝑅𝑃𝑊′𝑖:= 𝐻(𝐼𝐷𝑖·𝐾·𝑃𝑊𝑖) % Send the registration request message    ∧ Snd({𝐼𝐷𝑖·𝑅𝑃𝑊′𝑖}_𝑆𝐾𝑢𝑖𝑠𝑗) % Keep 𝑋𝑠 secret to 𝑆𝑗 and 𝑃𝑊𝑖, 𝐾 to 𝑈𝑖 ∧ secret({𝑋𝑠}, subs1, 𝑆𝑗)    ∧ secret({𝑃𝑊𝑖, 𝐾}, subs2, 𝑈𝑖) % Receive the smart card from the registration server 𝑆𝑗 (2) State = 1 ∧ Rcv({𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖)).     xor(𝐻(𝐼𝐷𝑖⋅𝑋𝑠), 𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))).     xor(𝑁𝐼𝐷𝑖, 𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖)))).     xor(𝑁𝐼𝐷𝑖, 𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖)))).     𝐻}_𝑆𝐾𝑢𝑖𝑠𝑗) =∣> % Login phase  State′:= 2 ∧    𝑁𝐼𝐷′𝑖1:= xor(𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))),      xor(𝑁𝐼𝐷𝑖, 𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))))    ∧  𝑀′1:= xor(xor(𝐻(𝐼𝐷𝑖⋅𝑋𝑠),       𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))),       𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖)))    % generate a random nonce     ∧  𝑅′𝑐:= new()    % 𝑇𝑐 is the current system timestamp     ∧  𝑇′𝑐:= new()     ∧  𝑀′2:= xor(𝑀′1, 𝑅′𝑐)     ∧  𝑀′3:= 𝐻(𝐼𝐷𝑖⋅𝑅′𝑐⋅𝑇′𝑐) % Send the login request message     ∧ Snd(𝑁𝐼𝐷′𝑖1·𝑀′2⋅𝑀′3⋅𝑇′𝑐) % 𝑈𝑖 has freshly generated the random nonce 𝑅𝑐 for 𝑆𝑗     ∧ witness(𝑈𝑖, 𝑆𝑗, alice_bob_rc, 𝑅′𝑐) % 𝑈𝑖 has freshly generated the timestamp 𝑇𝑐 for 𝑆𝑗     ∧ witness(𝑈𝑖, 𝑆𝑗, alice_bob_tc, 𝑇′𝑐) % Authentication phase % Receive the authentication request message (3) State = 2 ∧ Rcv(xor(xor(𝐻(𝐼𝐷𝑖⋅𝑋𝑠), 𝑅′𝑠),𝑇′𝑠).     xor(𝐻(𝑅′𝑠⋅𝑇′𝑠⋅xor(xor(xor(xor(xor(𝐻(𝐼𝐷𝑖⋅𝑋𝑠),      𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))),      𝐻(𝐼𝐷𝑖.𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))), 𝑅′𝑐),      𝐻(𝐼𝐷𝑖⋅𝑋𝑠)), 𝑇′𝑐)⋅𝑇′𝑐), 𝑁𝐼𝐷′𝑖2).     𝐻(𝐼𝐷𝑖⋅ADD(𝑅′𝑐⋅1)⋅ADD(𝑇′𝑐⋅1)⋅𝑅′𝑠.      𝑇′𝑠⋅𝑁𝐼𝐷′𝑖2).     𝑇′𝑠) =∣> % Send the authentication acknowlegement message  State′:= 3 ∧    𝑀′10:= xor(xor(xor(xor(𝐻(𝐼𝐷𝑖⋅𝑋𝑠), 𝑅′𝑠), 𝑇′𝑠),      𝐻(𝐼𝐷𝑖⋅𝑋𝑠)), 𝑇′𝑠)    ∧ 𝑀′11:= 𝐻(𝑀′10⋅𝑇′𝑠⋅𝑅′𝑐⋅𝑇′𝑐)    ∧ 𝑀′12:= 𝐻(𝐼𝐷𝑖⋅ADD(𝑅′𝑐⋅1)⋅ADD(𝑇′𝑐⋅1)⋅𝑀′10.      𝑇′𝑠⋅𝑁𝐼𝐷′𝑖2)    ∧ 𝑀′13:= 𝐻(ADD(𝑀′10⋅1)⋅ADD(𝑇′𝑠⋅1)⋅ADD(𝑅′𝑐⋅1).      ADD(𝑇′𝑐⋅1)⋅𝑁𝐼𝐷′𝑖2⋅𝐼𝐷𝑖)    ∧ Snd(𝑀′13) % 𝑈𝑖’s acceptance of the value 𝑅𝑁𝑗 generated for 𝑈𝑖 by 𝑆𝑗     ∧ request(𝑆𝑗, 𝑈𝑖, bob_alice_rs, 𝑅′𝑠) % 𝑈𝑖’s acceptance of the value 𝑇𝑠 generated for 𝑈𝑖 by 𝑆𝑗     ∧ request(𝑆𝑗, 𝑈𝑖, bob_alice_ts, 𝑇′𝑠) end role

Algorithm 3 

Role specification in HLPSL for the user 𝑈_𝑖 of our scheme.

During the login phase of our scheme, the user sends the login request message to the server . During the authentication phase, after receiving the authentication request message from , sends the authentication acknowledgment message to . In this role, witness (A, B, id, E) declares for a (weak) authentication property of by on that agent is witness for the information ; this goal will be identified by the constant in the goal section [29]. This expresses that the agent named in variable has freshly generated the value for the agent named in variable . The term is a new constant that identifies the message term upon which the goal should be authenticated. On the other hand, request (B, A, id, E) for a strong authentication property of by on declares that agent requests a check of the value ; this goal will be identified by the constant in the goal section [29]. This formalizes ’s acceptance of the value as having been generated for him/her by the agent named in .

The role of the responder, the server , is shown in Algorithm 4. During the registration phase, after receiving the registration request message securely from the user , then issues a smart card and sends it containing the information securely to . During the login phase, after receiving the login request message , sends the authentication request message to in the authentication phase. Finally, waits for the authentication acknowledgment message from .

role bob (𝑈𝑖, 𝑆𝑗: agent,   𝑆𝐾𝑢𝑖𝑠𝑗: symmetric_key,   % 𝐻 is hash function   𝐻: hash_func, Snd, Rcv: channel(dy)) % 𝑈𝑖 is the user; 𝑆𝑗 is the server played_by 𝑆𝑗 def = local State: nat,  𝐼𝐷𝑖, 𝑁𝐼𝐷𝑖, 𝑇𝐷𝑖, 𝐷𝑖, 𝑃𝑊𝑖, 𝑅𝑃𝑊𝑖, 𝑅𝑖, 𝐸𝑖: text,  % 𝐾 is a secret number to 𝑈𝑖  % 𝑋𝑠 is a secret number to 𝑆𝑗  𝑇𝑐, 𝑅𝑐, 𝑇𝑠, 𝑅𝑠, 𝐾, 𝑋𝑠: text,  𝑁𝐼𝐷𝑖1, 𝑁𝐼𝐷𝑖2: text,  ADD: hash_func,  𝑀1, 𝑀2, 𝑀3, 𝑀4, 𝑀5, 𝑀6, 𝑀7,  𝑀8, 𝑀9, 𝑀10, 𝑀11, 𝑀12, 𝑀13, 𝑀14: text const alice_bob_tc, bob_alice_ts,  alice_bob_rc, bob_alice_rs,  subs1, subs2: protocol_id init State:= 0 transition % Registration phase % Receive the registration request message from the user (1) State = 0 ∧ Rcv({𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖)}_𝑆𝐾𝑢𝑖𝑠𝑗) =∣> % Keep 𝑋𝑠 secret to 𝑆𝑗 and 𝑃𝑊𝑖, 𝐾 to 𝑈𝑖 State′:= 1 ∧ secret({𝑋𝑠}, subs1, 𝑆𝑗)   ∧ secret({𝑃𝑊𝑖, 𝐾}, subs2, 𝑈𝑖) % Send the smart card to the user   ∧  𝑅′𝑖:= 𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))   ∧  𝐸′𝑖:= xor(𝐻(𝐼𝐷𝑖⋅𝑋𝑠), 𝑅′𝑖)   ∧  𝑇𝐷′𝑖:= xor(𝑁𝐼𝐷𝑖, 𝐻(𝐼𝐷𝑖⋅𝑅′𝑖))   ∧  𝐷′𝑖:= xor(𝑁𝐼𝐷𝑖, 𝐻(𝐼𝐷𝑖⋅𝑅′𝑖))   ∧  Snd({𝑅′𝑖⋅𝐸′𝑖⋅𝑇𝐷′𝑖⋅𝐷′𝑖⋅𝐻}_𝑆𝐾𝑢𝑖𝑠𝑗) % Login phase % Receive the login request message (2) State = 1 ∧ Rcv(xor(𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))),    xor(𝑁𝐼𝐷𝑖, 𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖)))).    xor(xor(xor(𝐻(𝐼𝐷𝑖⋅𝑋𝑠),     𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))),     𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))), 𝑅′𝑐).    𝐻(𝐼𝐷𝑖⋅𝑅′𝑐⋅𝑇′𝑐)⋅𝑇′𝑐) =∣> % Authentication phase State′:= 2 ∧    % generate a random nonce     𝑅′𝑠:= new()   % 𝑇𝑠 is the current system timestamp   ∧  𝑇′𝑠:= new()   ∧  𝑀′4:= 𝐻(𝐼𝐷𝑖⋅𝑋𝑠)   ∧  𝑀′5:= xor(xor(xor(xor(xor(𝐻(𝐼𝐷𝑖⋅𝑋𝑠),     𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))),     𝐻(𝐼𝐷𝑖⋅𝐻(𝐼𝐷𝑖⋅𝐾⋅𝑃𝑊𝑖))), 𝑅′𝑐),     𝐻(𝐼𝐷𝑖⋅𝑋𝑠)), 𝑇′𝑐)   ∧  𝑀′6:= 𝐻(𝐼𝐷𝑖⋅𝑀′5⋅𝑇′𝑐)   ∧  𝑀′7:= xor(xor(𝑀′4, 𝑅′𝑠), 𝑇′𝑠)   ∧  𝑁𝐼𝐷′𝑖2:= new()   ∧  𝑀′8:= xor(𝐻(𝑅′𝑠⋅𝑇′𝑠⋅𝑀′5⋅𝑇′𝑐), 𝑁𝐼𝐷′𝑖2)   ∧  𝑀′9:= 𝐻(𝐼𝐷𝑖⋅ADD(𝑀′5⋅1)⋅ADD(𝑇′𝑐⋅1)⋅𝑅′𝑠.     𝑇′𝑠⋅𝑁𝐼𝐷′𝑖2) % Send the authentication request message   ∧ Snd(𝑀′7⋅𝑀′8⋅𝑀′9⋅𝑇′𝑠) % 𝑆𝑗 has freshly generated the random nonce 𝑅𝑠 for 𝑈𝑖   ∧ witness(𝑆𝑗, 𝑈𝑖, bob_alice_rs, 𝑅′𝑠) % 𝑆𝑗 has freshly generated the timestamp 𝑇𝑠 for 𝑈𝑖   ∧ witness(𝑆𝑗, 𝑈𝑖, bob_alice_ts, 𝑇′𝑠) % Receive the authentication acknowledgement message (3) State = 2 ∧ Rcv(𝐻(ADD(𝑅′𝑠⋅1)⋅ADD(𝑇′𝑠⋅1)⋅ADD(𝑅′𝑐⋅1).    ADD(𝑇′𝑐⋅1)⋅𝑁𝐼𝐷′𝑖2⋅𝐼𝐷𝑖)) =∣> % 𝑆𝑗’s acceptance of the value 𝑅𝑐 generated for 𝑆𝑗 by 𝑈𝑖 State′:= 3 ∧ request(𝑈𝑖, 𝑆𝑗, alice_bob_rc, 𝑅′𝑐) % 𝑆𝑗’s acceptance of the value 𝑇𝑐 generated for 𝑆𝑗 by 𝑈𝑖    ∧ request(𝑈𝑖, 𝑆𝑗, alice_bob_tc, 𝑇′𝑐) end role

Algorithm 4 

Role specification in HLPSL for the server 𝑆_𝑗 of our scheme.

Finally, in Algorithms 5 and 6, we have specified the roles for the session and the goal and environment of our scheme. In the session segment, all the basic roles, alice and bob, are instanced with concrete arguments. The top-level role (called the environment) is always defined in the specification of HLPSL language, which has the global constants and a composition of one or more sessions, where the intruder may play some roles as legitimate users. The intruder participates in the execution of protocol as a concrete session during the simulation. Goals are given in their own section, which generally comes at the end of a HLPSL specification. We have two secrecy goals and four authentication processes in the specification of HLPSL in our scheme.(i)secrecy_of subs1: it represents that is kept secret to the server only.(ii)secrecy_of subs2: it represents that and are kept secret to the user only.(iii)authentication_on alice_bob_tc: (the smart card) generates a timestamp . When the server receives in the messages from , authenticates .(iv)authentication_on alice_bob_rc: (the smart card) generates a random nonce , where is only known to the user . When the server receives in the messages from , authenticates .(v)authentication_on bob_alice_ts: generates a timestamp . When receives in the messages from , authenticates .(vi)authentication_on bob_alice_rs: generates a random nonce , where is only known to . When the user receives in the messages from , authenticates .

role session(𝑈𝑖, 𝑆𝑗: agent, 𝑆𝐾𝑢𝑖𝑠𝑗: symmetric_key,      𝐻: hash_func) def = local SI, SJ, RI, RJ: channel (dy) composition     alice(𝑈𝑖, 𝑆𝑗, 𝑆𝐾𝑢𝑖𝑠𝑗, 𝐻, SI, RI)     ∧ bob(𝑈𝑖, 𝑆𝑗, 𝑆𝐾𝑢𝑖𝑠𝑗, 𝐻, SJ, RJ) end role

Algorithm 5 

Role specification in HLPSL for the session of our scheme.

role environment() def = const 𝑢𝑖,  𝑠𝑗: agent,  𝑆𝐾𝑢𝑖𝑠𝑗: symmetric_key,  ℎ: hash_func,  alice_bob_tc, bob_alice_ts,  alice_bob_rc, bob_alice_rs,  subs1, subs2: protocol_id  intruder_knowledge = {𝑢𝑖, 𝑠𝑗, ℎ}  composition   session(𝑢𝑖, 𝑠𝑗, 𝑆𝐾𝑢𝑖𝑠𝑗, ℎ)    ∧ session(𝑢𝑖, 𝑠𝑗, 𝑆𝐾𝑢𝑖𝑠𝑗, ℎ) end role goal  secrecy_of subs1  secrecy_of subs2  authentication_on alice_bob_tc  authentication_on alice_bob_rc  authentication_on bob_alice_ts  authentication_on bob_alice_rs end goal environment()

Algorithm 6 

Role specification in HLPSL for the goal and environment of our scheme.

5.2. Analysis of Results

The simulation results of our scheme using the AVISPA web tool [30] for the widely accepted OFMC back-end [31] are shown in Table 7. It is evident from the summary of the results under OFMC back-end that our scheme is safe. Thus, our scheme is secure against the passive attacks and the active attacks.

6. Performance Comparison with Related Schemes

In this section, we compare the performance of our scheme with the related recently proposed password-based remote user authentication schemes: Lee and Liu [13], Das and Bruhadeshwar [14], Sonwanshi et al. [3], and Jiang et al. [15].

For communication cost comparison, we assume that the identity of a user/server is bits, the random nonce is bits, the timestamp is bits, and the hash value is bits. Since the security of -bit ECC (elliptic curve cryptography) is the same as that for -bit RSA cryptosystem, for Lee-Liu’s scheme [13], Das-Bruhadeshwar’s scheme [14], and Jiang et al.’s scheme [15] we take the elliptic curve over a -bit prime field and the modulus in RSA as bits. Thus, each elliptic curve point addition and that of multiplication take bits as these are again a point in the elliptic curve, whereas the ciphertext in RSA is bits.

In our scheme, during the login phase, the login request message requires bits. During the authentication phase of our scheme, the authentication request message requires bits and, finally, the authentication acknowledgment message requires bits. Summing all these, the total communication cost of our scheme during the login and authentication phases becomes bits. In Table 4, we have compared the communication cost of our scheme with other related recent password-based schemes [3, 13–15] for the login and authentication phases. It is noted that Sonwanshi et al.’s scheme [3] requires less communication cost as compared to our scheme and other schemes. However, Sonwanshi et al.’s scheme [3] is shown to be insecure against offline password guessing attack and stolen smart card attack, and it also suffers to protect strong replay attacks. On the other hand, our scheme requires less communication cost as compared to [13–15].

Table 4 

Comparison of communication overhead between our scheme and other related schemes during the login and authentication phases.

In Table 5, we have compared the computation cost of our scheme with other schemes [3, 13–15] for all the phases. In our scheme, the registration phase requires only hash computations. We ignore the cost of the bitwise XOR operation as it is negligible. The login and authentication phases require hash computations, whereas the password change phase requires hash computations. Thus, a total of hash computations are required for all the phases in our scheme. It is noted that the time taken for a hash computation is significantly less as compared to that for modular exponentiation in RSA encryption/decryption and elliptic curve point addition/multiplication [32]. Thus, our scheme performs significantly better in terms of computational costs than Lee-Liu’s scheme [13], Das-Bruhadeshwar’s scheme [14], and Jiang et al.’s scheme [15]. Though Sonwanshi et al.’s scheme [3] requires less computational cost than our scheme, Sonwanshi et al.’s scheme is insecure.

Table 5 

Comparison of computational overhead between our scheme and other schemes during all phases.

Finally, we have compared the functionality provided by our scheme with those for other schemes [3, 13–15] in Table 6. From this table, it is clear that our scheme performs better than Lee-Liu’s scheme [13] and Sonwanshi et al.’s scheme [3]. Further, our scheme is also comparable to Das-Bruhadeshwar’s scheme [14] and Jiang et al.’s scheme [15]. However, Lee-Liu’s scheme [13] has several security weaknesses as shown in [14], and Das-Bruhadeshwar’s scheme [14] and Jiang et al.’s scheme [15] require more communication and computational costs as compared to our scheme. Further, Sonwanshi et al.’s scheme [3] is insecure against different attacks. Thus, our scheme performs better in terms of various functionalities as compared to Sonwanshi et al.’s scheme [3].

Table 6 

Functionality comparison between our scheme and other schemes.

Table 7 

The result of the analysis using OFMC of our scheme.

7. Conclusion

In this paper, we have proposed a new robust and secure three-factor remote user authentication scheme, which uses the user’s identity, the user’s password, and the smart card. Our scheme avoids the expensive operations like modular exponentiations and ECC point addition/multiplication operations as used in [13–15]. Our scheme uses the efficient bitwise XOR operations and one-way hash computations. Due to this, our scheme requires significantly less communication and computational overheads as compared to those for other existing schemes. Our scheme supports several extra features as compared to other schemes. Further, through the rigorous informal and formal security analysis, we have shown that our scheme is secure against possible known attacks. In addition, we have performed the simulation for the formal security analysis to check whether our scheme is secure against passive and active attacks. The simulation results stated in this paper clearly show that our scheme is secure against passive and active attacks. Our scheme also supports efficiently the password change phase always locally without contacting the remote server and correctly. As a result, high security and low communication and computational costs make our scheme more suitable for practical applications.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgments

The authors would like to acknowledge the many helpful suggestions of the anonymous reviewers and the editors of this journal.