An Efficient Mutual Authentication Framework for Healthcare System in Cloud Computing

Abstract

The increasing role of Telecare Medicine Information Systems (TMIS) makes its accessibility for patients to explore medical treatment, accumulate and approach medical data through internet connectivity. Security and privacy preservation is necessary for medical data of the patient in TMIS because of the very perceptive purpose. Recently, Mohit et al.’s proposed a mutual authentication protocol for TMIS in the cloud computing environment. In this work, we reviewed their protocol and found that it is not secure against stolen verifier attack, many logged in patient attack, patient anonymity, impersonation attack, and fails to protect session key. For enhancement of security level, we proposed a new mutual authentication protocol for the similar environment. The presented framework is also more capable in terms of computation cost. In addition, the security evaluation of the protocol protects resilience of all possible security attributes, and we also explored formal security evaluation based on random oracle model. The performance of the proposed protocol is much better in comparison to the existing protocol.

Introduction

With the quick progress of information technology, the use of TMIS is increasing day by day. To offer conducive and rapid network services, a novel kind of cloud computing organization [8, 25] which contains of a large number of processors, memories, high-speed networks, and various appliances is expected by consumers through the internet. Cloud computing services are offered via a browser to access an online data applications. These computing methods can be achieved by the cloud platform. Further, the work [44] explained that the cloud services will develop in the future. Therefore, the security and privacy of the cloud computing have become important issues. Various articles have proposed different issues of their apprehensions, such as: cloud security [9, 54], personal privacy and cloud services [11, 52]. According to the article [12], several operations are associated to cloud services and their uses.

With the fast development of internet appliances, people can select an appropriate hospital for high excellence of healthcare [2, 40]. Furthermore, for the progress of medical center superiority and the medical trade struggles the healthcare center sustains hospitals in remote localities. The medical manufacturing offers more specialized medical apparatus and improves medical maintenance superiority. With the help of medical manufacturing the healthcare centers are trying to improve their services so that patients can get easy access of medical facilities [36]. For an example, if the electronic medical records shared very well, the healthcare centers can share their resources through the internet. Patients need not to depict their inspection reports. On the other side, as we know if the patient has come to healthcare center, the medical employees should try to get the patient’s medical reports as early as possible for the preparation of medical treatment and to decrease errors. Moreover, the sensor planted in the patient’s body is another option for the healthcare center to get his/her medical report.

In medical organization, the cloud users store medical data in the cloud database to recapture the data securely. As it is common that cloud is not completely secured, so a protected and authenticated framework required to prevent simple security attacks [33]. In newly years, there are several authentication schemes [3,4,5, 13, 18, 45] proposed for TMIS, where the patients find their treatment online. As indicated in [14] TMIS proficiency medical doctor and patients to begin a conversation via public channels to support healthcare assistances precisely in the patient’s residence. As attribute of TMIS, both doctors and patients can perform together through the cloud server, i.e. a patient transfer his/her manifestations to the TMIS server and the doctor collect them and uploads diagnosis data report of the patient to the cloud server as if they are collaborating precisely, and it is happening via TMIS. Furthermore, the transmission is done via public channel, so it is important to know how to get extra benefits from medical resources with secure communication. Additionally, the security obligations, data confidentiality, patient anonymity, and patient authentication are the significant appearances to retain throughout the communication. In order to keep up patient anonymity [19, 28, 41], the identification of the patient need to differentiate from the others including eavesdropper. In TMIS, the patient’s medical reports are extremely significant, and they have not to revealed widely. As the message shared between patients/doctors and cloud are very serious information and so, data are gathered strongly. As medical information comes under imperative data and collapse of it may reason deterioration of ones life [50], thus it is essential to prove a protected scheme so that no attacker can attempt to find patient’s data and mistreatment it. Newly, there have been several protocols proposed to recognize anonymity concern. Mainly of these existing schemes are not relevant to offer patient anonymity in the healthcare system.

Related works

Smart card based authentication technique is the ordinary which adopted to avert unapproved access over the confident networks. There are various authentication scheme [35, 36, 42] obtainable using card [30], where the clients accept a password and imports a smart card with it. The authentication scheme is very favorable in different use, such as wireless sensor network, medical system and adhoc networks[6, 7, 20,21,22,23,24,25,26,27,28, 34, 40, 52,53,54]. Wu et al. first suggested a password-based user authentication protocol [47] and a reliable client authentication and key agreement protocol for network based hospital-acquired epidemic surveillance information system [49] then, Wu-Lee et al. [48] presented a secure authentication scheme for TMIS. Then, He et al. [18] accumulated that Wu et al.’s protocol[48] has different technical issues, like as an insider and impersonation attack, they also advised an improved scheme. In 2012, Wei et al. [46] observed that earlier schemes [18, 48] which are not secured across security flaws and recommended an appreciated protocol to prevent the occurring attacks. After that, Zhu [52] proved that Wei et al. [46] protocol is not protected against off-line password guessing attack and implemented a protected authentication protocol for TMIS, which based on the RSA cryptosystem. In 2013, Jiang et al.’ [29] proposed privacy enhanced authentication scheme for TMIS. Kumari et al. [31] proposed cryptanalysis and improvement of a privacy enhanced scheme TMIS which claimed that [29] fails to offer online password guessing attack, impersonation attack, and stolen-verifier attack. Nonetheless, Mishra et al. [38] presented a secure and capable chaotic map-based authenticated key agreement protocol for TMIS in which they examined that the scheme [29] does not resist denial-of-service attack. In current year , Liu et al.’s [55] proposed authentication based a practical privacy preserving data aggregation scheme which is efficient in communication security aspects.

In 2013, Tan [43] suggested a capable biometrics based authentication scheme for TMIS which is a smart card based password authentication and key agreement protocol by implementing a biometric system, and the protocol is more secure. Further, Yan et al. [50] proposed a secure biometric-based authentication protocol for TMIS which validated that the scheme [51] not passes to resist Denial-of-Service attack. In 2014, Mishra et al. [37] presented cryptanalysis and improvement of Yan et al. Biometric-based authentication method for TMIS which described that scheme [50] have a number of security outlet, like as the client privacy, ineffectual password, insufficient login phase, password guessing attack, biometric update phase and three-factor authentication difficulty. To decide the above recognized complication, they as well presented an enhanced protocol. Li et al. [33] presented a secure chaotic maps, and smart card based password authentication and key agreement scheme with user anonymity for TMIS and declared that the Lee et al.’s [32] chaotic –maps based client authentication protocol bear security weaknesses like absence of client identifier in authentication phase, service misuse attacks, and advised a more effective explanation for accessing TMIS. In 2014 Chen et al. [16] associates the cloud computing environment with mobile devices to give medical resources and uses cryptographic infrastructure to defend the patients secret information. Then, the scheme has several security flaws. Chen et al. [15] also proposed a new scheme for the same environment based on the cloud computing environment, although the scheme does not support message authentication and patient anonymity. To improvise the security flaws in [15], Chiou et al. [17] adapted the occurring protocol and believed that the framework prepares real TMIS, message authentication and patient anonymity. In 2016, Liu et al.’s [56] proposed a privacy-preserving health data aggregation scheme. In 2017, Liu et al. [57] presented a lightweight pseudonym authentication scheme for multi-medical server architecture for TMIS. Furthermore, Mohit et al. [39] proposed mutual authentication framework for cloud environment based healthcare system, we found that it is vulnerable to stolen verifier attack, many logged-in patient attack, patient anonymity, impersonation attack and fails to protect session key.

Motivation and contribution

Recently, Mohit et al. [39] suggested a mutual authentication protocol for TMIS that can work in the cloud computing environment.

• It is analyzed and shown as follows:

  • Their scheme does not secure against stolen-verifier attack.

  • Their protocol does not support many logged in patient attack.

  • Their protocol does not ensure the anonymity of the patient.

  • Their protocol does not secure against impersonation attack.

  • Their protocol fails to protect session key.

• In this regard, to attain security against the aforementioned attacks and to ensure the security of an entire package, a mutual authentication framework for TMIS is presented which is suitable for the cloud computing. The proposed framework has many significant characteristics, such as:

  • Mutual authentication is accomplished between healthcare center and cloud server, patients and cloud server, doctor and cloud server, and patient and healthcare centers to strengthen the safety of a structure and transforming information.

  • Furthermore, the proposed protocol is strong against many security attributes, i.e., implements security against, patient anonymity, man-in-the-middle attack, strong replay attack, known key security property, data confidentiality, data non-repudiation, message authentication, impersonation attack, session key security, stolen mobile device attack, off-line password/identity guessing attack and many logged-in patient’s attack.

  • We provided formal security analysis of our proposed protocol based on random oracle model.

  • We evaluate the proposed scheme with other existing works and found that our scheme gets minimum computational and communication expenditure, but ensures security of the system.

Road map of the paper

The rest of this paper is formulated as follows. In “??”, we describe the Preliminaries. Section “??”, We reviewed Mohit et al.’s scheme. Section “Cryptanalysis of Mohit et al.’s scheme”, The cryptanalysis of Mohit et al.’s Scheme. Section “??”, Security model, Section “The proposed protocol”, We proposed an improved mutual authentication protocol for healthcare system in cloud computing. Section “??”, formal security analysis of the proposed protocol. Section “Performance analysis”, performance analysis of the proposed and earlier existing schemes. Finally, Section “Conclusion”, discusses about the conclusion. Moreover, we make use of the notation/symbol throughout the paper as given in Table 1.

Table 1 Notations/Symbol used

Preliminaries

Elliptic curve cryptography

Let q be the large prime and $\mathcal {E}$ denote an elliptic curve over the prime finite field F_q, an equation of elliptic curve over prime finite field is given by y² = x³ + ax + bmodq with a,b ∈ F_q and 4a³ + 27b²modq≠ 0. So, this is a non singular elliptic curve. Then, the additive elliptic curve group defined as G = {(x,y) : x,y ∈ F_q; $(x, y) \in \mathcal {E}\} \bigcup \{ {\Theta }\}$, where the point Θ is known as point at infinity which works as the identity element of G. The scalar multiplication on the group G is defined as tP = P + P... + P(t − times) and the point addition in G as: If P = (x₁,y₁), Q = (x₂,y₂) ∈ G , then P + Q = (x₃,y₃), where x₃ = λ² − x₁ − x₂modq, y₃ = (λ(x₁ − x₂) − y₁)modq where

$$\lambda = \left\{ \begin{array}{ll} \frac{y_{2}-y_{1}}{x_{2}-x_{1}} mod q & if P \neq Q \\\\ \frac{3{x^{2}_{1}}+a}{2y_{1}} mod q & if P=Q \end{array} \right. $$

The more details of elliptic curve group are given in [20].

• Elliptic Curve Discrete Logarithms Problem (ECDLP): For given P,Q ∈ G, find $k\in Z^{\ast }_{q}$ such that P = kQ, which is hard.

• Elliptic Curve Computational Diffie-Hellman Problem (ECCDHP): For $a, b \in Z^{\ast }_{q}$ and g is the generator of G, for given (g, ag, bg), then to compute abg is hard for the group G.

Hash function

Definition

A one-way hash function H_i : {0,1}^∗→{0,1}^l, inputs an arbitrary string length take x ∈{0,1}^∗, and outputs a finite length string l bit message assimilate or hash value h(x) ∈{0,1}^∗. A best hash function should contain the following properties:

• For any given input x, it is accessible to calculate the digest h(x).

• One-way: For a given hash value y = h(x), it is computationally not feasible to obtain x.

• Weak-collision resistance: For any given input x, obtaining any other input y, with x≠y, such that h(x) = h(y) is computationally infeasible.

• Strong-collision resistance: Finding a pair of inputs (x,y) with x≠y, such that h(x) = h(y) is also computationally not feasible.

Assumptions for the mutual authentication protocol

We take some assumptions to evaluation the invoked mutual authentication protocol.

Assumption 1

The hash results, the random number and secret numbers stored in cloud server. They reach the secure length l.

Assumption 2

The E_y (m), D_y (m) and h(.) are capable. That is to tell, in polynomial time, anybody can not decrypt the encrypted string E_y (m) without knowing y and no one find the collision of h(m), where m is the string [58,59,60,61].

Assumption 3

According to [2, 3, 60], both the identity and the one time password (OTP) of the entity have low entropy. There are two dictionaries in which one for identities and second for OTP. Advisory E can guess them in polynomial time.

Assumption 4

Adversary E can get the previous session keys, which is from the known-key attacks [60, 61].

Review of Mohit et al.’s scheme

Mohit et al. proposed a standard mutual authentication scheme for cloud based healthcare environment. There are five bodies : Patient, Cloud server, Doctor, Body sensor and Healthcare center. This scheme involves of four phases: (1) Healthcare center upload phase, (2) Patient data upload phase, (3) Treatment phase and (4) Checkup phase. Those are followed as:

Healthcare center upload phase (HUP)

The patient P registers herself/himself in the HC, and the HC provides OTP. The HC operates authentication with CS and uploads the P’s inspection medical report to CS as described bellow as:

Step 1. :

The healthcare center generates inspection record m_H = (ID_P,Data_P), and uses unique identity ID_H of healthcare center with a elected random number R. The HC sends message {ID_H,m_H} to the CS via secure channel.

Step 2. :

On receiving messages, CS takes secure key x and executes A = h(ID_H∥R∥x),S₁ = h(A) and B = ID_H ⊕ x. Sends {S₁,B} to HC via public channel.

Step 3. :

On collecting message, HC computes x^′ = B ⊕ ID_H,A^′ = h(ID_H∥x^′∥R) and checks whether $S^{\prime }_{1}=?h(A^{\prime })$ holds or not. If it does not hold, HC exits the session. Otherwise HC computes session key SK_HC = h(ID_H∥A^′∥B),key₁ = h(ID_P∥OTP) and encrypts the record as $C_{H}= E_{key_{1}}(m_{H})$. Further, the HC computes MD_H = h(m_H), digital signature $Sig_{H}= S_{PR_{H}}(MD_{H})$, encrypts $C_{1}= E_{SK_{HC}}(ID_{P}, C_{H}, Sig_{H}, SID)$ and computes S₂ = h(SK_HC∥C₁). Finally sends message {S₂,C₁} to the CS via public channel.

Step 4. :

Upon gathering message, the CS computes session key $SK^{\prime }_{HC}= h(ID_{H} \|A \|B)$ and checks whether $S^{\prime }_{2}\overset {?}{=} h(SK^{\prime }_{HC}\|C_{1})$ hold or not. If, it does, CS authenticates HC and decrypts the message using session key $SK^{\prime }_{HC}$ to get $(ID_{P},C_{H}, Sig_{H},SID)= D_{SK_{HC}}(C_{1})$, and store ID_P,C_H,Sig_H,SID. Otherwise, it fails and goes to Step.

Patient data upload phase (PUP)

The BS is fixed in the P’s body. The P requests BS, to assemble the reorganized health information, and presented it to the P through secure mobile device. The patient inputs identity ID_P and OTP of his/her mobile device. The cloud server provides a slot sequence number sn_i, inspection record card m_H to the patient which discussed below as:

Step 1. :

P obtains health information message m_B = (ID_P,Data_B) from BS through mobile device. Then, P inputs his/her ID_P,SID and forwards message {ID_P,SID} to the CS through a secure channel.

Step 2. :

On collecting messages, CS computes I = sn_i ⊕ SID,S₃ = h(SID∥I∥C_H∥Sig_H) and sends {I,S₃,C_H,Sig_H} to P via open channel.

Step 3. :

On getting information, P computes $sn^{\prime }_{i}=I \oplus SID$ and checks whether $S^{\prime }_{3}=?h(SID\|I\|C_{H}\|Sig_{H})$ grips or not. If is does, P authenticates CS and calculates session key SK_PC = h(ID_P∥SID), key₁ = h(ID_P∥OTP). Then, P decrypts the ciphertext to find $m_{H}=D_{key_{1}}(C_{H})$ and computes $MD_{H}=V_{PU_{H}}(Sig_{H})$. After that, checks m_H =?h(MD_H) holds or not. If is does, computes key_PD = h(ID_P∥ID_D∥sn_i), encrypts $E_{key_{PD}}(m_{H}, m_{B})$, computes MD_P = h(m_B), generates signature $Sig_{P}= S_{MD_{P}}(MD_{P})$ and computes S₄ = h(SK_PC∥C_P∥Sig_P). Sends message {S₄,C_P,Sig_P} to CS over public channel.

Step 4. :

On accepting messages, CS executes $SK^{\prime }_{PC}=h(ID_{P}\|SID)$ and checks whether $S^{\prime }_{4}=?h(SK^{\prime }_{PC}\|C_{P}\|Sig_{P})$ holds or not. If is does, cloud store C_P,Sig_P. Otherwise, terminates the session.

Treatment phase (TP)

In this phase, doctor provides treatment of authenticated patient by acting authentication between the doctor and the cloud server. Cloud contains all the medical report of patients and sends to doctor. Doctor and cloud server perform as bellow:

Step 1. :

Doctor D sends his/her identity ID_D and random number RD to CS through secure public channel.

Step 2. :

On receiving message, CS sends identity ID_D of the P and sequence number sn_i to D via secure public channel. Then, CS computes S₅ = h(RD∥Sig_P∥sn_i) and sends message {S₅,Sig_P,C_P} to D through public channel.

Step 3. :

Upon receiving message, doctor verifies whether $S^{\prime }_{5}=?h(RD\|Sig_{P}\|P_{P})$ holds or not. If it does, D authenticates the CS and computes session key SK_DC = h(ID_P∥RD∥sn_i), else rejects the message. Moreover, D computes key_PD = h(ID_P∥ID_D∥sn_i), and decrypts the received message as $(m_{H}, m_{B})= D_{key_{PD}}(C_{P})$, and verifies the patient’s signature using public key of P, which is $MD_{P}=V_{PU_{P}}(Sig_{P})$ and checks whether MD_P =?h(m_B) hold or not. If it does, D generates medical report m_D = (ID_P,Data_D), encrypts ciphertext $C_{D}=E_{key_{PD}}(m_{H}, m_{B}, m_{D})$ and computes MD_D = h(m_D), D signature $Sig_{D}=S_{PR_{D}}(MD_{D})$, and S₆ = h(SK_DC∥C_D∥Sig_D) and sends message {S₆,C_D,Sig_D} to CS through public channel.

Step 4. :

On getting messages, CS computes $SK^{\prime }_{DC}=h(ID_{P}\|RD\|sn_{i})$ and check whether $S^{\prime }_{6}=?h(SK^{\prime }_{DC}\|C_{D}\|Sig_{D})$ holds or not. If it does, CS store C_D,Sig_D. Otherwise, terminates the session and goes to Step 1.

Check up phase (CP)

In this phase, the P authenticates CS to encrypted medical report of the patient. The detail of the narration of this section is as follows:

Step 1. :

The patient inputs identity ID_P, request and sends message {ID_P,Request} to CS via secure public channel.

Step 2. :

On collecting message, CS executes S₈ = h(ID_P∥ID_D∥Sig_D) and sends message {S₈,C₈,Sig_D} to P via open channel.

Step 3. :

Upon getting information, P checks whether $S^{\prime }_{8}=? h(ID_{P}\|ID_{D}\|Sig_{D})$ holds or not. If it does not hold, exits the session. Otherwise, the P decrypts the ciphertext with using key_PD to get $(m_{H}, m_{B}, m_{D})= D_{key_{PD}}(C_{D})$ and verifies the signature $Sig_{D}= V_{PU_{D}}(Sig_{D})$ and checks whether MD_D =?h(m_D) hold or not. If it does, P encrypts message $C_{2}=E_{key_{P}}(m_{H}, m_{B}, m_{D})$, computes S₉ = h(SID∥C₂) and sends message {S₉,C₂} to the CS through public channel.

Step 4. :

On receiving message, CS checks whether $S^{\prime }_{9}=?h(SID\|C_{2})$ holds or not. If it does, CS store C₂, otherwise terminates the session and goes to Step 1.

Cryptanalysis of Mohit et al.’s scheme

After reviewed the Mohit et al.’s scheme, we found five security weaknesses in the protocol. We have discussed below as:

Stolen-verifier attack

The stolen-verifier attack, means that an adversary stoles the password or identity-verifier from the CS database and applies an off-line guessing attack on it to get patient’s correct OTP or identity ID_P. In Mohit et al.’s scheme, E stolen patient’s mobile phone, and intercepts in PUP. There are two following cases possible:

Stolen-verifier password attack

If an adversary E retrieves the store parameter key₁ = h(ID_P∥OTP), then he/she can successfully perform password guessing attack:

Step 1.:

An adversary E intercept in PUP, and retrieves ID_P.

Step 2.:

E guesses one time password OTP^∗ in one time password dictionary |OTP| and computes key₁ = h(ID_P∥OTP^∗), verifies h(ID_P∥OTP) =?h(ID_P∥OTP^∗).

Step 3.:

If the verification succeed, E consider OTP^∗ as a patients’s one time password. Otherwise step 2 is repeated.

The illustration of the attack is shown in Fig. 1.

Fig. 1

Stolen-verifier password attack

Stolen-verifier identity attack

If E retrieves the store parameter key₁ = h(ID_P∥OTP), then he/she can successfully perform identity guessing attack:

Step 1.:

E intercept in PUP, and retrieves patient’s OTP.

Step 2.:

E guesses an identity ID_E in identity dictionary |ID| and executes key₁ = h(ID_E∥OTP) and verifies h(ID_E∥OTP) =?h(ID_P∥OTP).

Step 3.:

If the verification succeed, consider ID_E as the patient identity, Otherwise Step 2 is repeated.

The illustration of the attack is shown in Fig. 2.

Fig. 2

Stolen-verifier identity attack

Many logged-in patient attack

The many logged-in patient attack is defined as the simultaneous access of a legitimate patient’s account of a CS by multiple adversaries using the same identity of the P. In Mohit et al.’s scheme, CS store the identity and OTP of the P in the database. But in this attack, we discuss only patient identities in PUP. Assume that legitimate identity ID_P is accountably exposed to many adversaries E₁,E₂,E₃,.....E_j......E_m, all knows ID_P and SID, then performed to CS at the same time by executing following steps:

Step 1.:

Each E_j sends the message {ID_P,SID} to CS.

Step 2.:

The CS computes I₁ = sn_i1 ⊕ SID,I₂ = sn_i2 ⊕ SID,I₃ = sn_i3 ⊕ SID,........I_j = sn_ij ⊕ SID,.....I_m = sn_im ⊕ SID and ${s^{1}_{3}}= h(SID\|I_{1}\| C_{H}\|Sig_{H}), {s^{2}_{3}}=h(SID \|I_{2}\| C_{H}\|Sig_{H}), {s^{3}_{3}}= h(SID\|I_{3}\|C_{H}\|Sig_{H}) .... {s^{j}_{3}}= h(SID\|I_{j}\|C_{H}\|Sig_{H}).....{s^{m}_{3}}= h(SID\|I_{m}\|C_{H}\|Sig_{H})$. Thus, CS allows all E₁,E₂,E₃,.....E_j......E_m to communicates in concurrently (Fig. 3).

Fig. 3

Many logged-in patient attack in Mohit et al.’s scheme

Patient anonymity

In Mohit et al.’s protocol, patient has the same identity in PUP, TP and CP. There was no anonymous identity use in these phases. These offer a chance for the attacker to track patient’s activity over public network.

Impersonation attack

In HUP of Mohit et al.’s protocol, CS store parameters ID_P,C_H,Sig_H,SID in database and sn_i is public. If E intercepts in PUP and perform as:

Step 1.:

E computes I_E = sn_i ⊕ SID,S_3E = h(SID∥I_E∥C_H∥Sig_H) and sends {I_E,S_3E,C_H,Sig_H} to P.

Step 2.:

On receiving message, P computes $sn^{\prime }_{i}= I_{E}\oplus SID, S^{\prime }_{3}= h(SID\|I_{E}\|C_{H}\| Sig_{H})$ and verifies that $S_{3E}= S^{\prime }_{3}$. Further, the P computes session key $SK_{PC}= h(ID_{P}\|SID), key_{1}=h(ID_{P}\|OTP), m_{H}= D_{key_{1}}(C_{H}), MD_{H}= V_{PU_{H}}(Sig_{H})$, where m_H = h(MD_H) and computes key_PD = h(ID_P∥ID_D∥sn_i), encrypts $C_{P}= E_{key_{PD}}(m_{H}, m_{B})$, computes MD_P = h(m_B), signature $Sig_{P}= S_{PR_{P}}(MD_{P}), S_{4}= h(SK_{PC}\|C_{P}\|Sig_{P})$ and sends {S₄,C_P,Sig_P} to E.

Step 3.:

On receiving message, E computes $SK^{E}_{PC}=h(ID_{P}\|SID)$ and ${S^{E}_{4}}= h(SK^{E}_{PC}\|C_{P}\|Sig_{P})$.

Here, $SK^{E}_{PC}$= SK_PC and ${S^{E}_{4}}$ = S₄. Thus, Mohit et al.’s scheme fails to protect the impersonation attack.

Fails to protect the session key

In PUP of Mohit et al.’s protocol. Then, P computes session key SK_PC = h(ID_P∥SID). From impersonation attack session 4.4, adversary E computes session key $SK^{E}_{PC}= h(ID_{P}\|SID)$. Thus E successfully computes the session key of the patient. Similarly, E got session key in HUP and TP. Hence, Mohit et al.’s scheme fails to support of session key.

Security model

In this section, we discuss the security model on the proposed scheme which is based on [1, 10, 53, 61]. There are two entities U and V, or every partner I with no difference in the proposed protocol $\mathcal {P}$. U has an identity ID_U and a password PW_U. V has an identity ID_V and a password PW_V. All passwords are in a dictionary with size $\mathcal {N}$, and elliptic curve group G has a generator g of order q.

Every party has several occurrence. Let U^S be the S^th occurrence of U. Similarly, V ^S and I^S can be prescribed. E case is an oracle. We apply a simulator to provides the replay to input information. In this way, there are three cases for an oracle: accept, reject and ⊥. If an oracle finds a ordinary information, the obtain state is achieved. If an incorrect information is collected, the reject case is arrived. Otherwise, if no response is generated, ⊥ occurs. Once upon a time the oracle Uⁱ or V ^j is established and determines a session key, each of them has the subsequent elements: a session identity $(sid_{U^{i}})$ or $(sid_{V^{j}})$, a partner identity $(pid_{U^{i}})$ or $(pid_{V^{j}})$, and a session key $(SK_{U^{i}})$ or $(SK_{V^{j}})$. E can totally run the simulator and query oracles to destroy the security of authentication or the session keys. We list all the oracles as followings:

Execute (Uⁱ,V ^j)::

This query simulates the passive attack, and permits the attacker E to learn all the transmitted communication between the instances of entities Uⁱ and V ^j.

Send[[spiespace:

]$(I, {I^{j}_{r}}, M)$:] This query simulates the active attack and It makes that the body I forwards a message M to the occurance ${I^{j}_{r}}$. If M is exact message and ${I^{j}_{r}}$ is prepared to accept the information, the simulator will return the message which ${I^{j}_{r}}$ should develop. Otherwise, if M is wrong, the query is aborted.

Reveal (I^k)::

It expresses known-key attacks and for U and V. If I^k grasps the status of partnering, the adversary E can obtain the session key through asking this query.

Corrupt (I^k)::

This query is use to check the perfect forward security property of the session key on the oracle I^k. All the messages of I^k is obtained by adversary E after this query, since E has known some message in the system, we list the specific as follow:

• Corrupt (Uⁱ): It allows the adversary E to concession the long-term private key of the session key of Uⁱ.

• Corrupt (V ^j): It allows the adversary E to concession the long-term private key of the session key of V ^j.

Test (I^k)::

At last adversary E chooses a session to challenge. At this time I may be U or V. If I^k has not been approved or it is not able for the view sfs − fresh which will disclosed below, the simulator will go back ⊥. Otherwise a coin s is toss. The simulator will output the actual session key if s = 1 appear. If s = 0 appears, a random string say session key is returned to adversary E.

We use few definitions for the verification of proof as follows:

Partnering : :

As the session key is created between Uⁱ and V ^j, we call Uⁱ and V ^j are partners if and only if they are established and $sid_{U^{i}}= sid_{V^{j}}$, $pid_{U^{i}} = V^{j}, Pid_{V^{j}}= U^{j}$ and $SK_{U^{i}}= SK_{V^{j}}$.

pfs-fresh (fresh with perfect forward security)::

We use this opinion for only Uⁱ and V ^j, we say that I^k is the pfs − fresh if no one the followings queries appears:

• E Reveal(I^k) occurs;

• E Reveal$(pid_{I^{k}})$ appears;

• Before Test arises, Corrupt(I^k) or $\textit {Corrupt}(pid_{I^{k}} )$ has been asked.

pfs- ake security : :

we define E’s advantage against the protocol $\mathcal {P}$ is the probability that E properly guesses the coin s after Test(I^k) query. Of course, I^k is established and pfs − fresh.

The advantage of E is $Adv^{pfs - ake}_{\mathcal {P}}(E)= 2Pro[s= s^{\prime }]-1$.

Where E outputs s^′. If Q_s is the number of Send queries and $Adv^{pfs - ake}_{\mathcal {P}}(E)$ is negligibly longer than $\frac {O(Q_{s})}{N}$ with l, the protocol is pfs − ake secure.

To show the protocol, we take two new assumptions for ECC. Those are based on the “Elliptic curve cryptography”.

• Elliptic Curve Decisional Diffie-Hellman problem (ECDDHP): Let ag,bg,cg ∈ G, The probability for E to determine whether cg = abg polynomial time t is $Adv^{ECDDHP}_{E}(t)$ and 𝜖 is an ignorably small positive real number and in fact $Adv^{ECDDHP}_{E}(t) \leq \epsilon$.

• Elliptic Curve Gap Diffie-Hellman problem (ECGDHP): Let ag,bg ∈ G, The probability for E to execute abg with an ECDDHP oracle in polynomial time t is $Adv^{ECDDHP}_{E}(t) \leq \epsilon$.

The proposed protocol

Architecture

There are five components associated in the proposed protocol for conversation are as follows:

(1) Patient: :

A person, who is applying for medical treatment.

(2) Doctor: :

A person, who has been skilled in medical science and offer treatment to patients.

(3) Healthcare center: :

A physical residence where the patient takes treatment.

(4) Cloud server: :

A server to collect patient’s medical data or records.

(5) Body sensor: :

A device associated with a physical impression of the patient and sends information to the patient’s mobile device.

The architecture of this proposed protocol is shown in the Fig. 4, and the details are as follows:

• Firstly P goes to HC for the routine-checkup/ inspection and takes registration, where HC support the report of the P.

• HC uploads the medical report/data of P to the CS. B installed in the P’s body collects the fitness information of the patient and forward to a P’s mobile device securely.

• P upload current medical record by updating the earlier data of the HC with the developed record by BS to the CS.

• CS forwards the medical information of P to the appreciated D in order of sequence number.

• D executes medical treatment by looking into the medical data and uploads latest information with the digital signature to the CS.

• CS sends the final medical report to P.

Fig. 4

Protocol architecture and authentication progress with ordering of phases

Protocol description

This scheme contains of five phases: (1) Healthcare center upload phase, (2) Patient data upload phase, (3) Treatment phase, (4) Checkup phase, and (5) Emergency phase. The details are as follows:

Healthcare center upload phase (HUP)

The patient registers herself/himself in HC, and HC assigns OTP and a dynamic pseudo random identity SID to P through secure mobile device. In this phase, HC performs mutual authentication with CS and uploads the P’s medical report to CS as displayed in the Fig. 5 and expressed as below:

Step 1. :

The healthcare center generates inspection report M_H = (ID_P,Data_P), random number $r \in Z^{\star }_{q}$, and inputs unique identity ID_H and r. Furthermore, HC sends M₁ = {ID_H,r,T_H1} to CS via a secure channel.

Step 2. :

On collecting message, CS verifies T_C1 − T_H1 ≤△T. If it does not hold, the CS terminates the session. Otherwise, generates random number $x \in Z^{\star }_{q}$ and computes H₁ = h(ID_H∥r∥x), A = ID_H ⊕ x,H₂ = h(H₁∥A∥r). Further, generates another random number $b \in Z^{\star }_{q}$ and sends message M₂ = {H₂,A,b,T_C2} to HC via public channel.

Step 3. :

On getting messages, HC checks T_H2 − T_C2 ≤△T. If it does not hold, HC terminates the session. Otherwise, computes $y= A\oplus ID_{H}, H_{3}= h(ID_{H}\| r \| y), \\H^{*}_{2}=h(H_{3}\|A\|r)$ and verifies whether $H^{*}_{2}=? H_{2}$ hold or not. If it does not hold, HC exits the session. Otherwise, HC authenticates CS and generates random number $a \in Z^{\star }_{q}$. Further, HC computes SK_HC = h(ID_H∥H₃∥A∥brg), K₁ = h(ID_P∥OTP∥ID_H), encrypts $C_{H}= E_{K_{1}}(M_{H})$, computes $MD_{H}= h(M_{H}), Sig_{H}= S_{PR_{H}}(MD_{H})$, H₄ = h(SK_HC∥C_H∥Sig_H∥abg∥T_H3) and again encrypts $C_{1}= E_{SK_{HC}}(ID_{P}, a, C_{H}, H_{4}, Sig_{H}$, SID,T_H3). Finally, the HC sends ,message M₃ = {C₁,T_H3} to the CS via public channel.

Step 4. :

Upon receiving message, the CS verifies T_C3 − T_H3 ≤△T. If it does not hold, CS terminate the session. Otherwise, computes SK_CH = h(ID_H∥H₁∥A∥brg), decrypts (ID_P,a,C_H,H₄, $Sig_{H}, SID, T_{H3})= D_{SK_{CH}}(C_{1})$, computes H₅ = h(SK_CH∥C_H∥Sig_H∥abg∥T_H3) and verifies whether H₅ =?H₄ hold or not. If it does, CS authenticates HC and CS stores ID_P,C_H,Sig_H and SID. Otherwise, CS terminates the session.

Fig. 5

Healthcare center upload phase (HUP)

Patient data upload phase (PUP)

The patient requests to BS, to gather the updated fitness information, and arranges it to the P through the mobile device securely. The P makes the request using his/her identity ID_P and OTP of the mobile device. CS contributes an engagement sequence number sn_i, inspection data report M_H to P as displayed in the Fig. 6 and discussed as below:

Step 1. :

The patient gets report M_B = (ID_P,Data_B) from body sensor via secure mobile device. Then, P takes his/her identity ID_P and dynamic pseudo random SID and sends message M₄ = {ID_P,SID,T_P1} to CS via secure channel.

Step 2. :

Upon collecting message, CS verifies T_C4 − T_P1 ≤△T. If it does not hold, CS terminate the session. Otherwise, computes N = sn_i ⊕ h(SID∥ID_P), generates random number $c \in Z^{\star }_{q}$, computes H₆ = h(SID∥sn_i∥C_H∥Sig_H∥T_C5), encrypts $L_{1}=E_{sn_{i}}(Sig_{H}, C_{H},H_{6}, ID_{H}, c, T_{C5})$ and sends message M₅ = {L₁,N,T_C5} to P.

Step 3. :

On receiving message, P checks T_P2 − T_C5 ≤△T. If it does not hold, P stops the session. Otherwise, computes N₁ = N ⊕ h(SID∥ID_P), decrypts $(Sig_{H}, C_{H},H_{6}, ID_{H}, c, T_{C5}) = D_{N_{1}}(L_{1})$, computes H₇ = h(SID∥N₁∥C_H∥Sig_H∥T_C5) and verifies whether H₇ =?H₆ hold or not. If it does not hold, P exits the session. Otherwise he/she authenticates CS, and generates random number $d \in Z^{\star }_{q}$. Further, computes SK_PC = h(ID_P∥ID_H∥N₁∥H₇∥cdg) and K₂ = h(ID_P∥OTP∥ID_H). Moreover, P decrypts the report $M^{*}_{H}= D_{K_{2}}(C_{H})$ and checks whether $M^{*}_{H}=? M_{H}$ hold or not. If it does not hold, P exits the session. Otherwise, computes $MD^{*}_{H}= V_{PU_{H}}(Sig_{H}$) and verifies $MD^{*}_{H}=? MD_{H}$. if it hold, computes K_PC = h(ID_P∥ID_H∥N₁), encrypts $C_{P}=E_{K_{PC}}(M_{H},M_{B})$, computes MD_P = h(M_B), makes digital signature $Sig_{P}= S_{PR_{P}}(MD_{P})$, computes H₈ = h(SK_PC∥C_P∥Sig_P∥cdg∥T_P3), again encrypts $L_{2}=E_{N_{1}}(d, H_{8}, Sig_{P}, C_{P}, ID_{P}, T_{P3})$ and sends message M₆ = {L₂,T_P3} to CS via public channel.

Step 4. :

Upon receiving message, the CS verifies T_C6 − T_P3 ≤△T. If it does not hold, CS terminate the session. Otherwise, decrypts $(d, H_{8},Sig_{P},C_{P}, ID_{P}, T_{P3}) = D_{sn_{i}}(L_{2})$, computes session key SK_CP = h(ID_P∥ID_H∥sn_i∥H₆∥cdg), H₉ = h(SK_CP∥C_P∥Sig_P∥cdg∥T_P3) and checks whether H₉ =?H₈ hold or not. If it does, CS authenticates P and stores C_P,Sig_P. Otherwise, terminates the session.

Fig. 6

Patient data upload phase (PUP)

Treatment phase (TP)

In this phase, the doctor and cloud server authenticates to each other and the doctor performs treatment of the patients. If they are valid entities, the cloud server uses the identity of doctor ID_D to find all of the D’s requests by P, who have prepared medical appointments, and forwards the P’s treatment description to doctor as displayed in the Fig. 7 and described as below:

Step 1. :

The Doctor generates random number e $\in Z^{\star }_{q}$ and sends message M₇ = {ID_D,e,T_D1} to the CS via a secure channel.

Step 2. :

On receiving message, CS verifies T_C7 − T_D1 ≤ΔT. If it does not hold, CS exits the session. Otherwise, computes N₂ = sn_i ⊕ h(SID∥ID_D∥ID_P), generates random number $f \in Z^{\star }_{q}$, computes H₁₀ = h(e∥sn_i∥Sig_P∥C_P∥T_C8), $L_{3}=E_{sn_{i}}(Sig_{P}, C_{P}, ID_{P}, ID_{H}, H_{10}, f, T_{C8})$. Further, sends the message M₈ = {L₃,N₂,T_C8} to D via public channel.

Step 3. :

On receiving message, D checks T_D2 − T_C8 ≤△T. If it does not hold, D terminates the session. Otherwise, computes N₃ = N₂ ⊕ h(SID∥ID_D∥ID_P) and decrypts (Sig_P,C_P,ID_P,ID_H, $H_{10}, f, T_{C8})= D_{N_{3}} (L_{3})$. Further, D computes H₁₁ = h(e∥N₃∥Sig_P∥C_P∥T_C8), verifies whether H₁₁ =?H₁₀ hold or not. If it does not hold, D exits the session. Otherwise, he/she authenticates to the CS and computes SK_DC = h(ID_P∥ID_D∥N₃∥H₁₁∥efg), K_DC = h(ID_P∥ID_H∥N₃). Moreover, D decrypts the report as $(M_{H}, M_{B})=D_{K_{DC}}(C_{P})$, computes $MD^{*}_{P}= V_{PU_{P}}(Sig_{P})$ and checks whether $MD^{*}_{P}= ? MD_{P}$ hold or not. If it does not hold, then D stops the session. Otherwise, D makes a medical diagnosis report based on M_D = (ID_P,Data_D) and encrypts $C_{D}= E_{K_{DC}}(M_{H}, M_{B}, M_{D})$. Furthermore, D computes MD_D = h(M_D) and makes digital signature message $Sig_{D}= S_{PR_{D}}(MD_{D})$. In additionally, D computes H₁₂ = h(SK_DC∥C_D∥Sig_D∥Sig_P∥efg∥T_D3), encrypts L₄=$E_{N_{3}}(Sig_{D}$, C_D, H₁₂, T_D3) and sends message M₉ = {L₄,T_D3} to CS via public network.

Step 4. :

On accepting message, CS verifies T_C9 − T_D3 ≤△T. If it does not hold, CS terminates the session. Otherwise, CS decrypts (Sig_D,C_D, $H_{12}, T_{D3})=E_{sn_{i}}(L_{4})$, computes SK_CD = h(ID_P∥ID_D∥sn_i∥H₁₀∥efg),H₁₃ = h(SK_CD∥C_D∥Sig_D∥Sig_P∥efg∥T_D3) and checks whether H₁₃ =?H₁₂ hold or not. If it does, CS authenticates D and stores C_D,Sig_D. Otherwise, D terminates the session.

Fig. 7

Treatment phase (TP)

Checkup phase (CP)

In this phase, P and CS authenticate to each other. Then, CS sends the encrypted the report to P. The detail description of this phase as displayed in the Fig. 8 and explained as below:

Step 1. :

The patient takes his/her identity ID_P, as request and sends message M₁₀ = {ID_P,request,T_P4} to CS via a secure channel.

Step 2. :

Upon collecting message, CS verifies T_C10 − T_P4 ≤△T. If it does not hold, CS exits the session. Otherwise, computes N₄ = h(ID_P∥sn_i). Further, generates random number $f_{1} \in Z^{\star }_{q}$, computes H₁₄ = h(ID_P∥C_D∥Sig_D∥Sig_P∥T_C11), $L_{5}=E_{N_{4}}(H_{14},Sig_{D}, C_{D}, f_{1}, T_{C11})$ and sends message M₁₁ = {L₅,T_C11} to P via public channel.

Step 3. :

On receiving message, P checks T_P4 − T_C11 ≤△T. If it does not hold, P stop the session. Otherwise, computes N₅ = h(ID_P∥N₁), decrypts $(H_{14}, Sig_{D}, C_{D}, f_{1}, T_{C11})= D_{N_{5}} (L_{5})$, and computes $H^{*}_{14}= h(ID_{P}\|C_{D}\|Sig_{D}\|Sig_{P}\| T_{C11})$, and verifies whether $H^{*}_{14}=? H_{14}$ hold or not. If it does not hold, D stops the session. Otherwise he/she authenticates CS. Then, P decrypts the report as $(M_{H}, M_{B}, M_{D})= D_{K_{PC}}(C_{D})$, and computes $MD^{*}_{D}= V_{PU_{D}}(Sig_{D})$ to checks whether $MD^{*}_{D}=? h(M_{D})$ hold or not. If it does not hold, then stops the session. Otherwise, generates random number $f_{2} \in Z^{\star }_{q}$, encrypts $C_{2}= E_{K_{PC}}(M_{H}, M_{B}, M_{D}, f_{2})$, computes H₁₅ = h(N₅∥C₂∥Sig_P∥Sig_D∥f₁f₂g∥T_P6), again encrypts $L_{6}=E_{N_{5}}(C_{2}, H_{15}, f_{2}, T_{P6})$ and sends message M₁₂ = {L₆,T_P6} to CS via public channel.

Step 4. :

Upon receiving message, CS verifies T_C12 − T_P5 ≤△T. If it does not hold, CS terminates the session. Otherwise, CS decrypts computes $(C_{2},H_{15}, f_{2}, T_{P6})= D_{N_{4}} (L_{6})$, computes $H^{*}_{15}= h(N_{4}\|C_{2}\|Sig_{P}\|Sig_{D}\|f_{1}f_{2}g\|T_{P6})$ and also verifies whether $H^{*}_{15}=? H_{15}$ hold or not. If it does, CS authenticates P and stores C₂. Otherwise, terminates the session.

Fig. 8

Checkup phase (CP)

Emergency phase (EP)

The patients use the body sensors network, and relocate the regular medical information to the cloud server. If the patient has an emergency, then the patient inputs his/her identity, sequence number and request sends to CS. Then, CS sends the information to HC. After verification the doctor provides treatment to the patients. The detail description of this phase as shown in the Fig. 9 and discussed as below:

Step 1. :

P inputs his/her identity ID_P,N₅,request, computes H₁₆ = h(ID_P∥N₅∥T_EP1), encrypts $L_{7}=E_{N_{5}}(H_{16}, T_{EP1})$ and sends message M_E1= {L₇,T_EP1} to CS via public channel.

Step 2. :

On receiving message, CS verifies T_EC1 − T_EP1 ≤△T. If it does not hold, CS terminates the session. Otherwise, decrypts $(H_{16}, T_{EP1})= D_{N_{4}} (L_{7})$, computes $H^{*}_{16}= h(ID_{P}\|N_{4}\|T_{EP1})$ and checks whether $H^{*}_{16}=? H_{16}$ hold or not. If it does not hold, CS terminates the session. Otherwise, generates random number $p \in Z^{\star }_{q}$, computes H₁₇ = h(ID_P∥ID_H∥Sig_H∥Sig_P∥T_EC2), $L_{8}=E_{SK_{CH}}(H_{17}, p, Sig_{P}, ID_{P}, T_{EC2})$ and sends message M_E2 = {L₈,T_EC2} to HC via public network.

Step 3. :

On receiving messages, HC verifies T_EH1 − T_EC2 ≤△T. If it does not hold, HC terminates the session. Otherwise, decrypts (H₁₇,p,Sig_P, $ID_{P}, T_{EC2})= D_{SK_{HC}} (L_{8})$, computes $H^{*}_{17}= h(ID_{P}\|ID_{H}\|Sig_{H}\|Sig_{P}\|T_{EC2})$ and verifies $H^{*}_{17}=? H_{17}$ hold or not. If it does not hold, HC terminates the session. Otherwise, generates random number $s \in Z^{\star }_{q}$, computes SK_HP = h(ID_P∥ID_H∥Sig_H∥Sig_P∥psg), H₁₈ = h(ID_P∥ID_H∥p∥s∥T_EH2), $L_{9}=E_{SK_{HC}}(s, H_{18}, T_{EH2})$ and sends message M_E3 = {L₉,T_EH2} to CS via public channel.

Step 4. :

On receiving message, CS verifies T_EC3 − T_EH2 ≤△T. If it does not hold, CS stops the session. Otherwise, CS decrypts $(s, H_{18}, T_{EH2})= D_{SK_{CH}} (L_{9})$, computes $H^{*}_{18}= h(ID_{P}\|ID_{H}\| p\|s\|T_{EH2})$ and verifies $H^{*}_{18}=? H_{18}$ hold or not. If it does not hold, CS terminates the session. Otherwise, authenticates HC by computing H₁₉ = h(Sig_P∥Sig_H∥pg∥sg∥T_EC4), encrypts $L_{10}=E_{N_{4}}(ID_{H}, p, s, H_{19}, T_{EC4})$ and sends message M_E4 = {L₁₀, T_EC4} to P via public network.

Step 5. :

Upon receiving message, P verifies T_EP2 − T_EC4 ≤△T. If it does not hold, P terminates the session. Otherwise, decrypts $(ID_{H}, p, s, H_{19}, T_{EC4})=D_{N_{5}} (L_{10})$, computes $H^{*}_{19}= h(Sig_{P}\| Sig_{H}\|pg\|sg\|T_{EC4})$, and verifies whether $H^{*}_{19}=? H_{19}$ hold or not. If it does not hold, P terminates the session. Otherwise, P authenticates CS and computes session key SK_HP = h(ID_P∥ID_H∥Sig_H∥Sig_P∥psg).

Fig. 9

Emergency phase (EP)

Security proof

Formal proof of the proposed protocol

Theorem: Patient data upload phase (PUP) of our protocol $\mathcal {P}$ employees a additive cyclic group G on an elliptic curve with a large prime order q. $\mathcal {N}$ is the size of one time password dictionary $\mathcal {D}$. If adversary E makes no more than Q_s send queries, Q_h hash queries, and Q_e execute queries, then

$$\begin{array}{@{}rcl@{}} Adv^{pfs - ake}_{\mathcal{P}}(E) &\leq& \frac{O(Q_{h})^{2}+O(Q_{s}+Q_{e})^{2}}{2^{l}}\\ &&+\frac{O(Q_{s}+Q_{e})^{2}}{(q-1)} + \frac{O(Q_{h})+ O(Q_{s})}{2^{l-1}}\\ &&+ \frac{O(Q_{s})}{\mathcal{N}}+ O(Q_{h}(Q_{s}+Q_{e})^{2}+ 1)\\ && \times Adv^{ECDDH}_{E}(t^{\prime}) \end{array} $$

Where t^′ = t + (O(Q_e) + O(Q_s))T_M and T_M is the time of one multiplication in G.

Proof: We prove this theorem with the help of a sequence of games. There are total eight games from G₀ to G₇. Succ_j is the action for adversary E accurately guessing the coin s through the investigation session in Game G_j. Since, there is one patient P in these games, E want to computes or guesses P’s identity ID_P. We have to discuss the games following as:

• Game G₀: This game is the actual game against the proposed authentication scheme of PUP with the random oracle model, from the definition, we have

  $$ Adv^{pfs - ake}_{\mathcal{P}}(E)= 2Pro[Succ_{0}]-1 $$

  (1)

  Furthermore, If various atypical circumstances occur, a random s^∗ is called as a report. The list of the atypical circumstances as follows:

  • The game exit or cancels or since E does not present the predicted s^∗.

  • More queries than the prearranged upper bound are used by E.

  • More time than the deliberated upper bound is used by E.

• Game G₁: In this game, we take addition of all counterfeited queries. Moreover, there are only three lists to accumulate the answers to the queries.

  • L_H: For the answer to all hash queries.

  • L_P: For the transcription of the communication.

  • L_E: It is for the respond of the two random oracles queried precisely by adversary E.

  The queries are established in Fig. 10. According to the situations mentioned above, Game G₁ and Game G₀ are indistinguishable and we can notice that

  $$ Pro[Succ_{1}]=Pro[Succ_{0}] $$

  (2)

  Fig. 10

  

  Simulation of queries

• Game G₂: In this game, we avoid the collisions in the transcriptions. There are three types of collisions. As stated in the birthday paradox, we display the probabilities of them:

  • $c, d \in Z^{\star }_{q}$ may collide particular session and upper bound for the case is

    $$\frac{O(Q_{s}+ Q_{e})^{2}}{2(q-1)} $$

  • Dynamic pseudo random identity $SID \in Z^{\star }_{q}$ may collide in different session and upper bound for the case is

    $$\frac{O(Q_{s}+ Q_{e})^{2}}{2^{l + 1}} $$

  • The hash function results may collide and upper bound for the case is

    $$\frac{O(Q_{h})^{2}}{2^{l + 1}}. $$

  From Game G₂ and Game G₁ are indistinguishable except the collisions occur. We observe that

  $$\begin{array}{@{}rcl@{}} |Pro[Succ_{2}]&-&Pro[Succ_{1}]|\leq \frac{O(Q_{s}+ Q_{e})^{2}}{2(q-1)}\\ &+&\frac{{O(Q_{h})^{2}}+ O(Q_{s}+ Q_{e})^{2}}{2^{l + 1}} \end{array} $$

  (3)

• Game G₃: In this game, we consider the probability of the attack that adversary E fakes message M₄. Since the simulator permits the answer as CS, we attach some steps on Send(Pⁱ,CS^j,M₄) the simulator wants to verify if M₄ ∈ L_P. If it is failing the query will stop. Here Game G₃ and Game G₂ are indistinguishable if the verifiers are under deliberation. We can obtain

  $$ | Pro[Succ_{3}]-Pro[Succ_{2}]| \leq \frac{O(Q_{s})}{2^{l}} $$

  (4)

• Game G₄: In this game, we deal with the probability of the attack that adversary E fakes message M₅. Since the simulator permits the answer as P, we attach some steps on Send(CS^j,Pⁱ,M₅) the simulator wants to verify if M₅ ∈ L_P and, (⋆∥ID_P,⋆),(⋆∥sn_i∥C_H∥Sig_H∥T_C5,H₆) ∈ L_E. If it is failing the query will stop. Here Game G₄ and Game G₃ are indistinguishable if the verifiers are under deliberation. We can obtain

  $$ | Pro[Succ_{4}]-Pro[Succ_{3}]| \leq \frac{O(Q_{s}+Q_{e})}{2^{l}} $$

  (5)

• Game G₅: In this game, we consider the probability of fake message M₆. Since the simulator gives the response as the CS. We append some steps on Send(Pⁱ,CS^j,M₆). The simulator wants to validate if M₆ ∈ L_P and (⋆∥ID_P,⋆),(⋆∥⋆∥C_H∥Sig_H∥T_C5,H₇),(1,ID_P∥ID_H∥⋆∥⋆∥⋆,⋆),(ID_P∥ID_H∥⋆,K_PC),(⋆∥C_P∥Sig_P∥⋆∥T_P3,H₈) ∈ L_E. If it is failing the query will stop. Here Game G₅ and Game G₄ are indistinguishable if the verifiers are under deliberation. We can obtain (⋆∥ID_P,⋆),(⋆∥⋆∥C_H∥Sig_H∥T_C5,H₇),(1,ID_P∥ID_H∥⋆∥⋆∥⋆,⋆),(ID_P∥ID_H∥⋆,K_PC),(⋆∥C_P∥Sig_P∥⋆∥T_P3,H₈) ∈ L_E. So we found that

  $$ |Pro[Succ_{5}]-Pro[Succ_{4}]|\leq \frac{O(Q_{h}+ Q_{s})}{2^{l}} $$

  (6)

• Game G₆: In this game, we take on ECGDHP. If adversary E can obtain the actual session key via hash oracle and be the success, we judge that E crack the problem. We adjust the hash oracle as follows: On one occasion E queries (1,ID_P∥ID_H∥sn_i∥X∥X,X),(X∥C_P∥Sig_P∥X∥X∥T_P3), the simulator first verifies if (1,ID_P∥ID_H∥sn_i∥H₆∥⋆,SK_PC),(SK_PC∥C_P∥Sig_P∥ ⋆ ∥T_P3) ∈ L_E. If it is in, SK_PC is returned. Otherwise, the simulator utilizes the ECGDHP oracle to evaluator X =?ECGDHP(cg,dg). If it is unsuccessful, the query is dropped. Otherwise, the simulator selects a random string SK_PC ∈{0,1}^l outputs it and adds (1,ID_P∥ID_H∥sn_i∥X∥X,SK_PC) to L_E.

  We analyze this game with two characteristics: the active attack and the passive attack. First E asks a Corrupt query and obtains all information:

  • It is for online OTP guessing attacks. E could embrace judge a OTP from the dictionary. Since E can utilize Send query Q_s and the size of OTP dictionary is $\mathcal {N}$, the probability for E to guess the exact OTP by loading a session is bounded by $\frac {Q_{s}}{\mathcal {N}}$.

  • For the passive attacks. There are two methods in this case:

    • ◇ The first is E finds information, he/she asks Execute queries. At the end E asks the hash query to succeed and cracks ECGDHP. We can find cdg. From L_E with the probability 1/Q_h. So the probability for this case is bounded by $Q_{h}Adv^{ECGDHP}_{E}(t+O(Q_{e})T_{M}$).

    • ◇ The other is E asks Send queries successively. Like the first kind of a passive attack, we can find that the upper bound probability of this case is $Q_{h}Adv^{ECGDHP}_{E}(t+ O(Q_{s})T_{M})$

The probability for the two types of the passive attack is

$$\begin{array}{@{}rcl@{}} &&Q_{h}Adv^{ECGDHP}_{E}(t+O(Q_{e})T_{M})+Q_{h}Adv^{ECGDHP}_{E}\\ &&\times(t+O(Q_{s})T_{M})\\ &\leq& Q_{h}Adv^{ECGDHP}_{E} .(2t+[O(Q_{s})+O(Q_{e})]T_{M}) \end{array} $$

Let t^′ = (2t + [O(Q_s) + O(Q_e)]T_M), then we got

$$ | Pro[Succ_{6}]-Pro[Succ_{5}]|\le \frac{Q_{s}}{\mathcal{N}}+Q_{h}Adv^{ECGDHP}_{E}(t^{\prime}) $$

(7)

• Game G₇: This game is for perfect forward security. E can determine all planned Corrupt queries. But according to the approach of sfs − fresh, Corrupt queries should be asked after the Test query. So adversary E can only exploit the historical queries and transcripts. In this last game, we can obtain (1,ID_P∥ID_H∥sn_i∥X∥X,SK_PC) in L_E. The probability of getting cg and dg in the same session is 1/(Q_s + Q_e)² and we have

  $$ |Pro[Succ_{7}]-Pro[Succ_{6}]|\!\!\leq\!\! Q_{h}(Q_{s}+Q_{e})^{2}Adv^{ECGDHP}_{E}(t^{\prime}) $$

  (8)

Combining the above games, there is no benefit for E to guess the session key and $Pro [Succ_{6}] =\frac {1}{2}$. Taking the sum of all results of these games, Theorem can be proved.Remark : Similarly the formal security proof of Healthcare center upload phase (HUP), Treatment phase (TP) and Emergency phase (EP) can also be analyzed.

Informal security analysis

In this phase, we evaluated that the prospective scheme has the capability to resist different cryptographic attacks.

Proposition 1

The proposed framework could assure the man-in-the-middle attack.

Proof

In our protocol, every step of every phase has time-stamp condition T_i − T_j ≤△T and hash condition H_i =?H_j. If possible, an attacker inter in these phases after verifying the times-tamp condition then, check the hash condition H_i=?H_j which not possible by the definition one way hash function is secure. Thus adversary will not get success in any phase. Therefore, our protocol protects the man-in middle attack. □

Proposition 2

The proposed protocol could assure the patient anonymity.

Proof

We describe the patient anonymity in each authentication phase:

• During HUP, the patient identity ID_P is encrypted by screening original identity. Here, patient identity ID_P in encrypted with session key SK_HC = h(ID_H∥H₁∥A∥brg), as get $C_{1}= E_{SK_{HC}}(ID_{P}, a, C_{H}, H_{4}, Sig_{H}, SID, T_{H3})$ and only be decrypt by cloud server $(ID_{P}, a, C_{H}, H_{4}, Sig_{H}, SID, T_{H3})= D_{SK_{CH}}(C_{1})$ with containing session key SK_CH = h(ID_H∥H₁∥A∥brg) and verifies the condition H₅ =?H₄ then, stores ID_P,C_H,Sig_H,SID.

• During PUP, the patient identity ID_P is encrypted by screening original identity. Here, patient identity ID_P in encrypted with session key N₁ = N ⊕ h(ID₍SID∥ID_P), as get $L_{2}= E_{N_{1}}(d, H_{8}, Sig_{P}, C_{P} a, C_{H}, ID_{P}, T_{P3})$ and only be decrypt by cloud server $(d, H_{8}, Sig_{P}, C_{P}, a, C_{H}, ID_{P}, T_{P3})= D_{sn_{i}}(L_{2})$, where, sn_i is the sequence number of patient and verified hash condition H₉ =?H₈ then, stores C_P,ID_P,Sig_P.

Similarly, the patient anonymity is hold in TP, CP and EP. Therefore, our protocol provides patient anonymity. □

Proposition 3

The proposed protocol could protect the strong replay attack.

Proof

Replay attack is a common attack in authentication procedure. However, the common countermeasures are time-stamps and random number. In our protocol, we adopt the time-stamp and random number as a counter-measure in every steps of every phases, receiver will check it. the times-tamps is legal or not by checking the valid time interval with equation T_i − T_j ≤△T , where △T is the valid time interval. Further, random number used random number to computing session key, hash values and different keys. Therefore, replay attack could not work in the proposed protocol. □

Proposition 4

The proposed protocol could provide the known-key security property.

Proof

The proposed scheme describes the different session keys in different phases:

• During HUP, the HC computes session key SK_HC = h(ID_H∥H₃∥A∥brg) and CS computes session key SK_CH = h(ID_H∥H₁∥A∥brg).

• During PUP, P computes session key SK_PC = h(ID_P∥ID_H∥N₁∥H₇∥cdg) and CS computes SK_CP = h(ID_P∥ID_H∥sn_i∥H₆∥cdg).

• During TP, D computes session key SK_DC = h(ID_P∥ID_D∥N₃∥H₁₁∥efg) and CS computes SK_CD = h(ID_P∥ID_D∥sn_i∥H₁₀∥efg).

• During EP, P computes session key SK_PH = h(ID_P∥ID_H∥Sig_P∥Sig_H∥psg) and HC computes SK_HP = h(ID_P∥ID_H∥Sig_P∥Sig_H∥psg).

The proposed protocol, presents different session key in a different phase. Even if the adversary abducts the earlier session key, she/he cannot computes the session key for the new phase. Thus, the proposed scheme has the quality of known-key security. □

Proposition 5

The proposed framework could protect the data Confidentiality.

Proof

Confidentiality is the method to security on transferring of data from the attacker. The encryption and description of data are given below:

• During HUP, HC encrypts the report as $C_{H}= E_{K_{1}}(M_{H})$ with using key K₁ = h(ID_P∥OTP∥ID_P) and upload to cloud server.

• During PUP, the patient encrypts $C_{P}= E_{K_{PC}}(M_{H}, M_{B})$ with using key K_PC = h(ID_P∥ID_D∥N₁) and upload to CS.

• During TP, D encrypts ciphertext $C_{D}= E_{K_{DC}}(M_{H}, M_{B}, M_{D})$ with using key K_DC = h(ID_P∥ID_D∥N₃) and upload to CS.

• During CP, P decrypts $C_{2}= E_{K_{PC}}(M_{H}, M_{B}, M_{D}, f_{2})$ using key K_PC = h(ID_P∥ID_D∥N₁) and upload to CS.

Thus, if an attacker tries to find data information during the transmission, she/he encrypts message which cannot be decrypted without the key and the hash value of inputs, as the definition of hash function is secure and one way. Therefore, the proposed protocol protect the confidentiality. □

Proposition 6

The proposed scheme could protect the data Non-repudiation.

Proof

The proposed protocol describes data Non- repudiation in different phases:

• During HUP, HC signs a message Sig_H= $S_{PR_{H}} (MD_{H})$.

• During PUP, P verified HC’s signature by computing $MD^{*}_{H}= V_{PU_{H}}(Sig_{H})$ and Verifies if $MD^{*}_{H}\overset {?}{=}MD_{H}$ hold or not. After that, P computes signature $Sig_{P}= S_{PR_{P}}(MD_{P})$.

• During TP, D verified P’s signature by computing $MD^{*}_{P}= V_{PU_{P}}(Sig_{P})$, checks whether $MD^{*}_{P}=? M_{P}$ hold or not and makes signature $Sig_{D}= S_{PR_{D}}(MD_{D})$.

• During CP, P verified D’s signature by computing $MD^{*}_{D}= V_{PU_{D}}(Sig_{D})$, checks whether $MD^{*}_{D}=?h(MD_{D})$ hold or not.

Thus, the patient verifies the health records. If the medical data have similar complications, the responsible person cannot be refused. The non-repudiation facts are stored in the cloud. Therefore, our proposed protocol protested data non-repudiation (Table 2). □

Table 2 Comparison of Functionality features

Proposition 7

The proposed protocol could provide Message authentication.

Proof

Message authentication is a method used to authenticate the integrity of the information. We describe message authentication in different phases below as:

• In HUP, HC receives message M₂ = {H₂,A,b,T_C2} and verifies the validity by checking time-stamps condition T_H2 − T_P2 ≤△T and hash function $H^{*}_{}=? H_{2}$. Similarly, CS receives message M₃ = {C₁,T_H3} and verifies the validity by checking timestamps condition T_C3 − T_H3 ≤△T, and hash function H₅ =?H₄. If any attacker endeavors alter any change of the message CS will recognize it.

• In PUP, P receives message M₅ = {L₁,N,T_C5}, verifies the validity by checking time-stamps condition T_P2 − T_C5 ≤△T, hash condition H₇ =?H₆ and $M^{*}_{H}=? M_{H}, MD^{*}_{H}=? MD_{H}$. Similarly, CS receives message M₆ = {L₂,T_P3} and verifies the validity by checking time-stamps condition T_C6 − T_P3 ≤△T and hash condition H₉ =?H₈. If any of the validation fails message will not be established.

• In TP, D receives message M₈ = {L₃,N₂,T_C8} and verifies the validity by checking the time-stamp condition T_D2 − T_C8 ≤△T and hash function H₁₁ =?H₁₀ and $MD^{*}_{P}=? MD_{P}$. Further, CS receives message M₉ = {L₄,T_D3} and verifies the validity by checking the time-stamp condition T_C9 − T_D3 ≤△T and hash function H₁₃ =?H₁₂. Message authentication verified between the D and the CS.

• In CP, P receives message M₁₁ = {L₅,T_C11} and verifies the validity by checking the time-stamp condition T_P4 − T_C11 ≤△T hash function $H^{*}_{14}=? H_{14}$ and $MD^{*}_{D}=?h(M_{D})$. Again CS receives message M₁₂ = {L₆,T_P6} and verifies the validity by checking time-stamps condition T_C12 − T_P6 ≤△T and hash condition $H^{*}_{15} =? H_{15}$. If any of the verification fails message will not be accepted.

• In EP, HC receives message M_E2 = {L₇,T_EC2} and verifies the validity by checking time-stamps condition T_EH1 − T_EC2 ≤△T and hash condition $H^{*}_{17}=? H_{17}$. CS receives message M_E1 = {L₈,T_EP1} and verifies the validity by checking time-stamps condition T_EC1 − T_EP1 ≤△T and hash condition $H^{*}_{16}=? H_{16}$, and CS also receives message M_E3 = {L₉,T_EH2} and verifies the validity by checking time-stamps condition T_EC3 − T_EH2 ≤△T and hash condition $H^{*}_{18}=? H_{18}$. Further, P receives message M_E4 = {L₁₀,T_EC4} and verifies the validity by checking time-stamps condition T_EP2 − T_EC4 ≤△T, hash function $H^{*}_{19}=? H_{19}$. If any of the verification fails message will not be accepted.

Therefore, this protocol protects the message authentication in every phase. □

Proposition 8

The proposed protocol could protect the impersonation attack.

Proof

We discussed the details of impersonation attacks in HUP as below:

• Any E tries to masquerade as a valid CS, and eavesdrop the transferred information message M₂ = {H₂,A,b,T_C2} and tries to computes H₂, where H₁ = h(ID_H∥r∥x),A = ID_H ⊕ x,H₂ = h(H₁∥A∥r). E cannot compute H₁, which the hash attribute of parameters ID_H,r,x where ID_H is the unique identity of the HC, r is a random number which generated by the HC and x is the secret value of CS. Note that, guessing of all three value at the same time is impossible. Further, E cannot compute H₂ which the hash value of H₁,A,r. Thus the adversary cannot impersonate as valid CS.

• E tries to impersonate as a valid a HC. If E breaks the time-stamp condition T_H2 − T_C2 ≤△T, guesses the identity of HC as ID_E = ID_H and random number r. Then, computes y_E = A ⊕ ID_E,H_E3 = h(ID_E∥r∥y_E) and H_E2 = h(H₃∥A∥r). Verifies the condition $H^{*}_{E2}=? H_{2}$ which not hold, as $H^{*}_{2}$ is the hash value of parameters H₃,A, and r. By the definition of hash function, $H^{*}_{2}$ is the secure value. Thus, E cannot impersonate as the valid HC.

Similarly, impersonation attacks not possible in PUP, TP, CP and EP phases. Hence, the protocol is secured against the impersonation attack. □

Proposition 9

The proposed scheme could protect the session key security.

Proof

The proposed protocol having four session keys those are compute between 1) HC and CS, 2) P and CS, 3) D and CS, and 4) P and HC. Here, we have discuss the session key security of HUP. However, the approach is the similar other remaining phases.

• In HUP, the session key between the HC and CS is SK_HC = SK_HC, where SK_HC = h(ID_H∥H₃∥A∥brg) and SK_CH = h(ID_H∥H₁∥A∥brg). E cannot computes the session key SK_HC or SK_HC, where $H_{1}= h(ID_{H}\|r\| x), H_{3}= h(ID_{H}\| r\|y), A= ID_{H}\oplus x, H^{*}_{2}= h(ID_{H}\|A\|r)$. With the help of Proposition 8, H₁ and $H^{*}_{2}$ cannot be computed by E. Further, For $b, r \in Z^{\star }_{q}$ and g is the generator of G, given (g,bg,rg), then compute brg is hard to the group G by ECCDHP in the elliptic curve cryptography. Thus, the session key can only be generated by the authenticated party.

Similarly, session key generated in PUP, TP and EP. Hence the proposed scheme could protect the session key □

Proposition 10

The proposed framework could protect the stolen mobile device attack.

Proof

Suppose that E stolen the mobile phone of the authorized P, E cannot find any secret communication of the P. As the mobile phone accepts the message, which is reachable only by inputs valid identity of P and OTP of mobile phone. In PUP, P computes key K₂ = h(ID_P∥OTP∥ID_H). Where OTP is the unique one time password of P’s mobile device and h(.) is the one way hash function which is secure by define it. Therefore, E cannot break the system even if she/he gets the mobile device of the valid patient.

Similarly, in HUP adversary does not break the system even if she/he grabs the mobile phone of the registered P. Thus, the proposed framework assures the stolen mobile device attack. □

Proposition 11

The proposed protocol could protect the off-line password/ identity guessing attack.

Proof

We discussed this attack in PUP. If possible, any E interprets in PUP and guesses the identity ID_E of valid P, then compute N_E = N ⊕ h(SID∥ID_E) and key K_E1 = h(ID_E∥OTP∥ID_H), Where OTP is the unique OTP of P. Thus, N_E≠N₁ and K_E≠K₂ because SID is unique for each patient, N₁ = N ⊕ h(SID∥ID_P) and ID_H is identity of HC which is also unique. On the other hand, if possible he/she guesses one time password OTP_E of legal patient, then computes K_E2 = h(ID_E∥OTP_E∥ID_H). As a result, K_E2≠K₂. Hence, off-line password/identity guessing attack cannot work in PUP of the proposed protocol.

Similarly, off-line password/identity guessing attack not possible in HUP, TP, CP and EP. Thus, off-line password/ identity guessing attack not possible in the proposed framework. □

Proposition 12

The proposed framework could resist many logged-in patient attack.

Proof

We discussed this attack in PUP. Suppose that many adversaries E₁,E₂,E₃,....E_j....E_m having same identity ID_P and sends messages $\{ID_{P}, SID, T_{E_{1}}\}, \{ID_{P}, SID, T_{E_{2}}\},\! \{ID_{P},\! SID,\! T_{E_{3}}\},......\{ID_{P}\!,\! SID\!,\! T_{E_{j}}\},\!.....\{ID_{P}\!,\!SID,T_{E_{m}}\}$ to CS, where $T_{E_{j}}$ is current message sending time of j^th adversary. Here, we discuss about only adversary E_j. On receiving message from adversary E_j, then CS verifies $T_{C4}- T_{E_{j}} \leq \triangle T$, If possibly hold, the CS computes N = sn_i ⊕ h(SID∥ID_P), generates random number $c \in Z^{\star }_{q}$, computes H₆ = h(SID∥sn_i∥C_H∥Sig_H∥T_C5), encrypts $L_{1}=E_{sn_{i}}(Sig_{H}, C_{H},H_{6}, ID_{H}, c, T_{C5})$ and sends message M₅ = {L₁,N,T_C5} to E_j via public channel. On receiving message E_j verifies $T_{E_{j}} - T_{C5} \leq \triangle T$ and computes ${N^{E}_{1}}= N\oplus h(SID\|ID_{P})$, decrypts $(Sig_{H}, C_{H},H_{6}, ID_{H}, c, T_{C5}) = D_{N^E_{1}}(L_{1})$, computes ${H^{E}_{7}}= h(SID\|N^E_{j}\|C_{H}\|Sig_{H}\|T_{C5})$. Here, $H^{E_{j}}_{7}\neq H_{6}$ as sn_i,SID,T_C5 are different and unique for each patients. Thus many logged-in patient’s attack is not work in PUP.

Similarly, many logged-in patient attack does not work in in CP and EP. Therefore, our protocol protected against many logged-in patient’s attack. □

Performance analysis

In this section, we estimate performance of the proposed framework with the relevant schemes worked in cloud environment for secure medical data communication, such as Chen et al. [15], Chiou et al. [17], Chen-Yang et al. [16] and Mohit et al. [39] protocols. The comparison performed in all the phases of framework like HUP, PUP, TP, CP and EP bellow as:

We have adopted different cryptographic operations in this paper based on the information applicable in Chiou et al. [17] to test the computation cost of the proposed protocol still existing relevant research. Chiou et al. [17], Windows 7 OS and Android phone used and the system structure of mobile phone is Android 4.4.4KTU84P along with a 2GB RAM and 1.8 GHz processor. The configurations of computer system is Windows 7, Professional with an Intel (R) core (TM) 2 Quad CPU Q8300, 2GB RAM and @2.50Hz. The execution time in second for the different time complexity symbols are as follows:

• T_Sign :The time for calculating execute/verify a signature (T_Sign ≈ 0.3317sec).

• T_A : the time for calculating asymmetric encryption/ decryption operation (T_A ≈ 0.3057sec).

• T_M : the time for calculating multiplication operation (T_M ≈ 0.0503sec).

• T_P : the time for calculating a bilinear pairing operation (T_P ≈ 0.0621sec).

• T_S : the time for calculating symmetric encryption/ decryption operation (T_S ≈ 0.0087sec).

• T_H : the time for calculating one-way hash function (T_H ≈ 0.0005sec).

Table 3 recaps the computation cost of the proposed scheme with relevant schemes. It is famous that the computational cost of XOR (⊕) and concatenation (∥) operations treated as imperceptible analyzed to other operations like as symmetric encryption/decryption, multiplication, pairing free, bilinear pairing, etc. There are following observation about computation cost and security information:

• In Fig. 11 shows that the computation cost of the HUP of the protocol is ≈ 0.3538sec which is greater than Mohit et al.’s scheme[39]. The proposed scheme is secured but Mohit et al. and other schemes have security weaknesses.

  Fig. 11

  

  Computation cost in HUP

  Table 3 Computation cost of our protocol with related protocols

• In Fig. 12 shows that the computation cost of the PUP of the protocol is ≈ 0.7031sec which is greater than Mohit et al.’s scheme[39], Chiou et al.’s [17] and less than Chen et al.’s [15] and Yang et al.’s [16]. The proposed protocol is secured but other relative schemes have security weaknesses.

  Fig. 12

  

  Computation cost in PUP

• In Fig. 13 shows that the computation cost of the TP of the protocol is ≈ 0.7026sec which is greater than Mohit et al.’s scheme[39]. The proposed framework is secured but Mohit et al. and other schemes have security weaknesses.

  Fig. 13

  

  Computation cost in TP

• In Fig. 14 shows that the computation cost of the CP of the protocol is ≈ 0.3689sec which is greater than Mohit et al.’s scheme[39] and less than Chiou et al.’s [17]. Therefore, the proposed protocol is secured but Mohit et al.’s and Chiou et al.’s scheme are not secure.

  Fig. 14

  

  Computation cost in CP

• In Fig. 15 shows that the computation cost of the EP of the protocol is ≈ 0.0506sec which is more less than Yang et al.’s scheme[16]. But in this phase, presented protocol is secured and efficient but Yang et al.’s scheme is not secure and efficient.

  Fig. 15

  

  Computation cost in EP

Liu et al.’s [57] is lightweight pseudonym authentication scheme for multi-server architecture in TMIS. This work efficient for authentication and key agreement process in TMIS. In the proposed protocol, we used single cloud server and patient, doctor and healthcare center. So, Liu et al.’s scheme is not applicable in this domain. It is clear from Fig. 16 that the the proposed protocol has less computation cost than the earlier protocols worked in a cloud environment for medical communication of data exchange. The computation cost of the proposed protocol is greater than Mohil et al.’s protocol, but Mohit et al.’s scheme has no emergency phase and have some security weaknesses.

Fig. 16

Total computation cost of our protocol with related protocols in seconds

Conclusion

The evolution of information technology offers conveniences to humanize medical services, maintaining patients with effectual treatment with enlarged convenience and security. In this paper, we have reviewed Mohit et al.’s mutual authentication scheme described for a TMIS using cloud computing environment. On cryptanalysis, we found that the protocol is susceptible to stolen-verifier attack, many logged-in patient attack, patient anonymity, impersonation attack and fails to protect session key. Then, we proposed an improved, secure and efficient mutual authentication scheme in the same environment. Further, we proved that the proposed protocol provides better security than other previous protocols by the security analysis. The proposed protocol is also profitable in terms of performance like as computation overheads.