1 Introduction

A modern healthcare system is highly important for the well-being of any country, especially in developing countries. Unfortunately, the mainstream of the healthcare industry is working at a sub-optimal level, as the use of health information systems (HIS) even at individual hospital/institution level where it is nearly non-existent [32]. Therefore, that is why there is a great need to improve the current system with information and communication technology.

National health information exchange (NHIX) is a rapidly evolving cyber-infrastructure technology enabling sharing of healthcare-related data within a geographic region electronically among healthcare-related autonomous entities, such as physicians, hospitals, test laboratories, health insurance companies, emerging health information organizations (HIO), and even government departments. A number of NHIX are currently being in the deployment process in USA under the federal initiative as the key cyber infrastructure for healthcare [30]. The health information technology (HIT) infrastructure is also under development in the United States [23, 38]. Its cornerstone is a national health information network (NHIN) initiative, which will create a national health information exchange (NHIX) system in the US [36, 38]. Health information exchange (HIX) is the meeting point technology for the mobilization of healthcare information transmitted electronically across organizations within a region, community, or hospital system [16]. The US HITECH Act is funding the building of this national health IT infrastructure, in which patients’ data are to fire across a national health information highway [31, 34].

One of the main problems is the numerous variety and formats of health-related data. Health level 7 (HL7) is an international organization, which has taken the responsibility to develop standards for the exchange of variety of electronic health data [33]. Because, nowadays, people travels different parts of the world frequently ever before, the demand for medical data exchange between different countries is becoming much greater. Then, during a foreign travel, a person may need medical attention. In such cases, doctors in the hospitals may need to have access to the previous history of the patient for proper treatment plans. To facilitate this process, clinical data must be exchangeable electronically in some standard format [36]. In this way, the integrity and permanence of patient’s health information can be maintained [27].

2 Existing work

With the rapid development in information and communication technologies, there is an ever growing demand for customized healthcare systems in medical industry. The demand for medical services and health promotions activities is also increasing with increase in population [27]. There is a need to cut down on monitory and time expanses of individuals and to form a communication bridge among patients and other entities of the system. Such system should provide seamless access to the information by any authorized entity, such as doctors provide treatment services to their patients after accessing the patient’s information [27, 36]. The main problem in these systems is that an unauthenticated entity must not be allowed access and also an authenticated entity must not be able to access information which is not authorized.

An authentication process is required for the medical entities to ensure that a particular user is authorized to access the data from MDB. Several authentication and key agreement schemes are proposed [2–5, 13–15, 17, 24] for different systems. Some of the authentication schemes are based on chaos theory [11, 29], because it has the better performance than the traditional cryptography approaches [11, 29]. Xiao et al. [39] introduced the authentication key agreement protocol based on chaotic maps using the random numbers in 2007. After the Xiao scheme, another user anonymity preserving authentication and key agreement scheme based on chaotic maps was introduced by Tseng et al. [35]. Niu et al. [28] proves that the scheme introduced by Tseng et al. was not be able to provide the user anonymity and he introduced his improved scheme by removing the flaws in Tseng et al.’s scheme. However, Xue et al. [41] also mention in his article that the Niu et al.’s scheme can be exposed in man-in-middle attack. Guo et al. [12] introduced the password authentication key agreement scheme using smart cards also based on chaotic maps. Lin [21] both introduced their updated versions of Guo et al.’s scheme to improve the deficiencies of user anonymity. Jiang et al. [18] proved that the scheme introduced by Hao et al. did not establish the session key properly and possible launch of stolen smart card attack. They tried to improve their scheme and to remove the flaws in Hao et al.’s scheme. After that Li et al. [20] presented that the schemes introduced by Jiang et al. were not be able to stop the service misuse attack from non-registered user and their scheme provides the user information during his authentication process. Li et al. adjusted some minor modifications in Lee’s scheme and introduce their enhanced scheme after addressing the limitations. In early 2015, Lu et al. [22] found some weaknesses, including: lack of local verification, vulnerability to impersonation attack, leakage of session key, etc., in Li et al.’s scheme. They further proposed an new scheme and stressed the merits of their scheme. However, Moon et al. [26] found that besides their claim, Lu et al.’s scheme cannot withstand server and user impersonation attacks. Furthermore, their scheme entails correctness issues and is not scalable. An improvement of Lu et al.’s scheme is also proposed by Moon et al. [26]. However, the scheme proposed by Moon et al. uses verification table on server side which effects the scalability and incurs the searching time during authentication. Furthermore, the use of the same parameters \(\mathrm{IM}_1\) and \(\mathrm{IM}_2\) during authentication makes the scheme traceable. This paper mainly focuses on an improved authentication scheme for the medical entities using medical drop box in NHIX.

In the remainder of this paper: Sect. 3 briefly presents some preliminaries about medical drop box, its security needs the notation guide, along with fundamentals of Chebyshev chaotic maps and hash functions. Section 4 presents a brief reviews of Moon et al.’s chaotic map-based authentication scheme, whereas cryptanalysis of Moon et al.’s scheme is solicited in Sect. 5. The proposed scheme is presented in Sect. 6. In Sect. 7, we present security analysis of proposed scheme, while its automated analysis is solicited in Sect. 8. The comparative performance analysis is illustrated in Sect. 9. Finally, a brief conclusion is made in Sect. 10

3 Preliminaries

This section explains the basic architecture for medical drop box in NHIX environments, the need of security for such systems, notations used throughout the paper and fundamental hard problems concerning hash functions, Chebyshev chaotic maps, and the conjoint model for adversarial capabilities.

3.1 Medical drop box

NHIX has the potential to improve the lives of millions of people. To meet the standards for the NHIX, MDB must support reliable and secure transfer of data among the various systems of the world and also facilitate to access and retrieval of data with all its privacy. MDB is a standard application implemented according to HL7 and HIT standards, so the information can be exchanged between the health service providers and health-related industry. The MDB is a small-scale exploration focused on one individual’s information. The MDB can be envisioned as a portable folder which will enable any person to carry all of his/her electronic medical information and share it with his/her medical service provider. However, this covering the necessities of the healthcare industry and allowing them to communicate clinical data internally as well as exchange of medical information with other parts of the world. Figure 1 shows the information access by medical entities through the MDB.

Fig. 1
figure 1

Access architecture of medical drop box

Full size image

3.2 Medical drop box security

Medical information security is the most important aspect in MDB for data exchange. Security of medical data in all level must be ensured during, i.e., access, transmission, and storage. Before an entity or a user executes a function for access or to exchange the information, the access control list and authentication process will execute to verify whether this entity has the permission to perform that operation. Therefore, the MDB makes sure that the entity is authenticated and eligible to perform the particular operation. The privacy of individual/patient and authenticity of medical entity is very important. However, as we have stated, the challenges are multifaceted and are extremely complex. In an effort to advance healthcare privacy and exchange of protected health information, we proposed a road map of how we could authenticate the medical entities of MDB. These entities are responsible for exchanging protected health information between different stakeholders/entities using MDB.

3.3 Notations

All notations used in this paper are itemized in Table 1.

3.4 Hash functions

A hash function \(H : \{0, 1\}^{*}\rightarrow Z_{q}^{*}\) produces fixed-size output code \(C =H(S)\) by taking random size input string S. The produced output is often designated as hash value or hash code. Trivial modification in the input string S can bring nontrivial change in the output C. Following are the characteristics to nominate a function as a secure hash function:

  • Computationally, it is effortless to compute \(C_t=H(P_t)\) if \(P_t\) and H(.) are specified.

  • It is tedious task to know two inputs \(P_1\) and \(P_2\), such that \(H(P_1)=H(P_2)\). This characteristic is recognized as collision resistance property (CRP).

Definition 1

(CRP for hash functions) Consider H(.) as a prearranged collision resistant (CR) secure hash function. The likelihood that \(\mathcal {A}\) (an adversary) can extract a pair \((P_1\ne P_2)\), where \(H(P_1)=H(P_2)\) is established as \(\mathrm{Advnt}^{\mathrm{HASH}}_{\mathcal {A}}(t)=\mathrm{Pr}0[(P_1,P_2) \Leftarrow _r \mathcal {A} : (P_1\ne P_2)\ \mathrm{and}\ H(P_1)=H(P_2) ]\), where \(\mathcal {A}\) can select any arbitrary pair \((P_1,P_2)\) through polynomial time t. Referring to the CR property, the advantage carried by \(\mathcal {A}\) is as follows: \(\mathrm{Advnt}^{\mathrm{HASH}}_{\mathcal {A}}(t)\le \epsilon \) for any sufficiently large \(\epsilon > 0\).

Table 1 Notation blueprint
Full size table

3.5 Chebyshev chaotic maps

Let k be an integer and r be a variable form a set \([-1,1]\), the Chebyshev polynomial \(\mathrm{Tn}(x): [-1, 1] \rightarrow [-1, 1]\) is defined as \(T_k(r)=\mathrm{cos}(k \mathrm{arccos}(r))\). Given \(n >= 2, T_0(r)=1\) and \(T_1(r)=r\), the recurrent relationship of Chebyshev polynomial map \(T_k:R\rightarrow R\) is defined as follows: \(T_k(r) = 2rT_{k-1} (r) - T_{k-2}(r)\). There are two main features pertaining to Chebyshev polynomial. (1) Chaotic feature the polynomial \(T_k(r): [-1, 1] \rightarrow [-1, 1]\) of degree k where \(k>=1\) represents a chaotic map with \(f*(r)=1/(\pi \sqrt{1-r^2})\) (invariant density) for all positive Lyapunov exponent k. (2) Semigroup feature the polynomial over an interval \([-\infty , \infty ]\) is defined as follows: \(T_k(r) = (2rT_{k-1} (r) - T_{k-2}(r)) \mathrm{mod}\ p\), where \(k>=2\), \(r\in [-\infty , \infty ]\), and p a large range prime number. Besides, \(T_x(T_y(r))= T_{xy}(r) =T_{y}(T_x(r)) \mathrm{mod}\ p\).

Definition 2

(Chebyshev chaotic map-based discrete logarithm problem (CMDLP)) Given the polynomial K and r, compute k, such that \(K=T_k(r)\). The likelihood that a polynomial time (t) bound \(\mathcal {A}\) (an adversary) can compute k is as given: \(\mathrm{Adv}_{\mathcal {A}}^{\mathrm{CMDLP}}(t) = \mathrm{Prb}[(\mathcal {A}(=K, r) = k: k\in Z_{p}, K=T_k(r)]\). The CMDLP supposition implies that \(\mathrm{Adv}_{\mathcal {A}}^{\mathrm{CMDLP}}(t)\le \epsilon \), for sufficiently large \(\epsilon >0\).

3.6 Adversarial model

In this paper, we have taken into consideration the conjoint model for adversarial capabilities as presented by [6, 9, 10]. Following are the considerations:

  1. 1.

    \(\mathcal {A}\) have control over entire public communication link. \(\mathcal {A}\) (an adversary) is capable to interrupt, rerun, amend, eliminate, or can transmit a new forged message.

  2. 2.

    The stored parameters in a smart card are liable to expose by \(\mathcal {A}\) (an adversary).

  3. 3.

    A user/server of the system can act as \(\mathcal {A}\) (an adversary).

  4. 4.

    The identities pertaining to users and server/s are known to insiders.

  5. 5.

    The private key of the server cannot be compromised.

4 Review of Moon et al.’s scheme

Registration, login, and authentication phases of Moon et al.’s scheme are presented in this section as follows:

4.1 Registration phase

The registration process is performed as follows:

  1. Step R1:

    \(\mathcal {U}_i\) provides scan of his/her \(\mathrm{BIO}_{i}\). Then, \(\mathcal {U}_i\) chooses the \(\mathrm{ID}_{i}\) and \(\mathrm{PW}_{i}\). \(\mathcal {U}_i\) proceeds and determines \(\mathrm{PWD}=h_{1}(\mathrm{PW}_{i}\Vert H(\mathrm{BIO}_{i}))\), then sends registration request in the form of \(\{\mathrm{ID}_{i}, \mathrm{PWD} \}\) to server \(\mathcal {S}\) over secure channel.

  2. Step R2:

    After receiving request from \(\mathcal {U}_i\), \(\mathcal {S}\) verifies the existence the of \(\mathrm{ID}_{i}\) in the repository. If \(\mathrm{ID}_{i}\) does not exist, \(\mathcal {S}\) produces unique random number \(k_\mathrm{u}\). Then, \(\mathcal {S}\) determines \(K=h_{1}(\mathrm{ID}_{i} \Vert \mathrm{PWD})\), \(\mathrm{IM}_{1}=K \oplus h_{1}(k_\mathrm{u})\), \(\mathrm{IM}_{2}=h_{1}(k_\mathrm{u}\Vert k_\mathrm{s}) \oplus h_{1}(k_\mathrm{s})\), and \(f = \mathrm{IM}_{1} \oplus h_{1}(\mathrm{ID}_{i} \oplus \mathrm{PWD}) \). At the end, \(\mathcal {S}\) store \(\{ \mathrm{ID}_{i} \oplus h_{1}(k_\mathrm{u}\Vert k_\mathrm{s}), k_\mathrm{u} \oplus k_\mathrm{s},h_{1}(k_\mathrm{u}\Vert k_\mathrm{s}) \}\) in its repository.

  3. Step R3:

    \(\mathcal {S}\) issue a smart card containing \(\{ \mathrm{IM}_{1}, \mathrm{IM}_{2}, f, h_{1}(.), h_{2}(.), H(.) \}\) and then send this smart card to \(\mathcal {U}_i\).

Fig. 2
figure 2

Moon et al.’s scheme

Full size image

4.2 Login and authentication phase

The login and authentication as illustrated in Fig. 2 is performed as follows:

  1. Step LP1

    User \(\mathcal {U}_i\) provides his/her \(\mathrm{ID}_{i}\) and \(\mathrm{PW}_{i}\) and imprints his/her biometrics impression as \(\mathrm{BIO}_{i}\), then computes \(\mathrm{PWD}=h_{1}(\mathrm{PW}_{i}\Vert H(\mathrm{BIO}_{i}))\), and verifies \(f \mathop {=}\limits ^{?} \mathrm{IM}_{1} \oplus h_{1}(\mathrm{ID}_{i} \oplus \mathrm{PW}_{i}) \), after successful verification, the \(\mathcal {U}_i\) steps forward and computes \(K=h_{1}(\mathrm{ID}_{i} \Vert \mathrm{PW}_{i})\). \(\mathcal {U}_i\) generates u and calculates \(R_{1}=\mathrm{ID}_{i} \oplus T_{i}(K)\) and \(R_{2}=h_{1}(\mathrm{ID}_{i} \Vert K \Vert T_{i}(K))\). At the end, \(\mathcal {U}_i\) sends login request towards server in the form of \(\{ \mathrm{IM}_{1}, \mathrm{IM}_{2}, R_{1}, R_{2} \}\).

  2. Step LP2

    The server \(\mathcal {S}\) receives the login request from \(\mathcal {U}_i\) and calculates \(h_{1}(k_{\mathrm{u}}\Vert k_{\mathrm{s}}) = \mathrm{IM}_{2} \oplus h_{1}(k_{\mathrm{s}})\). If computed \(h_{1}(k_{\mathrm{u}}\Vert k_{\mathrm{s}})\) is present in the repository, then \(\mathcal {S}\) proceeds and calculates \(K=\mathrm{IM}_{1} \oplus h_{1}(k_{\mathrm{u}})\) and \(T_{i}(K)=\mathrm{ID}_{i} \oplus R_{1}\). \(\mathcal {S}\) verifies \(h_{1}(\mathrm{ID}_{i} \Vert K \Vert T_{i}(K)) \mathop {=}\limits ^{?} R_{2}\), successful verification results in computation of \(\mathrm{IM}_{3} = T_{v}(K) \oplus \mathrm{ID}_{i}\), \(\mathrm{sk}= h_{2}(T_{i}(K),T_{v}(K), T_{uv}(K))\) and \(\mathrm{Auth}_{\mathrm{s}}=h_{1}(K\Vert T_{v}(K)\Vert \mathrm{sk})\). At the end, server generates challenge message in the form of \(\{\mathrm{IM}_{3},\mathrm{Auth}_{\mathrm{s}}\}\).

  3. Step LP3

    After getting challenge message from \(\mathcal {S}\), \(\mathcal {U}_i\) determines \(T_{i}(K) = \mathrm{IM}_{3} \oplus \mathrm{ID}_{i} \) and \(\mathrm{sk}=h_{2}(T_{i}(K),T_{v}(K), T_{uv}(K))\). Then, \(\mathcal {U}_i\) verifies \(h_{1}(K\Vert T_{v}(K)\Vert \mathrm{sk}) \mathop {=}\limits ^{?} \mathrm{Auth}_{\mathrm{s}} \), and after successful verification, it computes \(\mathrm{Auth}_\mathrm{u}=h_{1}(\mathrm{sk}\Vert T_{v}(K)\Vert K)\). \(\mathcal {U}_i\) sends computed \(\mathrm{Auth}_\mathrm{u}\) towards server.

  4. Step LP4

    \(\mathcal {S}\) receives \(\mathrm{Auth}_\mathrm{u}\) and verifies \(h_{1}(\mathrm{sk}\Vert T_{v}(K)\Vert K) \mathop {=}\limits ^{?} \mathrm{Auth}_\mathrm{u}\). Successful verification results in exchange of session key \(\mathrm{sk}= h_{2}(T_{i}(K),T_{v}(K), T_{uv}(K))\) between the user and server.

5 Cryptanalysis of Moon et al.’s scheme

This section highlights that Moon et al.’s scheme does not provide scalability and incurs the searching time during authentication. Moreover, the scheme is liable to traceability attack.

5.1 Stolen verifier attack

In Moon et al.’s scheme, server \(\mathcal {S}\) stores \(\mathrm{IM}_{1}\) and \(\mathrm{IM}_{2}\) in smart card and also maintains verifier table/database; therefore, stolen verifier attack can be attempted on Moon et al’s scheme. Because \(h_{1}(k_\mathrm{u})\) can be easily extracted from \(\mathrm{IM}_1\), similarly, by knowing public identity, \(h_{1}(k_\mathrm{u}\Vert k_\mathrm{s})\) can also be extracted from stolen verifier. Leakage of \(h_{1}(k_\mathrm{u}\Vert k_\mathrm{s})\) can be used to extract \(h_{1}(k_\mathrm{s})\) from \(\mathrm{IM}_2\). An adversary after getting \(h_{1}(k_\mathrm{s})\) can guess \(k_\mathrm{s}\) and verify his guessed value using \(h_{1}(k_\mathrm{s})\).

5.2 Scalability issue

Since in Moon et al.’s scheme, server maintains a verifier table for each unique user in table. Therefore, this verifier table impose limitations on number of users along with computation time to scan and match verifier table entities.

5.3 Traceability

Anonymity is subject to two aims: (1) user’s original identity cannot be exposed to \(\mathcal {A}\) (an adversary) and (ii) it cannot be known by \(\mathcal {A}\) whether or not two separate sessions are commenced by identical user. Moon et al. claimed their scheme to fulfill anonymity, but in login and authentication phase of their scheme, two parameters \(\mathrm{IM}_1\) and \(\mathrm{IM}_2\) are sent in request message from user. These two parameters remain the same in several login requests. Hence, their scheme does not fulfill a requirement to term it as anonymous. Hence, in their scheme, the user is traceable, which violates the user anonymity.

Fig. 3
figure 3

Proposed scheme

Full size image

6 Proposed scheme

This section presents the detail of improved scheme which is illustrated in Fig. 3 as follows:

6.1 Registration

  1. Step RS1

    The user \(\mathcal {U}_i\) chooses \(\mathrm{ID}_{i}\), \(\mathrm{PW}_{i}\), random r, and a secret key \(k_{\mathrm{u}}\). Then, \(\mathcal {U}_i\) provides scan of his/her biometrics as \(\mathrm{BIO}_{i}\) and determines \({\mathrm{PW}}_{i}'=h_{1}(\mathrm{PW}_{i}\Vert H(\mathrm{BIO}_{i}))\). After that \(\mathcal {U}_i\) sends registration request \(\{ \mathrm{ID}_{i}, \mathrm{PW}_{i}' \}\) to \(\mathcal {S}\) over protected channel.

  2. Step RS2

    Upon reception, \(\mathcal {S}\) computes \(K_{i}=h_{1}(\mathrm{ID}_{i}\Vert k_{\mathrm{s}})\oplus \mathrm{PW}_{i}'\). \(\mathcal {S}\) then stores \(K_{i}\), \(T_{k_\mathrm{s}}(r)\), r, \(h_1(.)\), and H(.) into smart card and handover it to \(\mathcal {U}_i\).

  3. Step RS3

    User \(\mathcal {U}_i\) determines \( f_{i}=h_{1}(\mathrm{ID}_{i}\Vert k_\mathrm{u}) \oplus \mathrm{PW}_{i}' \) and, \(\mathrm{IM}_{1}=k_{\mathrm{u}} \oplus h_{1}(\mathrm{PW}_i\oplus H(\mathrm{BIO}_i))\) using his/her private key \(k_{\mathrm{u}}\). At the end, \(\mathcal {U}_i\) stores computed \( f_{i}\) and \(\mathrm{IM}_{1}\) into smart card. Finally, smart card held by user \(\mathcal {U}_i\) contains \( \{f_{i}, \mathrm{IM}_{1}, h_{1}(.), h_{2}(.), H(.)\} \).

6.2 Login

The login phase proceeds as follows: \(\mathcal {U}_i\) enters the card into specific reader and provides \(\mathrm{ID}_{i}, \mathrm{PW}_{i}\). Then, \(\mathcal {U}_i\) scans his/her biometrics \(\mathrm{BIO}_{i}. \mathcal {U}_i\) computes \(k_\mathrm{u}=\mathrm{IM}_1\oplus h_{1}(\mathrm{PW}_{i}\oplus H(\mathrm{BIO}_i))\) and \(\mathrm{PW}_{i}'=k_\mathrm{u}\oplus h_{1}(\mathrm{PW}_{i}\Vert H(\mathrm{BIO}_i))\). \(\mathcal {U}_i\) then verifies whether \( f_{i}\mathop {=}\limits ^{?}h_{1}(\mathrm{ID}_{i}\Vert k_\mathrm{u}) \oplus \mathrm{PW}_{i}'\) is true or not. If it is true, then \(\mathcal {U}_i\) calculates \( h(\mathrm{ID}_{i}\Vert k_{\mathrm{s}})=k_{\mathrm{u}}\oplus K_i\oplus h_{1}(\mathrm{PW}_{i}\Vert H(\mathrm{BIO}_i))\). After that \(\mathcal {U}_i\) produces u and computes \(R_{1}= T_{\mathrm{u}}T_{k_{\mathrm{s}}}(r)=T_{uk_{\mathrm{s}}}(r)\), \( R_{2}= T_{\mathrm{u}}(r)\), \( R_{3}= \mathrm{ID}_{i} \oplus T_{uk_{\mathrm{s}}}(r)\) , \( and Auth_{\mathrm{u}}=h_{1}(h(\mathrm{ID}_{i}\Vert k_{\mathrm{s}})\Vert T_{uk_{\mathrm{s}}}\Vert t_{i})\). At the end, \(\mathcal {U}_i\) sends \(\{ R_{2}, R_{3}, \mathrm{Auth}_{\mathrm{u}},t_{i} \}\) to \(\mathcal {S}\), where \(t_i\) is freshly generated timestamp.

6.3 Authentication

Initially, the server \(\mathcal {S}\) checks the freshness of \(t_i\) if \(t_i\) is fresh \(\mathcal {S}\) responds to login request from \(\mathcal {U}_i\) as follows:

  1. Step AS 1

    \(\mathcal {S}\) computes \(R_{1}'=T_{k_{\mathrm{s}}}R_{2}=T_{k_{\mathrm{s}}u}(r)\), \(\mathrm{ID}_{i}=R_{1}' \oplus R_{3}\) using his/her private key \(k_\mathrm{s}\). \(\mathcal {S}\) authenticates \(\mathcal {U}_i\) after successful verification of \(\mathrm{Auth}_{\mathrm{u}}\mathop {=}\limits ^{?}h_{1}(h(\mathrm{ID}_{i}\Vert k_{\mathrm{s}})\Vert R_{1}'\Vert t_{i})\). Server \(\mathcal {S}\) then produces a random number v and calculates \(\mathrm{IM}_{2}=R_{1}'\oplus T_{v}(r)\), \(\mathrm{sk}=h_{2}(R_{1}'\Vert T_{v}(r)\Vert T_{uv}(r))\), and \(\mathrm{Auth}_{\mathrm{s}}= h_{1}(\mathrm{sk}\Vert R_{1}'\Vert T_{v}(r)\Vert T_{uv}(r))\). After that server \(\mathcal {S}\) sends a challenge message \(\{\mathrm{Auth}_{\mathrm{s}}, \mathrm{IM}_{2}\}\) to \(\mathcal {U}_i\).

  2. Step AS 2

    User \(\mathcal {U}_i\) after receiving challenge message computes \(T_{v}(r)=\mathrm{IM}_{2} \oplus R_{1}'\), \(\mathrm{sk}=h_{2}(R_{1}\Vert T_{v}(r)\Vert T_{uv}(r))\) and authenticates server after successful verification of \(\mathrm{Auth}_\mathrm{s}\mathop {=}\limits ^{?}h_{1}(\mathrm{sk}\Vert R_{1}'\Vert T_{v}(r)\Vert T_{uv}(r))\). Then, common session key is exchanged between \(\mathcal {U}_i\) and \(\mathcal {S}\).

7 Security analysis

Following subsections performs formal and informal security analysis of proposed scheme. Furthermore, the analysis is also verified using the widespread automated tool ProVerif in the following section.

7.1 Formal security analysis

The incumbent analysis to illustrate the security of proposed scheme is adopted from [25, 37]. The oracles for the said purposes are defined as follows:

  • Reveal: This oracle returns x from given \(T_x(r)\) and r unconditionally.

  • Extract: This oracle outputs a string S from the one-way hash function \(R=h(S)\) unconditionally.

Theorem 1

The proposed scheme is verifiable as secure besides an attacker \(\mathcal {A}\) for extraction of \(\mathcal {U}_i\)’s identity (\(\mathrm{ID}_{i}\)), the private key (\(k_\mathrm{s}\)) of \(\mathcal {S}\), and the computed session key SK between \(\mathcal {U}_i\) and \(\mathcal {S}\) under the hardness assumption of CMDLP and ruminating the secure hash function as random oracle.

Proof 1

Let an adversary \(\mathcal {A}\) is having the abilities to extract \(\mathcal {U}_i\)’s \(\mathrm{ID}_{i}\), \(\mathcal {S}\)’s secret key \(k_\mathrm{s}\), and the session key sk shared among \(\mathcal {U}_i\) and \(\mathcal {S}\). \(\mathcal {A}\) can execute the algorithmic experiment \(\mathrm{EXP1}^{\mathrm{CMDLP,OWHASH}}_{\mathcal {A},\mathrm{PCMAS}}\) against our proposed chaotic map-based authentication scheme. The success probability of said experiment is defined as follows: \(\mathrm{Suc}_1=|\mathrm{Prob}[\mathrm{EXP1}^{\mathrm{CMDLP,OWHASH}}_{\mathcal {A},\mathrm{PCMAS}}=1]-1|\). For the mentioned experiment, \(\mathcal {A}\) can make, \(q_{ex}\) and \(q_{rv}\), extract and reveal queries, respectively. Stating the experiment \(\mathrm{EXP1}^{\mathrm{CMDLP},\mathrm{OWHASH}}_{\mathcal {A},\mathrm{PCMAS}}\), \(\mathcal {A}\) can excerpt user identity \(\mathrm{ID}_{i}\), the shared key sk, the secret authentication parameter \(h(\mathrm{ID}_i\Vert k_\mathrm{s})\), and server’s private key \(k_\mathrm{s}\). If \(\mathcal {A}\) can: (1) invert the hash function and (2) break CMDLP. However, mentioning Definition 1 inverting one-way hash function is computationally infeasible. Likewise, stating Definition 2, breaking CMDLP is also computationally infeasible. Hence, proposed scheme is invincible against \(\mathcal {A}\) to derive \(\mathcal {U}_i\)’s \(\mathrm{ID}_{i}\), \(\mathcal {S}\)’s secret key \(k_\mathrm{s}\), and the session key sk shared among \(\mathcal {U}_i\) and \(\mathcal {S}\).

figure a

7.2 Informal security analysis

This subsection presents the security and correctness of improved scheme under the same considerations as discussed earlier in Sect. 5. The in-depth investigation reveals that the proposed scheme is capable to resist against recognized attacks. Table 2 provides a comparative overview of proposed scheme’s security with related schemes. The detailed description is as follows:

Table 2 Security Comparisons
Full size table

7.2.1 Anonymity and privacy

Since identity of user \(\mathcal {U}_i\) is not transmitted through public conduit, rather \(R_{2}\) and \(R_{3}\) are transmitted towards server \(\mathcal {S}\). Both of these parameters are generated uniquely during each session. Adversary \(\mathcal {A}\) can only violate the anonymity of \(\mathcal {U}_i\) once \(R_{1}\) is computed, but \(R_{1}\) calculation requires private key \(k_{\mathrm{s}}\). Therefore, proposed scheme proved to offer untraceability and anonymity.

7.2.2 Mutual authentication

User \(\mathcal {U}_i\) is authenticated by server \(\mathcal {S}\) after verifying \(\mathrm{Auth}_\mathrm{u}\mathop {=}\limits ^{?}h_{1}(h(\mathrm{ID}_{i}\Vert k_{\mathrm{s}}) \Vert R_{1}'\Vert t_{i})\). Calculation of \(\mathrm{Auth}_\mathrm{u}=h_{1}(h(\mathrm{ID}_{i}\Vert k_{\mathrm{s}})- \Vert T_{uk_{\mathrm{s}}}\Vert t_{i})\) demands valid smart card, password \(\mathrm{PW}_{i}\), and biometrics \(\mathrm{BIO}_{i}\) of legal user. Therefore, adversary \(\mathcal {A}\) can only betray server \(\mathcal {S}\) if he/she has smart card, password \(\mathrm{PW}_{i}\), and biometrics \(\mathrm{BIO}_{i}\) of user \(\mathcal {U}_i\). Considering the other side, \(\mathcal {U}_i\) authenticates \(\mathcal {S}\) by verifying \(\mathrm{Auth}_{\mathrm{s}}\mathop {=}\limits ^{?}h_{1}(\mathrm{sk}\Vert R_{1}'\Vert T_{v}(r)\Vert T_{uv}(r))\). This computation demands secret key \(k_{\mathrm{s}}\) of server \(\mathcal {S}\), as discussed in Sect. 7.2.1. Therefore, adversary \(\mathcal {A}\) must have private key \(k_{\mathrm{s}}\) of server \(\mathcal {S}\) to betray user \(\mathcal {U}_i\). Therefore, it can be calculated that only legitimate \(\mathcal {U}_i\) can clear authentication check from \(\mathcal {S}\) and vice versa. Moreover, \(\mathcal {U}_i\) is authenticated by server \(\mathcal {S}\) after verifying \(\mathrm{Auth}_\mathrm{u}\mathop {=}\limits ^{?}h_{1}(h(\mathrm{ID}_{i}\Vert k_{\mathrm{s}})\Vert R_{1}'\Vert t_{i})\). Calculation of \(\mathrm{Auth}_\mathrm{u}=h_{1}(h(\mathrm{ID}_{i}\Vert k_{\mathrm{s}})\Vert T_{uk_{\mathrm{s}}}\Vert t_{i})\) demands valid smart card, password \(\mathrm{PW}_{i}\), and biometrics \(\mathrm{BIO}_{i}\) of legal user. Therefore, adversary \(\mathcal {A}\) can only betray server \(\mathcal {S}\), if he/she has smart card, password \(\mathrm{PW}_{i}\), and biometrics \(\mathrm{BIO}_{i}\) of user \(\mathcal {U}_i\). On the other hand, user \(\mathcal {U}_i\) authenticates server \(\mathcal {S}\) by verifying \(\mathrm{Auth}_{\mathrm{s}}\mathop {=}\limits ^{?}h_{1}(\mathrm{sk}\Vert R_{1}'\Vert T_{v}(r)\Vert T_{uv}(r))\). This computation demands secret key \(k_{\mathrm{s}}\) of server \(\mathcal {S}\), as discussed in Sect. 7.2.1. Therefore, adversary \(\mathcal {A}\) must have private key \(k_{\mathrm{s}}\) of server \(\mathcal {S}\) to betray user \(\mathcal {U}_i\). Therefore, it can be calculated that only legitimate user can clear authentication check from \(\mathcal {S}\) and vice versa. Hence, proposed scheme offers mutual authentication.

7.2.3 Server and user impersonation attacks

Only authentic user \(\mathcal {U}_i\) can generate login request \(\{ R_{2}, R_{3}, \mathrm{Auth}_\mathrm{u},t_{i} \}\) and, in turn, only authentic server \(\mathcal {S}\) can reply login request with challenge message \(\{\mathrm{Auth}_{\mathrm{s}}, \mathrm{IM}_{2}\}\), as discussed in Sect. 7.2.2. Therefore, it is infeasible to launch impersonation attacks on the proposed scheme.

7.2.4 Privileged insider attack

User \(\mathcal {U}_i\) calculates \({\mathrm{PW}}_{i}'=h_{1}(\mathrm{PW}_{i}\Vert H(\mathrm{BIO}_{i}))\oplus k_{\mathrm{u}}\) and sends \({\mathrm{PW}}_{i}'\) along with \(\mathrm{ID}_{i}\) towards server \(\mathcal {S}\), since \({\mathrm{PW}}_{i}'\) calculation is done by concatenating \(\mathrm{PW}_{i}\) with \(H(\mathrm{BIO}_{i})\), and moreover, these concatenated values are further protected by hash function. It becomes very difficult for an adversary \(\mathcal {A}\) to calculate hash protected ingredients/values in polynomial time. Furthermore, server \(\mathcal {S}\) does not have direct access to these hash protected values. Hence, it can be concluded that proposed scheme overcomes the privileged insider attack.

7.2.5 Replay attack

If an adversary \(\mathcal {A}\) attempts to replay a former login request \(\{ R_{2}, R_{3}, \mathrm{Auth}_\mathrm{u},t_{i} \}\). \(\mathcal {S}\) will be able to identify replay message quickly after verifying freshness of the time stamp \(t_{i}\). Therefore, \(\mathcal {S}\) will be able to avoid replay messages. Hence, proposed scheme successfully turns down replay attack.

7.2.6 Stolen verifier attack

\(\mathcal {S}\) uses his secret key \(k_{\mathrm{s}}\) for manipulating login and authentication message and does not maintain verifier table. Therefore, it is confirmed that proposed scheme withstands stolen verifier attack.

7.2.7 Denial of service attack

The smart card verifies three entries identity \(\mathrm{ID}_{i}\), password \(\mathrm{PW}_{i}\), and biometrics \(\mathrm{BIO}_{i}\). The smart card will instantly reject the request if any one of these three entries is invalid. Hence, \(\mathcal {U}_i\) will be safe from denial of service attack due to wrong entry.

7.2.8 Password guessing attack

Suppose an adversary \(\mathcal {A}\) excerpts \(f_{i}\), \(\mathrm{IM}_{1}\), \(T_{k_{\mathrm{s}}}(r)\), r stored in smart card. Then, \(\mathcal {A}\) is required to calculate \({\mathrm{PW}}_{i}'=h_{1}(\mathrm{PW}_{i}\Vert H(\mathrm{BIO}_{i}))\) and it is difficult to do so, because \(\mathcal {A}\) has to get password \(\mathrm{PW}_{i}\) and \(H(\mathrm{BIO}_{i})\) that are hash protected. Hence, offline password guessing attack is infeasible. Likewise, permission for invalid request makes it hard to initiate online password guessing attack. Hence, proposed scheme withstands both offline and online guessing attacks.

Fig. 4
figure 4

Declarations

Full size image

8 Security validation through ProVerif

In this section, automated security analysis of proposed scheme is done through ProVerif [1, 19], the tool widely used for automated security analysis. It can be applied to a variety of authentication schemes to verify the security and privacy. ProVerif also provides the support for different cryptographic primitives like: hash functions, symmetric and asymmetric cryptography, bit-commitment, and digital signature. The tool has the capability to evaluate the reachability stuff, communication declarations, and observational correspondence [40]. The reasoning capabilities are very much useful in security domain, because they permit to consider the emerging properties of confidentiality, privacy, traceability, verifiability, and authentication in analysis process. ProVerif is also used as a verifier for cryptographic protocols with fully automatic with respect to an boundless sessions and message size [7, 8]. The simulation model of ProVerif is composed of three sections: (i) the declaration section; (ii) the process section; and (iii) main section. The declaration section as shown in Fig. 4 is used to declare all the variables, names, and constants along with cryptographic functions modeled as constructors, destructors, and equations. Likewise, process section as shown in Fig. 5 is used to define the working of each involved process and main section defines the working of protocol to be investigated. We have imprinted all the variables, names along with two communication channels in declaration section. In process section, we defined the server and user processes (ServerS and UserUx), respectively. Finally, to analyze the proposed scheme, three queries are simulated in main part as shown in Fig. 6; the results are solicited as follows:

  1. 1.

    RESULT inj-event(endServer(id)) \(==>\) inj-event(beginServer(id)) is true.

  2. 2.

    RESULT inj-event(endUser(id_1265)) \(==>\) inj-event(beginUser(id_1265)) is true.

  3. 3.

    RESULT not attacker(SK[]) is true.

(1) and (2) shows that the processes relating to \(\mathcal {S}\) and \(\mathcal {U}\) are executed and sacked normally, while (3) illustrates that attack query on session key SK is not successful. Hence, proposed scheme is correct and robust against session key discloser attack.

Fig. 5
figure 5

Processes

Full size image
Fig. 6
figure 6

Main

Full size image

9 Performance analysis

Performance comparison in terms of computation is presented in this section. For quick reference, formal computational terms are listed below:

  • \(T_{\mathrm{C}}\) represents time for determining Chebyshev.

  • \(T_{\mathrm{ED}}\) represents time required to perform encryption and decryption.

  • \(T_{\mathrm{H}}\) refers to time requirement for one-way hash functions.

Table 3 Computation comparisons
Full size table

The performance comparison illustrated in Table 3 depicts that proposed scheme is lightweight in terms of computation cost as compared to listed-related schemes. Therefore, proposed scheme can be considered to perform better than the rest of the related schemes, although computation cost of proposed scheme is slightly greater than Moon et al. [26], but it is proved earlier in this paper that Moon et al.’s scheme does not provide many security features, whereas proposed scheme provides security against recognized security threats and, in turn, offers robustness and efficiency.

10 Conclusion

In this paper, we have analyzed a recent authentication scheme for TMIS based on Chebyshev chaotic maps. It has been proved that Moon et al.’s scheme does not provide proper user anonymity and is having some issues relating to scalability. Furthermore, their scheme is vulnerable to stolen verifier attack. Then, we proposed an improved scheme for accessing medical drop box data, which has been proved invincible against familiar attacks by rigorous informal and formal analysis backed by automated analysis performed in ProVerif.