A Verifiably Secure and Efficient Authentication Protocol for Resource-Constrained IoT Devices in Cloud-Assisted E-Healthcare

1  Introduction

Communications systems are heterogeneous distributed systems explicitly designed for e-healthcare, logistics, complex tactical tasks, or industrial work. A communication system can respond to changes, assess their impact and operation, and react intelligently to complex tactical tasks [1]. It is typically formulated with multiple sensors, IoT devices, or actuators connected to a centralized server, control station, or cloud server [2]. The specified task is achieved through an interconnected system of components, including sensors, wearables, IoT devices, computing nodes, actuators, and the channels that link the communication system [3]. For instance, in the e-healthcare communication system, a feedback loop that attempts to reach patient diagnoses is created by the interaction of wearables, sensors, and IoT devices by recognizing the physiological vitals of the patient’s body and transmitting it to the server for examination by the physicians through their mobile device [4]. These interconnected smart devices, whether interacting with the patient’s body or with the physician, including IoT devices, sensors, wearables, or mobile devices, along with servers and communication channels, all belong to the communication system domain [5].

The essential factors that a healthcare communication system should consider include how to successfully implement a security protocol for the secure transmission of data to and from these sensors, wearables, or IoT devices, as well as how to manage data efficiently [6]. The successful implementation of a security system is the backbone of a healthcare communication system, providing support to enable the entire system to function effectively [7]. Besides these, data sensitivity, scalability, intelligence capabilities, and interoperability of these components are also essential [8]. Still, implementing a robust security mechanism poses considerable challenges. It can only be achieved by efficiently authenticating all components of a communication system, including its message with the cloud server, and then with the mobile device of a physician. If these components become authenticated, the remaining issues and challenges can be resolved automatically. Therefore, there is a dire need for an authentication mechanism to ensure that all the connected devices in the healthcare communication system securely communicate with each other and with the cloud server. Therefore, many researchers proposed several authentication mechanisms, which are discussed in detail in the literature section of the article. Despite the many benefits of these mechanisms in the form of offering flexibility, mobility, and cost-effectiveness in our daily lives, they still present a series of issues and challenges described as follows:

•   The existing solutions for healthcare communication systems either suffer from side-channel [9], MITM [10], and replay attacks [11], are not feasible for resource-constrained IoT due to modular exponentiation or bilinear pairing, or are completed in four to five round trips [12].

•   Within the next ten years, approximately half a trillion sensors, wearables, or IoT devices are anticipated. This unprecedented growth in IoT devices is creating a significant problem for cloud servers, particularly in terms of managing their access to the healthcare communication system.

•   Additionally, due to the limitations of low-power communication technologies, the lack of synergy, and the integration of hundreds of thousands of sensors, wearables, or IoT devices, latency is a significant issue for security protocols in the existing literature [13].

•   The sensors, wearables, or IoT devices in the healthcare communication system are resource-constrained in nature [14]. Energy consumption is a major issue for them, as frequent battery changes become unsustainable, making the security protocol vulnerable to numerous vulnerabilities like ephemeral secret leakage [15], session key disclosure [16], and traceability attacks [17].

Moreover, as stated in detail, security is a major concern for the healthcare communication system, especially those assisted by cloud computing and driven by IoT devices, due to the lack of sufficient security measures and the presence of strong adversaries. Vulnerability identification in existing solutions, misuse by hardware vendors, and the lack of significant network features to integrate embedded IoT devices with cloud servers necessitate the design of a robust security mechanism. It is worth noting that the said design is a complex task that requires careful attention and planning, as a minor lapse could create a significant hurdle for the system. Given the urgency of the situation and the importance of IoT in the healthcare communication system, the said efforts would answer these questions, including (a) How will the IoT devices securely authenticate with each other, with the physician’s mobile device, and with the cloud server, and (b) how patient trust be managed on the IoT devices, sensors, and wearables on the physician and with the cloud server. Hence, keeping these questions in mind, the key contributions of this research work are as follows:

•   To propose an authentication mechanism based on a simple hash cryptographic function that offers robust authentication to all the components of the e-healthcare communication system and works efficiently by securely transmitting data to and from these components to the cloud server. To integrate the SHA256 hashing algorithm for reliability and high data availability.

•   The proof of correctness and robustness analysis of the proposed authentication scheme is scrutinized through a well-known and widely used BAN authentication logic, RoR model, ProVerif 2.03 validation, and a pragmatic discussion.

•   To test the efficacy and feasibility by evaluating the performance metrics through a testbed research method that utilized the Multiprecision Integer and Rational Arithmetic Cryptographic Library (MIRACL), an outstanding open-source Software Development Kit (SDK) written in the C/C++ programming language. The testing was performed on a Windows 10 Pro system equipped with an Intel Core™ i7-6500U CPU (2.50 GHz, with a boost up to 2.59 GHz), 16 GB of RAM, and a 128 GB SSD.

•   To comparatively analyze the other performance trade-offs, including energy consumption vs. task offloading, latency vs. runtime, runtime vs. energy consumption, and throughput vs. execution time, for checking its real-world implementation.

The remainder of this paper is organized as follows: Section 2 presents a detailed literature review of various schemes/existing solutions, in which prior works are critically analyzed. Section 3 outlines the proposed system model, threat model, and design goals. In Section 4, the proposed protocol is designed, while Section 5 analyzes its security using BAN logic and ProVerif validation. Section 6 presents the performance evaluation and comparative analysis. Finally, the last section concludes the work presented in this article.

2  Related Works & Problem Definition

Masud et al. [9] proposed a key derivation function-based protocol for data transmission to the cloud server in the e-healthcare system. They [9] argued that e-healthcare records through cloud computing technology would be secure if their security mechanism were implemented. However, they [9] don’t analyze the security of their scheme, so no one can say whether their [9] scheme is robust and feasible. Padmaja and Seshadri [10] used MD5 and the chaotic method for crypto-hashing of the e-healthcare record in the cloud server but suffered from a hash collision attack. Chandrakar et al. [11] used an asymmetric method, bilinear mapping, and the SHA1 technique to design a conditional privacy protection scheme for remote patient monitoring. However, their scheme [11] is vulnerable to side-channel and traceability attacks and performs poorly. Deebak and Al-Turjman [12] used a bio-hashing method along with pairing-based cryptography by designing a protocol for a cloud-driven medical system, but due to the exponentiation function, their scheme [12] consumed more energy and had high computation cost, which is not feasible for resource-constrained IoT applications. Chiou et al. [13] also utilized a bilinear mapping method to design the authentication scheme and claimed that their scheme preserves patient privacy, achieving unlinkability and successfully reducing computation and communication costs. However, it doesn’t resist traceability, spoofing, and session key hijacking attacks. Qadir and Hussan [14] proposed the security secret key provider (SSKP) model to improve data security and privacy in the cloud server, but their [14] proposed model, while a significant step to the cloud-based e-healthcare system, still does not allow patients to access their medical records.

Okikiola et al. [15] used symmetric encryption, decryption, and watermark extraction techniques for a cloud-based healthcare system to detect unauthorized activity and illegitimate changes in medical records. They [15] highlighted the significance of resisting an insider threat in the e-health record by proposing a strategy that includes a logging system and watermark extraction; OpenNebula, Microsoft Azure, PHP, and MySQL were utilized to implement their proposed security model. Benil and Jasper [16] proposed a model for protecting patient-sensitive data on a cloud server, successfully improved the security of a medical cloud server, and extensively tested for a case study; however, their model has the limitation of low performance. Jan et al. [17] recommended a hybrid cryptosystem-based security protocol for the Internet of Medical Things (IoMT) of the healthcare system, while [18] proposed a simple hash-based security scheme for IoT-driven e-healthcare. However, these schemes [17,18] are vulnerable to insider threats and identity theft attacks and have traceability issues. The remaining summary of the literature review is shown in Table 1.

Furthermore, Hamed and Yassin [32] employed OTP (one-time password) and SHA-2 to secure the e-healthcare record on a cloud platform, but it didn’t preserve the privacy of the patients and is susceptible to an insider attack. Yao et al. [33] combined biometrics, PUF, and passwords with the ECC technique to securely validate the security mechanism for patient records. Lee et al. [34] introduced a PUF-based authentication mechanism for patient-sensitive information protection; however, it also has a privacy issue and is vulnerable to a side-channel attack. Zhang et al. [35] proposed an IoT-driven authentication mechanism that combines SHA1, asymmetric cryptography, and biometrics but doesn’t resist a hash collision attack. Sun et al. [36] employed a blockchain-based data-driven trust mechanism that leveraged the RSA algorithm to exchange medical information securely; however, it is vulnerable to a masquerade attack in which an attacker can easily impersonate the cloud server by showing themselves as a legitimate user. Sunitha et al. [37] presented an asymmetric encryption-based system and a three-factor authentication scheme to guarantee the secure exchange of medical records to the cloud server. However, their scheme [37] lacks privacy issues and is susceptible to a stolen verifier attack.

Therefore, considering the extensive analysis of the existing solutions available in the literature [13–17], it has been concluded that these schemes either suffer from side-channel, MITM, and replay attacks, are not feasible for resource-constrained IoT due to modular exponentiation or bilinear pairing, or are completed in four to five round trips.

Problem Formulation

Very recently, a cloud-centric authentication scheme [38] has been presented to protect the same environment utilizing Elliptic Curve Cryptography (ECC). The previous scheme [38] consisted of five phases: setup, registration, authentication, sensor addition, and revocation. During the authentication phase, the patient and cloud server, the physician and cloud server, and the patient and physician are authenticated and exchange messages that are vulnerable to various attacks, including side-channel, DoS, and MITM attacks. These are explained one by one as follows:

Side Channel Attack: If an attacker captures these messages {HIDP, PKPH1, XPA, PKU1, T3}, {HIDCS, PKPH2, XCS1, PKU2, T7}, and {HIDPA, PKPA2, XPA2, T11}, they can easily compute PKP = RP ⨁ h(HIDP||RP||PKP), PKV1 = SPH||(XPH ⨁ n4)||PKP, PKW1 = n4.XPH, KCS = RPH ⨁ h(HIDCS||RCS||PKCS), PKV2 = SCS||(XCS ⨁ n5)||PKPH, PKW2 = n5. XCS,:PKCS2 = RPA ⨁ h(HIDPA||RCS||PKCS), PKV3 = SCS2||(XCS2 ⨁ r6)||PKCS2, PKW3 = r6. XCS2 and reach for calculating the session secret key SK = h(PKV1||PKW1), SK = h(PKV3||PKW3), and SK = h(PKV2||PKW2). Because the keys are not random, they remain static for every new session. If an attacker copies the publicly transmitted messages, they can easily launch a side-channel attack on the system. Therefore, Ref. [38] is vulnerable to side-channel attacks.

Man-in-the-Middle (MITM) Attack: Due to the static parameters and fixed keys in [38], the attacker can execute the MITM attack on the previously proposed scheme for the same environment. The attacker can easily intercept and computes PKCS2 = RCS ⨁ h(HIDPC||RPA||PKPA), PKS3 = (SPA||XPA2 ⨁ n6)||PKPA2), PKHP2 = RPH ⨁ h(HIDPH||RPH||PKPH1), PKS2 = (SPH||(XPH ⨁ r5)||PKHP2), PKPH1 = RPH ⨁ h(HIDPC||RPH||PKPH), and PKS1 = (SP||(XPA ⨁ r4)||PKPH1) messages between participants, resend old messages, and modify the stored parameters with ease.

DoS Attack: As the scheme presented in [38] relies on static parameters, such as fixed keys and hardcoded credentials, and lacks dynamic parameters, it is highly susceptible to a denial-of-service (DoS) attack. By flooding the patient with malicious requests, the attacker can interfere with normal operations and cause system failure. They can easily compute PKCS2 = RCS ⨁ h(HIDPC||RPA||PKPA), PKS3 = (SPA||XPA2 ⨁ n6)||PKPA2), PKHP2 = RPH ⨁ h(HIDPH||RPH||PKPH1), PKS2 = (SPH||(XPH ⨁ r5)||PKHP2), PKPH1 = RPH ⨁ h(HIDPC||RPH||PKPH), PKS1 = (SP||(XPA ⨁ r4)||PKPH1), PKP = RP ⨁ h(HIDP||RP||PKP), PKV1 = SPH||(XPH ⨁ n4)||PKP, PKCS2 = RPA ⨁ h(HIDPA||RCS||PKCS), PKV3 = SCS2||(XCS2 ⨁ r6)||PKCS2, PKCS = RPH ⨁ h(HIDCS||RCS||PKCS), and PKV2 = SCS||(XCS ⨁ n5)||PKPH, and reach the internal secrets or disturbed the normal operation of the system. Hence [38] is vulnerable to a DoS attack.

3  System Architecture

In this section of the article, the system architecture can be modeled by explaining the key concepts related to the system, including all possible threats in the threat model, and design goals for presenting efficient and effective solutions for such a vulnerable environment. So far, these basic ideas and system model or network model have been explained as follows:

3.1 Network Model

The system or network model presented here in the research work consisted mainly of three participating entities, namely sensors/wearables or IoT devices inside the patient’s body or worn by the patient for the collection of physiological vitals from the body of the patient, mobile device of paramedical staff or used by a physician for real-time monitoring of the patient, and a cloud server. The participating entities are explained below, while the diagrammatic representation of the system/network model is depicted in Fig. 1.

Figure 1: Proposed network model.

(1)   Sensor/Wearable or IoT Device: The sensor/wearable or IoT device, a key element, might be either implanted inside the patient’s body or embedded in the affected part of the body, and plays a crucial role in sensing the physiological condition of a patient. The collected sensitive information, like blood pressure, heart rate, ECG, EEG, blood oxygen, and blood circulation, etc. are transmitted into the cloud server through a wireless channel. These sensors/wearables or IoT devices are resource constrained means consume very low energy, have small latency, and limited bandwidth. Only a lightweight and efficient security mechanism is feasible for it to perform appropriately because it has a small processor and Electrically Erasable Programmable Read Only Memory (EEPROM).

(2)   Physician Mobile Device: A smartphone or mobile device plays a crucial role in the proposed healthcare communication system and is considered an essential part of the proposed network model. Smartphones and tablets, the backbone of remote patient monitoring in the cloud-assisted e-healthcare system, enable real-time viewing of patient data from multiple linked sensors, wearables, or IoT devices through the cloud server. The smartphone is connected to a specified cloud-based e-healthcare system, displays patient data from associated monitoring IoT devices, equipment, sensors, and wearables, and the physician can easily diagnose the patient. The cloud system ensures that vital signs and other appropriate health indicators/sensors or wearables are updated in real-time for the physicians to examine, enhancing the efficiency of healthcare delivery. If a patient’s readings deviate from a signal range, the mobile devices provide immediate patient interaction through an alarm or a message.

(3)   Cloud Server: A cloud server, while providing scalability and affordability compared to conventional physical infrastructure, serves as a central, easily accessible center for handling and storing data in an e-healthcare system. A cloud server enables remote care examinations, where healthcare professionals can access patient data and conduct examinations from any location with internet access. It also allows for monitoring patients remotely, allowing for continuous tracking of patient health metrics. The cloud server also optimizes treatment processes across several healthcare professionals, ensures the sound and efficient handling of patient health-related records, scans, and other private information, and offers flexibility and mobility. It generates security parameters, cryptographic keys, and other credentials, hosts the e-healthcare system, stores sensitive patient data, maintains physician records, provides real-time patient monitoring facilities, and ensures patient privacy for the entire healthcare communication system.

3.2 Threat Model

We have adopted an extended Dolev-Yao (DY) adversarial model [39] enhanced to capture fully active and insider threats. The adversary 𝔸 has the following capabilities:

1.    Network Adversary: An adversary 𝔸 can modify a message in transit, inject new things into the message, delete or delay a message, or compromise the whole session. Also, the adversary 𝔸 can act as a malicious operator for the server, compromise the sensor, or rogue either the patient or the physician device.

2.    Insider Adversary: The adversary 𝔸 might compromise a legitimate entity like a sensor, a physician device, or a cloud server by extracting stored credentials, but not the long-term secrets, which are protected by hardware or might act as a malicious insider by compromising the cloud server.

3.    Cryptographic Assumptions: The one-way hash cryptographic function h(.) is collision-resistant and behaves as a random oracle; the different random numbers generated at different round-trip are secure and unpredictable, while the long-term secrets dS are stored in tamper-resistant memory where an attack is not possible.

4.    Adversarial Goals: The adversary 𝔸 tries to get SK, impersonate any legal entity, break the confidentiality, cause a desynchronization anomaly or launch a DoS attack on the system.

3.3 Design Goals

After designing the proposed protocol for the e-healthcare communication system, which works through the cloud and is assisted by IoT, the following design goals should be achieved.

(i)   Confidentiality: The proposed protocol is designed to maintain the privacy of patient-sensitive information proactively. Patient sensors, wearables, or IoT devices registered and utilized by a patient for monitoring will be allowed to access the cloud server for which these devices are functionalized. Only a legitimate mobile device will be used by the physician to access the designated patient data from the cloud server. The system is designed to promptly detect and discard most illegal attempts to access the system.

(ii)   Integrity: The proposed protocol is robust in maintaining the legitimacy of patient-sensitive information. When receiving patient data, the cloud server is designed to promptly discard any illegal modifications and ensure the integrity of the data. Only legitimate doctors/physicians should be allowed to access the cloud server, and any unauthorized attempts will be promptly detected and discarded. This robust protection ensures the integrity of patient data, physician sessions with the patient, and cloud server availability.

(iii)   Availability: The proposed protocol is reliable in maintaining the availability of patient data. Using this security mechanism, the sensors can securely exchange patient-sensitive data, either bandwidth-limited, low-latency, and low-powered wireless networking channels or powerful ones, to the cloud server. The cloud server incorporates any number of legitimate sensors, wearables, or IoT devices and grants access permissions from authentic doctors/physicians to access patient data, which are properly registered, and their records are available in the cloud server. Unauthorized attempts to access patient-sensitive information are expected to be discarded, and permission should not be granted under normal conditions. The proposed protocol also ensures the availability of all the resources associated with the proposed e-healthcare communication system to access data securely. It enables effective network reconfiguration when a patient goes out of the system.

4  Proposed Protocol

The protocol involves three main entities, including Wearables (W), Physician Mobile Devices (PM), and the Cloud Server (CS). The proposed protocol is based purely on simple hash functions, random nonces, timestamps, and simple bitwise operations. For clarity, Table 2 summarizes the key symbols that h(.) denotes a one-way hash function, ⊕ represents XOR, and || denotes concatenation. Timestamps like TW, TPM, and TCS and random numbers like r1, r2, and r3 that can ensure freshness and resist replay attacks.

4.1 Setup Phase

The cloud server chooses a one-way hash function h(.): {0, 1}* → {0, 1}1, secret key dS, publishes {h(.), dS}, and keeps dS as secret key.

4.2 Registration Phase

The registration phase is completed in the following two sub-phases:

(1)   Sensor Registration: Upon registering the sensor/wearable or IoT device, the following steps of computation are performed:

Step 01: The cloud (CS) server selects a unique identity IDW, a random number r1, and in a secure manner transmits {IDW, r1} to the sensor over a secure channel, and keeps {IDW, r1} in its memory.

Step 02: When receiving {IDW, r1}, the sensor stores for the record, as shown in module 1.

(2) Device Registration: This sub-phase is completed in the following two steps:

Step 01: Now registering the mobile device, the cloud server selects a unique identity IDPM, pseudo-identity PIDPM, computes Q1 = h(PDPM||dS), Q2 = h(IDPM||dS), and transmits {IDPM, PIDPM, Q1, Q2} to the mobile device and keeps its record in its memory.

Step 02: When receiving {IDPM, PIDPM, Q1, Q2} message, the mobile device securely stores these parameters in its memory for later authentication purposes, as shown in module 2.

4.3 Authentication Phase

This is the most important phase of the protocol, through which all three entities agree securely to a single session key. This phase is completed in the following computation steps.

Step 01: The mobile device user selects a random number, r2, records the current timestamp TPM, and performs a series of computations to generate S1, S2, and S3. These values are then sent as a message {PIDPM, TPM, S1, S2, S3} towards the sensor over a public channel.

Step 02: Upon receiving the {PIDPM, TPM, S1, S2, S3} message, the sensor’s role becomes crucial. It undergoes a meticulous verification process, checking the time Tc − TPM ≤ ΔT to ensure the absence of any potential replay/DoS attack. This verification process is a key step in maintaining the protocol’s security. If the message is validated, the sensor proceeds to the next step, choosing a random number r3 and recording the present timestamp TW, computing U1 = h(r1||TW) ⊕ r3, U2 = h(PIDPM||IDW||S1||S2||TPM||TW||r3) and sends {PIDPM, IDW, S1, S2, S3, U1, U2, TPM, TW} message to the cloud server over a public channel.

Step 03: The cloud server, when receiving {PIDPM, IDW, S1, S2, S3, U1, U2, TPM, TW} message, validates the received times (both TPM and TW) with the system current time Tc − TPM ≤ ΔT and TC − TW ≤ ΔT, if it doesn’t found with the pre-defined time threshold, the process is terminated, otherwise, the cloud server computes r3 = U1 ⊕ h(r1||TW), U2*= h(PIDPM||IDW||S1||S2||TPM||TW||r3), and confirms U2*? = U2, if become not validated, the process will be terminated, otherwise, computes IDPM = S1 ⊕ h(Q1||r2), S3*= h(PIDPM||IDPM||r2||TPM), and again confirms S3*? = S3 and again if not confirmed, the process will stop and terminate, else, the cloud server selects a pseudo-identity PIDPM2, records time TCS and computes the session key SK = h(IDPM||IDW||r2||r3||TPM||TW). Further the cloud server computes W1 = h(r3||r1||TCS) ⊕ SK, W2 = h(IDW||r3||TCS||SK), W3 = h(IDPM||r2||TCS) ⊕ SK, W4 = h(IDPM||r2||TCS) ⊕ PIDPM2, W5 = h(IDPM||r2||TCS) ⊕ h(PIDPM2||dS), W6 = h(IDPM||PIDPM2||r2||SK||h(dS||PIDPM2||TCS) and sends {W1, W2, W3, W4, W5, W6, TCS} message back to the sensor over a public channel.

Step 04: The sensor when receiving {W1, W2, W3, W4, W5, W6, TCS} message, it first checks TW − TCS ≤ ΔT, if validated, computes SK = W1 ⊕ h(r3||r1||TCS), W2*= h(IDW||r3||TCS||SK), and confirm W2*? = W2 if matched, sends {W3, W4, W5, W6, TCS} message towards the user over a public channel.

Step 05: The user, upon receiving {W3, W4, W5, W6, TCS} message, it first check TW–TCS ≤ ΔT, if validated, computes SK = W3 ⊕ h(IDPM||r2||TCS), PIDPM2 = W4 ⊕ h(IDPM||r2||TCS), Q1new = W5 ⊕ h(IDPM||r2||TCS), W6* = h(IDPM||PIDPM2||r2||SK||h(dS||PIDPM2||TCS) confirms W6*? = W6 and replaces Q1 with Q1new and PIDPM with PIDPM2, keeps SK as session secret key, as shown in module 3.

4.4 Algorithmic Representation

The algorithmic overview of this crucial phase of the protocol is demonstrated in Algorithm 1, which depicts the flow of information and random checks in the scheme. These conditions are a clear indication of its robustness against attacks; the implementation code is given in Appendix A of the article.

5  Proof of Correctness & Robustness

This section scrutinizes the proof of correctness and robustness of the proposed IoT-driven and cloud-assisted authentication protocol, which is accomplished through a well-known and widely used BAN logic [40], Random Oracle Model [41], ProVerif toolkit [42], and informal analysis, as follows:

5.1 BAN Logic Analysis

The BAN logic, introduced by Burrows et al. [40], is a systematic approach to protocol analysis. Its proof of correctness and security analysis is particularly adept at identifying potential flaws in a protocol, keeping us vigilant, or demonstrating its validity in terms of authentication. The logic consists of different notations and symbols (described in Table 3), different statements, postulates, and goals for checking the exchange of random numbers, keys, and hash codes. These are explained one by one for the proposed protocol in a systematic order as follows:

5.1.1 Message Content

The transmission of different messages among different participating entity during the authentication phase of the protocol is presented in message content form as follows:

W{PIDPM,TPM,S1,S2,S3}→PM(1)

PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS(2)

CS{W1,W2,W3,W4,W5,W6,TCS,}→PM(3)

PM{,W3,W4,W5,W6,TCS,}→W(4)

5.1.2 Idealization Form

The representation of numerous parameters into the rules defined by BAN logic or simply converting them into different messages, statements, and credentials in a form that expresses the belief and intentions of the participant. It is an essential step because it allows us to build trust, freshness, and authentication when checking its implementation and ensuring correctness, as well as running syntax. The idealized form of the proposed protocol is represented as follows:

PM|≡r2, PM|≡TPM,PM|≡dS(5)

W|≡r3,W|≡TW,W|≡dS(6)

CS|≡r1,r2,r3(7)

CS|≡TPM,TW,TCS(8)

CS|≡IDPM,IDW,PIDPM(9)

CS|≡dS(10)

5.1.3 Goals

It means to determine whether the protocol achieves the security features like mutual authentication, freshness, key secrecy, and confidentiality through the use of assumptions, rules, principles, identification, etc., and derive conclusions to check the proposed protocol for replay attack and trust violation or not, and obtain the core objectives, etc. So, the goals set for achieving are shown as follows:

W|≡(W{PIDPM,TPM,S1,S2,S3}→PM)(11)

PM|≡(W{PIDPM,TPM,S1,S2,S3}→PM)(12)

PM|≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS)(13)

CS|≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS)(14)

CS|≡(CS{W1,W2,W3,W4,W5,W6,TCS,}→PM)(15)

PM|≡(CS{W1,W2,W3,W4,W5,W6,TCS,}→PM)(16)

PM|≡(PM{,W3,W4,W5,W6,TCS,}→W)(17)

W|≡(PM{,W3,W4,W5,W6,TCS,}→W)(18)

5.1.4 Assumptions

The different keys, random numbers, nonces, etc., that form the foundation and derive the conclusion of scheme correctness, while mutually authenticating each other. It also explains how beliefs evolve during the shared session key computation and ensures that the proof is based on these assumptions. The assumptions for the proposed protocol are expressed as follows:

W|≡PM|≡(W{PIDPM,TPM,S1,S2,S3}→PM)(19)

PM|≡W|≡(W{PIDPM,TPM,S1,S2,S3}→PM)(20)

PM|≡CS|≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS)(21)

CS|≡PM|≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS)(22)

CS|≡PM|≡(CS{W1,W2,W3,W4,W5,W6,TCS,}→PM)(23)

PM|≡CS|≡(CS{W1,W2,W3,W4,W5,W6,TCS,}→PM)(24)

PM|≡W|≡(PM{,W3,W4,W5,W6,TCS,}→W)(25)

W|≡PM|≡(PM{,W3,W4,W5,W6,TCS,}→W)(26)

CS|≡(W{PIDPM,TPM,S1,S2,S3}→PM)(27)

CS|≡PM|≡(W{PIDPM,TPM,S1,S2,S3}→PM)(28)

CS|≡PM|≡W|≡(W{PIDPM,TPM,S1,S2,S3}→PM)(29)

W|≡PM|≡CS|≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS)(30)

PM|≡W|≡(PM{,W3,W4,W5,W6,TCS,}→W)(31)

PM|≡W|≡CS|≡(PM{,W3,W4,W5,W6,TCS}→W)(32)

5.1.5 Proof

For the proof of correctness of the protocol, the message contents, idealization, and assumptions will be used for achieving the goals. So, according to according to messages (1) and (23), the following result will be achieved.

W{PIDPM,TPM,S1,S2,S3}→PM:W|≡PM|≡(W{PIDPM,TPM,S1,S2,S3}→PM)(33)

Eq. (33) can be written as:

W|≡PM|≡(W{PIDPM,TPM,S1,S2,S3}→PM):(W{PIDPM,TPM,S1,S2,S3}→PM)(34)

Eq. (34), can be expressed as:

W|≡(W{PIDPM,TPM,S1,S2,S3}→PM):(W{PIDPM,TPM,S1,S2,S3}→PM)(35)

Eq. (35), means

W|≡(W{PIDPM,TPM,S1,S2,S3}→PM) Goal1 Eq. (11) Achieved

Now, Eq. (35) becomes

PM|≡(W{PIDPM,TPM,S1,S2,S3}→PM):(W{PIDPM,TPM,S1,S2,S3}→PM)(36)

Eq. (36) can be written as

PM|≡(W{PIDPM,TPM,S1,S2,S3}→PM) Goal2 Eq. (12) Achieved

Taking Eqs. (3) and (25), we get

PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CSPM|≡CS|≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS)(37)

Eq. (37), can be written as

PM|≡CS|≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS):(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS)(38)

Eq. (38), can also be expressed as

PM≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS):(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS)(39)

Eq. (39) means

PM≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW→CS) Goal3 Eq. (13) Achieved

Taking Eq. (38), we get

CS|≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS):(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS)(40)

Eq. (40) can also be expressed as

CS|≡(PM{PIDPM,IDW,TPM,S1,S2,S3,TW}→CS) Goal4 Eq. (14) Achieved

Taking Eqs. (5) and (27), we get

CS{W1,W2,W3,W4,W5,W6,TCS,}→PM:CS|≡PM|≡(CS{W1,W2,W3,W4,W5,W6,TCS,}→PM)(41)

Eq. (41), can also be expressed as

CS|≡PM|≡(CS{W1,W2,W3,W4,W5,W6,TCS,}→PM):(CS{W1,W2,W3,W4,W5,W6,TCS,}→PM)(42)

Eq. (42), means

CS|≡(CS{W1,W2,W3,W4,W5,W6,TCS}→PM):(CS{W1,W2,W3,W4,W5,W6,TCS}→PM)(43)

Eq. (43) can also be represented as

CS|≡(CS{W1,W2,W3,W4,W5,W6,TCS,}→PM) Goal5 Eq. (15) Achieved

Taking Eq. (43), we get

PM|≡(CS{W1,W2,W3,W4,W5,W6,TCS}→PM):(CS{W1,W2,W3,W4,W5,W6,TCS}→PM)(44)

Eq. (44) means

PM|≡(CS{W1,W2,W3,W4,W5,W6,TCS,}→PM) Goal6 Eq. (16) Achieved

Taking Eqs. (7) and (29), we get

PM{,W3,W4,W5,W6,TCS}→W:PM|≡W|≡(PM{,W3,W4,W5,W6,TCS}→W)(45)

Eq. (45) can be written as

PM|≡W|≡(PM{,W3,W4,W5,W6,TCS}→W):(PM{,W3,W4,W5,W6,TCS}→W)(46)

Eq. (46), means

PM|≡(PM{,W3,W4,W5,W6,TCS,}→W):(PM{,W3,W4,W5,W6,TCS,}→W)(47)

Eq. (47), can be written as

PM|≡(PM{,W3,W4,W5,W6,TCS,}→W) Goal7 Eq. (17) Achieved

Taking Eq. (46), we get

W|≡(PM{,W3,W4,W5,W6,TCS,}→W):(PM{,W3,W4,W5,W6,TCS,}→W)(48)

Eq. (48), means

W|≡(PM{,W3,W4,W5,W6,TCS,}→W) Goal8 Eq. (18) Achieved

Therefore, the BAN has verified the mutual authentication and freshness of the nonce, SK, and identities, not to prove resistance to all attacks. Hence, the proposed IoT-driven, and cloud centric security protocol is correct, and feasible for real-world e-healthcare system.

5.2 Limitations of BAN Logic and Complementary Analysis

In our design, the Dolev-Yao threat model [39] (Section 3.2) automatically takes into consideration the presence of an active attacker with total control over the network. Although BAN logic [40] (Section 5.1) is a formal methodological tool that verifies the authenticity of the designed protocols in an ideal state, this tool does not automatically assume the presence of multiple parallel protocol instances (concurrent sessions) or an adaptive attacker who can react during the protocol execution with the goal of breaching the protocol security. This weakness in BAN logic can be further overpowered by the random-oracle model (ROM) [41] analysis (Section 5.3) and an automated security protocol verification tool called “ProVerif” [42] (Section 5.4) that can formally verify the security of the designed protocols in the presence of multiple parallel protocol instances and an adaptive attacker. This tool shows the correctness of our designed protocol in providing a secure transmission of the data through the “session key” (SK) with the goal of securely covering the data transmission between the two parties. Meanwhile, the designed protocol provides the secrecy of the SK used in the secure transmission of the data. Also, the proposed protocol ensures mutual authentication (authentication of both parties at Sections 5.3 and 5.4). Moreover, the proposed protocol successfully resists the threats of “man-in-the-middle” attacks (the introduction of the attacker in the data transmission). Additionally, the proposed protocol uses “timestamps” (time indicators of the protocol messages) to guarantee the presence of each unique “session” with the goal of addressing the weakness of the adapted BAN logic methodology. It also generates multiple sessions that will have different session keys, due to using “dynamic pseudo-identities.” It means that the BAN logic proof in this work is used to establish belief consistency and authentication correctness, while resistance to concrete attacks such as MITM, replay, forgery, and insider attacks is separately analyzed through Random Oracle Model (ROM), ProVerif verification, and informal security analysis in the subsequent sections.

5.3 Analysis through RoR Model

The proposed protocol ℙ is a symmetric based scheme; it has no public key, so we will now adopt the widely accepted Real-Or-Random (ROR) model [41] and connect analysis for the proposed protocol ℙ with the DY-threat model [39]. The probabilistic polynomial-time adversary 𝔸 and the birthday paradox [43] will be used for the security assumption in the following manner.

Participants: Let ΠPMi be the ith instance of physician device (PM), ΠWj be the jth instance of sensor/wearable (W), and ΠCSk be the kth instance of cloud server (CS), respectively, then there exist three states i.e., accepted state in which the three instances successfully computes the SK, rejected state means not computed, and null (⊥)-state means nothing is output while running the protocol ℙ.

Partnering: Suppose two instances, Πl and Πm, are be the partners of ℙ, which either generated the same session key SK and share the identities to become partners of each other.

Freshness: If the SK computed by instance Πl and not revealed to 𝔸, then it means that it is fresh, because 𝔸 has complete control over the public channel and he/she is executing the following queries:

•   Execute(Πl, Πm): An adversary 𝔸 eavesdrops on the device and sensor to play a passive attacker.

•   Send(Πl, m): The adversary 𝔸 sends a message m to Πl and the output tuple they get shall be compared with the SK.

•   Reveal(Πl): Adversary 𝔸 gets SK of Πl.

•   Corrupt(Πl): 𝔸 gets long-term secret of ℙ.

•   Test(Πl): Adversary 𝔸 in this query test the SK they get while running different queries by flipping a coin; if they get 1—succeeded, 0—failed, ⊥(Null)—blank.

Theorem 1: Under the oracle, the SK is indistinguishable from a random string to the adversary 𝔸.

Proof: The session key SK = h(IDPM||IDW||r2||r3||TPM||TW), which is established from random nonce r2, r3 and is unknown to the adversary 𝔸. It means the input to the hash (h(.)) is unique per every session with overwhelming probability. So, in the oracle, the output of h(.) is a random string, so different from the 𝔸’s random string. Hence, the proposed protocol’s SK is indistinguishable. □

Semantic Security: Let 𝔸 act as a polynomial-time attacker against the proposed authentication protocol for the CS, has λ parameter. The ADV (advantage) with 𝔸 in breaching ℙ is shown by:

ADVP(A)≤(QH)22lh+(QS)2lr+(QS)|D|+ADVECDLP(t)(49)

Theorem 2: Under the oracle, P provides mutual authentication.

Proof: The authentication depends on U2, S3, W2, W6, and each one is masked by a hash for every individual session, along with a random nonce, and a timestamp. Hence, by running any query for finding collision of the preimages of h(.) is negligible under ROM.

In Eq. (49), the QH stands for “hash queries”, QS for “send queries”, lh is “length of hash output”, lr is “length of random number”, |D| is “size of password dictionary”, and ADVSHA256(t) is 𝔸’s advantage in breaking Secure Hash Algorithm 256 in time t. 𝔸 goes through different games which are mentioned as follows:

Game G0: 𝔸 plays this game for physically interacting 𝔸 as shown in Eq. (50). □

ADVP(A)=|2Prob[S0]−1|(50)

Theorem 3: The server secret key dS does not reveal the past SK.

Proof: SK depends on r2 and r3, which are discarded after the session is accomplished, so the knowledge of dS alone is not a guarantee for SK.

Game G1: 𝔸 plays this game by acting a eavesdropper and is shown in Eq. (51).

|Prob[S1]−Prob[S0]|≤ADVECDLP(t)+(QH)22lh(51)

Game G2: 𝔸 plays this game for forging SK which is shown in Eq. (52). □

|Prob[S2]−Prob[S1]|≤(QS)2lr(52)

Theorem 4: The replay of an old message or malicious attack is not valid for P.

Proof: The time stamp TPM, TCS, and TW, nonces r3, r4, and different checks at each round trip not only ensure freshness but also prohibit the adversary 𝔸 from replaying some old message. Such a reply to an old message failed the time checks, while a malicious attack failed by the hash chain in P.

Game G3: 𝔸 plays this game to reach the ephemeral random values is depicted in Eq. (53).

|Prob[S3]−Prob[S2]|≤(QS)2lr(53)

Game G4: 𝔸 plays this game for guessing the password or random number is shown by Eq. (54).

|Prob[S4]−Prob[S3]|≤(QS)|D|(54)

Game G5: 𝔸 play this game for reaching the secret key ds is shown in Eq. (55).

|Prob[S5]−Prob[S4]|≤ADVds(t)(55)

Eq. (55) can be written as:

Prob[S5]=12(56)

Combining Eqs. (50) to (56), we get

ADVP(A)≤(QH)22lh+(QS)2lr+(QS)|D|+ADVSHA256(t)+ADVds(t)(57)

Eq. (57) demonstrated that 𝔸 cannot break the semantic security of ℙ. □

5.4 ProVerif Simulation

A software verification toolkit called ProVerif [42] is used to check the robustness of the proposed protocol. The methodology of using this toolkit is shown in Fig. 2, which demonstrates that an attacker couldn’t crack the session secret key, a man-in-the-middle attack is not possible on the proposed protocol, and the confidentiality and reachability of the session secret are preserved. The code is shown in Appendix B of the article.

Figure 2: ProVerif simulation result summary.

The ProVerif model [42] implements an active adversary 𝔸 capable of intercepting, modifying, and forging messages on public channels, so the verification summary confirms that even under this strong adversary model, the SK remains secret, mutual authentication holds, and MITM are prevented. Also, insider threats are modeled by allowing the adversary 𝔸 to possess certain long-term credentials; the results show that the protocol remains secure under these conditions.

5.5 Informal Analysis

The proposed protocol ℙ can pragmatically be discussed for different attacks and security features in showing its robustness and feasibility. These are explained as follows:

(1)   Offers Mutual Authentication: The U2 = h(PIDPM||IDW||S1||S2||TPM||TW||r3) at the physician side confirms at the cloud side U2* = h(PIDPM||IDW||S1||S2||TPM||TW||r3), the S3* = h(PIDPM||IDPM||r2||TPM) at the patient side confirms at the cloud side S3 = h(PIDPM||IDPM||r2||TPM), the W2 = h(IDW||r3||TCS||SK) at the cloud side confirms at the patient side W2* = h(IDW||r3||TCS||SK) and W6 = h(IDPM||PIDPM2||r2||SK||h(dS||PIDPM2||TCS) at the cloud side confirms at the patient side W6* = h(IDPM||PIDPM2||r2||SK||h(dS||PIDPM2||TCS) demonstrates that all the participating parties mutually authenticate each other.

(2)   Offers Unlinkability, Anonymity, and Untraceability: The mentioned three security features can be attained for the proposed protocol because the cloud server communicates with the patient and doctor using a pseudonym PIDPM. The pseudo-identity PIDi is updated for the current session as well as each upcoming session. There is no interaction between the two sessions if the attacker receives the most recent one from the public network channel. Therefore, the proposed protocol aims to provide unlinkability, anonymity, and untraceability under the assumed threat model.

(3)   Resists Replay Attack: Let 𝔸 captures the first message {SID, PK2, E2, T1} which is transmitted between sensor and device and replay some other time, it has to pass T2 − T1 ≤ ∆T which is not possible, also the existence of 160-bits long key PK2 pseudo-identity SID, and E2 = r6 ⊕ A3 ⊕ h(PK2||SID||T1) complex set of calculation doesn’t allow the attacker to launch replay attack on the system. And suppose, the attacker captures the second {F2, F3, F6, F7, IDde, T3} message which is transmitted between device and sensor, the attacker has to pass these random checks T4 − T3 ≤ ∆T, F1* = F4 ⊕ B1 ⊕ PK ⊕ h(k.PK1), F1*? = F1 which is hard to launch the replay attack. Hence, the proposed protocol is designed to resist replay attacks under typical deployment scenarios.

(4)   Withstands MITM Attack: Suppose 𝔸 sends something towards the device by acting as a malicious user, the device first check the validity of the message with its current time, if lying within the pre-defined time threshold, it allow to verify the identity of sensor IDsr, PK2 and E2 = r6 ⊕ A3 ⊕ h(PK2||SID||T1), otherwise there any illegal attempt will never be entertained. Similarly, if the attacker sends a fake message toward the sensor, the sensor first check the message with their own time threshold, and then compute F1*= F4 ⊕ B1 ⊕ PK ⊕ h(k·PK1) and confirms F1*? = F1 which is looking very hard for the attacker to play the role of man-in-the-middle. Thus, the proposed scheme is designed to withstand MITM attacks under the Dolev-Yao adversary model.

(5)   Provide Perfect Forward Secrecy: The parameters are concealed with a SHA2 algorithm, through which all the parameters are securely stored in the memory of the sensor, mobile device, and cloud server. They are used by each participating entity for mutual authentication and establishing the shared secret key. The server secret key dS is entirely inaccessible to any potential attacker. Even if they manage to obtain the random number and secret key from the mobile device, they still be unable to use it. Furthermore, any changes made at the patient end are immediately reflected at the cloud server end.

(6)   Safe against an Insider Attack: The certificate authority stores {PK, G, p, P, q, h(.)}, where k ∈ Zp*, and the public key is 160 bits long. The sensor memory consists of {A2, A3} calculated from A1 = r1. P, B1 = r2. P, B2 = r2 ⊕ (k·PK), r2 = B2 ⊕ (k·PK), computes A2 = B1 ⊕ A1, A3 = k. PK, while the device memory stores {C2, C3, r5, PK1} parameters, constructed from a complex set of calculations, C1 = r3. P B3 = r4. P, B4 = r4 ⊕ (k·PK), r4 = B4 ⊕ (k·PK), C2 = B4 ⊕ r3, C3 = k·PK. PK1 = r5. P. Therefore, if an attacker gains control and enters the system to identify useful credentials from these stored parameters, due to the use of a 160-bit key, random numbers, the SHA256 algorithm, and curve points, they cannot succeed in launching an insider attack. Therefore, the proposed protocol is designed to resist insider threats under the specified security assumptions.

Moreover, if an adversary 𝔸 wants to act as an insider, he/she have to find the secret dS, r2, r3, and pseudo-identities PIDPM and PIDPM2. Let the adversary 𝔸 gets the Q1 and Q2. Still, he/she cannot compute the SK due to no knowledge of r2 and r3 because the server secret dS is not shared with anyone, and it is safely stored from anyone, limiting the insider. At the same time, the pseudo-identities PIDPM and PIDPM2 provide a shield to the long-term secret.

(7)   Free from Impersonation Attack: Suppose 𝔸 enters the open network channel and tries to get {PSID, E3, F4, E5, E6, T5} message, they have to computes PSID = IDsr ⊕ h(PK2||r9), E4 = F4 ⊕ B1 ⊕ PK ⊕ h(k·PK1), E5 = PSID ⊕ h(r9||E4), and E6 = r9 ⊕ PK ⊕ h(k·PK1)||T5 which is not possible because each parameters is tightly bounded with other, so attacker cannot impersonate a legitimate user. Therefore, the proposed scheme is designed to resist impersonation attacks under normal operational conditions.

(8)   Stolen Verifier Attack Is Not Valid: Suppose 𝔸 steals the mobile device and retrieves the stored credentials from its memory. The memory of the mobile device contains the {C2, C3, r5, PK1} parameters, which were calculated from a complex set of calculations, including C1 = r3. P B3 = r4. P, B4 = r4 ⊕ (k·PK), r4 = B4 ⊕ (k·PK), C2 = B4 ⊕ r3, C3 = k·PK. PK1 = r5. The attacker has to pass through a complex set of computations to find the 160-bit key, random numbers that are different for each session, a 192-bit secret key, and a curve point that is not fixed. Thus, the proposed protocol is designed to mitigate stolen verifier attacks under the assumed adversary capabilities.

(9)   Resists a Desynchronization Attack: The cloud server modifies the selection of a pseudo-identity PIDPM in the first round and then updates the pseudo-identity in the second round PIDPM2 and secret key dS, and then replacing the old pseudo-identity and secret key with the new ones PIDPMnew and dSnew. This process ensures that even though an attacker attempts to cease communication by flooding data, the communication will continue to function, and the protocol can secure the available data, by maintaining the system form a desynchronization attack.

(10)   Compromise Entity Analysis: Suppose adversary 𝔸 learns IDW, r1, and desires to compute SK, he/she cannot, due to no knowledge of r2 and r3. If he/she gets PIDPM, Q1, and Q2, they still cannot implement the CS due to a lack of knowledge of dS, because the dS of the server is protected, and the scheme perfectly provides key secrecy.

6  Performance Evaluations and Comparative Analysis

This section of the article will not only measures the performance metrics like computation, communication costs and energy consumption, but also other performance trade-offs and scalability as discussed one by one as under:

6.1 Implementation

The cost for each individual cryptographic operation was measured through a careful assessment process for the proposed IoT-driven and cloud-assisted protocol. The following resources were used to determine computation costs, communication costs, storage overhead, and energy consumption:

1.    The Raspberry Pi 5 [44] was chosen as the IoT protocol runner due to its Broadcom BCM2712 2.4 GHz quad-core 64-bit Arm Cortex-A76 CPU, 2 GB of RAM, and dual-band 802.11ac Wi-Fi. These specifications were selected for their compatibility and optimal performance with the MIRACL Crypto SDK using C/C++ programming library [45].

2.    The Samsung Galaxy A21s smartphone, with a CPU with 4 cores at 2.0 GHz Cortex-A55 and 4 cores at 2.0 GHz Cortex-A55, is equipped with 6 GB of RAM and an Android operating system.

3.    The Core i7 laptop, running Windows 10 Pro, was selected for its specifications, including an Intel® Core™ i7-6500U CPU operating at 2.50 GHz (2.59 GHz burst speed).

The results of running the proposed protocol with different cryptographic operations. Considering the results obtained for the hash cryptography operation, random number extraction, and encryption/decryption operations mentioned in Table 4, the evaluation of various performance metrics like computation, communication, and storage costs is explained below, one by one. It is important to note that because xor and concatenation operations are simple and require little computing power, their execution times are too short—nearly zero—and they have no effect on the overall performance of the system.

6.2 Computation Cost Analysis

The total number of cryptographic operations performed by the physician, patient, and cloud sides is detailed as: for the physician’s side, the total number of hash functions is 6 (denoted as 6TH), the number of XOR operations is 5 (denoted as 5T⊕), and the random number extraction is 1TRN. Consequently, the cumulative cost at the physician’s end can be calculated as: 6TH + 5T⊕ + 1TRN = 6(0.674) + 5(0) + 1(2.448) = 4.044 + 0 + 2.448 = 6.492 ms. For the patient side, the total number of hash functions is 4TH, the number of XOR operations is 2T⊕, and the random number extraction remains 1TRN. Thus, the cumulative cost at the patient end is: 4TH + 2T⊕ + 1TRN = 4(0.891) + 2(0) + 1(2.946) = 3.546 + 0 + 2.946 = 6.492 ms. At the cloud server side, the total number of hash functions is 12TH, the number of XOR operations is 7T⊕, and the random number extraction is again noted as 1TRN. Therefore, the cumulative cost at the server end is: 12TH + 7T⊕ + 1TRN = 12(0.149) + 7(0) + 1(2.011) = 1.788 + 0 + 2.011 = 3.799 ms. Adding the costs calculated for all three participating peers, i.e., physician, patient, and server ends, are given as: 6.492 + 6.492 + 3.799 = 16.783 ms. This is shown in Table 5, and diagrammatically represented in Fig. 3.

Figure 3: Performance evaluation of the proposed IoT-driven cloud-assisted authentication protocol.

6.3 Storage Cost Analysis

The parameters stored in the memory of different participants includes {PIDPM, IDPM, Q1, Q2} stored by the physician end of cost, according to [46] is 60 + 60 + 256 + 256 = 632 bits, {IDW, r1} of the Patient end of cost 60 + 32 = 92 bits, and h(.): {0, 1}* → {0, 1}1, dS, {PIDPM, IDPM, Q1, Q2}m and {IDW, r1} at the server end of cost 256 + 64 + 60 + 60 + 256 + 256 + 60 + 64 = 1044 bits. The cumulative storage cost for all three participating entities is 1768 bits, as shown in Table 6 and plotted in Fig. 3. This cost is the result of the individual contributions from the physician, patient, and server ends, which are 632, 92, and 1044 bits, respectively.

6.4 Communication Cost Analysis

The first message transmitted between PM (physician device) and W (patient wearable) consists of the following elements: {PIDPM, TPM, S1, S2, S3}. The total cost of this message is calculated; according to [46] is 60 + 32 + 256 + 256 + 256, which equals 860 bits. The second message transmitted between W (patient wearable) to CS (cloud server) includes the elements: {PIDPM, IDW, S1, S2, S3, U1, U2, TPM, TW}. The total cost for this message is 60 + 60 + 256 + 256 + 256 + 256 + 256 + 32 + 32, summing up to 1464 bits. The third message sent from CS (cloud server) to W (patient wearable) contains {W1, W2, W3, W4, W5, W6, TCS}. Its cost is calculated as 256 + 256 + 256 + 256 + 256 + 256 + 32, resulting in a total of 1568 bits. Finally, the last message transmitted between W (patient wearable) and PM (physician device) includes {W3, W4, W5, W6, TCS}, with a total cost of 256 + 256 + 256 + 256 + 32, which equals 1056 bits. When we add up the communication costs for all four messages, we get a cumulative total of 860 + 1464 + 1568 + 1056, amounting to 4948 bits. This detailed breakdown, which is also presented in Table 7 and illustrated in Fig. 3, provides a comprehensive view of the communication costs.

6.5 Energy Consumption Analysis

During the implementation phase, the resources consume a specific amount of battery power upon executing the proposed IoT-driven and cloud-assistant authentication protocol. The Raspberry Pi [44], Cell-phone, and Laptop utilize some power to perform computation and message communication. EC = CT × CP represents a wireless communication channel. In contrast, CT is the computation cost of the proposed IoT-driven and cloud-assistant authentication protocol, which is calculated as 16.783 ms; CP means the maximum power utilized by the CPU, which is set to be fixed at 10.88 W for the transmission of wireless data [47]. It is worth noting that computation time complexity is directly related to battery power, like a protocol that has fewer operations, which will consume less energy [48]. By inputting these values into the formula, EC = 16.783 × 10.88 = 182.56 mJ, considering the proposed protocol’s energy consumption. This calculation highlights the efficiency of the proposed protocol, reassuring the effectiveness in managing energy consumption.

6.6 Scalability Analysis

Upon running the protocol for one complete round trip and calculating the session secret key (SK), this complex calculation is essentially the round trip time (RTT). The precision of these calculations is not just important; it’s paramount. In the following set of calculations, where TSK represents the RTT for the generation of SK, TSP is the beginning time when it set computes, TRP is the complete RTT of the proposed protocol, and TRS is the time of reachability of SK to each participating entity, we ensure our utmost attention to detail shown in Eqs. (58) to (63):

TSK=TSP+TRP+TRS(58)

Now, the maximum time needed to keep SK as a session secret key is represented as:

TRS=DSWlog2(1+PDN)(59)

DS means data size in bits, W is the bandwidth required for exchanging different credentials, PD means the power of an IoT device, sensor, or wearable, and N means the Gauss noise [49] for energy in the communication channel [47].

TRP=CPCE(60)

Whereas C means the communication cost of the proposed cloud-assisted protocol, CE means the time the cloud server takes to run the setup phase for generating the secret credentials.

TRS≈0(61)

Put (51)–(53) in (50), we get

TSK=DSWlog2(1+PDN)+CPCE+0(62)

TSK=DSWlog2(1+PDN)+CPCE(63)

6.7 Performance Trade-Offs Analysis

In the case of a cloud-assisted e-healthcare system, the proposed method has significantly decreased computational costs, making it highly effective for n-number of sensors/IoT devices or wearables and energy consumption, run-time, latency in bps, and task-offloading contrary to ECC-based, PUF-based, Hash-based, Blockchain-based, Three-factor-based, and Hybrid Cryptosystem-based such as [11,12,26,27,50,51] This analysis, which is shown in Figs. 4–6, verifies the scalability of the proposed authentication scheme, which is designed for IoT, cloud servers, and mobile devices, and can process continuous processing at a lower cost. The proposed IoT-driven and cloud-assisted authentication protocol is not only cost-effective but also highly scalable, making it suitable for a wide range of real-world scenarios.

Figure 4: Energy consumption vs. number of devices.

Figure 5: Energy consumption vs. number of task-offloading.

Figure 6: Execution time vs. throughput.

(1)   Energy Consumption vs. Number of Devices: Fig. 4 shows the energy usage contrary to the number of devices for the proposed technique, as well as several other methods, like ECC-based, PUF-based, Hash-based, Blockchain-based, Three-factor-based, and Hybrid Cryptosystem-based are ineffective for small-scale deployments because they use more energy at lower device counts. The proposed scheme outperforms others with more than 1000 devices, retaining the lowest energy consumption and maximum number of devices as the number of devices rises. At increasing device densities, ECC-based and Three-factor based scale less successfully than the proposed method, and the inadequacy of the scalability of Hash-based and Blockchain-based is a major issue, as their energy usage is excessively high even at intermediate device counts.

(2)   Energy Consumption vs. Number of Task-Offloading: The energy consumption comparison of the proposed scheme and various existing techniques like ECC-based, PUF-based, Hash-based, Blockchain-based, Three-factor-based, and Hybrid Cryptosystem-based; the result is depicted in Fig. 5, which demonstrates not only the superior energy efficiency of the proposed method but also its practical implications. Our scheme consistently outperforms others at all task-offloading scales, with more significant benefits at higher workloads. The efficiency for lesser workloads, ECC-based and Hash-based exhibit poor scalability, with their energy usage increasing disproportionately at scale. Also, Hybrid-Cryptosystem based is particularly shown that as the load is distributed it doesn’t perform well. The steady performance curve of the proposed approach validates strong optimization; however, the sharper drops for Blockchain-based, Three-factor-based, and Hybrid Cryptosystem-based at larger work volumes make them impractical.

(3)   Execution Time vs. Throughput: In Fig. 6, the proposed method consistently maintains superior efficiency with the lowest execution times across all throughput levels, especially at higher data rates, where other methods like ECC-based, PUF-based, Hash-based, Blockchain-based, Three-factor-based, and Hybrid Cryptosystem-based show significant performance degradation. The execution times of Three-Factor authentication based and ECC-based grow disproportionately with increasing data rates, suggesting poor scalability despite their moderate efficiency at lower throughputs. Critical issues exist in PUF-based, Hash-based, Blockchain-based, and Three-factor authentication methods, as they exhibit longer processing times than the proposed scheme. Among these, the Hybrid Cryptosystem-based approach is particularly inefficient, demonstrating significantly lower performance. Specifically, when throughput is high, transitioning from a Hybrid Cryptosystem-based to a Three-factor-based authentication model leads to ineffective resource allocation under stress. In contrast, the proposed method’s consistent, nearly linear performance curve validates its resilient and optimized design.

6.8 Comparative Analysis

(1)   Comparative Analysis (Performance Metrics): When comparing the proposed protocol with state-of-the-art protocols [11,12,26,27,50,51] in terms of communication and computation costs, the result demonstrated in Table 8 showed that the communication cost of [50,51] is slightly better than the proposed authentication scheme; however, the proposed protocol is much better in computation cost from all the mentioned schemes, as shown in Fig. 7.

Figure 7: Performance metrics comparison with state-of-the-art schemes.

Fig. 7 demonstrates the differences in computation and communication costs among various protocols. For example, [51] leads the pack at 4408 bits, closely followed by [50] of communication cost of 4558 bits, while the proposed approach has 4948 bits. Also, [11] incurs the highest overhead at 9440 bits, over twice as much as the protocol scheme. Similarly, the proposed technique, with a mere 16.79 ms, significantly reduces computing costs compared to the worst-performing protocols, such as [12] at 1200 ms and [11] at 350.3 ms, surpassing its closest rivals [26,27], which are both up to 27 ms by improving the proposed protocol up to 38%. It means the proposed technique emerges as the superior overall solution due to its remarkable computing efficiency, the crucial criterion for real-time performance, despite its slightly higher communication cost (12%) than [51]. The formula used for reduction in the proposed scheme is shown in Eq. (64):

Reduction(%Improvement)=BaselineCost−ProposedCostBaselineCost×100(64)

•   Best Communication Cost: [51] (4408 bits) and Best Computation Cost: Proposed (16.79 ms)

•   Communication cost difference: +540 bits (12.3% higher)

•   Computation cost improvement: 0.0% better

•   Combined Performance Score (The Proposed one is better):

•   Overall [11] is 0.646, [12] is 0.905, [26] is 0.335, [27] is 0.368, [50] is 0.253, [51] is 0.245, and the proposed is 0.269, which achieves the best balance between communication and computation costs!

(2)   Comparative Analysis (Security Functionalities): The proposed protocol is compared with the state-of-the-art schemes in security functionalities, including at least five attacks and five security features. The result demonstrated that the proposed protocol not only meets but exceeds expectations, as it is safe against all the attacks and avails all the mentioned features, as depicted in Table 9, which ✓ means the mentioned scheme is resisting the mentioned attack and availing the mentioned security feature, χ which means contrary to ✓. The security features of several protocols [11,12,21,26,27,38] are contrasted in Table 9 with widespread cryptographic attacks and security attributes. All of the threats listed—including Man-in-the-Middle, Password Guessing, Impersonation, Insider, Key Disclosure, and Replay attacks—are successfully mitigated by the proposed protocol, which also preserves all of the security features—including anonymity, untraceability, forward/backward secrecy, and session key secrecy. Notably, [11,21,27,51,52] demonstrate susceptibility to Man-in-the-Middle assaults, but only the Proposed procedure and [38] provide defense against impersonation attempts. Except [26,27,38,51], most protocols are resistant to password guessing attacks. Forward/Backward Secrecy is absent in [11,27,50,53]. As the existing protocols have serious flaws, especially [11,21], which do not offer anonymity, or untraceability, and [53], which are susceptible to a key disclosure attack, the proposed protocol stands out as the sole alternative offering both untraceability and total attack resistance.

(3)   Energy Consumption through Different Infrastructure: If we compare the energy efficiency of four different computational strategies, including local, edge, cloud offloading, and the proposed hybrid approach, the result depicted in Fig. 8 demonstrates that as the number of offloaded tasks increases, the energy consumption rises for all strategies, but at different rates. However, the proposed scheme maintains the lowest energy consumption across the entire range of tasks, which is one of the most energy-efficient solutions.

Figure 8: Energy consumption vs. number of task offloaded into differing strategies.

7  Conclusion

This article presented an authentication protocol for the cloud-centric and IoT-driven e-healthcare communication system based on a simple hash cryptographic function and XOR operation. The security of the proposed authentication scheme has been scrutinized via a widely used BAN logic, ProVerif simulation, and pragmatic discussion. In contrast, the performance metrics have been measured by considering computation cost, storage overhead, communication cost, energy consumption, and other trade-offs, such as energy consumption vs. the number of devices, energy consumption vs. task offloading, and runtime vs. throughput. The comparative analysis demonstrated that the proposed protocol outperforms all its competitors and is recommended for practical implementation in the real-world e-healthcare communication system. Future research will extend the proposed work by integrating blockchain technology, identity distribution, AI-enhanced, and quantum key derivation.

Acknowledgement: The authors are thankful to the Deanship of Graduate Studies and Scientific Research at the University of Bisha for supporting this work through the Fast-Track Research Support Program.

Funding Statement: The authors received no specific funding.

Author Contributions: The authors confirm contribution to the paper as follows: study conception and design: Saeed Ullah Jan, Fahad Algarni; data collection: Fahad Algarni; analysis and interpretation of results: Fahad Algarni, Saeed Ullah Jan; draft manuscript preparation: Saeed Ullah Jan, Fahad Algarni. All authors reviewed and approved the final version of the manuscript.

Availability of Data and Materials: Data will be available on request.

Ethics Approval: Not applicable to this research work.

Conflicts of Interest: The authors declare no conflicts of interest.

Appendix A

Algorithm implementation code

Appendix B ProVerif implementation Code

References

1. Dzung D, Naedele M, Von Hoff TP, Crevatin M. Security for industrial communication systems. Proc IEEE. 2005;93(6):1152–77. doi:10.1109/jproc.2005.849714. [Google Scholar] [CrossRef]

2. Chen L, Gong G. Communication system security. Boca Raton, FL, USA: CRC Press; 2012. [Google Scholar]

3. Rahman MG, Imai H. Security in wireless communication. Wirel Pers Commun. 2002;22(2):213–28. [Google Scholar]

4. Burg A, Chattopadhyay A, Lam KY. Wireless communication and security issues for cyber–physical systems and the Internet-of-Things. Proc IEEE. 2017;106(1):38–60. doi:10.1109/jproc.2017.2780172. [Google Scholar] [CrossRef]

5. Stavroulakis P, Stamp M. Handbook of information and communication security. Berlin/Heidelberg, Germany: Springer; 2010. [Google Scholar]

6. Roy KS, Deb S, Kalita HK. A novel hybrid authentication protocol utilizing lattice-based cryptography for IoT devices in fog networks. Digit Commun Netw. 2024;10(3):989–1000. doi:10.1016/j.dcan.2022.12.003. [Google Scholar] [CrossRef]

7. Liu W, Park EK. E-healthcare security solution framework. In: Proceedings of the 30th International Conference on Computer Communications and Networks; 2012 Jul 19–22; Athens, Greece. p. 1–6. [Google Scholar]

8. Zeadally S, Isaac JT, Baig Z. Security attacks and solutions in electronic health (E-health) systems. J Med Syst. 2016;40(12):263. doi:10.1007/s10916-016-0597-z. [Google Scholar] [PubMed] [CrossRef]

9. Masud M, Gaba GS, Choudhary K, Alroobaea R, Hossain MS. A robust and lightweight secure access scheme for cloud based E-healthcare services. Peer-to-Peer Netw Appl. 2021;14(5):3043–57. [Google Scholar] [PubMed]

10. Padmaja K, Seshadri R. A real-time secure medical device authentication for personal E-Healthcare services on cloud computing. Int J Syst Assur Eng Manag. 2022;13(Suppl 1):S186–96. doi:10.1007/s13198-021-01148-1. [Google Scholar] [CrossRef]

11. Chandrakar P, Sinha S, Ali R. Cloud-based authenticated protocol for healthcare monitoring system. J Ambient Intell Humaniz Comput. 2020;11(8):3431–47. [Google Scholar]

12. Deebak BD, Al-Turjman F. Smart mutual authentication protocol for cloud based medical healthcare systems using internet of medical things. IEEE J Sel Areas Commun. 2021;39(2):346–60. doi:10.1109/jsac.2020.3020599. [Google Scholar] [CrossRef]

13. Chiou SY, Ying Z, Liu J. Improvement of a privacy authentication scheme based on cloud for medical environment. J Med Syst. 2016;40(4):101. doi:10.1007/s10916-016-0453-1. [Google Scholar] [PubMed] [CrossRef]

14. Qadir GA, Hussan BK. An authentication and access control model for healthcare based cloud services. J Eng. 2023;29(9):15–26. doi:10.31026/j.eng.2023.03.02. [Google Scholar] [CrossRef]

15. Okikiola FM, Mustapha AM, Akinsola AF, Sokunbi MA. A new framework for detecting insider attacks in cloud based e-health care system. In: Proceedings of the 2020 International Conference in Mathematics, Computer. Engineering and Computer Science (ICMCECS); 2020 Mar 18–21; Lagos, Nigeria. p. 1–6. [Google Scholar]

16. Benil T, Jasper J. Cloud based security on outsourcing using blockchain in E-health systems. Comput Netw. 2020;178(3):107344. doi:10.1016/j.comnet.2020.107344. [Google Scholar] [CrossRef]

17. Jan SU, Ali S, Abbasi IA, Mosleh MA, Alsanad A, Khattak H. Secure patient authentication framework in the healthcare system using wireless medical sensor networks. J Healthc Eng. 2021;2021(4):9954089. doi:10.1155/2021/9954089. [Google Scholar] [PubMed] [CrossRef]

18. Jan SU, Tariq MU, Khashan OA, Alzahrani N, Ghani A. FEELAP: fuzzy extractor-based efficient lightweight authentication protocol for edge-IoT ecosystem in e-healthcare. IEEE Open J Comp Soc. 2025;6:1727–40. doi:10.1109/OJCS.2025.3616014. [Google Scholar] [CrossRef]

19. Ahmim M, Ouafi N, Ullah I, Ahmim A, Chefrour D, Almukhlifi R. LSAP-IoHT: lightweight secure authentication protocol for the internet of healthcare things. Comput Mater Contin. 2025;85(3):5093–116. doi:10.32604/cmc.2025.067641. [Google Scholar] [CrossRef]

20. Anandhi T, Sangari AS. Privacy preserving authentication protocol with optimized Elliptic Curve Cryptography for healthcare domain in cloud. Cluster Comput. 2026 Apr;29(2):77. doi:10.1007/s10586-025-05854-4. [Google Scholar] [CrossRef]

21. Tanveer M, Chelloug SA, Alabdulhafith M, El-Latif AAA. Lightweight authentication protocol for connected medical IoT through privacy-preserving access. Egypt Inform J. 2024;26(7):100474. doi:10.1016/j.eij.2024.100474. [Google Scholar] [CrossRef]

22. Mir O, Nikooghadam M. A secure biometrics based authentication with key agreement scheme in telemedicine networks for e-health services. Wirel Pers Commun. 2015;83(4):2439–61. doi:10.1007/s11277-015-2538-4. [Google Scholar] [CrossRef]

23. Ni S, Kang B, Li A, Huo Y, Zuo X. Analysis and improvement of a privacy-preserving authentication scheme for telecare medical information system environment. Wuhan Univ J Nat Sci. 2023;28(6):531–40. doi:10.1051/wujns/2023286531. [Google Scholar] [CrossRef]

24. Yu S, Park K. Sals-tmis: secure, anonymous, and lightweight privacy-preserving scheme for iomt-enabled TMIS environments. IEEE Access. 2022;10:60534–49. doi:10.1109/ACCESS.2022.3181182. [Google Scholar] [CrossRef]

25. Zheng L, Zhang Y, Zhang R, Chen J, Cui M, Song C. An improved authentication protocol in telemedicine system. Lect Notes Comput Sci. 2018;11337(4):177–84. doi:10.1007/978-3-030-05234-8_22. [Google Scholar] [CrossRef]

26. Li CT, Shih D, Wang C. Cloud-assisted mutual authentication and privacy preservation protocol for telecare medical information systems. Comput Methods Programs Biomed. 2018;157:191–203. doi:10.1016/j.cmpb.2018.02.002. [Google Scholar] [PubMed] [CrossRef]

27. Mohit P, Amin R, Karati A, Biswas GP, Khan MK. A standard mutual authentication protocol for cloud computing based health care system. J Med Syst. 2017;41(5):83. doi:10.1007/s10916-017-0699-2. [Google Scholar] [PubMed] [CrossRef]

28. Amin R, Islam SK, Gope P, Choo KR, Tapas N. Anonymity preserving and lightweight multimedical server authentication protocol for telecare medical information system. IEEE J Biomed Health Inform. 2019;23(4):1749–59. doi:10.1109/jbhi.2018.2870319. [Google Scholar] [PubMed] [CrossRef]

29. Setianto, Dwi YB, Wahyuningrum, Estri S. Multitier model with JSON-RPC in telemedicine devices authentication and authorization protocol. In: Proceedings of the 2021 7th International Conference on Engineering, Applied Sciences and Technology (ICEAST); 2021 May 1–3; Pattaya, Thailand. p. 213–6. [Google Scholar]

30. Son S, Lee J, Kim M, Yu S, Das AK, Park Y. Design of secure authentication protocol for cloud-assisted telecare medical information system using blockchain. IEEE Access. 2020;8:192177–91. doi:10.1109/ACCESS.2020.3032680. [Google Scholar] [CrossRef]

31. Lei C, Chuang Y. Privacy protection for telecare medicine information systems with multiple servers using a biometric-based authenticated key agreement scheme. IEEE Access. 2019;7:186480–90. doi:10.1109/access.2019.2958830. [Google Scholar] [CrossRef]

32. Hamed NM, Yassin AA. Secure patient authentication scheme in the healthcare system using symmetric encryption. Iraqi J Electr Electron Eng. 2022;18(2):94–105. doi:10.37917/ijeee.18.1.9. [Google Scholar] [CrossRef]

33. Yao H, Yan Q, Fu X, Zhang Z, Lan C. ECC-based lightweight authentication and access control scheme for IoT E-healthcare. Soft Comput. 2022;26(10):4441–61. doi:10.21203/rs.3.rs-210016/v1. [Google Scholar] [CrossRef]

34. Lee TF, Lin KW, Hsieh YP, Lee KC. Lightweight cloud computing-based RFID authentication protocols using PUF for e-healthcare systems. IEEE Sens J. 2023;23(6):6338–49. doi:10.1109/jsen.2023.3242132. [Google Scholar] [CrossRef]

35. Zhang L, Zhu Y, Ren W, Zhang Y, Choo KR. Privacy-preserving fast three-factor authentication and key agreement for IoT-based E-health systems. IEEE Trans Serv Comput. 2023;16(2):1324–33. doi:10.1109/TSC.2022.3149940. [Google Scholar] [CrossRef]

36. Sun L, Liu D, Li Y, Zhou D. A blockchain-based e-healthcare system with provenance awareness. IEEE Access. 2024;12(3):39532–44. doi:10.1109/access.2024.3440170. [Google Scholar] [CrossRef]

37. Sunitha MJ, Asendra C, Kumar BB, Harshith Goud E, Basha SH. User authentication scheme and identity management for e-health systems using blockchain technology. In: Proceedings of the 2024 International Conference on Knowledge Engineering and Communication Systems (ICKECS); 2024 Apr 18–19; Chikkaballapur, India. p. 1–7. [Google Scholar]

38. Alzahrani A. RLKS-TMS: a robust and lightweight key agreement scheme for telemedicine system. IEEE Access. 2024;12:24312–27. doi:10.1109/ACCESS.2024.3422038. [Google Scholar] [CrossRef]

39. Dolev D, Yao A. On the security of public key protocols. IEEE Trans Inf Theory. 1983;29(2):198–208. doi:10.1109/tit.1983.1056650. [Google Scholar] [CrossRef]

40. Burrows M, Abadi M, Needham R. A logic of authentication. ACM Trans Comput Syst. 1990;8(1):18–36. doi:10.1145/77648.77649. [Google Scholar] [CrossRef]

41. Canetti R, Goldreich O, Halevi S. The random oracle methodology, revisited. J ACM. 2004;51:557–94. doi:10.1145/1008731.1008734. [Google Scholar] [CrossRef]

42. Blanchet B, Smyth B, Cheval V, Sylvestre M. ProVerif 2.00: automatic cryptographic protocol verifier, user manual and tutorial. 2018[cited 2026 Jan 1]. Available from: https://bblanche.gitlabpages.inria.fr/proverif/manual.pdf. [Google Scholar]

43. Suzuki K, Tonien D, Kurosawa K, Toyota K. Birthday paradox for multi-collisions. In: International Conference on Information Security and Cryptology. Berlin/Heidelberg, Germany: Springer; 2006. p. 29–40. [Google Scholar]

44. Upton E, Halfacree G. Raspberry Pi user guide. Hoboken, NJ, USA: John Wiley & Sons, Inc.; 2016. [Google Scholar]

45. Rahaman S, Cai H, Chowdhury O, Yao D. From theory to code: identifying logical flaws in cryptographic implementations in C/C++. IEEE Trans Dependable Secur Comput. 2021;19(6):3790–803. doi:10.1109/TDSC.2021.3108031. [Google Scholar] [CrossRef]

46. Kilinc HH, Yanik T. A survey of SIP authentication and key agreement schemes. IEEE Commun Surv Tutorials. 2014;16(2):1005–23. doi:10.1109/surv.2013.091513.00050. [Google Scholar] [CrossRef]

47. Patil P, Narayankar P, Narayan DG, Meena SM. A comprehensive evaluation of cryptographic algorithms: DES, 3DES, AES, RSA and Blowfish. Procedia Comput Sci. 2016;78:617–24. doi:10.1016/j.procs.2016.02.108. [Google Scholar] [CrossRef]

48. Althebyan Q, Yaseen Q, Jararweh Y, Al-Ayyoub M. Cloud support for large scale e-healthcare systems. Ann Telecommun. 2016;71(9–10):503–15. doi:10.1007/s12243-016-0496-9. [Google Scholar] [CrossRef]

49. Prelov VV. Communication channel capacity with almost Gaussian noise. Theory Probab Appl. 1989;33(3):405–22. doi:10.1137/1133068. [Google Scholar] [CrossRef]

50. Keshta I. A CRC-based authentication model and ECC-based authentication protocol for resource-constrained IoT applications. IEEE Access. 2024;12(1):24328–44. doi:10.1109/access.2024.3482991. [Google Scholar] [CrossRef]

51. Alghamdi AM. Design and analysis of lightweight and robust authentication protocol for securing the resource constrained IIoT environment. PLoS One. 2025;20(2):e0318064. doi:10.1371/journal.pone.0318064. [Google Scholar] [PubMed] [CrossRef]

52. Alzahrani A. Developing a provable secure and cloud-centric authentication protocol for the e-healthcare system. IEEE Access. 2024;12(2):39545–61. doi:10.1109/access.2024.3500216. [Google Scholar] [CrossRef]

53. Alzahrani A, Alzahrani HA. A privacy-preserving and energy efficient authentication protocol for the cloud-based e-healthcare system. Alex Eng J. 2025;118(6):59–90. doi:10.1016/j.aej.2025.01.051. [Google Scholar] [CrossRef]