Introduction

The electronic-health (e-health) system, which greatly facilitates people’s life, is developing rapidly. Many applications, such as personal health records (PHRs) and Telecare Medical Information Systems (TMISs), have been developed to store medical records on the cloud and to diagnose patients remotely. TMISs, among the most popular applications of e-health systems, have received much attention from patients and doctors. In a basic TMIS, as shown in Fig. 1, some sensors are installed on the patient to collect medical data in a timely manner. These data are transferred to the medical server for storage and are used to build the patient’s records. Then, the doctor can make an accurate diagnosis on the basis of the records. By means of the TMIS, patients are also able to receive good medical care at home without having to frequently rush to a hospital. Moreover, TMISs save time for patients in addition to saving many lives because doctors are able to diagnose patients in time.

Fig. 1
figure 1

A basic medical application scenario of a TMIS

However, the users (including doctors, patients, and relatives) of TMISs usually have limited computing and storage capabilities. A TMIS where the users are responsible for expensive and time-consuming computations is unsuitable for practical applications. Therefore, it is critical to minimize the user’s operations in a TMIS.

In addition to the efficiency of the user side, privacy protection and security issues have become a major obstacle to the adoption of TMISs. Because of the openness of the Internet, adversaries can intercept and tamper with exchanged messages. As a result, TMISs face major challenges with respect to privacy protection and other security problems.

The consequences of leaking medical data are serious. Imagine that a famous entrepreneur, whose health condition has a large impact on his/her company’s market value, is accessing a TMIS to treat his/her disease at home. If an adversary (we will use \(\mathcal {A}\) to represent an adversary) intercepts the entrepreneur’s medical data, he/she is able to know the severity of the entrepreneur’s illness. Then, the adversary has the ability to reveal the illness to the media for financial gains. This scenario shows that privacy protection is a critical consideration in a TMIS. Imagine another case where an adversary tampers with the medical data transmitted from a patient. Then, the doctor could make a false diagnosis that will lead to a serious medical accident.

Two-factor authentication protocols have been proposed to solve the privacy leakage and security weakness issues in TMISs [5, 12, 27, 29]. In this type of protocol, a user utilizes a password and a smart card as the two authentication factors. In addition, the user and the server authenticate each other, and an identical session key is shared between the user and the server at the end of the protocol. However, problems remain in two-factor authentication schemes. First, passwords and smart cards are easily lost or stolen. Second, authorized users can share passwords and smart cards with unauthorized users, and the system is hard to stop. Additionally, Wang et al. [24] demonstrated that two-factor authentication protocols cannot protect user privacy without using asymmetric cryptography. Wang et al. [24] also reported that if the verification information of the user’s password is stored on the smart card, then the adversary can launch password guessing attacks and other attacks after extracting the data stored on the smart card via a side channel attack. However, authentication protocols using public key cryptography are not suitable for TMISs because of the expensive computing operations.

Biometrics have been introduced to solve the problems with two-factor authentication protocols. The combination of passwords, smart cards and biometrics can resist loss or theft of passwords and smart cards, so three-factor authentication schemes overcome some of the problems presented by two-factor authentication protocols. Therefore, many three-factor (i.e., password, smart card and biometrics) authentication protocols have been proposed [2, 20]. Some researchers built three-factor authentication protocols based on public key cryptography [11, 19, 26, 30, 31]. Although there is considerable improvement in security, these schemes use expensive computing operations are not suitable for users with limited computing power.

Another approach is to construct three-factor authentication protocols based on symmetric cryptography or hash functions [2, 6, 16,17,18, 21]. These protocols are efficient because they use only symmetric encryptions, hash functions, biohash functions and so forth. However, these three-factor authentication protocols face difficulties with protecting user privacy, including user’s biometrics [2, 6, 16,17,18].

Fan et al. [8] proposed the notion of the truly three-factor authentication protocol. They considered that some malicious users may not comply with the protocol and not validate passwords and biometrics. Therefore, the three factors of the users should be verified at the server side rather than at the user side. In their proposed truly three-factor authentication protocol, the server is able to verify the three factors of the user to reduce the problem of user imitation and improve the security of the protocol.

Several three-factor authentication protocols authenticating user’s factors in server side have been proposed [8, 32]. However, these protocols are either not secure [8] or not truly three-factor authentication protocols [32]. Thus, the challenge remains to propose a truly efficient and secure three-factor protocol for TMISs.

Our research contributions

In this paper, we propose a novel three-factor authentication scheme for TMISs. Our major research contributions are summarized as follows:

  1. 1.

    Truly three-factor authentication scheme for TMISs. The three factors (i.e., password, smart card and biometrics) are all authenticated at the server side in our scheme. In previous TMIS schemes, the server depends on the user to authenticate the three factors, which is a weak point of these schemes. By contrast, in our proposed scheme, the user’s password and biometric template are stored on the server’s table. The server checks whether the user’s password and biometrics are valid each time the user logs in. Moreover, the user also sends a dynamic identity stored on the smart card to the server so that the server can verify the user’s smart card. Therefore, our proposed scheme is the first truly three-factor authentication scheme for TMISs.

  2. 2.

    Strong privacy protection. In the proposed scheme, passwords and biometrics are stored on the server side and are protected by secure hash functions and random numbers. Thus, no one other than the user can obtain the user’s passwords and biometrics. In terms of anonymity and untraceability, our proposed protocol adopts a dynamic identity mechanism. The adversary is unable to obtain the user’s real identity and trace the user’s actions because of this dynamic mechanism.

  3. 3.

    Efficiency. Our proposed scheme is efficient since the scheme is mainly based on hash functions, symmetric cryptosystems and some other efficient operators.

  4. 4.

    Lightweight for users. The user’s operations are minimal in our proposed scheme. The user does not need to verify the three authentication factors (i.e., password, smart card and biometrics) and only needs to execute some lightweight operations, which increases the efficiency of the user side.

  5. 5.

    Change passwords and biometrics freely. In a truly three-factor authentication protocol, the password and biometric templates are stored at the server side instead of on the smart card, so it is difficult for users to change passwords and biometrics. By contrast, our proposed protocol is user-friendly, that is, users are able to change passwords and biometrics freely.

Organization of the paper

The remainder of this paper is organized as follows. In Related work, we review the related literature. Background and notation introduces background material, including the formal security model, TMIS security requirements, and notation used in the proposed protocol. The protocol and its security analysis are presented in The proposed protocol and Security analysis, respectively. In Security properties and performance analysis, we compare the performance of our scheme with that of related schemes. Conclusion concludes this paper.

Related work

Public key cryptography has been applied to the access control structure of e-health systems. Three-factor authentication protocols based on discrete logarithms [19] and chaotic mapping and bilinear pairings have been proposed [20, 23, 33]. Since elliptic curve cryptography (ECC) has advantages over other public key cryptosystems in terms of computation time and communication size, several ECC-based three-factor authentication protocols have also been proposed [25, 26, 31]. Although the security of three-factor authentication protocols based on public key cryptography is constantly improving [11], these protocols remain unsuitable for TMISs with limited computing power because power multiplication and point multiplication operations are time-consuming and unsuitable for resource-constrained environments, especially on the user side.

Authentication protocols mainly using lightweight computing operations, such as symmetric encryption and hash functions, were proposed to solve the problems of protocols based on public key cryptography. Li and Hwang [17] proposed an efficient three-factor authentication protocol using only hash functions. Li et al. [18], Das et al. [6] and An [2] also proposed such kind of key exchange scheme respectively. However, those protocols still have many security issues. For example, the protocol in Li and Hwang [17] was found to be unable to withstand man-in-the-middle attacks [18], and the protocol in [6] was found to be prone to insider attacks, password guessing attacks, and impersonation attacks [2].

Additionally, the protection of a user’s biometrics in three-factor authentication protocols is also a problem. Passwords can be changed, but the user’s biometrics are unique and cannot be altered. Once biometrics are leaked, the consequences are serious. Therefore, both efficiency and security should be considered in three-factor authentication schemes.

A variety of tools are available for managing biometrics in authentication protocols, such as fuzzy commitments [15], fuzzy vaults [13, 22], error-correcting [9], fuzzy extractors [7, 14], and biohash functions [32]. Among these tools, the biohash function has one-way properties similar to hash functions and can conveniently handle biometric errors. Therefore, biohash functions, which can take into account both efficiency and security, are considered to be suitable for managing biometrics.

Several three-factor authentication protocols based on biohash functions have recently been proposed [1, 4, 10, 21, 32]. Amongst them, Chaudhry et al. [4] reported that Mir et al.’s protocol [21] cannot resist stolen smart card attacks and that user anonymity violation attacks are still possible [21]. Chaudhry et al. [4] then proposed an improved protocol. Additionally, the protocol in [10], which combines biohash functions with public key cryptography, is a useful exploration for designing authentication protocols in TMISs.

Fan et al. [8] proposed the concept of the truly three-factor authentication protocol. They believed that the three factors should be verified at the server side rather than at the user side, which is potentially insecure for protocols since the traditional verification at the user side gives a high level of trust to the user. However, dishonest users may not authenticate these factors and directly communicate with the server. In this case, the server cannot determine whether he/she is communicating with an honest user and has no idea whether the verification at the user side is executed correctly. However, a truly three-factor authentication protocol is not easy to achieve. Verifying the three factors at the server side means that the user’s password and biometrics or related values must be stored at the server side. Therefore, it is difficult to ensure that the server does not know the user’s password and biometrics or related values. The scheme proposed by the authors had several disadvantages. For example, Yeh et al. [31] reported that Fan et al.’s scheme is unable to resist insider attacks.

Zhang et al. [32] recently proposed a three-factor authentication scheme with key agreement based on biohash functions. In their scheme, the user’s biometrics are verified at the server side, whereas the password and smart card are not. Thus, it is not a truly three-factor authentication scheme. Additionally, after receiving a login request from a user, the server has to determine whether there is a value W in the database that is equal to user’s message, which reduces the efficiency of their scheme. Additionally, Zhang et al.’s protocol [32] is not user-friendly because it does not provide a password and biometrics change service.

Background and notation

Security model

In this subsection, we extend previously reported security models [3, 28, 32] for three-factor authentication protocols. Our improved model defines a \(TestID(\cdot )\) oracle to capture the notion of user anonymity. In addition, we define a \(CorruptSC(\cdot )\) oracle to simulate stolen smart card attacks, and we define a \(CorruptDB(\cdot )\) oracle to simulate stolen verifier table attacks.

Participants

Two types of participants exist in protocol \(\mathcal {P}\), i.e., users \(U_{i} \in User\) and servers \(S_{j} \in Server\). \({U^{a}_{i}}\) (resp. \({S^{a}_{j}}\)) represents the \(a^{th}\) instance of \(U_{i}\) (resp. \(S_{j}\)). \(ac{c^{i}_{U}}\) is a Boolean variable that indicates whether \(U_{i}\) accepts. \(ac{c^{i}_{U}}= 1\) indicates that \(U_{i}\) accepts, and \(ac{c^{i}_{U}}= 0\) indicates that \(U_{i}\) rejects.

Partnering

In the protocol, the session identifier in each session is unique. If Ui and \(S_{j}\) share the same non-null session identifier, then \(U_{i}\) and \(S_{j}\) are partnered.

Adversary ability

To simulate a realistic adversary, the adversary can query the following oracles:

  • \(Execute ({U^{a}_{i}}, {S^{b}_{j}})\): This query simulates eavesdropping attacks, where an adversary obtains session messages between \({U^{a}_{i}}\) and \({S^{b}_{j}}\).

  • \(Hash (m, h(m)) \): In this query, the oracle searches for the existence of \((m, h(m))\) in the hash list. If it exists, the oracle returns \((m, h(m))\)) for the adversary; otherwise, the oracle selects a random string k to return to the adversary and then stores \((m, k)\) in the list.

  • \(Biohash (m, h_{Bio}(m)) \): In this query, the oracle compares m and \(m^{*}\), which is in the biohash list, to determine whether the difference between m and \(m^{*}\) is within a tolerable range. If yes, the oracle returns \(h_{Bio}(m)\) to the adversary; otherwise, the oracle selects a random string r for the adversary and stores \((m, r) \) in the list.

  • \(Send({U^{a}_{i}}/{S^{b}_{j}}, m)\): This query simulates active attacks, where an adversary can obtain the corresponding messages according to the execution of the protocol.

  • \(Reveal({U^{a}_{i}})\): This query simulates known session key attack, where an adversary obtains the session key held by \({U^{a}_{i}}\).

  • \(CorruptSC({U^{a}_{i}})\): This query simulates stolen smart card attacks, where the adversary obtains the information stored on the smart card.

  • \(CorruptDB({S^{b}_{j}})\): This query simulates stolen verifier table attacks, where the adversary is able to obtain information stored on the verifier table at the server side.

  • \(TestID({U^{a}_{i}})\): This query tests user anonymity and can only be asked for once. In this query, the oracle randomly tosses a coin b. If \(b = 1\), then the adversary obtains the user’s real identity. If \(b = 0\), then the adversary obtains a random element in the identity space.

  • \(Test({U^{a}_{i}}/{S^{b}_{j}})\): By throwing a coin b, this query captures the notion of the semantic security of the session key. When \(b = 1\), the adversary obtains the session key; when \(b = 0\), the adversary obtains a random string with the same bit length as the session key.

Freshness

\({U^{a}_{i}}\) is fresh if:

  1. 1.

    \(ac{c^{i}_{U}}\)= 1.

  2. 2.

    No \(Reveal({U^{a}_{i}}/{S^{b}_{j}})\) is queried by adversary \(\mathcal {A}\).

AKE Security (Semantic Security)

In the Test query, the adversary \(\mathcal {A}\) outputs his/her guess \(b^{\prime }\). If \(b^{\prime }=b\), then \(\mathcal {A}\) wins the game. The advantage for \(\mathcal {A}\) to break the protocol is defined as:

$$Adv^{ake}_{P}= 2Pr[b^{\prime}=b]-1. $$

We say that a protocol \(\mathcal {P}\) is AKE secure if \(Adv^{ake}_{P}\) is negligible.

Security requirements

A truly three-factor authentication scheme for TMISs should satisfy the following security requirements.

User anonymity::

To protect user privacy, the protocol should ensure the anonymity of all the users, i.e., an adversary should be unable to obtain the users’ real identities from the exchanged messages.

Untraceability::

To provide greater security for user privacy, the protocol should support untraceability, i.e., an adversary should be unable to track users’ behaviors from the exchanged messages.

Mutual authentication::

The protocol should support mutual authentication, i.e., the user \(U_{i}\) and the medical server S in a TMIS should be able to authenticate each other.

Session key agreement::

In the protocol, the user \(U_{i}\) and the medical server S should share an identical session key for further communication.

Known key security::

Even if the adversary obtains the current session key, he/she should be unable to know the previous session keys.

Perfect forward secrecy::

Even if the adversary obtains the long secret keys of the participants, he/she should not be able to acquire the current and previous session keys.

Three-factor secrecy::

To guarantee the security of a user’s private keys, the scheme should permit three-factor (i.e., password, smart card and biometrics) secrecy, i.e., an adversary should be unable to mimic a legal user even if he/she obtains any two of the three factors.

Biometrics protection::

The scheme should ensure that the user’s biometrics cannot be compromised.

Resistance to various attacks::

To maintain security in open networks, the scheme should resist stolen verifier attacks, privileged insider attacks, user impersonation attacks, server spoofing attacks, replay attacks, and de-synchronization attacks.

Notation

Table 1 presents the notation used in the proposed scheme.

Table 1 Notation

The proposed protocol

In this section, we present a concrete construction of the proposed protocol. Our proposed scheme consists of five phases, i.e., the registration, login, mutual authentication, password and biometrics update, and smart card revocation.

Registration phase

To become a legitimate user in the system, a new user registers with the medical server by performing the following three steps, as shown in Table 2.

  1. 1.

    User \(U_{i}\) selects \(ID_{i}\) and \(PW_{i}\) as his/her identity and password, respectively. Then, \(U_{i}\) collects his/her biometrics \(T_{i}\) at the sensor and generates a random nonce \(r_{1}\). Subsequently, \(U_{i}\) computes \(C_{1}=h(ID_{i}|| PW_{i}||h_{Bio}(T_{i}))\) and \(C_{2}=T_{i}\oplus h(PW_{i})\oplus r_{1}\). Then, \(U_{i}\) sends his/her registration request \(<ID_{i},C_{1},C_{2}>\) to the medical server S via a secure channel.

    Table 2 Registration phase of our scheme
  2. 2.

    Upon obtaining the registration request from \(U_{i}, S\) calculates \(M=h(h_{Bio}(C_{2})||x), Y=M\oplus C_{1}\), and \(ID=ID_{i}||ID_{sc}\). Then, S generates a random number \(N_{1}\) and computes \(DID_{1}=E_{x}(ID||N_{1})\). Subsequently, S stores \(\{ID, C_{2}\}\) in a database for further verification processes. S also embeds \(\{ID_{sc}, h(\cdot ), h_{Bio}(\cdot ), Y,DID_{1}\}\) into a smart card SC. Then, S delivers the smart card SC to \(U_{i}\) through a secure channel.

  3. 3.

    After receiving the smart card \(SC, U_{i}\) calculates \(Z=r_{1}\oplus h_{Bio}(T_{i})\oplus h(PW_{i})\) and writes Z into the smart card SC. Finally, the smart card SC contains parameters \(\{ID_{sc}, h(\cdot ), h_{Bio}(\cdot ), Y, DID_{1}, Z\}\).

Login phase

If \(U_{i}\) wants to access services provided by the medical server S, he/she needs to perform the following steps to login to S. Table 3 shows details of the user login process.

  1. 1.

    The user \(U_{i}\) inputs \(ID_{i}, PW_{i}\), and his biometric information \(B_{i}\) into the terminal device. \(U_{i}\) then inserts the smart card into the terminal card reader.

  2. 2.

    The smart card computes \(C_{1}^{*}=h(ID_{i}||PW_{i}||h_{Bio} (B_{i})), M^{*}=Y\oplus h\left (C_{1}^{*}\right )\), and \(r^{*}_{1}=Z\oplus h_{Bio}(B_{i})\oplus h(PW_{i})\).

  3. 3.

    For the login request message, the smart card generates a random nonce \(r_{2}\) and calculates \(C_{3}=r_{2}\oplus h_{Bio}(B_{i}\oplus h(PW_{i})\oplus r^{*}_{1})\) and \(C_{4}=B_{i}\oplus h(PW_{i})\oplus r^{*}_{1}\oplus h(M^{*}||r_{2})\). Then, \(U_{i}\) sends \(m_{1}=<DID_{1},C_{3},C_{4}>\) to the medical server S.

Table 3 Login phase of our scheme

Mutual authentication phase

In this phase, \(U_{i}\) and S authenticate each other and then negotiate a session key for the next communication. Table 4 shows details of the mutual authentication process between a user and a medical server.

  1. 1.

    After receiving the login request from \(U_{i}, S\) decrypts \(DID_{1}\) to obtain \(ID^{\prime }||N^{\prime }_{1}\). Then, S checks whether \(ID^{\prime }\) is in the database to verify the validation of \(U_{i}\). If \(ID^{\prime }\) is valid, S retrieves \(C_{2}\) to compute \(M^{\prime }=h(h_{Bio}(C_{2})||x), r^{\prime }_{2}=C_{3}\oplus h_{Bio}(C_{2})\), and \((B_{i}\oplus h(PW_{i})\oplus r_{1})^{\prime }=C_{4}\oplus h(M^{\prime }||r^{\prime }_{2})\). Subsequently, S checks whether the difference between \((B_{i}\oplus h(PW_{i})\oplus r_{1})^{\prime }\) and \(C_{2}\) is less than a bearable threshold [32][33]. If it is not, S terminates the session; otherwise, S authenticates \(U_{i}\) and continues to the next step.

  2. 2.

    S generates a random nonce \(N_{2}\) and calculates \(DID_{2}=E_{x}(ID||N_{2})\). Then, S chooses another random nonce \(r_{3}\) and computes \(C_{5}=(r_{3}||DID_{2})\oplus h((B_{i}\oplus h(PW_{i})\oplus r_{1})^{\prime }), SK_{su}=h(M^{\prime }||r^{\prime }_{2}||r_{3})\), and \(Auth_{1}=h((B_{i}\oplus h(PW_{i})\oplus r_{1})^{\prime }||SK_{su}||r^{\prime }_{2}||r_{3})\) (we assume that the output of \(h((B_{i}\oplus h(PW_{i})\oplus r_{1})^{\prime })\) has the same bit length with \((r_{3}||DID_{2})\). And \(h(\cdot )\) in the protocol represents a family of hash functions, so its output length could be different). Subsequently, S sends \(m_{2}=<C_{5}, Auth_{1}>\) to \(U_{i}\).

  3. 3.

    After obtaining message \(m_{2}\) from \(S, U_{i}\) computes \(r_{3}^{*}||DID_{2}^{*}=C_{5}\oplus h(B_{i}\oplus h(PW_{i})\oplus r_{1}^{*})\) and \(SK_{us}=h(M^{*}||r_{2}||r^{*}_{3})\). Then, \(U_{i}\) verifies whether \(Auth_{1}\) is equal to \(h(B_{i}\oplus h(PW_{i})\oplus r_{1}^{*}||SK_{us}||r_{2}||r^{*}_{3})\). If this verification does not hold, \(U_{i}\) aborts the session; otherwise, \(U_{i}\) authenticates the medical server S. \(U_{i}\) also accepts the session key \(SK_{us}\) and the dynamic identity \(DID_{2}^{*}\) for the next login. Then, \(U_{i}\) computes \(Auth_{2}=h(ID||(B_{i}\oplus h(PW_{i})\oplus r^{*}_{1})||SK_{us}||r_{2}||r^{*}_{3})\) and launches \(m_{3}=<Auth_{2}>\) to S.

  4. 4.

    Upon receiving message \(m_{3}\) from \(U_{i}, S\) verifies whether \(Auth_{2}\) is equal to \(h(ID||(B_{i}\oplus h(PW_{i})\oplus r_{1})^{\prime }||SK_{su}||r^{\prime }_{2}||r_{3})\). If this verification condition does not hold, S aborts the session; otherwise, S ensures that message \(m_{3}\) comes from \(U_{i}\). Finally, S accepts the session key \(SK_{su}\).

Table 4 Mutual authentication phase of our scheme

Remark 1

DID1 and IDsc are two variables embedded into the user’s smart card by the server. When the user logs in, the server’s verification of DID1 represents the server’s authentication of the user’s smart card. Without DID1, the server would not consider the login request to be a valid login request message from Ui. Moreover, the server’s verification of Auth2, which contains IDsc, also indicates the server’s authentication of the user’s smart card.

In our proposed protocol, the server simultaneously, rather than separately, authenticates both the user’s passwords and biometrics. If the difference between \((B_{i}\oplus h(PW_{i})\oplus r_{1})^{\prime }\) and C2 is less than an acceptable threshold, the server accepts the passwords and biometrics contained in the login message sent by the user.

Passwords and biometrics update phase

A user \(U_{i}\) is able to update his/her passwords and biometrics during this phase, which is conducted with the help of the medical server since the password and biometrics template is stored at the server side.

  1. 1.

    First, \(U_{i}\) inserts the smart card SC into the card reader of the terminal device. Then, \(U_{i}\) enters \(ID_{i}, PW_{i}\), and \(B_{i1}\) on the terminal device. \(U_{i}\) also inputs new password \(PW^{new}_{i}\) and new biometrics \(B_{i2}\) to replace the original password and biometrics stored at the server side.

  2. 2.

    The smart card SC calculates \(C_{1}^{**}=h(ID_{i}||PW_{i}|| h_{Bio}(B_{i1})), M^{**}=Y\oplus h\left (C_{1}^{**}\right )\), and \(r^{**}_{1}=Z\oplus h_{Bio}(B_{i1})\oplus h(PW_{i})\).

  3. 3.

    For the update message, the smart card SC chooses a random number \(r_{4}\) and computes \(C_{6}=r_{4}\oplus h_{Bio}(B_{i1}\oplus h(PW_{i})\oplus r^{**}_{1}), C_{7}=B_{i1}\oplus h(PW_{i})\oplus r^{**}_{1}\oplus h(M^{**}||r_{4})\), and \(C_{8}=B_{i2}\oplus h(PW^{new}_{i})\oplus r^{**}_{1}\oplus h(M^{**}||r_{4})\). Then, \(U_{i}\) sends \(<DID_{2},C_{6},C_{7},,C_{8}>\) to S.

  4. 4.

    After obtaining the update message from \(U_{i}, S\) computes \(D_{x}(DID_{2})=ID^{\prime \prime }||N^{\prime }_{2}\). Then, S checks whether \(ID^{\prime \prime }\) is in the database to verify the validity of \(U_{i}\). If \(ID^{\prime \prime }\) is valid, S retrieves \(C_{2}\) to calculate \(M^{\prime \prime }=h(h_{Bio}(C_{2})||x), r^{\prime }_{4}=C_{6}\oplus h_{Bio}(C_{2}), (B_{i1}\oplus h(PW_{i})\oplus r_{1})^{\prime }=C_{7}\oplus h(M^{\prime \prime }||r^{\prime }_{4})\), and \((B_{i2}\oplus h(PW^{new}_{i})\oplus r_{1})^{\prime }=C_{8}\oplus h(M^{\prime \prime }||r^{\prime }_{4})\). Subsequently, S checks whether the difference between \((B_{i1}\oplus h(PW_{i})\oplus r_{1})^{\prime }\) and \(C_{2}\) is less than an acceptable threshold [32][33]. If it is not, S aborts the update request; otherwise, it proceeds to the next step.

  5. 5.

    S selects a random number \(N_{3}\) and computes \(DID_{3}=E_{x}(ID||N_{3})\). Then, S generates another random number \(r_{5}\) and calculates \(C_{9}=(r_{5}||DID_{3})\oplus h((B_{i2}\oplus h(PW^{new}_{i})\oplus r_{1})^{\prime })\) and \(Auth_{3}=h((B_{i2}\oplus h(PW^{new}_{i})\oplus r_{1})^{\prime }||r^{\prime }_{4}||r_{5})\) (we assume that the output of \(h((B_{i2}\oplus h(PW^{new}_{i})\oplus r_{1})^{\prime })\) has the same bit length with \((r_{5}||DID_{3})\) as above). Subsequently, S sends \(<C_{9}, Auth_{3}>\) to \(U_{i}\).

  6. 6.

    Upon obtaining the message \(<C_{9}, Auth_{3}>\) from \(S, U_{i}\) calculates \(r_{5}^{*}||DID_{3}^{*}=C_{9}\oplus h(B_{i2}\oplus h(PW^{new}_{i})\oplus r_{1}^{**})\). Then, \(U_{i}\) verifies whether \(Auth_{3}\) is equal to \(h(B_{i2}\oplus h(PW^{new}_{i})\oplus r_{1}^{**}||r_{4}||r^{*}_{5})\). If this verification condition does not hold, \(U_{i}\) terminates the update request; otherwise, \(U_{i}\) calculates \(Auth_{4}=h(ID|| (B_{i2}\oplus h(PW^{new}_{i})\oplus r^{**}_{1})||r_{4}||r^{*}_{5})\) and sends \(<Auth_{4}>\) to S.

  7. 7.

    After receiving \(<Auth_{4}>\) from \(U_{i}, S\) verifies whether \(Auth_{4}\) is equal to \(h(ID||(B_{i2}\oplus h(PW^{new}_{i})\oplus r_{1})^{\prime }||r^{\prime }_{4}||r_{5})\). If this verification condition does not hold, S terminates the update request; otherwise, S assures that the message \(<Auth_{4}>\) comes from the user \(U_{i}\) and then replaces \(C_{2}\) with \((B_{i2}\oplus h(PW^{new}_{i})\oplus r_{1})^{\prime }\) for further verification of \(U_{i}\), which completes the password and biometrics update phase.

Smart card revocation

If \(U_{i}\) loses his/her smart card, he/she can use their \(ID_{i}\) to apply to the server for a new smart card. This phase is the same as the user registration phase. The user utilizes the same \(ID_{i}\) as before, and selects new passwords \(PW_{i}\), new biometrics \(T_{i}\), and new random number \(r_{1}\), to calculate \(C_{1}=h(ID_{i}||PW_{i}||h_{Bio}(T_{i}))\) and \(C_{2}=T_{i}\oplus h(PW_{i})\oplus r_{1}\). Then, the user sends registration request \(<ID_{i},C_{1},C_{2}>\) to the medical server S via a secure channel. The subsequent steps are the same as those in the registration phase. When issuing a new smart card to the user, the server also changes the value of \(C_{2}\) corresponding to the \(ID_{i}\) in the database. Therefore, even if an adversary uses the lost smart card to login, he/she cannot be authenticated by the server.

Security analysis

Formal security proof

Theorem 1

Assume that \(\mathcal {A}\) executes \(Execute\) queries \(q_{exe}\) times, \(Send\) queries \(q_{send}\) times, \(Hash\) queries \(q_{h}\) times, and \(Biohash\) queries \(q_{b}\)times to breach the AKE security of the protocol. Let \(|H_{1}|, |H_{b}|\), and \(|T|\) represent the distribution space of the hash function, the distribution space of the biohash function, and the number of items in the server’s table, respectively. \(q_{t}\) denotes the number of \(\mathcal {A}\)’s guessing attempt towards the server. Let \(D_{P}\) and \(D_{B}\)represent the distribution spaces of user’s password and biometrics, respectively. \(|D_{P}|\) and \(|D_{B}|\) represent the size of \(D_{P}\) and \(D_{B}\), respectively, and \(|D_{B}|\) is much larger than \(|D_{P}|\). n represents the total number of times that a user might log in, and the server’s secret key x has length of l bits. In addition, \(Adv_{E_{x}}^{SE}(t)\) represents the advantage for the adversary to break the symmetric encryption in time t. Then, we have

$$\begin{array}{@{}rcl@{}} Adv^{ake}_{P}(\mathcal {A})\!&\leq&\! 2Adv_{E_{x}}^{SE}(t)\!+\frac{{q^{2}_{h}}}{|H_{1}|} + \frac{{q^{2}_{b}}}{|H_{b}|} + \frac{\left( q_{send} + q_{exe}\right)^{2}}{n}\\ &&+\frac{2q_{send}}{n}+max\{\frac{2q_{send}}{|D_{P}||D_{B}|}, \frac{q_{t}}{2^{l-1}\cdot |T|}\}. \end{array} $$

Proof

We create a series of games defined as \(G_{i} (0\leq i \leq 4)\) to show that the proposed protocol is provably secure. In each game \(G_{i}, Suc_{i}\) denotes the event that \(\mathcal {A}\) guesses b correctly in the \(Test\) query.

GameG0::

\(G_{0}\) is real attacks in the random oracle model. Thus, we have

$$ Adv^{ake}_{P}(\mathcal {A})= 2Pr[Suc_{0}]-1. $$
(1)
GameG1::

In this game, we simulate \(Hash\) oracles and \(Biohash\) oracles by maintaining the hash lists. The other oracles, including \(Execute, Send, Reveal, CorruptSC, CorruptDB, TestID\), and \(Test\), are the same as those in the original attacks. If the adversary makes the correct judgement in the \(TestID\) query, then the adversary can break the symmetric encryption with the same probability. Thus, we have

$$ Pr[Suc_{1}]-Pr[Suc_{0}]\leq Adv_{E_{x}}^{SE}(t). $$
(2)
GameG2::

\(G_{2}\) is the same as the previous game except that the game is terminated if the message transcripts and hash queries have collisions. The probability of collisions on message transcripts is \(\frac {(q_{send}+q_{exe})^{2}}{2n}\), and the probability of collisions on hash queries is \(\frac {{q^{2}_{h}}}{2|H_{1}|}+\frac {{q^{2}_{b}}}{2|H_{b}|}\), according to the birthday paradox. Therefore, we have

$$ Pr[Suc_{2}]-Pr[Suc_{1}]\leq \frac{{q^{2}_{h}}}{2|H_{1}|}+\frac{{q^{2}_{b}}}{2|H_{b}|} +\frac{(q_{send} + q_{exe})^{2}}{2n}. $$
(3)
GameG3::

\(G_{3}\) is the same as the previous game, but it is rejected if \(\mathcal {A}\) guesses \(Auth_{i}, Auth_{j}\), and \(Auth\) without querying the corresponding \(Hash\) oracle \(h(\cdot )\). Hence, we obtain

$$ Pr[Suc_{3}]-Pr[Suc_{2}]\leq \frac{q_{send}}{n}. $$
(4)
GameG4::

In this game, \(\mathcal {A}\) queries the \(CorruptSC\) oracle or \(CorruptDB\) oracle. Thus, the following two cases exist:

Case1::

In this case, \(\mathcal {A}\) queries \(CorruptSC\) and obtains parameters stored on the smart card. Then, \(\mathcal {A}\) launches dictionary attacks with possible passwords and biometrics. Thus, we obtain:

$$ Pr[Suc_{4}]-Pr[Suc_{3}]\leq \frac{q_{send}}{|D_{P}||D_{B}|}. $$
(5)
Case2::

In this case, \(\mathcal {A}\) queries \(CorruptDB\) and then obtains parameters stored in the verifier table. After receiving the table \(\{ID, C_{2}\}, \mathcal {A}\) tries all \(C_{2}\) to launch an online dictionary attack through computing \(M^{\prime }=h(h_{Bio}(C_{2})||x)\) and \(C_{4}=C_{2}\oplus h(M^{\prime }||r^{\prime }_{2})\), where \(r^{\prime }_{2}\) is random nonce. \(\mathcal {A}\) obtains \(C_{3}\) through the Biohash oracle, and \(\mathcal {A}\) also queries \(Send(S, \{DID_{1}, C_{3}, C_{4}\})\). \(\mathcal {A}\) then uses an l-bit random value to replace the server’s secret key x. Therefore, we have:

$$ Pr[Suc_{4}]-Pr[Suc_{3}]\leq \frac{q_{t}}{2^{l}\cdot |T|}. $$
(6)

Since \(\mathcal {A}\) is unable to query \(CorruptSC\) and \(CorruptDB\) simultaneously, \(\mathcal {A}\) can choose case 1 or case 2 as the final game \(G_{3}\). In \(G_{3}, \mathcal {A}\) queries the \(Test\) oracle and guesses b. Thus, we have:

$$ Pr[Suc_{3}]=\frac{1}{2}. $$
(7)

If \(\mathcal {A}\) chooses case 1, from Eqs. 12345 and 7, we obtain:

$$\begin{array}{@{}rcl@{}} Adv^{ake}_{P}(\mathcal {A})\!&\leq&\! 2Adv_{E_{x}}^{SE}(t)\!+\frac{{q^{2}_{h}}}{|H_{1}|} + \frac{{q^{2}_{b}}}{|H_{b}|} \!+\frac{(q_{send}\!+q_{exe})^{2}}{n}\\ &&+\frac{2q_{send}}{n}+\frac{2q_{send}}{|D_{P}||D_{B}|}. \end{array} $$

If \(\mathcal {A}\) chooses case 2, from Eqs. 12346 and 7, we obtain:

$$\begin{array}{@{}rcl@{}} Adv^{ake}_{P}(\mathcal {A})\!&\leq&\! 2Adv_{E_{x}}^{SE}(t) + \frac{{q^{2}_{h}}}{|H_{1}|} + \frac{{q^{2}_{b}}}{|H_{b}|} + \frac{(q_{send}+q_{exe})^{2}}{n}\\ &&+\frac{2q_{send}}{n}+\frac{q_{t}}{2^{l-1}\cdot |T|}. \end{array} $$

Therefore, we have:

$$\begin{array}{@{}rcl@{}} Adv^{ake}_{P}(\mathcal {A})\!&\leq&\! 2Adv_{E_{x}}^{SE}(t) + \frac{{q^{2}_{h}}}{|H_{1}|} + \frac{{q^{2}_{b}}}{|H_{b}|} + \frac{(q_{send}+q_{exe})^{2}}{n}\\ &&+\frac{2q_{send}}{n}\!+max\{\frac{2q_{send}}{|D_{P}||D_{B}|}, \frac{q_{t}}{2^{l-1}\cdot |T|}\}. \end{array} $$
(8)

Theorem 1 is proven by Eq. 8.

Analysis of security requirements

In this subsection, we will demonstrate that the proposed protocol satisfies all the security requirements listed in Section 2.

User anonymity :

: In the protocol, \(U_{i}\)’s identity \(ID_{i}\) is included in \(DID_{1}\), where \(DID_{1}=E_{x}(ID||N_{1})\). The adversary is unable to obtain the real identity \(ID_{i}\) from the intercepted information. Therefore, our scheme provides user anonymity.

Untraceability :

: In the protocol, the login request message \(<DID_{1},C_{3},C_{4}>\) is different each time. \(U_{i}\) receives a different \(DID_{x}\) for each login, and \(U_{i}\) generates a random nonce to compute \(C_{3}\) and \(C_{4}\) each time. Moreover, \(Auth_{2}\) is a random hash string in each execution of the protocol. Thus, \(\mathcal A\) is unable to trace a user’s actions from the public messages. Therefore, our protocol provides untraceability for users.

Mutual authentication::

In the proposed protocol, only the user with the correct \(DID_{x}\) can be authenticated by S. Moreover, only the medical server with the right secret value x can handle the login request message and respond with right challenge message \(<C_{5}, Auth_{1}>\). Therefore, our proposed scheme provides mutual authentication.

Session key agreement::

In the proposed protocol, \(U_{i}\) computes the session key \(SK_{us}=h(M^{*}||r_{2}||r^{*}_{3})\), and S calculates the session key \(SK_{su}=h(M^{\prime }||r^{*}_{2}||r_{3})\). Hence, \(U_{i}\) and S share an identical session key \(SK_{us}=SK_{su}\). Therefore, our proposed protocol provides session key agreement.

Known key security::

In the proposed scheme, \(U_{i}\) and S share the session key \(SK_{us}=SK_{su}=h(M^{*}||r_{2}||r^{*}_{3})\) at the end of the mutual authentication scheme. To compute the session key, \(U_{i}\) chooses a random number \(r_{2}\), and S chooses a random number \(r_{3}\). These numbers are random and different each time. Thus, even if \(\mathcal A\) obtains a session key, he/she still does not know the other session keys. Therefore, our proposed scheme provides known key security.

Perfect forward secrecy::

In the proposed scheme, even if \(\mathcal A\) obtains the medical server’s secret value x, he/she still does not have M to compute the session key \(SK_{us}=SK_{su}=h(M^{*}||r_{2}||r^{*}_{3})\). Additionally, \(\mathcal A\) also cannot obtain \(r_{2}\) and \(r_{3}\) to compute the session key. Therefore, our proposed scheme provides perfect forward secrecy.

Three-factor secrecy::

Three-factor secrecy means that even if \(\mathcal A\) obtains any two of the three factors, he/she still cannot mimic a legal user. To generate a correct login request message as a valid user, \(\mathcal A\) has to compute \(C_{4}=B_{i}\oplus h(PW_{i})\oplus r^{*}_{1}\oplus h(M^{*}||r_{2})\). Here, we demonstrate that even if \(\mathcal A\) acquires any two of the three factors, he/she still cannot obtain M to compute \(C_{4}\), which is an essential part of the login request message.

Case1::

In this case, we assume that \(\mathcal A\) obtains \(U_{i}\)’s password and smart card. To compute \(M^{*}=Y\oplus h(C_{1}^{*}), \mathcal A\) needs to obtain \(C_{1}^{*}\). However, without \(B_{i}, \mathcal A\) is unable to calculate \(C_{1}^{*}=h(ID_{i}||PW_{i}||h_{Bio}(B_{i}))\). Thus, in this case, \(\mathcal A\) cannot successfully forge a login request message.

Case2::

In this case, we assume that \(\mathcal A\) obtains \(U_{i}\)’s password and biometrics. To compute \(M^{*}=Y\oplus h(C_{1}^{*}), \mathcal A\) needs to obtain Y. However, without the smart card, \(\mathcal A\) is unable to acquire Y, which is stored on the smart card. Thus, in this case, \(\mathcal A\) cannot successfully mimic a legal user to forge a login request message.

Case3::

In this case, we assume that \(\mathcal A\) obtains \(U_{i}\)’s biometrics and smart card. To calculate \(M^{*}=Y\oplus h(C_{1}^{*}), \mathcal A\) needs to acquire \(C_{1}^{*}\). However, without \(PW_{i}, \mathcal A\) is unable to calculate \(C_{1}^{*}=h(ID_{i}||PW_{i}||h_{Bio}(B_{i}))\). Thus, in this case, \(\mathcal A\) cannot successfully forge a login request message.

These three cases demonstrate that our scheme provides three-factor secrecy.

Biometrics protection::

In the proposed scheme, we guarantee that biometrics are possessed only by the user himself and that \(\mathcal A\) cannot obtain the user’s biometrics. On the user side, \(Z=r_{1}\oplus h_{Bio}(T_{i})\oplus h(PW_{i})\) is stored on the smart card. The biometric template \(T_{i}\) is protected by secure hash functions and random number \(r_{1}\). Thus, \(\mathcal A\) is unable to obtain the user’s biometric template \(T_{i}\). On the server side, \(C_{2}=T_{i}\oplus h(PW_{i})\oplus r_{1}\) is stored in the server’s database. The biometric template \(T_{i}\) is also protected by secure hash functions and random number \(r_{1}\). Hence, \(\mathcal A\) cannot obtain the user’s biometric template \(T_{i}\) at the server side. Therefore, our protocol provides biometrics protection.

Resistance to stolen verifier attacks::

In the proposed scheme, ID and \(C_{2}\) are stored on the verifier. If the verifier is stolen by \(\mathcal A,\mathcal A\) still cannot successfully launch attacks. \(\mathcal A\) is unable to trace a user’s actions with only ID. Moreover, \(\mathcal A\) is unable to mimic a medical server with only \(C_{2}\). Additionally, \(\mathcal A\) cannot obtain the user’s biometric template \(T_{i}\) from \(C_{2}=T_{i}\oplus h(PW_{i})\oplus r_{1}\), as demonstrated above. Therefore, our proposed scheme is resistant to stolen verifier attacks.

Resistance to privileged insider attacks::

In authentication schemes, the privileged insider may somehow obtain \(ID_{i} ,C_{1}, ID\), and \(C_{2}\). With \(ID_{i}\) and \(C_{1}, \mathcal A\) can do nothing. We have demonstrate that even if \(\mathcal A\) acquires ID and \(C_{2}\), the scheme is still secure. Therefore, our proposed scheme is able to resist privileged insider attacks.

Resistance to user impersonation attacks::

To mimic a legal user, \(\mathcal A\) needs to calculate \(C_{4}=B_{i}\oplus h(PW_{i})\oplus r^{*}_{1}\oplus h(M^{*}||r_{2})\). We have demonstrated that even if \(\mathcal A\) obtains any two of the three factors, he/she still cannot compute \(C_{4}\) to forge a correct login request message to mimic a user. Therefore, our proposed scheme is free from user impersonation attacks.

Resistance to server spoofing attacks::

In the proposed scheme, S has its own secret key x to handle the login request message and generate a correct challenge message. \(\mathcal A\) is unable to mimic a legal medical server without the secret key x. Hence, our proposed scheme is free from server spoofing attacks.

Resistance to replay attacks::

In the proposed scheme, the messages exchanged between \(U_{i}\) and S are different each time because of the random numbers. If an adversary sends a previously used message to a participant in the protocol, the participant can check its validity. Therefore, our proposed scheme is free from replay attacks.

Resistance to de-synchronization attacks::

In the proposed scheme, after computing the session key, S sends \(DID_{2}\), which is included in the challenge message, to \(U_{i}\). If the challenge message is blocked and \(U_{i}\) does not receive \(DID_{2}\) within a given time, \(U_{i}\) will still use \(DID_{1}\) for login, which is permitted by S (in this case, \(C_{3}\) and \(C_{4}\) should be different each time to resist replay attacks). Therefore, our proposed scheme is free from de-synchronization attacks.

Security properties and performance analysis

In this section, we compare our scheme with related three-factor authentication schemes [18, 26, 32] in terms of security performance, computational complexity, and communication complexity.

Comparison of security properties

Table 5 shows the security performance comparison of our scheme and related schemes, i.e., Li et al.’s scheme [18], Wu et al.’s scheme [26], and Zhang et al.’s scheme [32]. In Table 5, Y stands for yes, indicating that the protocol provides the security property or can resist the attack; N stands for no, indicating that the protocol does not provide the security property or cannot resist the attack; and – indicates that the protocol does not provide the corresponding security property.

Table 5 Comparison of security properties

As shown in the table, Li et al.’s protocol [18] does not provide user anonymity or traceability and thus does not protect user privacy. Wu et al.’s scheme [26] does not provide three-factor secrecy and cannot resist user impersonation attacks. In Zhang et al.’s protocol [32], users cannot freely update passwords and biometrics. Only our proposed protocol meets all the security requirements and is a truly three-factor authentication scheme.

Comparison of computational complexity

We evaluate the computational complexity of the proposed scheme and compare it with that of the schemes in [18, 26, 32] based on the experimental data in [30].

The program in [30] is executed on a computer with a 2.1 GHz Intel(R) Core(TM) 2T6570 CPU, 4 GB RAM, and a 32-bit system. The software used includes Visual C++ and the MIRACL library. The evaluation involves hash function, biohash function, symmetric encryption, and elliptic scalar multiplication operations. The actual runtime for these operations is presented in Table 6. We denote \(T_{h}, T_{bh}, T_{s}\), and \(T_{smul}\) as the time cost for a hash function, the time cost for a biohash function, the time cost for a symmetric encryption/decryption, and the time cost for a scalar multiplication, respectively.

Table 6 Runtime of related operations

The total computational time, including both the user side and the server side, is \(11T_{h}\approx 0.0044 ms\) in the login and mutual authentication phases of Li et al.’s protocol [18]. The total computational time, including both the user side and the server side, is \(12T_{h}+ 4T_{smul}+ 4T_{s}\approx 29.9376 ms\) in the login and mutual authentication phases of Wu et al.’s protocol [26]. The total computational time, including both the user side and the server side, is \(19T_{h}+ 4T_{bh}\approx 0.0476 ms\) in the login and mutual authentication phases of Zhang et al.’s protocol [32]. Finally, the total computational time, including both the user side and the server side, is 2Ts + 22Th + 5Tbh ≈ 0.3194ms in the login and mutual authentication phases of our proposed protocol.

The computational cost comparison is shown in Table 7. Note that Wu et al.’s protocol [26] is based on ECC and consumes the most time. The remaining three protocols are based on hash functions, biohash functions, and symmetric cryptography. Although Li et al.’s protocol [18] and Zhang et al.’s protocol [32] are less time-consuming, only our proposed scheme is a truly secure three-factor authentication scheme in which users can freely change passwords and biometrics.

Table 7 Comparison of computational cost (milliseconds)

Comparison of communication overhead

Based on the experimental testbed in [30], the size of an elliptic curve point is 160 bits, the size of a hash function output is 160 bits, the size of a biohash function output is 160 bits, and the size of a symmetric encryption is 128 bits.

The size of an exchanged message in Li et al.’s protocol [18] is 832 bits (we assume that the user’s identity has a length of 32 bits in Li et al.’s protocol [18]). The size of an exchanged message in Wu et al.’s protocol [26] is 896 bits (we assume that the random number has a length of 160 bits in Wu et al.’s protocol [26]). The size of an exchanged message in Zhang et al.’s protocol [32] is 1056 bits. Finally, the size of an exchanged message < DID1,C3,C4,C5,Auth1,Auth2 > in our proposed scheme is \(128 + 160+ 160 + 128+ 160 + 160+ 160 = 1056\) bits.

Table 8 compares the communication bits of various schemes. Although the communication cost of the proposed protocol is slightly higher than that of the protocols in [18, 26, 32], our proposed protocol is more secure.

Table 8 Comparison of communication overhead

Conclusion

In this study, we constructed a truly three-factor authentication protocol for TMISs. In the proposed protocol, passwords and biometrics are stored at the server side for verification by the server. Each time a user logs in, he/she sends the value associated with the smart card to the server for verification. Thus, all three factors are verified at the server side. Moreover, our protocol does not use public key cryptosystems, which require time-consuming exponentiation and point multiplication operations. Instead, we use only symmetric cryptography, hash functions, and biohash functions, which makes our protocol efficient. Additionally, our protocol protects user privacy and fulfills all the security requirements of TMISs; therefore, our protocol is suitable for real-world applications. Formal security analysis demonstrates that our proposed protocol is provably secure in the extended security model.

With the advent of the post-quantum era, future research should focus on authentication protocols for TMISs that can withstand attacks from quantum computers.