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]:

1. not maintaining verification tables;

2. user's ability to freely choose and update password;

3. resistance to password disclosure to the server;

4. prevention of masquerade attacks;

5. resistance to replay, modification, parallel session, and stolen-verifier attacks;

6. an easy-to-remember password;

7. low communication cost and computation complexity;

8. achieving mutual authentication between login users and remote servers;

9. resistance to guessing attacks even if the smart card is lost or stolen by attackers;

10. session key agreement;

11. resistance to insider attacks;

12. 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 h : {0,1}* → {0,1}ⁿ is a one-way function, which takes an arbitrary-length binary string input x ∈ {0,1}* and outputs a fixed-length (e.g., n-bit) binary string, called the message digest or hash value h(x)∈{0,1}ⁿ. In addition, it has the following important properties [16].

1. h can be applied to a data block of all sizes.

2. For any given input x, it is relatively easy to compute the hash value h(x), which enables easy implementation in software and hardware.

3. Output length of h(x) is fixed.

4. One-way property: from a given hash value y = h(x) and the given hash function h(·), it is computationally infeasible to derive the input x.

5. Weak-collision resistance property: for any given input x, finding any other input y, with y ≠ x, such that h(y) = h(x) is computationally infeasible.

6. Strong-collision resistance property: finding a pair of inputs (x, y), with x ≠ y, such that h(x) = h(y) 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:

•   U _i: user,
•   S _j: remote server,
•   ID _i: identity of user U _i,
•   PW _i: password of user U _i,
•   X _s: permanent secret key only known to the remote server S _j,
•   K: secret number only known to the user U _i,
•   T _a: current system timestamp of an entity A,
•   R _a: random nonce generated by an entity A,
•   h(·): secure one-way collision-resistant hash function,
•   A||B: data A concatenating with data B,
•   A ⊕ B: bitwise XOR operation of A and B.

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 U _i needs to register to access services from a remote server S _j. After registering, the server S _j will issue a smart card containing important information stored in the smart card's memory. In the login phase, if the user U _i wants to access services from the server S _j, the user U _i 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 S _j authenticates the user U _i and the user U _i also authenticates the server S _j. After mutual authentication between U _i and S _j, both U _i and S _j 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 U _i first selects his/her own secret identity ID _i and chooses a strong (not low-entropy or weak) password PW _i.

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

Step R3. U _i then computes the masked password using K, ID _i, and PW _i as R PW _i = h(ID _i||K||PW _i) and sends the registration request message 〈ID _i, R PW _i〉 to the registration remote server S _j via a secure channel.

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

Step R5. S _j then computes r _i = h(ID _i||R PW _i) = h(ID _i||h(ID _i||K||PW _i)) and e _i = h(ID _i||X _s) ⊕ r _i. S _j further computes TD _i = N ID _i ⊕ h(ID _i||r _i) and D _i = TD _i as in [20]. Here N ID _i is a random and temporary identity for the user U _i, which is used instead of the permanent identity ID _i to achieve the user anonymity.

Step R6. Finally, S _j issues a smart card C _i containing the information (r _i, e _i, TD _i, D _i, h(·)) and sends it to the user U _i via a secure channel.

After receiving the smart card C _i from S _j, U _i stores the secret number K 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.

User (U i)	Remote server (S j)
Selects ID i, PW i.
Generates secret number K.
Computes R PW i = h(ID i||K||PW i).
$\stackrel{\langle I{D}_i,RP{W}_i\rangle }{\to }$
(via a secure channel)	Generates secret number X s.
	Computes r i = h(ID i||R PW i),
	e i = h(ID i||X s) ⊕ r i,
	TD i = N ID i ⊕ h(ID i||r i), and D i = TD i.
	$\stackrel{\hspace{1em}\hspace{1em}\langle SmartCard\left(r_i,e_i,T{D}_i,D_i,h\left(·\right)\right)\rangle \hspace{1em}\hspace{1em}}{\leftarrow }$
	(via a secure channel)
Stores K into the smart card's memory.

3.4.2. Login Phase

In this phase, the following steps are executed.

Step L1. U _i first inserts his/her smart card C _i into a card reader of the specific terminal. U _i then inputs his/her identity ID _i* and password PW _i*.

Step L2. C _i computes the masked password R PW _i* as R PW _i* = h(ID _i*||K||PW _i*) using the secret number K stored in its memory. C _i then computes r _i* = h(ID _i*||R PW _i*) and checks if the condition r _i* = r _i holds. If this condition holds, U _i passes password verification and the next step is executed. Otherwise, this phase terminates immediately.

Step L3. C _i computes N ID _i* = h(ID _i*||r _i*) ⊕ D _i and M ₁ = e _i ⊕ r _i* = h(ID _i||X _s) ⊕ r _i ⊕ r _i* = h(ID _i||X _s). C _i generates a 160-bit random nonce R _c and then computes M ₂ = M ₁ ⊕ R _c ⊕ T _c = h(ID _i||X _s) ⊕ R _c ⊕ T _c, where T _c is the current system timestamp, and M ₃ = h(ID _i*||R _c||T _c). C _i sends the login request message 〈N ID _i*, M ₂, M ₃, T _c〉 to the server S _j 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.

User (U i)/smart card (C i)	Remote server (S j)
Inputs ID i*, PW i*.
Computes R PW i* and r i*.
Checks if r i* = r i. If it holds
computes N ID i* = h(ID i*||r i*) ⊕ D i,
M 1 = e i ⊕ r i*, M 2 = M 1 ⊕ R c ⊕ T c,
and M 3 = h(ID i*||R c||T c).
$\stackrel{\hspace{1em}\langle NI{D}_i^{\mathrm{\ast }},M_{\mathrm{2}},M_{\mathrm{3}},T_c\rangle \hspace{1em}}{\to }$
(via a public channel)

3.4.3. Authentication Phase

After receiving the login request message 〈N ID _i*, M ₂, M ₃, T _c〉 from the user U _i, the server S _j checks the format of N ID _i* and then finds the entry (ID _i, N ID _i*) in its maintained ID database table. If it is found, S _j performs Case 1; otherwise, S _j proceeds to Case 2.

Case 1 —

Consider the following.

Step A1. S _j checks the validity of the timestamp T _c in the received message by the condition |T _c − T _c* | <ΔT, where T _c* is the current system timestamp of S _j and ΔT the expected transmission delay. If this condition is satisfied, S _j computes M ₄ = h(ID _i||X _s), using its own secret number X _s. After that S _j computes

$$\begin{array}{c}{M}_{\mathrm{5}}=M_{\mathrm{2}}\oplus M_{\mathrm{4}}\oplus T_c\\ \hspace{1em}\hspace{0.17em}\hspace{0.17em}=h\left(I{D}_i||X_s\right)\oplus R_c\oplus T_c\oplus h\left(I{D}_i||X_s\right)\oplus T_c\\ \hspace{1em}\hspace{0.17em}\hspace{0.17em}=R_c,\\ M_{\mathrm{6}}=h\left(I{D}_i||M_{\mathrm{5}}||T_c\right).\end{array}$$ (1)

S _j then verifies the condition whether M ₆ = M ₃ holds. If it does not hold, S _j 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 S _j stores the pair (ID _i, M ₅), where M ₅ = R _c, in its database. Suppose the server receives the next login request message 〈N ID _i*, M ₂′, M ₃′, T _c′〉 from the user U _i or an attacker. S _j first checks the validity of the timestamp T _c′ and if it is valid, it further computes M ₄′ = h(ID _i||X _s), using its own secret number X _s. After that S _j computes, say, M ₅′ = M ₂′ ⊕ M ₄′ ⊕ T _c′ = h(ID _i||X _s) ⊕ R _c ⊕ T _c′ ⊕ h(ID _i||X _s) ⊕ T _c′ = R _c′. If M ₅′ = M ₅, it ensures that the login request message is a replay one. Otherwise, S _j updates M ₅ with M ₅′ 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. S _j generates a random nonce R _s and then computes M ₇ = M ₄ ⊕ R _s ⊕ T _s, where T _s is the current system timestamp of the server S _j, M ₈ = h(R _s||T _s||M ₅||T _c) ⊕ N ID _i ^new, where N ID _i ^new is a random and temporary identity generated by S _j, and M ₉ = h(ID _i||M ₅ + 1||T _c + 1||R _s||T _s||N ID _i ^new). S _j then sends the authentication request message 〈M ₇, M ₈, M ₉, T _s〉 to the user U _i via a public channel.

Step A3. After receiving the message in Step A2, C _i checks the validity of the timestamp T _s in the received message with the condition |T _s − T _s* | <ΔT, where T _s* is the current system timestamp of C _j and ΔT the expected transmission delay. If this condition does not hold, the phase terminates immediately. Otherwise, C _i computes

$$\begin{array}{c}\hspace{1em}\hspace{1em}\hspace{0.17em}\hspace{0.17em}\hspace{0.17em}\hspace{0.17em}{M}_{\mathrm{10}}=M_{\mathrm{7}}\oplus M_{\mathrm{1}}\oplus T_s\\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{0.17em}\hspace{0.17em}\hspace{1em}=h\left(I{D}_i||X_s\right)\oplus R_s\oplus T_s\oplus h\left(I{D}_i||X_s\right)\oplus T_s\\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{0.17em}\hspace{0.17em}=R_s,\\ \hspace{1em}\hspace{1em}\hspace{0.17em}\hspace{0.17em}\hspace{0.17em}\hspace{0.17em}{M}_{\mathrm{11}}=h\left(M_{\mathrm{10}}||T_s||R_c||T_c\right),\\ \hspace{0.17em}\hspace{0.17em}\hspace{0.17em}\hspace{0.17em}\hspace{0.17em}NI{D}_i^{\text{new}\ast }=M_{\mathrm{8}}\oplus M_{\mathrm{11}}.\end{array}$$ (2)

C _i further computes M ₁₂ = h(ID _i||R _c + 1||T _c + 1||M ₁₀||T _s||N ID _i ^new∗) and checks the condition M ₁₂ = M ₉. If it does not hold, this phase terminates immediately. Otherwise, on the other hand, C _i updates TD _i and D _i with D _i and D _i ⊕ N ID _i* ⊕ N ID _i ^new∗, respectively, in its memory.

Step A4. C _i computes M ₁₃ = h(M ₁₀ + 1||T _s + 1||R _c + 1||T _c + 1||N ID _i ^new∗||ID _i) and sends the authentication acknowledgment message 〈M ₁₃〉 to the server S _j via a public channel. C _i also computes a secret session key shared between U _i and S _j as SK _Ui,Sj = h(ID _i||R _c||T _c||M ₁₀||T _s||M ₁).

Step A5. After receiving the authentication acknowledgment message 〈M ₁₃〉 from the user U _i in Step A4, S _j computes M ₁₄ = h(R _s + 1||T _s + 1||M ₅ + 1||T _c + 1||N ID _i ^new||ID _i) and verifies whether the condition M ₁₄ = M ₁₃ holds. If it holds, S _j authenticates the user U _i and also computes the same secret session key shared with U _i as K _Sj,Ui = h(ID _i||M ₅||T _c||R _s||T _s||M ₄). Thus, after successful authentication, both U _i and S _j 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. N ID _i* is obtained by computing h(ID _i*||r _i*) ⊕ TD _i instead of h(ID _i*||r _i*) ⊕ D _i in Step L3 of the login phase. The smart card C _i of the user U _i in this case only needs to update D _i with D _i ⊕ N ID _i* ⊕ N ID _i ^new∗ without changing TD _i in Step A3.

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

Table 3.

Summary of the authentication phase of our scheme.

User (U i)/smart card (C i)	Remote server (S j)
	Checks the validity of T c.
	If it holds, computes
	M 4 = h(ID i||X s),
	M 5 = M 2 ⊕ M 4 ⊕ T c,
	and M 6 = h(ID i||M 5||T c).
	Checks if M 6 = M 3. If it holds,
	computes M 7 = M 4 ⊕ R s ⊕ T s,
	M 8 = h(R s||T s||M 5||T c) ⊕ N ID i new,
	and M 9 = h(ID i||M 5 + 1||T c + 1
	||R s||T s||N ID i new).
	$\stackrel{\hspace{1em}\hspace{1em}\hspace{1em}\langle M_{\mathrm{7}},M_{\mathrm{8}},M_{\mathrm{9}},T_s\rangle \hspace{1em}\hspace{1em}\hspace{1em}}{\leftarrow }$
Checks the validity of T s.	(via a public channel)
If it holds, computes
M 10 = M 7 ⊕ M 1 ⊕ T s,
M 11 = h(M 10||T s||R c||T c),
NI D i new∗ = M 8 ⊕ M 11,
and M 12 = h(ID i||R c + 1||T c + 1||M 10||T s
||N ID i new∗). Checks if M 12 = M 9. If it
holds, updates TD i and D i. Computes
M 13 = h(M 10 + 1||T s + 1||R c + 1||T c + 1||N ID i new∗||ID i).
$\stackrel{\langle M_{\mathrm{13}}\rangle }{\to }$
(via a public channel)	Computes M 14 = h(R s + 1||T s + 1
	||M 5 + 1||T c + 1||N ID i new||ID i).
	Checks if M 14 = M 13. If it holds,
	S j authenticates u i.
Computes K Ui,Sj = h(ID i||R c||T c||M 10||T s||M 1).	Computes K Sj,Ui = h(ID i||M 5||T c||SR s||T s||M 4).

3.4.4. Password Change Phase

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

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

Step P2. C _i then computes masked password R PW _i ^old = h(ID _i||K||PW _i ^old) using the secret number K stored in its memory and r _i ^old = h(ID _i||R PW _i ^old). C _i checks if the condition r _i ^old = r _i holds. If it does not hold, the old password verification fails and this phase terminates immediately. Otherwise, C _i asks the user U _i to input his/her chosen strong (high-entropy) password PW _i ^new, where PW _i ^old ≠ PW _i ^new.

Step P3. C _i computes

$$\begin{array}{c}x=e_i\oplus r_i^{\text{old}}\\ =h\left(I{D}_i||X_s\right)\oplus r_i\oplus r_i^{\text{old}}\\ =h\left(I{D}_i||X_s\right),\hspace{1em}\text{since}\hspace{0.17em}{r}_i^{\text{old}}=r_i,\\ RP{W}_i^{\text{new}}=h\left(I{D}_i||K||P{W}_i^{\text{new}}\right),\\ r_i^{\text{new}}=h\left(I{D}_i||RP{W}_i^{\text{new}}\right),\\ e_i^{\text{new}}=x\oplus r_i^{\text{new}}.\end{array}$$ (3)

C _i further computes TD _i ^new = TD _i ⊕ h(ID _i||r _i ^old) ⊕ h(ID _i||r _i ^new) = N ID _i ⊕ h(ID _i||r _i ^new) and D _i ^new = TD _i ^new.

Step P4. Finally, C _i updates r _i with r _i ^new, e _i with e _i ^new, TD _i with TD _i ^new, and D _i with D _i ^new in its memory.

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

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 U _i and the server S _j 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 U _i and the server S _j compute a secret session key between them. Note that, in Step A4, C _i computes the secret session key shared between U _i and S _j as K _Ui,Sj = h(ID _i||R _c||T _c||M ₁₀||T _s||M ₁), where M ₁₀ = R _s and M ₁ = h(ID _i||X _s). Thus, K _Ui,Sj = h(ID _i||R _c||T _c||R _s||T _s||h(ID _i||X _s)).

On the other side, the server S _j in Step A5 computes the secret session key shared with U _i as K _Sj,Ui = h(ID _i||M ₅||T _c||R _s||T _s||M ₄), where M ₅ = R _c and M ₄ = h(ID _i||X _s). As a result, SK _Sj,Ui = h(ID _i||R _c||T _c||R _s||T _s||h(ID _i||X _s)) = SK _Ui,Sj. 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 〈N ID _i*, M ₂, M ₃, T _c〉 during the login phase, where M ₂ = M ₁ ⊕ R _c ⊕ T _c = h(ID _i||X _s) ⊕ R _c ⊕ T _c and M ₃ = h(ID _i*||R _c||T _c), and starts a new session with the message 〈N ID _i*, M ₂′, M ₃′, T _c′〉 = 〈N ID _i*, M ₂, M ₃, T _c〉. According to our policy, the server S _j stores the pair (ID _i, M ₅), where M ₅ = R _c, in its database. S _j first checks the validity of the timestamp T _c′ and if it is valid, it further computes M ₄′ = h(ID _i||X _s), using its own secret number X _s. After that S _j computes, say, M ₅′ = M ₂′ ⊕ M ₄′ ⊕ T _c′ = h(ID _i||X _s) ⊕ R _c ⊕ T _c′ ⊕ h(ID _i||X _s) ⊕ T _c′ = R _c′. If M ₅′ = M ₅, 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 〈N ID _i*, M ₂, M ₃, T _c〉 during the login phase, where M ₂ = M ₁ ⊕ R _c ⊕ T _c = h(ID _i||X _s) ⊕ R _c ⊕ T _c and M ₃ = h(ID _i*||R _c||T _c). In order to make success in the man-in-the-middle attack, the attacker has to change M ₂ and M ₃ properly so that the server S _j can authenticate the message successfully. Assume that the attacker uses a timestamp T _c′ and wants to change M ₂ and M ₃ to M ₂′ = M ₂ ⊕ T _c ⊕ T _c′ = h(ID _i||X _s) ⊕ R _c ⊕ T _c′ and M ₃′ = h(ID _i*||R _c||T _c′), respectively. However, for M ₃′ the attacker needs to know both ID _i* and R _c which are unknown to that attacker. As pointed out in [20], the probability of guessing an identity composed of exact n characters is approximately 1/2⁶ⁿ. Thus, to correctly know ID _i* and R _c from M ₃, the attacker has to guess both ID _i* and R _c at the same time using T _c and the probability of guessing both ID _i* composed of exact n characters and R _c composed of m bits (m = 160 bits in our scheme) at the same time becomes approximately 1/2^6n+m. If n = 10, then this probability is approximately 1/2⁶⁰⁺¹⁶⁰ = 1/2²²⁰, 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 S _j or a legal user U _i in order to cheat the other party. Suppose an attacker intercepts the login request message 〈N ID _i*, M ₂, M ₃, T _c〉 during the login phase and wants to start a new session. In order to start a new session, the attacker has to modify both M ₂ and M ₃. However, as discussed in Section 4.2.2, to change M ₃ the attacker has to guess/know both ID _i and R _c, which are unknown to the attacker. Thus, the probability of guessing both ID _i* composed of exact n characters and R _c composed of m bits (m = 160 bits in our scheme) at the same time becomes approximately 1/2^6n+m = 1/2⁶ⁿ⁺¹⁶⁰, 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 C _i of a legal user U _i is lost or stolen by an attacker. Then the attacker can extract all the secret information (r _i, e _i, TD _i, D _i, K) from the memory of the stolen or lost smart card C _i of the user U _i using the power analysis attacks [23, 24]. Note that r _i = h(ID _i||R PW _i) = h(ID _i||h(ID _i||K||PW _i)) and e _i = h(ID _i||X _s) ⊕ r _i. The attacker can derive h(ID _i||X _s) = e _i ⊕ r _i. In order to know the secret information X _s of the server S _j, the attacker needs to guess both ID _i and X _s. The probability of guessing both ID _i composed of exact n characters and X _s composed of m bits (m = 1024 bits in our scheme) at the same time becomes approximately 1/2^6n+m = 1/2^6n+1024, which is very negligible. Again, to derive the password PW _i composed of l characters, the attacker needs to also guess ID _i using K. Thus, the probability of guessing both ID _i composed of exact n characters and PW _i composed of exact l characters at the same time becomes approximately 1/2^6n+6l, 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 C _i of a legal user U _i is lost or stolen by an attacker and all the secret information (r _i, e _i, TD _i, D _i, K) stored in the memory of the smart card C _i is known to the attacker. Still then the attacker can not guess correctly the password PW _i of U _i offline, which is evident from Section 4.2.4.

Suppose the attacker intercepts all the transmitted messages 〈N ID _i*, M ₂, M ₃, T _c〉 during the login phase and 〈M ₇, M ₈, M ₉, T _s〉 and 〈M ₁₃〉 during the authentication phase. However, none of these messages involves the password PW _i of the user U _i. As a result, these messages will not be helpful to the attacker to obtain PW _i of U _i 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 C _i of a legal user U _i stores TD _i and D _i for the previous and the latest random identities, respectively. Thus, the corruption of the message 〈M ₁₃〉 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 ID _i of a legal user U _i indirectly and it is protected by the one-way secure hash function h(·). Due to the collision-resistant property of h(·), it is computationally infeasible for an attacker to derive ID _i.

Even if we assume that the smart card C _i of a legal user U _i is lost or stolen by an attacker and all the secret information (r _i, e _i, TD _i, D _i, K) stored in the memory of the smart card C _i is known to the attacker, from TD _i and N ID _i* from the intercepted login request message 〈N ID _i*, M ₂, M ₃, T _c〉 the attacker can compute h(ID _i | |r _i) = TD _i ⊕ N ID _i*. Again, ID _i is protected by the one-way secure hash function h(·). Due to the collision-resistant property of h(·), it is computationally infeasible for an attacker to derive ID _i. Hence, our scheme preserves the user anonymity property.

4.2.8. Mutual Authentication

During the authentication phase, after receiving the authentication request message 〈M ₇, M ₈, M ₉, T _s〉 from the server S _j, the smart card C _i of a legal user U _i computes M ₁₂ = h(ID _i||R _c + 1||T _c + 1||M ₁₀||T _s||N ID _i ^new∗) and checks the condition M ₁₂ = M ₉. If it holds, U _i authenticates the server S _j and then only sends the authentication acknowledgment message 〈M ₁₃〉 to the server S _j. After that the server S _j also computes M ₁₄ = h(R _s + 1||T _s + 1||M ₅ + 1||T _c + 1||N ID _i ^new||ID _i) and verifies whether the condition M ₁₄ = M ₁₃ holds. If it holds, S _j authenticates the user U _i. Hence, the mutual authentication is always performed in our scheme.

4.2.9. Session Key Security

After mutual authentication, the smart card C _i of a legal user U _i computes the secret session key shared between U _i and S _j as K _Ui,Sj = h(ID _i||R _c||T _c||M ₁₀||T _s||M ₁). The server S _j also computes the secret session key shared with the user U _i as K _Sj,Ui = h(ID _i||M ₅||T _c||R _s||T _s||M ₄), where M ₁ = h(ID _i||X _s) and M ₄ = h(ID _i||X _s). It is also evident from Theorem 1 that K _Ui,Sj = SK _Sj,Ui. In order to compute the secret key SK _Ui,Sj from all the transmitted messages during the login and authentication phases, an attacker has to guess/derive correctly ID _i composed of exact n characters, X _s of m = 1024 bits, and R _c and R _s, each composed of 160 bits at the same time, and, thus, the probability of deriving this secret key is approximately 1/2^6n+m+160+160 = 1/2^6n+1344, 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 h(·) given in Definition 2.

Definition 2 (one-way hash function [25, 26]) —

A one-way collision-resistant hash function h : {0,1}* → {0,1}ⁿ is a deterministic function that takes the input as an arbitrar-length binary string x ∈ {0,1}* and outputs a binary string y = h(x)∈{0,1}ⁿ of fixed length n. We formalize an adversary A's advantage in finding collision in the following manner:

$$\begin{array}{c}\text{A}\text{d}{\text{v}}_{\mathcal{A}}^{\text{HASH}}\left(t\right)\\ \hspace{1em}=\text{Pr}\left[\left(x,x^{\prime }\right)⟸\mathcal{A}:x\ne x^{\prime }h\left(x\right)=h\left(x^{\prime }\right)\right],\end{array}$$ (4)

where Pr[E] denotes the probability of an event E and (x, x′) ⇐ A denotes that the pair (x, x′) is selected randomly by A. The adversary A is allowed to be probabilistic and the probability in the advantage is computed over the random choices made by the adversary A with the execution time t. The hash function h(·) is called collision resistant, if Adv_A ^HASH(t) ≤ ϵ, for any sufficiently small ϵ > 0.

We then define the following random oracle for our formal security analysis.

1. Reveal. This random oracle will unconditionally output the input x from the corresponding hash value y = h(x).

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

Theorem 3 —

Under the assumption that a one-way hash function h(·) closely behaves like a random oracle, the proposed scheme is provably secure against an adversary for deriving the secret number X _s of the server S _j.

Proof —

We follow the same proof presented in [14, 27, 28]. In this proof, we construct an adversary A such that he/she can derive the secret number X _s of the server S _j correctly. For this purpose, the adversary A runs the experiment, EXP1_A,REUAS ^HASH, 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 EXP1_A,REUAS ^HASH as cc1_A,REUAS ^HASH = Pr[EXP1_A,REUAS ^HASH = 1] − 1. Then the advantage of EXP1_A,REUAS ^HASH becomes Adv1_A,REUAS ^HASH(t ₁, q _R) = max⁡_A{S u cc1_A,REUAS ^HASH}, where the maximum is taken over all A's with the execution time t ₁ and the number of queries q _R made to the Reveal oracle. We call that our scheme is provably secure against the adversary A for deriving the secret number X _s of the server S _j, if Adv1_A,REUAS ^HASH(t ₁, q _R) ≤ ϵ, for any sufficiently small ϵ > 0.

Consider the experiment provided in Algorithm 1. According to this experiment, if the adversary A has the ability to invert the hash function h(·), then only he/she can derive the secret number X _s of the server S _j and win the game. However, according to Definition 2, it is a computationally infeasible (hard) problem for inverting a one-way hash function h(·). Since Adv_A ^HASH(t) ≤ ϵ, for any sufficiently small ϵ > 0, we have Adv1_A ^HASH(t ₁, q _R) ≤ ϵ, as it is dependent on the former. As a result, the adversary A does not have any ability to derive the secret number X _s of the server S _j.

Algorithm 1.

EX P1_{A,REU  AS} ^HASH.

Theorem 4 —

Under the assumption that a one-way hash function h(·) closely behaves like a random oracle, the proposed scheme is provably secure against an adversary for deriving the password PW _i of a user U _i, even if the smart card C _i of  U _i is lost or stolen by that adversary.

Proof —

We need to construct an adversary A such that he/she can derive the password PW _i of the user U _i correctly after extracting the information stored in the stolen or lost smart card C _i of U _i. For this purpose, the adversary A runs the experiment, EXP2_A,REUAS ^HASH, which is provided in Algorithm 2.

Similar to the experiment EXP1_A,REUAS ^HASH given in Algorithm 1, we also define the success probability for EXP2_A,REUAS ^HASH as S u cc2_A,REUAS ^HASH = Pr[EXP2_A,REUAS ^HASH = 1] − 1 and the advantage of EXP2_A,REUAS ^HASH as Adv2_A,REUAS ^HASH(t ₂, q _R) = max⁡_A{S u cc2_A,REUAS ^HASH}, where the maximum is taken over all A's with the execution time t ₂ and the number of queries q _R made to the Reveal oracle. Our scheme is then provably secure against the adversary A for deriving the password PW _i of the user U _i, if Adv2_A,REUAS ^HASH(t ₂, q _R) ≤ ϵ, for any sufficiently small ϵ > 0.

Now, consider the experiment provided in Algorithm 2. After extracting all the secret information (r _i, e _i, TD _i, D _i, K) from the memory of the stolen or lost smart card C _i of the user U _i, the adversary A can derive the password PW _i of the user U _i and win the game, if he/she has the ability to invert the one-way hash function h(·). Since inverting the one-way hash function h(·) is computationally infeasible, that is, Adv_A ^HASH(t) ≤ ϵ, for any sufficiently small ϵ > 0, we have Adv2_A ^HASH(t ₂, q _R) ≤ ϵ, as it is dependent on the former. Hence, our scheme is provably secure against an adversary for deriving the password PW _i of a user U _i, even if the smart card C _i of U _i is lost or stolen by that adversary.

Algorithm 2.

EX P2_{A,REU  AS} ^HASH.

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 U _i, and another for bob, which represents the remote server S _j. The role of the initiator, the user U _i, is shown in Algorithm 3. In this role, U _i first receives the start signal, changes its state value from 0 to 1, and then sends the registration request message 〈ID _i, R PW _i〉 securely to the server S _j using the symmetric key SK u i s j shared between U _i and S _j via the Snd(  ) operation. During the registration phase, the user U _i then receives a smart card containing the information {r _i, e _i, TD _i, D _i, h(·)} securely from S _j by the Rcv(  ) operation. The type declaration channel (dy) 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 i. 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, {Msg}_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 A 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 X = |>Y, which relate an event X and an action Y. This means that whenever we take a transition that is labeled in such a way so as to make the event predicate X true, we must immediately (i.e., simultaneously) execute action Y. If a variable V remains permanently secret, it is expressed by the goal secrecy_of V. Thus, if V is ever obtained or derived by the intruder, a security violation will result.

Algorithm 3.

Role specification in HLPSL for the user U _i of our scheme.

During the login phase of our scheme, the user U _i sends the login request message 〈N ID _i*, M ₂, M ₃, T _c〉 to the server S _j. During the authentication phase, after receiving the authentication request message 〈M ₇, M ₈, M ₉, T _s〉 from S _j, U _i sends the authentication acknowledgment message 〈M ₁₃〉 to S _j. In this role, witness (A, B, id, E) declares for a (weak) authentication property of A by B on E that agent A is witness for the information E; this goal will be identified by the constant id in the goal section [29]. This expresses that the agent named in variable B has freshly generated the value E for the agent named in variable A. The id 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 A by B on E declares that agent B requests a check of the value E; this goal will be identified by the constant id in the goal section [29]. This formalizes A's acceptance of the value E as having been generated for him/her by the agent named in B.

The role of the responder, the server S _j, is shown in Algorithm 4. During the registration phase, after receiving the registration request message 〈ID _i, R PW _i〉 securely from the user U _i, S _j then issues a smart card and sends it containing the information {r _i, e _i, TD _i, D _i, h(·)} securely to U _i. During the login phase, after receiving the login request message 〈N ID _i*, M ₂, M ₃, T _c〉, S _j sends the authentication request message 〈M ₇, M ₈, M ₉, T _s〉 to U _i in the authentication phase. Finally, S _j waits for the authentication acknowledgment message 〈M ₁₃〉 from U _i.

Algorithm 4.

Role specification in HLPSL for the server S _j 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 (i) 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.

1. secrecy_of subs1: it represents that X _s is kept secret to the server S _j only.

2. secrecy_of subs2: it represents that PW _i and K are kept secret to the user U _i only.

3. authentication_on alice_bob_tc: U _i (the smart card) generates a timestamp T _c. When the server S _j receives T _c in the messages from U _i, S _j authenticates U _i.

4. authentication_on alice_bob_rc: U _i (the smart card) generates a random nonce R _c, where R _c is only known to the user U _i. When the server S _j receives R _c in the messages from U _i, S _j authenticates U _i.

5. authentication_on bob_alice_ts: S _j generates a timestamp T _s. When U _i receives T _s in the messages from S _j, U _i authenticates S _j.

6. authentication_on bob_alice_rs: S _j generates a random nonce R _s, where R _s is only known to S _j. When the user U _i receives R _s in the messages from S _j, U _i authenticates S _j.

Algorithm 5.

Role specification in HLPSL for the session of our scheme.

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.

Table 7.

The result of the analysis using OFMC of our scheme.

% OFMC
% Version of 2006/02/13
SUMMARY
SAFE
DETAILS
BOUNDED_NUMBER_OF_SESSIONS
PROTOCOL
/home/avispa/web−interface−computation/
./tempdir/workfiletnHXFr.if
GOAL
as_specified
BACKEND
OFMC
COMMENTS
STATISTICS
parseTime: 0.00 s
searchTime: 0.30 s
visitedNodes: 13 nodes
depth: 4 plies

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 160 bits, the random nonce is 160 bits, the timestamp is 32 bits, and the hash value is 160 bits. Since the security of 163-bit ECC (elliptic curve cryptography) is the same as that for 1024-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 163-bit prime field and the modulus in RSA as 1024 bits. Thus, each elliptic curve point addition and that of multiplication take (163 + 163) = 326 bits as these are again a point in the elliptic curve, whereas the ciphertext in RSA is 1024 bits.

In our scheme, during the login phase, the login request message 〈N ID _i*, M ₂, M ₃, T _c〉 requires (160 + 160 + 160 + 32) = 512 bits. During the authentication phase of our scheme, the authentication request message 〈M ₇, M ₈, M ₉, T _s〉 requires (160 + 160 + 160 + 32) = 512 bits and, finally, the authentication acknowledgment message 〈M ₁₃〉 requires 160 bits. Summing all these, the total communication cost of our scheme during the login and authentication phases becomes (512 + 512 + 160) = 1184 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.

Scheme	Total number of messages required	Total number of bits required
Lee and Liu [13]	3	1504
Das and Bruhadeshwar [14]	3	1664
Sonwanshi et al. [3]	2	704
Jiang et al. [15]	3	1944
Ours	3	1184

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 4 hash computations. We ignore the cost of the bitwise XOR operation as it is negligible. The login and authentication phases require 14 hash computations, whereas the password change phase requires 6 hash computations. Thus, a total of 24 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.

Phase	[13]	[14]	[3]	[15]	Ours
Registration	2t h	4t h	2t h	7t ecm + 6t eca + 8t h	4t h
Login + authentication	2t me + 10t h	2t me + 14t h	13t h	10t ecm + 3t eca + 10t h	14t h
Password change	2t h	5t h	4t h	2t ecm + 2t eca + 8t h	6t h
Total	2t me + 14t h	2t me + 23t h	19t h	19t ecm + 11t eca + 26t h	24t h

Note: t _h: the time to compute a one-way hash function; t _me: the time to compute a modular exponentiation; t _ecm: the time to compute a point multiplication on the elliptic curve group; t _eca: the time to compute a point addition on the elliptic curve group.

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.

Functionality	[13]	[14]	[3]	[15]	Ours
F 1	No	Yes	No	Yes	Yes
F 2	Yes	Yes	Yes	Yes	Yes
F 3	No	Yes	Yes	Yes	Yes
F 4	Yes	Yes	Yes	Yes	Yes
F 5	Yes	Yes	No	Yes	Yes
F 6	Yes	Yes	No	Yes	Yes
F 7	Yes	Yes	No	No	Yes
F 8	Yes	Yes	No	Yes	Yes
F 9	Yes	Yes	No	Yes	Yes
F 10	Yes	Yes	No	Yes	Yes
F 11	No	Yes	No	No	Yes
F 12	No	Yes	No	No	Yes
F 13	No	Yes	No	Yes	Yes
F 14	No	Yes	Yes	Yes	Yes
F 15	No	Yes	Yes	Yes	Yes
F 16	No	No	No	No	No

Notes: F ₁: whether it protects against strong replay attacks or not; F ₂: whether it protects against man-in-the-middle attacks or not; F ₃: whether it protects against privileged insider attacks or not; F ₄: whether it protects against impersonation attacks or not; F ₅: whether it protects against stolen smart card attacks or not; F ₆: whether it protects against password guessing attacks or not; F ₇: whether it protects against denial-of-service attacks or not; F ₈: whether it provides mutual authentication or not; F ₉: whether it provides user anonymity property or not; F ₁₀: whether it establishes a secret session key between U _i and S _j after successful authentication or not; F ₁₁: whether it provides formal security proof or not; F ₁₂: whether it provides formal security verification or not; F ₁₃: whether it provides session key security or not; F ₁₄: whether it supports local password verification or not; F ₁₅: whether it provides password changing freely and correctly or not; F ₁₆: whether it requires any password verification table or not.

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.