# Fingerprint Protected Password Authentication Protocol

Authors: Chao Yang; Junwei Zhang; Jingjing Guo; Yu Zheng; Li Yang; Jianfeng Ma
Journal: Security and Communication Networks
 (2019)

---

## Abstract

With the rapid development of industrial Internet of things (IIOT), a variety of cloud services have been deployed to store and process the big data of IIOT. The traditional password only authentication is unable to meet the needs of security situation in IIOT. Therefore, a lot of mobile phone assisted password authentication schemes have been proposed. However, in existing schemes, the secret information is required to be stored in the user’s mobile phone. Once the phone is lost, the secret information may be obtained by the opponent, which will bring irreparable loss to the user. To address the above problems, we propose a fingerprint protected password authentication scheme which has no need to store the secret parameter in the mobile phone. When a user logs in, he uses his mobile phone to generate the private key which is used to decrypt the encrypted text generated during the registration phase. The process of generating the private key needs to enter the password and the fingerprint. When the computer interacts with the mobile phone, the user’s password will be blinded so that it can protect the user’s password from adversary’s attacks. Theoretical analysis and experimental results show that our scheme improves the security of the user’s secret. Meanwhile, our scheme can resist the opponent’s dictionary attacks, replay attacks, and phishing attack. Our scheme can reduce the storage pressure of the mobile phone and is easy to deploy.


---

## Body

## 1. Introduction

The rapid development of industrial Internet of things (IIOT) has reformed many aspects of user’s daily life. A variety of cloud services have been deployed to store and process the big data of IIOT [1–4]. Due to the openness of public network, these cloud services suffer from a wide range of attacks [5–8]. Text-based passwords remain the dominant authentication technique for various online services and systems, because it is accessible and convenient. Most of them require their own password and the user has to manage multiple passwords to their accounts.However, password authentication schemes have inherent limitations. Firstly, the user is prone to use a simple password for convenience. If the length of the password is short, its information entropy will be very low. Therefore, the user’s password will be easily compromised by attackers. After obtaining the user’s password, the opponent can use the password to access the user’s account and steal user’s private information. In addition, the user may use a single password to authenticate to multiple services. If one of the user’s accounts information leaks, it would pose a threat to the security of other accounts. What is worse, users often forget their passwords and try to login via trial-and-error, which means that a malicious online service would learn not only a user’s password to that service, but to many other services, possibly also through a cross-site impersonation attack. The low information entropy and the repeated setting of the password are common problems in the process of password setting and password usage. These above problems are also easily exploited by attackers. Moreover, malicious service providers may also launch attacks against the user. For example, the CEO of Facebook allegedly used Facebook login data to access the private mails of some business rivals and journalists in 2004[9]. Hence, protecting users’ passwords has become extremely important for individuals.To avoid the limitation of password authentication mechanism, researchers have proposed many schemes [10–12]. Adding an additional factor is one of the common ways to protect user’s password. With the extensive use of mobile phones in recent years, users often use mobile phone to manage personal information and store many credentials or secrets on the mobile phone. Consequently, the research on mobile phone assisted password authentication is one of the important trends.In 2004, Wu et al. [13] proposed a scheme using the mobile phone as an authentication token with the help of a trusted agent P. When a user wants to authenticate to a remote server, he/she is required to communicate with the agent P first. The agent P sends a session name to the mobile phone and the PC client. The user compares the session name showing on the mobile phone and the PC client. Then the user sends the result to the agent P. However, this scheme requires the agent to be secure and trustworthy, which is a strong assumption in practice. Moreover, the mobile phone is required to interact with the agent several times and is prone to man-in-the-middle attack. In addition, the involvement of a trust agent makes the scheme hard to be deployed.The scheme [14] proposed by Thanh et al. uses a mobile phone and an authentication server to assist the user during login authentication. In this scheme, with the help of the mobile phone and the authentication server, the client and the server is not required to communicate directly through the public network while sending or receiving credentials. However, the authentication server is utilized to receive the data transmitted by the mobile terminal through the GSM network, which is considered to be an insecure transmission channel. Therefore, the response phase is prone to be attacked by the opponents. When the user uses a mobile phone to send a message to the authentication server through the GSM network, it is not hard for the opponent to hijack the user’s message. The adversary can use the hijacked information to authenticate with the server.Considering the security of information transmission in the authentication phase, the scheme in [15] uses the mobile phone as the intermediary to transmit the user’s secrets securely. It uses the QR code and the camera to encrypt the key during the authentication phase. But this scheme requires adding a bar code on the device in advance. If there are plenty of authentication devices or services, many QR codes are required to be predeployed, which is not practical for deployment.The scheme in [16] is put forward to resist session hijacking and phishing attacks. The client PC is independent to the mobile device and just performs calculations in the scheme, while the mobile phone records the user’s password. They share a session key to against session hijacking. However, the mechanism requires the terminal to calculate and establish a pair of public keys with each server. If there are a number of services, the setting will be cumbersome, which will bring much overhead to the mobile phone. What is more, this scheme needs to establish a secure channel between the client PC and server, which greatly reduces the availability of this scheme.In [17], a method for users to authenticate with the server on an unreliable computer is provided. The main idea is that the mobile phone scans the QR code on the computer, encrypts the QR code, and then uses it to authenticate with the server. However, this scheme requires the trusted mobile phone and the server to set up a shared key in advance, which is difficult to realize in the practice. Moreover, mobile phone and computer need to communicate with the server several times during the authentication phase, which makes this scheme time consuming.In the SPA (single password authentication) scheme proposed by Acar et al. [18], it requires additional cloud storage to store the user’s data and assist the user to register and log in. However, the scheme needs to set a secure channel between the client and the storage when the client sends the blind signature private key to the storage, which is a strong assumption. Furthermore, this scheme also requires a trusted cloud storage to store the ciphertext, which is not readily accessible in practice. Moreover, the user and the cloud storage require a lot of data transmission and interaction during the authentication phase, making time consuming. Acar et al. also proposed a different SPA scheme based on a mobile device. In this scheme, a trusted mobile device is used to assist users to register and log in. The user uses the password to encrypt the authentication key and then store the ciphertext on the trusted mobile phone device. When the user wants to access his account, he inputs his password to decrypt the ciphertext to get his authentication key and then authenticate with the server. But this scheme also requires the mobile device and server to be trusted, and no collusion between the server and mobile phone, which is a very harsh security requirement for mobile devices. In addition, if the mobile device is lost, which is a very common situation, user’s ciphertext stored on the mobile device can be cracked offline by adversaries, which will lead to serious consequences.In the password authentication method based on mobile phone assistance, there is a method based on fingerprint, which attracts much attention. The scheme [19] proposed using a fingerprint to replace the PIN code to authenticate the user’s identity. However, fingerprint information is still stored in the mobile phone in this scheme. If the fingerprint information is cracked by adversaries, it will pose a security threat to the user. So this scheme cannot protect the user’s privacy very well. The scheme [20] proposes a solution that enables a user to authenticate with a remote server through a password and fingerprint. However, this scheme requires a secure channel between the client and the server, which is difficult to deploy in the actual scenario. Moreover, the mobile device is also required to be trusted. It means that if the mobile device is lost, the ciphertext and the fingerprint parameters stored on the phone can be cracked by attackers.The password authentication method based on mobile phone assistance has received extensive attention and has been widely studied. However, these schemes have security risks in terms of user’s privacy: the mobile phone has to store the user’s privacy or credentials during the authentication process and the mobile phone must be trusted. Otherwise the user’s privacy stored in the mobile phone can be cracked forcedly by the adversary. In March 2016, FBI announced that it can crack the IOS to obtain the suspect’s mobile phone terminal information [21]. This means that there is no mature technology that can fully guarantee the user’s privacy stored in the mobile devices at present. So it is risky to store the user’s secret information on the mobile phone. This risk will affect the security of the authentication scheme based on mobile phone assistance extensively.Although authentication schemes assisted by mobile phone are popular, there are a lot of defects and hidden danger in this kind of authentication schemes. At present, most authentication schemes with mobile phone assistance have to store the user’s private information on the mobile phone to help authentication. Moreover, in most schemes, the mobile phone is required to be fully trusted. However, in March 2016, FBI announced that it can crack the IOS system to obtain the suspect’s mobile phone terminal information. This means that there is no mature technology that can fully guarantee the user’s privacy stored in the mobile devices at present. So it is risky to store the user’s secret information on the mobile phone. HCR (Hidden Credential Retrieval from a Reusable Password) [22] is a protocol that can be used by the user to store his information on an unreliable remote server. When the user wants to obtain his information, he can get his own encrypted information by a preset password and do not have to disclose the password to the server. However, this protocol needs to set up a secure channel to transmit the private key during the registration phase. Meanwhile, the private key has been saved on the server for a long time, which is an insecure operation. Existing three party authentication schemes participated with mobile phone, computer, and server often require the user’s encrypted information saved on the mobile phone; meanwhile, the mobile phone must be reliable. What is more, the scheme assumes a secure channel to transmit secret information. This assumption and deployment are too difficult to be implemented in an actual situation, which greatly reduces the availability and security of the authentication scheme.To solve these difficult problems, we propose a fingerprint protected password authentication (FPPA). Our new scheme has eliminated the complete credibility of the phone and the security channel between the phone and the server. When the user logs in he uses his mobile phone to generate the private key which is used to decrypt the ciphertext generated during the registration phase. The user needs to enter his password and fingerprint at the private key generation process. When the computer interacts with the mobile phone, the user’s password will be blind. So the password can be protected from adversaries’ attacks. Our scheme does not need to store any user’s secret information on the mobile phone. Even if the mobile phone is stolen by adversaries, the private information in it will not be leaked. Security analysis proves that this scheme can protect the user’s password against dictionary attacks and session hijacking attacks even without the assumption of secure storage and a secure channel between phone and server. Experimental results show that our scheme is essentially the same as the current schemes in terms of performance and has a significant advantage in the storage of mobile terminal over other schemes. The main contributions of our work can be summarized as follows:(I) In order to ensure the security of the user’s secret information in the IIOT, a fingerprint protected password authentication protocol which has no need to store the secret parameter in the mobile phone is proposed.(II) Our scheme can resist the opponent’s dictionary attacks, replay attacks, and phishing attack.(III) Our scheme has good performance and strong practicability.The rest of the paper is organized as follows. Section2 introduces the preliminary knowledge of the paper. Section 3 introduces the model of the system model and the adversary model respectively. Section 4 introduces the overview of the FPPA scheme. Section 5 describes the security analysis and proof. Performance analysis and evaluation are presented in Section 6. Finally, Section 7 concludes.


## 2. Preliminary

### 2.1. Blind Signature

Blind signature scheme is a basic cryptographic primitive to guarantee the anonymity of participants. A blind signature scheme consists of two entities: a message sender and a signer. It allows the sender to obtain the signature of a given message without revealing any information about the message and the corresponding signature. The basic principle of blind signature is the application of two commutative algorithms. One algorithm is to conceal information, called blind transformation, and the other is the signature algorithm.The characteristics of blind signature are as follows:(I) The content of the message is blind to the signer.(II) The signer cannot associate the signed message with the actual message signed. Even if he saves all the documents he signed, he cannot distinguish the real content of the documents he signed.


### 2.2. HKDF (Halting Key Derivation Functions)

HKDF [23] is a protocol that can generate strong security key through a general weak password. It can choose the cost of the calculation, which is applied to the password-based encryption system.HKDF includes two algorithms:HKDF.prepare() andHKDF.extract().(I)
H
K
D
F
.
p
r
e
p
a
r
e
(
w
,
t
,
r
)
→
y
,
v.HKDF.prepare() takes as input a password w, a random stringr, and a parametert of cycle calculations and returns a random tokeny and its ciphertextv.(II)
H
K
D
F
.
e
x
t
r
a
c
t
(
w
,
v
)
→
y.HKDF.extract() takes as input a password w and a ciphertextv and either returns a tokeny or fails to halt in polynomial time. If the password w is not correct, this algorithm will always be a loop operation without output feedback 0.In this paper, we use aHKDF algorithm to generate a strong key using a private key, and user or system can establish a suitable parameter value to select the corresponding calculation cost.


## 2.1. Blind Signature

Blind signature scheme is a basic cryptographic primitive to guarantee the anonymity of participants. A blind signature scheme consists of two entities: a message sender and a signer. It allows the sender to obtain the signature of a given message without revealing any information about the message and the corresponding signature. The basic principle of blind signature is the application of two commutative algorithms. One algorithm is to conceal information, called blind transformation, and the other is the signature algorithm.The characteristics of blind signature are as follows:(I) The content of the message is blind to the signer.(II) The signer cannot associate the signed message with the actual message signed. Even if he saves all the documents he signed, he cannot distinguish the real content of the documents he signed.


## 2.2. HKDF (Halting Key Derivation Functions)

HKDF [23] is a protocol that can generate strong security key through a general weak password. It can choose the cost of the calculation, which is applied to the password-based encryption system.HKDF includes two algorithms:HKDF.prepare() andHKDF.extract().(I)
H
K
D
F
.
p
r
e
p
a
r
e
(
w
,
t
,
r
)
→
y
,
v.HKDF.prepare() takes as input a password w, a random stringr, and a parametert of cycle calculations and returns a random tokeny and its ciphertextv.(II)
H
K
D
F
.
e
x
t
r
a
c
t
(
w
,
v
)
→
y.HKDF.extract() takes as input a password w and a ciphertextv and either returns a tokeny or fails to halt in polynomial time. If the password w is not correct, this algorithm will always be a loop operation without output feedback 0.In this paper, we use aHKDF algorithm to generate a strong key using a private key, and user or system can establish a suitable parameter value to select the corresponding calculation cost.


## 3. System and Adversary Model

### 3.1. System Model

The system model of the scheme is shown in Figure1. It mainly includes the following three entities: mobile phone (MP), personal computer (PC), and cloud server (CS).Figure 1
System architecture of our scheme.MP is in charge of user’s authentication key and generation of the ciphertext during the registration phase. It interacts with the PC in the authentication phase, so that the user’s blind password and fingerprint parameters are processed during this phase. In addition to the basic functions of the mobile phone, it should be able to register the user’s fingerprint data and connect to the PC via Bluetooth, USB, or Wi-Fi, in order to communicate with PC.PC is responsible for the password input and interacts with mobile phone to generate session key when the user logs on. PC should ensure that it is connected to the Internet and can communicate with the CS and mobile phones.CS stores users’ authentication key and their ciphertext at the end of the registration phase and provides users with their corresponding ciphertext information. Meanwhile, it verifies user’s identity in the login phase. Accordingly, the CS should be able to connect to the Internet and has a powerful database to store user’s information.The registration phase includes step ①, and the login phase includes steps ②, ③, and ④.


### 3.2. The Adversary Model

The adversary model is defined as follows:(I) PC is distrusted. In the login phase, if the user’s PC is infected by malwares, the keyboard may record the user’s password. If the user accesses a phishing site, the adversary may also record the user’s password.(II) User uses mobile phone during the registration and login phase, while the mobile phone is prone to be lost or be implanted with malwares. If the phone was infected by malwares, the adversary may impersonate as the user to communicate with the PC.(III) The CS authenticates the user and provides application services. In the registration phase, the CS is trusted. After that, the CS may suffer from replay attack or dictionary attacks. In addition, the CS may also be curious about user information.


## 3.1. System Model

The system model of the scheme is shown in Figure1. It mainly includes the following three entities: mobile phone (MP), personal computer (PC), and cloud server (CS).Figure 1
System architecture of our scheme.MP is in charge of user’s authentication key and generation of the ciphertext during the registration phase. It interacts with the PC in the authentication phase, so that the user’s blind password and fingerprint parameters are processed during this phase. In addition to the basic functions of the mobile phone, it should be able to register the user’s fingerprint data and connect to the PC via Bluetooth, USB, or Wi-Fi, in order to communicate with PC.PC is responsible for the password input and interacts with mobile phone to generate session key when the user logs on. PC should ensure that it is connected to the Internet and can communicate with the CS and mobile phones.CS stores users’ authentication key and their ciphertext at the end of the registration phase and provides users with their corresponding ciphertext information. Meanwhile, it verifies user’s identity in the login phase. Accordingly, the CS should be able to connect to the Internet and has a powerful database to store user’s information.The registration phase includes step ①, and the login phase includes steps ②, ③, and ④.


## 3.2. The Adversary Model

The adversary model is defined as follows:(I) PC is distrusted. In the login phase, if the user’s PC is infected by malwares, the keyboard may record the user’s password. If the user accesses a phishing site, the adversary may also record the user’s password.(II) User uses mobile phone during the registration and login phase, while the mobile phone is prone to be lost or be implanted with malwares. If the phone was infected by malwares, the adversary may impersonate as the user to communicate with the PC.(III) The CS authenticates the user and provides application services. In the registration phase, the CS is trusted. After that, the CS may suffer from replay attack or dictionary attacks. In addition, the CS may also be curious about user information.


## 4. The FPPA Scheme

### 4.1. Design Rationale of the FPPA Scheme

Our FPPA protocol allows a user register and authenticate with online services using his password and mobile phone securely. During the authentication protocol, the mobile phone may be lost or compromised by malwares, so the information stored on the mobile phone may be exposed by adversaries. At the same time, when the user logs on, the mobile phone interacts with the PC. If the mobile phone gets the user’s password, it may also be stolen by the adversary. Therefore, it is required that authentication information and encrypted data should not be stored in the mobile phone. To avoid the case that the password is stolen by adversaries during the authentication phase, it is required that the PC encrypts the password after the user enters his password.To this end, we improve the existing HCR protocol, which is deployed on the PC and mobile phone, such that user can interact with the distrusted mobile phone. In the HCR protocol, the private key needs to be transmitted in a secure channel and stored safely for a long time. Our scheme replaces the private key parameter with the user’s fingerprint so that our scheme does not require the secure channel, or the long-term storage.


### 4.2. The Detailed Process of the FPPA Scheme

Our scheme includes a mobile phone, a PC, and a CS during the registration phase and the login phase. The user enters his password and fingerprint on the phone and PC to register and log on. The CS is responsible for the registration and authentication when the user wants to access the CS.The system initialization definition is as follows:p: a prime number;name: the user name;pwd: the user’s password;G: a cyclic abelian group of orderp;F: a multiplicative domain of orderp;e: the user’s fingerprint;s: the user’s private key;y: the user’s authentication key;v: the ciphertext of the authentication information;H
a
s
h
(
)
:
{
0,1
}
∗
→
G: a cryptographic hash function, which is to be viewed as a random oracle;d
∈
F
p
x: a random number generated by the system;f: a hash function;HKDF: a key derivation function, which consists of two functions:HKDF.prepare() andHKDF.extract().Generally, in the previous mobile phone based authentication scheme, the mobile phone stores user’s authentication information. The user’s password is encrypted and stored on the mobile phone, or the user’s secret key is encrypted with his password and stored on the mobile phone. If the phone is compromised by the adversary, the adversary is likely to get the user’s password or authentication information.In our FPPA scheme, the mobile phone does not store the user’s authentication information. The authentication key is regenerated by himself when he wants to log on. Even if the device is stolen, it will not pose threat to the user’s password, fingerprint, or encrypted information. Moreover, when the user sends the name to the server in the registration phase, he/she can also choose to send a random identity ID, so that he/she can preserve his/her anonymity. Even if several CSs are in collusion with each other, the user cannot be attacked.Registration and login phase are as follows:


#### 4.2.1. Registration Phase

In this phase, before the user accesses to the service provided by the CS, he/she is required to register to be a legal user. The user can register through the mobile phone, after the completion of registration phase, the user namename and service information are sent to the PC side.The process is detailed as follows, as is shown in Figure2.Figure 2
Registration phase.(I) Mobile phone generates the user’s private key s according to the user’s passwordpwd and fingerprint parametere. The user’s private keys is generated as follows:(1)
H
a
s
h
p
w
d
e
→
s
.(II) The mobile phone side generates the user’s authentication keyy and the ciphertext of authentication keyv based on the HKDF function and the private keys. The operation is as follows:(2)
H
K
D
F
.
p
r
e
p
a
r
e
s
,
t
,
r
→
y
,
v
,wherer is a random string generated by the system;t is the number of loop operations. Note thatt can be selected according to the security requirements of the user. If the value oft is larger, the computation would be more time consuming. So the generated key is more secure.(III) The mobile phone sends the authentication keyy, the ciphertextv, and the user namename to the CS. Meanwhile, the mobile phone sends the user namename and CS informationserver to the PC. The user just remembers the user namename and passwordpwd, and the mobile phone does not store any secret information of the user.


#### 4.2.2. Login Phase

When the user wants to access the CS, he/she needs to send a login request to the CS. The user enters his own password and fingerprint data to generate a private key and then decrypts the ciphertext to obtain the authentication key. The server determines whether to accept the logon request or not after the server computes and compares the authentication information. The specific operation is as follows, as is shown in Figure3Figure 3
Login phase.(I) The PC sendsname to the CS, and then the CS retrieves the corresponding information according toname. After that, the CS sends the corresponding ciphertextv and certified random numberchal to the PC.(II) The user enters his password on the PC. The system generates a blind parameterd and then calculates the blinded passwordμ to the mobile phone.(3)
H
a
s
h
p
w
d
d
→
μ(III) The user inputs his fingerprint on the mobile phone. The mobile phone gets the fingerprint parameterε and then obtains β by signing the blinded password μ. The mobile phone sends β to the PC.(4)
μ
ε
→
β(IV)The PC recovers the private keys by the following calculation.(5)
β
1
/
d
→
s(V)The PC uses the private keys and HKDF algorithm to decrypt the ciphertextv and then obtains the authentication keyv.(6)
H
K
D
F
.
e
x
t
r
a
c
t
s
,
v
→
y(VI)The PC obtains the response by computingf
(
y
,
c
h
a
l
)
→
r
e
s
p
o
n
s
e and sends the responseresponse to the CS.(VII)Finally, the CS computesr
e
s
p
o
n
s
e
′
←
f
(
y
,
c
h
a
l
) and compares it with the response received. This logon is successful if these two parameters are identical.


## 4.1. Design Rationale of the FPPA Scheme

Our FPPA protocol allows a user register and authenticate with online services using his password and mobile phone securely. During the authentication protocol, the mobile phone may be lost or compromised by malwares, so the information stored on the mobile phone may be exposed by adversaries. At the same time, when the user logs on, the mobile phone interacts with the PC. If the mobile phone gets the user’s password, it may also be stolen by the adversary. Therefore, it is required that authentication information and encrypted data should not be stored in the mobile phone. To avoid the case that the password is stolen by adversaries during the authentication phase, it is required that the PC encrypts the password after the user enters his password.To this end, we improve the existing HCR protocol, which is deployed on the PC and mobile phone, such that user can interact with the distrusted mobile phone. In the HCR protocol, the private key needs to be transmitted in a secure channel and stored safely for a long time. Our scheme replaces the private key parameter with the user’s fingerprint so that our scheme does not require the secure channel, or the long-term storage.


## 4.2. The Detailed Process of the FPPA Scheme

Our scheme includes a mobile phone, a PC, and a CS during the registration phase and the login phase. The user enters his password and fingerprint on the phone and PC to register and log on. The CS is responsible for the registration and authentication when the user wants to access the CS.The system initialization definition is as follows:p: a prime number;name: the user name;pwd: the user’s password;G: a cyclic abelian group of orderp;F: a multiplicative domain of orderp;e: the user’s fingerprint;s: the user’s private key;y: the user’s authentication key;v: the ciphertext of the authentication information;H
a
s
h
(
)
:
{
0,1
}
∗
→
G: a cryptographic hash function, which is to be viewed as a random oracle;d
∈
F
p
x: a random number generated by the system;f: a hash function;HKDF: a key derivation function, which consists of two functions:HKDF.prepare() andHKDF.extract().Generally, in the previous mobile phone based authentication scheme, the mobile phone stores user’s authentication information. The user’s password is encrypted and stored on the mobile phone, or the user’s secret key is encrypted with his password and stored on the mobile phone. If the phone is compromised by the adversary, the adversary is likely to get the user’s password or authentication information.In our FPPA scheme, the mobile phone does not store the user’s authentication information. The authentication key is regenerated by himself when he wants to log on. Even if the device is stolen, it will not pose threat to the user’s password, fingerprint, or encrypted information. Moreover, when the user sends the name to the server in the registration phase, he/she can also choose to send a random identity ID, so that he/she can preserve his/her anonymity. Even if several CSs are in collusion with each other, the user cannot be attacked.Registration and login phase are as follows:


### 4.2.1. Registration Phase

In this phase, before the user accesses to the service provided by the CS, he/she is required to register to be a legal user. The user can register through the mobile phone, after the completion of registration phase, the user namename and service information are sent to the PC side.The process is detailed as follows, as is shown in Figure2.Figure 2
Registration phase.(I) Mobile phone generates the user’s private key s according to the user’s passwordpwd and fingerprint parametere. The user’s private keys is generated as follows:(1)
H
a
s
h
p
w
d
e
→
s
.(II) The mobile phone side generates the user’s authentication keyy and the ciphertext of authentication keyv based on the HKDF function and the private keys. The operation is as follows:(2)
H
K
D
F
.
p
r
e
p
a
r
e
s
,
t
,
r
→
y
,
v
,wherer is a random string generated by the system;t is the number of loop operations. Note thatt can be selected according to the security requirements of the user. If the value oft is larger, the computation would be more time consuming. So the generated key is more secure.(III) The mobile phone sends the authentication keyy, the ciphertextv, and the user namename to the CS. Meanwhile, the mobile phone sends the user namename and CS informationserver to the PC. The user just remembers the user namename and passwordpwd, and the mobile phone does not store any secret information of the user.


### 4.2.2. Login Phase

When the user wants to access the CS, he/she needs to send a login request to the CS. The user enters his own password and fingerprint data to generate a private key and then decrypts the ciphertext to obtain the authentication key. The server determines whether to accept the logon request or not after the server computes and compares the authentication information. The specific operation is as follows, as is shown in Figure3Figure 3
Login phase.(I) The PC sendsname to the CS, and then the CS retrieves the corresponding information according toname. After that, the CS sends the corresponding ciphertextv and certified random numberchal to the PC.(II) The user enters his password on the PC. The system generates a blind parameterd and then calculates the blinded passwordμ to the mobile phone.(3)
H
a
s
h
p
w
d
d
→
μ(III) The user inputs his fingerprint on the mobile phone. The mobile phone gets the fingerprint parameterε and then obtains β by signing the blinded password μ. The mobile phone sends β to the PC.(4)
μ
ε
→
β(IV)The PC recovers the private keys by the following calculation.(5)
β
1
/
d
→
s(V)The PC uses the private keys and HKDF algorithm to decrypt the ciphertextv and then obtains the authentication keyv.(6)
H
K
D
F
.
e
x
t
r
a
c
t
s
,
v
→
y(VI)The PC obtains the response by computingf
(
y
,
c
h
a
l
)
→
r
e
s
p
o
n
s
e and sends the responseresponse to the CS.(VII)Finally, the CS computesr
e
s
p
o
n
s
e
′
←
f
(
y
,
c
h
a
l
) and compares it with the response received. This logon is successful if these two parameters are identical.


## 4.2.1. Registration Phase

In this phase, before the user accesses to the service provided by the CS, he/she is required to register to be a legal user. The user can register through the mobile phone, after the completion of registration phase, the user namename and service information are sent to the PC side.The process is detailed as follows, as is shown in Figure2.Figure 2
Registration phase.(I) Mobile phone generates the user’s private key s according to the user’s passwordpwd and fingerprint parametere. The user’s private keys is generated as follows:(1)
H
a
s
h
p
w
d
e
→
s
.(II) The mobile phone side generates the user’s authentication keyy and the ciphertext of authentication keyv based on the HKDF function and the private keys. The operation is as follows:(2)
H
K
D
F
.
p
r
e
p
a
r
e
s
,
t
,
r
→
y
,
v
,wherer is a random string generated by the system;t is the number of loop operations. Note thatt can be selected according to the security requirements of the user. If the value oft is larger, the computation would be more time consuming. So the generated key is more secure.(III) The mobile phone sends the authentication keyy, the ciphertextv, and the user namename to the CS. Meanwhile, the mobile phone sends the user namename and CS informationserver to the PC. The user just remembers the user namename and passwordpwd, and the mobile phone does not store any secret information of the user.


## 4.2.2. Login Phase

When the user wants to access the CS, he/she needs to send a login request to the CS. The user enters his own password and fingerprint data to generate a private key and then decrypts the ciphertext to obtain the authentication key. The server determines whether to accept the logon request or not after the server computes and compares the authentication information. The specific operation is as follows, as is shown in Figure3Figure 3
Login phase.(I) The PC sendsname to the CS, and then the CS retrieves the corresponding information according toname. After that, the CS sends the corresponding ciphertextv and certified random numberchal to the PC.(II) The user enters his password on the PC. The system generates a blind parameterd and then calculates the blinded passwordμ to the mobile phone.(3)
H
a
s
h
p
w
d
d
→
μ(III) The user inputs his fingerprint on the mobile phone. The mobile phone gets the fingerprint parameterε and then obtains β by signing the blinded password μ. The mobile phone sends β to the PC.(4)
μ
ε
→
β(IV)The PC recovers the private keys by the following calculation.(5)
β
1
/
d
→
s(V)The PC uses the private keys and HKDF algorithm to decrypt the ciphertextv and then obtains the authentication keyv.(6)
H
K
D
F
.
e
x
t
r
a
c
t
s
,
v
→
y(VI)The PC obtains the response by computingf
(
y
,
c
h
a
l
)
→
r
e
s
p
o
n
s
e and sends the responseresponse to the CS.(VII)Finally, the CS computesr
e
s
p
o
n
s
e
′
←
f
(
y
,
c
h
a
l
) and compares it with the response received. This logon is successful if these two parameters are identical.


## 5. Security Analysis and Proof

### 5.1. FPPA Protocol

Our FPPA protocol has three types of entities: the PC client who wants to use a password and fingerprint to access services, the CS who registers and authenticates clients, and mobile phone who assists PC client to complete registering and logging.Our FPPA protocol consists of following algorithms:UserGen. This algorithm is run by the user to generate a user namename and an l-bit passwordpwd.Register. The user registers with the server by inputting his password and fingerprint on the mobile phone. In the end, the mobile phone outputs an authenticated keyy and ciphertext of the authenticated keyv. The mobile phone sends (name,y,v) to the CS and sends (name,server) to the PC.Store. The PC stores the user namename. The mobile phone does not store user’s any information. The user just needs to remember his name and password.Retrieve. The PC client uses its user namename to retrieve its ciphertextv from the server. The server sends the ciphertextv and challengechal to the PC client.PreAuth. The user inputs his passwordpwd in the PC side and inputs his fingerprinte on the mobile phone. The PC client interacts with the mobile phone using the blind signature. At the end of the blind signature, the PC client generates the private keys and decrypts the ciphertextv usings. The PC client obtains the authenticated keyy after decrypting the ciphertext.Authenticate. The user uses his authenticated keyy and changechal to prove to the server that he owns the corresponding account credential. Finally, the CS outputs accept or reject.


### 5.2. Security Game

Our FPPA scheme assumes that the user has a mobile phone and PC client, so that the user can enter his own password and fingerprint on these devices. However, mobile phones may be lost. Therefore, malicious adversaries may use the user’s data stored on the mobile phone to access the server, and even decrypt the ciphertext brutally. What is more, the PC client and the server are also easily attacked by adversaries [24, 25]. We divide the potential attacks into two types: Insider attack (Game One) and Outsider attack (Game Two). Let x be a security parameter, such that all hash functions have at least l≥2x bits of output. Let |
D
|
<
<
2
x be the length of the password dictionary. k is the length of the user’s password. k
∈
N. Let neg(k) be a negligible function of k if ∃K finite:∀k>K: n
e
g
(
k
)
<
k
-
c[26–28].Game One (Outsider Attack). In this game, the adversary can control the PC side. He can perform the Store step with the mobile phone and PC. He can also perform thePreAuth step with the server by acting as a malicious PC. The adversary may also control the PC side and then launch the Retrieve request. We assume the times of requests are q. The adversary can control the mobile phone side and perform Retrieve step with the PC side by simulating the mobile phone side. In the algorithm of our scheme, mobile phone can only receive data from the PC side but cannot initiate requests to the PC side. If the adversary got the user’s password through the game or guessed the private key s without the password, we consider the adversary win [29, 30].Definition 1.
We assume that the probability of adversary winning the Game One is P1. If P1≤max[q/|D|+neg(k), 1/2|s|], we consider that FPPA is in accord with the security based on Game One.Game Two (Insider Attack). In this game, the adversary can control the server side. He can launch an offline dictionary attack on the server to get the ciphertext of the user’s password. We assume that the adversary can initiateT times offline dictionary attacks againstHKDF.extract. If the adversary got the user’s password through the game, we consider the adversary wins.Definition 2.
We assume that the probability of the adversary winning the Game Two isP2. If p
2
≤
q
/
|
D
|
+
2
T
/
|
D
|
t
+
n
e
g
(
k
), we consider that FPPA is in accord with the security based on Game Two.Definition 3.
If FPPA is in accord with the security based on Game One and Game Two, we consider the FPPA is security.


### 5.3. Security of FPPA

Theorem.FPPA is in accord with the security based on Definition3.Prove. (I) FPPA can provide security based on Game One.Game One. (1)The adversary simulates the PC side and performsStore with mobile phone to get the user’s namename. The adversary performsPreAuth with server side and retrieves user secret key ciphertextv and challengechal according to the user’s name. According tov is generated by the algorithm ofHKDF[23], if someone inputs wrong password to decrypt the ciphertext, theHKDF would compute circularly with no output. So the adversary cannot get user’s password throughv. Consequently,P1 is a small value that can be ignored.(2)The adversary simulates the PC side, generates a passwordpwd0, and performsRetrieve with mobile phone. This interaction process is similar to the interaction process in the algorithm ofHCR and just replaces the signature private key inHCR into fingerprint parameters. The probability of guessing password in this game is the same as that in HCR [22]. So the probability of the adversary guessing the password:P[guess password]≤q/|D|+neg(k). The probability of the adversary winning this game:P1≤q/|
D
|+neg(k).(3)The adversary controls the PC side and guesses the private keys without password. The probability of the adversary guessing private key:P[guess s]≤1/2
|
s
|. The probability of the adversary winning this game: P1≤1/2
|
s
|.(4)The adversary performsRetrieve with PC side by simulating mobile phone. The adversary can get the blinded password of the user. So the probability of the adversary guessing the password is the same as the analysis of (b). The probability of the adversary guessing the password: P[get the password] ≤q/|
D
|+neg(k).The probability of the adversary winning this game:P1≤q/
|
D
|
+neg(k).In summary,P1≤max[q/
|
D
|+neg(k), 1/2
|
s
|]. So FPPA can provide the security based on Game One.(II) FPPA can provide security based on Game Two.Game Two. Malicious server launches offline dictionary attacks on the ciphertext stored on itself. It generates a private key s’ and tries to decrypt ciphertext:HKDF.extract (s’,v). According to the security ofHKDF[23]:P
[
g
e
t
t
h
e
p
a
s
s
w
o
r
d
]
≤
T
/
|
D
|
t
+
n
e
g
(
k
).t is the parameter of cyclic operation times set up inHKDF.prepare.So the probability of the adversary getting the user’s password:P
2
≤
q
/
|
D
|
+
2
T
/
|
D
|
t
+
n
e
g
(
k
).Consequently, FPPA can provide the security based on Game Two.In summary, FPPA can provide security based on Game One and Game Two, so FPPA is a secure protocol.


## 5.1. FPPA Protocol

Our FPPA protocol has three types of entities: the PC client who wants to use a password and fingerprint to access services, the CS who registers and authenticates clients, and mobile phone who assists PC client to complete registering and logging.Our FPPA protocol consists of following algorithms:UserGen. This algorithm is run by the user to generate a user namename and an l-bit passwordpwd.Register. The user registers with the server by inputting his password and fingerprint on the mobile phone. In the end, the mobile phone outputs an authenticated keyy and ciphertext of the authenticated keyv. The mobile phone sends (name,y,v) to the CS and sends (name,server) to the PC.Store. The PC stores the user namename. The mobile phone does not store user’s any information. The user just needs to remember his name and password.Retrieve. The PC client uses its user namename to retrieve its ciphertextv from the server. The server sends the ciphertextv and challengechal to the PC client.PreAuth. The user inputs his passwordpwd in the PC side and inputs his fingerprinte on the mobile phone. The PC client interacts with the mobile phone using the blind signature. At the end of the blind signature, the PC client generates the private keys and decrypts the ciphertextv usings. The PC client obtains the authenticated keyy after decrypting the ciphertext.Authenticate. The user uses his authenticated keyy and changechal to prove to the server that he owns the corresponding account credential. Finally, the CS outputs accept or reject.


## 5.2. Security Game

Our FPPA scheme assumes that the user has a mobile phone and PC client, so that the user can enter his own password and fingerprint on these devices. However, mobile phones may be lost. Therefore, malicious adversaries may use the user’s data stored on the mobile phone to access the server, and even decrypt the ciphertext brutally. What is more, the PC client and the server are also easily attacked by adversaries [24, 25]. We divide the potential attacks into two types: Insider attack (Game One) and Outsider attack (Game Two). Let x be a security parameter, such that all hash functions have at least l≥2x bits of output. Let |
D
|
<
<
2
x be the length of the password dictionary. k is the length of the user’s password. k
∈
N. Let neg(k) be a negligible function of k if ∃K finite:∀k>K: n
e
g
(
k
)
<
k
-
c[26–28].Game One (Outsider Attack). In this game, the adversary can control the PC side. He can perform the Store step with the mobile phone and PC. He can also perform thePreAuth step with the server by acting as a malicious PC. The adversary may also control the PC side and then launch the Retrieve request. We assume the times of requests are q. The adversary can control the mobile phone side and perform Retrieve step with the PC side by simulating the mobile phone side. In the algorithm of our scheme, mobile phone can only receive data from the PC side but cannot initiate requests to the PC side. If the adversary got the user’s password through the game or guessed the private key s without the password, we consider the adversary win [29, 30].Definition 1.
We assume that the probability of adversary winning the Game One is P1. If P1≤max[q/|D|+neg(k), 1/2|s|], we consider that FPPA is in accord with the security based on Game One.Game Two (Insider Attack). In this game, the adversary can control the server side. He can launch an offline dictionary attack on the server to get the ciphertext of the user’s password. We assume that the adversary can initiateT times offline dictionary attacks againstHKDF.extract. If the adversary got the user’s password through the game, we consider the adversary wins.Definition 2.
We assume that the probability of the adversary winning the Game Two isP2. If p
2
≤
q
/
|
D
|
+
2
T
/
|
D
|
t
+
n
e
g
(
k
), we consider that FPPA is in accord with the security based on Game Two.Definition 3.
If FPPA is in accord with the security based on Game One and Game Two, we consider the FPPA is security.


## 5.3. Security of FPPA

Theorem.FPPA is in accord with the security based on Definition3.Prove. (I) FPPA can provide security based on Game One.Game One. (1)The adversary simulates the PC side and performsStore with mobile phone to get the user’s namename. The adversary performsPreAuth with server side and retrieves user secret key ciphertextv and challengechal according to the user’s name. According tov is generated by the algorithm ofHKDF[23], if someone inputs wrong password to decrypt the ciphertext, theHKDF would compute circularly with no output. So the adversary cannot get user’s password throughv. Consequently,P1 is a small value that can be ignored.(2)The adversary simulates the PC side, generates a passwordpwd0, and performsRetrieve with mobile phone. This interaction process is similar to the interaction process in the algorithm ofHCR and just replaces the signature private key inHCR into fingerprint parameters. The probability of guessing password in this game is the same as that in HCR [22]. So the probability of the adversary guessing the password:P[guess password]≤q/|D|+neg(k). The probability of the adversary winning this game:P1≤q/|
D
|+neg(k).(3)The adversary controls the PC side and guesses the private keys without password. The probability of the adversary guessing private key:P[guess s]≤1/2
|
s
|. The probability of the adversary winning this game: P1≤1/2
|
s
|.(4)The adversary performsRetrieve with PC side by simulating mobile phone. The adversary can get the blinded password of the user. So the probability of the adversary guessing the password is the same as the analysis of (b). The probability of the adversary guessing the password: P[get the password] ≤q/|
D
|+neg(k).The probability of the adversary winning this game:P1≤q/
|
D
|
+neg(k).In summary,P1≤max[q/
|
D
|+neg(k), 1/2
|
s
|]. So FPPA can provide the security based on Game One.(II) FPPA can provide security based on Game Two.Game Two. Malicious server launches offline dictionary attacks on the ciphertext stored on itself. It generates a private key s’ and tries to decrypt ciphertext:HKDF.extract (s’,v). According to the security ofHKDF[23]:P
[
g
e
t
t
h
e
p
a
s
s
w
o
r
d
]
≤
T
/
|
D
|
t
+
n
e
g
(
k
).t is the parameter of cyclic operation times set up inHKDF.prepare.So the probability of the adversary getting the user’s password:P
2
≤
q
/
|
D
|
+
2
T
/
|
D
|
t
+
n
e
g
(
k
).Consequently, FPPA can provide the security based on Game Two.In summary, FPPA can provide security based on Game One and Game Two, so FPPA is a secure protocol.


## 6. Performance Analysis and Evaluation

### 6.1. Test Plan and Scenario

We rented Ali CS to authenticate with the user in order to make the test scenario more close to the actual one. Ali CS deployed in Qingdao and the distance between Qingdao and Xi’an is 1058.6km.As shown in the Figure4, 1 describes that the mobile phone computes and generates authenticate keyy and authenticate key ciphertextv. And then the mobile phone sendsv to the CS in the end of registration phase. 2, 3, and 4 describe that the mobile phone and the PC compute and generate authenticate keyy to authenticate with CS in login phase.Figure 4
The overall test scenario.Android device, a PC and CS are used to simulate our scheme. We evaluate the usability of our scheme from the aspects of time and storage. We test the user’s registration and login time in four different scenarios. In terms of storage capacity, we mainly analyze and evaluate the storage capacity of the Android device. The experimental devices of our scheme are a PC, a CS, and an Android device. The specific parameters of the experimental devices are as follows:We use Ali CS located in Qingdao as the CS in our scheme. RAM of the CS is 1GB. It has a single-core processor. The operating system of it is windows Server 2008.We use HP Compad dx7408 MT DT PC as the computer in our scheme. It has a dual-core processor. RAM of the computer is 2GB. The operating system of it is windows 7(32 bits).We use Bluestacks (Android 4.1.2-API Level 16, CPU ARM (armeabi), RAM 512, VM Heap 16, Internal Storage 200MiB) and Android phone as the mobile phone in our scheme.We tested our scheme in 4 cases.Case 1.
The user registers and logs in, and then enters his password and fingerprint. We test the time spent on registration phase and login phase and then test several sets of data to find the average time for one user spent on registration and login phase. The Android device used in this scenario is the Android simulator.Case 2.
The length and complexity of passwords are different for different users. In order to analyze the influence of different passwords on our scheme, we select 20 groups of users. We test the time of these users spent on registration phase and login phase. The Android device used in this scenario is the Android simulator.Case 3.
Due to the different system settings, different length of fingerprint parameters is generated in this case. We test the time spent on registration phase and login phase while the length of the fingerprint is 128b, 256b, and 512b. The Android device used in this scenario is the Android simulator.Case 4.
The user uses different Android devices (Android emulator, Meizu mobile phone, and HTC mobile phone) for registering and logging in.We test the time spent on registration phase and login phase. We divide the total time of registration phaseK into two parts:k1 andk2 in this experiment. As shown in Figure 5,k1ms is the time spent on the registration phase starting from the user’s registration on the Android device to the end of the generation of authenticated key ciphertext.k2ms is the time spent on sending the authenticated key to the CS.Figure 5
Registration phase.The total time T ms of the login phase is divided into five parts. As shown in Figure6, t1 is the time spent on requesting the corresponding authentication key ciphertext from the user’s PC. t2+t4 is the time spent on blinding the user’s password and generating the authentication key. t3 is the time spent on signing the blinded password with fingerprint data on the Android device. t5 is the time spent on sending the user authentication information to the CS.Figure 6
Login phase.


### 6.2. Experiment Data

#### 6.2.1. Experiment Data of Case1

(I) Registration Phase. In this case, the user enters the user name, password, and fingerprint on the Android device for registration. The length of user’s fingerprint is 256b. As shown in Table 1, we measured 10 groups of data. We can calculate that the average registration time is 216.9ms through the following data.Table 1
Registration phase time of Case1.
Test Group
Registration Phase Time/ms
k1
k2
K
1
197
19
216
2
200
18
218
3
199
18
217
4
210
17
227
5
199
15
214
6
198
18
216
7
196
17
213
8
190
19
209
9
213
17
220
10
199
20
219(II) Login Registration. When the user logs in, he enters his password and fingerprint on the PC and Android emulator. We measured the time spent on each stage and then measured 10 groups of data showing in Table 2. We can calculate the average login time is 192.5 ms through these following data.Table 2
Login phase time of Case1.
Test Group
Login Phase Time/ms
t1
t3
t2+t4
t5
T
1
39
90
36
19
184
2
45
98
39
18
200
3
38
94
41
18
191
4
38
92
38
16
184
5
37
110
40
17
204
6
39
98
39
19
195
7
40
96
35
17
188
8
41
97
41
19
198
9
39
92
40
18
189
10
38
99
38
17
192


#### 6.2.2. Experiment Data of Case2

(I) Registration Phase. In this case, we test 20 groups of different users. The user inputs his name, password, and fingerprint on Android emulator for registration. We measure the time (k1, k2) spent during the registration phase. The complexity and length of the user name and password are different. The length of these users’ fingerprint is 256 bits. The measured result is shown in Table 3.Table 3
Registration phase time of Case2.
User
Registration Phase Time/ms
k1
k2
K
User1
222
15
237
User2
195
17
212
User3
271
17
288
User4
236
19
255
User5
243
20
263
User6
190
17
207
User7
220
18
238
User8
214
16
230
User9
195
21
216
User10
239
18
257
User11
197
16
213
User12
220
19
239
User13
230
18
248
User14
220
17
237
User15
200
18
218
User16
261
19
280
User17
199
16
215
User18
215
18
233
User19
250
19
269
User20
234
17
251(II) Login Phase. Users enter their password and fingerprint on the PC and Android devices. We measure the time spent on each stage. 20 groups of data are shown in Table 4.Table 4
Login phase time of Case2.
User
Login Phase Time/ms
t1
t3
t2+t4
t5
T
User1
45
88
36
17
186
User2
37
94
38
17
186
User3
37
93
41
15
186
User4
38
63
35
18
154
User5
37
90
41
20
188
User6
39
111
39
19
208
User7
37
93
42
17
189
User8
40
98
36
16
190
User9
39
90
38
21
188
User10
37
92
38
19
186
User11
38
94
42
17
191
User12
40
80
35
18
173
User13
37
98
36
19
190
User14
39
91
44
18
192
User15
36
89
36
19
180
User16
38
92
40
17
184
User17
37
100
39
20
196
User18
38
93
37
19
187
User19
39
92
40
17
188
User20
37
94
39
18
188


#### 6.2.3. Experiment Data of Case3

(I) Registration Phase. The user inputs his password on Android device, and then the Android device generates three kinds of fingerprint data with different length (512b, 256b, and 128b). We measure the time (k1, k2) spent during the registration phase. The measured result is shown in Table 5.Table 5
Registration phase time of Case3.
Length Of Fingerprint/b
Registration Phase Time/ms
k1
k2
K
512
210
19
229
256
205
18
223
128
192
18
220(II) Login Phase. The user inputs his password and fingerprint on PC and Android devices. We test the time spent during the login phase. The measured result is shown in Table 6.Table 6
Login phase time of Case3.
Length Of Fingerprint/b
Login Phase Time/ms
t1
t3
t2+t4
t5
T
512
39
100
39
18
196
256
39
98
38
18
193
128
38
95
38
17
186


#### 6.2.4. Experiment Data of Case4

(I) Registration Phase. In this case, there are three different Android devices (Android simulator, Meizu phone, and HTC phone). The user enters his password and fingerprint on different Android devices. We measure the time spent during this phase (k1, k2).(II) Login Phase. The user enters his password and fingerprint on PC and different Android devices. We test the time spent during the login phase. The measured result is shown in Table 8.


### 6.3. Performance Analysis

We can calculate the average time the user registered on the Android simulator is 216.9ms according to the Table1. The average time required for the user to log in using the Android emulator and PC is 192.5ms.As shown in Table3, when different users enter a different password to register, the difference between the longest and the shortest time is 81ms which is less than the human reaction time. Users cannot feel the difference in the length or complexity of passwords. Therefore, the length and complexity of the password have little impact on the user’s registration time. The comparison of the time spent by different users in the registration phase is shown in Figure 7.Figure 7
Registration phase experimental data of Case2.As shown in Table4, when different users enter their password to login, the difference between the longest and the shortest time is 54ms, which is less than the human reaction time. Therefore, the length and complexity of the password have little impact on the user’s login time. The comparison of the time spent during the login phase is shown in Figure 8.Figure 8
Login phase experimental data of Case2.When the length of the fingerprint is different, the maximum difference of the time among users during the registration phase is 9ms. The maximum difference of the time spent in the login phase is 10ms which has little effect on users. When the length of the fingerprint is 128b, 256b, and 512b, the comparison of the time spent in the registration phase and the login phase is shown in Figure9.Figure 9
Comparison of experimental data in two phases of Case3.In Case4, the user enters the same password and fingerprint on different Android devices. As shown in Tables 7 and 8, the total time spent on registering and logging in on mobile devices is less than the total time spent on the Android simulator. There is no difference in their transmission time. The main difference is the calculation time on Android devices. In the existing Mobile SPA scheme, the total time (26ms) spent in the registration phase is the transmission time and the computation time on the mobile terminal. The time spent on the two mobile phones in this paper is 37ms and 40ms. The difference of the time between them is small, so it has little effect on the performance of the scheme. In the SPA Mobile scheme, the time (38ms) spent in the login phase is the computation time on the server side, computing time on the mobile phone, and the transmission time. The total time of our scheme is 152ms and 151ms. Compared with the scheme of Mobile SPA, the time difference of our scheme is larger. However, our scheme has blind signature operation in the login phase and regeneration of the key operation and so on which greatly improve the security of the system. The time Users’ using different Android device in registration and login is shown in Figure 10.Table 7
Registration phase time of Case4.
Device
Registration Phase Time/ms
k1
k2
K
Bluestacks
200
17
217
MEIZU
18
19
37
HTC
19
21
40Table 8
Login phase time of Case4.
Device
Login Phase Time/ms
t1
t3
t2+t4
t5
T
Bluestacks
39
96
39
18
192
MEIZU
40
56
35
21
152
HTC
38
57
36
20
151Figure 10
Comparison of experimental data in two phases of Case4.We can see from above test scenarios that the running time of our scheme during the registration phase is k1; the running time of our scheme in the login phase is t3+t2+t4; the total running time of our scheme is k1+t3+t2+t4 called w. The propagation delay time between the computer and the mobile phone is brief, so we consider t3 as the running time in the Android device. We can calculate the total running time w according to the Case4. The comparison diagram of the time running in the distinct Android device is shown in Figure 11. We can see from Figure 11 that our scheme running in the Bluestacks costs the longest time. That is because there are some gaps in processor and set parameters between Bluestacks and Android mobile phone which influences the efficiency of our scheme.Figure 11
Comparison of the running time of different devices.In the storage capacity of mobile phones, the Mobile SPA scheme requires storing MAC key on the phone to authenticate with the CS. A server corresponds to a MAC key, while the length of a MAC key is 128 bytes. In our scheme, the mobile device only needs to store the user’s fingerprint data. The maximum length of fingerprint data is 512 bits (64 bytes). If the user registers 2000 servers, in the Mobile SPA scheme, the user requires 250kb storage capacity while the user requires 0.0625kb storage capacity in our FPPA scheme. Meanwhile, our scheme does not need to store data in the mobile phone for a long time.In conclusion, although our scheme has a significant increase in the login phase, the user has little effect on the use in terms of user experience. Meanwhile, our scheme adds the blind signature operation and regeneration of the key operation and so on which greatly improve the security of the system. What is more, our scheme only stores the user’s fingerprint in the mobile phone temporary. Because only a small amount information is stored in our scheme, the storage pressure of the mobile terminal is reduced. Therefore, our scheme has a high application value.


## 6.1. Test Plan and Scenario

We rented Ali CS to authenticate with the user in order to make the test scenario more close to the actual one. Ali CS deployed in Qingdao and the distance between Qingdao and Xi’an is 1058.6km.As shown in the Figure4, 1 describes that the mobile phone computes and generates authenticate keyy and authenticate key ciphertextv. And then the mobile phone sendsv to the CS in the end of registration phase. 2, 3, and 4 describe that the mobile phone and the PC compute and generate authenticate keyy to authenticate with CS in login phase.Figure 4
The overall test scenario.Android device, a PC and CS are used to simulate our scheme. We evaluate the usability of our scheme from the aspects of time and storage. We test the user’s registration and login time in four different scenarios. In terms of storage capacity, we mainly analyze and evaluate the storage capacity of the Android device. The experimental devices of our scheme are a PC, a CS, and an Android device. The specific parameters of the experimental devices are as follows:We use Ali CS located in Qingdao as the CS in our scheme. RAM of the CS is 1GB. It has a single-core processor. The operating system of it is windows Server 2008.We use HP Compad dx7408 MT DT PC as the computer in our scheme. It has a dual-core processor. RAM of the computer is 2GB. The operating system of it is windows 7(32 bits).We use Bluestacks (Android 4.1.2-API Level 16, CPU ARM (armeabi), RAM 512, VM Heap 16, Internal Storage 200MiB) and Android phone as the mobile phone in our scheme.We tested our scheme in 4 cases.Case 1.
The user registers and logs in, and then enters his password and fingerprint. We test the time spent on registration phase and login phase and then test several sets of data to find the average time for one user spent on registration and login phase. The Android device used in this scenario is the Android simulator.Case 2.
The length and complexity of passwords are different for different users. In order to analyze the influence of different passwords on our scheme, we select 20 groups of users. We test the time of these users spent on registration phase and login phase. The Android device used in this scenario is the Android simulator.Case 3.
Due to the different system settings, different length of fingerprint parameters is generated in this case. We test the time spent on registration phase and login phase while the length of the fingerprint is 128b, 256b, and 512b. The Android device used in this scenario is the Android simulator.Case 4.
The user uses different Android devices (Android emulator, Meizu mobile phone, and HTC mobile phone) for registering and logging in.We test the time spent on registration phase and login phase. We divide the total time of registration phaseK into two parts:k1 andk2 in this experiment. As shown in Figure 5,k1ms is the time spent on the registration phase starting from the user’s registration on the Android device to the end of the generation of authenticated key ciphertext.k2ms is the time spent on sending the authenticated key to the CS.Figure 5
Registration phase.The total time T ms of the login phase is divided into five parts. As shown in Figure6, t1 is the time spent on requesting the corresponding authentication key ciphertext from the user’s PC. t2+t4 is the time spent on blinding the user’s password and generating the authentication key. t3 is the time spent on signing the blinded password with fingerprint data on the Android device. t5 is the time spent on sending the user authentication information to the CS.Figure 6
Login phase.


## 6.2. Experiment Data

### 6.2.1. Experiment Data of Case1

(I) Registration Phase. In this case, the user enters the user name, password, and fingerprint on the Android device for registration. The length of user’s fingerprint is 256b. As shown in Table 1, we measured 10 groups of data. We can calculate that the average registration time is 216.9ms through the following data.Table 1
Registration phase time of Case1.
Test Group
Registration Phase Time/ms
k1
k2
K
1
197
19
216
2
200
18
218
3
199
18
217
4
210
17
227
5
199
15
214
6
198
18
216
7
196
17
213
8
190
19
209
9
213
17
220
10
199
20
219(II) Login Registration. When the user logs in, he enters his password and fingerprint on the PC and Android emulator. We measured the time spent on each stage and then measured 10 groups of data showing in Table 2. We can calculate the average login time is 192.5 ms through these following data.Table 2
Login phase time of Case1.
Test Group
Login Phase Time/ms
t1
t3
t2+t4
t5
T
1
39
90
36
19
184
2
45
98
39
18
200
3
38
94
41
18
191
4
38
92
38
16
184
5
37
110
40
17
204
6
39
98
39
19
195
7
40
96
35
17
188
8
41
97
41
19
198
9
39
92
40
18
189
10
38
99
38
17
192


### 6.2.2. Experiment Data of Case2

(I) Registration Phase. In this case, we test 20 groups of different users. The user inputs his name, password, and fingerprint on Android emulator for registration. We measure the time (k1, k2) spent during the registration phase. The complexity and length of the user name and password are different. The length of these users’ fingerprint is 256 bits. The measured result is shown in Table 3.Table 3
Registration phase time of Case2.
User
Registration Phase Time/ms
k1
k2
K
User1
222
15
237
User2
195
17
212
User3
271
17
288
User4
236
19
255
User5
243
20
263
User6
190
17
207
User7
220
18
238
User8
214
16
230
User9
195
21
216
User10
239
18
257
User11
197
16
213
User12
220
19
239
User13
230
18
248
User14
220
17
237
User15
200
18
218
User16
261
19
280
User17
199
16
215
User18
215
18
233
User19
250
19
269
User20
234
17
251(II) Login Phase. Users enter their password and fingerprint on the PC and Android devices. We measure the time spent on each stage. 20 groups of data are shown in Table 4.Table 4
Login phase time of Case2.
User
Login Phase Time/ms
t1
t3
t2+t4
t5
T
User1
45
88
36
17
186
User2
37
94
38
17
186
User3
37
93
41
15
186
User4
38
63
35
18
154
User5
37
90
41
20
188
User6
39
111
39
19
208
User7
37
93
42
17
189
User8
40
98
36
16
190
User9
39
90
38
21
188
User10
37
92
38
19
186
User11
38
94
42
17
191
User12
40
80
35
18
173
User13
37
98
36
19
190
User14
39
91
44
18
192
User15
36
89
36
19
180
User16
38
92
40
17
184
User17
37
100
39
20
196
User18
38
93
37
19
187
User19
39
92
40
17
188
User20
37
94
39
18
188


### 6.2.3. Experiment Data of Case3

(I) Registration Phase. The user inputs his password on Android device, and then the Android device generates three kinds of fingerprint data with different length (512b, 256b, and 128b). We measure the time (k1, k2) spent during the registration phase. The measured result is shown in Table 5.Table 5
Registration phase time of Case3.
Length Of Fingerprint/b
Registration Phase Time/ms
k1
k2
K
512
210
19
229
256
205
18
223
128
192
18
220(II) Login Phase. The user inputs his password and fingerprint on PC and Android devices. We test the time spent during the login phase. The measured result is shown in Table 6.Table 6
Login phase time of Case3.
Length Of Fingerprint/b
Login Phase Time/ms
t1
t3
t2+t4
t5
T
512
39
100
39
18
196
256
39
98
38
18
193
128
38
95
38
17
186


### 6.2.4. Experiment Data of Case4

(I) Registration Phase. In this case, there are three different Android devices (Android simulator, Meizu phone, and HTC phone). The user enters his password and fingerprint on different Android devices. We measure the time spent during this phase (k1, k2).(II) Login Phase. The user enters his password and fingerprint on PC and different Android devices. We test the time spent during the login phase. The measured result is shown in Table 8.


## 6.2.1. Experiment Data of Case1

(I) Registration Phase. In this case, the user enters the user name, password, and fingerprint on the Android device for registration. The length of user’s fingerprint is 256b. As shown in Table 1, we measured 10 groups of data. We can calculate that the average registration time is 216.9ms through the following data.Table 1
Registration phase time of Case1.
Test Group
Registration Phase Time/ms
k1
k2
K
1
197
19
216
2
200
18
218
3
199
18
217
4
210
17
227
5
199
15
214
6
198
18
216
7
196
17
213
8
190
19
209
9
213
17
220
10
199
20
219(II) Login Registration. When the user logs in, he enters his password and fingerprint on the PC and Android emulator. We measured the time spent on each stage and then measured 10 groups of data showing in Table 2. We can calculate the average login time is 192.5 ms through these following data.Table 2
Login phase time of Case1.
Test Group
Login Phase Time/ms
t1
t3
t2+t4
t5
T
1
39
90
36
19
184
2
45
98
39
18
200
3
38
94
41
18
191
4
38
92
38
16
184
5
37
110
40
17
204
6
39
98
39
19
195
7
40
96
35
17
188
8
41
97
41
19
198
9
39
92
40
18
189
10
38
99
38
17
192


## 6.2.2. Experiment Data of Case2

(I) Registration Phase. In this case, we test 20 groups of different users. The user inputs his name, password, and fingerprint on Android emulator for registration. We measure the time (k1, k2) spent during the registration phase. The complexity and length of the user name and password are different. The length of these users’ fingerprint is 256 bits. The measured result is shown in Table 3.Table 3
Registration phase time of Case2.
User
Registration Phase Time/ms
k1
k2
K
User1
222
15
237
User2
195
17
212
User3
271
17
288
User4
236
19
255
User5
243
20
263
User6
190
17
207
User7
220
18
238
User8
214
16
230
User9
195
21
216
User10
239
18
257
User11
197
16
213
User12
220
19
239
User13
230
18
248
User14
220
17
237
User15
200
18
218
User16
261
19
280
User17
199
16
215
User18
215
18
233
User19
250
19
269
User20
234
17
251(II) Login Phase. Users enter their password and fingerprint on the PC and Android devices. We measure the time spent on each stage. 20 groups of data are shown in Table 4.Table 4
Login phase time of Case2.
User
Login Phase Time/ms
t1
t3
t2+t4
t5
T
User1
45
88
36
17
186
User2
37
94
38
17
186
User3
37
93
41
15
186
User4
38
63
35
18
154
User5
37
90
41
20
188
User6
39
111
39
19
208
User7
37
93
42
17
189
User8
40
98
36
16
190
User9
39
90
38
21
188
User10
37
92
38
19
186
User11
38
94
42
17
191
User12
40
80
35
18
173
User13
37
98
36
19
190
User14
39
91
44
18
192
User15
36
89
36
19
180
User16
38
92
40
17
184
User17
37
100
39
20
196
User18
38
93
37
19
187
User19
39
92
40
17
188
User20
37
94
39
18
188


## 6.2.3. Experiment Data of Case3

(I) Registration Phase. The user inputs his password on Android device, and then the Android device generates three kinds of fingerprint data with different length (512b, 256b, and 128b). We measure the time (k1, k2) spent during the registration phase. The measured result is shown in Table 5.Table 5
Registration phase time of Case3.
Length Of Fingerprint/b
Registration Phase Time/ms
k1
k2
K
512
210
19
229
256
205
18
223
128
192
18
220(II) Login Phase. The user inputs his password and fingerprint on PC and Android devices. We test the time spent during the login phase. The measured result is shown in Table 6.Table 6
Login phase time of Case3.
Length Of Fingerprint/b
Login Phase Time/ms
t1
t3
t2+t4
t5
T
512
39
100
39
18
196
256
39
98
38
18
193
128
38
95
38
17
186


## 6.2.4. Experiment Data of Case4

(I) Registration Phase. In this case, there are three different Android devices (Android simulator, Meizu phone, and HTC phone). The user enters his password and fingerprint on different Android devices. We measure the time spent during this phase (k1, k2).(II) Login Phase. The user enters his password and fingerprint on PC and different Android devices. We test the time spent during the login phase. The measured result is shown in Table 8.


## 6.3. Performance Analysis

We can calculate the average time the user registered on the Android simulator is 216.9ms according to the Table1. The average time required for the user to log in using the Android emulator and PC is 192.5ms.As shown in Table3, when different users enter a different password to register, the difference between the longest and the shortest time is 81ms which is less than the human reaction time. Users cannot feel the difference in the length or complexity of passwords. Therefore, the length and complexity of the password have little impact on the user’s registration time. The comparison of the time spent by different users in the registration phase is shown in Figure 7.Figure 7
Registration phase experimental data of Case2.As shown in Table4, when different users enter their password to login, the difference between the longest and the shortest time is 54ms, which is less than the human reaction time. Therefore, the length and complexity of the password have little impact on the user’s login time. The comparison of the time spent during the login phase is shown in Figure 8.Figure 8
Login phase experimental data of Case2.When the length of the fingerprint is different, the maximum difference of the time among users during the registration phase is 9ms. The maximum difference of the time spent in the login phase is 10ms which has little effect on users. When the length of the fingerprint is 128b, 256b, and 512b, the comparison of the time spent in the registration phase and the login phase is shown in Figure9.Figure 9
Comparison of experimental data in two phases of Case3.In Case4, the user enters the same password and fingerprint on different Android devices. As shown in Tables 7 and 8, the total time spent on registering and logging in on mobile devices is less than the total time spent on the Android simulator. There is no difference in their transmission time. The main difference is the calculation time on Android devices. In the existing Mobile SPA scheme, the total time (26ms) spent in the registration phase is the transmission time and the computation time on the mobile terminal. The time spent on the two mobile phones in this paper is 37ms and 40ms. The difference of the time between them is small, so it has little effect on the performance of the scheme. In the SPA Mobile scheme, the time (38ms) spent in the login phase is the computation time on the server side, computing time on the mobile phone, and the transmission time. The total time of our scheme is 152ms and 151ms. Compared with the scheme of Mobile SPA, the time difference of our scheme is larger. However, our scheme has blind signature operation in the login phase and regeneration of the key operation and so on which greatly improve the security of the system. The time Users’ using different Android device in registration and login is shown in Figure 10.Table 7
Registration phase time of Case4.
Device
Registration Phase Time/ms
k1
k2
K
Bluestacks
200
17
217
MEIZU
18
19
37
HTC
19
21
40Table 8
Login phase time of Case4.
Device
Login Phase Time/ms
t1
t3
t2+t4
t5
T
Bluestacks
39
96
39
18
192
MEIZU
40
56
35
21
152
HTC
38
57
36
20
151Figure 10
Comparison of experimental data in two phases of Case4.We can see from above test scenarios that the running time of our scheme during the registration phase is k1; the running time of our scheme in the login phase is t3+t2+t4; the total running time of our scheme is k1+t3+t2+t4 called w. The propagation delay time between the computer and the mobile phone is brief, so we consider t3 as the running time in the Android device. We can calculate the total running time w according to the Case4. The comparison diagram of the time running in the distinct Android device is shown in Figure 11. We can see from Figure 11 that our scheme running in the Bluestacks costs the longest time. That is because there are some gaps in processor and set parameters between Bluestacks and Android mobile phone which influences the efficiency of our scheme.Figure 11
Comparison of the running time of different devices.In the storage capacity of mobile phones, the Mobile SPA scheme requires storing MAC key on the phone to authenticate with the CS. A server corresponds to a MAC key, while the length of a MAC key is 128 bytes. In our scheme, the mobile device only needs to store the user’s fingerprint data. The maximum length of fingerprint data is 512 bits (64 bytes). If the user registers 2000 servers, in the Mobile SPA scheme, the user requires 250kb storage capacity while the user requires 0.0625kb storage capacity in our FPPA scheme. Meanwhile, our scheme does not need to store data in the mobile phone for a long time.In conclusion, although our scheme has a significant increase in the login phase, the user has little effect on the use in terms of user experience. Meanwhile, our scheme adds the blind signature operation and regeneration of the key operation and so on which greatly improve the security of the system. What is more, our scheme only stores the user’s fingerprint in the mobile phone temporary. Because only a small amount information is stored in our scheme, the storage pressure of the mobile terminal is reduced. Therefore, our scheme has a high application value.


## 7. Summary

Passwords are widely deployed to secure users’ access to cloud services in IIOT. However, passwords are prone to dictionary attack and phishing. Therefore, protecting the user’s password when authenticating the user’s identity has become a widespread concern. In this paper, we use the mobile phone to assist user’s authentication. Specifically, we use both password and fingerprint to generate a secret key and then we use the secret key and HKDF function to generate the authentication key. Due to the characteristic of HKDF function, any adversary cannot get the key or password or decrypt the ciphertext through exhausting enumerating attacks. There is no user’s secret information on the mobile phone, so even if the mobile phone is lost, it will not pose a security risk to the user’s account. Finally, we prove the security of the scheme and evaluate the performance of our scheme. Results show that our scheme can resist dictionary attacks and attacks against the user’s mobile phone. Meanwhile, there is no significant difference between our scheme and the existing three party authentication schemes, in terms of performance. In addition, our scheme reduces the storage pressure on the mobile phone. Overall, our scheme has high practicality.



---

*Source: 1694702-2019-06-26.xml*