Introduction

In medical-system environment, the cloud users store medical records in the cloud database to retrieve the medical information safely. As it is known that cloud server is not fully trusted, hence a secure and authentication protocol is needed to resist common security attacks [28]. In recent years there are some authentication protocols [1–3, 6, 12, 38] proposed for TMIS, where the patients get their treatment online. As mentioned in [7] Telecare medical information system (TMIS) facilitates medical practitioners and patients to establish a communication over public network to provide health care services directly in the patient’s home. As an explanation of TMIS, it is observed that both patients and doctors can work together via TMIS server, i.e. a patient upload diagnosis symptoms to the server and a doctor collects them and submits diagnosis report to the server as if they are interacting directly and this is happened through TMIS. Moreover, how to get medical resources more conveniently and securely are the major concerning issues as the communication is performed over the public channel. In addition, the security requirements, data confidentiality, data/patient authentication and patient anonymity are the important features to be maintained during the communication. In order to maintain patient anonymity [13, 19, 35], the true identity of the patient need to be hidden from the others including eavesdropper. The patients’ diagnosis reports in TMIS are very important and they should not be disclosed publicly.

As the information shared between cloud server and patients/doctors are very critical information and thus, data should be stored securely. As medical data come under crucial data and failure of it may cause failure of ones life [44], so it is necessary to develop a secure protocol so that no adversary can try to obtain patients’ medical records and misuse it. Recently, there have been some protocols presented to realize anonymity issue. Most of these existing protocols may not be applicable to provide patient anonymity in healthcare environment.

Motivation and contribution

Recently, Chiou et al. [10] devised an authentication protocol for TMIS that can be used in the cloud environment. It is reviewed and shown that

  • Their protocol doest no support patient anonymity.

  • The protocol does not provide security against mobile device stolen attack.

In order to achieve security against the aforementioned attacks and to provide a complete package, a light-weighted authentication protocol for TMIS is proposed which is suited for the cloud environment. Our protocol has several important features, which are discussed below:

  • Mutual authentication is achieved between healthcare center and cloud server, patients and cloud server, and doctor and cloud server to strength the security of a system and transmitting information.

  • Patient anonymity is supported during the data transmission by securing patient identity.

  • The protocol resists strong security attacks, i.e., provides security against patient anonymity, non-repudiation and confidentiality of data.

  • The protocol is also free from some known security attacks which are discussed in “Security analysis”.

  • We compare our protocol with other existing protocols and found that it achieves minimum computational and communicational overheads.

Related works

Smart card based authentication mechanism is the most common technique which is used to prevent unauthorized access over the insecure networks. There are so many authentication protocols [30, 31, 36] available using smart card [24], where the user chooses a password and carries a smart card with it. The authentication protocol is very useful in various applications, such as ad-hoc network , wireless sensor network , and medical system [4, 5, 14–18, 20, 29, 34]. Wu et al. first presented a password-based user authentication scheme for medical system and web-based hospital-acquired infection surveillance information system (WHISS) [40, 42]. After that, Wu-Lee et al. [41] proposed a new scheme using smartcard and password-based security protocol for TMIS. Then, He et al. [11] pointed out that Wu et al.’s scheme [41] has various security loopholes, such as impersonation attack and insider attack. They also suggested an enhanced protocol. In 2012, Wei et al. [39] recognized that both the existing protocols [11, 41] which are not protected against security attacks and suggested an enhanced scheme to resist the existing attacks. After that, Zhu et al. [45] presented that Wei et al.’s protocol is not secured against off-line password guessing attack and provided an extended authentication scheme suitable for TMIS, which is based on the RSA cryptosystem. However, there are several security weaknesses that have been identified by Khan et al. [23] on the scheme [45]. After that, Khan et al. designed an improved version of Zhu et al.’s [45] scheme. In 2013, Jiang et al. [21] discussed a strong chaotic map-based authentication scheme with anonymity for Telecare Medical Information System. Kumari et al. [25] claimed that their scheme fails to provide impersonation attack, online password guessing attack and stolen-verifier attack. According to the above reasons, the proposed scheme should defend against these weaknesses. However, Mishra et al. [33] discussed that the protocol in [21] does not provides denial-of-service attack.

In 2013, Tan et al. [37] proposed a smartcard based password authentication and key agreement scheme by applying biometric technique and pointed out that the scheme is more standard and secured. However, Yan et al. [43] demonstrated that the protocol [37] fails to resist Denial-of-Service attack. In order to resolve the problem, Yan et al. [43] proposed a improved authentication scheme to overcome the drawbacks of [37]. In 2014, Mishra et al. [32] described that Yan et al. [43] protocol have a number of security loopholes, such as the user privacy problem, inefficient login phase, inefficient password and biometric update phase, password guessing attack and three-factor authentication problem. To resolve the above mentioned problems, they also proposed an improved protocol. Li et al. [27] claimed that the Lee et al.’s [26] chaotic-maps based user authentication scheme has security flaws such as lack of user identity in the authentication phase, service misuse attacks and suggested a more efficient solution for obtaining the medical system.

In 2014 Chen et al. [9] combines the cloud computing with mobile devices to provide medical resources and uses cryptographic technology to protect the patients personal information. However, the protocol has several weaknesses. Chen et al. [8] also discussed another protocol for medical system based on cloud computing, but the protocol does not support patient anonymity and message authentication. In order to solve the problem of [8], Chiou et al. [10] modified the existing scheme and claimed that the protocol provides real tele-medicine service, patient anonymity, and message authentication.

Road map of the paper

“Introduction” gives the introduction of TMIS, followed by study of Chiou et al.’s protocol in “Review of Chiou et al.’s scheme [10]”. After that, cryptanalysis of Chiou et al.’s is presented in “Cryptanalysis of Chiou et al.’s scheme”. “Proposed protocol” discusses the proposed protocol for medical system over cloud server, followed by its security analysis in “Security analysis”. Performance evaluation is given in “Performance analysis”. Finally, the conclusion of this paper is given in “Conclusion”.

Review of Chiou et al.’s scheme [10]

Chiou et al. [10] proposed an improved version of cloud-based privacy, authentication scheme for medical treatment. There are five entities, e.g. Patient, Doctor, Cloud, Healthcare Center and Body Sensor. The Chiou’s scheme consists of four different phases, e.g. (1) Healthcare center upload phase, (2) Patient data upload phase, (3) Treatment phase and (4) Checkup phase. All the notations are represented in Table 1.

Table 1 Symbols used
Full size table

Healthcare center upload phase (HUP)

In this phase, the patient goes to the healthcare center for the treatment and the healthcare generates medical report as \(m_{H} = (ID_{P}, Data_{H}, {T_{H}^{1}})\). In addition, a pseudo-random identity (N I D P ) is allotted to patients and performs mutual authentication to send the medical report to the cloud server. The operations used in this phase are as follows.

  • Step 1. The healthcare uses the private key to sign the report \(Sig_{H} = S_{SK_{H}} (m_{H})\); and encrypts m H as \(C_{1} =E_{key_{1}} (m_{H})\), where \(key_{1} =h(e(PK_{P},\) S K H ),N I D P ). Then, the healthcare randomly chooses a session key k e y H C ∈ G k e y to compute \(s_{1}=h(e(PK_{C},SK_{H}),{T_{H}^{1}}) \oplus key_{HC}\); s 2 = h(k e y H C ). Further, healthcare computes \(C_{2} =E_{key_{HC}} (ID_{P}, NID_{P}, C_{1}, Sig_{H})\) and sends \(<ID_{H}, s_{1}, s_{2}, C_{2},{T_{H}^{1}}>\) to the cloud.

  • Step 2. On receiving, cloud server verifies \({T_{C}^{1}} - {T_{H}^{1}} \textless \bigtriangleup T\) and computes \(key_{HC}^{\prime } \) = \(h(e(PK_{H},SK_{C}),{T_{H}^{1}})\oplus s_{1}\). Further, the server verifies the equation \(s_{2}? =h(key_{HC}^{\prime })\) and decrypts C 2 using \(key_{HC}^{\prime }\). Finally, cloud server stores I D P , N I D P , C 1, S i g H corresponding to patient and sends s 3 = h(k e y H C + 1) to healthcare.

  • Step 3. After receiving the message s 3 from cloud. The healthcare verifies s 3? = h(k e y H C + 1). If it holds, the healthcare uploads the data otherwise, rejects the session.

Patient data upload phase (PUP)

Body sensor measures patients health information \(m_{B}= (ID_{P}, Data_{B}, {T_{P}^{1}}) \) and gets an appointment sequence number sn. Then, it updates and uploads encrypted m B and m H to cloud server. The details of this phase are described below:

  • Step 1. The patient randomly chooses k e y P C ∈ G k e y as a session key between patient and cloud. Then, patient computes \(s_{4} =h(e(PK_{C}, SK_{P}), {T_{P}^{1}}) \oplus key_{PC}\) ; s 5 = h(k e y P C ) and sends < N I D P , s 4, s 5, T P > to the cloud.

  • Step 2. On receiving these messages, cloud server verifies \({T_{C}^{2}} - {T_{P}^{1}} < \triangle T\) and computes \(key_{PC}^{\prime } =h(e(PK_{P}, SK_{C}), T_{P}^ 1) \oplus s_{4}\). Further, the cloud verifies whether the equation \(s_{5} ?= h(key_{PC}^{\prime })\) is correct or not. If it is correct, obtains the stored data C 1 and signature S i g H of patient using N I D P . Finally, it sends \(s_{6}=h(key_{PC}^{\prime }, C_{1}, Sig_{H})\), C 1 and S i g H to patient.

  • Step 3. On receiving, patient verifies s 6? = h(k e y P C , C P , S i g H ) and computes k e y 1 = h(e(P K H , S K P ),N I D P ) to decrypt \(m_{H} ?=D_{key_{1}} (C_{1})\). After that, patient verifies signature m H ? = \(V_{PK_{H}} (Sig_{H})\) and computes k e y 2 = h(e(P K D , S K P ),s n); \(C_{3} = E_{key_{2}} (m_{H}, m_{B})\) and s 7 = h(k e y P C , I D D , s n,C 3). Finally, the patient sends < I D D , s n,s 7, C 3 > to cloud, and renews \(NID_{P}^{new} =h(NID_{P}||key_{PC})\) with updated \(NID_{P}^{new}\).

  • Step 4. On receiving these messages, cloud verifies whether \(s_{7} ?\,=\,h(key_{PC}^{\prime }, ID_{D}, sn,C_{3})\) holds or not. If it does, cloud computes \(NID_{P}^{new} = h(NID_{P}\) ||k e y P C ) and stores \(<NID_{P}^{new}, ID_{D}, sn>\), replaces C 1 with C 3; otherwise terminates the phase.

Treatment phase (TP)

Doctor obtains patient’s id I D P and sequence number sn form cloud server after establishing mutual authentication. After diagnosing Patient’s symptom, doctor uploads diagnostic records to cloud. The detail is described below.

  • Step 1. Doctor chooses a random number k e y D C ∈ G k e y as a session key between doctor and cloud. Then, Doctor computes messages \(s_{8} =h(e(PK_{C}, SK_{D}),{T_{D}^{1}}) \oplus key_{DC}\), s 9 = h(k e y D C ) and sends < I D D , s 8, s 9, \({T_{D}^{1}}>\) to the cloud.

  • Step 2. On receiving these messages, cloud verifies \({T_{C}^{3}} - {T_{D}^{1}}\textless \triangle T\) and computes \(key_{DC}^{\prime } = h(e(PK_{D}, SK_{C}),{T_{D}^{1}} \oplus s_{8})\). Further, the cloud server verifies the equation \(s_{9}=? h(key_{DC}^{\prime })\) and computes \(s_{10}=h(key_{DC}^{\prime }, sn,C_{3}, Sig_{H})\). Finally, sends < s 10, s n,C 3, S i g H > to the doctor.

  • Step 3. Upon receiving these messages, doctor verifies s 10? = h(k e y D C , s n,C 3, S i g H ) and computes \(key_{2}^{\prime } = h(e(PK_{P}, SK_{D}), sn)\) to decrypt \((m_{H}, m_{B})=D_{key_{2}^{\prime }} (C_{3})\). Further, doctor verifies the signature by checking \(m_{H}?= V_{PK_{H}}(Sig_{H})\) and makes a medical diagnosis based on the medical reports and generates medical record \(m_{D} =(ID_{P},Data_{D},{T_{D}^{2}})\). Finally, the doctor encrypts the report using \(key_{2}^{\prime }\) as \(C_{4} = E_{key_{2}^{\prime }}(m_{H}, m_{B}, m_{D})\) and sends s 11 = h(k e y D C , C 4, S i g D ), s n,C 4, S i g D to cloud.

  • Step 4. On receiving these messages, cloud verifies whether the equation \(s_{11} =? h (key_{DC}^{\prime } ,C_{4}, Sig_{D})\) holds or not. If it does, cloud stores C 4 and S i g D otherwise, terminates the phase.

Check up phase (CP)

The patient can use his mobile phone to download the medical report generated by doctor and arrange the appropriate medical treatment based on the report.

  • Step 1. The patient randomly chooses a number k e y P C ∈ G k e y as the session key between patient and cloud. Then, patient computes the messages \(s_{12} = h(e(PK_{C}, SK_{P}), {T_{P}^{2}} )\) ⊕k e y P C ; s 13 = h(k e y P C ) and sends \(<NID_{P}^{new}, s_{12}, \ s_{13}, \ {T_{P}^{2}}>\) to cloud.

  • Step 2. On receiving these messages, cloud verifies \({T_{C}^{4}} - {T_{P}^{2}}\textless \triangle T\) and computes \(key_{PC}^{\prime } =h(e(PK_{C}, SK_{P}),{T_{P}^{2}} ) \oplus s_{12}\). Further, the cloud verifies equation by checking \(s_{13} =? h(key_{PC}^{\prime })\) holds or not. If it does, cloud sends \(<s_{14}=h(key_{PC}^{\prime }, C_{4}, Sig_{D})\), C 4, S i g D > to patient.

  • Step 3. On receiving these messages, patient verifies s 14? = h(k e y P C , C 4, S i g D ) and obtains \((m_{H}, m_{B}, m_{D})=D_{key_{2}}(C_{4})\) and also verifies the validation of S i g D by checking \(m_{D} ?= V_{PK_{D}} (Sig_{D})\) and takes medical measures according to the diagnosis report, using the pre-generated key k e y P to encrypt m H , m B , m D , and obtains \(C_{5} = E_{key_{P}} (m_{H}, m_{B}, m_{D})\). Finally, the patient sends S 15 = h(k e y P C , C 5), C 5 to cloud.

  • Step 4. On receiving these messages, cloud verifies whether \(S_{15} =? h(key_{PC}^{\prime }, C_{5})\) holds or not. If it does, cloud replaces C 4 with C 5 and stores C 5 in the cloud. Depending on the need of patients, the medical staff can get the pre-generated key k e y P from KGC to decrypt C 5.

Cryptanalysis of Chiou et al.’s scheme

Chen et al. [10] point out that their scheme supports user anonymity which is the most important feature for the medical system. However, we demonstrated that their scheme fails to support it. We also found that, Chiou et al.’s protocol fails to support mobile device stolen problem. The detail description is provided below.

Fails to support patients’ anonymity

User anonymity states that adversary \(\mathcal {A}\) should not be able to obtain the identity of user by any means of communication. Chiou et al. claim that identity of patient I D P is protected from the adversary \(\mathcal {A}\). However, we have noted that it is not true. During patient data upload phase, cloud sends \(Sig_{H}= S_{SK_{H}}(m_{H})\) to patient via public channel. As, the communication media is public, the adversary \(\mathcal {A}\) can easily access it. For instance, assume an attacker interrupts in between patient and cloud and obtains the value of S i g H , the attacker can apply the public key of healthcare to obtain the message as m H = P K H (S i g H )\(=V_{PK_{H}}(S_{SK_{H}}(m_{H}))\); where, m H contains \((ID_{P}, Data_{H}, {T_{H}^{1}})\). Hence, patient anonymity breaks. Similarity in the treatment phase, cloud sends \(Sig_{H}= S_{SK_{H}}(m_{H})\) to the doctor via open channel, where an attacker can interrupt and get the original message. Hence, the scheme fails to support patient anonymity as well as message protection.

Fails to support mobile device stolen

As mobile device of patient is an important tool for communication with doctor. The body sensor embedded in patients body provides the updated report of patient to the mobile device. Now, assume the mobile device of the patient is stolen, still the body sensor will send the message \(m_{B}=(ID_{P}, Data_{B}, {T_{P}^{1}})\) to the patient’s mobile phone. As, sensor is sending the message m B directly without any security to the mobile device of patient. Thus, the adversary \(\mathcal {A}\) have direct access to the mobile phone of patient and message m B .

Similarly, there is no security warning is given by patient to differentiate between the original patient and attacker. Hence, the scheme does not support stolen Mobile device attack.

Proposed protocol

Architecture and discussion

There are five entities involve in the communication: 1) Patient: A person, who is requesting for medical treatment, 2) Doctor: A person, who has been trained in medical science and whose job is to treat patients, 3) Cloud: A server to store patient’s medical records, 4) Healthcare Center: Physical place where the patient receives medical treatment, 5) Body Sensor: A device connected with a physical sense of the patient. The architecture is shown in Fig 1 and explanation is given below:

  • Initially the patient goes to the healthcare center for the health inspection/ routine-checkup and performs registration, where hospital maintains the report of patients.

  • The health care uploads the report of a patient to the cloud.

  • Body sensors embedded in the patient’s body collect the health report of the patient and send to patient’s mobile phone (securely).

  • After that, patient uploads new report by integrating the previous report of health care with the generated report by body sensor to the cloud.

  • The cloud sends the report of the patient to the respected doctor in order of sequence number.

  • The doctor performs treatment by looking into the report and uploads the new report with the digital signature to the cloud server.

  • The cloud sends the final report to the patient which contains the treatment of the patient.

Fig. 1
figure 1

Protocol architecture and authentication process with ordering of phases

Full size image

Protocol description

This section proposes a new lighter weighted protocol for medical system which involves cloud server. Our protocol consists of four phases: 1) Healthcare center upload phase, 2) Patient data upload phase, 3) Treatment phase and 4) Check up phase.

Healthcare center upload phase (HUP)

The Patient registers himself in healthcare center, and the healthcare center allots one-time password (OTP) and a dynamic pseudo-random identity NID to patient via mobile device. In this phase, the healthcare center performs mutual authentication with cloud and uploads patient’s inspection report to cloud as shown in Fig. 2 and described below.

  • Step 1. The healthcare center generates inspection report m H = (I D P , D a t a P ), and inputs unique identity of healthcare I D H (either random number or MAC address of system) with a randomly selected number R. Further, the healthcare sends < I D H , R> to cloud server via secure channel.

  • Step 2. On receiving these messages, the cloud server computes A = h(I D H ∥R∥x), S 1 = h(A) and B = I D H ⊕x, where x is a secret key of cloud and sends B,S 1 to healthcare via public channel.

  • Step 3. On receiving these messages, healthcare computes x ′ = B⊕I D H , A ′ = h(I D H ∥x ′∥R) and verifies whether \(S_{1}^{\prime } =? h(A^{\prime })\) holds or not. If it does, the healthcare authenticates the cloud server and computes the session key between healthcare center and cloud as S K H C = h(I D H ∥A ′∥B). After performing mutual authentication, the healthcare encrypts the report as \(C_{H}= E_{key_{1}}(m_{H})\) using k e y 1 = h(I D P ∥O T P) and signs the message \(Sig_{H}= S_{PR_{H}}(MD_{H})\), where M D H = h(m H ) is a message digest. Further, the healthcare encrypts I D P , C H , S i g H , N I D with the session key S K H C to get \(C_{1}= E_{SK_{HC}}(ID_{P}, C_{H},Sig_{H}, NID)\) and S 2 = h(S K H C ||C 1) and finally sends S 2, C 1 to cloud server via insecure channel.

  • Step 4. Upon receiving these messages, cloud computes \(SK_{HC}^{\prime }= h(ID_{H} \parallel A \parallel B)\) and verifies whether equation \(S_{2}^{\prime } ? = h(SK_{HC}^{\prime }||C_{1})\) holds or not. If it does, cloud authenticates the healthcare center and decrypts the messages using the session key \(SK_{HC}^{\prime }\) to obtain \((ID_{P}, C_{H}, Sig_{H}, NID) = D_{SK_{HC}}(C_{1})\) otherwise, it fails and goes to Step 1.

Fig. 2
figure 2

Healthcare center uploading phase (HUP)

Full size image

Patient data upload phase (PUP)

The patient requests the Body sensor, which is embedded in the patient’s body, to collect the updated health information, and provides it to the patient via the mobile device securely. This request is made by patient by inputting his identity I D P and password of mobile phone to the mobile device. The cloud provides an appointment sequence number s n i , inspection report m H to patient as shown in Fig. 3 and discussed below:

  • Step 1. Patient gets health information m B = (I D P , D a t a B ) from body sensor via mobile phone. Then, patient inputs his identity I D P and dynamic pseudo-random identity NID and sends it to cloud via a secure channel.

  • Step 2. On receiving, cloud computes I = s n i ⊕N I D, S 3 = h(N I D∥I∥C H ∥S i g H ) and sends < I 3, S 3, C H , S i g H > to patient via public channel.

  • Step 3. Upon receiving these messages, patient computes \(sn_{i}^{\prime }= I \oplus NID\) and verifies whether \(S_{3}^{\prime }=?h(NID\parallel I \parallel C_{H} \parallel Sig_{H})\) holds or not. If it does, patient authenticates cloud and computes session key between patient and cloud S K P C = h(I D P ∥N I D). After performing authentication, the patient decrypts the ciphertext to obtain \(m_{H}= D_{key_{1}}(C_{H})\) using k e y 1 = h(I D P ∥O T P). Further, the patient computes \(MD_{H}= V_{PU_{H}}(Sig_{H})\) and verifies whether m H ? = h(M D H ) holds or not. If it does, patient computes key between patient and doctor k e y P D = h(I D P ∥I D D ∥s n i ) and uses the key to encrypt \(C_{P}= E_{key_{PD}}(m_{H}, m_{B})\). Finally, patient generates the signature corresponding to message m B , using its private key and computes \(Sig_{P}= S_{PR_{P}}(MD_{P})\) where M D P is message digest, S 4 = h(S K P C ∥C P ∥S i g P ) and sends < S 4, C P , S i g P > to the cloud server via public channel.

  • Step 4. On receiving these messages, cloud computes \(SK_{PC}^{\prime }= h(ID_{P} \parallel NID)\) and verifies whether equation \(S_{4}^{\prime } ?= h(SK_{PC}^{\prime } \parallel C_{P} \parallel Sig_{P})\) holds or not. If it does, cloud stores C P , S i g P ; otherwise, terminates the phase.

Fig. 3
figure 3

Patient uploading phase (PUP)

Full size image

Treatment phase (TP)

Doctor performs treatment of patient by performing mutual authentication between doctor and cloud. If they are valid entities, cloud uses I D D to find all of doctor’s requests by patients, who have made appointments, and sends the patient’s medical treatment data to doctor as shown in Fig. 4 and described below.

  • Step 1. Doctor initializes the communication by sending it’s identity I D D and a random number RD to cloud via secure channel.

  • Step 2. In response, cloud sends the identity I D P of patient and sequence number s n i via a secure channel to the doctor. The cloud computes S 5 = h(R D∥S i g P ∥C P ) and sends < S 5, S i g P , C P > to doctor via public channel.

  • Step 3. On receiving these messages, doctor verifies the validity of message, by checking whether \(S_{5}^{\prime }=? h(RD \parallel Sig_{P} \parallel C_{P})\) holds or not. If it does, doctor authenticates the cloud and computes the session key between doctor and cloud as S K D C = h(I D P ∥R D∥s n i ), otherwise, rejects the message. Further, the doctor computes k e y P D to decrypt the received messages \((m_{H}, m_{B})= D_{key_{PD}}(C_{P})\), and verifies the patient’s signature using public key of patient \(MD_{P} = V_{PU_{P}}(Sig)\) and checks whether M D P ? = h(m B ) holds or not. If it does, doctor makes a medical diagnosis based on the reports m H , m B and generates medical records m D = (I D P , D a t a D ), using k e y P D = h(I D P ∥I D D ∥s n i ) to encrypt messages (m H , m B , m D ) for generating cipher text \(C_{D}= E_{key_{PD}}(m_{H}, m_{B}, m_{D})\). Finally, the doctor signs \(Sig_{D}= S_{PR_{D}}(MD_{D})\) on the message m D with its private key by computing message digest M D D = h(m D ), S 6 = h(S K D C ∥C D ∥S i g D ) and sends < S 6, C D , S i g D > to the cloud via public channel.

  • Step 4. Upon receiving these messages, cloud computes \(SK_{DC}^{\prime }=h(ID_{P} \parallel RD \parallel sn_{i})\) and verifies whether \(S_{6}^{\prime }?= h(SK_{DC}^{\prime } \parallel C_{D} \parallel Sig_{D})\) holds or not. If it does, the cloud stores C D , S i g D otherwise, terminates and goes to Step 1.

Fig. 4
figure 4

Treatment phase (TP)

Full size image

Check up phase (CP)

After performing treatment from a doctor, the patient’s report is stored in the cloud. The Patient performs authentication with the cloud and then it sends the encrypted report to patient as shown in Fig. 5. The detail description of checkup phase is as follows.

  • Step 1. The patient inputs its identity (I D P ), as request and sends it to cloud via secure channel.

  • Step 2. On receiving, cloud computes S 8 = h(I D P ∥C D ∥S i g D ) and sends < S 8, C D , S i g D > to patient via public channel.

  • Step 3. On receiving these messages, patient verifies whether \(S_{8}^{\prime }=? h(ID_{P} \parallel C_{D} \parallel Sig_{D})\) holds or not. If it does, the patient decrypts the ciphertext using k e y P D to get \((m_{H}, m_{B}, m_{D})= D_{key_{PD}}(C_{D})\) and verifies the signature by computing the message digest \(MD_{D}= V_{PU_{D}}(Sig_{D})\) and checks whether M D D ? = h(m D ) holds or not. If it does, patient encrypts the messages \(C_{2}= E_{key_{P}}(m_{H}, m_{B}, m_{D})\), S 9 = h(N I D∥C 2) and sends S 9, C 2 to the cloud server via public channel.

  • Step 4. Upon receiving these messages, cloud verifies whether \(S_{9}^{\prime }?= h(NID \parallel C_{2})\) holds or not. If it does exist, the cloud stores C 2, otherwise terminates and goes to Step 1.

Fig. 5
figure 5

Checkup phase (CP)

Full size image

Security analysis

This section discusses security issues and analyzes them in our protocol. We consider an attacker \(\mathcal {A}\) has the capacity to modify and eavesdrop the communicating message over the public channel. Table 2 illustrates the security comparison of proposed protocol with related existing protocols qualitatively, where ‘Yes’ means the respected feature is present in scheme and ‘No’ means not present.

Table 2 Security analysis
Full size table

Property 1

The proposed protocol provides data Confidentiality.

Proof

Confidentiality is the mechanism to provide protection on transmitting of data from the adversary. Thus, encryption of data is required during transmission. The clear description for the above claim is given below.

  • During HUP phase, the healthcare’ s report m H is encrypted with k e y 1 and obtains \(C_{H}= E_{key_{1}}(m_{H})\) to upload in cloud server.

  • In PUP phase, the patient’s report m B is encrypted with k e y P D and obtains \(C_{P}= E_{key_{PD}}(m_{H}, m_{B})\) to upload in the cloud.

  • In TP phase, the doctor’s report m D is encrypted with k e y P D and obtains \(C_{D}= E_{key_{PD}}(m_{H}, m_{B}, m_{D})\) to upload in the cloud.

  • In CP phase, the k e y P is used to encrypt \(C_{2}= E_{key_{P}}(m_{H}, m_{B}, m_{D})\).

Hence, if the adversary \(\mathcal {A}\) tries to obtain information during communication, he gets encrypted data which can’t be decrypted without the key. Thus, our scheme supports confidentiality. □

Property 2

The proposed protocol provides the Non-repudiation.

Proof

Non-repudiation states as the ability to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated. During HUP phase, the healthcare signs a message \(Sig_{H}= S_{PR_{H}}(MD_{H})\) which is verified by patient m H ? = h(M D H ) by computing \(MD_{H}= V_{PU_{H}}(Sig_{H})\). The signature S i g H ensures that the report is issued from legal healthcare center, and only the patient can perform the verification of S i g H . If the healthcare records have some problems, the healthcare cannot be denied from the fact that the message is sent by healthcare. Hence, non-repudiation is ensured in our protocol. □

Property 3

The proposed protocol provides Message authentication.

Proof

Message authentication [22] is a mechanism used to verify the integrity of the message. Here, we describe message authentication in each phase:

  • During HUP phase, healthcare center receives S 1, B and verifies its validity. Similarly, the cloud receives S 2, C 1 and verifies it using S K H C as S 2? = h(S K H C ||C 1). If an adversary \(\mathcal {A}\) tries to alter any value of the message the cloud server will recognize it.

  • In PUP phase, the patient verifies I,S 3, C H , S i g H as S 3 = ?h(N I D∥I∥C H ∥S i g H ) and the cloud verifies received S 4, C P , S i g P as \(S_{4}^{\prime }= h(SK_{PC}^{\prime } \parallel C_{P} \parallel Sig_{P})\), Hence, message authentication between patient and cloud is verified.

  • In TP phase, doctor verifies received S 5, S i g P , C P using S K D C as S 5? = h(S K D C ∥C P ∥S i g P ) and the cloud verifies the received message S 6, S i g D , C D as \(S_{6}?= h(SK_{DC}^{\prime } \parallel C_{D} \parallel Sig_{D})\) and if any of the verification fails, the messages will not be accepted.

  • In CP phase, the patient verifies S 8, C D , S i g D as S 8? = h(I D P ∥C D ∥S i g D ) and the cloud verifies S 9, C 2 as S 9? = h(N I D∥C 2).

Thus, our scheme protects message authentication in every phase. □

Property 4

The Patient anonymity of the proposed protocol is secure.

Proof

Our scheme can preserve anonymity property by hiding original identity. During HUP phase, I D P is encrypted with S K H C as \(C_{1}= E_{SK_{HC}}(ID_{P}, C_{H}, Sig_{H}, NID)\) and only can be decrypted by cloud having session key \((ID_{P}, C_{H}, Sig_{H}, NID) = D_{SK_{HC}}(C_{1})\) to obtain I D P , C H , S i g H , N I D. The identity of patient I D P cannot be derived without the knowledge of S K H C . Furthermore, S K H C cannot be derived due to one-way hash function. Therefore, our protocol provides patient anonymity. □

Property 5

The Man-in-the-middle attack does not exist in our scheme.

Proof

In our scheme, the patient, healthcare center and doctor use encryption of data before sending message over public channel and verify message before accepting it. If the message is altered during transmission it fails the verification process. Thus, the attacker will not get success in the alteration process. Therefore, our scheme protects the man-in-middle attack. □

Property 6

The proposed protocol provides protection against the known-key security.

Proof

In our scheme, the patient, healthcare center, the doctor and cloud can use random numbers to generate session key. Even if an attacker steals previous session key, he/she cannot generate the session key for the next times. Therefore, our protocol is protected against known-key security. □

Property 7

The proposed protocol protects the stolen mobile device attack.

Proof

Suppose that an adversary steals the mobile device of a legal patient, the adversary \(\mathcal {A}\) cannot obtain any of the secret information of the patient. As the mobile device receives m B = (I D P , D a t a B ), which is accessible only by inputting valid identity of patient (I D P ) and valid password of mobile device, which is only known to the valid patient. Therefore, the attacker is not able to break the system even if he/she gets the mobile device of the registered patients. □

Property 8

The proposed protocol protects the impersonation attack.

Proof

If an adversary \(\mathcal {A}\) interrupts in between communication, the adversary can trap the transmitting messages, which is transferred via the public channel. After getting the transmitted message the adversary \(\mathcal {A}\) can alter the message, and re-transmit the modified. Moreover, the modified message has to pass the verification process performed by the other party, which is impossible in the proposed protocol. The detail is described in terms of healthcare center update phase. However, the concept is same in other phases.

  • An adversary \(\mathcal {A}\) tries to impersonate as a legal cloud, and eavesdrops the transmitted message < S 1, B> and tries to re-compute B using I D H , which is unknown parameter and only known to the authenticated parties. Also the computation of S 1 is not possible, as it involves hashing of A. If the adversary \(\mathcal {A}\) tries to impersonate as healthcare center by using different identity or guessing the I D H . It results in computing the value of A as it involves two other parameters, 1) secret key x of cloud 2) Random number R generated by the healthcare center. Note that, guessing of all the value at the same time is not possible due to preserving high entropy property. If adversary \(\mathcal {A}\) uses incorrect value to compute S 1, B, the verification process will not pass. Hence, computation of S 1 depends on A and the computation of A depend on x. The incorrect value of x leads to incorrect value of S 1. Thus, the adversary cannot impersonate a legal cloud.

  • If the adversary\(\mathcal {A}\) tries to impersonate as a valid healthcare center, he first eavesdrops the transmitted message < S 2, C 1 > from the public channel and re-constructs the new message. The computation of both messages involve the session key between the healthcare center and cloud, which involves hash operation in computation. Thus, the adversary cannot impersonate the healthcare.

From the above points it is clear that the proposed protocol is protected against impersonation attack. □

Property 9

The proposed protocol is secure against the session-key security.

Proof

The session key security is one of the very important parameters which we have considered in order to design our protocol. It is necessary that the session key is only known to the legitimate parties. In this protocol, there are total three session keys which are computed between 1) Healthcare center and Cloud, 2) Patient and Cloud and 3) Doctor and Cloud. All of these session keys are well secured. Here we describe the security in terms of healthcare center update phase. However, the concept is same in other phases.

The session key between Healthcare center- Cloud S K H C = h(I D H ∥A∥B) comprises hashing of I D H , A,B that need to be determined by the attacker \(\mathcal {A}\) for generating an exact session key. Property 8 shows that the adversary \(\mathcal {A}\) can not extract the parameter A, B from the communicating messages between helthcare and cloud. Similarly, the identity of hospital I D H is sent via a secure channel to cloud, attacker can not access the identity I D H . Without knowing the parameters I D H , A, B an adversary \(\mathcal {A}\) cannot compute the session key S K H C . Thus, the session key can only be generated by a legitimate party. □

Performance analysis

In this section, we evaluate the performance of our protocol with the related protocols used in cloud for secure medical data exchange, such as Chen et al. [9], Chiou et al. [10] and Chen-Yang et al. [8] protocols. The comparison is performed in all the phases of protocol like HUP, PUP, TP, CP and EP. Chuang et al. [8] uses the emergency phase (EP) in his scheme.

Table 3 summarizes the computation cost of our protocol with related protocols. It is well known that the computational cost of XOR (⊕) and concatenation (||) operations are considered as negligible compared to other operations such as symmetric encryption, multiplication, bilinear pairing, etc. As it is clear from Table 3 that the proposed protocol has less computation cost than the existing protocols used in cloud for medical exchange of data. Hence, our scheme is light weighted.

Table 3 Computation cost of our protocol with related schemes
Full size table

We have used several crypto-operations in this article based on the information available in Ref. [10] to evaluate computation cost of our protocol as well as existing related research. In Ref. [10], Android phone and Windows 7 OS is used and the system configurations of mobile phone is Android 4.4.4KTU84P with a 1.8 GHz processor and 2GB RAM. The configurations of computer system is Windows 7, Professional with an Intel (R) core (TM) 2 Quad CPU Q8300, @2.50Hz, and 2GB RAM. The execution time in second for the different time complexity notations are as follows:

T S i g ::

the time for computing executing/verifying a signature (T S i g ≈ 0.3317s e c.)

T A ::

the time for computing asymmetric encryption or decryption operation (T A ≈ 0.3057s e c.)

T M ::

the time for computing multiplication (T M ≈ 0.0503s e c.)

T P ::

the time for computing a bilinear pairing operation (T P ≈ 0.0621s e c.)

T S ::

the time for computing symmetric encryption or decryption operation (T S ≈ 0.0087s e c.)

T H ::

the time for computing one-way hash function (T H ≈ 0.0005s e c.)

We summarize the communication cost in Table 4 of our protocol with related protocols. Assume the bit length of identity, timestamp and randomly generated numbers to be 48-bits each, the bilinear pairing and cryptographic hash function as 160 bits, the length of symmetric cryptosystem, asymmetric- algorithm/signature to be 128, 512-bits respectively. The proposed scheme is efficient in terms of communication cost as its communication cost is 5312-bits, which is less than the [8, 10] having costs of 7952, 6528-bits respectively. Although, it is greater than [9] having cost of 2576-bits. But [9] is vulnerable to impersonation attack, user anonymity and stolen mobile device attack, and hence, not suitable for practical implementation in cloud. However, our scheme can resist all the above attacks.

Table 4 Communication cost of our protocol with related protocol
Full size table

Conclusion

We have outlined Chiou et al.’s authentication scheme designed for a TMIS using cloud environment. On cryptanalysis, it is found that the scheme is vulnerable to patient anonymity, mobile device stolen attack. We have then proposed a new user authentication and session key agreement scheme for the same, which fixed the mentioned security weaknesses. In addition, we showed that the proposed scheme provides better security than other existing schemes through the security analysis. Our protocol is also efficient in terms of performance such as computation and computation overheads. We have not considered some security issues of the cloud environment in this work. Hence, it is our future research to solve in future.