1 Introduction

Storing the health records manually and retaining them for future references becomes challenging to manage with large data volumes. The most peculiar example is the number of patients surpassing the capacity of the hospitals due to the coronavirus pandemic. In countries like the USA, Brazil, and India, the healthcare system has been reeling under pressure as its capacities were falling short of taking in more patients. The load on the healthcare infrastructure is unimaginable due to the current global crises of this current pandemic.

The problem with the traditional method of storing all data manually or on paper is that it’s tough to find a patient’s data from the record room where a large number of health records are being kept. It takes a lot of time and energy to find the specific medical record of a patient. It is also possible that data can get lost and eradicated in any natural or human-made disaster. Data can be stolen easily because it is in the form of plain text so anyone can read and write the data in records or modify it as it is easily accessible [1]. Keeping the health records in digital format is enabled by the technology powered by the Internet of Things (IoT) [2, 3]. Security in E-healthcare is even more important because it concerns the sensitive health data of the patient. The attackers can exploit the vulnerabilities of the open wireless channels to conduct attacks [4,5,6,7,8,9,10]. These attacks can cause various types of damage to the E-healthcare framework.

Let us consider a scenario where a patient has received treatment from a hospital in a different city from his hometown, after which he/she gets discharged and goes home. Later, he suddenly falls ill and is admitted to a nearby hospital, but he does not have the full details or the file of his treatment from the previous hospital. Lack of information can cause a delay in his treatment, which can be fatal. But if the patient already has/her his data on devices accessible via the cloud, retrieval of patient’s data would be done in seconds, thus enabling the new hospital staff to begin the treatment as soon as possible [11,12,13,14,15]. The health care department can store data on the cloud in encrypted form with high secure algorithms used in cryptography that allow only the legitimate user to access any remote location provided it has internet connectivity, wired or wireless. The “cloud” has servers on which many software and databases are run, and they are accessed over the Internet. Cloud servers are located in every part of the world. With the help of cloud computing, stakeholders, insurance companies, and healthcare departments don’t have to manage physical servers by themselves or run any software applications on their machines [16]. Cloud computing offers advantages like sharing enormous amounts of data, and patients’ medical records in a timely and safe manner [17,18,19,20,21,22,23]. Digital solutions in hospitals recommend healthcare providers manage their infrastructure well and provide them ample opportunity to familiarize themselves with IT, service providers [24, 25]. Other benefits of Cloud and mobile computing include scalability, cost-effectiveness, agility enhancement, and collaborative sharing of resources [26,27,28].

E-healthcare can be made flexible in hospitals not having the full provisions for implementing cloud-based services. Some of the hospital’s data can be stored using the traditional medium of paper to store the general data, and the cloud can be used to store more important data. The access to the legitimate users is provided irrespective of the location, and the exchange of data is secure [29,30,31]. Only specific stakeholders can read the data, delete the data, and modify the data according to the need or future use [29, 32, 33]. The health data of patients must be protected end to end, and it’s also a big challenge to ensure patients’ privacy while also retaining data quality [1]. 90 percent of healthcare institutions in Australia and many other countries have already adopted E-healthcare to facilitate effective health care services. Digitally, the medical records are stored in the form of Electronic medical record (EMR), Electronic Health Data (EHD), and Personal Health Record (PHR) [34]. EHR and EMR health records are maintained by health care professionals, whereas PHR is handled by the patients themselves or by their relatives. The communication exchange between doctors and patients or between cloud and systems usually occurs through a wireless medium, which is highly prone to attacks like denial of service (DoS), man in the middle attack (MITM), and eavesdropping, and so forth. Although the health care department asserts that it is the staff’s responsibility to maintain the patient’s data confidentiality, the technology used in e-healthcare should also protect the data.

The stakeholders in the dynamic and complex IoT environment of the healthcare system are the patient, nurse, doctor, pharmacist, lab technicians, etc. To successfully run the healthcare system, a specific set of regulations are necessary. There are several organizations in the world like Health Information Technology for Economic and Clinical Health (HITECH) and Health Insurance Portability and Accountability Act (HIPAA) that provide the regulations related to healthcare [35,36,37].

In 1996, HIPAA [37] was established to regulate the US healthcare industry. The HIPAA’s primary focus is to ensure the patients’ security and privacy and protect the full information of the hospital and its different services. HIPAA ensures that only authorized users can access the hospital data from any part of the world.

This paper proposes a scheme in which only legitimate staff can access the patient’s data. The doctor has access to reading and writing the data, and others can only read the data but cannot modify it. The proposed scheme explains how an admin generates the subkeys from the master key to ensure end-to-end security of critical information. We have also addressed the requirements of key security for a secure healthcare system such as integrity, confidentiality, and protection from known key attacks, etc. [5, 38,39,40,41,42,43].

1.1 Motivation

Internet of Things offers a variety of features that support the real-time applications of the e-healthcare. The IoT and WSN networks are prone to diverse attacks because they share the information through insecure public channels. Moreover, cloud access, if not protected, could disclose potential confidential information to adversaries. It becomes more dangerous for medical applications as it can endanger the lives of the patients. The adversary can misuse the information to exploit the reputation of the hospital as well. The frequency of cyberattack incidents reported in the HIPAA journal points out the adversaries’ interest in the information stored in the cloud. As per the report, 32,205 users information were breached through 8 separate incidents of unauthorized access reported in August 2020 [44]. The few healthcare institutions whose users are victimized are the University of Florida Health, Northwestern Memorial Healthcare, Hamilton Health Center, Inc. A possible solution to protect against these cyber attacks in the future is the use of robust access control protocols. However, designing such protocols is challenging due to the resource-constrained user devices and vulnerable wireless channels. Therefore, lightweight security protocols with extreme robustness to protect sensitive networks should be developed.

1.2 Our contribution

  1. 1.

    We propose a robust and lightweight, secure access scheme for cloud-based e-healthcare services.

  2. 2.

    The proposed security protocol verifies the user’s identity (doctor, patient, nurse, etc.) and permits only legitimate users to access cloud services.

  3. 3.

    The proposed protocol attains data confidentiality, message freshness, etc., as security measures while preventing the networks from various threats like man in the middle (MITM) attack, message modification attack, replay attack, etc.

The remaining paper is structured as follows: Section 2 discusses the literature review whereas Section 3 presents the system model. Section 4 describes the proposed scheme. Section 5 provides the security and comparative analysis followed by conclusions in Section 6.

2 Literature review

Olutayo Boyinbode et al. [45] suggests a new web-based technology that enables nurse, doctor, and pharmacist to access the patients’ medical records. It uses the local cloud to store the information of the patient. The data is accessible remotely, and it can also be updated. It is ideal for healthcare units where patients’ data records need to be shared with other doctors for collaborative treatments. But the drawback of this scheme is that it does not allow the patient to access the health records.

Another group of researchers at the Eindhoven University of Technology have proposed a secure E-healthcare scheme, “My PHR Machine” [46]. It is a mixture of cloud and PHR systems. The hospital crew and himself can access, share, and analyze the PHR data through HR software. Another advantage of this scheme is that the data of different users can be accessed with more flexibility at the same time and with proper security measures. The information accessed through My PHR machine is also accessible via the cloud. This scheme does not enable faster access to health records.

The authors in [47] have suggested a cloud-based healthcare framework for successful communication between caregivers and healthcare providers that can completely replace the manual record system in hospitals. The healthcare providers, as well as the patient, can access the records using the above system without any restriction of time or place. The framework incorporates a collaborative service so that only the legitimate healthcare provider or the patient himself can access the data through the Authentication Management service. Patients are not allowed to modify the data, whereas the healthcare staff can write, read, or modify. The patient’s health record is divided into two parts, one of which is stored in the concerned health care department’s system in local databases, and the other is stored in a cloud server database. This system’s main problem is that if a hospital or a healthcare unit does not have its local EHR system, the whole data is stored on the cloud server.

Masud and Hossain [48] introduces a new methodology of storing medical records electronically in the cloud storage system. The suggested method takes care of data privacy using Shamir’s Secret Sharing Mechanism. The EHR is categorized into multiple segments by the healthcare center. The segments are distributed equally to the cloud servers. Whenever any legitimate user wants to access the EHR, the healthcare center captures all segments from partial cloud servers to reconstruct the EHR. This method increases the efficiency of the EHR by outsourcing every patient’s data, which can be reconstructed using cloud computing. The authors claim that they have introduced the novel concept of separation and reconstruction of EHR. The method’s experiential and theoretical analysis suggests that it is a highly efficient and secure method of handling medical records electronically. The framework is not suitable to protect from intruders and unauthorized access of resources.

Shekha chenthara, [34] and a few other experts have surveyed, investigated, and reviewed various articles and identified multiple concerns in protecting E-healthcare. Some of them are EHR privacy, EHR security, and EHR cloud architecture. Authors also indicate that there is still a broad scope of research in EHR security.

Another approach in [49] discusses a data sharing and profile matching scheme for Mobile Healthcare Social Networks (MHSN) in cloud computing for EHR. The scheme allows the encryption of health records using an identity based encryption scheme. Not only this, attribute-based conditional data re-encryption can also be performed under this scheme. The scheme is claimed to be preventive against eavesdropping on sensitive data. A profile matching mechanism in MHSN based on identity-based encryption and an equality test helps achieve a very flexible and robust authorization. A trust negotiation based framework is proposed to provide authentication, sensitivity, and other access control services in healthcare systems [50,51,52]. Mutual disclosure of attributes to perform sensitive transactions is done using digital credentials. However, the technique is not able to protect E-healthcare system from all the prominent threats.

The authors in [53] emphasized the security aspects of the E-Healthcare systems especially access control mechanisms. The authors have declared that their scheme outperforms the traditional access control systems. The proposed access control model is based on the trust degree of the communicating parties. The degree of trust is evaluated based on user behavior. The user request is only granted when the degree of trust from both parties (from the user and service) is greater than or equal to the mutual trust threshold value. The author explains that the model ensures that only legitimate and trustful users can access medical records.

Table 1 provides a comprehensive comparison of various E-Healthcare security protocols. Table 1 elaborates the various vulnerabilities that could easily be exploited by attackers to conduct cyber-attacks on different medical devices. Additionally, the level of difficulty required to conduct a successful cyber-attack, the impact of cyber-attacks on medical devices, and the cyber awareness of stakeholders are also included in Table 1. Conclusively, it can be stated that most of the techniques discussed in the literature review section do not offer complete security in terms of identity anonymity, authenticity, confidentiality, and integrity of communications. Absentia of these security properties makes the traditional schemes inappropriate for the sensitive applications of e-healthcare. The inadequacies in the framework of existing schemes allow the adversaries to intrude and access unauthorized resources. Besides, the conventional schemes incur high computation and communication costs that result in precious resource deprivation of tiny smart nodes. Therefore, E-Healthcare applications need a robust authenticated key agreement scheme to protect the network from unauthorized abuses.

Table 1 Comparison related work
Full size table

3 System model and adversary model

3.1 System model

The system model describes the relationship between admin, gateway (GW), doctor, patient, and nurse. Figure 1 illustrates the process of accessing the medical records from the cloud by stakeholders via Gateway.

Fig. 1
figure 1

Secure cloud based E-Healthcare system

Full size image

3.1.1 Admin

Admin is an IT in charge of the hospital who successfully registers the hospital with the cloud. The admin communicates securely with the cloud through the gateway by using a public key of the cloud. The cloud computes the master key of the hospital upon registration and returns this master key to the admin. Afterward, the admin creates various subkeys from the master key through KDF. Admin also performs the offline registration of the patient, doctor, and nurse’s devices and issues the subkeys to them.

3.1.2 Doctor

A doctor is a person who takes care of the patients assigned to him for treatment. Ideally, only the associated doctor should access the information of the patient. This is achieved by matching the patient id (stored in the cloud) with the patient id requested by the doctor, and if the association exists, the request is permitted else denied. According to his treatment, the doctor has the right to both read and write/modify the patient’s medical record. The doctor enters all the patient information and stores it in the cloud using encryption, hash, and subkey. Only the legitimate staff can access the information for reading. The doctor provides his two unique identity numbers to the admin, UIDG and UIDH to the admin. The admin stores them in the cloud. Cloud returns a unique DID number. A doctor uses the secret subkey provided by the admin to communicate securely with the gateway.

3.1.3 Patient

The patient is the person who is admitted to the hospital for his diagnosis or checkup. According to his diagnosis, a particular doctor and nurse are assigned to take care of him in the hospital. The patient also provides the two unique identity numbers issued by the govt. (UIDG) and the hospital (UIDG), respectively to the admin. Admin receives both the ids and stores the same on the cloud. The cloud returns the unique patient id (PID) to the admin. A patient uses the secret subkey provided by the admin to communicate with the gateway securely. It is assumed that devices used by the stakeholders are resource constrained.

3.1.4 Nurse

A nurse is the caretaker of the patient after the doctor leaves. She uses her subkey SK to securely get the information from the cloud via a gateway. In offline registration, the nurse provides her unique identity number issued by govt. (UIDG) and the hospital (UIDH). In return, the nurse gets the secret subkey SK, issued by admin and NID issued by cloud. A nurse can only access the data of patients assigned to her by the healthcare department. A nurse can only read the data and can not change the data because she does not have access to modify or write the information in the patient’s EHR. The nurse also uses her secret subkey provided by the admin to communicate with the gateway securely, and it is assumed that the user’s devices are resource constrained.

3.1.5 Gateway

Gateway provides the interface to the doctor, patient, nurse, and admin to get connected to the cloud. The present system model is constructed considering the hospital’s applications, where the Gateway is not resource-constrained. The Gateway receives full security credentials of doctor, patient, and nurse from the admin and provides a secure interface to access the records from the cloud. During the offline registration, the Gateway receives the master key MK, subkeys SK, and HID from the admin. Gateway secures the communication with different users like a doctor, nurse, and patient using various subkeys, whereas it uses the master key (MK) for ciphering the communication between Gateway and cloud.

3.2 Adversary model

The adversarial nodes are deployed to hinder the routine operations of the network and its services. The authors have considered the Dolev-Yao (DY) adversary model to evaluate the proposed protocol’s strength against malicious activities. As per the DY model, the adversary can eavesdrop on the messages exchanged between the user, gateway, and cloud. The attacker can capture the authentication messages while in transit from the user to the cloud and replay those messages to get unauthorized access to cloud services. The captured messages can also lead to the disclosure of secret credentials that the adversary may use later by the adversary to perform impersonation, known key, and man-in-the-middle attacks. Besides, the adversary can flood the cloud with redundant requests to launch a DoS attack. Therefore, it can be summarized that adversary has the power to disrupt the functioning of the network either temporarily or permanently.

4 Proposed secure access scheme

In the hospital environment, the staff’s work life is very complicated as they have to do multi-tasking when it comes to handling and storing the patient’s records, and it is a big challenge for every hospital. To solve their problem, we have proposed the scheme in which the medical records are stored in the cloud, which helps the hospital staff get relief from doing everything manually. Note that to run the proposed protocol, we have considered the following assumptions:

  • The user device is a resource-constrained entity having limited storage and computation capabilities, whereas gateway and cloud are trusted entities with extensive computation and storage resources.

  • All the entities (user device, gateway, and cloud) can execute the identical cryptography functions.

  • The user can access the data only after the authentication at a cloud.

The cryptography function used to derive one or more secret keys from the master key is the Key Derivation Function (KDF). KDF can be used for stretching keys into longer key or to obtain the keys of the required format. KDF is an example of a pseudo-random function used for key derivation. KDF is used as DK = KDF (key, salt, iteration), DK is the derived key, KDF is the key derivation function, key is the original key, salt is the random number that acts as cryptographic salt, and iteration is the number of iterations of sub-function.

The proposed protocol has been implemented in four steps: a) Hospital registration phase, b) Offline registration phase, c) Information retrieval phase, and d) Information storage phase.

4.1 Hospital registration

Table 2 lists out the notations used throughout the paper. Figure 2 illustrates the hospital registration process with the cloud by the admin through the gateway. Admin generates the nonce (N1) and concatenates the values RRN || PRN || HID || N1 to form α. The message α is encrypted using PUC to form β and the generated message (M1) is sent to the gateway. Gateway receives the message β and generates the nonce N2 which is encrypted using PUC to generate γ. The encrypted message is concatenated with β to form δ and the generated message M2 is sent to the cloud.

Table 2 Notations and descriptions
Full size table
Fig. 2
figure 2

Hospital registration at cloud

Full size image

The received message is decrypted with PRC to compute 𝜖 followed by generation of nonce N2. The cloud verifies the freshness of the nonce N2. If N2 is fresh, then the operation is continued else aborted. The cloud decrypts the message β with PRC to compute F. Cloud also verifies the freshness of nonce N1, if fresh then operation is carried on else canceled. The cloud verifies RRN || PRN || HID, if not found true then the process is aborted. The cloud now generates the master key MK and nonces N3, N4. All values are concatenated HID || MK || N3 to compute G. Cloud also computes KTA at this point by concatenating and hashing, H(RRN || PRN || HID || N1).

The computed value G is encrypted with a key, KTA. Using the hash function, KTG is obtained (= H(N2). The obtained key, KTG, is used to encrypt the nonce N4 to form L. The message L is concatenated with K and stored in M.

The message M is sent to the gateway. The gateway computes the KTG by taking the hash of N2. The message L is decrypted using KTG to form R. The freshness of N4 is checked if found true then the process recommences else it is stopped. Gateway sends the value K as the message M4 to the admin. Admin computes the hash value of {RRN || PRN || HID || N1} to generate KTA. The received message K is decrypted with KTA to generate Y. The freshness of nonce N3 is checked at this stage, if found fresh, then the operation is returned to where it was left off. Finally, the admin is able to retrieve the master key (MK) successfully. This master key is a secret key to securing the communications between the gateway and the cloud.

4.2 Offline registration

Figure 3 illustrates the offline registration process of devices. The admin records stakeholders’ unique identity details, i.e., UIDG, UIDH. Gateway provides MAC address and the serial number SN to admin as identity information. After recording the information, the admin stores the information in the cloud, and the cloud, in turn, generates the MK and unique ids’ for the doctor (DID), patient (PID) and nurse (NID) and provides it to admin. The admin makes use of KDF to derive multiple sub-keys (SK) from securing communication between the gateway and other entities. The admin provides the identity details and unique secret sub-keys to users (doctor, patient, etc) whereas the gateway receives the MK, SK, DID, PID, NID, and HID. In the offline registration phase, the unique identifiers help the admin ensure that the patient’s records’ privacy is maintained. The admin gives the patient access to only those doctors and nurses who are treating that particular patient.

Fig. 3
figure 3

Offline Registration of devices

Full size image

The proposed scheme enables the admin to choose stakeholders’ access rights to the information stored in the cloud. Table 3 provides the default settings used by the administrator, where doctors treating the patient has been given rights to access and store the information. In contrast, other stakeholders have been given the right to access the information only.

Table 3 Distribution of access rights
Full size table

4.3 Information retrieval phase

In Fig. 4, the user (doctor) approaches the gateway to show interest in communication with the cloud. The device of the user (doctor) generates the nonce N1 which is concatenated with DID and PID to compute ζ. The resulting message ζ is encrypted (SK, ζ) to compute η. Using the hash function, H(DID) is computed and stored in O. η is concatenated with the message O to generate A. The user sends the value A as message S1 to the gateway. DID is extracted from the database by the gateway, and its hash value is calculated and stored in B. The gateway compares B with O (B == O) to choose the appropriate subkey for decryption. Using the subkey SK, η is decrypted to form 𝜃. The gateway checks the freshness of nonce N1, if it is fresh then operation is resumed else aborted. Gateway generates the nonce N2 and concatenates it with all other values HID || DID || PID || N2 and form μ. Then μ is encrypted with MK to form λ. Now gateway sends message S2 to cloud. After receiving the message cloud decrypts λ using MK to give κ. If N2 is fresh, then the operation is continued else aborted. The values HID, PID, DID are verified, if found not true then process is aborted. It is verified if PID belongs to DID or not, if it does then the operation is proceeded with further. Upon successful verification, nonce (N3) and requested data (RD) is generated which is concatenated with other values HID || PID || DID || RD || N3 to form ξ. The computed ξ is encrypted with MK to generate π. Cloud sends message S3 to the gateway. Gateway upon receiving the message, decrypts it D(MK, π) to form ρ. Nonce N3 is checked, if found fresh then operation is kept on else halted. Now gateway verifies HID and generates the nonce N4. Next, σ is computed by concatenating all values DID || PID || RD || N4 and then σ is encrypted with SK to form τ. Thereafter, gateway sends the message S4 to user (doctor). After receiving the message, the user decrypts τ using SK and computes υ. If nonce N4 is fresh, only then operation is pursued further. Upon verification of the freshness, the user (doctor) is able to successfully retrieve the requested data, RD.

Fig. 4
figure 4

Information retrieval phase

Full size image

4.4 Information storage phase

In Fig. 5, the user device (doctor) generates the Nonce N1 and concatenates the all other values DID || PID || DA || N1 to generate ϕ. The value ϕ is encrypted with SK to give χ. Using the hash function, H(DID) is computed and stored in Q. Now user concatenates the values χ || Q to form W. Next, the user sends the message K1 to the gateway. DID is extracted from the database by the gateway and its hash value is calculated to form Z. Gateway compares, Z == Q for choosing the appropriate subkey for decryption. Next, gateway compute Ψ by decrypting the χ with SK. Now gateway checks the freshness of the nonce N1, if fresh then operation stays on else it is abandoned. Gateway generates the nonce N2 which is concatenated with other values as HID || PID || DID || DA || N2 to generate ω. Next, ω gets encrypted using MK and result is stored in \(\sum \). Now gateway sends the message K2 to cloud. Cloud decrypts the message \(\sum \) using MK to prepare Ω. Cloud evalutes the freshness of nonce N2, if found fresh then operation is kept going else stopped right there. Cloud verifies the values HID, PID, DID, if not found true, then operation is aborted. Cloud checks if PID belongs to DID (PID ∈ DID), if result is false then operation is aborted. Cloud generates nonce N3 and acknowledgment A, then concatenates with other values HID || DID || PID || A|| N3 to form ∀. Further cloud encrypts the ∀ with MK to compute ∃. Now cloud sends the message K3 to the gateway and gateway decrypts the message to form ⊄ = D(MK, ∃). Gateway checks the freshness of nonce N3, if found fresh then operation is taken up again else process is aborted. Gateway verifies the value HID and generates the nonce N4. Next, Gateway concatenates the values DID, PID, A, N3 in order to form ∝. After this, the gateway encrypts the message ∝ with SK and form ∉. Then gateway sends the message K4 to user device (doctor). After receiving the message, the user decrypts the message ∅ = D(SK, ∉). Further, the user device examines the freshness of nonce N4, if found fresh, then the operation is carried forward else terminated. In the end, the user can retrieve the acknowledgment (A) successfully.

Fig. 5
figure 5

Information storage phase

Full size image

Similarly, the nurse and the patient can also use the proposed access model to securely access the cloud’s information. We have shown only one instance, that of the doctor in the paper, since the process is identical for other stakeholders as well.

Table 4 demonstrates the computational cost of different entities (device, gateway, and cloud) in all phases: hospital registration, information retrieval, and information storage phase. It can be seen from the Table 4 that resource constrained nodes, i.e., user’s device is only computing few crypto operations in each phase; thus the proposed scheme is suitable for all resource constrained devices and applications.

Table 4 Computational cost of proposed protocol
Full size table

5 Security and comparative analysis

5.1 Formal analysis

We have used the ‘Automated Validation of Internet Security Protocols and Applications (AVISPA)’ tool to evaluate the proposed protocol’s strength operating in a vulnerable environment. AVISPA uses four backends, namely, ‘on-the-fly mode-checker (OFMC)’, ‘constraint-logic based attack searcher (CL-AtSe)’, ‘SAT (Boolean satisfiability problem) based model checker (SATMC),’ and ‘tree automata-based on automatic approximations for the analysis of security protocols (TA4SP) [8]. However, only OFMC and CL-AtSe are considered for the present evaluation; SATMC and TA4SP are excluded because they do not support few cryptography operations used in the algorithm [9]. The simulation requires the conversion of protocol code to the ‘High-Level Protocol Specification Language (HLPSL)’. Afterward, the HLPSL script is transformed into ‘Intermediate Format’ (IF) for understanding by OFMC and CL-AtSe backends [63]. The script consists of agent descriptions, session information, intruder capabilities, security goals, and environment details. The interested readers can refer to [64] for detailed knowledge on AVISPA. The backends of AVISPA produces any of these outcomes: ‘safe’, ‘unsafe’, and ‘inconclusive’. Figure 6 demonstrates the robustness of the proposed protocol against various vulnerabilities. After many reiterations, it is concluded by AVISPA that the proposed protocol is safe to use for e-healthcare applications.

Fig. 6
figure 6

Robustness evaluation of proposed protocol using OFMC and CL-AtSe backend of AVISPA

Full size image

5.2 Informal analysis

The informal security analysis of our proposed scheme has been discussed in this sub-section.

Theorem 1

Resistant to replay attacks.

Proof Proof of Theorem 1

Freshness in each session is guaranteed as the messages (MN, SN, KN) are composed of nonce N1, N2, N3, N4. Every entity verifies the freshness of the message by examining the nonce present in the message. For example, when gateway sends the encrypted message δ = E(β || γ) to cloud, it decrypts the message γ with PRC to form 𝜖. Further cloud verifies the freshness of nonce N2, if found true, then operation goes on else it is closed. Assume that an attacker eavesdropped the message, δ = E(β || γ) and it replays the same later to the cloud for getting unauthorized access. Since it contains the old nonce (N2), the cloud discards the request and terminate the session. Furthermore, adversary cannot read and alter the nonce’s (N1, N2, N3, N4) as messages M1 and M2 are ciphered with the public key of cloud whereas M3 is encrypted with temporary key of gateway KTG. Hence any alteration requires either the private key of the cloud or the secret temporary key of gateway unknown to the attacker. Similarly, other messages are protected. Thus, the proposed scheme is secured against replay attacks.□

Theorem 2

Resistant to man in the middle (MITM) attack.

Proof Proof of Theorem 2

In a MITM attack, the adversary modifies the captured messages in such a way that the destination cannot differentiate the modified message from the original message. Assume an attacker performs MITM between the gateway and the cloud by capturing and modifying the message δ = E(β || γ). These computations are hard for the attacker due to the non-availability of the master key (MK) required for deciphering the captured message. Therefore, the attacker fails to attempt a MITM attack between the gateway and the cloud. Similarly, other messages MN, KN, SN, are also encrypted and hence cannot be modified. Therefore, the proposed scheme is protected from MITM attacks. □

Theorem 3

Secure against modification attack.

Proof Proof of Theorem 3

Integrity is preserved due to the use of one way hash function (i.e., SHA). For example, the element O = hash (DID) guarantees prevention against modification attacks. Any form of alterations in O can be easily identified during reconstruction and hash comparison at other entities. Apart from one way hash functions, the messages exchanged are encrypted to ensure the integrity of the communication. Let us assume that the attacker captures the message δ = E(β || γ), and tries to modify δ = E(β || γ)*. However, it is computationally difficult for the attacker to make any changes as the information is encrypted with the secret key. Neither the key nor the security credentials are ever shared in plain text over the unsecured medium. Therefore, the attacker does not find a way to modify the content. Similarly, other messages MN, SN, KN are ciphered to prevent modifications. Thus, the proposed scheme is secure against modification attacks. □

Theorem 4

Proposed scheme exhibits data confidentiality.

Proof Proof of Theorem 4

Revealing information to unreliable entities can pose serious threats to the existence of any network. Let us assume that an attacker eavesdrops a message, γ = E(PUC, N2). Despite successful eavesdropping, the attacker would not be able to interpret the information due to the non-availability of the private key of Cloud, D(\(PR_{C}^{?}\), N2). The Cloud has never shared its private key (PRC) with anyone; therefore, the attacker remains unsuccessful in obtaining the information from the captured message. Similarly, the messages MN, SN, KN are also encrypted. Therefore, the confidentiality of the information is ensured at all levels of communication. The attacker does not have these keys, PUC, SK, MK. Thus the proposed scheme exhibits the security property of data confidentiality. □

Theorem 5

Proposed scheme exhibits Authorization of legitimate stakeholders.

Proof Proof of Theorem 5

The proposed cloud based e-healthcare system assigns a unique identity (DID, PID, etc.) to each stakeholder to classify the access level and the privileges assigned to each authorized entity. The proposed scheme allows only the authorized entities to communicate with the cloud. The admin during offline registration collects the identity details (UIDG, UIDH) of the legitimate users and stores it in the cloud. Cloud generates a unique identifier for every user (DID, PID, etc.) and shares it with the admin. Admin provides the unique identifier to each user during offline registration and the secret subkey (SK). During the communication, a user has to append its hashed identity (e.g., H(DID) along with the message. The hashed identity is verified at the gateway (GW) to prevent the flow of unauthorized abuses. Moreover, the communication is encrypted using the admin’s secret subkey and shared securely during offline registration. Therefore, permitting the authorized entities to communicate with the gateway. The scheme offers two-step authenticity verification, i.e., gateway and cloud. Cloud upon reception of messages also verifies the details (HID, DID, PID, etc.). If the details do not match with the database, the request is aborted. Therefore, the proposed scheme only allows the authorized entities to read and write data in the cloud. □

5.3 Comparative analysis

The Table 5 depicts a clear comparison of old and the proposed protocols’ security properties. It can be observed from the last row in the Table 5 that the proposed scheme attains all the significant security properties (e.g., confidentiality, integrity, authorization, authentication and anonymity). In contrast, none of the traditional approaches is able to attain all of them, as is evident from all the rows of the table except the last one. Non-achievement of all essential security properties by not even a single traditional scheme points out the possible vulnerabilities and increased possibility of attacks. Therefore, based on the investigation, the proposed scheme is found more superior in contrast to the conventional schemes.

Table 5 Comparison of protocols based on security properties
Full size table

6 Conclusions

Cloud based e-healthcare services are becoming increasingly popular due to the easy availability and mobility of the patient’s medical records. Practices like telemedicine have become a reality due to the cost-effective solutions provided by cloud service vendors. Despite the benefits, the framework of storing and accessing the information through the cloud is highly vulnerable due to the use of open wireless channels. The proposed scheme provides a secure interface of access that only permits the legitimate entities (doctors, nurses, etc.) to store and access the patient’s information. The scheme provides end-to-end encryption using multiple keys derived through KDF to preserve patient’s sensitive information privacy. The hospital’s burden of patient record keeping is eased, and the health records’ access and storage are enhanced. Investigation reveals that the proposed scheme is lightweight and exhibits the must have security properties like confidentiality, integrity, authentication, freshness, etc. Security analysis revealed the scheme’s robustness against various prominent attacks like message modification, MITMA, and replay, etc. The potential of the scheme for cloud based solutions is evident. However, the proposed scheme is not cost-effective for Low Power Wide Area Networks (LPWAN) using a local database. This is the future scope to enhance the scheme a cost-effective solution for LPWAN.