A provably lightweight mutually authentication and key establishment protocol using extended chaotic map for telecare medicine information system

Abstract

Telecare Medicine Information System (TMIS) provides patient’s efficient and convenient e-healthcare services where the patient private health related information is stored in TMIS server. However, it has also resulted a major privacy and security concerns. Thus, by considering privacy preserving and user anonymity, a major concern, a secure mutual authentication and key establishment protocol needed for creating a secure connection between patients and medical TMIS servers. In research we found major security flaws in already existing authentication schemes. To ensure user anonymity, we propose an efficient, provably secure, lightweight mutually authentication and key establishment protocol using extended chaotic map for TMIS. As the unpredictable behavior of extended chaotic map can provide a possible security solution, a contemporary cryptography. For security and correctness proof of the proposed authentication protocol, BAN (Burrows–Abadi–Needham) logic is adopted. Furthermore, the proposed authentication protocol is secure against various well-known attacks which is proved by formal and informal security analysis. The AVISPA (Automated validation of internet security protocols and application) is utilized to test the correctness of the proposed authentication protocol. Moreover, the proposed protocol satisfies the most required security requirements, with less communication and computation overhead, and outperforms the other existing authentication techniques in terms of computation, communication, storage overheads, and security.

1 Introduction

In E-healthcare services like TMIS, we may reduce the time-consuming process such as visiting hospitals, getting medical practitioners' appointment, waiting in queue for a long time, and so on [1, 2]. Since, the introduction of the Internet and communication technologies, internet-based applications became popular and convenient means for consumers to access services from any location. E-healthcare apps are now available for various medical services such as telemedicine, ambulance services, patient healthcare services, physician advice, and TMIS. Patient can access health-related information remotely from anywhere across the world with the E-healthcare service. Interaction between patient at home and physicians from hospitals is feasible via a public communication channel. Because medical data, like electronic health records are transmitted through a public network, an adversary may intercept it. Thus, medical data can be eavesdropped, modified, deleted, and diverted by an enemy. As a result, preserving patient private information from a potential attacker requires an extreme level of confidentiality. Furthermore, the COVID-19 phase [3] is causing problems in several countries across the world. An intelligent method such as TMIS is used widely all over the world. There are some common problems like denial of service (DoS) from the TMIS server, since many patients can use the TMIS server simultaneously, so to protect patient’s electronic medical health records and data security for the E-healthcare system is the critical issue. Only authenticated TMIS users, such as patients, physicians, and healthcare staff, may access these services, requiring a robust authentication system. The correct session key exchange techniques are necessary for the user's authenticity to be confirmed. Moreover, authentication tokens such as smartcards, passwords, and biometrics are utilized to validate a specific user. Thus, the resilient scheme should have the following characteristics:

• 1. A secure authentication and login process.

• 2. Resistant to password guessing and replay attacks.

• 3. Authentication is required for both the patient and the authentication server.

• 4. Agreement and validation of the session key.

• 5. The cost of communication, processing, and storage must be kept to a minimum.

The uniqueness of biometric keys (such as fingerprints, faces, iris, hand geometry, and palm prints) increases their use in authentication procedures [4]. These keys aid in identifying the proper user and improving authentication protocol security.

The biometric keys provide many benefits that have received a great deal of research are as follows;

• 1. No need to remember biometric keys.

• 2. Forging biometric keys is exceedingly challenging.

• 3. Biometric keys keep their uniqueness.

• 4. Biometric keys are difficult to guess.

Only the TMIS medical server should be trusted, and no internal user of the medical server should be able to predict the user's password or identity. The Password update phase might be helpful, if the patient chooses to refresh their password. We know that RSA and Elliptic Curve Cryptography (ECC) provide the same level of security. ECC, on the contrary is better suited than RSA because it uses two techniques. One is used to multiply an ECC point by a scalar, while the other is used to add two points on the Elliptic curve, whereas RSA only allows exponentiation [5]. ECC provides a key that is just 160 bits long, whereas RSA uses a key that is 1024 bits long and takes longer to generate than ECC. The hash function and ECC processes are utilized to provide a user authentication mechanism for login. Furthermore, the chaotic map operation is much more efficient and effective of computing than ECC and RSA [6,7,8,9], making it accurately adapted for developing a mutual authentication scheme. According to [10], RSA and ECC are the most suitable algorithm for mobile devices where the power is an issue also they have applied simplified Swarm Optimization and Particle Swarm Optimization techniques to Enhance RSA and ECC performance. In [11], states that a mix of provably secure elliptic curves with cyclotomic points and elliptic curves combined with encryption provides increased security. By establishing a connection between an elliptic curve's coordinate and a variable in the polynomial, it leverages the Weierstrass form of an elliptic curve and cyclotomic polynomial to construct a structure. Thus, we can conclude, RSA and ECC both are useful for TMIS services.

As shown in Fig. 1 the architecture of TMIS, patient sharing their medial information with the TMIS medical Server, Physician can access this critical patient information via a public channel, moreover, an attacker is also shown in this system. Patients connect to the medical server using their smartcards from a distance. The smartcard is lightweight and portable at a low cost. The accused of stealing smartcard attack, on either hand, is a significant security flaw in the smartcard-based user login system since it gives the attacker access to all of the critical data contained on the smartcard. This issue is addressed by using mutual authentication via a smartcard. A password guessing vulnerability, in addition to the lost smartcard attack, is a key security problem in smartcard-based authentication systems. Many users are likely to choose weak passwords which can be guessed in polynomial time using virtual memory. To prevent against these known attacks, the authentication protocol masks sensitive data with hash algorithms and XOR operations before storing it in smartcard memory. As a result, the attacker can't read plain messages from the smartcard's memory. Adding biometrics to the login process can improve things even more [12]. Biometric security is improved because it’s not feasible to steal, forget, lose, or copy, and impersonate it is exceedingly difficult. Guessing the biometric is also tricky. Authentication and safe data transfer are essential for the remote patient. The password, although being safe, is susceptible to off-line dictionary attacks.

Fig. 1

The architecture of telecare medicine information system

A biometric security system based on fingerprint, iris, retina and a password has been developed to avoid smartcard theft and password guessing attacks. Mutual authentication utilizing both password and user identification is called as two-factor authentication. There are still fewer security vulnerabilities [13,14,15]. We propose a novel three-factor authentication technique to solve these limitations, which combines a password, identity, and a third element known as biometric to provide utterly safe authentication. This three-factor authentication method is secure against a wide range of security threats.

1.1 Motivation

Due to expensive ECC point multiplication or/and modular exponentiation operations. Extended chaotic map-based user authentication methods are more efficient than ECC or RSA-based schemes, since the key size in Chebyshev chaotic maps is lower than in ECC and RSA. Moreover, we discovered that most chaotic map-based user authentication systems remain vulnerable to several common attacks and cannot offer good user anonymity or smartcard revocation methods [16]. These considerations lead us to propose a low-cost, high-efficiency extended chaotic map-based novel authentication scheme for TMIS server, which will address the security limitations in previous approaches.

1.2 Contributions

Although numerous studies in TMIS security have been published, most of the authentication schemes do not provide maximal security features with minimal computing cost. They are therefore unsuitable for TMIS, i.e., E-healthcare systems.

The main key contributions in this research are as follows:

• 1. To design a robust security scheme that is resistive against various known security threats.

• 2. A robust mutual authentication mechanism with key establishment capability is developed to utilize in TMIS.

• 3. An informal analysis is offered for several security issues of the proposed protocol.

• 4. The validity of each entity's mutual authentication is proposed using the formal approach BAN logic.

• 5. Finally, the proposed extended chaotic map authentication scheme for TMIS is compared with several existing schemes.

1.3 Model for attacker

The experimentation of the authentication scheme suggested in this paper occurs via insecure communication. We assume an adversary has the following capabilities. The following are some of the legitimate assumptions:

• 1. An adversary can access data from a stolen or lost smartcard by monitoring power usage.

• 2. An enemy can intercept messages sent between entities through a public communication channel.

• 3. An adversary can alter, resend, and redirect eavesdropped communications.

The organization of this paper is as follows: Related works are discussed in Sect. 2. The characteristics of the Chebyshev chaotic maps, Extended Chaotic map operation, one-way chaotic hash function, and tree-based identity techniques are discussed in Sect. 3. Section 4 explains our user/client authentication scheme for TMIS using one-way chaotic hash, extended chaotic map, and tree-based identity approach. In Sect. 5, presents a various informal and formal security analysis of the proposed authentication scheme. Formal security validation is discussed in Sect. 6. Section 7 highlights the comparison of our authentication scheme with state-of-the-arts. In the last section, we conclude the paper.

2 Related works

In this section, we discuss the existing authentication schemes. In [17], a safe, anonymous authentication mechanism for patients at home is developed. In the same year, the protocol security of [17] is investigated in [18] and discovered that it is two-factor authentication susceptible. To fix the issue, a novel authentication scheme designed for two-factor authentication. In [19], the security aspects of [18] is examined and authors created a password-guess resistant protocol. However, communicating anonymously was not addressed in the developed protocol. Progressively, a secure and efficient lightweight authentication mechanism that protects anonymity in TMIS is proposed in [20]. Further, [21] revealed that identity may be traced in [20] using password and dictionary guesses, in addition to lost/stolen smart card information. Authors, attempted to remove the majority of current threats by developing an anonymous authentication system. Subsequently, authors in [22] revealed that [20] is susceptible to identification and password guessing attacks, in addition to data retrieved from smartcard. As a result, new TMIS system which is more efficient is presented.

In [23], the chaotic map-based authentication mechanism was proposed. Eventually, [24] identified the flaws in [25], the protocol potentially susceptible to stolen smartcards. Further, an effective and secure chaotic map-based authentication protocol and key agreement technique for healthcare was presented in [26]. However, authors in [27] discovered that the system is susceptible to password guessing, impersonation, and impersonation-related attacks. In [28], authors investigated the security breaches in [20], and authentication protocol is vulnerable to password guessing, identity guessing, and stolen/lost smartcard attacks and further presented a TMIS RSA-based authentication technique. Moreover, another TMIS authentication system is proposed in [29]. Leveraging extended chaotic maps, [30] create a trustworthy and efficient certificate-based authentication scheme solution for HIPAA privacy/security rules. In [31], an authentication method based on a verifiably secure Chebyshev chaotic map (CCM) is proposed. This method converted the standard Chebyshev chaotic map key pair into a private key and merged two private keys to create a one-time key that was utilized to encrypt authentication data. A key agreement method is proposed in [32] wherein ECC is utilized for smart grid authentication. Here, the concept of bi-linear paring is not applied, results are verified on ProVerif. Further, light weight ECC is adopted to provide secure communication for smart healthcare under IoT enabled medical system in [33]. The system compatibility can be realized for real time scenario by implementing on suitable hardware.

According to [34], image watermarking is a potential tool for protection, content authentication, fingerprinting, and intellectual property protection. These watermarking techniques may also be more effective for TMIS. The proposed scheme in [35] adopts a dynamic authentication key agreement strategy to preserve the privacy and security of the IoT sensing data that is distributed among the sensors collected by users in the Industrial Internet of Things (IIoT) infrastructure domain, allowing authenticated users to access the data that is distributed among various IoT sensing devices.

A secure 3-factor authentication solution for healthcare services is developed in [36]. Further, [37] examined the protocol's security of [27] and found it vulnerable to password guessing, identity guessing, impersonation, and stolen smartcards attacks. In [38], an efficient, provably secure verifier-based 3-party authentication technique that uses partial discrete logarithm (PDL) to exchange data in TMIS is proposed. This technique does not utilize any server's public keys and requires additional messages and numbers for key confirmation rounds. Moreover, a novel RSA-based authentication technique is proposed in [39]. However, it relies on modulo operations, reducing the protocol's performance due to expensive modulo exponentiation. We present some comparative analysis in terms of security features in Table 1.

Table 1 Comparison of existing schemes

3 Preliminaries

In this section, we study Chebyshev chaotic maps and Chebyshev polynomial maps since they will be utilized in the suggested approach. The notations utilized for the scheme are shown in Table 2.

Table 2 The notation used in the proposed authentication scheme

3.1 Chebyshev chaotic maps

We extend on the function of Chebyshev polynomials [44] in this paper. In a variant ${\mathcalligra{z}}$, a polynomial (${\mathcalligra{z}}$) is a Chebyshev polynomial with a degree ${\mathcalligra{k}}$. Let us consider the exponent ${\mathcalligra{z}}$ and ${\mathcalligra{z}}$ ∈ [− 1, 1], as well as the integer n. The polynomial Chebyshev is defined as (${\mathcalligra{z}}$) = cos(${\mathcalligra{k}}$ × arccos(${\mathcalligra{z}}$)), ${\mathcalligra{T}}$₀₍${\mathcalligra{z}}$₎ = 1, ${\mathcalligra{T}}$₁₍${\mathcalligra{z}}$₎ = ${\text{x}}$,.., ${\mathcalligra{T}}$${\mathcalligra{k}}$₍${\mathcalligra{z}}$₎ = 2${\mathcalligra{z}}$${\mathcalligra{T}}$${\mathcalligra{k}}$₋₁₍${\mathcalligra{z}}$₎ − ${\mathcalligra{T}}$${\mathcalligra{k}}$₋₂₍${\mathcalligra{z}}$₎;${\mathcalligra{k}}$ ≥ 2.

The trigonometric [45] functions cos(${\mathcalligra{z}}$) and arcos(${\mathcalligra{z}}$) are defined as arcos: [− 1, 1] → [0, π] and cos: ℛ → [− 1, 1]. Chebyshev polynomials e has two important features [46, 47]: chaotic and semi-group properties.

3.2 Chaotic property

${\mathcalligra{T}}$${\mathcalligra{k}}$ represents a Chebyshev polynomial map: [− 1, 1] → [− 1, 1] is a chaotic map of degree ${\mathcalligra{k}}$ > 1 with the exponent density function being ${\mathcalligra{f}}$ ∗ (${\text{x}}$) = 1 (π√1 − ${\mathcalligra{z}}$2) and a positive Lyapunov exponent λ = In ${\mathcalligra{k}}$ > 0.

3.3 Semi-group property

${\mathcalligra{T}}$_ℓ (${\mathcalligra{T}}_{{\text{w(z)}}}$) = cos (ℓ cos − 1(cos(${\mathcalligra{w}}$cos − 1(${\mathcalligra{z}}$)))) = cos(ℓ${\mathcalligra{w}}$ cos − 1(${\mathcalligra{z}}$)) = ${\mathcalligra{T}}_{{\text{wl(z)}}}$ =  ${\mathcalligra{T}}_{{\mathcalligra{w}}}$(${\mathcalligra{T}}_{{\text{l(z)}}}$), where ${\mathcalligra{w}}$ and ℓ are positive integers and ${\mathcalligra{z}}$ ∈ [− 1, 1]. Chebyshev polynomials have two main issues, both of which are difficult to solve in polynomial time:

• 1. DL's (Discrete Logarithms) goal is to find an integer ${\mathcalligra{w}}$ for which the aim is (${\mathcalligra{z}}$) = ${\mathcalligra{y}}$for two known components ${\mathcalligra{z}}$ and ${\mathcalligra{y}}$.

• 2. The goal of DHP (Diffie-Hellman problem’s) task is to the estimation of exponent ${\mathcalligra{T}}_{{\text{l(z)}}}$ for three known components ${\mathcalligra{z}}$, ${\mathcalligra{T}}_{{\text{w(z)}}}$ and ${\mathcalligra{T}}_{{\text{l(z)}}}$.

3.4 Extended chaotic maps

Zhang et al. [48] demonstrated that the semigroup condition holds for chebyshev polynomials in the interval (− ∞, + ∞).

((${\mathcalligra{z}}$) = (2${\mathcalligra{z}}$${\mathcalligra{T}}$${\mathcalligra{k}}$₋₁₍${\mathcalligra{z}}$₎ − ${\mathcalligra{T}}$${\mathcalligra{k}}$₋₂₍${\mathcalligra{z}}$₎) (mod ${\mathcalligra{q}}$) where ${\mathcalligra{k}}$ ≥ 2, ${\mathcalligra{z}}$ ∈ (− ∞, + ∞), and prime number ${\mathcalligra{q}}$ are all prime numbers.

Now, we may establish the recurrence relations, ${\mathcalligra{T}}_{{\text{k(z)}}}$ = 12${\mathcalligra{T}}_{{\text{k - 1(z)}}}$−  ${\mathcalligra{T}}_{{\text{k - 2(z)}}}$d 13), where ${\mathcalligra{T}}$₁₍${\mathcalligra{z}}$₎ = 6 and ${\mathcalligra{T}}_{{\text{0(z)}}}$= 1, where  = 13. The values of (${\mathcalligra{z}}$) are 1, 6, 6, 1, 6, 6,…, which are created by the recurrence stated before ${\mathcalligra{T}}$ = 3. Here, [49, 50] is the selected timeframe ${\mathcalligra{T}}_{{\text{l(z)}}}$≡ ${\mathcalligra{T}}_{{\text{wl(z)}}}$ ≡ ${\mathcalligra{T}}_{{\mathcalligra{w}}} ({\mathcalligra{T}}_{{{\mathcalligra{l}}({\mathcalligra{z}})}} )$ (mod ${\mathcalligra{q}}$).

The improved Chebyshev polynomials can still change under composition, and they still have semigroup properties.

3.5 Chaotic hash function $({\mathcalligra{h}}_{\boldsymbol{\varsigma }})$

$${\mathcalligra{y}}_{i+1}=\left\{\begin{array}{c}\genfrac{}{}{0pt}{}{\frac{{\mathcalligra{y}}_{i}}{\gamma },\mathrm{ if }0\le {\mathcalligra{y}}_{i}<\gamma }{\frac{{\mathcalligra{y}}_{i}-\gamma }{0.5-\gamma },\mathrm{ if }\gamma \le {\mathcalligra{y}}_{i}<0.5 }\\ \genfrac{}{}{0pt}{}{\frac{1-{\mathcalligra{y}}_{i}-\gamma }{0.5-\gamma },\mathrm{ if }0.5\le {\mathcalligra{y}}_{i}<1-\gamma }{\frac{1-{\mathcalligra{y}}_{i}}{\gamma },\mathrm{ if }1-\gamma \le {\mathcalligra{y}}_{i}<1}\end{array}\right.$$

Chaotic hash function is one-dimensional and piecewise linear map [38, 51, 52, 53, 54], and [55], where _i ∈ [0, 1] and γ ∈ (0, 0.5) are the control parameter. The parameter γ in _i+1 ensures that the map will operate in a chaotic state while using 0 < γ < 0.5. The map's self-transformation is done at [0, 1], using only one parameter γ. The transformation begins with using the chaining variables ₀ and _i, which serve as indicators in a one-way hash method.

3.6 Notations

A lightweight mutually authenticated & key-establishment (AKE) protocol using extended chaotic map for TMIS for fuzzy-entity information sharing. Let's look at how often notations are specified, as they will later be used when we get to the details of our new scheme. For simplicity, $[x, y]$ corresponds to $\{ x, x+1, ... ,y \}$  and $[x]$ corresponds to n$[ 1,x ]$. For every$\mathcalligra{i}\mathcalligra{d} =({\mathcalligra{i}\mathcalligra{d}}_{1},{\mathcalligra{i}\mathcalligra{d}}_{2},...,{\mathcalligra{i}\mathcalligra{d}}_{\mathcalligra{k}})$, where $\mathcalligra{i}\mathcalligra{d}$ is an identity vector, let ${S}_{\mathcalligra{i}\mathcalligra{d}}=\{{\mathcalligra{i}\mathcalligra{d}}_{1},...,{\mathcalligra{i}\mathcalligra{d}}_{\mathcalligra{k}}\}$ is the set of$(\mathcalligra{i}\mathcalligra{d})$. The$\mathcalligra{i}\mathcalligra{d}$’s location record in a tree is defined by${I}_{\mathcalligra{i}\mathcalligra{d}} =\left\{i : {\mathcalligra{i}\mathcalligra{d}}_{i} \in {S}_{\mathcalligra{i}\mathcalligra{d}}\right\}$. An identified receiver formulate a subtree related to the tree-based encryption technique [56,57,58,59]. $\mathcalligra{i}\mathcalligra{d}$ and respective places of receivers are joined into${\mathbb{T}}$. The legitimate ${\mathbb{T}}$ must cover the root node. From this we depict that PKG manages the structure. Similarly, identity set of ${\mathbb{T}}$ and location indices of ${\mathbb{T}}$ are expressed by ${S}_{\mathbb{T}}={\cup }_{\mathcalligra{i}\mathcalligra{d}\in {\mathbb{T}}}{S}_{\mathcalligra{i}\mathcalligra{d}}$ and${I}_{\mathcalligra{i}\mathcalligra{d}} =\{i : {\mathcalligra{i}\mathcalligra{d}}_{i} \in {S}_{\mathbb{T}}\}$. The symbolizations here can be expressed as $Sup (\mathcalligra{i}\mathcalligra{d})=\{({\mathcalligra{i}\mathcalligra{d}}_{1},{\mathcalligra{i}\mathcalligra{d}}_{2},...,{\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{k}}^{\mathrm{^{\prime}}}}) : {\mathcalligra{k}}^{\mathrm{^{\prime}}} \le \mathcalligra{k}\}$ to indicate the superiority of$\mathcalligra{i}\mathcalligra{d} =({\mathcalligra{i}\mathcalligra{d}}_{1},{\mathcalligra{i}\mathcalligra{d}}_{2},...,{\mathcalligra{i}\mathcalligra{d}}_{\mathcalligra{k}})$. Subtree ${\mathbb{T}}$'s predictable receivers are categorized as$Sup ({\mathbb{T}})= {\cup }_{\mathcalligra{i}\mathcalligra{d}\in {\mathbb{T}}} Sup (\mathcalligra{i}\mathcalligra{d})$.We present here the symbolizations that are appropriate for the proposed client authentication scheme based on subtree. Suppose that users are structured as shown in Fig. 2 in a tree structure [52]. The ${S}_{\mathcalligra{i}\mathcalligra{d}} =\left\{\mathcalligra{B},\mathcalligra{F}\right\}$ and ${I}_{\mathcalligra{i}\mathcalligra{d}} =\left\{2, 6\right\}$ are used to specify a known user with$\mathcalligra{i}\mathcalligra{d} =\left(\mathcalligra{B},\mathcalligra{F}\right)$. The$Sup \left(\mathcalligra{i}\mathcalligra{d}\right)=\left\{\left(\mathcalligra{B}\right), \left(\mathcalligra{B},\mathcalligra{F}\right)\right\}$, a set is created by the user involving superiors of him/her. When message sent by the data owner to receivers set in a subtree i.e.${\mathbb{T}} =\left\{\left(\mathcalligra{A}\right)\left(\mathcalligra{B},\mathcalligra{F}\right), \left(\mathcalligra{B},\mathcalligra{G}\right)\right\}$. Then, ${\mathbb{T}}$'s identity set is denoted by${S}_{\mathbb{T}} =\left\{\mathcalligra{A},\mathcalligra{B},\mathcalligra{F},\mathcalligra{G}\right\}$, and ${\mathbb{T}}$'s position indices are represented by ${I}_{\mathbb{T}}=\{1, 2, 6, 7\}$ whereas superiors of ${\mathbb{T}}$'s are expressed by$Sup({\mathbb{T}}) = \{\left(\mathcalligra{A}\right), \left(\mathcalligra{B}\right),\left(\mathcalligra{B},\mathcalligra{F}\right), \left(\mathcalligra{B}, \mathcalligra{G}\right) \}$, we see user agreement towards data owner is conveyed.

Fig. 2

A Tree-based identity approach authentication scheme representation example

4 Proposed protocol

This section proposes a lightweight mutually authentication and key establishment (AKE) protocol using an extended chaotic map for TMIS. Secure communication between the client and server is a primary concern in the proposed scheme. There are five major phases in the proposed scheme:

Phase 1 (Initial setup phase): TMIS registration center sets up the parameters in off-line mode.

Phase 2 (Client registration phase): Client (Patient/ Doctor) gets registered with the registration center (TMIS Server) to avail of the healthcare services.

Phase 3 (Login phase): Client (Patient/Doctor) login takes place to use the TMIS services.

Phase 4 (Authentication phase): TMIS server and client authenticate each other. After authentication, a random session key is generated.

Phase 5 (Password update phase): Legitimate client can update their password. Before updating the password, the client’s authenticity needs to be verified.

4.1 Initial setup phase

A large prime ${\mathcalligra{q}}_{1}$ chooses by the TMIS server and also constructs a prime field ${Z}_{{\mathcalligra{q}}_{1}}^{*}$ and selects his/her private key${\varvec{\beta}} \in { Z}_{{\mathcalligra{q}}_{1}}^{*}$. The server defines a function ${\mathcalligra{h}}_{\varsigma } : {\{ 0 , 1 \} }^{*}\to {Z}_{{\mathcalligra{q}}_{1}}^{*}$ as a one-way collision resistant chaotic hash function and a chaotic map $\mathcalligra{T}$ on (− ∞, ∞) as a Chebyshev polynomial.

$${\mathcalligra{T}}_{m} \left( U \right) = \left[ {2U{\mathcalligra{T}}_{{m - 1}} \left( U \right) - {\mathcalligra{T}}_{{m - 2}} \left( U \right)} \right]\left( {\bmod q_{1} } \right) for{\text{~U}} \in \left( { - \infty, \infty } \right)$$

In the proposed system, TMIS user uses fingerprint as a biometric identification. Due to some technical deficiency, sometimes same users' biometric may not match as discussed in [36, 40]. As studied, some pattern matching techniques were developed for such similarity of two biometric authentications of same user. Thus, the system has produced the unique output using pattern matching techniques. From this outstanding output, calculate a Bio-Hash (${bio}_{{\mathcalligra{C}}_{\mathcalligra{i}}})$ unique value for the users Client ${\mathcalligra{C}}_{\mathcalligra{i}}$.

4.2 Client registration phase

To obtain the trusted TMIS services, a new client (patient/doctor) need to register themselves as shown in Fig. 3. The registration phase of the AKE (authentication and key establishment) protocol creates a platform for the Client and server to share secret credentials. They can use their optimum privileged credentials during login and authentication to make the computation process more accessible if they share them.

Fig. 3

Registration phase

Step RP1: The Client ${\mathcalligra{C}}_{\mathcalligra{i}}$ selects his/her identity $({\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}\in Sup \left({\mathbb{T}}\right))$ and password $({\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}})$ and computes biometric for Client${{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$. Additionally, the Client computes,${{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}}={\mathcalligra{h}}_{\varsigma }({\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} )$, ${{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}={\mathcalligra{h}}_{\varsigma }({{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}})$ and sends a message ${{\varvec{M}}}_{0}=\langle {{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}\rangle$ using a secure channel.

Step RP2: After receiving the registration message, the server calculates ${\mathcalligra{T}}_{{\varvec{\beta}}}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}})$, ${{\mathcalligra{V}}_{{\varvec{c}}}}_{i}={{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}}\oplus {\mathcalligra{T}}_{{\varvec{\beta}}}(\left( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}\right),$ ${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}={\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}}||{\mathcalligra{T}}_{{\varvec{\beta}}}(( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}))$ and fabricate a smartcard with the following details: ${\varvec{S}}{\varvec{C}}=\langle {{\mathcalligra{V}}_{{\varvec{c}}}}_{i},{{\mathcalligra{V}}_{{\varvec{e}}}}_{i},{\mathcalligra{h}}_{\varsigma }(.)\rangle$.

In the same private channel, the server sends the smart card ${\varvec{S}}{\varvec{C}}$ to the Client (Patient/doctor).

Step RP3: After receiving the smartcard,${\varvec{S}}{\varvec{C}}$, the Client computes ${{\mathcalligra{V}}_{{\varvec{d}}}}_{{\varvec{i}}}=\left( {{\mathcalligra{V}}_{{\varvec{c}}}}_{i}\oplus {{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}}\right)\oplus {\mathcalligra{h}}_{\varsigma }({\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} )$ and replaces ${{\mathcalligra{V}}_{{\varvec{c}}}}_{i}$ with ${{\mathcalligra{V}}_{{\varvec{d}}}}_{{\varvec{i}}}$ Within the${\varvec{S}}{\varvec{C}}$. Then rebuild the smartcard as${\varvec{S}}{\varvec{C}}=\langle {{\mathcalligra{V}}_{{\varvec{d}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{e}}}}_{i},{\mathcalligra{h}}_{\varsigma }(.)\rangle$. Figure 3 depicts the entire process involved in the registration procedure.

4.3 Login phase

Before being served, the Client must first login as a legal user. The stages of completing the login procedure are listed below, as prescribed by the scheme. The Client inserted ${\varvec{S}}{\varvec{C}}$ into the card reader, followed by his/her ${\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}},{\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} \ and \ {{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$. The ${\varvec{S}}{\varvec{C}}$ performs calculations,

$${\mathcalligra{h}}_{\varsigma }({\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}|\left|{\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}\right), {\mathcalligra{T}}_{{\varvec{\beta}}}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}})={{\mathcalligra{V}}_{{\varvec{d}}}}_{{\varvec{i}}}\oplus {\mathcalligra{h}}_{\varsigma }({\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} )$$

$${{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{*}={\mathcalligra{h}}_{\varsigma }({\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} ), {{\mathcalligra{V}}_{{\varvec{e}}}}_{i}^{*}={\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{*}||{\mathcalligra{T}}_{{\varvec{\beta}}}({\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} ))$$

The smartcard checks to see if the computed ${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}^{*}$ is matches to ${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}$ The one built into the ${\varvec{S}}{\varvec{C}}.$ The session is terminated, if ${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}^{*}\ne {{\mathcalligra{V}}_{{\varvec{e}}}}_{i}$; otherwise, the ${\varvec{S}}{\varvec{C}}$ picks a random integer $\boldsymbol{\alpha }$ and calculates the following:

$${{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}={\mathcalligra{h}}_{\varsigma }({{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}})$$

$${{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}={\mathcalligra{h}}_{\varsigma }({{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}})$$

$${{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}={\mathcalligra{T}}_{\boldsymbol{\alpha }}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}})$$

$${{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}={\mathcalligra{T}}_{\boldsymbol{\alpha }}({\mathcalligra{T}}_{{\varvec{\beta}}}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}))$$

$${{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}={\mathcalligra{T}}_{\boldsymbol{\alpha }}({\mathcalligra{T}}_{{\varvec{\beta}}}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}))$$

$${{\mathcalligra{V}}_{{\varvec{h}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}$$

$${{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{h}}}}_{{\varvec{i}}}\oplus {{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}}$$

$${{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{h}}}}_{{\varvec{i}}}\oplus {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}$$

$${\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{1} )$$

As a login message, the smartcard sends, ${M}_{1} = \langle {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}, {{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}} {{\mathcalligra{V}}_{{\varvec{e}}}}_{i},{{\varvec{T}}{\varvec{S}}}_{1},{\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{1} )\rangle$ to the medical server, where ${{\varvec{T}}{\varvec{S}}}_{1}$ is the present time-stamp at the Client.

4.4 Authentication and key generation phase

The TMIS server verifies whether$\left({TS}_{2}-{TS}_{1}\right)<\Delta TS$, where ${TS}_{2}$ is the current server time-stamp and $\Delta TS$ is the allowed time delay. The server computes if the time delay is acceptable,${{\mathcalligra{V}}_{{\varvec{g}}}}_{i}^{*}={\mathcalligra{T}}_{{\varvec{\beta}}}\left( {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}\right)$, ${\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{i}^{*}||{{\varvec{T}}{\varvec{S}}}_{1} )$ & checks if the computed ${\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{i}^{*}|\left|{{\varvec{T}}{\varvec{S}}}_{1}\right)$ is equal as the obtained ${\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{1} ).$ If${\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{i}^{*}|\left|{{\varvec{T}}{\varvec{S}}}_{1} \right)\ne {\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{1} )$, otherwise, the server terminates the session, ${\mathcalligra{S}}_{\mathcalligra{j}}$ picks a random integer $\gamma$ and computes the following:

$${{\mathcalligra{V}}_{{\varvec{h}}}}_{i}^{*}={{\mathcalligra{V}}_{{\varvec{g}}}}_{i}^{*}\oplus {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}$$

$${{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{*}={{\mathcalligra{V}}_{{\varvec{h}}}}_{i}^{*}\oplus {{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}$$

$${{\mathcalligra{V}}_{{\varvec{b}}}}_{i}^{*}={{\mathcalligra{V}}_{{\varvec{h}}}}_{i}^{*}\oplus {{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}}$$

$${{\mathcalligra{V}}_{{\varvec{l}}}}_{i}^{*}={\mathcalligra{T}}_{ \gamma }\left( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}\right)$$

$${{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{g}}}}_{i}^{*}\oplus {{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}$$

$${{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{*}\oplus {{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}$$

$${\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{2} )$$

The message ${M}_{2} = \langle {{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}},{{\varvec{T}}{\varvec{S}}}_{2},{\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{2} )\rangle$ is then sent to the Client by the server. When the Client receives the server's response message, he checks if $\left({TS}_{3}-{TS}_{2}\right)<\Delta TS$, where ${TS}_{3}$ is the current time-stamp on the client-side. If it's acceptable, the SC calculates:

$${{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}}={\mathcalligra{h}}_{\varsigma }({\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} )$$

$${{\mathcalligra{V}}_{{\varvec{l}}}}_{i}^{\mathrm{^{\prime}}}= {{\mathcalligra{V}}_{{\varvec{n}}}}_{i}\oplus {{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}}$$

$${{\mathcalligra{V}}_{{\varvec{m}}}}_{i}^{\mathrm{^{\prime}}}= {{\mathcalligra{V}}_{{\varvec{g}}}}_{i}\oplus {{\mathcalligra{V}}_{{\varvec{l}}}}_{i}^{\mathrm{^{\prime}}}, {\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{m}}}}_{i}^{\mathrm{^{\prime}}}||{{\varvec{T}}{\varvec{S}}}_{2} )$$

The smart card also double-checks that the computed ${\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{m}}}}_{i}^{\mathrm{^{\prime}}}||{{\varvec{T}}{\varvec{S}}}_{2} )$ matches the obtained ${\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{m}}}}_{i}^{\mathrm{^{\prime}}}|\left|{{\varvec{T}}{\varvec{S}}}_{2} \right).$ If matched i.e. ${\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{m}}}}_{i}^{\mathrm{^{\prime}}}|\left|{{\varvec{T}}{\varvec{S}}}_{2} \right)\ne {\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{m}}}}_{i}^{\mathrm{^{\prime}}}|\left|{{\varvec{T}}{\varvec{S}}}_{2}\right)$ then the shared session key is computed as $\mathcalligra{s}\mathcalligra{k}={\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{h}}}}_{{\varvec{i}}}||{{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}||{{{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}||{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}} )$ at the completion of this proper mutual authentication procedure on both sides. As a result, both the client and the server may now communicate via$\mathcalligra{s}\mathcalligra{k}$. As shown in Fig. 4, the step-by-step calculations with communications involved in both the login and authentication phases is presented.

Fig. 4

Login and Authentication phase

4.5 Password update phase

It's very likely that the client's password has poor entropy and is easily broken in real time world. In one example, the user could register without having to redo the process. The user can make use of this feature during the password update phase process. Our scheme's safe password updating method is as follows:

The client puts ${\varvec{S}}{\varvec{C}}$ into the terminal and inputs the following information: ${\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}},$ old${\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$, $\ and \ {{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}.$ The ${\varvec{S}}{\varvec{C}}$ calculates${\mathcalligra{h}}_{\varsigma }({\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} )$,${\mathcalligra{T}}_{{\varvec{\beta}}}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}})={{\mathcalligra{V}}_{{\varvec{d}}}}_{{\varvec{i}}}\oplus {\mathcalligra{h}}_{\varsigma }({\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} )$,${{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{*}={\mathcalligra{h}}_{\varsigma }({\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} )$, and ${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}^{*}={\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{*}||{\mathcalligra{T}}_{{\varvec{\beta}}}({\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} )).$ The smart card checks if the calculated ${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}^{*}$= ${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}$ stored in server(S). The session is canceled if${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}^{*}\ne {{\mathcalligra{V}}_{{\varvec{e}}}}_{i}$; otherwise, the S requests the Client to provide a new password. The user enters the new password ${\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}^{new}$ In response to the ${\varvec{S}}{\varvec{C}}$ command. Following new values are calculated by the smart card.

${{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{new}=\mathcalligra{h}({\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}^{new}||{{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} )$,${{\mathcalligra{V}}_{{\varvec{c}}}}_{i}^{new}=({{\mathcalligra{V}}_{{\varvec{c}}}}_{i}\oplus {{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}}\oplus {{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{new})$,${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}^{new}={\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{new}||{\mathcalligra{T}}_{{\varvec{\beta}}}({{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}))$, and${{\mathcalligra{V}}_{{\varvec{d}}}}_{i}^{new}=({{\mathcalligra{V}}_{{\varvec{c}}}}_{i}^{new}\oplus {{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{new})\oplus {\mathcalligra{h}}_{\varsigma }({\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}^{new}||{\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}} ))$. Replaces the old ${{\mathcalligra{V}}_{{\varvec{d}}}}_{{\varvec{i}}}$ and ${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}$ with the new ${{\mathcalligra{V}}_{{\varvec{d}}}}_{i}^{new} and {{\mathcalligra{V}}_{{\varvec{e}}}}_{i}^{new}$ within the smartcard. ${{\mathcalligra{V}}_{{\varvec{d}}}}_{{\varvec{i}}}$ and ${{\mathcalligra{V}}_{{\varvec{e}}}}_{i}$ are two variables. Figure 5 depicts the full procedure of changing the password.

Fig. 5

Password update phase

5 Security analysis of the proposed protocol

The proposed protocol security is critical in terms of implementation. Our protocol’s security analysis is divided into three sub sections. Informal security analysis for different security threats, Formal security analysis utilizing BAN logic for mutually authenticated and key-agreement and Formal verification using AVISPA simulation tool.

5.1 Informal security analysis

In this subsection, many of the essential security threats and common security features are discussed informally.

Theorem 1

The suggested protocol can resist an off-line identification guessing threat.

Proof

As the client uses several methods of maintaining and remembering separate identities for different application unnecessarily. For the sake of ease, user might typically uses the same identity across many applications. According to the adversary model's premise, the attacker can infer the lower entropy user's identity. The suggested protocol's login request,

$${M}_{1} = \langle {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}, {{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}} {{\mathcalligra{V}}_{{\varvec{e}}}}_{i},{{\varvec{T}}{\varvec{S}}}_{1},{\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{1} )\rangle.$$

(1)

Here the message (${M}_{1})$ as shown in (1) of suggested protocol involves users identification ${\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$ as shown below.

$${{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}={\mathcalligra{T}}_{\boldsymbol{\alpha }}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}})$$

(2)

$$\begin{gathered} {\boldsymbol{\mathcalligra{V}}}_{{\varvec{ji}}} = {\boldsymbol{\mathcalligra{V}}}_{{\varvec{hi}}} \oplus {\boldsymbol{\mathcalligra{V}}}_{{\varvec{ai}}} \hfill \\ = {\boldsymbol{\mathcalligra{V}}}_{{\varvec{gi}}} \oplus {\boldsymbol{\mathcalligra{V}}}_{{\varvec{fi}}} \oplus {\mathcalligra{h}}_{\varsigma } (pw_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ||\varvec{bio}_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ) \hfill \\ = {\mathcalligra{T}}_{\varvec{\alpha }} \left( {{\mathcalligra{T}}_{\varvec{\beta }} \left( {{\boldsymbol{\mathcalligra{V}}}_{{\varvec{bi}}} } \right)} \right) \oplus {\mathcalligra{T}}_{\varvec{\alpha }} \left( {{\boldsymbol{\mathcalligra{V}}}_{{\varvec{bi}}} } \right) \oplus {\mathcalligra{h}}_{\varsigma } (pw_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ||\varvec{bio}_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ) \hfill \\ \end{gathered}$$

(3)

$${{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{h}}}}_{{\varvec{i}}}\oplus {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}} , {{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}\oplus {\mathcalligra{T}}_{\boldsymbol{\alpha }}({\mathcalligra{T}}_{{\varvec{\beta}}}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}))\oplus {\mathcalligra{T}}_{\boldsymbol{\alpha }}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}})$$

(4)

As ${{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}={\mathcalligra{h}}_{\varsigma }({{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}})$ is used in the production of all these composite messages. Even if an adversary predicts the user identification ${\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$, the adversary cannot check and validate his/her claim without knowing ${{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$. Aside from that, other parameter ${\varvec{\beta}}$ is also hidden. Comparable arguments can apply to the composite message ${M}_{2}$ as well. As a result, the suggested protocol is immune to an off-line identification guessing threat.

Theorem 2

Our proposed technique is well-protected against off-line password guess attack.

Proof.

In off-line, an attacker might try to determine the user's password and see if his / her attempt is valid. After acquiring the collection of login & authentication messages ${M}_{1}$& ${M}_{2}$ is taken from equation (1) and (6), respectively.

$${M}_{1} = \langle {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}, {{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}} {{\mathcalligra{V}}_{{\varvec{e}}}}_{i},{{\varvec{T}}{\varvec{S}}}_{1},{\mathcalligra{h}}_{\varsigma }\left({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}|\left|{{\varvec{T}}{\varvec{S}}}_{1} \right)\right.\rangle \& {M}_{2} = \langle {{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}},{{\varvec{T}}{\varvec{S}}}_{2},{\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{2} )\rangle$$

(5)

During the session, the attacker can guess the user's password ${\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$. To test his/her theory, assume the attacker looks for the composite message which includes ${\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$. in ${M}_{1}$ and ${M}_{2}$. ${M}_{1}$ composite message containing ${\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$, ${{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}$ as shown below.

$$\begin{gathered} {\boldsymbol{\mathcalligra{V}}}_{{\varvec{ji}}} = {\boldsymbol{\mathcalligra{V}}}_{{\varvec{hi}}} \oplus {\boldsymbol{\mathcalligra{V}}}_{{\varvec{ai}}} \hfill \\ = {\boldsymbol{\mathcalligra{V}}}_{{\varvec{gi}}} \oplus {\boldsymbol{\mathcalligra{V}}}_{{\varvec{fi}}} \oplus h_{\varsigma } (pw_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ||\varvec{bio}_{{{\boldsymbol{\mathcalligra{C}}}i}}) \hfill \\ = {\mathcalligra{T}}_{\varvec{\alpha }} \left( { {\mathcalligra{T}}_{\varvec{\beta }} \left( {{\boldsymbol{\mathcalligra{V}}}_{{\varvec{bi}}} } \right)} \right) \oplus {\mathcalligra{T}}_{\varvec{\alpha }} \left( {{\boldsymbol{\mathcalligra{V}}}_{{\varvec{bi}}} } \right) \oplus {\mathcalligra{h}}_{\varsigma } (pw_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ||\varvec{bio}_{{{\boldsymbol{\mathcalligra{C}}}_{i} }}) \hfill \\ = {\mathcalligra{T}}_{\varvec{\alpha }} ({\mathcalligra{T}}_{\varvec{\beta }} ({\mathcalligra{h}}_{\varsigma } (\varvec{bio}_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ||id_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ))) \oplus {\mathcalligra{T}}_{\varvec{\alpha }} ({\mathcalligra{h}}_{\varsigma } (\varvec{bio}_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ||id_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} )) \oplus {\mathcalligra{h}}_{\varsigma } (pw_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ||\varvec{bio}_{{{\boldsymbol{\mathcalligra{C}}}_{i} }}) \hfill \\ \end{gathered}$$

(6)

& in ${M}_{2}$ is ${{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}}$ as

$$\begin{gathered} {{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{*}\oplus {{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}={\mathcalligra{T}}_{ \gamma }\left( {{\mathcalligra{V}}_{{\varvec{b}}}}_{i}^{*}\right) \oplus {{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{*} \hfill \\ = {\mathcalligra{T}}_{{\gamma }} \left( {{\boldsymbol{\mathcalligra{V}}}_{{\varvec{b}i}}^{{\text{*}}} } \right) \oplus {\boldsymbol{\mathcalligra{V}}}_{{\varvec{a}i}}^{{\text{*}}} \hfill \\ = T_{y} ({\mathcalligra{h}}_{\varsigma } (\varvec{bio}_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ||id_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ) \oplus {\mathcalligra{h}}_{\varsigma } (pw_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ||\varvec{bio}_{{{\boldsymbol{\mathcalligra{C}}}_{i} }} ) \hfill \\ \end{gathered}$$

(7)

To confirm the correctness of the assumed ${\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$, the adversary has to know the extra secret parameters $\boldsymbol{\alpha }, {\varvec{\beta}}, \gamma$ and, most importantly, ${{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$. As a result, checking the anticipated ${\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$ in a polynomial-time procedure is computationally challenging. As a result, the suggested authentication technique can survive a password guessing attack off-line.

Theorem 3

The suggested protocol is resistant to attacks on traceability.

Proof

Because, the attacker can maintain track of a particular user's login messages and thereby harm the user's privacy, the adversary should not be able to determine which login message belongs to which user. Assume an attacker captures any two random login messages ${M}_{1} = \langle {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}, {{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}} ,{{\varvec{T}}{\varvec{S}}}_{1},{\mathcalligra{h}}_{\varsigma }\left({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}|\left|{{\varvec{T}}{\varvec{S}}}_{1} \right)\right.\rangle$ and ${M}_{1}^{*}=\langle {\mathcalligra{V}}_{{f}_{i}}^{*},{\mathcalligra{V}}_{{j}_{i}}^{*},{\mathcalligra{V}}_{{k}_{i}}^{*},{{\varvec{T}}{\varvec{S}}}_{1},{{\mathcalligra{h}}_{\varsigma }({\mathcalligra{V}}_{{g}_{i}}^{*}||{{\varvec{T}}{\varvec{S}}}_{1} )}^{*}\rangle$ for a certain server, because each composite message includes a session parameter in their composition, the attacker cannot identify any similarities in the composite messages. As a result, the suggested approach can withstand a tracing attack.

Theorem 4

The suggested protocol is resistant against insider attack.

Proof

It is common for people to use the same user identification and password for their online accounts. An insider on TMIS server may take note of their user's identification and password also utilize them to log in as a genuine user on another server. The user sends the anonymous identity and password ${{\mathcalligra{V}}_{a}}_{i}={\mathcalligra{h}}_{\varsigma }({\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{bio}_{{\mathcalligra{C}}_{\mathcalligra{i}}} )$ & ${{\mathcalligra{V}}_{b}}_{i}={\mathcalligra{h}}_{\varsigma }({bio}_{{\mathcalligra{C}}_{\mathcalligra{i}}}||{\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}})$ to the TMIS server during the (RP) registration phase of our protocol. It is computationally challenging to get ${{\mathcalligra{V}}_{b}}_{i}||{\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$ and ${\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$ from ${{\mathcalligra{V}}_{b}}_{i}$ and ${{\mathcalligra{V}}_{a}}_{i}$ Because of the features of the 1-way hash function. Furthermore, it is computationally impossible to predict the ${\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$ & ${\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$ without knowing the hidden value ${{\mathcalligra{V}}_{b}}_{i}.$ Consequently, our protocol is impervious to insider threats.

Theorem 5

The enhanced protocol is strongly protected against user impersonation attacks.

Proof.

If an attacker wants to impersonate a specific user, he/ she must record that user's login message and edit the composite messages as needed. Because our protocol is resistant to traceability attacks, the attacker will not collect a specific user's login message. Assume the attacker is a valid user who intends to mimic another user by constructing the login message, As shown in Eq. (1) a composite message ${M}_{1} = \langle {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}, {{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}} ,{{\varvec{T}}{\varvec{S}}}_{1},{\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{1} )\rangle$ generated in his own, in which the value of the secret parameters ${\mathcalligra{i}\mathcalligra{d}}_{{\mathcalligra{C}}_{\mathcalligra{i}}},{\mathcalligra{p}\mathcalligra{w}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}\mathrm{ and }{{\varvec{b}}{\varvec{i}}{\varvec{o}}}_{{\mathcalligra{C}}_{\mathcalligra{i}}}$ is desired for the creation of the composite messages${{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}, {{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}}$, and${\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}})$. The attacker cannot generate the login message ${M}_{1}$ of a specific user even though they are unique to each user. Consequently, the suggested protocol is resilient to the impersonation attack.

Theorem 6

Our scheme is secure against server impersonation attacks.

Proof

Allow the login message to be captured by an adversary i.e. from Eq. (1), ${M}_{1} = \langle {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}, {{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}} ,{{\varvec{T}}{\varvec{S}}}_{1},{\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{1} )\rangle$ and an attacker trying to create response message as shown in Eq. (6), ${M}_{2} = \langle {{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}},{{\varvec{T}}{\varvec{S}}}_{2},{\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{2} )\rangle$ impersonate as a genuine server, where ${{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}}$ and ${{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}$ are as follows: ${{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{g}}}}_{i}^{*}\oplus {{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}$, ${{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{a}}}}_{i}^{*}\oplus {{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}$, ${{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}$ must be used by the attacker to derive ${{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}}$ from ${{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}$ and${{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}$. However, to compute${{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}={\mathcalligra{T}}_{{\varvec{\beta}}}\left( {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}\right)$, the server's secrete parameter s must be known. As a result, without knowing the value of the server's secrete parameter s, the attacker cannot compute ${{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}}$ and ${{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}$ As a result, our protocol is resistant to server impersonation attacks.

Theorem 7

The suggested protocol resilient replaying attack.

Proof

Assume that an adversary tries to execute the replaying attack on the suggested protocol by sending an old login message ${M}_{1} = \langle {{\mathcalligra{V}}_{{\varvec{f}}}}_{1}^{old},{{\mathcalligra{V}}_{{\varvec{j}}}}_{1}^{old}, {{\mathcalligra{V}}_{{\varvec{k}}}}_{1}^{old}, {TS}_{1}^{old},{{\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}||{TS}_{1} )}^{old}\rangle$ to$server(S)$. Because of the old time-stamp${T}_{1}^{old}$, the server will verify for the time latency $\left({TS}_{2}-{TS}_{1}\right)<\Delta TS$ and fails. Similarly, the time-stamp ${T}_{2}^{old}$ is included in the server responded message, thus old ${M}_{2}$ cannot be replayed. As a result, the suggested protocol is resistant to replaying attacks.

Theorem 8

The suggested protocol ensures perfect forward secrecy.

Proof

If the previous session keys were compromised, the attacker may be able to decode previously sent messages, exposing the shared secret. Both Client and server compute the session key in the proposed technique at the end of mutual authentication is

$$\mathcalligra{s}\mathcalligra{k}={\mathcalligra{h}}_{\varsigma }\left({{\mathcalligra{V}}_{{\varvec{h}}}}_{{\varvec{i}}}\left|\left|{{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}\right|\right|{{{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}||{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}} \right)\mathrm{ in which }{{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}={\mathcalligra{T}}_{\boldsymbol{\alpha }}({\mathcalligra{T}}_{{\varvec{\beta}}}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}))$$

(8)

$${{\mathcalligra{V}}_{{\varvec{h}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}\oplus {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}$$

(9)

$${{\mathcalligra{V}}_{{\varvec{h}}}}_{{\varvec{i}}}={\mathcalligra{T}}_{\boldsymbol{\alpha }}({\mathcalligra{T}}_{{\varvec{\beta}}}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}))\oplus {\mathcalligra{T}}_{\boldsymbol{\alpha }}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}})$$

(10)

$${{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}={\mathcalligra{T}}_{ \gamma }\left( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}\right)$$

(11)

$${{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}={{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}\oplus {{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}= {\mathcalligra{T}}_{\boldsymbol{\alpha }}({\mathcalligra{T}}_{{\varvec{\beta}}}( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}))\oplus {\mathcalligra{T}}_{ \gamma }\left( {{\mathcalligra{V}}_{{\varvec{b}}}}_{{\varvec{i}}}\right)$$

(12)

Even if the server's longer—term secrets value (${\varvec{\beta}}$) is known, the adversary cannot compute our protocol session key$\mathcalligra{s}\mathcalligra{k}={\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{h}}}}_{{\varvec{i}}}||{{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}||{{{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}||{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}} )$, since the session random nonce i.e. $x \& y$ involve in every composite message transfer as shown in proposed authentication scheme. The session key is dependent on both the server and the user's longer-term secrets and the session secrets. consequently, 100% forward secrecy is achieved by the proposed protocol.

Theorem 9

Forward secrecy is robust protection against a Stolen verifier attack in the protocol suggested.

Proof

There is no such verifier table is required for verification in our protocol. i.e., throughout the login and authentication procedure, our system doesn’t need the use of a verification table. Therefore the absence of a verifier table removes the possibility of a stolen-verifier attack [60].

Theorem 10

The suggested protocol safe against man in the middle threat.

Proof

Allow an adversary to record a legitimate user's login message ${M}_{1} = \langle {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{j}}}}_{{\varvec{i}}}, {{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}},{{\varvec{T}}{\varvec{S}}}_{1},{\mathcalligra{h}}_{\varsigma }({{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}||{{\varvec{T}}{\varvec{S}}}_{1} )\rangle$ and tries to come up with a valid ${M}_{1}^{new}$ on its own. It is computationally impossible for the adversary to produce a legitimate${M}_{1}^{new}$, as indicated in the user impersonation attack as proved in theorem 5. Furthermore, if the adversary tries to respond with a genuine login message, it is computationally infeasible to create a responsive message ${M}_{2}^{new}$ and persuade the user, as our technique withstands server impersonation attacks. As a result, the suggested protocol is impervious to a man in the middle threat.

5.2 BAN logic is a formal method to prove authentication

BAN logic is initially utilized to test the security protocol's correctness [61]. The BAN logic is a formal approach for determining if a protocol can resist security risks such as replay attacks, eavesdropping, and man-in-the-middle attacks. This formal technique primarily focuses on confirming the message origin, message freshness, and origin's trustworthiness in the security protocol. The BAN logic, with its formal definitions, syntax, and postulates, is well-established for analyzing authentication protocols. The study begins with a BAN logic model of the intended protocol that follows a well-defined syntax. The basic assumptions for the planned procedure are established after the Idealization. The set of objectives to be met is then determined based on the attributes that must be verified. Finally, the idealized procedure is combined with definitions, postulates, and assumptions to meet the needed set of goals can be found in [62, 63].

5.2.1 Idealization of proposed protocol

To do the formal analysis, the suggested authentication scheme must be idealized in BAN logic. The sharing credentials may be discovered since the login message is written in such a way that the user authenticated towards the server. Applying ${{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}$ the user integrates ${{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}$, and masks in the suggested protocol, also in that same message the user combines ${{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}$ with the time-stamp ${TS}_{1}$.The login message ${M}_{1}$ may be simplified in the BAN logic using this concept. The server combines ${{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}$ with the time-stamp ${TS}_{2}$ in the responsive message and masks it with ${{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}$. As a result, these are the idealised messages:

$${M}_{1}= \langle {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}},{\langle {{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}\rangle }_{{{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}},{{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}},{\langle {{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}\rangle }_{{TS}_{1}}\rangle$$

$${M}_{2}=\langle {{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}},{\langle {{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}\rangle }_{{{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}}$$

To do the formal analysis, the suggested system must be idealized in BAN logic. The shared credentials may be discovered since the login message is written so that the patient/client (user) authenticates to the TMIS server. The Client combines ${{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}$ and masks using ${{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}$, in the suggested protocol, and the Client also integrates ${{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}$ with the time-stamp ${TS}_{1}$ in the same message. The login message ${M}_{1}$ may be idealised in the BAN logic using this concept. The server combines ${{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}$ with the time-stamp ${TS}_{2}$ in the response message and masks it with ${{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}$. As a result, these are the idealised messages:

$${M}_{1} = \langle {{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}},{\langle {{\mathcalligra{V}}_{{\varvec{a}}}}_{{\varvec{i}}},{{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}\rangle }_{{{\mathcalligra{V}}_{{\varvec{f}}}}_{{\varvec{i}}}},{{\mathcalligra{V}}_{{\varvec{k}}}}_{{\varvec{i}}},{\langle {{\mathcalligra{V}}_{{\varvec{g}}}}_{{\varvec{i}}}\rangle }_{{TS}_{1}}\rangle , {M}_{2} = \langle {{\mathcalligra{V}}_{{\varvec{n}}}}_{{\varvec{i}}},{\langle {{\mathcalligra{V}}_{{\varvec{m}}}}_{{\varvec{i}}}\rangle }_{{{\mathcalligra{V}}_{{\varvec{l}}}}_{{\varvec{i}}}}$$

5.2.2 Security objectives

The users must establish the security objectives according to needed attributes to be validated to properly analyze the proposed technique. To provide mutual authentication between both Client and the TMIS server, we establish the essential security objectives in our protocol.

$${G}_{1}: {S}_{ k}|\equiv {U}_{i}|\equiv {G}_{i}$$

$${G}_{2} : {S}_{ k}|\equiv {G}_{i}$$

$${G}_{3} :{U}_{i} |\equiv {S}_{ k}|\equiv {M}_{i}$$

$${G}_{4} :{U}_{i} |\equiv {M}_{i}$$

$${G}_{5} :{U}_{i} |\equiv {U}_{i} \stackrel{{S}_{ k}}{\leftrightarrow }{S}_{ k}$$

$${G}_{6} :{S}_{ k} |\equiv {U}_{i} \stackrel{{S}_{ k}}{\leftrightarrow }{S}_{ k}$$

The additional objectives ${G}_{5}$, ${G}_{6}$ are established to guarantee that the session key is exchanged solely between the Client and the server, and the security objectives ${G}_{1}\mathrm{to} {G}_{4}$ certify that the Client and server are mutually authenticated.

5.2.3 Preliminary assumptions

In order to derive the above-mentioned goals, the formal methodology allows the user to make certain basic assumptions based on the given protocol. The first assumptions made regarding the proposed protocol in regard to the defined security goals are listed below.

$${A}_{1} :{S}_{ k}|\equiv {U}_{i} \stackrel{{F}_{i}}{\leftrightarrow }{S}_{ k}$$

$${A}_{2} :{S}_{ k}|\equiv \#x$$

$${A}_{3} :{S}_{ k}|\equiv {U}_{i}|\Rightarrow {G}_{i}$$

$${A}_{4} :{U}_{i}|\equiv {U}_{i} \stackrel{{L}_{i}}{\leftrightarrow }{S}_{ k}$$

$${A}_{5} :{U}_{i}|\equiv \#y$$

$${A}_{6} :{U}_{i}|\equiv {S}_{ k}|\Rightarrow {L}_{i}$$

5.2.4 Scheme analysis

Let us utilize the rule on the message ${M}_{1}$, $ST_{1} :S_{{{\text{~}}k}} \triangleleft \langle F_{i} ,A_{i} ,G_{{iF_{i} }} ,K_{i} ,{\mathcalligra{h}}(G_{i} ||T_{1} )\rangle$. Simultaneously, with ${ST}_{1}$, we derive $ST_{2} :S_{{k}} \triangleleft A_{i} ,G_{{iF_{i} }}$, using the subcomponent rule of the seeing rule.

By applying assumptions, ${A}_{1}$ on ${ST}_{2}$ and by message meaning rule, we derive ${ST}_{3}: |\equiv {U}_{i}\sim \langle {A}_{i}, {G}_{i}\rangle$. Applying its subcomponent rule, we get ${ST}_{4}:{S}_{k}\left|\equiv {U}_{i}\right|\sim {G}_{i}$.

As we have${G}_{i}={{T}_{x}( T}_{s}( {B}_{i}))$, using the assumption ${A}_{2}$ and freshness rule, we get${ST}_{5}:{S}_{k}|\equiv \#{G}_{i}$. Using ${ST}_{4}$ and ${ST}_{5}$ in nonce verification rule, we get ${G}_{1}:{S}_{k}\equiv {U}_{i}| \equiv {G}_{i} . \left({\varvec{G}}{\varvec{o}}{\varvec{a}}{\varvec{l}} {G}_{1} \right).$ Using ${G}_{1}$ and ${A}_{3}$ in Jurisdiction rule, we get ${G}_{2}:{S}_{k}\equiv {G}_{i} . ({\varvec{G}}{\varvec{o}}{\varvec{a}}{\varvec{l}} {G}_{2} )$ According to seeing rule,$ST_{6} :U_{i} \triangleleft \langle N_{i} ,{\mathcalligra{h}}\left( {M_{i} } \right)\rangle$.

As user possesses ${A}_{i}, {L}_{i} = {N}_{i} {A}_{i} and {M}_{i} ={G}_{i} {L}_{i} ,$ we have${ST}_{7}: {U}_{i} \triangleleft \langle {N}_{i},{\langle {M}_{i}\rangle }_{{L}_{i}} \rangle$.

Using assumption ${A}_{4}$ and by message meaning rule, we get ${ST}_{8}: {U}_{i}|\equiv {S}_{k}\sim {M}_{i}$. As ${M}_{i} ={G}_{i} {T}_{Y}( {B}_{i})$, using the assumption ${A}_{5}$ and subcomponent rules for freshness, we get ${ST}_{9}: {U}_{i}|\equiv \#{M}_{i}$.

Using ${ST}_{8}$ and ${ST}_{9}$ in nonce verification rule, we get${G}_{3}: {U}_{i}|\equiv {S}_{k}|\equiv {M}_{i} . ({\varvec{G}}{\varvec{o}}{\varvec{a}}{\varvec{l}} {G}_{3} )$. As ${M}_{i} = {G}_{i} \oplus {L}_{i}$ and using assumption${A}_{6}$, we get${ST}_{10}: {U}_{i}|\equiv \#{M}_{i}$.

Using ${ST}_{10}$ and ${G}_{3}$ in Jurisdiction rule, we get${G}_{4}: {U}_{i}|\equiv {M}_{i} . ({\varvec{G}}{\varvec{o}}{\varvec{a}}{\varvec{l}} {G}_{4} )$.

Since, ${S}_{k}=\mathcalligra{h}({{\varvec{H}}}_{{\varvec{i}}}||{{\varvec{L}}}_{{\varvec{i}}}||{{{\varvec{M}}}_{{\varvec{i}}}||{\varvec{G}}}_{{\varvec{i}}} )$, by using ${ST}_{9}$ with ${G}_{3}$ in the session key rule, we get get${G}_{5}: {U}_{i}|\equiv {U}_{i}\stackrel{SK}{\leftrightarrow } {S}_{k}. ({\varvec{G}}{\varvec{o}}{\varvec{a}}{\varvec{l}} {G}_{5} )$. Similarly, by using ${ST}_{5}$ with ${G}_{1}$ in the session key rule, we get ${S}_{k}{G}_{6}: {S}_{k}|\equiv {U}_{i}\stackrel{SK}{\leftrightarrow } {S}_{k}. ({\varvec{G}}{\varvec{o}}{\varvec{a}}{\varvec{l}} {G}_{6} )$.

5.3 Formal verification using AVISPA

In this subsection, we utilize the AVISPA for formal verification of the proposed authentication and key exchange protocol. The AVISPA uses role-based programming language i.e., HLPSL (High-Level Protocol Specification Language) programming language [56, 57]. The AVISPA is a well-known tool for verifying that proposed protocols are secure against replay and man-in-the-middle attacks.

The following four back-ends can be utilized to implement the AVISPA tool.

• 1. OFMC (On the Fly Model Checker)

• 2. CL-AtSe (Constraint Logic based Attack Searcher)

• 3. TA4SP (Tree Automate Based Protocol Analyzer)

• 4. SATMC (SAT Based Model Checker).

The AVISPA simulation results of our proposed protocol are as follows. To simulate the our proposed authentication and key exchange protocol, we use the OFMC back-end of the AVISPA tool, as shown in Fig. 6 and CL-AtSe back-end, as shown in Fig. 7. The findings demonstrate that the proposed protocol is safe from passive and active attacks, including replay attacks, man-in-the-middle attacks, and user anonymity attacks, which are all major security issues in TMIS.

Fig. 6

Final experimental result of the formal security analysis using AVISPA tool generated by OFMC back-end

Fig. 7

Final Experimental result of the formal security analysis using AVISPA tool generated by CL-AtSe back-end

6 Performance comparison

This section demonstrated the performance analysis and comparison study related to the security and functionality characteristics offered by the scheme presented. our approach performance will look at storage costs, computational overheads, and communication costs. To accomplish so, a comparison of our approach with other relevant authentication systems is carried out. The numerous attacks and vulnerabilities targeted in the performance evaluation are listed in Table 3. Also, Table 3 shows that our authentication scheme can limit the vulnerabilities discussed in Sect. 5. We also comparatively discussed and analyze the other related authentication scheme.

Table 3 Various attacks

6.1 Computation Cost: As shown in Table 5, the performance characteristics for current identical authentication schemes and our approach. Here, we compared the proposed authentication scheme with [27, 29, 36, 39, 58, 59] and [3]. Different operations, such as modular exponential $({\varvec{T}}{\varvec{e}}{\varvec{x}}{\varvec{p}})$ operations, Hash/MAC $({\varvec{T}}{\varvec{h}})$ operations, Chebyshev chaotic map $({\varvec{T}}{\varvec{c}}{\varvec{c}}{\varvec{m}})$, Symmetric-key encryption-decryption operation $({\varvec{T}}{\varvec{s}}{\varvec{y}}{\varvec{m}})$, elliptic curve point multiplication operation (${\varvec{T}}{\varvec{e}}{\varvec{c}}{\varvec{c}}$) and Biometric hash $({\varvec{T}}{\varvec{b}}{\varvec{i}}{\varvec{o}})$ and other authentication scheme characteristics, are used to compare with our authentication scheme. The experiment result was conducted on Intel Pentium4 1 GB RAM 2600 MHz processor in [27, 60] as the cost of various operations is shown in Table 4.

Table 4 Notations used for computational cost and Execution time for each operation

Table 5 shows the comparative analysis based on the computational cost for various stages. Here, we compared with existing similar chaotic map based authentication schemes [27, 29, 36, 39, 58, 59] and [3] with our authentication scheme and found that our scheme outperforms. In comparison to the schemes mentioned, our proposed authentication scheme has a lower computing cost.

Table 5 Comparative analysis based on computational cost for various stages

6.1 Communication Cost

Table 6 presents the comparative analysis based on communication cost between our authentication scheme and the other related existing similar chaotic map-based authentication schemes communication cost [27, 29, 36, 39, 58, 59] and [3]. In our experiment, the hash function ${(L}_{h})$ is 160 bits (20 bytes), the length of exponentiation operation ${(L}_{exp})$ is 256 bits (32 bytes), the output length of chebyshev chaotic map ${(L}_{cch})$ is 256 bits (32 bytes) and the output of Time-stamp ${(L}_{TS})$, random number ${(L}_{r})$, identity ${(L}_{id})$ is 32 bit (4 bytes). To calculate the communication cost of our proposed scheme, the two messages M1 and M2, for login and verification stage considered. The length of M1 is one time-stamp, one hash, and three chaotic map i.e. ${1L}_{h}+{3L}_{ccm}+{L}_{TS}=960 bits$ and length of M2 is one time-stamp, one hash and one chaotic map i.e. ${L}_{h}+{L}_{ccm}+{L}_{TS }=448 bits$ therefore, the total communication cost is ${2L}_{h}+{4L}_{ccm}+2{L}_{TS}=1408 bits$. As shown in Table 6 it is comparatively lower in term of communication cost.

Table 6 Comparative analysis based on communication cost for Login and verification stage

Smart cards are often constructed with limited storage capacity, and storing additional data in the smartcard reduces the device's computational performance. The suggested approach computes hash values using the chaotic hash algorithm, with a 160-bit output. The chaotic map value is 256 bits, but the random number and identity are 32 bits. The storage cost of our proposed scheme if one chaotic map and one chaotic hash i.e. ${(\mathrm{L}}_{\mathrm{h}}+{\mathrm{L}}_{\mathrm{ccm}})=416\mathrm{ bits}.$

7 Conclusion and future scope

This article proposed a provably lightweight mutually authentication and key establishment protocol using extended chaotic map for TMIS. We evaluate and compare a number of similar authentication schemes and analyze them to develop a solution that overcomes the flaws in each one. According to the security and performance analysis, the proposed method not only withstands numerous attacks but is also more efficient than other existing schemes. Our scheme is more suitable for TMIS because of its better communication and computational overhead performance.

In future, the proposed scheme can be implemented for applications on IoMT (Internet on Medical Things) and IIoT. The scheme can further be extended to offer lightweight functionality for resource constraint devices.