An Improved Biometric-Based User Authentication Scheme for C/S System

The authors first review the recently proposed Das's biometric-based remote user authentication scheme, and then show that Das's scheme is still insecure against some attacks and has some problems in password change phase. In order to overcome the design flaws in Das's scheme, an improvement of the scheme is further proposed. Cryptanalysis shows that our scheme is more efficient and secure against most of attacks; moreover, our scheme can provide strong mutual authentication by using verifying biometric, password as well as random nonces generated by the user and server.


Introduction
In a client/server system, the validity of remote user is necessary to assure the security of the system. Traditional remote identity-based authentication schemes [1][2][3][4][5][6][7][8][9] are based on passwords only. However, simple passwords are always easy to break by using simple dictionary attacks since they have low entropy. To overcome this problem, cryptographic secret keys and passwords are used in the remote user authentication schemes. But the long and random cryptographic keys are difficult to memorize and hence they must be stored somewhere [10]; it is expensive to maintain the long cryptographic keys. Furthermore, both passwords and cryptographic keys are unable to provide nonrepudiation because they can be forgotten or lost or when they are shared with other people, there is no-way to know who the actual user is [11]. A biometric system operates by acquiring biometric data from an individual, extracting a feature set from the acquired data and comparing this feature set against the template set in the database [12][13][14]. In [3], the authors propose an online ( , ) threshold secret sharing scheme based on biometric verification and threshold password authentication. In [15], a continuous user authentication scheme based on biometric verification by fusing hard and soft traits is proposed irrespective of user posture in front of the system. In [16], a BIO3G protocol based on biometric authentication for 3G mobile environments is proposed to provide real end to end strong user authentication. In [17], the author analyzes the security of Das's biometric-based authentication scheme and shows that the scheme is still insecure against some attacks and does not provide mutual authentication between the user and server. In [18], the author proposes an enhanced scheme based on biometric verification and smart card to remove the security weakness of Das's scheme analyzed in [17]. However, the proposed scheme in [18] cannot withstand the replay attack between the user and the remote server. In the abovementioned schemes, biometric verification allows one to confirm or establish an individual identity. Therefore, biometric keys are proposed which are based on physiological and behavioral characteristics of persons such as fingerprints, faces, irises, hand geometry, and palm prints. Some advantages of biometric keys are described as follows [19,20].
(i) Biometric keys cannot be lost or forgotten.
(ii) Biometric keys are very difficult to copy or share. (iii) Biometric keys are extremely hard to forge or distribute. (iv) Biometric keys cannot be guessed easily.
(v) Someone's biometrics is not easier to break than others.
2 International Journal of Distributed Sensor Networks As a result, biometric-based remote user authentications are inherently more reliable and secure than usual traditional password-based remote user authentication schemes.
In this paper, we propose an improvement of Das's biometric-based remote user authentication scheme using smart cards in order to withstand his design flaws. The remainder of this paper is organized as follows. In Section 2, we briefly review the Das's biometric-based remote user authentication scheme using smart cards [21]. In Section 3, we analyze the design flaws in Das's scheme. In Section 4, we propose an improvement of the scheme in order to eliminate the design flaws discussed in Section 3. Security analysis of our scheme and performance comparison with other related schemes are implemented in Section 5. Finally, we conclude the paper in Section 6.

Review of DAS's Biometric-Based Remote User Authentication Scheme
In this section, we review in brief Das's biometric-based remote user authentication scheme [21]. For describing the Das's scheme [21], we use the notations shown in Table 1.
Das's scheme consists of the following four phases, namely, registration phase, login phase, authentication phase, and change password phase. Details of each phase are given in the following subsections.

Registration Phase.
In order to login to the system, the remote user needs to perform the following stages, as shown in Algorithm 1.
Step 1. The user inputs his/her personal biometric on a specific device and offers his/her password PW and the identity ID of the user to the registration center in person. Step 2. The registration center then computes = ℎ( ), = ℎ(PW ) ⊕ , and = ℎ(ID ‖ ) ⊕ . Here is secret information generated by the server.
Step 3. Finally, the registration center loads (ID , ℎ(⋅), , , ) on the user's smart card and sends the information to the user via a secure channel.

Login Phase.
In this phase, if a user wants to login to the server , he/she needs to perform the following steps, as shown in Algorithm 2.
Step 1. first inserts his/her smart card into the smart card reader of a terminal and offers his/her personal biometric template, , on the specific device to verify his/her biometric.
Step 2. Next, the user's personal biometric template is matched against the template stored in the system.
Step 3. If the above verification does not hold, then does not pass the biometric verification and, as a result, the remote user authentication is terminated. Otherwise, on the other hand, if the abovementioned verification holds, passes the biometric verification and then inputs his/her password PW to perform Step 4.
Step 4. The smart card computes = ℎ(PW ) ⊕ . If ̸ = , then password verification fails, and the client terminates the session.

Authentication Phase.
After receiving the login request message ⟨ID , 2 , 3 ⟩, performs the following steps, as shown in Algorithm 3, in order to authenticate whether the user is legal or not.
(1) Checks whether the format of s ID is valid or not. If above holds, computes the following: If it holds, then computes Step 1. first checks the format of 's ID .
Step 6. If the abovementioned does not hold, rejects 's login request.
Step 7. In case the verification is successful, then only accepts 's login request.

Password Change.
The password change phase of Das's scheme [21] has the following steps.
Step 1. It inserts the smart card into the card reader and offers .
Step 2. It verifies whether the user's personal biometric template matches against the template stored in the system.
Step 3. If passes the biometric verification, then only enters his/her old password PW old and new changed password PW new .
Step 5. Finally, replace with and with on the smart card.

Cryptanalysis of Das's Scheme
This section demonstrates that Das's scheme [21] has some drawbacks: denial-of-service attack, user impersonation attack, replay attack, and password change problem.

Denial-of-Service Attack.
One of fundamental properties of a secure one-way hash function is that its outputs are very sensitive to small perturbations in their inputs. The cryptographic hash function cannot be applied straightforwardly when the input data are with noise such as biometrics [22]. Then the predetermined threshold for biometric verification cannot be used to measure outputs of hash functions. In the registration phase of Das's scheme, the register center computes = ℎ( ) and = ℎ(PW ) ⊕ and then stores and in the smart card. In the login phase, inserts his/her smart card into the card reader and provides his/her personal biometrics on a specific device to verify the users biometrics by verifying whether ℎ( ) = or not. In Step 4 of login phase, password verification is performed by verifying whether = . However, both the biometric verification and password verification procedures may result in serious flaws because ℎ( ) = may never succeed, since the inputted biometrics belonging to the same person may differ slightly from time to time [22], so the next login and authentication procedure will be terminated. As a result, this may cause the legal user to be unable to pass biometric verification at the login phase of Das's scheme. Therefore, Das's scheme is vulnerable to the denial-of-service attack.

User Impersonation Attack.
We see from the login and authentication phase of Das's scheme that an attacker can impersonate a legal user to access to the server. In the login phase of Das's scheme, since the user sends the message ⟨ID , 2 , 3 ⟩ to the remote server where identity is not masked, this will result in user impersonation attack as follows.
When an attack denoted as wants to access the remote server, he/she can eavesdrop the message ⟨ID , 2 , 3 ⟩ by tapping communication lines or wireless link between the legal user and the remote server . Once derives the message ⟨ID , 2 , 3 ⟩ he can send the eavesdropped message to the remote server . Since the legal user's ID is not masked, so the check of user's validity can easily pass. We can clearly see that when computes 4 = ℎ(ID ‖ ) and 5 = 2 ⊕ 4 , the verification of ℎ( 5 ) = 3 is successful. Then computes 6 = 4 ⊕ , 7 = ℎ( 2 ‖ 5 ), and 8 = ℎ( ) and then sends message ⟨ 7 , 6 , 8 ⟩ to . The attack may eavesdrops the message ⟨ 7 , 6 , 8 ⟩ and modifies the 7 , replaces it with 7 , and then sends a forged message ⟨ 7 , 6 , 8 ⟩ to . Obviously 7 ̸ = ℎ( 2 ‖ ), so terminates the session. However, the attacker will pass the verification ⟨ 7 , 6 , 8 ⟩, and computes 9 = 6 ⊕ 1 = 6 ⊕ 4 . Since the attack can verify 9 = 8 , he proceeds as follows by computing 10 = ℎ( 6 ‖ 9 ) and sends message ⟨ 10 ⟩ to the remote server . On receiving the message, the remote server will verify whether 10 = ℎ( 6 ‖ ) or not. We can see obviously that the above equation holds, so the remote accepts the attacker's login request and the user impersonation attack will occur sequentially.

Replay
Attack. In Das's scheme, the replay and man-inthe-middle attack is withstood by checking whether 5 (= 2 ⊕ 4 ) = 5 , where 5 is equal to and is stored in the database of remote server . It is noted that 5 is disclosed to any user when one breaks the remote server . When the remote server is compromised by an attacker, he/she can change ⟨ID , 5 ⟩ in the database of the remote server . Obviously, once 5 is changed, the replayed message ⟨ID , 2 , 3 ⟩ will not be discarded and 5 will be replaced by 5 .

Password Change.
In password change procedure of Das's scheme, if remote user wants to change his/her password, he/she must pass biometric verification by verifying ℎ( ) = . However, the inputted biometrics belonging to the same person may differ slightly from time to time [22], so the password change procedure will be terminated. In addition, for more time, since ℎ( ) ̸ = , then = ℎ(PW old ) ⊕ computed by smart card is not equal to stored in the smart card, so the password change procedure will also be terminated. According to the above analysis, Das's scheme cannot realize the password change freely.

Proposed Scheme
In this section, we propose an improvement of the Das's biometric-based remote user authentication scheme [21] using smart cards in order to withstand the flaws discussed in Section 3. For convenience, we use the same notations used as in Das's scheme shown in Table 1.

Registration Phase.
In order to login to the system, the remote user needs to perform the following steps, as shown in Algorithm 4. Step 1. The user inputs his/her personal biometric on a specific device and offers his/her password PW and the identity ID to the registration center in person.
Step 2. The registration center then computes = ℎ( ), = ℎ(ID ), = ℎ(PW )⊕ , and = ℎ( ‖ )⊕ . Here is secret information generated by the server. We note that and passwords of the corresponding users are not disclosed to any others for all secure future communications.
Step 3. Finally, the registration center loads (ℎ(⋅), , , , , , (⋅)) on the user's smart card and sends this information to the user via a secure channel.

Login Phase.
In order to login to the system, the remote user needs to perform the following stages, as shown in Algorithm 5.
Step 1. first inserts his/her smart card into the card reader of a terminal and offers his/her personal biometric template, , on the specific device. If ( , ) > , the remote user authentication is terminated. Otherwise, passes the biometric verification and then inputs his/her password PW to perform Step 2.
Step 2. The smart card computes = ℎ(PW )⊕ . If ( , ) > , then password verification fails, and the system terminates the session; otherwise, the smart card computes 1 = ⊕ , which is equal to ℎ( ‖ ), 2 = ℎ( ‖ ), where is a random number generated by the user and is the current timestamp of 's system, and 3 = 1 ⊕ 2 .
Step 3. Finally, the user sends the message ⟨ , 2 , 3 , ⟩ to the remote server .

Authentication Phase.
When the remote server receives the login request ⟨ , 2 , 3 , ⟩ at time * , it will perform the following steps as shown in Algorithm 6 to authenticate whether the user is legal or not.
Step 1. Verify T. If ( * − ) > Δ , the authentication phase aborts, where Δ is the expected time interval for the transmission delay of the system. On the contrary, if ( * − ) ≤ Δ , the next step will be performed.
Step 2. checks the format of 's ID . It computes 4 = ℎ( ‖ ) using the secret value maintained by the server and then computes 5 = 4 ⊕ 3 and verifies whether 5 = 2 . If it does not hold, then rejects 's login request. In case the verification is successful, the next step will be performed.
Step 4. After receiving the message ⟨ 4 , 6 , 7 , ⟩ at time * * , first checks the freshness of by verifying ( * * − ) > Δ . If it holds, the following session is terminated; otherwise computes 8 = 4 ⊕ 7 and then verifies whether terminates the session. Otherwise, it goes to the next step.
Step 5. computes 9 = 4 ⊕ 6 and then verifies whether 9 = 7 . If it does not hold, is rejected by ; otherwise, if it holds, computes 10 = ℎ( ‖ ), where is the current timestamp of the user , and then computes 11 = 7 ⊕ 10 and sends the message ⟨ 11 , , ⟩ to the remote server .

Password Change. In our scheme, user
can freely change the password PW old to a new one PW new . The password change procedure is performed as follows.
Step 1. inserts the smart card into the card reader and offers his/her personal biometrics ; then the smart card computes = ℎ( ) and verifies it by checking ( , ) ≤ . where = ℎ( ) is the information stored in the smart card.
Step 2. If it holds, inserts old password PW old and new password PW new ; otherwise the password change procedure is terminated.
Step 3. Smart card performs = ℎ(PW old ) ⊕ and checks ( , ) ≤ . where is the information stored in the smart card.
Step 5. Finally, replace with and with on the smart card.
Algorithm 5: Login phase of our scheme.
Algorithm 6: Authentication phase of our scheme.

Security Analysis.
If a legal user lost his/her smart card, it is extremely hard for an adversary to derive the user's sensitive information such as user's identity, password, and biometrics because the extraction of parameters from the smart card is quite difficult. Furthermore, the adversary cannot change the password because he/she cannot pass the biometric verification.

Denial-of-Service
Attack. In our proposed protocol, we take into account hash function's sensitivity to small perturbations in its inputs. In the login phase, user's biometric verification is performed by checking ( , ) > instead of checking ℎ( ) = . Moreover, the password verification is performed by checking ( , ) > instead of = . So denial-of-service attack caused by hash function's fundamental properties can be withstood.

Stolen-Verifier Attack.
Our scheme can resist stolenverifier attack because the scheme is free from the verifier/password table. In our protocol, the remote server does not keep password tables. Therefore, an attacker cannot steal user's password from . Moreover, the password is masked by hash function in the procedure of message transfer between the user and remote server .

Many Logged-In Users Attack.
Most systems, which maintain the password table to verify user login, are vulnerable to this kind of threat. Our scheme can resist the threat since our scheme requires on-card computation for login to the remote server , and once the smart card is removed, the login process will be aborted.

Guessing Attack.
Our protocol can resist guessing attack, which is a critical concern in password-based systems, since the password in our protocol is transmitted as a digest of some other secret information. The attacker cannot guess the user's password from the digest because of the one-way characteristic of the hash function, even if the attacker may get the digest which contains the password.

Replay Attack.
Replaying an intercepted message can be prevented in our proposed protocol. If an attacker intercepts ⟨ID , 2 , 3 , ⟩ and tries to login to the remote server via replaying the same message, he/she cannot pass the verification of the login request due to ( * − ) > Δ , where * is the system time when the remote server receives the replayed message. Moreover, if an attacker intercepts ⟨ 4 , 6 , 7 , ⟩ and tries to replay the message to the user , this kind of attack also can be prevented due to ( * * − ) > Δ .

User Impersonation Attack.
In the login phase of our scheme, the message sent to remote server is ⟨ , 2 , 3 , ⟩ instead of ⟨ID , 2 , 3 , ⟩, where the user's identity ID is masked by hash function. Even though an attacker eavesdrops the message ⟨ , 2 , 3 , ⟩, he cannot derive the user's identity, ID , due to the one-way characteristic of hash function. In the authentication phase, when the remote server receives the login request message ⟨ , 2 , 3 , ⟩, it will check the validity of user's identity. Since the attacker cannot derive legal user's identity, the check of user's identity cannot pass which will result in the termination of authentication phase. Through the above analysis, we can see that user impersonation attack can be avoided in our scheme.

Server Masquerading Attack.
If an attack attempts to masquerade as the legitimate server , he/she must make the forged replay message to the user when receiving the user's login request message ⟨ , 2 , 3 , ⟩. However, the forged replay message is more difficult to fake since the time-stamped message ⟨ 4 , 6 , 7 , ⟩ is sent to the user when the remote server is receiving 's login request message ⟨ , 2 , 3 , ⟩. Moreover, the attacker cannot masquerade as the server by forging the replay message ⟨ 4 , 6 , 7 , ⟩, because cannot compute ( 4 , 7 ) sending to the user without knowing the secret value kept by the server . Hence, the attacker cannot masquerade as the legal server to the user by launching the server masquerading attack.

Insider Attack.
In the registration phase, if the user's password PW and the biometrics information are revealed to the server , the insider of the server may directly obtain PW and , and the insider impersonates as the user to access the user's other accounts in the server. But in the login phase of our scheme, if the insider wants to access 's other accounts, he/she must input his/her smart card to the card reader and provide his biometric information in order to pass the verification ( , ) < . Since the insider cannot provide the user 's smart card, the biometric verification will be aborted. So the insider attack can be prevented. 5.1.9. Mutual Authentication. As described above, our scheme can withstand the user impersonation attack and server masquerading attack; consequently our scheme can provide mutual authentication between the user and remote server .

Man-in-the-Middle Attack.
Man-in-the-middle attack means that an active attacker intercepts the communication line between a legal user and the server and uses some means to successfully masquerade as both the server to the user and the user to the server. Then, the user will believe that he is talking to the intended server and vice versa. In our scheme, when a user wants to login to the remote server , mutual authentication between the user and remote server is performed, so man-in-the-middle attack can be prevented.

Performance of the Proposed Scheme.
In this subsection, we compare the performances of our improved scheme with those for Li-Hwang's scheme [11] and Das's scheme [21]. It is worth recalling that the protocol of Li-Hwang's scheme [11] has security weaknesses against denial-of-service attack, replay attack, user impersonation attack, and manin-the-middle attack. It is noted that Das's scheme [21] has security weaknesses against denial-of-service attack, user impersonation attack, replay attack, server masquerading attack, and insider attack. The security comparisons between our scheme and the schemes proposed by Li and Hwang [11] and Das [21] are summarized in Table 2. For the convenience of evaluating the efficiency of related scheme, we define the notation ℎ , the time of executing a one-way hash function. The efficiency comparison with related schemes is shown in Table 3. From the table, we can see that our scheme is more efficient than Das's scheme [21]. Though our scheme is less efficient than Li-Hwang's scheme [11], it can provide better security against most attacks.

Conclusion
This paper presents a biometric-based user authentication scheme for client/server system. The method employs biometric keys and resists the threats of stolen-verifier, of which many are logged-in users with the same login identity, denialof-service attack, guessing attack, insider attack, replay attack, user impersonation attack, server masquerading attack, and man-in-the-middle attack. Moreover, the improved scheme can realize mutual authentication between the user and remote server. The proposed scheme uses only hash function and XOR operation, which is efficient compared with that of related protocols. In addition, the user's password can be changed freely using the proposed scheme. Our proposed scheme provides strong authentication with the help of verifying biometrics, passwords, and random nonces generated by the user and server as compared to that of related schemes.