Introduction

A telecare medical information system (TMIS) allows the patients to send health related information or use portals for health monitoring and healthcare-related services over the Internet or mobile networks [14]. For example, if a patient travels to a hospital, it is desirable that the expense of the patients such as travel cost and the hospitalization time is much. Thus, to reduce significantly these factors, the patients can easily apply TMIS in order to access the healthcare delivery services.

There are several applications of TMIS including distant nursing, e-healthcare, and home monitoring facility [20, 21, 25, 28, 32, 46]. In TIMS, we have two parties: one is user from public and other is medical server, which is responsible to ensure the availability of healthcare services to the registered users via the Internet [32]. The medical server has the database of keeping records of information of its registered users including the user name, telephone number, age, address, the electronic medical record, and disclosure of any of these may endanger user’s privacy. Since the telecare servers keep the electronic medical records of all registered users in the hospitals, TMIS is very useful for the physicians to make more comprehensive decision via the cooperation of some physicians in different places. However, TMIS usually works in the open environments. The security issue then becomes a crucial concern in TMIS.

In recent years, several user authentication schemes have been proposed in the literature [20, 22, 23, 26, 29, 30, 36, 39, 40, 4345, 47, 52, 57]. In 2010, Yang and Yang [58] proposed a biometric password-based multi-server authentication scheme with smart card. However, their scheme does not resist insider attack, and has a high computational cost as it requires to perform exponential operations [42]. Sood et al. [53] then proposed a dynamic identity-based multi-server authentication scheme. Li et al. [34] pointed out that Sood et al.’s scheme fails to resist stolen verifier attack as well as stolen smart card attack. In addition, they proposed an improved smart-card based authentication scheme for multi-server architecture and it requires the involvement of a control server in order to achieve mutual authentication. Later, Wang and Ma [56] presented a smart-card based authentication scheme for multi-server environment. However, their scheme is vulnerable to privileged insider attack, server spoofing attack, impersonation attack and off-line password guessing attack [42]. Chuang and Chen [9] proposed an efficient multi-server authenticated key agreement scheme based on a user’s password and biometrics. Mishra et al. [42] showed that their scheme does not resist stolen smart card attack which causes the user’s impersonation attack and server spoofing attack. Mishra et al. also showed that their scheme fails to protect denial-of-service attack.

Recently, Amin and Biswas [1] presented a biometric-based authentication scheme in TMIS based on multi-medical server architecture. Though their scheme is efficient, in this paper we point out that their scheme has numerous security flaws as well as design flaws. In order to withstand those flaws found in Amin-Biswas’s scheme, we aim to propose a novel and robust user authentication and key agreement scheme for the hierarchical multi-medical server architecture, which is very suitable for TMIS and secure against possible known attacks.

Threat Model

We use the Dolev-Yao threat model [19] in which any two communicating parties communicate over an insecure channel. An adversary (attacker or intruder) can eavesdrop the transmitted messages over a public insecure channel and he/she has the ability to modify, delete or change the contents of the transmitted messages. We adopt the similar threat model in our scheme in which the communicating channels are insecure and the end-point nodes (users, medical servers, physician servers in multi-medical server environment in TMIS) cannot in general be trustworthy. If a user’s smart card is stolen or lost, an attacker can extract all the sensitive information stored in its memory by monitoring the power consumption of the smart card [31, 37] even if the smart card is tamper resistant.

Our contributions

Our contributions towards this paper are listed below:

  • We analyze the recently proposed Amin-Biswas’s scheme [1] and show that their scheme has several security loopholes as well as design flaws, such as it fails to protect privileged-insider attack, it fails to protect strong replay attack, it fails to protect strong man-in-the-middle attack, it has design flaw in user registration phase, it has design flaw in login phase, it has design flaw in password change phase, it lacks of supporting biometric update phase, and it has flaws in formal security analysis.

  • We then propose a secure and robust user authenticated key agreement scheme for the hierarchical multi-server environment suitable in TMIS using the cryptographic one-way hash function and fuzzy extractor.

  • Through the rigorous security analysis including the formal security analysis using the widely-accepted Burrows-Abadi-Needham (BAN) logic, the formal security analysis under the random oracle model and the informal security analysis, we show that our scheme is secure against possible known attacks.

  • We simulate our scheme using the most-widely accepted and used Automated Validation of Internet Security Protocols and Applications (AVISPA) tool and the simulation results clearly show that our scheme is secure.

  • Our scheme is more efficient in computation and communication as compared to Amin-Biswas’s scheme and other existing related schemes.

  • Our scheme also supports extra functionality features as compared to Amin-Biswas’s scheme and other existing related schemes.

Organization of the Paper

The remainder of this paper is organized as follows. In Section “Useful Mathematical Preliminaries”, we discuss some basic mathematical preliminaries, which are essential for describing and analyzing Amin-Biswas’s scheme as well as our proposed scheme. In Section “Review of Amin-biswas’s Scheme”, we briefly review different phases of their scheme, which are useful for Section “Cryptanalysis of Amin-biswas’s Scheme”. In Section “The Proposed Scheme”, we describe the various phases of our proposed scheme. In Section “Security Analysis of the Proposed Scheme”, we show that our scheme is secure against different known attacks through the rigorous formal and informal security analysis. We simulate our scheme for the formal security verification using the widely-accepted and used AVISPA tool in Section “Simulation for Formal Security Verification using AVISPA Tool”. We compare functionality features and performance of our scheme with Amin-Biswas’s scheme and other related existing schemes in Section “Performance Comparison with Other Related Schemes”. Finally, we conclude the paper in the next section.

Useful Mathematical Preliminaries

In this section, we briefly describe some mathematical preliminaries, which are essential for describing and analyzing Amin-Biswas’s scheme [1] as well as our proposed scheme.

Collision-resistant One-way Hash Function

We define formally a one-way collision-resistant cryptographic hash function as follows [15, 51, 54].

Definition 1 (One-way collision resistant hash function)

A collision-resistant one-way hash function h:PQ, where P={0,1} and Q={0,1}n is a deterministic algorithm that takes an arbitrary length binary string xP as input and produces a binary string of fixed-length n, yQ as output. Let \(Adv_{\mathcal {A}}^{HASH} (t)\) denote an adversary (attacker) \(\mathcal {A}\)’s advantage in finding a collision. Then,

$$\begin{array}{@{}rcl@{}} Adv_{\mathcal{A}}^{HASH} (t) & = & Pr [(x, x^{\prime}) \Leftarrow_{R} \mathcal{A}: x \neq x^{\prime} \\ & & \text{and} \, h(x) = h(x^{\prime})], \end{array} $$

where P r[E] denotes the probability of a random event E, and \((x, x^{\prime }) \Leftarrow _{R} \mathcal {A}\) denotes the pair (x,x ) is selected randomly by \( \mathcal {A}\). In this case, \(\mathcal {A}\) is allowed to be probabilistic and the probability in the advantage is computed over the random choices made by \(\mathcal {A}\) with the execution time t. h(⋅) is then called collision-resistant, if \(Adv_{\mathcal {A}}^{HASH} (t) \le \epsilon \), for any sufficiently small 𝜖>0.

Key Data Extraction Process from Biometric Template

We briefly describe the extraction process of key data from a given biometric of a user using a fuzzy extractor method. Note that the output of a conventional one-way hash function h(⋅) is very sensitive and it may also return completely different outputs even if there is a little variation in inputs. The biometric information is prone to various noises during data acquisition, and as a result, the reproduction of actual biometric is hard in common practice. In order to avoid such problem, a fuzzy extractor method [5, 18, 24] is prefered, which has the ability to extract a uniformly random string b i and a public information p a r i from the biometrics B i with the error tolerance threshold t. In the reproduction process, the fuzzy extractor recovers the original biometric key data b i for a noisy biometric B using p a r i and t. Let \(\mathcal {M} = \{0, 1\}^{v}\) be a finite v-dimensional metric space of biometric data points, \(d: \mathcal {M} \times \mathcal {M} \rightarrow \mathbb {Z}^{+}\) a distance function, which can be used to calculate the distance between two points based on the metric chosen and l is the number of bits of the output string b i , where \(\mathbb {Z}^{+}\) denotes the set of all positive integers.

Definition 2

The fuzzy extractor is a tuple \((\mathcal {M}, l, t)\) defined by the following two algorithms, called G e n and R e p:

  • Gen: This is a probabilistic algorithm, which takes a biometrics \(B_{i} \in \mathcal {M}\) as input and outputs a secret key data b i ∈{0,1}l and a public reproduction parameter p a r i , where (b i ,p a r i )=G e n(B i ).

  • Rep: This deterministic algorithm takes a noisy biometrics \(B_{i}^{\prime } \in \mathcal {M}\) and a public parameter p a r i related to B i , and then it recovers the biometric key data b i . In other words, \(b_{i} = Rep(B_{i}^{\prime }, par_{i})\) provided that the condition \(d(B_{i},B_{i}^{\prime }) \le t\) is satisfied.

For more detailed description of the fuzzy extractor and the extraction procedure, one can refer to [5, 18].

Review of Amin-biswas’s Scheme

Amin and Biswas [1] proposed a hierarchical architecture for accessing multi-medical server system for the telecare medicine information system (TMIS), which is shown in Fig. 1. This architecture is similar to that in [8, 17] presented for hierarchical wireless sensor networks. In this architecture, they considered four types of network entities, which are discussed below:

  • U i (i th user/patient): There are several users present in this architecture, which can access medical services from the physician servers with the help of the medical servers.

  • MRS (medical registration server): There is only one MRS present in the system. MRS is responsible for providing registration to the new patients (users) U i as well as the medical servers (M S j ), j=1,2,…,m.

  • M S j (j th medical server): There are several medical servers in the system.

  • P S k (k th physician server): There are also several physician servers in the system.

A P S k provides services on demand to the authorized registered users/patients U i through a medical server M S j . The users/patients U i then can access P S k through M S j for solving personal medical related problems in TMIS. As specified in [1], P S k may be different servers such as Cardiologist, Perinatologist, Gastroenterologist, Anesthesiologist, Hematologist, Nephrologist, Neurologist. In Amin-Biswas’s scheme, there are five phases, which are described in brief in the following subsections. The notations listed in Table 1 are used for describing various phases of their scheme.

Fig. 1
figure 1

Architecture for accessing multi-medical server system in Amin-Biswas’s scheme (Source: [1])

Table 1 Notations used in this paper

Medical Server Registration Phase

In this phase, if a medical server M S j wants to join in the network for providing the medical services to the remote users U i , M S j needs to choose an identity \(ID_{MS_{j}}\) and send it to the MRS. After receiving \(ID_{MS_{j}}\), the MRS computes the secret key \(X_{j} =h(ID_{MS_{j}} || X_{c})\), where X c is the secret key of the MRS, and sends it back to M S j via a secure channel. At the end of this phase, M S j keeps \(ID_{MS_{j}}\) and X j .

User Registration Phase

A user U i needs to register to the MRS with the following steps:

Step 1.:

U i first chooses hos/her identity I D i , password P W i and imprints his/her personal biometrics B i at the sensor of a specific device. U i then computes P W D i =h(I D i ||P W i ) and sends the message 〈I D i ,P W D i ,B i 〉 to the MRS via a secure channel.

Step 2.:

The MRS computes F i =H(B i ) using the biohashing function H(⋅) [27, 35], R E G i =h(I D i ||P W D i ), A j =h(I D i ||X j )⊕R E G i , and \(P_{j} = h(ID_{MS_{j}} || X_{j} || F_{i}) \oplus h(REG_{i} || F_{i})\), 1<jm. The MRS then issues a smart card containing the information \(\{ \{(ID_{MS_{j}}, A_{j}, P_{j}) | 1 < j \le m \}, REG_{i}, h(\cdot ), H(\cdot )\}\) and sends it to U i via a secure channel.

Remark 1

In Amin-Biswas’s scheme, after the end of the user registration phase, the smart card does not store F i =H(B i ). Also, the smart card contains the table having the tuples \(\langle ID_{MS_{j}}, A_{j}, P_{j} \rangle ,1 < j \le m\). Thus, the smart card does not store the tuple \(\langle ID_{MS_{1}}, A_{1}, P_{1} \rangle \) corresponding to the first medical server M S 1. Furthermore, it is assumed that U i can choose very low entropy 〈I D i ,P W i 〉 which are guessable individually in polynomial time.

Login Phase

In this phase, the following steps are executed:

Step 1.:

A user U i inserts his/her smart card into the card reader of a specific device, and then imprints biometric template B i at the sensor to the specific device. The smart card computes \(F_{i}^{*} =H(B_{i})\). It is claimed in Amin-Biswas’s scheme that the computed \(F_{i}^{*}\) is matched with the stored F i in the smart card. However, it is seen from Remark 1 that there is no F i stored in the smart card, and as a result, the biometric verification is not valid in Amin-Biswas’s scheme. After that U i inputs 〈I D i ,P W i 〉.

Step 2.:

The smart card computes \(REG_{i}^{*} =h(ID_{i} || PW_{i})\). If \(REG_{i}^{*} = REG_{i}\), the provided 〈I D i ,P W i 〉 are valid. Otherwise, the smart card stops the session.

Step 3.:

Based on a medical server’s identity, say \(ID_{MS_{j}}\), the smart card generates a random nonce R c and then computes C i =A j R E G i , D i =h(C j ||R c ), E i =P j h(R E G i ||F i ), G i =I D i E i and L i =E i R c . The smart card then sends the message \(\langle ID_{MS_{j}}, ID_{k}, F_{i}, D_{i}, G_{i}, L_{i} \rangle \) to a medical server M S j via a public channel, where I D k is the identity of a physician server P S k from which U i wants to access the medical services.

The login phase of Amin-Biswas’s scheme is summarized in Table 2.

Table 2 Login phase of Amin-Biswas’s scheme

Authentication and Key Agreement Phase

In this phase, the mutual authentication and session key agreement between a user U i and a physician server P S k are achieved. The following steps are involved in this phase:

Step 1.:

After receiving the login message from U i , M S j computes \(E_{i}^{*} =h(ID_{MS_{j}} || X_{j} || F_{i})\), \(ID_{i}^{*} = G_{i} \oplus E_{i}^{*}\), \(R_{c}^{*} =L_{i} \oplus E_{i}^{*}\), \(C_{i}^{*} =h(ID_{i}^{*} || X_{j})\) and \(D_{i}^{*} =h(C_{i}^{*} || R_{c}^{*})\). After that M S j checks the condition \(D_{i}^{*} = D_{i}\). If it matches, M S j believes the authenticity of U i ; otherwise, M S j terminates the session.

Step 2.:

M S j generates a random nonce R m s , and computes N j =h(I D k ||X k ||F i ), O j =I D i N j , S j =h(I D i ||X k )⊕R m s , \(RAN_{j} =R_{c}^{*} \oplus R_{ms}\), Q j =h(I D i ||X k ||N j ||R m s ). M S j then sends the message 〈I D k ,O j ,S j ,Q j ,R A N j ,F i 〉 to the accessed physician server P S k via a public channel.

Step 3.:

After receiving the message in Step 2, P S k computes \(N_{j}^{\prime } = h(ID_{k} || X_{k} || F_{i})\), \(ID_{i}^{\prime } =O_{j} \oplus N_{j}^{\prime }\), \(R_{ms}^{\prime } =h(ID_{i}^{\prime } || X_{k}) \oplus S_{j}\), \(R_{c}^{\prime } =RAN_{j} \oplus R_{ms}^{\prime }\), \(Q_{j}^{\prime } =h(ID_{i}^{\prime } || X_{k} || N_{j}^{\prime } || R_{ms}^{\prime })\). If the condition \(Q_{j}^{\prime } = Q_{j}\) is satisfied, P S k believes the authenticity of M S j and U i ; otherwise, P S k stops the session.

Step 4.:

P S k further generates a random nonce R k and computes a session key \(SK =h(ID_{i}^{\prime } || ID_{k} || R_{c}^{\prime } || R_{k})\) shared with the user U i , \(T_{k} =h(h(ID_{i}^{\prime } || X_{k}) || SK)\), \(RAN_{k} =R_{c}^{\prime } \oplus R_{k}\), \(V_{k} =h(ID_{i}^{\prime } || X_{k}) \oplus R_{k}\), and sends the message 〈T k ,R A N k ,V k 〉 to U i via a public channel.

Step 5.:

After receiving the message in Step 4, U i computes \(R_{k}^{*} =RAN_{k} \oplus R_{c}\), \(W_{k} =V_{k} \oplus R_{k}^{*}\), \(SK^{*} =h(ID_{i} || ID_{k} || R_{c} || R_{k}^{*})\) and \(T_{k}^{*} =h(W_{k} || SK^{*})\). Finally, U i compares \(T_{k}^{*}\) with the received T k . If they match, U i believes the authenticity of P S k and also, the session key S K (=S K) between U i and P S k is verified.

This phase of Amin-Biswas’s scheme is summarized in Table 3.

Table 3 Authentication and session key agreement phase of Amin-Biswas’s scheme

Password Change Phase

In this phase, if a user U i wants to change his/her old password P W i by a desired new password \(PW_{i}^{new}\), the following steps need to be executed:

Step 1.:

U i first inserts his/her smart card in a specific card reader, and imprints personal biometrics B i . After the biometric verification, U i also inputs 〈I D i ,P W i 〉. The smart card also verifies P W i . If it is valid, next steps are executed; otherwise, the smart card stops the phase.

Step 2.:

U i inputs the new password \(PW_{i}^{new}\). The smart card then computes \(PWD_{i}^{new} =h(ID_{i} || PW_{i}^{new})\), \(REG_{i}^{new} =h(ID_{i} || PWD_{i}^{new})\), \(A_{j}^{new} =A_{j} \oplus REG_{i} \oplus REG_{i}^{new}\), \(P_{j}^{new} =P_{j} \oplus h(REG_{i} || F_{i}) \oplus h(REG_{i}^{new} || F_{i})\). The smart card then replaces 〈R E G i ,A j ,P j 〉 with \(\langle REG_{i}^{new}, A_{j}^{new}, B_{j}^{new} \rangle \), 1<jm, respectively.

Cryptanalysis of Amin-Biswas’s Scheme

In this section, we show that Amin-Biswas’s scheme is vulnerable to several known attacks. In addition, we also demonstrate that their scheme has several design flaws.

Fails to Protect Privileged-insider Attack

During the user registration phase, a user U i sends the registration request message 〈I D i ,P W D i ,B i 〉 securely to the MRS, where P W D i =h(I D i ||P W i ). Then an insider user being an attacker directly knows the identity I D i and the personal biometrics B i . Furthermore, knowing the identity I D i and P W D i , the insider attacker can mount the offline password guessing attack in order to know the password P W i of U i using the following steps as in [12]:

Step 1.:

Pick a guessed password \(PW_{i}^{*}\) from a relatively small dictionary as it is assumed in Amin-Biswas’s scheme that P W i is a low-entropy password.

Step 2.:

Compute \(PWD_{i}^{*}= h(ID_{i} || PW_{i}^{*})\).

Step 3.:

Check if \(PWD_{i}^{*} = PWD_{i}\). If there is a match, the insider attacker is successful in finding the correct password P W i of the user U i and terminates the procedure. Otherwise, the insider attacker discards this guessed password and guesses another password, and continues from Step 1.

Hence, it is clear that Amin-Biswas’s scheme is completely insecure against privileged-insider attack, where an insider user of the MRS being an attacker knows all the user’s credentials I D i , P W i and B i . In practice, it is expected that a user U i keeps the same B i and P W i for different application due to easy-to-remember policy. In fact, P W i and B i must not be revealed even to the MRS though the MRS is considered as a trustworthy node in the network [41].

Fails to Protect Strong Replay Attack

Suppose an adversary \(\mathcal {A}\) intercepts the login message \(\langle ID_{MS_{j}}, ID_{k}, F_{i}, D_{i}, G_{i}, L_{i} \rangle \), which is sent to a medical server M S j by a user U i , during the login phase of Amin-Biswas’s scheme. After that \(\mathcal {A}\) sends the same intercepted message \(\langle ID_{MS_{j}}^{\prime }, ID_{k}^{\prime }, F_{i}^{\prime }, D_{i}^{\prime }, G_{i}^{\prime }, L_{i}^{\prime } \rangle =\langle ID_{MS_{j}}, ID_{k}, F_{i}, D_{i}, G_{i}, L_{i} \rangle \) to the M S j . However, this message is not detected as a replay message by the MRS due to the following reason. After receiving the login message, M S j computes \(E_{i}^{\ast } =h(ID_{MS_{j}} || X_{j} || F_{i})\), \(ID_{i}^{\ast } = G_{i} \oplus E_{i}^{\ast }\), \(R_{c}^{\ast } =L_{i} \oplus E_{i}^{\ast }\), \(C_{i}^{\ast } =h(ID_{i}^{\ast } || X_{j})\) and \(D_{i}^{\ast } =h(C_{i}^{\ast } || R_{c}^{\ast })\). When M S j checks the condition \(D_{i}^{*} = D_{i}\), this condition is always satisfied. As a result, M S j believes the authenticity of U i and proceeds further to send the message 〈I D k ,O j ,S j ,Q j ,R A N j ,F i 〉 to a physician server P S k . This happens, because there is no mechanism used in Amin-Biswas’s scheme that the previous random nonce R c is old or not. Thus, Amin-Biswas’s scheme fails to protect strong replay attack.

Fails to Protect Strong Man-in-the-middle Attack

During the authentication and key agreement phase of Amin-Biswas’s scheme, after receiving the login message \(\langle ID_{MS_{j}}, ID_{k}, F_{i}, D_{i}, G_{i}, L_{i} \rangle \) from a user U i , M S j generates a random nonce R m s , and computes N j =h(I D k ||X k ||F i ), O j =I D i N j , S j =h(I D i ||X k )⊕R m s , \(RAN_{j} =R_{c}^{\ast } \oplus R_{ms}\), Q j =h(I D i ||X k ||N j ||R m s ). M S j then sends the message 〈I D k ,O j ,S j ,Q j ,R A N j ,F i 〉 to the accessed physician server P S k via a public channel. Suppose an adversary \(\mathcal {A}\) intercepts the message 〈I D k ,O j ,S j ,Q j ,R A N j ,F i 〉, and generates a fake random nonce R a and computes \(RAN_{j}^{\prime } =RAN_{j} \oplus R_{a}\), which is \(R_{c}^{\ast } \oplus R_{ms} \oplus R_{a}\). \(\mathcal {A}\) then sends the modified message \(\langle ID_{k}, O_{j}, S_{j}, Q_{j}, RAN_{j}^{\prime }, F_{i} \rangle \) to P S k via a public channel. After receiving this modified message, P S k proceeds to compute \(N_{j}^{\prime } = h(ID_{k} || X_{k} || F_{i})\), \(ID_{i}^{\prime } =O_{j} \oplus N_{j}^{\prime }\), \(R_{ms}^{\prime } =h(ID_{i}^{\prime } || X_{k}) \oplus S_{j}\), \(R_{c}^{\prime } =RAN_{j} \oplus R_{ms}^{\prime }\neq R_{c}\), \(Q_{j}^{\prime } =h(ID_{i}^{\prime } || X_{k} || N_{j}^{\prime } || R_{ms}^{\prime })\). Then, the condition \(Q_{j}^{\prime } = Q_{j}\) is satisfied as this condition does not involve R c . Thus, P S k believes the authenticity of M S j and U i , and proceeds to generate a random nonce R k and computes a session key \(SK =h(ID_{i}^{\prime } || ID_{k} || R_{c}^{\prime } || R_{k})\) shared with the user U i , which is not equal to h(I D i ||I D k ||R c ||R k ), \(T_{k} =h(h(ID_{i}^{\prime } || X_{k}) || SK)\), \(RAN_{k} =R_{c}^{\prime } \oplus R_{k}\neq R_{c} \oplus R_{k}\), \(V_{k} =h(ID_{i}^{\prime } || X_{k}) \oplus R_{k}\), and sends the message 〈T k ,R A N k ,V k 〉 to U i via a public channel. At the user U i ’s side, this message is then rejected. Thus, it is clear that Amin-Biswas’s scheme gives the adversary \(\mathcal {A}\) a fair chance to modify R A N j to \(RAN_{j}^{\prime }\) so that the condition \(Q_{j}^{\prime } = Q_{j}\) does not fail. Hence, Amin-Biswas’s scheme also fails to protect strong man-in-the-middle attack.

Design Flaw in User Registration Phase

In Amin-Biswas’s scheme, after the end of the user registration phase, the smart card does not store F i =H(B i ) for the purpose of biometric verification in the login phase. Also, the smart card contains the table having the tuples \(\langle ID_{MS_{j}}, A_{j}, P_{j} \rangle ,1 < j \le m\). Thus, the smart card does not store the tuple \(\langle ID_{MS_{1}}, A_{1}, P_{1} \rangle \) corresponding to the first medical server M S 1. This means that a user U i can not access the medical services of the physician servers through the medical server M S 1.

Design Flaw in Login Phase

In Amin-Biswas’s scheme, the biometric verification always fails as the condition \(F_{i}^{\ast } = F_{i}\) will never meet, and F i =H(B i ) is not stored in the smart card’s memory during the user registration phase as specified in Remark 1. Further, the smart card continues to compute E i =P j h(R E G i ||F i ), G i =I D i E i and L i =E i R c , which contain the value of F i . Therefore, without the actual value of F i computation of E i , G i and L i are incorrect and as a result, the login request message \(\langle ID_{MS_{j}}, ID_{k}, F_{i}, D_{i}, G_{i}, L_{i} \rangle \) is totally incorrect. This is a very serious design flaw found in Amin-Biswas’s scheme. In addition, during the password verification, the smart card computes \(REG_{i}^{\ast } = h(ID_{i} || PW_{i})\) and then checks the condition \(REG_{i}^{*} = REG_{i}\). Note that R E G i =h(I D i ||P W D i )=h(I D i ||h(I D i ||P W i )). As a result, the password verification will also always fail in Amin-Biswas’s scheme. It is thus clear that Amin-Biswas’s scheme fails to verify both password as well as biometric verification during the login phase.

Design Flaw in Password Change Phase

In Amin-Biswas’s scheme, the password change phase has the inherent flaw as found in the login phase (discussed in Section “Design Flaw in Login Phase”). In this phase, the biometric verification is not possible because the smart card does not store F i =H(B i ). Further, the password verification will also always fail in Amin-Biswas’s scheme. In addition, P j must be replaced by \(P_{j}^{new}\), but not by \(B_{j}^{new}\) in the smart card’s memory. As a consequence, the subsequent password change phases will be incorrect and subsequent authentication for the same user U i by P S k will always fail.

In the following, we show the offline password guessing attack in this phase. We assume that the smart card of the user U i is lost or stolen and it is with an insider attacker (user) of the MRS. Note that the updated smart card contains the information \(\{ \{(ID_{MS_{j}}, A_{j}^{new}, B_{j}^{new}) | 1 < j \le m \}, REG_{i}^{new}, h(\cdot ), H(\cdot )\}\), where \(REG_{i}^{new} =h(ID_{i} || PWD_{i}^{new})= h(ID_{i} || h(ID_{i} || PW_{i}^{new}))\). Further, we assume that the insider attacker of the MRS has the registration request message 〈I D i ,P W D i ,B i 〉 earlier. Thus, the insider attacker knows the identity I D i of the user U i . The offline password guessing attack in Amin-Biswas’s scheme works as follows. Note that this attack is similar to that presented in [12].

Step 1.:

Extract the information stored in the lost/stolen smart card of the user U i using the power analysis attack [38] as described in our threat model. Thus, the insider attacker knows \(REG_{i}^{new} =h(ID_{i} || PWD_{i}^{new})= h(ID_{i} || h(ID_{i} || PW_{i}^{new}))\).

Step 2.:

Pick a guessed password \(PW_{i}^{*}\).

Step 3.:

Compute \(PWD_{i}^{*}= h(ID_{i} || PW_{i}^{*})\) and \(REG_{i}^{*} =h(ID_{i} || PWD_{i}^{*})= h(ID_{i} || h(ID_{i} || PW_{i}^{*}))\).

Step 4.:

Check if \(REG_{i}^{*} = REG_{i}^{new}\). If there is a match, the insider attacker is successful in finding the correct new updated password \(PW_{i}^{new}\) of the user U i and terminates the procedure. Otherwise, the insider attacker discards this guessed password and guesses another new password, and continues from Step 2.

Since in Amin-Biswas’s scheme, the password is assumed to be low-entropy, it is very clear from the above attack that the insider user being an attacker can successfully obtain the new changed password even if the old password of the user U i is changed through the password change phase.

Lacks of Supporting Biometric Update Phase

In a biometrics-based authentication scheme, one of the most desirable properties is that a legal user must be allowed to change his/her old password as well as biometrics [12, 41]. However, it is noted that Amin-Biswas’s scheme fails to support biometric update phase.

Flaws in Formal Security Analysis

Amin and Biswas used the R e v e a l oracle for their formal security analysis. It is an oracle, which unconditionally outputs the input string m from the corresponding hash value y=h(m). In the first algorithm, they have used the R e v e a l oracle on the input R E G i =h(I D i ||P W D i )=h(I D i ||h(I D i ||P W i )) in order to retrieve I D i , P W i and B i as \((ID_{i}^{\prime } || PW_{i}^{\prime } || B_{i}^{\prime }) \leftarrow Reveal (REG_{i})\). However, since R E G i does not involve B i , the R e v e a l oracle never returns the biometrics \(B_{i}^{\prime }\). Hence, \(B_{i}^{\prime }\) can not be used in the rest of the algorithm. As a result, the formal security analysis is incorrect in Amin-Biswas’s scheme.

The Proposed Scheme

In this section, we describe the various phases of our scheme, which are (i) medical server registration phase, (ii) user registration phase, (iii) login phase, (iv) authentication and session key agreement phase, (v) password and biometric update phase, and (vi) dynamic medical server addition phase. Our scheme is an improvement over Amin-Biswas’s scheme, which withstands all the security pitfalls and design flaws found in their scheme, which are already discussed in the previous section. We use the notations provided in Table 1 for describing our scheme. We also use the same architecture provided in Fig. 1 for describing our improved scheme.

We apply the fuzzy extractor algorithms in order to strengthen the biometric verification procedure in our scheme. Further, we make use of both the time-stamp and random nonce to protect strongly the replay and man-in-the-middle attacks. For this reason, we assume that all the network entities, such as the MRS, medical servers M S j (1≤jm+m ), physician servers P S k (1≤kp) and user devices (smart cards) are synchronized with their clocks. The various phases of our scheme are discussed in the following subsections.

Medical Server Registration Phase

Suppose m number of medical servers M S j ,(1≤jm) are to be deployed initially in the network. We further assume that m number of additional medical servers M S j ,(m+1≤jm+m ) may be added later in the network, where m <<m. For example, initially m=100 medical servers may be deployed and later we may add m =10 additional medical servers after initial deployment in the network, if required, based on the demand of the medical services when more users want to access the services.

For this purpose, a medical server M S j ,(1≤jm), which wants to provide the medical services to the remote users (patients), needs to select a unique identity \(ID_{MS_{j}}\) and send it to the MRS. After receiving \(ID_{MS_{j}}\), the MRS computes the secret key \(X_{j} =h(ID_{MS_{j}} || X_{c})\), where X c is the 1024-bit secret key of the MRS for security reasons, and sends it back to M S j via a secure channel. Thus, each M S j keeps \((ID_{MS_{j}}, X_{j})\). For m additional medical servers M S l ,(m+1≤lm+m ), the MRS itself chooses a unique identity \(ID_{MS_{l}}\) and also compute the secret key \(X_{l} =h(ID_{MS_{l}} || X_{c})\). Note that these computed \((ID_{MS_{l}}, X_{l})\) are kept to the MRS and will be used later during the user registration phase and dynamic medical server addition phase.

User Registration Phase

In this phase, a legal user U i needs to register with the MRS for accessing the medical services from a particular physician server P S k under a medical server M S j in the network. This phase has the following steps:

Step R1: :

As in [13], U i first inputs his/her desired identity I D i , password P W i , and then imprints the personal biometrics B i at the sensor of a specific device. U i generates a 1024-bit random number K, which is kept secret to U i only. U i then applies the fuzzy extractor generation function G e n(⋅) on the input B i in order to produce the biometric data key σ i and the public parameter τ i as G e n(B i )=(σ i ,τ i ). Note that σ i is kept secret to U i only.

Step R2: :

U i computes the pseudo-random password R P W i as R P W i =h(I D i ||K||P W i ) and sends the registration request 〈I D i ,R P W i 〉 to the MRS via a secure channel.

Step R3: :

After receiving the registration request from U i , the MRS continues to compute A j =h(I D i ||X j )⊕R P W i and \(P_{j} =h(ID_{MS_{j}} || X_{j}) \oplus RPW_{i}\), for 1≤jm+m . Then the MRS stores the information \(\{ \{ \langle ID_{MS_{j}}, A_{j}, P_{j}\rangle | 1 \le j \le m+m^{\prime }\}, h(\cdot ), Gen(\cdot ), Rep(\cdot ), t \}\) in a smart card, say S C i and sends it to the user U i via a secure channel, where t is the error tolerance threshold used in fuzzy extractor.

Step R4: :

After receiving the smart card S C i from the MRS, the user U i computes e i =h(I D i ||σ i )⊕K and f i =h(I D i ||R P W i ||σ i ). U i then stores e i and f i in the smart card S C i . Finally, note that the smart card S C i contains the information \(\{\langle ID_{MS_{j}}, A_{j}, P_{j}\rangle | 1 \le j \le m+m^{\prime }\},e_{i}, f_{i}, h(\cdot ), Gen(\cdot ), Rep(\cdot ), \tau _{i}, \)and t.

The summary of the user registration phase of our scheme is shown in Table 4.

Table 4 User registration phase of our scheme

Login phase

In this phase, a legal user U i can access any medical server M S j for the medical services from a physician server P S k under that medical server M S j at anytime from anywhere through his/her issued smart card S C i . This phase contains the following steps:

Step L1: :

U i first inserts his/her smart card S C i into a smart card reader of a specific terminal, and then inputs his/her identity I D i , password P W i , and also imprints the personal biometrics B i at the sensor.

Step L2: :

S C i then computes

$$\begin{array}{@{}rcl@{}} \sigma_{i}^{*} & = & Rep(B_{i}, \tau_{i}), \\ K^{*} & = & h(ID_{i} || \sigma_{i}^{*}) \oplus e_{i}, \\ RPW_{i}^{*} & = & h(ID_{i} || K^{*} || PW_{i}), \\ f_{i}^{*} & = & h(ID_{i} || RPW_{i}^{*} || \sigma_{i}^{*}). \end{array} $$

S C i further checks the verification condition \(F_{i}^{*} = F_{i}\). If it holds, it ensures that the user U i passes successfully both password and biometric verification. Otherwise, this phase is terminated immediately.

Step L3: :

S C i further proceeds to generate a random nonce R c and the current time-stamp T S c . Then S C i computes

$$\begin{array}{@{}rcl@{}} M_{1} & = & A_{j} \oplus RPW_{i}^{*} \\ & = & h(ID_{i} || X_{j}) \oplus RPW_{i} \oplus RPW_{i}^{*} \\ & = & h(ID_{i} || X_{j}), \\ M_{2} & = & P_{j} \oplus RPW_{i}^{*} \\ & = & h(ID_{MS_{j}} || X_{j}), \\ M_{3} & = & ID_{i} \oplus M_{2}, \\ M_{4} & = & ID_{i} \oplus M_{1} \oplus R_{c}, \\ M_{5} & = & h(M_{1} || M_{3} || M_{4} || R_{c} || TS_{c}). \end{array} $$

S C i sends the login request message \(\langle ID_{MS_{j}},ID_{k},M_{3},M_{4},M_{5},TS_{c} \rangle \) to the medical server M S j via a public channel, where I D k is the identity of the physician server P S k from where U i wants to access the medical service.

The summary of the login phase of our scheme is shown in Table 5.

Table 5 Login phase of our scheme

Authentication and Session key Agreement Phase

In this phase, a legal user U i authenticates an accessed physician server P S k and P S k also authenticates U i for mutual authentication purpose before they can establish a symmetric common session key \(SK_{U_{i},PS_{k}}\) between them for their future secure communication. This phase involves the following steps:

Step A1: :

\(\langle ID_{MS_{j}},ID_{k},M_{3},M_{4},M_{5},TS_{c} \rangle \) from U i , M S j verifies the validity of the received time-stamp T S c in the message. Let the login request message be received by M S j at time \(TS_{c}^{*}\). M S j then checks the condition \(|TS_{c}^{*} - TS_{c}| \le \bigtriangleup T\), where △T denotes the maximum transmission delay or preset acceptable delay threshold or expected time interval for transmission delay or expected network delay time. If this condition fails, the login request message is rejected and also the session is terminated immediately. Otherwise, M S j executes the next step.

Step A2: :

M S j continues to compute \(M_{6} =h(ID_{MS_{j}}|| X_{j})\) using its own identity \(ID_{MS_{j}}\) and the secret key X j , where \(X_{j} = h(ID_{MS_{j}} || X_{c})\) and X c is the secret key of the MRS. M S j then computes

$$\begin{array}{@{}rcl@{}} M_{7} & = & M_{3} \oplus M_{6} \\ & = & ID_{i}, \\ M_{8} & = & h(M_{7} || X_{j}) \\ & = & h(ID_{i} || X_{j}), \\ M_{9} & = & M_{4} \oplus M_{7} \oplus M_{8} \\ & = & R_{c}, \\ M_{10} & = & h(M_{8} || M_{3} || M_{4} || M_{9} || TS_{c}) \\ & = & h(h(ID_{i} || X_{j}) || M_{3} || M_{4} || R_{c} || TS_{c}). \end{array} $$

M S j further checks the condition M 10=M 5. If it holds, M S j believes the authenticity of the user U i . Otherwise, M S j terminates the session immediately.In order to protect strongly the replay and man-in-the-middle attacks in our scheme, we adopt the following strategy as suggested in [11, 33]. If the condition M 10=M 5 holds, M S j stores the pair (M 7,M 9)=(I D i ,R c ) in its database. Later, when M S j receives the next login request message, say \(\langle ID_{MS_{j}},ID_{k},M_{3}^{\prime },M_{4}^{\prime },M_{5}^{\prime },TS_{c}^{\prime } \rangle \), M S j first checks the validity of the time-stamp \(TS_{c}^{\prime }\). If it is valid, M S j computes \(M_{6}^{\prime } =h(ID_{MS_{j}}|| X_{j})\), \(M_{7}^{\prime } = M_{3}^{\prime } \oplus M_{6}^{\prime }\), \(M_{8}^{\prime } = h(M_{7}^{\prime } || X_{j})\), \(M_{9}^{\prime } = M_{4}^{\prime } \oplus M_{7}^{\prime } \oplus M_{8}^{\prime }\). After that M S j compares \(M_{9}^{\prime }\) with the stored M 9=R c corresponding to the user U i ’s identity M 7=I D i in its database. If there is a match, M S j ensures that the received login request message \(\langle ID_{MS_{j}},ID_{k},M_{3}^{\prime },M_{4}^{\prime },M_{5}^{\prime },TS_{c}^{\prime } \rangle \) is a replay message and discards this message. Otherwise, M S j replaces M 9 with \(M_{9}^{\prime }\) in its database and treats this message as a fresh message.

Step A3: :

M S j generates a random nonce R m s and the current time-stamp T S m s . M S j computes \(M_{11} =h(ID_{MS_{j}} || ID_{k} || X_{k})\), where X k is the secret key shared between M S j and P S k . M S j further computes

$$\begin{array}{@{}rcl@{}} M_{12} & = & ID_{i} \oplus M_{11}, \\ M_{13} & = & h(ID_{i} || X_{k}) \oplus R_{ms}, \\ M_{14} & = & ID_{i} \oplus M_{9} \oplus R_{ms} \\ & = & ID_{i} \oplus R_{c} \oplus R_{ms}, \\ M_{15} & = & h(ID_{i} || M_{11} || M_{12} || M_{13} || M_{14} \\ & & || M_{9} || R_{ms} || TS_{ms}). \end{array} $$

M S j then sends the authentication request message \(\langle ID_{MS_{j}},ID_{k},M_{12},M_{13},M_{14},M_{15},TS_{ms} \rangle \) to the physician server P S k via a public channel.

Step A4: :

After receiving the message in Step A3, P S k checks the validity of the received time-stamp T S m s in the message by the condition \(|TS_{ms}^{*} - TS_{ms}| \le \bigtriangleup T\), where \(TS_{ms}^{*}\) is the time when the message is received by P S k . If it is valid, P S k further continues to compute

$$\begin{array}{@{}rcl@{}} M_{16} & = & h(ID_{MS_{j}} || ID_{k} || X_{k}), \\ M_{17} & = & M_{12} \oplus M_{16} \\ & = & ID_{i}, \\ M_{18} & = & M_{13} \oplus h(M_{17} || X_{k}) \\ & = & R_{ms}, \\ M_{19} & = & M_{14} \oplus M_{17} \oplus M_{18} \\ & = & R_{c}, \\ M_{20} & = & h(M_{17} || M_{16} || M_{12} || M_{13} || \\ & & M_{14} || M_{19} || M_{18} || TS_{ms}) \\ & = & h(ID_{i} || h(ID_{MS_{j}} || ID_{k} || X_{k}) || M_{12} || \\ & & M_{13} || M_{14} || R_{c} || R_{ms} || TS_{ms}). \end{array} $$

P S k then checks the condition M 20=M 15. If it does not hold, the session is terminated by P S k . Otherwise, P S k believes the authenticity of both M S j as well as U i .

Step A5: :

P S k generates a random nonce R k and the current time-stamp T S k . P S k also computes

$$\begin{array}{@{}rcl@{}} M_{21} & = & h(M_{17} || X_{k}) \\ & = & h(ID_{i} || X_{k}), \\ M_{22} & = & M_{17} \oplus M_{19} \oplus R_{k} \\ & = & ID_{i} \oplus R_{c} \oplus R_{k}, \\ M_{23} & = & M_{21} \oplus R_{k} \\ & = & h(ID_{i} || X_{k}) \oplus R_{k}, \\ SK_{U_{i},PS_{k}} & = & h(M_{17} || ID_{k} || M_{19} || R_{k} || M_{21} || TS_{k}) \\ & = & h(ID_{i} || ID_{k} || R_{c} || R_{k} || h(ID_{i} || X_{k}) || TS_{k}), \\ M_{24} & = &h(SK_{U_{i},PS_{k}} || M_{22} || M_{23} || M_{19} || R_{k} || TS_{k}). \end{array} $$

P S k finally sends the authentication reply message 〈I D k ,M 22,M 23,M 24,T S k 〉 to the user U i via a public channel.

Step A6: :

After receiving the message in Step A5, the smart card S C i of the user U i checks the validity of the time-stamp T S k in the received message by the condition \(|TS_{k}^{*} - TS_{k}| \le \bigtriangleup T\), where \(TS_{k}^{*}\) is the time when the message is received by U i . If it holds, U i computes

$$\begin{array}{@{}rcl@{}} M_{25} & = & M_{22} \oplus (ID_{i} \oplus R_{c}) \\ & = & R_{k}, \\ M_{26} & = & M_{23} \oplus M_{25} \\ & = & h(ID_{i} || X_{k}), \\ SK_{U_{i},PS_{k}}^{*} & = & h(ID_{i} || ID_{k} || R_{c} || M_{25} || M_{26} || TS_{k}), \\ M_{27} & = & h(SK_{U_{i},PS_{k}}^{*} || M_{22} || M_{23} || R_{c} || M_{25} || TS_{k}). \end{array} $$

S C i then checks if M 27=M 24. If it matches, U i authenticates P S k , and both U i and P S k treat \(SK_{U_{i},PS_{k}}^{*}= SK_{U_{i},PS_{k}}\) as the session key shared between them.

The summary of the authentication and session key agreement phase of our scheme is shown in Table 6.

Table 6 Authentication and session key agreement phase of our scheme

Password and Biometric Update Phase

This phase is executed by a legal user U i , if he/she wants to change his/her old password and biometrics for some security reasons. Note that this phase is not executed frequently by U i . This phase has the following steps:

Step PB1: :

U i first inserts his/her smart card S C i into a smart card reader of a specific terminal, and then inputs his/her identity I D i , old password \(PW_{i}^{old}\), and also imprints the old personal biometrics \(B_{i}^{old}\) at the sensor. The smart card S C i of U i computes

$$\begin{array}{@{}rcl@{}} \sigma_{i}^{old} & = & Rep(B_{i}^{old}, \tau_{i}), \\ K^{\prime} & = & h(ID_{i} || \sigma_{i}^{old}) \oplus e_{i}, \\ RPW_{i}^{old} & = & h(ID_{i} || K^{\prime} || PW_{i}^{old}), \\ f_{i}^{old} & = & h(ID_{i} || RPW_{i}^{old} || \sigma_{i}^{old}), \end{array} $$

and checks the verification condition \(f_{i}^{old} = f_{i}\). If it holds, it ensures that U i passes successfully both old password and biometric verification. Otherwise, this phase is terminated immediately.

Step PB2: :

S C i asks the user U i to input new password and biometrics. Let \(PW_{i}^{new}\) and \(B_{i}^{new}\) be the new password and personal biometrics entered by U i . S C i then applies the fuzzy extractor generation function G e n(⋅) on the input \(B_{i}^{new}\) in order to produce the biometric data key \(\sigma _{i}^{new}\) and the public parameter \(\tau _{i}^{new}\) as \(Gen(B_{i}^{new}) = (\sigma _{i}^{new}, \tau _{i}^{new})\), where \(\sigma _{i}^{new}\) is kept secret to U i only.

Step PB3: :

S C i computes \(RPW_{i}^{new} =h(ID_{i} ||K^{\prime } ||PW_{i})\), \(e_{i}^{new} =h(ID_{i} || \sigma _{i}^{new}) \oplus K^{\prime }\) and \(f_{i}^{new} =h(ID_{i} || RPW_{i}^{new} || \sigma _{i}^{new})\). S C i further computes \(\{(A_{j}^{new}, P_{j}^{new}) | 1 \le j \le m+m^{\prime }\}\), where \(A_{j}^{new} =A_{j} \oplus RPW_{i}^{old} \oplus RWP_{i}^{new}= h(ID_{i} || X_{j}) \oplus RPW_{i}^{new}\) and \(P_{j}^{new} =P_{j} \oplus RPW_{i}^{old} \oplus RWP_{i}^{new}= h(ID_{MS_{j}} || X_{j}) \oplus RPW_{i}^{new}\).

Step PB4: :

Finally, S C i replaces {〈A j ,P j 〉|1≤jm+m },e i ,f i ,and τ i with \(\{\langle A_{j}^{new}, P_{j}^{new} \rangle | 1 \le j \le m+m^{\prime }\},e_{i}^{new}, f_{i}^{new}, \)and \(\tau _{i}^{new}\), respectively, in its memory. As a result, the updated smart card S C i now contains the information \(\{\langle ID_{MS_{j}}, A_{j}^{new}, P_{j}^{new} \rangle | 1 \le j \le m+m^{\prime }\},e_{i}^{new}, f_{i}^{new}, h(\cdot ), Gen(\cdot ), Rep(\cdot ), \tau _{i}^{new}, \)and t.

It is thus clear that the new password and biometric are correctly updated in the user U i ’s smart card S C i only after validating the old password and biometric. This phase is executed locally without the involvement of the MRS further by the user U i .

Dynamic Medical Server Addition Phase

It is assumed in the medical server registration phase that m medical servers M S j (1≤jm) are deployed in the network. If later some more m medical servers M S j (m+1≤jm+m ) are deployed, it is one of the desirable requirement that the proposed scheme should support dynamic medical server addition after initial deployment. Our scheme has the ability to support this important feature and it is explained below.

Note that during our medical server registration phase, for m additional medical servers M S l ,(m+1≤lm+m ), the MRS already selected a unique identity \(ID_{MS_{l}}\) and computed the secret key \(X_{l} =h(ID_{MS_{l}} || X_{c})\). Assume that a new medical server M S l be deployed in the existing network. Then, M S j needs to register with the MRS. In this case, M S l needs to simply send a request to the MRS and the information \(\langle ID_{MS_{l}}, X_{l} \rangle \) are sent back to M S l securely by the MRS. Thus, M S l does not choose any identity in this phase. M S l then stores the information \(\{ ID_{MS_{l}}, X_{l} \}\). Further, note that during the user registration phase, a legal registered user U i ’s smart card S C i already contains the information regarding the new medical server M S l , since S C i has the information \(\{\langle ID_{MS_{j}}, A_{j}, P_{j}\rangle | 1 \le j \le m+m^{\prime }\},e_{i}, f_{i}, h(\cdot ), Gen(\cdot ), Rep(\cdot ), \tau _{i}, \)and t. Thus, there is no need to update the user’s smart card in this phase. Finally, the MRS needs to inform the user U i regarding the addition of new medical server M S l so that U i can access services of some physician servers through this medical server M S l .

Security Analysis of the Proposed Scheme

In this section, we show that our scheme is secure against various known attacks.

Formal Security Analysis using BAN Logic

In this section, we provide the authentication proof using the widely-accepted Burrows-Abadi-Needham (BAN) logic [6]. In this proof, we show that both a legal user U i and a physician server P S k belonging under a medical server M S j mutually authenticate among each other.

The notations used in the BAN logic are given below: P∣≡X: Principal P believes a statement X or P is entitled to believe X. #(X): Formula X is considered as fresh. P|⇒X: Principal P has jurisdiction over statement X. \(P \vartriangleleft X:\) Principal P sees the statement X. P∣∼X: Principal P once said the statement X. (X,Y): Formula X or Y is a part of formula (X,Y). {X} K : Formula X is encrypted under the key K. 〈X Y : Formula X is combined with the formula Y. \(P \overset {K}{\longleftrightarrow } Q:\) P and Q may use the shared key K to communicate. The key K is good, in that it will never be discovered by any principal except P and Q. \(P \overset {X}{\rightleftharpoons } Q:\) Formula X is secret known only to P and Q, and possibly to principals trusted by them.

Rules:

We have the following four rules used in the BAN logic:

  • R u l e(1). Message-meaning rule: \(\frac {P \mid \equiv P \overset {K}{\longleftrightarrow } Q, P \vartriangleleft \{X\}_{K}}{P \mid \equiv Q \mid \sim X}\) and \(\frac {P \mid \equiv P \overset {Y}{\rightleftharpoons } Q, P \vartriangleleft \langle X \rangle _{Y}}{P \mid \equiv Q \mid \sim X}\)

  • R u l e(2). Nonce-verification rule: \(\frac {P \mid \equiv \# (X), P \mid \equiv Q \mid \sim X}{P \mid \equiv Q \mid \equiv X}\)

  • R u l e(3). Jurisdiction rule: \(\frac {P \mid \equiv Q\shortmid \Rightarrow X, P \mid \equiv Q \mid \equiv X}{P \mid \equiv X}\)

  • R u l e(4). Freshness-conjuncatenation rule: \(\frac {P \mid \equiv \# (X)}{P \mid \equiv \#(X, Y)}\)

Goals:

According to the analytic procedures of the BAN logic, the proposed protocol must satisfy the following test goals in order to ensure the system is secure. Assume that SK is shared session key \(SK_{U_{i}, PS_{k}}\) between U i and P S k for the sake of simplicity of the proof.

  • \(G_{1}:U_{i} \mid \equiv U_{i} \overset {SK}{\rightleftharpoons } PS_{k}\).

  • \(G_{2}:PS_{k} \mid \equiv U_{i} \overset {SK}{\rightleftharpoons } PS_{k}\).

Idealized form:

The arrangement of the proposed protocol to its idealized forms are as follows:

  • From the login request message (Step L3), we have U i M S j : \(\langle ID_{i} \oplus h(ID_{MS_{j}}, X_{j}), ID_{i} \oplus M_{1} \oplus R_{c}, R_{c}, TS_{c} \rangle _{U_{i} \overset {M_{1}}{\longleftrightarrow } MS_{j}}\).

  • From the authentication request message (Step A3), we have M S j P S k : \(\langle ID_{i}, h(ID_{MS_{j}}, ID_{k}, X_{k}), ID_{i} \oplus M_{11}, h(ID_{i}, X_{k}) \oplus R_{ms}, ID_{i} \oplus R_{c} \oplus R_{ms}, U_{i} \overset {R_{c}}{\rightleftharpoons } PS_{k}, R_{ms}, TS_{ms} \rangle _{MS_{j} \overset {X_{k}}{\longleftrightarrow } PS_{k}}\).

  • From the authentication reply message (Step A5), we have P S k U i : \(\langle U_{i} \overset {SK}{\longleftrightarrow } PS_{k}, ID_{i} \oplus R_{c} \oplus R_{k}, h(ID_{i} \oplus X_{k}) \oplus R_{k}, U_{i} \overset {R_{k}}{\longleftrightarrow } PS_{k}, TS_{k} \rangle _{U_{i} \overset {R_{c}}{\longleftrightarrow } PS_{k}}\).

Hypotheses:

The following assumptions about the initial state are made to analyze the proposed protocol:

  • H 1: U i ∣≡#(T S k ), M S j ∣≡#(T S c ), P S k ∣≡#(T S m s ).

  • H 2:\(U_{i} \mid \equiv U_{i} \overset {M_{1}}{\longleftrightarrow } MS_{j}\).

  • H 3:\(MS_{j} \mid \equiv U_{i} \overset {M_{1}}{\longleftrightarrow } MS_{j}\).

  • H 4:\(MS_{j} \mid \equiv MS_{j} \overset {X_{k}}{\longleftrightarrow } PS_{k}\).

  • H 5:\(PS_{k} \mid \equiv MS_{j} \overset {X_{k}}{\longleftrightarrow } PS_{k}\).

  • H 6: P S k ∣≡M S j |⇒U i ∣∼X.

  • H 7:\(U_{i} \mid \equiv PS_{k} \shortmid \Rightarrow U_{i} \overset {R_{k}}{\longleftrightarrow } PS_{k}\).

  • H 8:\(MS_{j} \mid \equiv U_{i} \shortmid \Rightarrow U_{i} \overset {R_{c}}{\longleftrightarrow } PS_{k}\).

  • H 9:\(PS_{k} \mid \equiv U_{i} \shortmid \Rightarrow U_{i} \overset {R_{c}}{\longleftrightarrow } PS_{k}\).

The idealized form of the proposed protocol is analyzed based on the BAN logic rules and the assumptions. The main proofs are stated as follows:

  • From the login request message, we have \(S_{1}:MS_{j} \vartriangleleft \langle ID_{i} \oplus h(ID_{MS_{j}}, X_{j}), ID_{i} \oplus M_{1} \oplus R_{c}, U_{i} \overset {R_{c}}{\rightleftharpoons } PS_{k}, TS_{c} \rangle _{U_{i} \overset {M_{1}}{\longleftrightarrow } MS_{j}}\).

  • From S 1, H 1, H 3, R u l e(1), R u l e(2) and R u l e(4), we get S 2:M S j ∣≡U i ∣∼R c . M S j shares R c with P S k as it is shared by the legal user U i in the authentication request message.

  • From the authentication request message, we have \(S_{3}:PS_{k} \vartriangleleft \langle ID_{i}, h(ID_{MS_{j}}, ID_{k}, X_{k}), ID_{i} \oplus M_{11}, h(ID_{i}, X_{k}) \oplus R_{ms}, ID_{i} \oplus R_{c} \oplus R_{ms}, U_{i} \overset {R_{c}}{\rightleftharpoons } PS_{k}, R_{ms}, TS_{ms} \rangle _{MS_{j} \overset {X_{k}}{\longleftrightarrow } PS_{k}}\).

  • From S 3, H 1, H 5, R u l e(1), R u l e(2) and R u l e(4), we get \(S_{4}:PS_{k} \mid \equiv MS_{j} \mid \equiv (U_{i} \overset {R_{c}}{\rightleftharpoons } PS_{k}))\).

  • From S 4 and R u l e(3), we get \(S_{5}:PS_{k} \mid \equiv U_{i} \overset {R_{c}}{\rightleftharpoons } PS_{k}\). Since the session key SK is computed using the formula \(SK = SK_{U_{i},PS_{k}} = h(M_{17} || ID_{k} || M_{19} || R_{k} || M_{21} || TS_{k}) = h(ID_{i} || ID_{k} || R_{c} || R_{k} || h(ID_{i} || X_{k}) || TS_{k})\), where R k is random number generated by P S k , we get the goal G 1 . This implies that \(PS_{k} \mid \equiv U_{i} \overset {SK}{\rightleftharpoons } PS_{k}\), which is Goal G 2. From S 5, it is clear that the random secret is shared between U i and P S k .

  • From the authentication reply message, we have \(S_{6}:U_{i} \vartriangleleft \langle U_{i} \overset {SK}{\rightleftharpoons } PS_{k}, ID_{i} \oplus R_{c} \oplus R_{k}, h(ID_{i} \oplus X_{k}) \oplus R_{k}, U_{i} \overset {R_{k}}{\rightleftharpoons } PS_{k}, TS_{k} \rangle _{U_{i} \overset {R_{c}}{\rightleftharpoons } PS_{k}}\).

  • From S 5, S 6, H 1, H 3, H 7, R u l e(1), R u l e(2) and R u l e(4), and since the session key SK is computed as the formula using R c and R k , that is, \(SK_{U_{i},PS_{k}} = h(ID_{i} || ID_{k} || R_{c} || R_{k} || h(ID_{i} || X_{k}) || TS_{k})\), we have the Goal G 1 as \(S_{7}:U_{i} \mid \equiv U_{i} \overset {SK}{\rightleftharpoons } PS_{k}\).

This completes the proof.

Formal Security Analysis using Random Oracle Model

In this section, we perform the formal security analysis of our scheme under the random oracle model as in [7, 13, 41, 48] for the formal security analysis. We apply the method of contradiction proof [10] for our formal security analysis. Note that one can also prove the formal security in the standard model. However, in this paper, we perform the formal security analysis under the generic group model of cryptography.

In order to apply the method of contradiction proof [10], we assume that the following random oracle exists for an adversary, say \(\mathcal {A}\):

  • R e v e a l: This random oracle will unconditionally output the input string x from the corresponding hash value y=h(x).

Theorem 1

Under the assumption that a one-way hash function h(⋅) closely behaves like a random oracle, our scheme is secure against an adversary for deriving the identity ID i of a legal user U i and the secret key X j of a medical server MS j .

Proof

This proof is similar to that presented in [7, 13, 14, 16, 41, 48]. In this proof, we plan to construct an adversary \(\mathcal {A}\) who will have the ability to derive the identity I D i of a legal user U i and the secret key X j of a medical server M S j . For this purpose, \(\mathcal {A}\) can use the R e v e a l oracle and run the experiment E X P1 for our scheme given in Algorithm 1. We define the success probability for E X P1 as S u c c1=|P r[E X P1=1]−1|. The advantage function for this experiment becomes \(Adv1(et_{1},q_{R})= \max _{\mathcal {A}}\{Succ1\}\), where the maximum is taken over all \(\mathcal {A}\) with execution time e t 1, and the number of queries q R made to the R e v e a l oracle. Our scheme is said to be provably secure against \(\mathcal {A}\) for deriving I D i and X j , if A d v1(e t 1,q R )≤𝜖 1, for any sufficiently small 𝜖 1>0. According to the experiment provided in Algorithm 1, if \(\mathcal {A}\) has the ability to invert the one-way cryptographic hash function h(⋅), he/she can easily derive I D i and X j , and win the game. However, by Definition 1, it is a computationally infeasible problem to invert h(⋅), that is, \(Adv_{\mathcal {A}}^{HASH} (t) \le \epsilon \), for any sufficiently small 𝜖>0. Since A d v1(e t 1,q R ) depends on the advantage \(Adv_{\mathcal {A}}^{HASH} (t)\), we have A d v1(e t 1,q R )≤𝜖 1. Hence, our scheme is secure against an adversary for deriving the identity I D i of a legal user U i and the secret key X j of a medical server M S j . □

figure a

Theorem 2

Under the assumption that a one-way hash function h(⋅) closely behaves like a random oracle, our scheme is secure against an adversary for deriving the secret key X k of a physician server PS k .

Proof

This proof is similar to that in Theorem 1. We construct an adversary \(\mathcal {A}\) who will have the ability to derive successfully the secret key X k of a physician server P S k . For this purpose, \(\mathcal {A}\) can use the R e v e a l oracle and run the experiment E X P2 provided in Algorithm 1.

We define the success probability for E X P2 as S u c c2=|P r[E X P2=1]−1| and the advantage function as \(Adv2 (et_{2},q_{R})= \max _{\mathcal {A}}\{Succ2\}\), where the maximum is taken over all \(\mathcal {A}\) with execution time e t 2, and the number of queries q R made to the R e v e a l oracle. Our scheme is said to be provably secure against \(\mathcal {A}\) for deriving X k , if we have A d v2(e t 2,q R )≤𝜖 2, for any sufficiently small 𝜖 2>0. According to this experiment, if \(\mathcal {A}\) has the ability to invert the one-way cryptographic hash function h(⋅), he/she can easily derive X k , and win the game. However, by Definition 1, it is again a computationally infeasible problem to invert h(⋅), that is, \(Adv_{\mathcal {A}}^{HASH} (t) \le \epsilon \), for any sufficiently small 𝜖>0. Since A d v2(e t 2,q R ) depends on the advantage \(Adv_{\mathcal {A}}^{HASH} (t)\), we have A d v2(e t 2,q R )≤𝜖 2. As a result, our scheme is also secure against an adversary for deriving the secret key X k of a physician server P S k . □

figure b

Informal Security Analysis

In this section, we analyze the security of our proposed scheme informally to show that our scheme provides strong security protection on the relevant security attacks. In the following, we justify that our scheme has the ability to tolerate several known attacks.

Off-line Identity-password Guessing Attack

Suppose that an adversary \(\mathcal {A}\) extracts all the information \(\{\langle ID_{MS_{j}}, A_{j}, P_{j}\rangle | 1 \le j \le m+m^{\prime },, e_{i}, f_{i}, \tau _{i}\}\) stored in the smart card S C i of a legal user U i , where R P W i =h(I D i ||K||P W i ), A j =h(I D i ||X j )⊕R P W i , \(P_{j} =h(ID_{MS_{j}} || X_{j})\oplus RPW_{i}\), e i =h(I D i ||σ i )⊕K and f i =h(I D i ||R P W i ||σ i ). Clearly the identity I D i and password P W i are protected by the one-way cryptographic hash function h(⋅) under the security parameters: the random number K as well as secret biometric key σ i . Thus, guessing the identity-password pair without the knowledge of the user personal biometrics B i is computationally infeasible problem. Moreover, in our scheme the user password P W i does not appear in the communication messages and identity I D i is protected using the long-term secret tokens. As a result, our scheme successfully prevents the off-line identity-password guessing attack.

Privileged-insider Attack

In the registration phase of our scheme, a user U i sends the registration request message 〈I D i ,R P W i 〉 securely to the MRS, where R P W i =h(I D i ||K||P W i ). The password P W i in the request message is protected by the one-way hash function h(⋅) under the security parameter K. Therefore, guessing P W i from the request message without the knowledge of K is again a computationally hard problem. Thus, our scheme resits the privileged-insider attack.

Stolen Smart Card Attack

Assume that the smartcard S C i of a legal user U i is lost/stolen. An attacker \(\mathcal {A}\) can then try to login to a server M S j using the lost/stolen smartcard S C i by guessing the valid user credentials 〈I D i ,P W i ,B i 〉. However, guessing valid user credentials from the information stored in the smartcard S C i is computationally infeasible due to the hardness of guessing user personal biometrics B i . Hence, our scheme is secure against the stolen/lost smartcard attack.

User-server Impersonation Attack

In this attack, an adversary may try to impersonate a user or server by intercepting the communication messages between them. In our scheme, the medical server M S j authenticates a user U i , and U i and physician server P S k mutually authenticate each other in order to establish a shared session key \(SK_{U_{i},PS_{k}}\). Therefore, the attacker cannot compute the valid messages to authenticate at the servers M S j or P S k even if he/she intercepts the communication messages between them. Thus, our scheme resists the user-server impersonation attack.

Known key Secrecy

In this attack, an adversary may try to derive the previous session key using the current compromised session key. However, in our scheme, the session key \(SK_{U_{i},PS_{k}} =h(ID_{i} || ID_{k} || R_{c} || R_{k} || h(ID_{i} || X_{k}) || TS_{k})\) is computed using the one-time random secrets and these are protected by the one way hash function h(⋅). Thus, all the session keys are computed independently, and as a result, computing previous session key using the known session key is computationally infeasible problem.

Session key Agreement and Verification

In our scheme, a user U i and a physician server P S k mutually authenticate each other to establish the shared session key \(SK_{U_{i},PS_{k}}\), which is already proved using the widely-accepted BAN logic. Finally, after mutually authentication both U i and P S k agree on a common session key \(SK_{U_{i},PS_{k}} =h(ID_{i} || ID_{k} || R_{c} || R_{k} || h(ID_{i} || X_{k}) || TS_{k})\). Thus, our scheme provides the session key agreement and verification property.

Session key Discloser Attack

The session key \(SK_{U_{i},PS_{k}} =h(ID_{i} ||ID_{k} ||R_{c} ||R_{k} ||h(ID_{i} ||X_{k})|| TS_{k})\) between a user U i and a physician server P S k depends on the one-time random secrets R c and R k , and the long-term shared secret key X k between P S k and M S j . Thus, computing the session key \(SK_{U_{i},PS_{k}}\) without these parameters is computationally hard problem. As a result, our scheme resists the session disclosure attack.

Strong Replay Attack Protection

In order to avoid the reply attack, we have used both the random nonces and time stamps. As discussed in Step A2 of the authentication and session key agreement phase, our scheme successfully uses the random nonces to avoid the immediate reply attack within the time interval. Thus, our scheme provides the message freshness property to avoid strong replay attack.

Strong Man-in-the-middle Attack Protection

Suppose an adversary \(\mathcal {A}\) intercepts the message \(\langle ID_{MS_{j}},ID_{k},M_{3},M_{4},M_{5},TS_{c} \rangle \) during the login phase, where \(M_{3} = ID_{i} \oplus M_{2}= ID_{i} \oplus h(ID_{MS_{j}} || X_{j})\), \(X_{j} =h(ID_{MS_{j}} || X_{c})\), X c is the 1024-bit secret key of the MRS, M 4=I D i M 1R c =I D i h(I D i ||X j )⊕R c , M 5=h(M 1||M 3||M 4||R c ||T S c ) and M 1=h(I D i ||X j ). Further, assume that \(\mathcal {A}\) generates a new random nonce \(R_{c}^{\prime }\) and changes M 4 to \(M_{4}^{\prime } = M_{4} \oplus R_{c}^{\prime }= ID_{i} \oplus h(ID_{i} || X_{j}) \oplus (R_{c} \oplus R_{c}^{\prime })\). However, \(\mathcal {A}\) can not modify M 5 because it involves computation of M 1=h(I D i ||X j ), which needs the secret key X c of the MRS, I D i as well as R c . Since X j (subsequently, X c ) is protected by the one-way cryptographic hash function h(⋅), it is computationally infeasible problem for \(\mathcal {A}\) to modify M 5. As a result, \(\mathcal {A}\) does not have any ability to modify this message and send to M S j . In a similar manner, \(\mathcal {A}\) does not have also the ability modify other messages \(\langle ID_{MS_{j}},ID_{k},M_{12},M_{13},M_{14},M_{15},TS_{ms} \rangle \) and 〈I D k ,M 22,M 23,M 24,T S k 〉 during the authentication and key agreement phase. Thus, our scheme protects strongly the man-in-the-middle attack.

No Encryption/decryption

As in Amin-Biswas’s scheme [1], our scheme does not use any cryptographic symmetric-key cryptosystem. Our scheme is free from usage of symmetric-key encryption/decryption and uses only cryptographic hash function h(⋅) for authentication and session key agreement purpose. Thus, our scheme is efficient in computation.

Fast Error Detection

In our scheme, the user credentials verification is done locally by the smart card of a legal user U i without contacting the medical server M S j . Moreover, the password and biometric updates also take place locally. The adversary can not generate the valid message to create the denial of service to the valid registered user without the valid user credentials. Therefore, our scheme avoids extra computation and communication costs, and also the denial of service attack by immediately detecting the invalid user credentials.

No Verification Table

As in Amin-Biswas’s scheme [1], our scheme does not require any password-verifier table. Thus, an attacker has no ability to get the secret information of the entities.

Simulation for Formal Security Verification using AVISPA Tool

In this section, we simulate our scheme for the formal security verification using the most widely-accepted and used tool, called AVISPA (Automated Validation of Internet Security Protocols and Applications) [2] to show that our scheme is secure against the replay and man-in-the-middle attacks.

AVISPA is a push-button tool for the automated validation of Internet security-sensitive protocols and applications, which basically provides a modular and expressive formal language for specifying protocols and their security properties, and integrates different back-ends that implement a variety of state-of-the-art automatic analysis techniques [2]. We use the widely-accepted AVISPA tool for our formal security verification [1214, 41, 49, 50]. AVISPA implements four back-ends: On-the-fly Model-Checker (OFMC), Constraint Logic based Attack Searcher (CL-AtSe), SAT-based Model-Checker (SATMC) and Tree Automata based on Automatic Approximations for the Analysis of Security Protocols (TA4SP). A static analysis is performed to check the executability of the protocol, and then the protocol and the intruder actions are compiled into an intermediate format (If), which is the starting point for the four automated protocol analysis techniques. The detailed descriptions of these back-ends are given in [2]. In AVISPA, the designed protocols need to be specified in HLPSL language [55]. HLPSL is based on roles: the basic roles represent each participant role, and composition roles represent the scenarios of basic roles. Each role is independent from the others, which gets some initial information by parameters, and then communicates with the other roles by channels. The intruder is always denoted by i in HLPSL and the intruder is always modeled using the Dolev-Yao model [19] (also described in the threat model used in this paper) with the possibility for the intruder to assume a legitimate role in a protocol run. The role system defines the number of sessions, and the number of principals and the basic roles. The output format (OF) is produced by using one of the four back-ends. When the analysis of a protocol has been successful (by finding an attack or not), the output describes precisely what is the result, and under what conditions it has been obtained. The detailed formats of the OF can be found in [55].

Specifying the Protocol

In our HLPSL implementation, we have four basic roles for the user U i , the MRS, the medical server M S j and the physician server P S k . The specification in HLPSL language for the role of the initiator, the user U i is given in Fig. 2. In this implementation, U i first receives the start signal, changes its state value from 0 to 1, and then sends the user registration request message 〈I D i ,R P W i 〉 securely to the MRS with the S N D() operation. U i then receives a smart card with the necessary information securely from the MRS by the R C V() operation. During the login phase, U i sends the login request message \(\langle ID_{MS_{j}}, ID_{k}, M_{3}, M_{4}, M_{5}, TS_{c} \rangle \) to M S j via a public channel. Finally, during the authentication and session key agreement phase, U i receives the authentication reply message 〈I D k ,M 22,M 23,M 24,T S k 〉 from P S k via a public channel. The type declaration c h a n n e l (d y) declares that the channel is for the Dolev-Yao threat model (as described in our threat model) [19]. The intruder (i) will have the ability to intercept, analyze, and/or modify messages transmitted over the insecure channel. The declaration secret(PWi, Bi, K, s2, Ui) means that the information P W i , B i and K are only known to the user U i , which are characterized by the protocol id s2. The declaration witness(A, B, id, E) declares for a (weak) authentication property of A by B on E and declares that agent A is witness for the information E. This goal is identified by the constant id in the goal Section [2]. request(B, A, id, E) declaration means for a strong authentication property of A by B on E and declares that agent B requests a check of the value E. This goal is identified by the constant id in the goal section [2]. In a similar way, we have also specified the HLPSL implementation for the roles of the MRS, the medical server M S j and the physician server P S k in Fig. 3, Figs. 4 and 5, respectively.

Fig. 2
figure 2

Role specification in HLPSL for the user U i

Fig. 3
figure 3

Role specification in HLPSL for the MRS

Fig. 4
figure 4

Role specification in HLPSL for the medical server M S j

Fig. 5
figure 5

Role specification in HLPSL for the physician server P S k

In Fig. 6, we have shown the HLPSL implementation for the role of the session. In the session segment, all the basic roles: alice and bob are instanced with concrete arguments.

Fig. 6
figure 6

Role specification in HLPSL for the session.

Finally, in Fig. 7, we have shown the HLPSL implementation for the role of goal and environment. The top-level role (called the environment) needs to be always defined in the specification of HLPSL language. This contains the global constants and a composition of one or more sessions, where the intruder may play some roles as legitimate users. The intruder (i) also participates in the execution of protocol as a concrete session during the simulation as shown in this figure.

Fig. 7
figure 7

Role specification in HLPSL for the goal and environment

In our implementation, the following four secrecy goals and six authentication properties are verified:

  • secrecy_of s1: It represents that X c is kept secret to the MRS only.

  • secrecy_of s2: It tells that P W i , B i and K are kept secret to the user U i only.

  • secrecy_of s3: In this case, X k is kept secret to M S j and P S k .

  • secrecy_of s4: It indicates that I D i is known to U i , M S j and P S k .

  • authentication_on user_msj_tsc: When M S j receives T S c from the messages from U i , M S j authenticates U i based on T S c .

  • authentication_on user_msj_rc: When M S j receives R c from the messages from U i , M S j also authenticates U i based on R c .

  • authentication_on msj_psk_tsms: When P S k receives T S m s from the messages from M S j , P S k authenticates M S j based on T S m s .

  • authentication_on msj_psk_rms: When P S k receives R m s from the messages from M S j , P S k also authenticates M S j based on R m s .

  • authentication_on psk_user_tsk: When U i receives T S k from the messages from P S k , U i authenticates P S k based on T S k .

  • authentication_on psk_user_rk: When U i receives R k from the messages from P S k , U i also authenticates P S k based on R k .

Analysis of the Results

We have simulated our scheme using the AVISPA web tool [3] for the widely-accepted OFMC back-end [4]. The simulation results for the formal security verification of our scheme using OFMC back-end are shown in Fig. 8. For replay attack check, OFMC backend verifies whether the legitimate agents can execute the specified protocol by performing a search of a passive intruder. OFMC backend then gives the intruder the knowledge of some normal sessions between the legitimate agents. The simulation results shown in Fig. 8 ensures that our scheme is secure against the replay attack. OFMC backend also checks if there is any man-in-the-middle attack possible by an intruder between the communications. In this backend, the depth for the search is 8, and 198 nodes have been searched in 4.98 s. It is thus evident from the results shown in Fig. 8 that our scheme also fulfills the design properties and it is secure under the test of AVISPA using OFMC backend with the bounded number of sessions. Hence, our scheme is secure against the passive attacks and the active attacks, such as the replay and man-in-the-middle attacks.

Fig. 8
figure 8

The result of the analysis using OFMC backend

Performance Comparison with Other Related Schemes

In this section, we analyze the performance analysis of our scheme and compare with the related existing schemes, such as Yang-Yang’s scheme [58], Sood et al.’s scheme [53], Wang-Ma’s scheme [56], Chuang-Chen’s scheme [9], Xue et al.’s scheme [57], Li et al.’s scheme [34], Maitra-Giri’s scheme [36] and Amin-Biswas’s scheme [1].

In Table 7, we have compared the functionality features among our scheme and other existing related schemes. From this table, it is evident that our scheme outperforms other schemes as our scheme supports extra features and efficient design in the login and authentication phases as compared to those for other existing schemes.

Table 7 Functionality comparison among our scheme and other existing related schemes

In Table 8, we have compared the computation costs required by our scheme and other existing schemes during the login and authentication phases. We have used the notations in this table as follows: T h : execution time for one-way hash function; T h : execution time for biohashing function; T f e : execution time for a fuzzy extractor function (G e n(⋅)/R e p(⋅)); T e : execution time for exponentiation operation; T s p m : execution time for encryption/decryption operation. Our scheme requires 1T f e +4T h and 14T h operations for the login phase, and authentication and session key agreement phase, respectively. On the other hands, Yang-Yang’s scheme [58], Sood et al.’s scheme [53], Wang-Ma’s scheme [56], Chuang-Chen’s scheme [9], Xue et al.’s scheme [57], Li et al.’s scheme [34], Maitra-Giri’s scheme [36] and Amin-Biswas’s scheme [1] require 8T h +5T e , 31T h , 11T h +6T s p m , 16T h , 27T h , 27T h , 10T h +1T e +2T s p m and 18T h +1T H operations, respectively. Since the fuzzy extractor functions are efficient in computation, our scheme is also efficient in computation as compared to other schemes.

Table 8 Computation cost comparison among our scheme and existing related schemes

Finally, in Table 9, we have compared the communication costs required by our scheme and other existing schemes for the login and authentication phases. We assume that the bit lengths of identities I D i , \(ID_{MS_{j}}\) and I D k are 64 bits each, hash output and random number are of length 128 bits each, and timestamp is 32 bits. In this table, the third column (communication mode) represents the total number of messages required and the communication between the entities in the network. In our scheme, the communication costs required during the login phase for the message \(\langle ID_{MS_{j}}, ID_{k}, M_{3}, M_{4}, M_{5}, TS_{c} \rangle \) is (64+64+64+128+128+32)=480 bits, and during the authentication and session key agreement phase, the messages \(\langle ID_{MS_{j}},ID_{k},M_{12},M_{13},M_{14},M_{15},TS_{ms} \rangle \) and 〈I D k ,M 22,M 23,M 24,T S k 〉 need (64+64+64+128+128+128+32)+(64+128+128+128+32)=1098 bits. Thus, our scheme needs the total communication cost 1578 bits and requires 3 messages transmission. On the other hands, Yang-Yang’s scheme [58], Sood et al.’s scheme [53], Wang-Ma’s scheme [56], Chuang-Chen’s scheme [9], Xue et al.’s scheme [57], Li et al.’s scheme [34], Maitra-Giri’s scheme [36] and Amin-Biswas’s scheme [1] require the communication costs of 2816, 2112, 576, 1024, 2944, 2176, 896 and 1920 bits, respectively. Our scheme is efficient in computation as compared to Yang-Yang’s scheme [58], Sood et al.’s scheme [53], Xue et al.’s scheme [57], Li et al.’s scheme [34] and Amin-Biswas’s scheme [1]. Though our scheme requires more communication overhead as compared to Wang-Ma’s scheme [56], Chuang-Chen’s scheme [9], Maitra-Giri’s scheme [36], either those schemes are vulnerable to known attacks or they are inefficient and do not support extra important functionality features. As compared to Amin-Biswas’s scheme [1], our scheme is highly efficient and provides more functionality features.

Table 9 Communication cost comparison among our scheme and existing related schemes

Conclusion

In this paper, we have proposed a robust user authentication with key agreement scheme in hierarchical multi-medical server architecture in TMIS in order to erase several security drawbacks and design flaws found in Amin-Biswas’s scheme. From the performance and functionality analysis, it is evident that our scheme provides more features and is efficient in communication and computation as compared to Amin-Biswas’s scheme and other related existing schemes. The rigorous formal security analysis using both BAN logic and random oracle, and informal security analysis show that our scheme has the ability to tolerate various known attacks. In addition, the simulation results using the widely-accepted AVISPA tool for the formal security verification reveal that our scheme is also secure against passive and active adversaries. Furthermore, our scheme supports dynamic medical server addition in the network after initial deployment, and password and biometric update phase correctly and effectively without further contacting the MRS. Thus, our scheme is very suitable for practical applications in TMIS.