J Med Syst (2014) 38:27 DOI 10.1007/s10916-014-0027-z

TRANSACTIONAL PROCESSING SYSTEMS

An Enhanced Biometric Authentication Scheme for Telecare Medicine Information Systems with Nonce Using Chaotic Hash Function Ashok Kumar Das · Adrijit Goswami

Received: 20 September 2013 / Accepted: 5 March 2014 / Published online: 3 June 2014 © Springer Science+Business Media New York 2014

Abstract Recently, Awasthi and Srivastava proposed a novel biometric remote user authentication scheme for the telecare medicine information system (TMIS) with nonce. Their scheme is very efficient as it is based on efficient chaotic one-way hash function and bitwise XOR operations. In this paper, we first analyze Awasthi-Srivastava’s scheme and then show that their scheme has several drawbacks: (1) incorrect password change phase, (2) fails to preserve user anonymity property, (3) fails to establish a secret session key beween a legal user and the server, (4) fails to protect strong replay attack, and (5) lacks rigorous formal security analysis. We then a propose a novel and secure biometric-based remote user authentication scheme in order to withstand the security flaw found in Awasthi-Srivastava’s scheme and enhance the features required for an idle user authentication scheme. Through the rigorous informal and formal security analysis, we show that our scheme is secure against possible known attacks. In addition, we simulate our scheme for the formal security verification using the widely-accepted AVISPA (Automated Validation of Internet Security Protocols and Applications) tool and show that our scheme is secure against passive and active attacks, including the

This article is part of the Topical Collection on Transactional Processing Systems A. K. Das () Center for Security, Theory and Algorithmic Research, International Institute of Information Technology, Hyderabad, 500 032, India e-mail: [email protected]; [email protected] A. Goswami Department of Mathematics, Indian Institute of Technology, Kharagpur, 721 302, India e-mail: [email protected]

replay and man-in-the-middle attacks. Our scheme is also efficient as compared to Awasthi-Srivastava’s scheme. Keywords Telecare medicine information systems · Chaotic hash function · Biohashing · Security · Biometrics · Password · Anonymity · AVISPA

Introduction A telecare medicine information system (TMIS) consists of the low-cost telecommunocation systems and customized patients’ monitoring devices, which enables healthcare delivery systems and brings the advantages of telemedicine directly into the patient’s home. Since these systems need automated patient medical records and electronically interconnected healthcare facilities, the security issues such as authentication, patient’s privacy protection and data confidentiality need to be considered very seriously in order to access the electronic medical records for a patient or doctor. In 1981, L. Lamport [21] introduced a solution to the problem of password-based remote user authentication using cryptographic hash functions. As pointed out in [3], the necessity of password resetting decreases its suitability for practical applications. After this proposal, several password-based remote user authentication schemes have been proposed in the literature [13, 15, 16, 19, 29]. Some comprehensive surveys on password-based remote user authentication schemes could be found in [17, 26]. However, most of these schemes are insecure against various attacks. Li and Hwang proposed an efficient biometric-based user authentication scheme using smart cards [22]. However, LiHwang’s scheme has several drawbacks which are shown in

27, Page 2 of 19

[7]. Das [7] further proposed an improved scheme to withstand those security weaknesses. Moreover, Li et al. showed that Li-Hwang’s scheme is also insecure [24] and they proposed an efficient scheme over Li-Hwang’s scheme. Chang et al. proposed an effective scheme providing uniqueness and anonymity for remote user authentication for connected health care [5]. However, their scheme has several drawbacks and security flaws, which are pointed out in [9], and in order to withstand those security weaknesses, a secure and effective scheme has been proposed [9]. Recently, Awasthi and Srivastava proposed a novel biometric remote user authentication scheme for the telecare medicine information system (TMIS) with nonce [3]. Though their scheme is very efficient, we show that their scheme has several drawbacks: (1) incorrect password change phase, (2) fails to preserve user anonymity property, (3) fails to establish a secret session key beween a legal user and the server, (4) fails to protect strong replay attack, and (5) lacks rigorous formal security analysis. In this paper, we aim propose an enhanced and secure biometric-based remote user authentication scheme using chaotic map based random nonce with the help of chaotic hash function. In our scheme, the user’s biometrics verification is performed using the secure efficient biohashing function. Our scheme keeps the original merits of Awasthi-Srivastava’s scheme. Our scheme enhances extra features required for an idle user authentication scheme as compared to Awasthi-Srivastava’s scheme. Though the rigorous informal and formal security analysis, we show that our scheme is secure against possible known attacks. In addition, we simulate our scheme for the formal security verification using the widely-accepted AVISPA (Automated Validation of Internet Security Protocols and Applications) tool and show that our scheme is secure against passive and active attacks, including the replay and man-in-the-middle attacks. Our scheme is also efficient as compared to Awasthi-Srivastava’s scheme. The remainder of this paper is organized as follows. In “Mathematical preliminaries” section, we discuss the properties of one-way chaotic hash function and biohashing for better understanding and analysis of Awasthi-Srivastava’s scheme and our scheme. In section “Review of AwasthiSrivastava’s scheme”, we provide the overview of AwasthiSrivastava’s scheme and its security weaknesses. We discuss our scheme in section “The proposed enhanced and secure biometric authentication scheme”. In section “Security analysis of the proposed scheme”, we provide the detailed security analysis of our scheme using both the rigorous informal and formal security analysis. In next section, we simulate our scheme for the formal security verification using the widely-accepted AVISPA (Automated Validation of Internet Security Protocols and Applications) tool to show that our scheme is secure against passive and active attacks. We then

J Med Syst (2014) 38:27

compare the performances of our scheme with Awasthi-Srivastava’s scheme in section “Performance comparison with related schemes”. Finally, we conclude the paper in next section.

Mathematical preliminaries In this section, we discuss the properties of chaotic hash function and biohashing for reviewing Awasthi-Srivastava’s scheme and analyzing our scheme. Chaotic hash function A chaotic hash function is one-dimensional and piecewise linear map [30]: ⎧ xi if 0 ≤ xi < β ⎪ β ⎪ ⎪ ⎨ xi −β if β ≤ xi < 0.5 xi+1 = 0.5−β 1−xi −β ⎪ ⎪ 0.5−β if 0.5 ≤ xi < 1 − β ⎪ ⎩ 1−xi if 1 − β ≤ xi ≤ 1, β where xi ∈ [0, 1] and β ∈ (0, 0.5) is the control parameter. The parameter β in xi+1 ensures that the map runs in a chaotic state when 0 < β < 0.5. This map transforms an interval [0, 1] onto itself and contains only one parameter β. The transformation has the initial value x0 and xi is the chaining variable, which indicates the chaining variable of a one-way hash algorithm. Biohashing In [18], Jina et al. proposed a two factor authenticator based on iterated inner products between tokenised pseudo-random number and the user specific fingerprint feature, which produces a set of user specific compact code that coined as biohashing, which is also one-way. Later, Lumini and Nanni in [25] proposed an improvement on biohashing. As specified in [6, 9], bioahshing is used to map a user/patient’s biometric features onto user-specific random vectors in order to generate a code, called the biocode and then discritizes the projection coefficients into zero or one. Biocode is also as secure as a hashed password.

Review of Awasthi-Srivastava’s scheme In this section, we first review Awasthi-Srivastava’s scheme [3]. We then discuss the drawbacks and security weaknesses of Awasthi-Srivastava’s scheme [3]. The notations listed in Table 1 are used throughout this paper for reviewing Awasthi-Srivastava’s scheme and also for describing our proposed scheme.

J Med Syst (2014) 38:27

Page 3 of 19, 27

Table 1 Notations used in this paper Symbol

Description

Sj Ui Ci I Di P Wi Bi Si

Trustworthy remote system (server) User/patient Mobile device of user Ui Identity of user Ui Password of user Ui Personal biometrics of user Ui Extracted fingerprint (biometric) template of user Ui Secure collision-free one-way chaotic hash function Secure biohashing function 1024-bit secret information of Sj only 1024-bit secret information of Ui only Chaotic map based 128-bit random nonce Random and temporary identity chosen by Sj for Ui Current timestamp of Ui ’s system Current timestamp of Sj ’s system Chaotic map based 128-bit random nonce chosen by Ui Chaotic map based 128-bit random nonce chosen by Sj Bitwise XORed of data A with data B Data A concatenates with data B

hc (·) H (·) Xs K n NI Di Tu Ts RNu RNs A⊕B A||B

Step 3:

Login phase If the user Ui wants to login to the remote server Sj , he/she needs to perform the following steps: Step 1:

Step 2:

Description of the scheme Awasthi-Srivastava’s scheme has the four phases: registration phase, login phase, authentication phase and password change phase, which are described in the following subsections.

computes P Wi ⊕ Si as P Wi ⊕ Si = α ⊕ γ , using α and γ . Sj then computes Ai = hc (I Di ⊕ Xs ), where Xs is a secret key of the server Sj and Xi = hc (Ai ), where hc (·) is the collision-resistant secure oneway chaotic hash function. Sj also computes Vi = Ai ⊕ hc (P Wi ⊕ Si ) and personalizes the secure information {I Di , Xi , Vi , Si , hc (·)} and saves these information into the mobile device of the user Ui .

Ui opens the login application software and then provides his/her identity I Di , password P Wi∗ and also imprints his/her fingerprint biometric template Si at the sensor. If the biometrics verification is successful, Ui ’s mobile device Ci further computes Bi = Vi ⊕ hc (P Wi∗ ⊕ Si ) and then checks if the condition hc (Bi ) = Xi holds or not. If it holds, Ci proceeds to the next step; otherwise, the phase terminates immediately. Ci computes D1 = hc (Bi ⊕ Tu ), where Tu is the current timestamp of the device, and sends the login message I Di , D1 , Tu  to Sj via a public channel.

Authentication phase After receiving the login message I Di , D1 , Tu  from the user Ui , Ci and Sj perform the following steps:

Registration phase Step 1: In order to register at the server Sj , the user Ui and the server Sj need to perform the following steps: Step 1:

Step 2:

The user Ui first chooses his/her identity I Di , password P Wi , and then generates a chaotic map based random nonce n, and interactively submits I Di , β = Epu (P Wi ⊕ n) to the registration center, where Epu (·) represents the public key encryption using the public key pu. Ui then imprints his/her fingerprint (biometric) impression γ = (Si ⊕ n) at the sensor, where Si is the extracted fingerprint template of the user Ui . The server Sj decrypts the encrypted password Epu (P Wi ⊕ n) using its own private key pr to retrieve α = Dpr [β] = Dpr [Epu (P Wi ⊕ n)] = P Wi ⊕ n, where Dpr (·) represents the public key decryption using the private key pr. Sj then

Step 2:

Sj first checks the format of I Di . If it is valid, Sj checks if Ts = Tu , where Ts is the timestamp of the remote server Sj . If both are invalid, Sj rejects the login request of the user Ui . Otherwise, Sj checks if (Ts − Tu ) > T , where T is the expected valid time interval for transmission delay. If it does not hold, Sj rejects the login message of Ui . Sj computes D1∗ = hc (hc (I Di ⊕ Xs ) ⊕ Tu ), using its own secret key Xs , and checks if D1∗ = D1 . If it does not hold, the login request of Ui is rejected. On the other hand, Sj assumes that Ui is authentic and Sj accepts the login request of the user Ui . For mutual authentication purpose, Sj also computes D2 = hc (hc (I Di ⊕ Xs ) ⊕ Ts ), where Ts is the current timestamp of the server Sj , and sends the authentication message D2 , Ts  to the user Ui .

27, Page 4 of 19

Step 3:

J Med Syst (2014) 38:27

After receiving the authentication message in Step 2, Ci verifies if Ts is invalid or Ts = Tu . If it is so, this phase terminates immediately. Otherwise, Ci computes D2∗ = hc (Bi ⊕ Ts ) and checks if the condition D2∗ = D2 is satisfied or not. If it is satisfied, Ui believes that Sj is authentic, and Sj allows access to the services to the user Ui .

Incorrect password change phase

If the user Ui wants to update his/her password, the following steps are performed by the user’s mobile device locally without further contacting the remote server Sj :

The design flaws presented in the password change phase for Awasthi-Srivastava’s scheme is similar to that in LiHwang’s scheme [22] and Chang et al.’s scheme [6], which were given in [7, 9]. In order to update the old password P Wiold of the user Ui , the mobile device Ci of the user Ui never checks this password before it updates the new password P Winew . In Awasthi-Srivastava’s scheme, Ui first inputs his/her biometric credential Si into the smartcard reader. If the biometric verification is successful, Ui directly inputs the old password P Wiold and the new password P Winew . Usually for security reasons, a user keeps different passwords for different applications. We assume that the user Ui enters his/her old password P Wiold incorrectly by mistake, where P Wiold = P Wi . According to the Awasthi-Srivastava’s password change phase, Ci directly computes

Step 1:

Vinew = Vi ⊕ hc (P Wiold ⊕ Si ) ⊕ hc (P Winew ⊕ Si )

The summary of message exchanges during the registration phase, login phase and authentication phase of AwasthiSrivastava’s scheme is shown Table 2. Password change phase

Step 2:

Ui inputs his/her biometric credential Si and then requests the mobile device Ci to update the password. If the biometric verification passes, the system directs the user Ui to provide his/her old password and new password. Ui then submits his/her old password P Wiold and new password P Winew . Ci then computes Vinew = Vi ⊕ hc (P Wiold ⊕ Si ) ⊕ hc (P Winew ⊕ Si ), and updates the smartcard information Vi with Vinew .

Note that the user Ui ’s mobile device Ci now contains the information {I Di , Xi , Vinew , Si , hc (·)}. Drawbacks of Awasthi-Srivastava’s scheme In this section, we show that Awasthi-Srivastava’s scheme has a security weakness and some drawbacks, which are discussed in the following subsections.

Table 2 Summary of message exchanges during the registration phase, login phase and authentication phase of Awasthi-Srivastava’s scheme

= Ai ⊕ hc (P Wi ⊕ Si ) ⊕ hc (P Wiold ⊕ Si ) ⊕hc (P Winew ⊕ Si ) = Ai ⊕ hc (P Winew ⊕ Si ), since P Wiold = P Wi . As a result, Ci updates Vi with Vinew and clearly, this is not correct. As a consequence, when the same user Ui will later login to the server Sj providing his/her biometric credential Si , new changed password P Winew and identity I Di , it is noted that after successful biometric authentication, the condition hc (Bi ) = Xi always fails, where Bi = Vinew ⊕hc (P Winew ⊕Si ) even if Ui enters correctly P Winew at that time. Hence, in presence of such irrecoverable error in the password change phase, the user Ui will have only the option to issue another new mobile device with necessary information by the server Sj . This clearly shows that Awasthi-Srivastava’s scheme fails to provide correct and effective password change phase, which is considered as

Phase

Ui /Ci

Registration

I Di , β, γ  −−−−−−−→ (via a public channel)

Sj

I Di , Xi , Vi , Si , hc (·) ←−−−−− (via a secure channel) Login and Authentication

I Di , D1 , Tu  −−−−−−−−−→ (via a public channel)

D2 , Ts  ←−−−−− (via a public channel)

J Med Syst (2014) 38:27

Page 5 of 19, 27

a crucial component while designing an idle remote user authentication scheme.

is received, the timestamp has already expired. Hence, this attack is a little weak.

Fails to preserve user anonymity property

Lacks formal security analysis

It is desirable for an idle remote user authentication scheme to preserve the user anonymity property [23], where instead of revealing/sending the real identity I Di of a user Ui , the transmitted messages should contain a random and temporary identity for the user Ui . Note that during the registration process, the user Ui interactively submits I Di and Epu (P Wi ⊕ n). Again, during the login phase, the user Ui also sends the login message I Di , D1 , Tu  to the server Sj via a public channel. Since I Di is known to an adversary by eavesdropping these messages, Awasthi-Srivastava’s scheme fails to preserve user anonymity property.

Awasthi-Srivastava’s scheme contains only some informal security analysis and it lacks the rigorous formal security analysis for its security under the random oracle model and using the simulation for formal security verification under the AVISPA (Automated Validation of Internet Security Protocols and Applications) tool to ensure that the scheme is secure against passive and active attacks.

Fails to establish a secret session key between a user Ui and the remote server Sj

In this section, we first mention the main motivation behind the proposal of our enhanced and secure biometric authentication scheme, which uses the secure collision-resistant one-way chaotic hash function hc (·) and the secure biohashing function H (·). We then provide a threat model under which our scheme and Awasthi-Srivastava’s scheme are analyzed and evaluated. We finally provide the different phases in detail for our scheme.

While designing an idle remote user authentication scheme, another desirable criteria is to establish a secret session key between a user Ui and the remote server Sj [23]. Note that the mutual authentication is achieved in AwasthiSrivastava’s scheme during the authentication phase. However, there is no secret session key establishment process after successful mutual authentication between Ui and Sj , so that Ui and Sj can communicate securely in future for their secure communications for accessing services from Sj by Ui . Fails to protect strong replay attack During the login phase of Awasthi-Srivastava’s scheme, the user Ui sends the login message I Di , D1 , Tu  to the server Sj via a public channel. Suppose an adversary intercepts this login message and sends another login message I Di , D1 , Tu  = I Di , D1 , Tu  within the expected valid time interval to the server Sj . After receiving this message, the remote server Sj validates the timestamp Tu within the expected valid time interval and then computes D1∗ = hc (hc (I Di ⊕ Xs ) ⊕ Tu ), using its own secret key Xs , and checks if D1∗ = D1 . If it does not hold, the login request of Ui is rejected. On the other hand, Sj assumes that Ui is authentic and Sj accepts the login request of the user Ui . For mutual authentication, the server Sj will send the authentication message D2 , Ts  to the user Ui . The user Ui will validate this authentication message and treats the server Sj as authentic. As pointed out in [8], it is noted that this attack depends on the value of the expected valid time interval and this attack can be prevented by setting the valid time interval to a small value, so that when the replayed message

The proposed enhanced and secure biometric authentication scheme

Motivation The idea proposed in Awasthi-Srivastava’s scheme is very interesting and novel. This scheme is also very efficient due to usage of efficient one-way chaotic hash function and bitwise XOR operation. However, it is shown that AwasthiSrivastava’s scheme has a design flaw in the password change phase, where even if the user Ui enters his/her old password P Wiold incorrectly by mistake, the new password change takes place incorrectly by the mobile device. The user Ui will have only the option to issue another new mobile device with necessary information by the server Sj . As a result, Awasthi-Srivastava’s scheme fails to provide the correct and effective password change phase, which is considered as a crucial component while designing an idle remote user authentication scheme. Further, AwasthiSrivastava’s scheme has several drawbacks such as it fails to preserve the user anonymity property, it fails to establish a secret session key between a user Ui and the remote server Sj , it fails to protect strong replay attack, and it lacks formal security analysis. This motivates us that there is a great need to enhance Awasthi-Srivastava’s scheme, which will be secure against different known attacks and supports other desirable properties that an idle remote user authentication scheme requires to achieve. We propose an enhanced and secure biometric remote user authentication scheme for the

27, Page 6 of 19

telecare medicine information system in order to eliminate the security flaw found in Awasthi-Srivastava’s scheme and enhance other features compared to Awasthi-Srivastava’s scheme. Our scheme retains the original merits of AwasthiSrivastava’s scheme. We show that our scheme is also efficient as in Awasthi-Srivastava’s scheme, since our scheme is based on the efficient secure collision-resistant one-way chaotic hash function hc (·), the secure biohashing function H (·), and bitwise XOR operation. Through both rigorous informal and formal security analysis, we show that our scheme has the ability to tolerate different known attacks. In addition, we simulate our scheme for formal security analysis using the widely-accepted AVISPA tool that our scheme is secure against passive and active attacks including the replay and man-in-the-middle attacks.

J Med Syst (2014) 38:27

Step R1:

Step R2: Step R3:

Threat model Step R4: As in [9, 28], we make use of the Dolev-Yao threat model [14] in which any two communicating parties communicate over an insecure channel. Any adversary (attacker or intruder) can eavesdrop the transmitted messages over the public insecure channel and he/she will have the ability to modify, delete or change the contents of the transmitted messages. Further, we assume that if a user’s smart card or mobile device is stolen or lost, an attacker can know all the sensitive information stored in its memory by the power analysis attack of the smart card or the mobile device [20, 27].

γ = = = Ai = Xi = Vi = =

Step R5:

Description of our scheme The notations listed in Table 1 are used for describing our scheme. As in Chang et al.’s scheme [6] and Das-Goswami’s scheme [9], we make use of the biohashing function H (·) ([18, 25]) for the user’s personal biometric verification. An ID table is maintained by the trustworthy remote system (server) Sj . To achieve user anonymity, a random and temporary identity N I Di instead of the permanent identity I Di of the user Ui is transmitted in the messages as in [6, 9], where N I Di is updated by the server Sj for each session. Our scheme consists of the following four phases: registration phase, login phase, authentication and session key agreement phase, and password change phase.

The user Ui first chooses his/her identity I Di , password P Wi , and inputs the personal biometrics Bi (for example, fingerprint) at the sensor. Ui then generates a 128-bit chaotic map based random nonce n and a 1024-bit random number K, which are kept secret to the user Ui only. Ui computes fi = H (I Di ||K||Bi ) using the biohashing function H (·). Ui then computes masked password RP Wi = hc (P Wi ) ⊕ n using the chaotic hash function hc (·) and nonce n. Note that the output of the chaotic hash function hc (·) is taken as 128 bits for security purpose so that the collisionresistant property is preserved. Ui further computes the masked biometrics RBi = H (Bi ) ⊕ n and interactively sends the registration request message I Di , RP Wi , RBi  to the registration center Sj via a secure channel. After receiving the registration request message in Step R3, the server computes RP Wi ⊕ RBi ⊕ I Di hc (P Wi ) ⊕ n ⊕ H (Bi ) ⊕ n ⊕ I Di hc (P Wi ) ⊕ H (Bi ) ⊕ I Di , hc (I Di ⊕ Xs ), hc (Ai ), Ai ⊕ hc (γ ) hc (I Di ⊕ Xs ) ⊕ hc (hc (P Wi ) ⊕ H (Bi ) ⊕ I Di ),

where Xs is a 1024-bit secret number known to the server Sj only. Sj then selects a random and temporary identity N I Di instead of the permanent identity I Di of the user Ui , and computes T Di = N I Di ⊕ hc (I Di ), Di = T Di .

Step R6:

Sj personalizes the information {T Di , Di , Xi , Vi , hc (·), H (·)} and saves these information into the mobile device Ci of the user Ui . Finally, after receiving the mobile device Ci from the server Sj , Ui stores fi and K in the memory of the mobile device Ci .

As compared to Awasthi-Srivastava’s scheme, it is clear that in our scheme the real permanent identity I Di of the user Ui is not stored in his/her mobile device Ci . Login phase

Registration phase Before accessing the services from the telecare medicine information systems server Sj , the user Ui needs to register to the registration center. This phase consists of the following steps:

For accessing the services from the server Sj , the user Ui must login to the system. As suggested in [9], we have two cases in order to protect denial-of-service (DoS) attack. In first case (Case I), the latest identities kept by Ci and Sj are matched against each other. In second case (Case II), the

J Med Syst (2014) 38:27

latest random identities kept by Ci and Sj are distinct. For this purpose, the following steps are needed to execute by the user Ui : Step L1:

Step L2:

Ui first opens the login application software. Ui then provides his/her identity I Di∗ , password P Wi∗ and also imprints his/her fingerprint biometric template Bi∗ at the sensor. The mobile device Ci of Ui computes fi∗ = H (I Di∗ ||K||Bi∗ ) using the stored secret number K and biohashing function H (·). Ci then checks if the condition fi∗ = fi holds or not. If it is satisfied, it ensures that the biometrics verification is successful. Otherwise, the login phase terminates immediately. Ci computes δ ∗ = hc (P Wi∗ ) ⊕ H (Bi∗ ) ⊕ I Di∗ and M1 = Vi ⊕ hc (δ ∗ ) = hc (I Di ⊕ Xs ) ⊕ hc (hc (P Wi ) ⊕ H (Bi ) ⊕ I Di ) ⊕ hc (hc (P Wi∗ ) ⊕ H (Bi∗ ) ⊕ I Di∗ ). Ci then checks if the condition hc (M1 ) = Xi holds or not. If it holds, it also ensures that Ui has entered his/her password P Wi∗ correctly (that is, P Wi∗ = P Wi ) and Ci proceeds further; otherwise, the phase terminates immediately.

Case I This case is executed when the pair (I Di , N I Di ) is found in the ID table maintained by the server Sj . Step LI1:

Ci generates a 128-bit chaotic map based random nonce RNu . Ci then computes M2 = M1 ⊕ RNu ⊕ Tu = hc (I Di ⊕ Xs ) ⊕ RNu ⊕ Tu , M3 = hc (M1 ||RNu ||Tu ||I Di ), N I Di = hc (I Di ) ⊕ Di ,

Step LI2:

where Tu is the current system timestamp of the mobile device Ci of the user Ui . Ci sends the login request message N I Di , M2 , M3 , Tu  to Sj via a public channel.

Case II This case is executed when the pair (I Di , N I Di ) is not found in the ID table maintained by the server Sj . Step LII1:

Ci generates a 128-bit chaotic map based random nonce RNu . Ci then computes M2 = M1 ⊕ RNu ⊕ Tu = hc (I Di ⊕ Xs ) ⊕ RNu ⊕ Tu , M3 = hc (M1 ||RNu ||Tu ||I Di ), N I Di = hc (I Di ) ⊕ T Di , where Tu is the current system timestamp of the mobile device Ci of the user Ui . Note that

Page 7 of 19, 27

Step LII2:

in this case N I Di is computed as hc (I Di ) ⊕ T Di instead of hc (I Di ) ⊕ Di in Case I. Ci sends the login request message N I Di , M2 , M3 , Tu  to Sj via a public channel.

Authentication and session key agreement phase In this phase, after receiving the login request message from the user Ui , the server Sj authenticates Ui and Ui also authenticates Sj for mutual authentication purpose. After successful mutual authentication, both Ui and Sj will establish a common secret session key between them so that they can communicate securely using the established session key for their future secure communications. This phase has the following steps. After receiving the login request message N I Di , M2 , M3 , Tu  from the user Ui , the server Sj first checks if the pair (I Di , N I Di ) is present in its maintained ID table. If it is found, then it proceeds for Case I; otherwise, it proceeds for Case II. Case I This case is executed when the pair (I Di , N I Di ) is found in the ID table maintained by the server Sj . Step AI1:

Sj checks the validity of the timestamp Tu in the received login request message by checking the condition |Tu −Tu∗ | > T , where T is the expected valid time interval for transmission delay and Tu∗ is the current system timestamp of the server Sj . If it is invalid, the phase terminates immediately. On the other hand, Sj computes M4 = hc (I Di ⊕ Xs ), M5 = M2 ⊕ Tu ⊕ M4 = hc (I Di ⊕ Xs ) ⊕ RNu ⊕ Tu ⊕ Tu ⊕hc (I Di ⊕ Xs ) = RNu , M6 = hc (M4 ||M5 ||Tu ||I Di ). Sj then checks whether the condition M6 = M3 holds or not. If it does not hold, the phase terminates immediately. Otherwise, Sj accepts the login request of the user Ui and treats the user Ui as authentic user. In order to protect the man-in-the-middle attacks and the replay attacks, we adopt the similar strategy as used in [7–9]. The server Sj can store the pair (I Di , M5 ), where M5 = RNu in its database. If the server Sj receives the next login request message N I Di , M2 , M3 , Tu  from the user Ui or an attacker, Sj first checks

27, Page 8 of 19

Step AI2:

J Med Syst (2014) 38:27

the validity of the timestamp Tu and if it is valid, it further computes M4 = hc (I Di ⊕ Xs ), using its own secret number Xs . Sj then computes M5 = M2 ⊕ Tu ⊕ M4 = hc (I Di ⊕ Xs ) ⊕ RNu ⊕ Tu ⊕ hc (I Di ⊕ Xs ) ⊕ Tu = RNu , say. Now, if M5 = M5 , it certainly ensures that the login request message is a replay one. Otherwise, Sj needs to update M5 with the computed M5 in its database. In our scheme, both the timestamp and random nonce defend strongly the replay and man-in-the-middle attacks. Sj selects a new random and temporary identity N I Dinew , generates a 128-bit chaotic map based random nonce RNs , and further computes

computes the secret session key shared with Sj as SKUi ,Sj = hc (I Di ||M1 ||RNu ||Tu ||M10 || Ts ). Note that SKUi ,Sj = hc (I Di ||hc (I Di ⊕ Xs )||RNu ||Tu ||RNs ||Ts ) = SKSj ,Ui . This means that both Ui and Sj share the same secret session key between them. Ci also updates T Di and Di with Di and Di ⊕ N I Di ⊕ N I Dinew∗ in it memory, respectively.

Case II This case is executed when the pair (I Di , N I Di ) is not found in the ID table maintained by the server Sj . Step AII1:

M7 = M4 ⊕ RNs ⊕ Ts = hc (I Di ⊕ Xs ) ⊕ RNs ⊕ Ts , M8 = hc (M4 ||RNs ||Ts ||M5 ||Tu ||I Di ||N I Dinew ), M9 = N I Dinew ⊕ hc (M4 ||RNs ||Ts ||I Di ),

Step AI3:

where Ts is the current system timestamp of the server Sj . Sj then sends the authentication request message M7 , M8 , M9 , Ts  to the user Ui . Sj further computes the secret session key shared with Ui as SKSj ,Ui = hc (I Di ||M4 ||M5 ||Tu ||RNs ||Ts ). Note that SKSj ,Ui = hc (I Di ||hc (I Di ⊕ Xs )||RNu ||Tu ||RNs ||Ts ). After receiving the authentication request message M7 , M8 , M9 , Ts  from the server in Step AI2, Ci first checks the validity of the timestamp Ts in the received authentication request message by checking the condition |Ts − Ts∗ | > T , where T is the expected valid time interval for transmission delay and Ts∗ is the current system timestamp of the mobile device Ci . If it is invalid, the phase terminates immediately. Otherwise, Ci computes

The summary of message exchanges during the registration phase, login phase, and authentication and session key agreement phase of our scheme is given in Table 3. Password change phase In order to enhance security, an important desirable property of an idle remote user authentication scheme is that the user Ui should change his/her password periodically locally without contacting the remote server Sj . Suppose the user Ui wants to change his/her original password P Wi by a new changed password P Winew . The following steps are necessary for performing this activity:

Step P1:

M10 = M7 ⊕ M1 ⊕ Ts = hc (I Di ⊕ Xs ) ⊕ RNs ⊕ Ts ⊕hc (I Di ⊕ Xs ) ⊕ Ts = RNs , N I Dinew∗ = M9 ⊕ hc (M1 ||M10 ||Ts ||I Di ), M11 = hc (M1 ||M10 ||Ts ||RNu ||Tu ||I Di ||N I Dinew∗ ). Ci finally checks if the condition M11 = M8 holds or not. If it does not hold, the phase terminates immediately. Otherwise, Ci (the user Ui ) accepts the server Sj as authentic and

The login request message N I Di , M2 , M3 , Tu  from the user Ui contains N I Di = hc (I Di )⊕T Di . Processes in this phase remain same as in Case I except Ci updates Di with Di ⊕N I Di ⊕N I Dinew∗ without changing T Di in Step AI3.

Step P2:

Ui first enters his/her identity I Di∗ and imprints the personal biometrics template Bi∗ at the sensor, and requests the smartcard reader to update his/her old password. The mobile device Ci of the user Ui then computes fi∗ = H (I Di∗ ||K||Bi∗ ) using the stored secret value K and biohashing function H (·). Ci verifies if the condition fi = fi∗ holds or not. Note that fi = H (I Di || K||Bi ) is already stored in the memory of Ci . If this condition does not hold, the biometric verification fails and the phase terminates immediately. On the other hand, Ui passes the biometric verification, and the mobile device Ci asks the user Ui to enter his/her password old password P Wiold and new changed password P Winew .

J Med Syst (2014) 38:27

Page 9 of 19, 27

Table 3 Summary of message exchanges during the registration phase, login phase and authentication phase of our scheme

Phase

Ui /Ci

Registration

I Di , RP Wi , RBi  −−−−−−−−−−−−−→ (via a secure channel)

Sj

T Di , Di , Xi , Vi , hc (·), H (·) ←−−−−−−− (via a secure channel) Login and

NI Di , M2 , M3 , Tu  −−−−−−−−−−−−−−→ (via a public channel)

Authentication

Step P3:

Ci computes A∗i

hc (hc (P Wiold ) ⊕ H (Bi∗ ) ⊕ I Di∗ )

= Vi ⊕ = Ai ⊕ hc (hc (P Wi ) ⊕ H (Bi ) ⊕ I Di ) ⊕hc (hc (P Wiold ) ⊕ H (Bi∗ ) ⊕ I Di∗ ) = hc (I Di ⊕ Xs ) ⊕ hc (hc (P Wi ) ⊕ H (Bi ) ⊕I Di ) ⊕ hc (hc (P Wiold ) ⊕ H (Bi∗ ) ⊕ I Di∗ ).

Ci then checks if the condition hc (A∗i ) = Xi holds or not. If this condition does not hold, the old password verification fails and the phase terminates immediately. Otherwise, Ci computes Vinew = A∗i ⊕ hc (hc (P Winew ) ⊕ H (Bi∗ ) ⊕ I Di∗ ) = hc (I Di ⊕ Xs ) ⊕hc (hc (P Winew ) ⊕ H (Bi∗ ) ⊕ I Di∗ ), Step P4:

since P Wi = P Wiold . Finally, Ci updates Vi with Vinew in its memory.

It is clear to observe that in our scheme the user’s new password P Winew is always updated correctly and locally in his/her mobile device without contacting further the remote server Sj by our password change phase.

Security analysis of the proposed scheme For analyzing the security of our scheme, we use the threat model given in section “Threat model”. Informal security analysis In this section, through the informal security analysis we show that our scheme is secure against the following known attacks. Stolen mobile device attacks Suppose the user Ui ’s mobile device Ci is lost or stolen. According to our threat model, an attacker can extract all the

M7 , M8 , M9 , Ts  ←−−−−−−−−−−− (via a public channel)

stored information {T Di , Di , Xi , Vi , K, fi } from the memory of the mobile device Ci , where Xi = hc (Ai ) = hc (hc (I Di ⊕ Xs )), Vi = Ai ⊕ hc (hc (P Wi ) ⊕ H (Bi ) ⊕ I Di ), and fi = H (I Di ||K||Bi ). In order to know the biometric template Bi of Ui , the attacker has to invert H (·). For this purpose, the attacker has to guess both I Di and Bi correctly as I Di∗ and Bi∗ , respectively, and if the computed value fi∗ = H (I Di∗ ||K||Bi∗ ) using the extracted K matches with fi , the attacker will know Bi . As pointed out in [9], the probability of guessing a correct identity I Di composed of exact n characters and biometric template Bi composed of exact m bits is 1 approximately 26n+m , which is very negligible, and as a result, it is a computationally infeasible problem for the attacker to derive Bi from fi due to secure biohashing function H (·). Again, to know the secret key Xs of the server Sj , the attacker needs to guess both I Di and Xs , because I Di and Xs are protected in Xi . Thus, the probability of guessing both I Di composed of exact n characters and Xs composed of exact l bits (in our scheme, l = 1024) is approximately 1 1 = 26n+1024 , which is also very negligible, and the 26n+l attacker does not have any feasible way to derive Xs . Finally, to derive the password P Wi of the user Ui from Vi , the attacker needs to know I Di , Xs , and Bi at the same time. Thus, the probability of guessing I Di composed of exact n characters, Bi composed of exact m bits, and Xs composed of exact l bits (in our scheme, l = 1024) is 1 1 approximately 26n+m+l = 26n+l+1024 , which is also very negligible, and the attacker has no feasible way to derive P Wi of the user Ui . Hence, our scheme is secure against an attacker for deriving I Di , P Wi , Xs , and Bi . Replay attacks Assume that an attacker intercepts all the transmitted messages N I Di , M2 , M3 , Tu  and M7 , M8 , M9 , Ts  during the login phase, and the authentication and session key agreement phase, respectively. Let the attacker

27, Page 10 of 19

start a new session with the login request message N I Di , M2 , M3 , Tu  = N I Di , M2 , M3 , Tu , which is sent to the server Sj . In our scheme, the server Sj stores the pair (I Di , M5 ), where M5 = RNu , in its database. In this case, the server Sj first checks the validity of the timestamp Tu and if it is valid, Sj further computes M4 = hc (I Di ⊕ Xs ), M5 = M2 ⊕ Tu ⊕ M4 = hc (I Di ⊕ Xs ) ⊕ RNu ⊕ Tu ⊕ hc (I Di ⊕ Xs ) ⊕ Tu = RNu , say. If M5 = M5 , it ensures that this login request message is a replay one. Hence, both timestamp and random nonce in our scheme help to protect strongly the replay attacks. Man-in-the-middle attacks During the login phase, if an attacker intercepts the login request message N I Di , M2 , M3 , Tu  during the login phase, and wants to change this message, he/she has to change both M2 and M3 correctly. To change M2 , the attacker needs to know both I Di and Xi , where M2 = M1 ⊕ RNu ⊕ Tu = hc (I Di ⊕ Xs ) ⊕ RNu ⊕ Tu . Similarly, to change M3 = hc (M1 ||RNu ||Tu ||I Di ), the attacker needs to know both M1 = hc (I Di ⊕ Xs ) and I Di . As a result, the probability of guessing a correct I Di composed of exact n characters and Xs composed of exact l 1 bits (in our scheme, l = 1024) is approximately 26n+l 1 = 26n+1024 , which is very negligible. Thus, the attacker does not have any ability to modify the login request message. Similarly, the attacker does not have the ability to change the authentication request message M7 , M8 , M9 , Ts  during the authentication and session key agreement phase. Hence, our scheme protects the man-in-the-middle attacks.

Impersonation attacks Suppose an attacker intercepts the login request message N I Di , M2 , M3 , Tu  during the login phase, and the authentication request message M7 , M8 , M9 , Ts  during the authentication and session key agreement phase. In a new session, the attacker has to modify the login request message N I Di , M2 , M3 , Tu  in order to impersonate/cheat the server Sj . However, as pointed out in the analysis of the man-in-the-middle attacks in our scheme, the attacker needs to guess correctly both I Di and Xs in order to change correctly both M2 and M3 , and the probability of guessing both I Di and Xs correctly is very negligible. Again, the attacker has to modify the authentication request message M7 , M8 , M9 , Ts  in order to cheat the user Ui . To change this message, the attacker needs to change M7 , M8 , and M9 correctly. In order to do this, the attacker needs to guess correctly both I Di and Xs , and the probability of guessing these correctly is also very negligible. Hence, our scheme protects the impersonation attacks.

J Med Syst (2014) 38:27

Offline password guessing attacks Suppose the user Ui ’s mobile device Ci is lost or stolen, and an attacker extracts all the stored information {T Di , Di , Xi , Vi , K, fi } from the memory of the mobile device Ci by the power analysis attack [27], where Xi = hc (Ai ) = hc (hc ( I Di ⊕ Xs )), Vi = Ai ⊕ hc (hc (P Wi ) ⊕ H (Bi ) ⊕ I Di ), and fi = H (I Di ||K||Bi ). Let the attacker try to derive the password P Wi in offline from Vi and fi . However, the attacker needs to guess I Di and Bi both at the same time using fi , and the probability of guessing a correct I Di composed of exact n characters and Bi composed 1 of exact m bits is approximately 26n+m , which is negligible. Again, to derive the password P Wi , the attacker needs to guess I Di , Bi and P Wi at the same time. The probability of guessing I Di composed of exact n characters, Bi composed of exact m bits, and Xs composed of exact l bits (in our 1 1 scheme, l = 1024) is approximately 26n+m+l = 26n+l+1024 , which is also very negligible, and the attacker has no feasible way to derive P Wi of the user Ui . Thus, our scheme is secure against the offline password guessing attacks. Online password guessing attacks Suppose an attacker tries to derive the password P Wi of the user Ui from the transmitted login request message N I Di , M2 , M3 , Tu  during the login phase, and the authentication request message M7 , M8 , M9 , Ts  during the authentication and session key agreement phase, where M2 = M1 ⊕ RNu ⊕Tu = hc (I Di ⊕Xs )⊕RNu ⊕Tu , M3 = hc (M1 ||RNu ||Tu ||I Di ), N I Di = hc (I Di ) ⊕ T Di , M7 = M4 ⊕ RNs ⊕ Ts = hc (I Di ⊕Xs )⊕RNs ⊕Ts , M8 = hc (M4 ||RNs ||Ts ||M5 ||Tu ||I Di ||N I Dinew ), M9 = N I Dinew ⊕ hc (M4 ||RNs ||Ts ||I Di ). Note that none of the messages involves the user’s password P Wi directly or indirectly. Thus, these messages are not helpful for deriving the password P Wi of a user Ui , and our scheme is then secure against online password guessing attacks. Denial-of-service attacks As in [6, 9], Ci stores T Di and Di for the previous and the latest random identities, respectively. Thus, the corruption of the messages N I Di , M2 , M3 , Tu  and M7 , M8 , M9 , Ts  are not possible in the system. As a result, our scheme prevents the denial-of-service (DoS) attacks. Privileged insider attacks Note that during the registration phase of our scheme, the user Ui sends the registration request message I Di , RP Wi , RBi  to Sj via a secure channel, where

J Med Syst (2014) 38:27

RP Wi = hc (P Wi ) ⊕n, RBi = H (Bi ) ⊕ n, and n is a 128bit chaotic map based random nonce. Since n is unknown to the server Sj , to derive the password P Wi of the user Ui from RP Wi , the server Sj needs to guess correctly both P Wi and n. The probability of guessing P Wi composed of exact m characters and n composed of exact l bits (in our 1 1 scheme, l = 128) is approximately 26m+l = 26m+128 , which is very negligible, and the server Sj has no feasible way to derive P Wi of the user Ui . To derive the biometrics template Bi from RBi , the server Sj needs again to guess both n and Bi . The probability of guessing Bi composed of exact m bits and n composed of exact l bits (in our scheme, l = 128) 1 1 is approximately 2m+l = 2m+128 , which is also negligible, and thus, the server Sj has no feasible way to derive Bi of the user Ui . As a result, an insider can not derive P Wi and Bi , and hence, our scheme protects the privileged insider attacks. Parallel session and reflection attacks In our scheme, without knowing the correct password P Wi and biometrics template Bi of a user Ui , an attacker can not masquerade as a legal user by creating a valid login request message from the eavesdropped messages during the communication between Ui and the server Sj . Thus, our scheme protects the parallel session and reflection attacks. Server spoofing attacks In our scheme, after receiving the login request message of the user Ui , the server Sj also sends the authentication request message for mutual authentication. An attacker can not resend the forged message to the user Ui because of involvement of the timestamps Tu , Ts , and random nonces RNu and RNs . As a result, our scheme withstands the server spoofing attack. User anonymity Suppose an attacker eavesdrops the login request message N I Di , M2 , M3 , Tu  during the login phase, and the authentication request message M7 , M8 , M9 , Ts  during the authentication and session key agreement phase, where M2 = M1 ⊕ RNu ⊕ Tu = hc (I Di ⊕ Xs ) ⊕ RNu ⊕ Tu , M3 = hc (M1 ||RNu ||Tu ||I Di ), N I Di = hc (I Di ) ⊕ T Di , M7 = M4 ⊕ RNs ⊕ Ts = hc (I Di ⊕ Xs ) ⊕ RNs ⊕ Ts , M8 = hc (M4 ||RNs ||Ts ||M5 ||Tu ||I Di ||N I Dinew ), M9 = hc (M4 ||RNs ||Ts ||I Di )⊕N I Dinew . It is clear that all M2 , M3 , M7 , M8 and M9 involve implicitly the user identity I Di . Due to the one-way property of the collision-resistant chaotic hash function hc (·), it is a computational infeasible task for an attacker to derive I Di from these eavesdropped messages. As a result, our scheme provides user’s anonymity property.

Page 11 of 19, 27

Session key security After mutual authentication between the user Ui and the server Sj during the login and authentication and session key agreement phases, the user Ui computes the secret session key shared with the server Sj as SKUi ,Sj = hc (I Di || M1 ||RNu ||Tu ||M10 || Ts ). Note that SKUi ,Sj = hc (I Di || hc (I Di ⊕ Xs )||RNu ||Tu ||RNs ||Ts ). On the other hand, the server Sj also computes the same secret session key shared with the user Ui as SKSj ,Ui = hc (I Di ||M4 ||M5 ||Tu ||RNs ||Ts ). Note that SKSj ,Ui = hc (I Di ||hc (I Di ⊕ Xs )||RNu || Tu ||RNs ||Ts ) = SKUi ,Sj . To derive the secret key, an attacker needs to know I Di , Xs , RNu and RNs at the same time. The probability of deriving the secret key is then the probability of guessing correct I Di composed of exact n characters, Xs composed of exact m bits (in our scheme, m = 1024), RNu and RNv each of exact l bits (in our 1 1 scheme, l = 128) is approximately 26n+m+2l = 26n+1280 , which is very negligible. As a result, there is no feasible way to derive the secret session key by the attacker due to one-way collision-resistant property of chaotic hash function hc (·), and hence, our scheme provides the session key secrecy. Formal security analysis In this section, using the random oracle model we show that our scheme is provably secure against an adversary for deriving the secret key Xs of the server Sj , and the password P Wi and the biometrics template Bi of a legal user Ui . We first define formally the one-way chaotic hash function hc (·) and biohashing function H (·) as follows. Definition 1 (Secure collision-resistant chaotic hash CH ASH (t ) function) If AdvA denotes an adversary 1 (attacker) A’s advantage in finding collision for a chaotic one-way hash function hc (·), we have CH ASH AdvA (t1 ) = P r[(x, x ) ⇐R A : x = x

and hc (x) = hc (x )],

where P r[E] denotes the probability of a random event E, and (x, x ) ⇐R A denotes 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 execuCH ASH tion time t1 . Then hc (·) is secure, if AdvA (t1 ) ≤ 1 , for any sufficiently small 1 > 0. Definition 2 (Secure biohashing function) Let the advantage of an adversary (attacker) A for a biohashing function BioH ash H (·) be AdvA (t2 ), where the adversary A be allowed to be probabilistic and the probability in the advantage be computed over the random choices made by the adversary

27, Page 12 of 19

J Med Syst (2014) 38:27

A with the execution time t2 . We call H (·) is secure, if BioH ash (t ) ≤  , for any sufficiently small  > 0. AdvA 2 2 2

We now define the following two random oracles for our formal security analysis: Reveal1 : This random oracle will unconditionally output the input x from the corresponding chaotic hash value y = hc (x). Reveal2 : This random oracle will unconditionally output the input x from the corresponding biohashing value y = H (x).

–

–

Theorem 1 Under the assumption that one-way collisionresistant chaotic hash function hc (·) closely behaves like a random oracle, our scheme is provably secure against an adversary for deriving the secret key Xs of the server Sj . Proof We follow the proof of this theorem as in [8–12, 28]. We need to construct an adversary A who will have the ability to derive the secret key Xs of the server Sj by intercepting the messages during the login phase and the authentication and session key agreement phase. For this purpose, A runs the experiment for our enhanced and secure biometric authentication scheme, say ESBAS, which is given in Algorithm 1.

ASH Algorithm 1 EXP 1CH A,ESBAS

1: Eavesdrop

2:

3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14:

N I Di ,

the login request message M2 , M3 , Tu  during the login phase, which is sent from a user Ui to the server Sj . Note that M2 = M1 ⊕ RNu ⊕ Tu = hc (I Di ⊕ Xs ) ⊕ RNu ⊕ Tu , M3 = hc (M1 ||RNu ||Tu ||I Di ), N I Di = hc (I Di ) ⊕ T Di . Call Reveal1 oracle on input M3 in order to retrieve the information M1 , RNu , Tu and I Di as (M1 ||RNu ||Tu ||I D ) ← Reveal1(M3 ). if Tu = Tu then Compute M1 = M2 ⊕ RNu ⊕ Tu . if M1 = M1 then Call Reveal1 oracle on input M1 to retrieve w = I Di ⊕ Xs as w ← Reveal1(M1 ). Compute Xs = w ⊕ I Di , using the retrieved I Di in Step 2. return 1 (Success) else return 0 (Failure) end if else return 0 (Failure) end if

ASH We define the success probability for EXP 1CH A,ESBAS as ASH Succ1A = |P r[EXP 1CH A,ESBAS = 1] − 1|. The advanASH tage of EXP 1CH A,ESBAS is then given by Adv1A (et1 , qR1 ) = maxA {Succ1A }, where the maximum is taken over all A with the execution time et1 and the number of queries qR1 made to Reveal1 oracle. Our scheme is said to be provably secure against the adversary A for deriving the secret key Xs of the server Sj , if Adv1A (et1 , qR1 ) ≤ , ASH for any sufficiently small  > 0. Consider EXP 1CH A,ESBAS given in Algorithm 1. According to the experiment, if the adversary A has the ability to invert one-way chaotic hash function hc (·), he/she can derive the secret key Xs of the server Sj , and win the game. However, it is a computationally infeasible task for the adversary A from Definition 1 CH ASH that AdvA (t1 ) ≤ 1 , for any sufficiently small 1 > 0. Thus, we have Adv1A (et1 , qR1 ) ≤ , for any sufficiently CH ASH (t ). As small  > 0, since it is dependent on AdvA 1 a result, the adversary A has no feasible way to derive the secret key Xs of the server Sj .

Theorem 2 Our scheme is provably secure against an adversary for deriving the password P Wi and the biometrics template Bi of a legal user Ui , even if all the secret information stored in the mobile device Ci of the user Ui are revealed to that adversary, under the assumption that the chaotic hash function hc (·) and the biohashing function H (·) closely behave like random oracles. Proof Assume that a legal user Ui has lost his/her mobile Ci or Ci is stolen. We assume that all the secret information stored in the mobile devices are known to the adversary A from the memory of the stolen/lost device Ci . In this proof, we need to construct an adversary A who will have the ability to derive the password P Wi and the biometrics template Bi of the user Ui . For this purpose, A runs the experiment: ASH,BioH ash EXP 2CH for our enhanced and secure biometA,ESBAS ric authentication scheme, ESBAS, which is provided in Algorithm 2. ASH,BioH ash The success probability for EXP 2CH is A,ESBAS ASH,BioH ash defined by Succ2A = |2EXP 2CH = 1] − 1|. A,ESBAS

ASH,BioH ash The advantage of EXP 2CH becomes Adv2A A,ESBAS (et2 , qR1 , qR2 ) = maxA {Succ2A }, where the maximum is taken over all A with the execution time et2 and the number of queries qR1 and qR2 made to Reveal1 and Reveal2 oracles, respectively. Our scheme is said to be provably secure against the adversary A for deriving the password P Wi and the biometrics template Bi of a legal user Ui , if Adv2A (et2 , qR1 , qR2 ) ≤ , for any sufficiently small  > 0. ASH,BioH ash Now, consider EXP 2CH given in Algorithm A,ESBAS 2. According to the experiment, if the adversary A has the ability to invert chaotic hash function hc (·) and biohashing

J Med Syst (2014) 38:27 ASH,BioH ash Algorithm 2 EXP 2CH A,ESBAS

1: Extract

2: 3: 4: 5: 6: 7: 8:

9: 10: 11: 12: 13:

all the secret stored information {T Di , Di , Xi , Vi , K, fi } from the memory of the mobile device Ci using the power analysis attacks [20, 27]. Call Reveal1 oracle on input Xi to retrieve Ai as A i ← Reveal1(Xi ). Compute v = Vi ⊕A i , which needs to be hc (hc (P Wi )⊕ H (Bi ) ⊕ I Di ). Call Reveal1 oracle on input v to retrieve w = hc (P Wi ) ⊕ H (Bi ) ⊕ I Di as w ← Reveal1(v). call Reveal2 oracle on input fi in order to retrieve I Di , K and Bi as (I Di ||K ||Bi ) ← Reveal2(fi ). if K = K then Compute z = w ⊕ H (Bi ) ⊕ I Di , which needs to be hc (P Wi ). Call Reveal1 oracle on input z to derive the password P Wi of the user Ui as P Wi ← Reveal1(z). Accept P Wi as the correct password P Wi and Bi as the correct biometrics template of the user Ui . return 1 (Success) else return 0 (Failure) end if

function H (·), he/she can derive P Wi and Bi successfully, and win the game. However, it is a computationally infeasible task for the adversary A from Definitions 1 and CH ASH 2 that AdvA (t1 ) ≤ 1 , for any sufficiently small BioH ash 1 > 0 and AdvA (t2 ) ≤ 2 , for any sufficiently small 2 > 0. Hence, Adv2A (et2 , qR1 , qR2 ) ≤ , for any sufficiently small  > 0, since it is dependent on both CH ASH (t ) and Adv BioH ash (t ). Thus, the adversary A AdvA 1 2 A has no feasible way to derive the password P Wi and the biometrics template Bi of the user Ui .

Simulation for formal security verification of our scheme using AVISPA tool In this section, we simulate our scheme for the formal security verification using the widely-accepted AVISPA (Automated Validation of Internet Security Protocols and Applications) tool and show that our scheme is secure against passive and active attacks, including the replay and man-in-the-middle attacks. AVISPA is a push-button tool for the automated validation of Internet security-sensitive protocols and applications. It integrates different back-ends that implement a variety of state-of-the-art automatic analysis techniques [1].

Page 13 of 19, 27

There are four back-ends for AVISPA tool analysis: On-thefly 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), which are given in details in [1]. To analyze the protocols under the AVISPA tool, the protocols need to be specified in HLPSL (High Level Protocols Specification Language), which is based on roles: basic roles for representing each participant role, and composition of roles for representing scenarios of basic roles. Each role is also independent from the other, getting some initial information by parameters, communicating with the other roles by channels. The specification in HLPSL is first translated into a lower level specification by a translator, called the hlpsl2if. After that it generates an intermediate format, which is called the Intermediate Format (If). The output format (OF) of AVISPA is generated using one of the back-ends has the following format: –

–

–

–

The first printed section is called SUMMARY, which indicates whether the protocol is safe, unsafe, or whether the analysis is inconclusive. The second section, which is called DETAILS, explains under what condition the protocol is declared safe, or what conditions have been used for finding an attack, or finally why the analysis was inconclusive. The remaining sections, called PROTOCOL, GOAL and BACKEND are the name of the protocol, the goal of the analysis and the name of the back-end used, respectively. Finally, after some possible comments and the statistics, the trace of the attack (if any) is also printed in a standard Alice-Bob format.

Specifying our scheme In this section, we provide the implementation details in HLPSL language of our scheme for the registration phase, the login phase, and the authentication and session key agreement phase. There are two basic roles: alice and bob which represent the participants as the user Ui , which acts as the initiator and the server Sj , which acts as the responder, respectively. As explained in [9], the basic types available in HLPSL are the followings [1]: –

–

agent: Values of type agent represent principal names. The intruder is always assumed to have the special identifier i. public key: These values represent agents’ public keys in a public-key cryptosystem. For example, given a public (respectively private) key pk, its

27, Page 14 of 19 role alice (Ui, Sj : agent, SKuisj : symmetric_key, %Hc is the chaotic hash function % H is the BioHashing function Hc: hash_func, H : hash_func, Snd, Rcv: channel(dy)) % Player by the initiator: the user Ui played_by Ui def= local State : nat, RPWi, PWi, RBi, Bi, Xs, K, N, IDi, NIDi, TDi, Di, Fi, Tu, Ts, RNu, RNs: text, M1, M2, M3, M4, M5, M6, M7, M8, M9: message const alice_bob_tu, bob_alice_ts, alice_bob_rnu, bob_alice_rns, subs1, subs2, subs3 : protocol_id init State := 0 transition % Registration phase 1. State = 0 /\ Rcv(start) =|> State’ := 1 /\ N’ := new() /\ RPWi’ := xor(Hc(PWi), N’) /\ RBi’ := xor(H(Bi), N’) % Send the registration request message to Sj /\ Snd({IDi.RPWi’.RBi’}_SKuisj) /\ secret({Xs}, subs1, Sj) /\ secret({PWi, Bi, K}, subs2, Ui) /\ secret({IDi}, subs3, {Ui,Sj}) % Receive the registration acknowledgment message from Sj 2. State = 1 /\ Rcv({xor(NIDi’,Hc(IDi)). xor(NIDi’,Hc(IDi)). Hc(Hc(xor(IDi,Xs))).xor(Hc(xor(IDi,Xs)), Hc(xor(xor(Hc(PWi),H(Bi)),IDi))). Hc.H}_SKuisj) =|> % Login phase State’ := 2 /\ Tu’ := new() /\ RNu’ := new() /\ TDi’ := xor(NIDi’,Hc(IDi)) /\ M1’ := Hc(xor(IDi,Xs)) /\ M2’ := xor(xor(M1’,RNu’),Tu’) /\ M3’ := Hc(M1’.RNu’.Tu’.IDi) % Send the login request message to Sj /\ Snd(xor(Hc(IDi),TDi’).M2’.M3’) % Ui has freshly generated the timestamp Tu for Sj /\ witness(Ui, Sj, alice_bob_tu, Tu’) % Ui has freshly generated the value RNu for Sj /\ witness(Ui, Sj, alice_bob_rnu, RNu’) %Authentication and session key agreement phase % Receive the authentication request message from Sj 3. State = 2 /\ Rcv(xor(xor(Hc(xor(IDi, Xs)), RNs’),Ts’). Hc(Hc(xor(IDi, Xs)).RNs’.Ts’.RNu’.Tu’.IDi.NIDi’). xor(NIDi’,Hc(Hc(xor(IDi, Xs)).RNs’.Ts’.IDi)). Ts’) =|> % Ui’s acceptance of the value Ts generated for Ui by Sj State’ := 3 /\ request(Sj, Ui, bob_alice_ts, Ts’) % Ui’s acceptance of the value RNs generated for Ui by Sj /\ request(Sj, Ui, bob_alice_rns, RNs’) end role

Fig. 1 Role specification in HLPSL for the user Ui of our scheme

– –

inverse private (respectively public) key is obtained by inv pk. symmetric key: Variables of this type represent keys for a symmetric-key cryptosystem. text: In HLPSL, text values are often used as nonces. These values can be used for messages. If N a is of type text (fresh), then N a will be a fresh value which the intruder cannot guess.

J Med Syst (2014) 38:27

– – –

nat: The nat type represents the natural numbers in nonmessage contexts. const: This type represents constants. hash func: The base type hash func represents cryptographic hash functions. The base type function also represents functions on the space of messages. It is role bob ( Ui, Sj : agent, SKuisj : symmetric_key, %Hc is the chaotic hash function % H is the BioHashing function Hc: hash_func, H : hash_func, Snd, Rcv: channel(dy)) % Player by the responder: the server Sj played_by Sj def= local State : nat, RPWi, PWi, RBi, Bi, Xs, K, N, IDi, NIDi, TDi, Di, Fi, Tu, Ts, RNu, RNs: text, M1, M2, M3, M4, M5, M6, M7, M8, M9: message const alice_bob_tu, bob_alice_ts, alice_bob_rnu, bob_alice_rns, subs1, subs2, subs3 : protocol_id init State := 0 transition % Registration phase % Receive the registration request message from Ui 1. State = 0 /\ Rcv(({IDi.xor(Hc(PWi), N’). xor(H(Bi), N’)}_SKuisj)) =|> State’ := 1 /\ secret({Xs}, subs1, Sj) /\ secret({PWi, Bi, K}, subs2, Ui) /\ secret({IDi}, subs3, {Ui,Sj}) /\ NIDi’ := new() % Send the registration acknowledgment message to Ui /\ Snd({xor(NIDi’,Hc(IDi)). xor(NIDi’,Hc(IDi)). Hc(Hc(xor(IDi,Xs))).xor(Hc(xor(IDi,Xs)), Hc(xor(xor(Hc(PWi),H(Bi)),IDi))). Hc.H}_SKuisj) % Login phase % Receive the login request message from Ui 2. State = 1 /\ Rcv(xor(Hc(IDi),xor(NIDi’,Hc(IDi))). xor(xor(Hc(xor(IDi,Xs)),RNu’),Tu’). Hc(Hc(xor(IDi,Xs)).RNu’.Tu’.IDi)) =|> % Authentication and session key agreement phase State’ := 2 /\ M1’ := Hc(xor(IDi,Xs)) /\ M2’ := xor(xor(M1’,RNu’),Tu’) /\ M4’ := Hc(xor(IDi, Xs)) /\ M5’ := xor(xor(M2’,Tu’), M4’) /\ Ts’ := new() /\ RNs’:= new() /\ M7’ := xor(xor(M4’, RNs’),Ts’) /\ M8’ := Hc(M4’.RNs’.Ts’.M5’.Tu’.IDi.NIDi’) /\ M9’ := xor(NIDi’,Hc(M4’.RNs’.Ts’.IDi)) % Send the authentication request message to Ui /\ Snd (M7’.M8’.M9’.Ts’) % Sj has freshly generated the timestamp Ts for Ui /\ witness(Sj, Ui, bob_alice_ts, Ts’) % Sj has freshly generated the value RNs for Ui /\ witness(Sj, Ui, bob_alice_rns, RNs’) % Sj’s acceptance of the value Tu generated for Sj by Ui /\ request(Ui, Sj, alice_bob_tu, Tu’) % Sj’s acceptance of the value RNu generated for Sj by Ui /\ request(Ui, Sj, alice_bob_rnu, RNu’) end role

Fig. 2 Role specification in HLPSL for the server Sj of our scheme

J Med Syst (2014) 38:27

role session(Ui, Sj: agent, SKuisj : symmetric_key, Hc : hash_func, H : hash_func) def= local SI, SJ, RI, RJ: channel (dy) composition alice(Ui, Sj, SKuisj, Hc, H, SI, RI) /\ bob(Ui, Sj, SKuisj, Hc, H, SJ, RJ) end role Fig. 3 Role specification in HLPSL for the session of our scheme

–

assumed that the intruder cannot invert hash functions (in essence, that they are one-way). bool: Boolean values are useful for modeling, for instance, binary flags.

The space of legal messages are defined as the closure of the basic types. For a given message Msg and encryption key Key, we denote {Msg} Key as the symmetric/publickey encryption. The associative “·” operator is used for concatenations. The specification in HLPSL language for the role of the user Ui is given in Fig. 1. The user Ui first receives the start

role environment() def= const ui, sj: agent, skuisj : symmetric_key, hc : hash_func, h : hash_func, pwi, bi, xs, k, idi, nidi, tu, ts, rnu, rns: text, alice_bob_tu, bob_alice_ts, alice_bob_rnu, bob_alice_rns, subs1, subs2, subs3 : protocol_id intruder_knowledge = {ui, sj, hc, h, tu, ts} composition session(ui, sj, skuisj, hc, h) /\ session(ui, sj, skuisj, hc, h) end role goal secrecy_of subs1 secrecy_of subs2 secrecy_of subs3 authentication_on alice_bob_tu authentication_on alice_bob_rnu authentication_on bob_alice_ts authentication_on bob_alice_rns end goal environment() Fig. 4 Role specification in HLPSL for the goal and environment of our scheme

Page 15 of 19, 27

% OFMC % Version of 2006/02/13 SUMMARY SAFE DETAILS BOUNDED_NUMBER_OF_SESSIONS PROTOCOL /home/avispa/web−interface−computation/ ./tempdir/workfileN7OL7d.if GOAL as_specified BACKEND OFMC COMMENTS STATISTICS parseTime: 0.00s searchTime: 0.72s visitedNodes: 82 nodes depth: 4 plies Fig. 5 The result of the analysis using OFMC of our scheme

signal and changes its state from 0 to 1 and sends the registration request message I Di , RP Wi , RBi  securely to the server Sj in the registration phase with the Snd( ) operation. In reply, the user Ui gets a mobile device with the information (T Di , Di , Xi , Vi , hc (·), H (·)) securely from Sj by the Rcv( ) operation. Here, the type declaration channel (dy) in HLPSL specification declares that the channel is for the Dolev-Yao threat model (as described in our threat model) [14]. The “played by A” declaration means that the agent named in variable A will play in the role. A knowledge declaration (generally in the top-level Environment role) is used in order to specify the intruder’s initial knowledge. The form X = | > Y represents the immediate reaction transition, which relates an event X with an action Y . If a variable V needs to made permanently secret, it is then expressed by the goal secrecy of V. If V is ever obtained or derived by the intruder, a security violation will result. witness(A,B,id,E) declares for a (weak) authentication property of A by B on E, declares that agent A is witness for the information E; this goal will be identified by the constant id in the goal section [2]. request(B,A,id,E) means 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 [1]. During the login phase, the user Ui sends the login request message N I Di , M2 , M3 , Tu  to the server Sj via a public channel. In reply, the user waits for the authentication request message M7 , M8 , M9 , Ts  from Sj via a public channel. We have implemented the role for the server Sj in our scheme in Fig. 2. In this figure, during the registration phase, after receiving the registration request message I Di , RP Wi , RBi  securely from the user Ui , Sj issues a mobile

27, Page 16 of 19 Table 4 Comparison of communication overhead between Awasthi-Srivastava’s scheme and our scheme during the login and authentication phases

J Med Syst (2014) 38:27

Scheme

Total number of messages required

Total number of bits required

Awasthi-Srivastava [3] Ours

2 2

448 832

device with the information (T Di , Di , Xi , Vi , hc (·), H (·)) securely to Ui . After receiving the login request message N I Di , M2 , M3 , Tu  from the user Ui , the server Sj sends the authentication request message M7 , M8 , M9 , Ts  to Ui via a public channel. In Figs. 3 and 4, we have implemented the specified for the roles of the session, and the goal and environment of our scheme. In the session role, all the basic roles, alice and bob, are instanced with concrete arguments. The top-level role (environment) is always defined in the specification of HLPSL language. It contains the global constants and a composition of one or more sessions, where the intruder may play some roles as legitimate users. The intruder also participates in the execution of protocol as a concrete session in AVISPA analysis. The following three secrecy goals and two authentications are verified in our scheme: – – – –

–

secrecy of subs1: It represents that Xs is kept secret to the server Sj only. secrecy of subs2: It indicates that P Wi , Bi , and K are kept secret to the user Ui only. secrecy of subs3: It tells that I Di is kept secret to Ui and Sj only. authentication on alice bob ru: Ui (Ci ) generates a random nonce Ru , where Ru is only known to Ui . When the server Sj receives Ru from the messages from Ui , Sj authenticates Ui . authentication on alice bob tu: Tu is the current system timestamp of Ui (Ci ). When the server Sj receives Tu from the messages from Ui , Sj authenticates Ui .

Table 5 Comparison of computational overhead between Awasthi-Srivastava’s scheme [3] and our scheme during all phases

tH : time for biohashing operation, thc : time for one-way chaotic hashing operation, tbv : time for biometrics verification in Awasthi-Srivastava’s scheme [3], tpke /tpkd : time for publickey encryption/decryption, tske /tskd : time for symmetric-key encryption/decryption

–

–

authentication on bob alice rs: Sj generates a random nonce Rs , where Rs is only known to Sj . If the user Ui gets Rs from the messages from Sj , Ui authenticates Sj . authentication on bob alice rs: Ts is the current system timestamp of Sj . If the user Ui gets Ts from the messages from Sj , Ui authenticates Sj .

Analysis of results We have finally simulated our scheme using the AVISPA web tool [2] for the widely-accepted OFMC model checker [4]. The simulation result for the formal security verification analysis of our scheme using OFMC is shown in Fig. 5. The results clearly ensure that our scheme is secure against the active attacks, such as the replay and man-in-the-middle attacks, and passive attacks. The summary of the results under OFMC also reports our scheme is safe.

Performance comparison with related schemes In this section, we only compare the performance of our scheme with Awasthi-Srivastava’s scheme, since our scheme is an enhancement over Awasthi-Srivastava’s scheme. In Table 4, we have compared the communication overhead in terms of total number of messages and total number of bits required for all transmitted messages during the login and authentication phase between AwasthiSrivastava’s scheme and our scheme. In our scheme and

Phase

Entity

[3]

Ours

Registration

Ui /Ci Sj

tpke tpkd + 3thc

2tH + thc + tske 3thc + tskd

Login

Ui /Ci Sj

tbv + 3thc −

2tH + 5thc −

Authentication

Ui /Ci Sj

thc 3thc

3thc 4thc

Password change

Ui /Ci Sj

tbv + 2thc −

2tH + 4thc −

J Med Syst (2014) 38:27

Page 17 of 19, 27

Table 6 Functionality comparison between Awasthi-Srivastava’s scheme and our scheme Functionality

Awasthi-Srivastava [3]

Ours

F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 F16 F17

Yes Yes Yes Yes Yes Yes Yes No No No No No No Yes Yes No Yes

No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

F1 : whether flaws exist in password change phase; F2 : whether protects privileged insider attacks or not; F3 : whether protects man-inthe-middle attacks or not; F4 : whether provides proper authentication or not; F5 : whether protects stolen mobile device (smart card) attacks or not; F6 : whether protects impersonation attacks or not; F7 : whether resilient against offline attacks or not; F8 : whether protects DoS attacks or not; F9 : whether resists strong replay attacks or not; F10 : whether establishes a secret session key between Ui and Sj after successful authentication or not; F11 : whether provides formal security proof or not; F12 : whether provides formal security verification using AVISPA tool or not; F13 : whether supports user anonymity property or not; F14 : whether resilient against parallel session and reflection attacks or not; F15 : whether protects server spoofing attacks or not; F16 : whether provides session key security or not; F17 : whether provides uniqueness property or not

Awasthi- Srivastava’s scheme, we assume the output of the chaotic hash function hc (·) is 128 bits for providing sufficient security, identity is 128 bits, random nonce is 128 bits and timestamp is 32 bits long. In Awasthi-Srivastava’s scheme, the login message I Di , D1 , Tu  requires (128 + 128 + 32) = 288 bits and the authentication message D2 , Ts  requires (128 + 32) = 160 bits, and thus a total of 448 bits. In our scheme, the login request message N I Di , M2 , M3 , Tu  requires (128+128+128+32) = 416 bits, and the authentication request message M7 , M8 , M9 , Ts  requires (128 + 128 + 128 + 32) = 416 bits. Adding all these, the communication overhead becomes (416 + 416) = 832 bits. It is noted that our scheme requires more communication overhead than Awasthi-Srivastava’s scheme. This is acceptable, because our scheme is more secure and supports extra features when compared to those with Awasthi-Srivastava’s scheme.

In Table 5, we have compared the computational overhead between Awasthi-Srivastava’s scheme and our scheme during the registration phase, the login phase, the authentication phase, and the password change phase. The biohashing operation H (·) is efficient and also the one-way hash operation hc (·) is efficient. We have ignored the bitwise XOR operations in the analysis of our scheme and Awasthi-Srivastava’s scheme, since bitwise XOR is negligible. Due to the efficiency of the hash function, the computational overhead of our scheme is comparable with that for Awasthi-Srivastava’s scheme. In Table 6, we have finally provided the functionality supported by our scheme and Awasthi-Srivastava’s scheme. It is clear to note from Table 6 that our scheme is superior when compared with Awasthi-Srivastava’s scheme. In our scheme the transmitted identity N I Di is updated by random nonces RNu and RNs after each session such that the transmitted identities are distinct from each other for each session. Our scheme thus protects DoS attacks, whereas Awasthi-Srivastava’s scheme fails to protect DoS attacks. Our scheme also ensures the user anonymity property, whereas Awasthi-Srivastava’s scheme does not support this property. Thus, no one can trace a specific user with the transmitted random and temporary identity N I Di in our scheme. Since the pair (I Di , N I Di ) is maintained in the database of the server, the server can correctly store, update or manipulate patients’ (users’) medical records corresponding to the actual identity I Di of the user Ui . In our scheme and Awasthi-Srivastava’s scheme for biometric verification the user needs to input his/her correct identity I Di and personal biometrics Bi . Since biometrics characteristics are unique, easy to be verified, and hard to copy [22], no one except the user (patient) can be authenticated by the mobile device. If the biometric verification fails, the mobile device does not proceed further in the login phase and the authentication phase. Hence, as in Awasthi-Srivastava’s scheme, our scheme also ensures user uniqueness property. Finally, our scheme is secure against possible attacks, whereas Awasthi-Srivastava’s scheme has security weaknesses and does not support other important features as in our scheme. Considering the security and other extra important features provided by our scheme, we conclude that our scheme outperforms than AwasthiSrivastava’s scheme.

Conclusion We have proposed a secure and enhanced biometric-based remote user authentication scheme for the telecare medicine information systems, which achieves uniqueness and

27, Page 18 of 19

J Med Syst (2014) 38:27

user anonymity properties. In our scheme, we have used the efficient chaotic one-way hash function and biohashing function. Our scheme withstands the security weaknesses found in Awasthi-Srivastava’s scheme. Compared with Awasthi-Srivastava’s scheme, our scheme is efficient in terms of communication and computational overheads, and also supports extra important features which are necessary for an idle user authentication protocol. Through the formal and informal security analysis, we have shown that our scheme is secure against possible known attacks including stolen mobile device attack, impersonation attack, replay attack, man-in-the-middle attack, offline password guessing attack, online password guessing attack, privileged insider attack, parallel session and reflection attack, server spoofing attack, DoS attack and session key security. In addition, through the simulation results using the AVISPA model checkers for the formal security verification, we have shown that our scheme is secure against passive and active attacks, including the replay and man-in-the-middle attacks. Furthermore, a legal user can always change his/her password correctly and locally at any time without contacting the medical server as compared to Awasthi-Srivastava’s scheme. In our scheme, after successful mutual authentication a symmetric secret session key is established between the user and the server so that they can use that key for their future secure communications, whereas AwasthiSrivastava’s scheme fails to provide this feature. Overall, considering the security, efficiency and features provided by our scheme, our scheme is more suitable for practical application for the telecare medicine information systems. Acknowledgments The authors would like to acknowledge the many helpful suggestions of the anonymous reviewers, which have improved the content and the presentation of this paper. Conflict of interests of interest.

The authors declare that they have no conflict

References 1. AVISPA: Automated validation of internet security protocols and applications. http://www.avispa-project.org/. Accessed Jan 2013. 2. AVISPA: AVISPA Web Tool. http://www.avispa-project.org/ web-interface/expert.php/. Accessed Sept 2013. 3. Awasthi, A. K., and Srivastava, K., A biometric authentication scheme for telecare medicine information systems with nonce. J. Med. Syst. 37(5):1–4, 2013. 4. Basin, D., Modersheim, S., and Vigano, L., OFMC: A symbolic model checker for security protocols. Int. J. Inf. Sec. 4(3):181– 208, 2005. 5. Chang, Y.-F., Yu, S.-H., and Shiao, D.-R., An uniqueness-andanonymity-preserving remote user authentication scheme for connected health care. J. Med. Syst. 37:9902, 2013.

6. Chang, Y.-F., Yu, S.-H., and Shiao, D.-R., An uniqueness-andanonymity-preserving remote user authentication scheme for connected health care. J. Med. Syst. 37:1–9, 2013. 7. Das, A. K., Analysis and improvement on an efficient biometricbased remote user authentication scheme using smart cards. IET Inf. Sec. 5(3):145–151, 2011. 8. Das, A. K., A secure and effective user authentication and privacy preserving protocol with smart cards for wireless communications. Netw. Sci. 2(1–2):12–27, 2013. 9. Das, A. K., and Goswami, A., A secure and efficient uniquenessand-anonymity-preserving remote user authentication scheme for connected health care. J. Med. Syst. 37(3):1–16, 2013. 10. Das, A. K., Massand, A., and Patil, S., A novel proxy signature scheme based on user hierarchical access control policy. J. King Saud University - Comput. Inf. Sci. 25(2):219–228, 2013. 11. Das, A. K., Paul, N. R., and Tripathy, L., Cryptanalysis and improvement of an access control in user hierarchy based on elliptic curve cryptosystem. Inf. Sci. 209:80–92, 2012. 12. Das, A. K., and Bruhadeshwar, B., An improved and effective secure password-based authentication and key agreement scheme using smart cards for the telecare medicine information system. J. Med. Syst. 37(5):1–17, 2013. 13. Das, M. L., Saxena, A., and Gulati, V. P., A dynamic ID-based remote user authentication scheme. IEEE Trans. Consum. Electron. 50(2):629–631, 2004. 14. Dolev, D., and Yao, A., On the security of public key protocols. IEEE Trans. Inf. Theory. 29(2):198–208, 1983. 15. Hwang, M. -S., and Li, L. -H., A new remote user authentication scheme using smart cards. IEEE Trans. Consum. Electron. 46(1): 28–30, 2000. 16. Hwang, T., Chen, Y., and Laih, C. -S., Non-interactive password authentications without password tables. In: Proceedings of IEEE Region 10 Conference on Computer and Communication Systems (TENCON’90). Vol. 1, pp. 429–431, 1990. 17. Jaspher, G., Kathrine, W., Kirubakaran, E., and Prakash, P., Smart card based remote user authentication schemes: A survey. Procedia Eng. 38:1318–1326, 2012. 18. Jina, A. T. B., Linga, D. N. C., and Goh, A., Biohashing: Two factor authentication featuring fingerprint data and tokenised random number. Pattern Recog. 37(11):2245–2255, 2004. 19. Khan, M. K., Kim, S. -K., and Alghathbar, K., Cryptanalysis and security enhancement of a ‘more efficient & secure dynamic ID-based remote user authentication scheme’. Comput Commun. 34(3):305–309, 2011. 20. Kocher, P., Jaffe, J., and Jun, B., Differential power analysis. In: Proceedings of Advances in Cryptology - CRYPTO’99, LNCS. Vol. 1666, pp. 388–397, 1999. 21. Lamport, L., Password authentification with insecure communication. Commun. ACM. 24(11):770–772, 1981. 22. Li, C. -T., and Hwang, M. -S., An efficient biometric-based remote user authentication scheme using smart cards. J. Netw. Comput. Appl. 33:1–5, 2010. 23. Li, C. -T., Lee, C. -C., Liu, C. -J., and Lee, C. -W., A robust remote user authentication scheme against smart card security breach. In: Proceedings of Data and Applications Security and Privacy XXV, LNCS. VOl. 6818, pp. 231–238, 2011. 24. Li, X., Niu, J. -W., Ma, J., Wang, W. -D., and Liu, C. -L., Cryptanalysis and improvement of a biometrics-based remote user authentication scheme using smart cards. J. Netw. Comput. Appl. 34:73–79, 2011. 25. Lumini, A., and Nanni, L., An improved BioHashing for human authentication. Pattern Recog. 40(3):1057–1065, 2007. 26. Madhusudhan, R., and Mittal, R. C., Dynamic ID-based remote user password authentication schemes using smart cards: A review. J. Netw. Comput. Appl. 35(4):1235–1248, 2012.

J Med Syst (2014) 38:27 27. Messerges, T. S., Dabbish, E. A., and Sloan, R. H., Examining smart-card security under the threat of power analysis attacks. IEEE Trans. Comput. 51(5):541–552, 2002. 28. Odelu, V., Das, A. K., and Goswami, A., An effective and secure key-management scheme for hierarchical access control in e-medicine system. J. Med. Syst. 37(2):1–18, 2013.

Page 19 of 19, 27 29. Wang, Y. -Y., Liu, J. -Y., Xiao, F. -X., and Dan, J., A more efficient and secure dynamic ID-based remote user authentication scheme. Comput. Commun. 32(4):583–585, 2009. 30. Xiao, D., Liao, X., and Deng, S., One-way hash function construction based on the chaotic map with changeable-parameter. Chaos, Solitons Fractals. 241:65–71, 2005.