Revision as of 11:11, 12 April 2026 (view source) Fahad.alqarni (talk | contribs) (Created page with " <!-- metadata commented in wiki content <div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> <big>AKA – eHS: An Authentication and Key Agreeme...")	Revision as of 11:39, 12 April 2026 (view source) Fahad.alqarni (talk | contribs) m (Fahad.alqarni moved page Draft Algarni 534547190 to Algarni et al 2026a) Newer edit →
(No difference)

---

Revision as of 11:39, 12 April 2026

Abstract: The Internet of Things (IoT), sensors, and wearables collect real-time physiological vitals from the patient's body and transmit them to their destination through a wireless channel prone to several threats, including replay, denial-of-service (DoS) attacks, and pose privacy issues. However, if all the involved entities become securely authenticated, this, in turn, can minimize the mentioned threats and ensure the confidentiality, integrity, and privacy of patient-sensitive information. Therefore, this article presents a robust and lightweight authentication protocol for the IoT-driven e-healthcare system by utilizing Elliptic Curve Cryptographic (ECC) technique in which all the sensors/wearables or IoT/devices that are operationalized in the e-healthcare system for real-time patient monitoring can securely be connected to the gateway to show strong resistance to all the known cyber-threats in such hostile environments and maintain patient privacy, confidentiality, integrity, and authorization. The security analysis was conducted using the well-known and widely used BAN (Burrows–Abadi–Needham) logic, ProVerif simulation, AVISPA validation, and ROM analysis. While the performance evaluation of the proposed protocol has been measured by considering both computation and communication costs, an 81.01% improvement has been recorded in terms of communication cost, and a 92.26% improvement in terms of computation overhead, when compared with prior works.

Keywords: Biosensor; Threat; Privacy; Authentication; Healthcare; Physiological Vitals

1. Introduction

Integrating smart sensing devices/wearable technology and innovative health trackers into a person's body is becoming increasingly popular nowadays to remotely monitor patients and facilitate ease of diagnosis [1]. It monitors the various physiological activities of someone's body, which can help prevent and manage diseases, monitor mental status, and predict acute events because they (sensors, wearables, or IoT devices) are linked by wireless networking technology that uses an addressing scheme similar to the Internet [2]. It is also used in various other areas, including transportation, logistics, and infrastructure surveillance. Remarkably, the IoT in the healthcare system has successfully enabled continuous and noninvasive patient monitoring, ensuring a constant watch over a specific body part or an individual's health [3]. However, due to the resource-constrained nature of IoT, they are exposed to security threats from outside parties because they often operate in congested locations and require limited bandwidth and low-latency networking technology [4].

To date, data integrity, confidentiality, message authentication, and patient privacy are essential components of any medical application. Still, due to the resource-constrained nature of IoT, the security risks presented by these devices are especially alarming [5]. The urgency of resolving these issues is paramount, as protecting medical data obtained from sensors/wearables, avoiding access to unauthorized users, and concealing data exploitation via public networking channels are significant problems to be resolved [6]. In addition to these, IoT has become an essential tool in healthcare, enabling real-time data sharing, remote monitoring, and enhanced patient care. Utilizing IoT technologies to deliver sensitive physiological information and make it effective for the e-healthcare system can definitely gain patients’ trust and improve overall system effectiveness [7]. For example, IoT-enabled healthcare systems provide automatic vital sign detection, activity tracking, and patient monitoring, sending the data to doctors for diagnosis and laboratories for examination, investigation, and research purposes [8].

Eventually, IoT technology has made it possible to ensure initial diagnoses at the patient's end and to examine them remotely by physicians and other paramedical staff [9]. It also enables other services, such as real-time monitoring, medical consultations, and prescription of treatments at a patient's doorstep [10]. Various efforts have been made over time to enhance the system's security and preserve user privacy. For example, Lopes et al. [11] proposed a mutual authentication protocol for device-to-device (D2D) communications in a cloud-based e-health system. Ayub et al. [12] presented a lightweight authentication protocol for e-health clouds in an IoT-based system, utilizing a robust three-factor authentication scheme to ensure a secure Telecare Medical Information System (TMIS).  The researchers in [13] argued that radio frequency identification (RFID) can be utilized in cloud-based e-healthcare systems. Ansari et al. [15] proposed a privacy-enabled framework for cloud-based e-healthcare systems to achieve privacy-preserved and secure communication in e-healthcare. However, these various approaches [11-15] have faced difficulties during real-world implementation and are prone to DOS and replay attacks, and patient privacy is not preserved. However, security and privacy issues are still not adequately addressed, and this problem underscores the need for a robust security mechanism to ensure the privacy of patient-sensitive medical information and secure all implanted devices/sensors, and wearables, thereby making the e-healthcare system immune to threats and anomalies.

1.1 Motivation

Several authentication techniques, combining multiple approaches such as bilinear pairing, symmetric, RSA, Computational Diffie-Hellman, and Chebyshev polynomial techniques [11-15], have been recently developed for IoT-driven e-healthcare systems. These techniques are either vulnerable to man-in-the-middle, denial-of-service, side-channel, and replay attacks or have design flaws. They are also durable due to module exponentiation and are completed in five to six round trips. Among these, the Chebyshev polynomial-based authentication methods created unstable poles, failed to maintain error production, and yielded no apparent advantage. As a result of these vulnerabilities, the specific requirements of e-health systems could not be met by the authentication techniques covered in the literature. Consequently, to ensure the confidentiality, integrity, and security of such a critical environment [16] and ECC-driven robust and lightweight security mechanism is needed to alleviate all the issues in the literature effectively. To achieve this, we were motivated to design an ECC-based protocol for resource-constrained IoT-driven e-healthcare systems. Integrating ECC [17] and a gateway enables the system to generate random numbers and store data locally before transmitting patient data to physicians' mobile devices for diagnosis, treatment, and examination.

1.2 Contributions

This paper proposes an ECC-based [18-19] protocol for resource-constrained IoT applications in e-healthcare systems, including smart watches, health monitoring, and implantable and wearable sensors. It utilizes a gateway for the local processing and storage of credentials, and then securely sends patient-sensitive data to physicians' or doctors' mobile devices for treatment and examination. The goal is to maintain the integrity, security, and privacy of health-related data, while the major contributions of the research work are as follows:

* To design a robust and lightweight authentication protocol for the IoT operationalized in the medical field by utilizing the geometric characteristics of ECC techniques. Through this rigorous design of a lightweight protocol, integrating the ECC method, these devices can securely connect to the gateway, exhibiting strong resistance to all known cyber-threats due to the freshness of random numbers, even in hostile environments, while maintaining patient privacy, confidentiality, integrity, and authorization of patient-sensitive information.

• To analyze the security of the proposed protocol via well-known and widely used BAN logic, and ROM analysis and ProVerif and AVISPA toolkits.

• To measure the performance of the proposed protocol by considering energy consumption, computation, and communication cost.

• The proposed protocol's scalability was confirmed by measuring the trade-offs among energy consumption, throughput, delay, latency, and task offloading. The results demonstrated that the proposed protocol outperforms its competitors.

• To analyze the proposed protocol comprehensively by matching it with state-of-the-art schemes in evaluating its security functionalities and performance metrics like energy consumption, throughput, delay, latency, and task-offloading, ultimately achieving the balance of security with performance that is often missing in prior works.

1.3 Paper Layout

Sec. 2 demonstrates the preliminary and background, in sec. 3 the literature review can be presented along with a review analysis of the baseline scheme and the loopholes identified in their scheme; Sec. 4 proposes the network model along with an ECC-Based protocol for the resource-constrained IoT-applications in the e-healthcare system, a proposal that the security analysis in Sec. 5 will further solidify. Sec. 6 then measures the performance, providing a comprehensive understanding of the system's capabilities. Finally, in Sec. 7, the research work is concluded, leaving reassurance and confidence in the results obtained.

2. Backgrounds

This section introduces the preliminary concepts, definitions, and terminologies pertaining to conducting this research work, which are explained as follows:

2.1 Secure Hash Algorithm (SHA256)

One of the most widely used hashing algorithms is SHA-256, a component of the superior SHA-2 (Secure Hash Algorithm 2) used by [13] and [14]. This algorithm's real-world applicability is due to the clarity of each step. SHA-256is renowned for its speed and security, and it surpasses SHA-1 in every aspect. No one has found a collision in SHA-256, unlike SHA-1. Its speed and security make it the best choice in a variety of situations, especially when keys are frequently created in asymmetric methods like ECC.

2.2 Elliptic Curve Cryptography (ECC)

ECC, a type of asymmetric key cryptography, is a complex topic that involves representing the curve E(Fp) as y^2 = x^3 + ax + b, where a and b belong to Fp (a finite field) [17]. It provides a set of public keys and secret numbers (integers) and is more secure than RSA. The computational challenge in finding the randomly selected integer value (secret key) from the curve is a testament to the complexity of ECC. For instance, the same key will be 160 bits in ECC, but in RSA [18], it is 1024 bits long, which means RSA is six times greater than ECC and has less security than ECC.

2.3 Security Requirements

When designing the protocol for IoT applications, the following measures are necessary to ensure high security.

1) Authentication: Before operationalizing IoT for a task, the retrieval of patient data, physician information, and their cross-legality, along with all communicating entities, must first be authenticated. This emphasis on authentication ensures that only legitimate users and entities can access the system, providing a strong sense of security.

2) Attack Resilience: Our proposed ECC-based security protocol is not static. It is designed to dynamically update its topology by adding or removing any wearable, sensor, or IoT device. This adaptability ensures that the system can handle any scenario, even when a single or multiple sensor node or IoT devices fails during task completion, providing a high level of resilience.

3) Access Control: The data provided by the information provider is not just accessed; it's accessed in a controlled and precise manner. The physician, the laboratory, and the gateway each access only the specific parts of patient data they need, ensuring utmost care in handling patient-sensitive information in a hostile environment and instilling confidence in the system's ability to protect this information.

4) Authorization: Only the authorized entity, such as a legitimate physician, legitimate patient, or any other paramedical staff, can gather information or observe access related to the patient.

5) Other Features: The proposed ECC-based protocol's remaining features are entity identification, storage security, identity management, availability, data transmission security, secure network access, and tamper resistance.

3. Related Works

Lopes et al. [11] proposed a scheme for device-to-device (D2D) communications in the cloud-centric e-health system. They argued that their scheme aimed to establish secure and privacy-preserving mutual authentication among devices in the cloud-based e-healthcare system. Ayub et al. [12] introduced a lightweight authentication protocol for the same environment, which utilized IoT for data collection. Their scheme was a three-factor authentication ensuring secure access to the telecare server. Their scheme also provides a high level of security and confidentiality of authorization. A blockchain-based framework has been proposed by [12] to integrate the decentralized and immutable nature of blockchain into e-healthcare, ensuring the integrity and authenticity of healthcare records. RFID tags/scanners sense physiological vitals from patients in electronic systems [13] for healthcare design. A lightweight cloud-assisted authentication protocol can ensure a secure and reliable authentication in e-healthcare systems [13]. The researchers in [14] also used RFID to address the identified challenges in prior works and guarantee the security and reliability of electronic health information. These solutions are of utmost importance in ensuring the security and privacy of patient-sensitive data within a hospital environment. Ansari et al. [20] also proposed a privacy-based scheme for cloud-centric e-healthcare systems to enhance privacy and secure communication among physicians in e-healthcare. Their [20] framework aimed to secure the privacy, confidentiality, integrity, and security of patient data and prevent various attacks launched by an attacker via cryptanalysis and formally and automatically detect violations of e-healthcare security. The summary of the remaining literature review is shown in Table 1.

Table 1. Summary of the literature review

Ref	Year	Methodology	Limitations
[21]	2019	Bilinear Pairing, Hash, Operation	Suffered from session secret key leakage and impersonation attacks
[22]	2019	Hash function, and bilinear pairing.	Vulnerable to ESL and MITM attacks
[23]	2020	Physical Unclonable Function (PUF)	Vulnerable to a DoS attack.
[24]	2021	Fuzzy extractor, ECC, and h(.)	Anonymity and traceability issue; also vulnerable to replay attack
[25]	2021	Bilinear Map and CDHP.	Poor performance and anonymity are also vulnerable to secret key leakage.
[26]	2021	Bilinear Pairing, hash, and XOR	Heavyweight and vulnerable to ESL attack
[27]	2022	PUF, ECC, Hash, and XOR	Vulnerable to a traceability attack and the process incurs high computation costs.
[28]	2023	Hash and concatenation functions	Prone to replay and tracking attacks.
[29]	2023	Symmetric algorithm	Stolen verifier and offline password-guessing attacks
[30]	2024	Blockchain and Identity-based scheme	Third-party evolvement is a path to privileged insider attack
[31]	2024	Fuzzy extractor, ECC, hash, and XOR	Design flaw and MITM attack

Like ECC, many researchers have utilized complex mathematical structures in authentication protocols designed for e-healthcare systems to enhance the efficiency and security of remote user and patient interactions. The issues of data integrity and unauthorized access in healthcare applications can be effectively addressed by these approaches, particularly in environments where private patient data is exchanged. In this context, Ali et al. [32] presented an authentication Technique that utilizes a Sierpinski triangle to enhance the ECC, strengthen the system, and provide security against shoulder surfing and other attacks. Agarwal et al. [33] developed a SHA256-based geometric encryption technique suitable for the secure transmission of both grayscale and color images by utilizing a permutation-combination structure to maintain confusion and diffusion properties. By combining the advantages of the RSA algorithm, homomorphic encryption, and chaotic maps—especially the sine and logistic maps—with the self-similar properties of the ECC [35], Mfungo et al. [35] developed a novel method to enhance image encryption. These schemes, according to [36-37], however, lack balance between accuracy, scalability, and security [32, 34], are susceptible to parallel session, reflection, and hostile attacks [33, 35], bandwidth overload during high authentication demand [32, 34], session key security violations [33, 35], and impersonation attacks [32].

Finally, energy efficiency is also an essential element for IoT-driven e-healthcare systems. In this regard, Rana et al. [38] introduced E2SCEC2, an elliptic curve cryptography-based approach. Their [38] method is especially designed for the secure computation of SK in the resource-constrained IoT and effectively managing the SK through the setup of the session in the Datagram Transport Layer Security. In a different vein, Rehman et al. [39] developed an ECC-based protocol for resource-constrained IoT applications. Their [39] focus was on the energy efficiency of IoT in e-health systems, because it is a resource-constrained system that needs a much smaller amount of energy; otherwise, it will quickly drain the power, and cannot perform well. They also combine AI and homomorphic secret sharing, making it not only suitable for storing medical data on cloud platforms but also ensuring its feasibility and energy efficiency for quick disease detection. Their [39] scheme also provides secure exchange of credentials and prevention of intrusions ot the whole system. Garg et al. [40] presented a privacy-preserving technique for secure key creation and access control that offered resilience to numerous threats, both active and passive, which are ineffective in their scheme. Their [40] protocol significantly enhances the safety of e-healthcare systems by improving secure communication in IoT applications within resource-constrained e-health systems.

3.1 Review Analysis of Krishnasrjia et al. Scheme

Recently, Krishnasrjia et al. [41] proposed a comprehensive scheme based on a Chebyshev polynomial, a one-way hash function, and xor operations. Their scheme, which includes registration, authentication, and transitive authentication phases, is described in detail, ensuring that the reader is fully informed. The symbols they used for designing their protocol are shown in Table 2.

Table 2. Notations of Krishnasrjia et al. Scheme

Symbol	Meaning	Symbol	Meaning
Dn	New Device	Dt	Trusted Device
GW	Gateway	ID	Identity
PW	Password	R	Random number
r	random number	T	Timestamp
style="vertical-align: top;"		Concatenation	h(.)	Hash
⊕	XOR	z*	Random number

1) Registration Phase: The new device chooses identity ID_n password PW_n and selects a random number R, Compute PID=ID_n⊕R, PIN=PW_n⊕T₁ and send {PID, PIN, R, T₁} to GW. The GW checks the timestamp and selects s, x, z randomly, and computes T_s(x)=2xT_s-1(x)-T_s-2(x), z^*=z⊕PID, CK=H(PIN⊕PID)⊕z^*, stores {ID_n, s, x, T_s(x), z} and sends {CK, x, T_s(x), T₂} to the device. The device checks the timestamp and computes z=CK⊕h(PIN⊕PID) ⊕PID, v=z⊕h(ID_n||PW_n) and stores {v, x, T_s(x)}.

2) Authentication Phase: In this phase the device takes r, N and computes T_r(x)=2xT_r-1(x)-T_r-2(x), k_rs=T_r(T_s(x)), z=v⊕h(ID_n||PW_n), v*=h(z⊕T_s(x)), e=(v^*||N) ⊕k_rs, AID=ID_n⊕(T₁) and sends {AID, e, T_r(x), T₁} to GW. The GW checks the timestamp and computes ID_n=AID⊕h(T₁), k_rs=T_s(T_r(x)), e^*=e⊕k_rs=(v^*||N), v^**=h(z⊕T_s(x)), confirm V^**?=V^* and calculates N^*=h(N)⊕k_rs, SK_t=h(k_rs||N) and sends {N^*, T₂} to new device. The device confirms the timestamp, computes N^**=h(N), checks N^**?=N^*, and computes the session key SK_t=h(k_rs||N).

3) Transitive Authentication Phase: This is the third phase of the Krishnasrjia et al. [41] scheme, completed by which the device sends {AID_n, e, T_rn(x_n), T₁} to trusted device (D_t); the trusted device (D_t) sends {AID_t, M_t, T₂} to GW; the GW sends {M_g, T₃} to D_t; the D_t sends {N_p^*, N_g^*, T₄} to D_n, and the D_n keeps SK_gn=h(k_rs||N).

3.2 Cryptanalysis of Krishnasrjia et al. Scheme

After an exhaustive investigation, the Krishnasrjia et al. [41] scheme has meticulously suffered the following vulnerabilities.

1) Replay Attack: This vulnerability, if exploited, can expose internal secrets. If an attacker can intercept the publically transmitted message {AID, e, T_r(x), T₁} from the open network channel, the recurrence relation of Chebyshev polynomials allows an adversary to reconstruct the trajectory from two consecutive values, thereby exposing the secret parameters like T_r(x)=2xT_r-1(x)-T_r-2(x), k_rs=T_r(T_s(x)), z=v⊕h(ID_n||PW_n), v*=h(z⊕T_s(x)), e=(v^*||N) ⊕k_rs, AID=ID_n⊕(T₁). In AID, the identity is transmitted openly, and the attacker can get it and launch a replay attack.

2) DoS Attack: If the attacker gets a time T_A and transmits it with the {AID_n, e, T_rn(x_n), T₁, T_A}, they can easily pass these steps of computations k_rs=T_rn(T_sn(x)), e=(v_n||N) k_rs, AID_n=ID_n⊕h(T₁) and authorized for launching DoS attack quickly on the system.

3) Anonymity Issue: The presence of ID_n in {AID_n, e, T_rn(x_n), T₁} message and ID_t in {AID_t, M_t, T₂} in raw format allows the attacker to efficiently compute these identities from AID_n and AID_t, leading to easy tracing out of each device. This vulnerability significantly compromises the system's anonymity, highlighting the importance of addressing it in Krishnasrjia et al. [41].

4) Authentication Issue: Many steps consist of single-value hashing, like N^**=h(N), N_t^*=h(N_t), N_g^*=h(N), and N_t^*?=h(N_t), which provides an easy way for the attacker to establish their own link with either D_t or D_n or both. These computations also create problems for the mutual authentication of devices. Therefore, Krishnasrjia et al. [41] lack mutual authentication.

3.3 Proposed Network Model

The sensor node, patient device, doctor device, and the gateway are the four components that make up the network model, as shown in Figure 1.

Figure 1. Proposed Network Model

The medical professional/operator wears a wearable device or embeds a sensor/IoT device (PD), which continuously records the patient's physiological vitals or other vital signs, monitors them, and collects valuable data, sending it to the gateway node. These patient-sensitive vitals, received by the gateway node, can be transmitted to the physician device. The physician device (IoT) may formulate a suitable treatment plan for the patient by obtaining pertinent physiological data. The gateway handles data transmission, acting as a middleware between the sensors, wearables/IoT devices, and the physician's mobile device. The gateway also registers each sensor/wearables/ IoT device, and physician's mobile device, with the paramedical staff/doctors.

The gateway registers both the patient and doctor sides of IoT devices, which will then be deployed practically to the e-healthcare system to collect, process, and securely manage patient-sensitive information. It is worth mentioning that due to their limited processing capability, low storage, and resource-constrained nature, IoT devices are designed to manage the computational demands of heavyweight cryptographic operations. However, the proposed protocol utilizes a gateway (GW) to manage the registration, authorization, and authentication processes for sensors/IoT devices at both the patient's and physician's end. The proposed strategy significantly reduces computational and communication overheads, providing scalability and ease in terms of potential resource savings without compromising the security of the entire e-healthcare system.

Moreover, the network model designed has been provided, which indicates the direction of transmitted credentials through an arrow form and finally agrees on a shared session key for future secure communication.

4. Proposed Protocol

This section presents the proposed security protocol for IoT applications based on elliptic curve cryptography (ECC) geometry. The proposed protocol, therefore, consists of two phases: registration and authentication. These phases are described in detail, while the symbols used for the design of the security protocol are listed in Table 3.

Table 3. Notations of the proposed protocol

Symbol	Meaning	Symbol	Meaning
PD	Patient Device/Sensor/IoT	s	Secret number
DD	Doctor Device/	style="vertical-align: top;"		Concatenation
DW	Gateway	h(.)	Hash function
P	Point over curve	Pkey	Public Key
IDsd	Patient device identity	Skey	Secret Key
IDms	Doctor device identity	Tc	Current timestamp
∆	Matching Algorithm	SK	Session Key

4.1 Setup Phase

In this work, first generates a pseudorandom number L, which can be considered the system's secret key. Both the curve points x and y are ECC-based on the Mandelbrot set [16-19], which will be used f-or computing the public key in both the patient registration phase and the authentication phase. Similarly, all the random numbers used in the scheme, namely L₁, L₂, ..., L₇, are generated from practical geometry, thereby maintaining the cross-verification of credential randomness, and each session key differs from both previous and upcoming session keys. This will lead the system to offer perfect forward and backward secrecy.

4.1 Registration Phase

The registration process is divided into two sub-phases: patient registration and doctor registration to ensure the reliability and security of the system, as each step is carefully designed and executed.

1) Patient Registration: The device chooses a point x based on ECC from the curve, calculates the ECC key P_key1=x.P, and selects a random number L_1, whichcalculates A₁=L₁.P_key1, A₂=h(ID_sd||P_key1), A₃=h(A₁||A₂||S_key) and replays {A₁, A₂, A₃} to the gateway through a secure channel. The gateway chooses a random point from the curve y, calculates ECC-key P_key2=y.P, selects a random number L₂, and calculates A₁^*=L₂.P_key2, A₂^*=h(ID_sd||P_key2), A₃^*=h(A₁^*||A₂^*||S_key), confirms A₃^*?=A₃ and stores for record as shown in module 1.

PD GW

Choose: x and select L₁

Compute: P_key1=x.P

A₁=L₁.P_key1

A₂=h(ID_sd||P_key1)

A₃=h(A₁||A₂||S_key)

{A₁, A₂, A₃}

Choose: y and select L₂

Compute: P_key2=y.P

A₁^*=L₂.P_key2

A₂^*=h(ID_sd||P_key2)

A₃^*=h(A₁^*||A₂^*||S_key)

Verify: A₃^*?=A₃

Store: {A₁, A₂, A₃}

Module 1. Patient Registration Phase

2) Doctor Registration: The doctor side device chooses a point from the curve a, calculates ECC-Key P_key3=a.P, selects a random number L₃, and calculates B₁=L₃.P_key3, B₂=h(ID_ms||P_key3), B₃=h(B₁||B₂||S_key) and relays {B₁, B₂, B₃} to the gateway through a secure channel. The gateway chooses another point from curve b, calculates ECC-key P_key4=y.P, selects a random number L₄, and calculates B₁^*=L₄.P_key4, B₂^*=h(ID_ms||P_key4), B₃^*=h(B₁^*||B₂^*||S_key), confirms B₃^*?=B₃ and stores for record, as shown in module 2.

DD GW

Choose: a, and select L₃

Compute: P_key3=a.P

B₁=L₃.P_key3

B₂=h(ID_ms||P_key3)

B₃=h(B₁||B₂||S_key)

{B₁, B₂, B₃}

Choose b, and select L₄

Compute: P_key4=b.P

B₁^*=L₄.P_key4

B₂^*=h(ID_ms||P_key4)

B₃^*=h(B₁^*||B₂^*||S_key)

Verify: B₃^*?=B₃

Store: {B₁, B₂, B₃}

Module 2. Doctor Registration Phase

4.2 Authentication Phase

This phase takes the following computation steps to complete:

Step 01: The patient side device chooses a random number L₅, records time T, calculates X₁=h(L₅||A₃||T), and replays {X₁, T} to the gateway.

Step 02: The gateway, when receiving {X₁, T} message, confirms the timestamp T_c-T≤∆T, and if found within the pre-defined time threshold, the process is succeeded; otherwise, it terminates and is considered for a potential replay attack. For successful confirmation of time, the gateway chooses a random number L₆, includes A₂ and A₃ from the storage, calculates X₂=h(L₆||P_key2), X₃=h(A₂||A₃)||r₆||X₂), record time T, calculates X₄=h(X₃||T) and sends {A₃, P_key2, X₄, T} to the other side device.

Step 03: The doctor side device, upon receiving {A₃, P_key2, X₄, T} message, confirms the timestamp T_c-T≤∆T, and if found within the pre-defined time threshold, the process is succeeded, it terminates and is considered for potential replay attack. For successful confirmation of time, the other-side device chooses a random number L₇, includes B₁, and B₂ form the stored values, calculates X₅=h(L₇||P_key3), X₇=h(B₂||B₃||L₇||X₅), X₄^*=h(X₇||T), confirm X₄^*?=X₄, it doesn't validate, the process is terminated, otherwise compute the session key SK=h(B₂||B₃)||L₆||L₇||h(B₁||T), record time stamp, calculate X₈=h(SK||T) and replays {B₃, P_key3, X₈, T} back to the gateway.

Step 04: The gateway, when receiving {B₃, P_key3, X₈, T} message, confirms the timestamp T_c-T≤∆T, and if found within the pre-defined time threshold, the process is succeeded; otherwise, it terminates and is considered for potential replay attack. For successful confirmation of time, the gateway computes X₉=h(L₆||P_key2), recover B₂^*, B₃^* from its memory and computes X₁₀= h(B₂^*||B₃^*)||L₆||X₉, X₄^**=h(X₉||T), confirms X₄^**?=X₄^*, if validated, compute the session key SK=h(B₂^*||B₃^*||L₆||L₇||h(B₁^*||T), calculates X₁₁=h(SK||T) and replays {B₃^*, P_key2, X₁₁, T} towards the patient device.

Step 05: The patient side device, when receiving {B₃^*, P_key2, X₁₁, T} message, confirms the timestamp T_c-T≤∆T, and if found within the pre-defined time threshold, the process is succeeded, otherwise terminates and is considered for potential replay attack. For successful confirmation of time, the device computes X₁₂=h(L₅||P_key2), recovers B2 and B₃ from its memory, and computes X₁₃= h(B₂^*||B₃^*)||L₅||X₁₂, X₄^***=h(X₁₂||P_key1), confirms X₄^***?=X₄^**, if it doesn't validate, the process is terminated, otherwise compute the session key SK= SK=h(B₂||B₃)||L₆||L₇||h(B₁||T), calculates X₁₄=h(SK||T), matches X₈, X₁₁ and X₁₄, if succeeded, key SK as session secret key, as shown in module 3.

PD GW DD

Step 01: Chooses L₅ and record T

Compute: X₁=h(L₅||A₃||T)

{X₁, T}

Step 02: Confirm: T_c-T≤∆T

Choose: L₆, extract: A₂ and A₃, and record: T

Compute: X₂=h(L₆||P_key2)

X₃=h(A₂||A₃)||r₆||X₂)

X₄=h(X₃||T) {A₃, P_key2, X₄, T}

Step 03: Confirm: T_c-T≤∆T

Choose: L₇, extract: B₁, B₂, and record: T

Compute: X₅=h(L₇||P_key3)

X₇=h(B₂||B₃||L₇||X₅)

X₄^*=h(X₇||T)

Verify: X₄^*?=X₄

Compute: SK=h(B₂||B₃)||L₆||L₇||h(B₁||T)

X₈=h(SK||T)

{B₃, P_key3, X₈, T}

Step 04: Confirm: T_c-T≤∆T

Computes X₉=h(L₆||P_key2)

Recover: B₂^*, B₃^*

Computes X₁₀= h(B₂^*||B₃^*)||L₆||X₉)

X₄^**=h(X₉||T) and Verify: X₄^**?=X₄^*

Compute: SK=h(B₂^*||B₃^*||L₆||L₇||h(B₁^*||T)

X₁₁=h(SK||T)

{B₃^*, P_key2, X₁₁, T}

Step 05: Confirm: T_c-T≤∆T

Compute: X₁₂=h(L₅||P_key2)

Recover: B₂, B₃

Computes X₁₃= h(B₂^*||B₃^*)||L₅||X₁₂)

X₄^***=h(X₁₂||P_key1), and Verify: X₄^***?=X₄^**

Compute: SK=h(B₂||B₃)||L₆||L₇||h(B₁||T)

X₁₄=h(SK||T)

Match: X₈, X₁₁ and X₁₄

Module 3. Authentication Phase

5 Security Analysis

In this section of the article, the proposed key agreement scheme can be analyzed by considering formal security analysis and informal security analysis. These analyses are described one by one as follows:

5.1 BAN Logic Analysis

BAN logic used by [21], [22], [27], and [29] can be used for informal analysis of the proposed protocol and can thoroughly be discussed for numerous potential attacks. It is based on trust, correctness, and belief in discovering any weak points in the protocol (if they exist). This logic of correctness consisted of notations, statements, rules, and definitions, which are defined in Table 4, while the BAN rules include:

Table 4. BAN Logic Notations

Notations	Pronounced as	Description
style="border-top: 1pt solid black;"	⇒	Jurisdiction	A |⇒ B can be expressed as A has complete Jurisdiction over B
≡	Believes	≡ B can be expressed as A believes in B
#	Fresh	#X can be expressed as X is fresh
⊲	Sees	A ⊲ B can be expressed as A sees B
~	Once Said	~ B can be expressed as A Once Said B
< . >	Combines	<A, B> can be expressed as A and B are combined
${\displaystyle {\quad \,\,K\quad \quad }}$	Communicates	A ${\textstyle {\quad \,\,K\quad \quad }}$B can be expressed as the communication between A and B is performed via key K.

1) Message Meaning Rule – ${\textstyle \left({\frac {A\,\vert \equiv \,A\,{\quad \,\,K\quad \,\,}\,B,\,\vartriangleleft \lbrace M\rbrace \,}{A\,\vert \equiv \,B\,\vert \sim \,M}}\right)}$

2) Message Integrity Rule – ${\textstyle \left({\frac {A\,\vert \equiv \,\#(M),B\,\vert \sim \,M}{\,A\,\vert \equiv \,B\,\vert \equiv \,M}}\right)}$

3) Jurisdictional Rule – ${\textstyle \left({\frac {A\,\vert \equiv \,B\,\vert \Rightarrow \,\left(M\right),\,A\,\vert \equiv \,B\,\vert \equiv \,M}{B\,\vert \equiv \,M}}\right)}$

4) Session Key Rule – ${\textstyle \left({\frac {A\,\vert \equiv \,\#\,(M),\,A\,\vert \equiv \,B\,\vert \equiv \,M}{A\,\vert \equiv \,A{\quad \,\,SK\quad \,\,}\,B}}\right)}$

5) Goals – The BAN logic goals defined are as under

The patient side IoT device believes the transmission of message between patient side IoT device and gateway over a public channel.

G1: ${\textstyle PD\vert \equiv \left(PD{\quad \quad \quad \,\,{\lbrace X}_{1},\,T\,\rbrace \quad \quad \quad }\,GW\right)}$

The gateway believes the transmission of message between patient side IoT device and gateway over a public channel.

G2: ${\textstyle \,GW\,\vert \equiv \left(PD{\quad \quad \quad \,\,{\lbrace X}_{1},\,T\,\rbrace \quad \quad \quad }\,GW\right)}$

Both patient side IoT device and gateway believes the transmission of message between patient side IoT device and gateway over a public channel.

G3: ${\textstyle PD\vert \equiv GW\vert \equiv \left(PD{\quad \quad \quad \,\,{\lbrace X}_{1},\,T\,\rbrace \quad \quad \quad }\,GW\right)}$

Now, the gateway believes the message transmission between gateway and physician side IoT device over a public network channel.

G4: ${\textstyle GW\vert \equiv \left(GW{\quad \quad \quad \,\,{\lbrace A}_{3},\,{P}_{key2},\,{X}_{4},\,\,T\,\rbrace \quad \quad \quad }\,DD\right)}$

The doctor side IoT device believes the message transmission between gateway and physician side IoT device over a public network channel.

G5: ${\textstyle DD\vert \equiv \left(GW{\quad \quad \quad \,\,{\lbrace A}_{3},\,{P}_{key2},\,{X}_{4},\,\,T\,\rbrace \quad \quad \quad }\,DD\right)}$

Bothe the gateway and doctor side IoT device believes the message transmission between gateway and physician side IoT device over a public network channel.

G6: ${\textstyle GW\vert \equiv DD\vert \equiv \left(GW{\quad \quad \quad \,\,{\lbrace A}_{3},\,{P}_{key2},\,{X}_{4},\,\,T\,\rbrace \quad \quad \quad }\,DD\right)}$

Similarly, the doctor side IoT device believes the message transmission between doctor side IoT device and gateway over an insecure channel.

G7: ${\textstyle DD\vert \equiv \left(DD{\quad \quad \quad \,\,{\lbrace B}_{3},\,{P}_{key3},\,{X}_{8},\,\,T\,\rbrace \quad \quad \quad }\,GW\right)}$

The gateway believes the message transmission between doctor side IoT device and gateway over an insecure channel.

G8: ${\textstyle GW\vert \equiv \left(DD{\quad \quad \quad \,\,{\lbrace B}_{3},\,{P}_{key3},\,{X}_{8},\,\,T\,\rbrace \quad \quad \quad }\,GW\right)}$

Both the doctor side IoT device and gateway believes the message transmission between doctor side IoT device and gateway over an insecure channel.

G9: ${\textstyle DD\vert \equiv GW\vert \equiv \left(DD{\quad \quad \quad \,{\lbrace B}_{3},\,{P}_{key3},\,{X}_{8},\,\,T\,\rbrace \quad \quad \quad }\,GW\right)}$

Finally, the gateway believes the message transmission between gateway and patient side IoT device over an open channel.

G10: ${\textstyle GW\vert \equiv \left(GW{\quad \quad \quad \,\,\lbrace {B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,\,T\,\rbrace \quad \quad \quad }\,PD\right)}$

The patient side IoT device believes the message transmission between gateway and patient side IoT device over an open channel.

G11: ${\textstyle PD\vert \equiv \left(GW{\quad \quad \quad \,\,\lbrace {B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,\,T\,\rbrace \quad \quad \quad }\,PD\right)}$

Both the gateway and patient side IoT device believes the message transmission between gateway and patient side IoT device over an open channel.

G12: ${\textstyle GW\vert \equiv PD\vert \equiv \left(GW{\quad \quad \quad \,\,\lbrace {B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,\,T\,\rbrace \quad \quad \quad }\,PD\right)}$

6) Idealization – The idealization form of the prosed ECC-based protocol are as under:

The patient side IoT devices sends {X₁, T} message towards the gateway over an open network channel as represented as I1.

I1: ${\textstyle PD\rightarrow GW:\,<{X}_{1},\,T>}$

The gateway sends {A₃, P_key2, X₄, T} message towards the physician side IoT device over an open network channel as represented as I2.

I2: ${\textstyle GW\rightarrow DD:<{A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,>}$

The physician side IoT device sends {B₃, P_key3, X₈, T} message towards the gateway over an open network channel as represented as I3.

I3: ${\textstyle DD\rightarrow GW:<{B}_{3},\,{P}_{key3},\,{X}_{8},\,T>\,}$

The gateway sends {B₃^*, P_key2, X₁₁, T} message towards the patient side IoT device over an open network channel as represented as I4.

I4: ${\textstyle GW\rightarrow PD:<{B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T>}$

7) Assumptions – The different assumptions for the proposed protocol are as under:

The patient side IoT device believes the freshness of L₅ and T.

A1: ${\textstyle PD\vert \equiv \,\#\left({L}_{5}\right)}$ ${\textstyle PD\vert \equiv \,\#\left(T\right)}$

The gateway believes on the freshness of L₆ and T.

A2: ${\textstyle GW\vert \equiv \,\#\left({L}_{6}\right)}$ ${\textstyle GW\vert \equiv \,\#\left(T\right)}$

The physician side IoT device believes on the freshness of L₇ and T.

A3: ${\textstyle DD\vert \equiv \,\#\left({L}_{7}\right)}$ ${\textstyle DD\vert \equiv \,\#\left(T\right)}$

The patient side IoT device believes the transmission of ECC key between gateway and patient side device over a public channel securely.

A4: ${\textstyle PD\vert \equiv \left(GW{\quad \quad \quad \quad \quad \,\,{P}_{key2}\quad \quad \quad \quad \quad \,\,}\,PD\right)}$

The gateway believes the transmission of ECC key between gateway and patient side device over a public channel securely.

A5: ${\textstyle GW\vert \equiv \left(GW{\quad \quad \quad \quad \quad \,\,{P}_{key2}\quad \quad \quad \quad \quad \,\,}\,PD\right)}$

The gateway believes the transmission of ECC key between gateway and physician side device over a public channel securely.

A6: ${\textstyle GW\vert \equiv \left(GW{\quad \quad \quad \quad \quad \,\,{P}_{key2}\quad \quad \quad \quad \quad \,\,}\,DD\right)}$

The physician side IoT device believes the transmission of ECC key between gateway and physician side IoT device over a public channel securely.

A7: ${\textstyle DD\vert \equiv \left(GW{\quad \quad \quad \quad \quad \,\,{P}_{key2}\quad \quad \quad \quad \quad \,\,}\,DD\right)}$

The physician side IoT device believes the transmission of ECC key between physician side IoT device and gateway over a public channel securely.

A8: ${\textstyle DD\vert \equiv \left(DD{\quad \quad \quad \quad \quad \,\,{P}_{key3}\quad \quad \quad \quad \quad \,\,}\,GW\right)}$

The gateway believes the transmission of ECC key between physician side IoT device and gateway over a public channel securely.

A9: ${\textstyle GW\vert \equiv \left(DD{\quad \quad \quad \quad \quad \,\,{P}_{key3}\quad \quad \quad \quad \quad \,\,}\,GW\right)}$

The patient side IoT device believes the freshness of X₄^***, X₄, and sees X₁₁

A10: ${\textstyle PD\vert \equiv \,\#\left({X}_{4}^{\ast \ast \ast }\right)}$ , ${\textstyle PD\vert \equiv \,\#\left({X}_{4}\right)}$ , and ${\textstyle PD\vartriangleleft \,\left({X}_{11}\right)}$

The gateway believes the freshness of X₄^**, Sees X₈ and X₁₄

A11: ${\textstyle GW\vert \equiv \,\#\left({X}_{4}^{\ast \ast }\right)}$ , ${\textstyle GW\vartriangleleft \,\left({X}_{8}\right)}$ , and ${\textstyle GW\vartriangleleft \,\left({X}_{14}\right)}$

The doctor side IoT believes the freshness of X₄^*, and sees X₁₁

A12: ${\textstyle DD\vert \equiv \,\#\left({X}_{4}^{\ast }\right)}$ , and ${\textstyle DD\vartriangleleft \,\left({X}_{11}\right)}$

9) Proof – The proof of the scheme using BAN logic is as under:

The idealized form I1-to-I4 and the assumptions from A1 to A12 will be used to achieve the different goals defined in section e above, so let suppose I1 and A1, we get

${\textstyle PD\rightarrow GW:\,<{X}_{1},\,T>:\,\#\left({L}_{5}\right)}$

(1)

${\textstyle PD\rightarrow GW:\,<{X}_{1},\,T>:\,\#\left(T\right)}$

(2)

Eq: (1) and (2) can also be written as

${\textstyle PD\rightarrow <{X}_{1},\,T>:\,\#\left({L}_{5}\right)}$

(3)

${\textstyle PD\rightarrow \#\left({L}_{5}\right)}$

(4)

${\textstyle PD\vert \equiv \#\left({L}_{5}\right)}$

(5)

Eq: (5) and A13, the following result will be obtained

${\textstyle \left({L}_{5}\right)=\left({X}_{4}\right)}$

(6)

${\textstyle \left({L}_{5}\right)=\left({X}_{4}^{\ast \ast \ast }\right)}$

(7)

A4 and Eq: (6) and (7) can be written as

${\textstyle PD\vert \equiv \left(GW{\quad \quad \quad \quad \quad \,\,{P}_{key2}\quad \quad \quad \quad \quad \,\,}\,PD\right)}$

(8)

It means

${\textstyle PD\vert \equiv {P}_{key2}}$

(9)

${\textstyle GW\vert \equiv {P}_{key2}}$

(10)

Eq: (9) and (10) can be written as

${\textstyle PD\vert \equiv {GW\vert \equiv P}_{key2}}$

(11)

Eq: (3), (11), A4 and A5, the following result will be obtained

${\textstyle PD\vert \equiv {GW\vert \equiv P}_{key2}:<{X}_{1},\,T>:\left(GW{\quad \,{P}_{key2}\,}\,PD\right)}$

(12)

Eq: (12) can be written as

${\textstyle PD\left|\equiv GW\right|\equiv :<{X}_{1},\,T>:\left(GW{\quad \quad \,{P}_{key2}\quad \quad }\,PD\right)}$

(13)

Eq: (13), becomes

${\textstyle PD\left|\equiv GW\right|\equiv \left(GW{\quad \quad \quad \quad \quad \quad {\lbrace X}_{1},\,T\,\rbrace \quad \quad \quad \quad \quad \,\,}\,PD\right)}$

(14)

Eq: (14) can be written as

${\textstyle GW\left|\equiv PD\right|\equiv \left(GW{\quad \quad \quad \quad \quad \quad {\lbrace X}_{1},\,T\,\rbrace \quad \quad \quad \quad \quad \,\,}\,PD\right)}$

(15)

${\textstyle PD\left|\equiv GW\right|\equiv \left(PD{\quad \quad {\lbrace X}_{1},\,T\,\rbrace \quad \,\,}GW\right)}$ G3-Achieved

Taking eq: (13), (14), and I1, the following result will be achieved

${\textstyle GW\vert \equiv :<{X}_{1},\,T>:\left(GW{\quad \quad \quad {P}_{key2}\quad \quad \,}\,PD\right)}$

(16)

Eq: (16), becomes

${\textstyle GW\vert \equiv \left(GW{\quad \quad \quad \quad \quad \quad {\lbrace X}_{1},\,T\,\rbrace \quad \quad \quad \quad \quad \,}\,PD\right)}$

(17)

${\textstyle GW\vert \equiv \left(PD{\quad \,\,{\lbrace X}_{1},\,T\,\rbrace \quad \,\,}\,GW\right)}$ G2-Achieved

Eq: (13), (14) and I2, the following result will be obtained

${\textstyle PD\vert \equiv :<{X}_{1},\,T>:\left(GW{\quad \,{P}_{key2}\quad \,\,}\,PD\right)}$

(18)

Eq: (18) becomes

${\textstyle PD\vert \equiv \left(GW{\quad \quad \quad \quad \quad \quad {\lbrace X}_{1},\,T\,\rbrace \quad \quad \quad \quad \quad \,}\,PD\right)}$

(19)

${\textstyle PD\vert \equiv \left(PD{\quad \quad \quad {\lbrace X}_{1},\,T\,\rbrace \quad \quad }\,GW\right)}$ G1-Achieved

Suppose I2 and A2, the following result will be obtained.

${\textstyle GW\rightarrow DD:\,:<{A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,>:\,\#\left({L}_{6}\right)}$

(20)

${\textstyle GW\vert \equiv GW\rightarrow DD:\,:<{A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,>:\,\#\left({L}_{6}\right)}$

(21)

Eq: (21) and A7, the following result will be obtained

${\textstyle GW\vert \equiv DD\vert \equiv :<{A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,>:\left(GW{\,\,{P}_{key2}\quad }\,DD\right)}$

(22)

Eq: (22), becomes

${\textstyle GW\left|\equiv DD\right|\equiv \lbrace {A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,\rbrace :\left(GW{\quad \,{P}_{key2}\quad }\,DD\right)}$

(23)

Eq: (23) and (10), the following result will be achieved

${\textstyle GW\left|\equiv DD\right|\equiv \left(GW{\quad \quad \quad \quad \quad \,\,{P}_{key2}\quad \quad \quad \quad \quad \,\,}\,DD\right)}$

(24)

Eq: (24) can also be written as

${\textstyle GW\left|\equiv DD\right|\equiv \left(GW{\quad \,\,{\lbrace A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,\rbrace \,\,}\,DD\right)}$ G6-Achieved

Eq: (21), (24), A5 and A6, the following result will be obtained

${\textstyle DD\vert \equiv {GW\vert \equiv P}_{key3}:\left(GW{\quad {P}_{key2}\quad \,}\,DD\right)}$

(25)

Eq: (25) can be written as

${\textstyle {DD\vert \equiv P}_{key3}:\left(GW{\quad \,{P}_{key2}\quad \,\,}\,DD\right)}$

(26)

Eq: (25) and G6, the following result will be obtained

${\textstyle DD\vert \equiv \left(GW{\quad {\lbrace A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,\rbrace \quad }\,DD\right)}$ G5-Achieved

Eq: (22), (23), A6 and A7, the result obtained as given as under

${\textstyle DD\vert \equiv {GW\vert \equiv P}_{key3}:\left(GW{\quad \,{P}_{key2}\quad }\,DD\right)}$

(27)

Eq: (27) can be written as

${\textstyle {GW\vert \equiv P}_{key3}:\left(GW{\quad \,\,{P}_{key2}\quad \quad }\,DD\right)}$

(28)

Eq: (28) and Goal 5, the result obtained as

${\textstyle {GW\vert \equiv P}_{key3}:\left(GW{\quad {\lbrace A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,\rbrace \quad \,\,}\,DD\right)}$

(29)

Eq: (29) becomes

${\textstyle GW\vert \equiv \left(GW{\quad \quad {\lbrace A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,\rbrace \quad \,\,}\,DD\right)}$ G4-Achieved

Suppose I3 and A3, the following result will be obtained.

${\textstyle DD\rightarrow GW:<{B}_{3},\,{P}_{key3},\,{X}_{8},\,T>\,:\,\#\left({L}_{7}\right)}$

(30)

${\textstyle DD\vert \equiv :\,DD\rightarrow GW:<{B}_{3},\,{P}_{key3},\,{X}_{8},\,T>\,:\,\#\left({L}_{7}\right)}$

(31)

Eq: (31) and A8, the following result will be obtained

${\textstyle DD\vert \equiv GW\vert \equiv :<{A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,>:\,\#\left({L}_{6}\right):\left(GW{\,{P}_{key2}\,\,}\,DD\right)}$

(32)

Eq: (32), becomes

${\textstyle GW\left|\equiv DD\right|\equiv \,\#\left({L}_{7}\right):\left(DD{\quad \,{P}_{key3}\quad \,}\,GW\right)}$

(33)

Eq: (33) and (26), the following result will be achieved

${\textstyle GW\left|\equiv DD\right|\equiv \left(DD{\quad \quad {P}_{key3}\quad \,}\,GW\right)}$

(34)

Eq: (34) can also be written as

${\textstyle DD\left|\equiv GW\right|\equiv \left(DD{\,\,\lbrace {B}_{3},\,{P}_{key3},\,{X}_{8},\,T\,\rbrace \quad }\,DD\right)}$ G9-Achieved

Eq: (31), (34), A7 and A8, the following result will be obtained

${\textstyle GW\vert \equiv {DD\vert \equiv P}_{key3}::\left(DD{\quad {P}_{key2}\quad }\,GW\right)}$

(35)

Eq: (35) can be written as

${\textstyle {GW\vert \equiv P}_{key3}::\left(DD{\quad \,{P}_{key3}\quad \quad }\,GW\right)}$

(36)

Eq: (35) and G9, the following result will be obtained

${\textstyle GW\vert \equiv \left(DD{\quad \lbrace {B}_{3},\,{P}_{key3},\,{X}_{8},\,T\,\rbrace \quad }\,GW\right)}$ G8-Achieved

Eq: (32), (33), A8 and A9, the result obtained as given as under

${\textstyle DD\vert \equiv {GW\vert \equiv P}_{key3}::\left(DD{\quad \quad {P}_{key3}\quad \,}\,GW\right)}$

(37)

Eq: (37) can be written as

${\textstyle {DD\vert \equiv P}_{key3}::\left(DD{\quad \,{P}_{key3}\quad }\,GW\right)}$

(38)

Eq: (38) and Goal 8, the result obtained as

${\textstyle {DD\vert \equiv P}_{key3}:\left(DD{\,\,{\lbrace A}_{3},\,{P}_{key2},\,{X}_{4},\,T\,\rbrace \,}\,GW\right)}$

(39)

Eq: (39) becomes

${\textstyle DD\vert \equiv \left(GW{\,\lbrace {B}_{3},\,{P}_{key3},\,{X}_{8},\,T\,\rbrace \quad }\,DD\right)}$ G7-Achieved

Suppose I4 and A4, the following result will be obtained.

${\textstyle GW\rightarrow PD:\,\,PD\vert \equiv \left(GW{\quad \,\,{P}_{key2}\quad \,}\,PD\right)}$

(40)

Eq: (40) becomes

${\textstyle <{B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T>:PD\vert \equiv \left(GW{\,\,{P}_{key2}\,}\,PD\right)}$

(41)

Eq: (41), becomes

${\textstyle PD\vert \equiv \left(GW{\quad {P}_{key2}\quad \,}\,PD\right):<{B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T>}$

(42)

Eq: (42), becomes

${\textstyle PD\vert \equiv \left(GW{\quad {\lbrace B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T\rbrace \,\,}\,PD\right)}$ G11-Achieved

Now, going back to I4 A5, the following result will be achieved

${\textstyle GW\rightarrow PD:\,\,GW\vert \equiv \left(GW{\quad {P}_{key2}\quad }\,PD\right)}$

(43)

Eq: (40) becomes

${\textstyle <{B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T>:GW\vert \equiv \left(GW{\quad \,{P}_{key2}\quad }\,PD\right)}$

(44)

Eq: (41), becomes

${\textstyle GW\vert \equiv \left(GW{\quad {P}_{key2}\quad }\,PD\right):<{B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T>}$

(45)

Eq: (42), becomes

${\textstyle GW\vert \equiv \left(GW{\quad {\lbrace B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T\rbrace \,\,}\,PD\right)}$ G10-Achieved

Eq: (41) and (42), the result obtained as

${\textstyle PD\vert \equiv \left(GW{\quad {\lbrace B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T\rbrace \,\,}\,PD\right)}$

(46)

Eq: (44) and (45), the result obtained as

${\textstyle GW\vert \equiv \left(GW{\quad {\lbrace B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T\rbrace \quad }\,PD\right)}$

(47)

Combine Eq: (46) and (47), the result obtained as

${\textstyle PD\vert \equiv GW\vert \equiv \left(GW{\quad {\lbrace B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T\rbrace \,}\,PD\right)}$

(48)

Eq: (48) can be written as

${\textstyle GW\vert \equiv PD\vert \equiv \left(GW{\,\,{\lbrace B}_{3}^{\ast },\,{P}_{key2},\,{X}_{11},\,T\rbrace \,\,}\,PD\right)}$ G12-Achieved

The analysis through BAN logic tells us what types of weaknesses exist in the security protocol and how it could be disastrous and have consequences for the system. The necessity of this formal validation process underscores the importance of the audience's role in ensuring the system's security. The analysis shows these steps in multiple logical forms above (eq: 1-to-48).

5.2 ProVerif Simulation

A software verification toolkit used by [17], [18], [19], and [20]to verify the integrity of the secret session key. In this toolkit, we define two channels, i.e., secure and public, and declare all variables, constants, constraints, functions, queries, and equations. We then code all the computation steps for the patient side IoT device, Gateway side, and physician side IoT device and process them. When the verification is successful, it's a clear indication that the SK is secure, resists MITM attacks, and is verified for reachability. This reassures us of the security benefits of the verification process. The results generated are shown in Figure 2.

---

Verification summary:

Query not attacker(SK1[]) is true.

Query not attacker(SK2[]) is true.

Query not attacker(SK3[]) is true.

Query inj-event(end_PD(IDsd[])) ==> inj-event (start_PD(IDsd[])) is true.

Query inj-event(end_GW(IDgw[])) ==> inj-event (start_GW(IDgw[])) is true.

Query inj-event(end_DD(IDms[])) ==> inj-event(start_DD(IDms[])) is true.

---

Figure 2. ProVerif Simulation

5.3 AVISPA Validation

AVISPA (Automated Validation of Internet Security Protocols and Applications) is a push-button tool for automatically validating the sensitivity of security protocol working in distributed system using Internet used by [20], [23], [26] and [41]. It incorporates many back-ends that perform a range of cutting-edge automatic analysis techniques and offers a modular and expressive formal language for defining protocols and their security features. Suppose a protocol runs successfully over this toolkit. In that case, it provides outstanding performance and ensures scalability, adapting to the needs of different scenarios and having the same degree of resilience and scope. Therefore, considering the successful validation of the proposed protocol through AVISPA, as shown in Figure 3, it's important to highlight its robustness. The protocol has demonstrated resistance to insider, man-in-the-middle, replay, and DoS attacks, which is a significant achievement in the field of cybersecurity.

---

SUMMARY

SAFE

DETAILS

BOUNDED_NUMBER_OF_SESSIONS

TYPED_MODEL

PROTOCOL

/path/to/authentication_scheme.hlpsl

BACKEND

OFMC

CL-AtSe

COMMENTS

The protocol appears to satisfy the specified security properties

No attacks were found within the bounded session model

---

Figure 3. AVISPA Validation

5.4 Informal Analysis

In the informal analysis section, the proposed scheme can be discussed pragmatically via different attacks and other security features. These are explained one by one as follows:

1) Replay Attack: Due to timestamp verification before going to the next step, 160-bit ECC keys can strictly prohibit the attacker from launching a replay attack. Suppose an attacker copies {X₁, T} from the communication line and replay some other time, he/she has to pass from T_c-T≤∆T and verifies X₄^*?=X₄ whereas X^4*=h(X₇||T), X₇=h(B₂||B₃||L₇||X₅) and X₅=h(L₇||P_key3). Further, the attacker has to verifies X₄^***?=X₄^* whereas X₄^***=h(X₉||T), X₁₀= h(B₂^*||B₃^*)||L₆||X₉), and X₉=h(L₆||P_key2) These complex computation steps are not possible for an adversary to accomplish. Therefore, the proposed protocol is resisting a replay attack.

2) DoS Attack: The proposed key agreement scheme, with its timestamp verification and multiple checks in different protocol round trips, stands as a reliable defense against DoS attacks, ensuring uninterrupted communication. Suppose the adversary captures {X₁, T}, {A₃, P_key2, X₄, T}, {B₃, P_key3, X₈, T}, and {B₃^*, P_key2, X₁₁, T} from the communication line and tries to find something useful for launching other types of attacks and denies the services of the system for the patient or physician. The adversary has to confirm timestamp checks T_c-T≤∆T in each round trip of the protocol, and verifies X₄^*?=X₄, X₄^*?=X₄, and X₄^***?=X₄ which is impossible to do. Therefore, the proposed protocol is strongly resisting a DoS attack.

3) Impersonation Attack: The scheme's use of SHA-256 and ECC techniques effectively hides the publically transmitted credentials i.e., first message {X₁, T} whereas X₁= h(L₅||A₃||T), second message {A₃, P_key2, X₄, T}, whereas X₄=h(X₃||T) and X₃=h(A₂||A₃)||r₆||X₂), third message {B₃, P_key3, X₈, T} whereas X₈=h(SK||T) and SK=h(B₂||B₃)||L₆||L₇||h(B₁||T), fourth message {B₃^*, P_key2, X₁₁, T} whereas X₁₁=h(SK||T) and SK=h(B₂^*||B₃^*||L₆||L₇||h(B₁^*||T) and those stored in the registration phase like {A₁, A₂, B₁, B₂}, B₂^* and B₃^* making it impossible for an attacker to glean any useful information, thereby preventing impersonation attacks.

4) Perfect Forward Secrecy: If an attacker gets the 160-ECC keys P_key1, P_key2, or P_key3 and starts computing the session key SK=h(B₂||B₃)||L₆||L₇||h(B₁||T), they have to confirm the timestamp T_c-T≤∆T, other random checks X₄^*?=X₄, X₄^**?=X₄, and X₄^***?=X₄, hash images, and other keys L₁, L₃, L₅ and L₇ , which is absolutely impossible. They also have to compute X₉=h(L₆||P_key2), X₁₀= h(B₂^*||B₃^*)||L₆||X₉), and X₁₃= h(B₂^*||B₃^*)||L₅||X₁₂), which is also not possible to calculate. So, the proposed protocol offers PFS (perfect forward secrecy). In simple works, if an adversary tries to find out the ECC key and struggle for session secret key which is consisted of random numbers, secret keys, timestamp and other tightly bound credentials, he will never succeeded.

5) Perfect Backward Secrecy: If an attacker gets the session key and desires to reach the login credentials by reverse engineering or power analysis, they have to find B₃, B₄, L₆, L₇, ECC-keys P_key1, P_key2, and P_key3, and other long-term secret keys L₁, L₃, L₅ and L₇, which is absolutely impossible. In simple words, the adversary if copies the previous session key and desires to found something for reaching back to the initial steps, they will never succeeded because, the SK SK=h(B₂||B₃)||L₆||L₇||h(B₁||T) consisted of timestamp, public keys, secret keys, and other associated parameters. So, the proposed key agreement scheme offers PBS (perfect backward secrecy).

6) Anonymity: The proposed scheme consisted of timestamps at each round trip, a 160-bit ECC keys P_key1, P_key2, and P_key3, and SHA-256of size 256-bit hash images h(B₂^*||B₃^*||L₆||L₇||h(B₁^*||T), h(L₅||P_key2), h(B₂^*||B₃^*)||L₅||X₁₂), h(L₇||P_key3), h(B₂||B₃||L₇||X₅), h(L₆||P_key2), h(A₂||A₃)||r₆||X₂), and h(X₃||T). Similarly, all the publically transmitted credentials like {A₃, P_key2, X₄, T}, {B₃, P_key3, X₈, T}, and {B₃^*, P_key2, X₁₁, T} are not in raw format; these are strongly concealed with the SHA-256technique. So, if an attacker attempts to find out anything from the publically transmitted messages like {A₃, P_key2, X₄, T}, {B₃, P_key3, X₈, T}, and {B₃^*, P_key2, X₁₁, T}, and passed through many random checks at each round trip T_c-T≤∆T, other random checks X₄^*?=X₄, X₄^**?=X₄, and X₄^***?=X₄, they cannot succeed, so the proposed protocol offers a user anonymity secure feature.

7) Resists a Man-in-the-Middle Attack: The attacker cannot fabricate a valid patient or physician or gateway as they cannot construct the login message to start their own session with any authentic participant due to the availability of long-term secret keys L₁, L₃, L₅ and L₇, ECC-keys P_key1, P_key2, and P_key3 many random checks at each round trip T_c-T≤∆T, X₄^*?=X₄, X₄^**?=X₄, and X₄^***?=X₄. This indicates that this scheme is resistant to an adversary in launching an MITM attack.

8) ESL Attack: To access the session key, an attacker must obtain the ephemeral secrets L₅, L₆, and L₇. Assuming that A can first acquire each of these parameters, we next require three more parameters B₁, B₂, B₃ with ID_sd and ID_ms, which are unavailable over a public channel. This indicates that the proposed protocol withstands the ephemeral secret leakage (ESL) attack.

9) Insider & Hash Collision Threats: In the proposed protocol, registration is accomplished in offline mode, while all credentials are stored as salted hashes, utilizing a 160-bit long key generated from ECC, along with a 192-bit secret key. As encryption is performed using a public key (160 bits) and decryption is performed using a secret key (192 bits), an attacker couldn't succeed. Similarly, the hash function is uni-directional. We have used SHA-256. Suppose an attacker finds the hash image inside the memory of a gateway and tries to launch a hash collision attack. In that case, he cannot generate a hash image identical to the available one, because the protocol includes an indistinguishability feature. Additionally, since an attacker doesn't know the secret key to open it, if they gain control of the channel and enter the gateway for malicious purposes, they cannot succeed in launching an insider attack or hash collision attacks on the system.

10) Session Key Secrecy: If an attacker gets the session key and desires to reach the login credential L₅, A₃ by reverse engineering or power analysis, they have to find  B₂, B₃, L₆, L₇, and other long-term secret keys L₁, L₃, L₅ and L₇, which is absolutely impossible. So, in the proposed protocol, the session key SK=h(B₂||B₃)||L₆||L₇||h(B₁||T) doesn’t indicate anything about the upcoming session login details because the current session is entirely different from the previous session due to dynamic credentials.

5.5 RoM Analysis

Let G = {G₁, G₂, …………., G_n} denote a set of actors in the proposed scheme P, and each actor has i events of interaction in various forms for simultaneous iteration of P, where i and n are random numbers generated through ECC. Then ${\textstyle {\prod }_{i,\,j}^{T}}$ denotes the T^th session of P executed among G_i and G_j. ${\textstyle {\prod }_{i,\,j}^{T}}$ is in an accepted state if and only if it generates the SK for messages Mi and M_j, identities ID_sd and ID_ms, which Gi transmits between DD and PD. According to the Random Oracle Model [42], suppose adversary Ᾱ has complete control over the public network channel, knowing the P_key and SK but not s; then, Ᾱ runs the following queries to obtain SK.

• Reveal( ${\textstyle {\prod }_{i,\,j}^{T}}$): In this query, the adversary gets some secret r from G_i.

• Replace(ID_sd): In this query, the adversary Ᾱ replaces the public key P_key for G_i.

• Reveal( ${\textstyle {\prod }_{i,\,j}^{T}}$): The Ᾱ sends a tuple to P and receives some output. Due to computational Diffie-Hellman, he still has to confirm whether the output is either SK or not. To do so, Ᾱ flips a coin. If he gets 1, he obtains SK; if he obtains 0, ⊥he obtains nothing.

• Send( ${\textstyle {\prod }_{i,\,j}^{T}}$, M): Here, the Ᾱ sends some random tuple, and the result obtained is stored.

• Test( ${\textstyle {\prod }_{i,\,j}^{T}}$): In this query, the Ᾱ simulates the indistinguishability among the result of Ᾱ and actual SK; again if found fresh, but still the Ᾱ cannot claim that the out they get is SK due to CDHP, Ᾱ flips a coin, if get 1, obtained SK, 0-failed, ⊥- nothing.

• Freshness: If ${\textstyle {\prod }_{i,\,j}^{T}}$ for H_i is equal to ${\textstyle {\prod }_{j,\,i,\,}^{U}}$then they are accurate peer; however, still these peers have to qualify that Reveal( ${\textstyle {\prod }_{i,\,j}^{T}}$) query ok among them, ${\textstyle {\prod }_{i,\,j}^{T}}$ is matched with ${\textstyle {\prod }_{j,\,i}^{T}}$ means from one side the SK generated must match with the SK generated from the other side. And finally, the running query for polynomial integers will never be negligible, due to the use of CDHP.

• Semantic Security: If Ᾱ runs the test(.) query, the chances get real SK is shown in eq (49)

${\textstyle {D}_{A}^{P}=\left|2P\left[{W}_{0}\right]-1\right|}$

(49)

Suppose q_H, q_S, and q_E are the hash, send, and execute queries, k₁ is the hash length, k₂ is a tuple, and k₃ is the public key. The win chance with Ᾱ is shown in eq (50)

${\textstyle {D}_{A}^{P}=\left|2P\left[{W}_{1}\right]-1\right|}$

(50)

Ᾱ is struggling to launch a hash collision attack; the win chance with Ᾱ is shown in eq (51).

${\textstyle {D}_{A}^{P}\leq {\frac {{\left({Q}_{H}\right)}^{2}}{{2}^{{d}_{1}}}}+}$${\displaystyle {\frac {{\left({Q}_{S}+{Q}_{E}\right)}^{2}}{{d}_{2}}}+{\frac {{Q}_{S}}{{2}^{{d}_{3}-1}}}+}$${\displaystyle 2{D}_{A}^{P}\left(\varphi \right)}$

(51)

Whereas 𝜑 means very small numbers generated through ECC method, for real interaction of Ᾱ with P is shown in eq (52):

${\textstyle {D}_{A}^{P}=P\left[{W}_{1}\right]-{\frac {1}{2}}}$

(52)

For acting is malicious deeds in eavesdropping on publicly transmitted conversations, the winning chance with Ᾱ is shown in eq (53):

${\textstyle {D}_{A}^{P}=P\left[{W}_{2}\right]-P\left[{W}_{1}\right]}$

(53)

The conversation between G_i and G_j while executing it, A chooses k₂ and creates a hash of it; the win chance with Ᾱ is shown in eqs (54) and (55):

${\textstyle P\left[{W}_{2}\right]-P\left[{W}_{1}\right]\leq {\frac {{\left({q}_{H}\right)}^{2}}{{2}^{{k}_{1}+1}}}+}$${\displaystyle {\frac {{\left({q}_{S}+{q}_{E}\right)}^{2}}{2{k}_{2}}}}$

(54)

${\textstyle P\left[{W}_{3}\right]-P\left[{W}_{2}\right]\leq {\frac {{q}_{S}}{{2}^{{k}_{3}}}}}$

(55)

The SK is comprised of various credentials, including ECC keys, and pseudorandom numbers. The chances with Ᾱ in getting these are shown in eq (56):

${\textstyle P\left[{W}_{4}\right]-P\left[{W}_{3}\right]\leq {D}_{A}^{P}\left(\varphi \right)}$

(56)

The guess of random numbers for Ᾱ is shown in eq (57)

${\textstyle P\left[{W}_{4}\right]={\frac {1}{2}}}$

(57)

Combine all the winning chance of Ᾱ by merging all the above Eqs. (49)-(57), we get

${\textstyle {\frac {1}{2}}{D}_{A}^{P}=\left|P\left[{W}_{0}\right]-{\frac {1}{2}}\right|\leq {\frac {{\left({q}_{H}\right)}^{2}}{{2}^{{k}_{1}}}}+}$${\displaystyle {\frac {{\left({q}_{S}+{q}_{E}\right)}^{2}}{{k}_{2}}}+{\frac {{q}_{S}}{{2}^{{k}_{3}-1}}}+}$${\displaystyle 2{D}_{A}^{P}\left(\varphi \right)}$

(58)

Eq: (58) means

${\textstyle {D}_{A}^{P}\leq {\frac {{\left({q}_{H}\right)}^{2}}{{2}^{{k}_{1}}}}+}$${\displaystyle {\frac {{\left({q}_{S}+{q}_{E}\right)}^{2}}{{k}_{2}}}+{\frac {{q}_{S}}{{2}^{{d}_{3}-1}}}+}$${\displaystyle 2{D}_{A}^{P}\left(\varphi \right)}$

(59)

It means Ᾱ cannot succeed in any attack due to CDHP, and ECC pseudorandom numbers and keys; hence, the proposed protocol is safe from all attacks.

6 Performance & Comparative Analysis

This section examines two performance metrics, communications, and computation, while the remaining metrics, like storage, latency, scalability, etc., should be kept for the upcoming research work. The primary focus here is on comparing the proposed protocol with state-of-the-art protocols, particularly regarding performance metrics (communication and computation costs) and security functionalities. This comparison process is crucial for understanding the effectiveness of the proposed protocol. So, these are discussed one by one as follows:

6.1 Communication Cost

The communication costs for different parameters, sourced from MIRACL Crypto SDK [12], and [16], are as follows: hash image/code is 256 bits, identity, timestamp, ECC-key, random number, and secret key are 64, 32, 160, 60, and 60 bits correspondingly. The key agreement phase involves the following sequence of messages: the first message transmitted between PD→ GW is {X₁, T}, the 2nd message between GW→ DD is {A₃, P_key2, X₄, T}, the third message between DD→ GW is {B₃, P_key3, X₇, T}, and the last message between GW→ PD is {B₃^*, P_key2, X₁₀, T} of cost is 256+32=288 bits, 256+160+256+32=704, 704, and 704, respectively, so the total communication cost of the proposed protocol is 2400 bits. Compared with state-of-the-art schemes in Table 5, the proposed protocol demonstrates less communication cost (lightweight) than all the remaining schemes.

Table 5. Communication Cost Comparison

Schemes	Communication Costs
Lopes et al. [11]	3072
Ma et al. [17]	12640
Jia et al. [18]	6880
Chen et al. [20]	3904
Wu et al. [21]	7744
Krishnasrija et al. [41]	3718
Proposed	2400 bits

In Table 5, the communication costs of the scheme presented by Lopes et al. [11] consist of the health center upload phase of 736 bits, the patient upload phase occupies 736 bits, the treatment (TP) and checkup (CP) phases are 864 and 736 bits correspondingly. The proposed protocol, a patient-side IoT device, gateway, and physician-side IoT device, each occupying 704 bits of space in a communication line, is significantly more lightweight than [11], providing a sense of relief about its practicality. In Ma et al. [21], the communication cost for the user side is 1696 bits, the fog-node side is 7200 bits, and the control server is 3744, cumulatively 12640 bits too much heavyweight from the proposed protocol. In Jia et al. [22] scheme, the cost for the user is 1376, the fog node (gateway) is 4128 bits, and the cloud server is 1376 bits, cumulatively 6880 bits, a high cost compared to the proposed protocol. The scheme presented by Chen et al. [24] is 3004 bits. In comparison, the protocol given by Wu et al. [25] has 6|G1|+9|q|+5|T| = 7744 bits. Krishnasrija et al. [41] have a communication cost of 3718 bits, which means they all are too high than the proposed protocol, as plotted diagrammatically in Figure 4.

Figure 4. Communication Cost Comparison Analysis

6.2 Computation Cost

Implementation the proposed protocol, a Raspberry Pi 5 Broadcom BCM2712 quad-core Arm Cortex A76 processor @ 2.4GHz, and a Laptop of Core i7-6500U @ 2.5 GHz of 16GB RAM. The specific costs for each cryptographic operation in milliseconds (ms) are ECC point multiplication (T_X) ≈ 2.2260 ms, point addition (T₊) ≈ 0.0288 ms, random number extraction (T_R) ≈ 2.011 ms, and hash cryptographic function (T_H) ≈ 0.0023 ms. Therefore, considering the costs mentioned above, the computation costs of the proposed key agreement scheme are 5(2.2260) + 22(0.0023) + 8(2.011) = 11.13 + 0.0506 + 16.088 = 27.27 ms. The cost of the key agreement phase has been taken into account. It's worth noting that the registration procedure, which only runs once, has minimal impact on the scheme's performance. The number of operations performed in the key agreement phase of the proposed scheme is 5T_X+22T_H+8T_R. A comparison with the existing schemes in the literature, as shown in Table 6, confirms that the proposed verifiably secure key agreement scheme outperforms all its competitors. This is due to the fact that SHA-256 is more secure than SHA1, which has become obsolete. SHA-256 is faster than SHA1 and offers superior security, providing a confident and reassuring solution.

Table 6. Computation Cost Comparison

Schemes	Computation Costs in ms
Lopes et al. [11]	210.00
Ma et al. [17]	70.86
Jia et al. [18]	109.187
Chen et al. [20]	85.74
Wu et al. [21]	196.02
Krishnasrija et al. [41]	352.56
Proposed	27.27 ms

Table 6 demonstrated that, in the Lopes et al. [11] scheme, the health upload phase (HUP) consisted of 2-point multiplication and 8 hash codes, the patient upload phase (PUP) has 4 point multiplication and 9 hash images, the treatment phase (TP) has 4 ECC point multiplication and 8 hash codes and the checkup phase (CP) hs 2 ECC point multiplication and 8 hash codes of which takes 210 milliseconds to compute the session secret key. In contrast, the proposed protocol was executed in 27.69 ms, showcasing its exceptional computational efficiency. The different operations of Ma et al. [21] include a user-side computation cost of 40.439 ms, a fog-node (gateway) side of 8.688 ms, and a cloud server executed in 21.727 ms of cumulative computation cost for the execution of session secret key of 70.86 ms, which is significantly higher than the proposed protocol. The computation cost of Jia et al. [22] is 109.19 ms, Chen et al. [24] is 85.74 ms, Wu et al. [25] is 196.02 ms, and Krishnasrija et al. [41] is 352.56 ms; this significant difference in computation costs underscores the impact of the proposed protocol's efficiency, as plotted in Figure 5.

Figure 5. Computation Cost Comparison Analysis

6.3 Comparison of Security Functionalities

Suppose the horizontal row in Table 7 represents the security functionalities/attacks like 1 denotes Replay Attack found, 2 denotes DoS Attack is available, 3 means Impersonation Attack is possible, 4 means Perfect Forward Secrecy provides, 5 represents Perfect Backward Secrecy provides, 6 represents Anonymity exists, 7 denotes Man-in-the-Middle Attack found, 8 denotes ESL Attack available, 9 means Insider Threat found, and 10 means Session Key Secrecy provide. In contrast, the vertical row means the state-of-the-art protocol (prior work). Then, the proposed protocol can be compared with prior works in terms of the security functionalities presented above from 1 to 10. This comparison is significant as it provides a clear benchmark for understanding the robustness of the proposed protocol, which is the main focus of our research, as demonstrated by the result obtained from Table 7. This means that [11] is not vulnerable to replay, DoS, impersonation, and MITM attacks but doesn’t provide perfect forward/backward/session key secrecy. The protocol presented in [21] is strong against replay, DoS, impersonation, MITM, ESL, and insider threats but doesn’t offer user anonymity; [22] is weak against DoS, ESL, and insider attacks, cannot offer perfect backward secrecy while safe/provides the remaining feature’ [24] is susceptible to impersonation, and ESL attacks, and doesn’t provides session key secrecy; [25] is vulnerable to DoS, and MITM attacks, cannot offer perfect forward/backward/session key secrecy while all other features have existed in it. Finally, the scheme presented in [41] is weaker against replay, DoS, impersonation, and insider attacks but doesn’t provide perfect forward secrecy. In contrast, the proposed protocol is robust against all its competitors, providing a high level of security and ensuring the secrecy of forward/backward/session keys, thereby safeguarding the data.

Table 7. Security Functionalities Comparison

Features→ Schemes↓	1	2	3	4	5	6	7	8	9	10
[11]	N	N	N	Y	Y	N	N	N	N	Y
[21]	N	N	N	N	Y	Y	N	N	N	Y
[22]	N	Y	N	Y	N	Y	Y	N	N	Y
[24]	Y	Y	N	Y	Y	Y	Y	N	Y	N
[25]	Y	N	Y	N	N	Y	N	Y	Y	N
[41]	N	Y	Y	N	Y	N	Y	Y	N	Y
Proposed	N	N	N	Y	Y	Y	N	N	N	Y

6.4 Improvement in Performance

In Table 8, the proposed protocol is comprehensively evaluated against existing ones. It is 21.85% better in communication cost and 87.01% better in computation cost than the protocol presented by Lopes et al [11]. The proposed protocol also outperforms the one presented by Ma et al. [21], being 81.01% better in communication cost and 61.51% better in computation cost. It is 65.11% better in communication costs and 75.02% better in computation costs than the scheme presented by Jia et al.[22]. The proposed protocol is 38.52% lighter and 68.19% faster than the one by Chen et al.[24]. It is 69% lighter and 86.08% better than the one by Wu et al.[25], and 35.44% better in communication cost and 92.26% faster in computation cost than the one by Krishnasrija et al. [41]. This thorough evaluation provides a clear picture of the proposed scheme's outstanding performance against its competitors, as shown in Figure 6.

Table 8. Improvement in performance

Scheme	%age Improvement in Communication Costs	%age Improvement in Communication Costs
[11]	21.85%	87.01%
[21]	81.01%	61.51%
[22]	65.11%	75.02%
[24]	38.52%	68.19%
[25]	69%	86.08%
[41]	35.44%	92.26%

6.5 Round Trip Time (RTT)

The time needed for one complete round-trip of the proposed protocol is RTT. This calculation, which you can trust due to the use of the reliable MIRACL Crypto SDK [43-44], shows that the cost T_X function is 2.2260 ms, T_R is 2.011 ms, and T_H ≈ 0.0023 ms. The proposed protocol involves three types of operations. In step a, the number of operations is 1T_H+0T_X+1T_R= 0.0023 + 0 + 2.011 = 3.0133 ms. In step b, it is 3T_H+0T_X+2T_R = 0.0069 + 4.022 = 4.0289 ms. In step c, it is 5T_H+0T_X+2T_R = 0.0115 + 4.011 = 4.0225 ms. In step d, it is 5T_H+0T_X+2T_R = 0.0115 + 4.011 = 4.0225 ms. And in step e, it is 5T_H+0T_X+2T_R = 0.0115 + 4.011 = 4.0225 ms. By summing each step's computation time, we get the RTT of 19.11 ms for the proposed protocol, a result you can rely on as shown in Table 9 and plotted in Figure 7.

Table 9. Round Trip Time

Step	No. of Operations	Values	Cost
a	1TH+0TX+1TR	0.0023 + 2.011	3.0133
b	3TH+0TX+2TR	0.0069 + 4.022	4.0289
c	5TH+0TX+2TR	0.0115 + 4.011	4.0225
d	5TH+0TX+2TR	0.0115 + 4.011	4.0225
e	5TH+0TX+2TR	0.0115 + 4.011	4.0225
Total Round Trip Time (RTT) in Milliseconds			19.11 ms

Figure 6. Performance Improvement across different protocols

Figure 7. Round Trip Time

6.6 Energy Consumption

Suppose E_P is the energy of the whole system, which is a constant value equivalent to 10.88 mJ, E_C represents the energy consumption while computing the shared session key, and C_P is the computation cost of the proposed protocol measured in 6.2 of the article, which is equivalent to 27.27 ms. Then E_C=C_P x E_P, putting the values 27.27 x 10.88 = 296.7 mJ. Therefore, the energy consumption of the proposed protocol is 296.7 mJ; by comparing it with state-of-the-art protocols, we have conducted a thorough and comprehensive comparison, demonstrating that the proposed protocol consumes less energy compared to Lopes et al. is 2284.8 mJ, Ma et al. is 770.95 mJ, Jia et al. is 1187.95 mJ, Chen et al. is 932.85 mJ, Wu et al. is 2132.7 mJ and Krishnasrija et al. is 3835.85 mJ is shown in Table 10, and plotted in Figure 8.

Table 10. Energy Consumption

Protocols	Energy Consumption in Mill joule	Energy Consumption in Joule
Lopes et al. [11]	2284.8	2.6
Ma et al. [21]	770.95	0.8
Jia et al. [22]	1187.95	1.2
Chen et al. [24]	932.85	1.0
Wu et al. [25]	2132.7	2.2
Krishnasrija et al. [41]	3835.85	3.9
Proposed	296.7 mJ	0.2 J

Figure 8. Energy Consumption

6.7 Other Performance-Tradeoffs Assessment

Operators (users) play a crucial role in maintaining stability between devices and remote monitoring. They must consciously balance security and limited energy resources in energy-constrained environments like IoT networks. As the number of users increases, the energy consumption initially rises. However, it's important to note that with the increase in users, the energy consumption gradually decreases. This is a reassuring sign of the excellent scalability of the proposed protocol against its competitors as shown in Figure 9 which illustrates that IoT devices make more energy efficiency possible through a decrease in energy usage, better monitoring, and administration of IoT devices, which highlights the integral role of the proposed protocol for the resource-constrained IoT application and its process.

Figure 9. Energy Consumption vs No. of Operators

Similarly, transferring computing processes that require a lot of resources from a device to an external platform to speed up IoT applications that require high resources and low latency is termed task offloading. It entails dividing the program, choosing which task/what type of task to be offloaded, and carrying them among the participating entities. The procedure can increase energy efficiency and optimize resource consumption, especially in IoT applications with limited resources. Contrary to the processing time for completion of one round trip and task-offloading, the proposed protocol, which is a specific method or system for task-offloading, trade-offs of these metrics are high compared to the opponents, as shown in Figure 10.

Figure 10. Energy Consumption vs Task-offloading

Figure 11 demonstrates that the trade-off finally, in contrast to runtime, the proposed protocol has also been assessed for throughput, demonstrating that our scenario outperforms its opponents.

Figure 11. Throughput vs Run-Time

7. Conclusion

This article presented an ECC-based protocol for resource-constrained IoT applications in the e-healthcare system, utilizing SHA-256 and XOR methods. The security analysis of the proposed protocol was conducted using BAN logic, AVISPA validation, ProVerif simulation, and ROM analysis. The performance evaluation section was addressed by comprehensively measuring communication, computation cost, energy consumption, other performance trade-offs, including task offloading, latency, and scalability. The results from these analyses demonstrated that the proposed protocol is robust and feasible for real-world implementation. In future, a CNN classifier for the extraction method will be applied to the timing side channel for tracing and detecting anomalies in the proposed protocol. We also plan to explore whether fractal-based QKD encoding can further compress key exchange traffic in ultra-low-power wearables.

Acknowledgment: The authors extend their sincere gratitude to the Deanship of Scientific Research at the University of Bisha, Bisha, Saudi Arabia, for their unwavering support and encouragement.

Funding Statement: This research work is funded by the Deanship of Scientific Research, University of Bisha, Saudi Arabia in its promising Program under grant No. (UB-Promising-26-1445).

Competing Interest: The authors declare no competing interest exist.

Data Availability: https://github.com/AV8790094/README

References

[1] Rizzardi A, Sicari S, Coen-Porisini A, 2024, IoT-driven blockchain to manage the healthcare supply chain and protect medical records. Future Generation Computer Systems 161, 415–431.

[2 Bisht A, Das AK, Niyato D, Park Y, 2023, Efficient personal-health-records sharing in Internet of Medical Things using searchable symmetric encryption, blockchain, and IPFS. IEEE Open J. Commun. Soc. 4, 2225–2244.

[3] Jagatheesaperumal SK, Pham QV, Ruby R, Yang Z, Xu C, Zhang Z, 2022, Explainable AI over the Internet of Things (IoT): Overview, state-of-the-art and future directions. IEEE Open J. Commun. Soc. 3, 2106–2136.

[4] Ahmadi Z, Kashani MH, Nikravan M, Mahdipour E, 2021, Fog-based healthcare systems: A systematic review. Multimedia Tools Appl. 80, 36361–36400.

[5] Raj H, Kumar M, Kumar P, Singh A, Verma OP, 2022, Issues and challenges related to privacy and security in healthcare using IoT, fog, and cloud computing, in Advanced Healthcare Systems: Empowering Physicians with IoT-Enabled Technologies, 21–32.

[6] Barua A, Al Alamin MA, Hossain MS, Hossain E, 2022, Security and privacy threats for Bluetooth Low Energy in IoT and wearable devices: A comprehensive survey. IEEE Open J. Commun. Soc. 3, 251–281.

[7] Rehman AU, Tariq N, Jan MA, Khan F, Song H, Ibrahim M, 2024, A blockchain-based hybrid model for IoMT-enabled intelligent healthcare system. IEEE Trans. Netw. Sci. Eng. 11(4), 3512–3521.

[8] Venkatesh R, 2024, A lightweight quantum blockchain-based framework to protect patients' private medical information. IEEE Trans. Netw. Sci. Eng. 11(4), 3577–3584.

[9] Soni P, Islam SH, Pal AK, Mishra N, Samanta D, 2024, Blockchain-based user authentication and data-sharing framework for healthcare industries. IEEE Trans. Netw. Sci. Eng. 11(4), 3623–3638.

[10] Liu Y et al., 2024, A blockchain-based cross-domain authentication management system for IoT devices. IEEE Trans. Netw. Sci. Eng. 11(1), 115–127.

[11] Lopes G, Gondim RP, 2024, Mutual authentication protocol for D2D communications in a cloud-based e-health system. Sensors 20(7), 2072.

[12] Ayub MF, Mahmood K, Kumari S, Sangaiah AK, 2021, Lightweight authentication protocol for e-health clouds in IoT-based applications through 5G technology. Digit. Commun. Netw. 7(2), 235–244.

[13] Khan AA et al., 2022, A blockchain security module for brain-computer interface (BCI) with multimedia life cycle framework (MLCF). Neurosci. Inform. 2(1), 100030.

[14] Shariq M, Singh KA, 2022, A secure and lightweight RFID-enabled protocol for IoT healthcare environment: A vector space-based approach. Wirel. Pers. Commun. 127(4), 3467–3491.

[15] Tucker MD, Rhia C, 2022, The importance of a HIPAA security risk analysis. J. Med. Pract. Manag. 38(3), 103–104.

[16] Mandelbrot BB, 1989, Fractal geometry: What is it, and what does it do? Proc. R. Soc. Lond. A, Math. Phys. Sci. 423(1864), 3–16.

[17] Falconer KJ, 1997, Techniques in Fractal Geometry, Wiley, Chichester.

[18] Cao Z, Liu L, 2024, The practical advantage of RSA over ECC and pairings. Cryptology ePrint Archive.

[19] Suárez-Albela M, Fernández-Caramés TM, Fraga-Lamas P, Castedo L, 2018, A practical performance comparison of ECC and RSA for resource-constrained IoT devices, in 2018 Global Internet of Things Summit (GIoTS), 1–6.

[20] Ansari et al., 2022, Privacy-enabling framework for cloud-assisted digital healthcare industry. IEEE Trans. Ind. Inform. 18(11), 8316–8325.

[21] Ma et al., 2019, An efficient and provably secure authenticated key agreement protocol for fog-based vehicular ad-hoc networks. IEEE Internet Things J. 6(5), 8065–8075.

[22] Jia et al., 2019, Authenticated key agreement scheme for fog-driven IoT healthcare system. Wirel. Netw. 25(8), 4737–4750.

[23] De et al., 2021, Lightweight PUF-based authentication scheme for fog architecture. Wirel. Netw. 27(2), 947–959.

[24] Chen et al., 2021, A secure authenticated and key exchange scheme for fog computing. Enterp. Inf. Syst. 15(9), 1200–1215.

[25] Wu et al., 2021, Improved authenticated key agreement scheme for fog-driven IoT healthcare system. Secur. Commun. Netw. 2021, 1–16.

[26] Deebak BD, Al-Turjman F, 2021, Robust, lightweight privacy-preserving and session scheme interrogation for fog computing systems. J. Inf. Secur. Appl. 58, 102689.

[27] Hailong Y, Yan Q, Fu X, Zhang Z, Lan C, 2022, ECC-based lightweight authentication and access control scheme for IoT e-healthcare. Soft Comput. 26(9), 4441–4461.

[28] Rana et al., 2023, Towards a provably secure authentication protocol for fog-driven IoT-based systems. Appl. Sci. 13(3), 1424.

[29] Ashraf Z, Mahmood Z, Iqbal M, 2023, Lightweight privacy-preserving remote user authentication and key agreement protocol for next-generation IoT-based smart healthcare. Future Internet 15(12), 386.

[30] Zhao G, Li X, Li H, 2024, A trusted authentication scheme using semantic LSTM and blockchain in IoT access control system. Int. J. Semant. Web Inf. Syst. 20(1), 1–27.

[31] Arpitha T, Dharamendra C, Shreyas J, 2024, Anonymous and robust biometric authentication scheme for secure social IoT healthcare applications. J. Eng. Appl. Sci. 71(1), 8.

[32] Ali A et al., 2019, A fractal-based authentication technique using Sierpinski triangles in smart devices. Sensors 19(3), 678.

[33] Agarwal S, 2019, A fractal-based image cipher using Knuth shuffle method and dynamic diffusion. Int. J. Comput. Netw. Commun. 11, 81–100.

[34] Sun N et al., 2023, Random fractal-enabled physical unclonable functions with dynamic AI authentication. Nat. Commun. 14(1), 2185.

[35] Mfungo DE, Fu X, 2023, Fractal-based hybrid cryptosystem: Enhancing image encryption with RSA, homomorphic encryption, and chaotic maps. Entropy 25(11), 1478.

[36] Chen G, Cheng Q, 2018, Fractal-based wavelet filter for separating geophysical or geochemical anomalies from background. Math. Geosci. 50(3), 249–272.

[37] Ge W et al., 2024, Machine learning predictions for bending capacity of ECC-concrete composite beams hybrid reinforced with steel and FRP bars. Case Stud. Constr. Mater. 21, e03670.

[38] Rana A et al., 2022, Internet of medical things-based secure and energy-efficient framework for health care. Big Data 10(1), 18–33.

[39] Rehman A et al., 2021, Energy-efficient IoT e-health using artificial intelligence model with homomorphic secret sharing. Energies 14(19), 6414.

[40] Garg S, Kaur K, Kaddoum G, Choo KKR, 2019, Toward secure and provable authentication for Internet of Things: Realizing industry 4.0. IEEE Internet Things J. 7(5), 4598–4606.

[41] Krishnasrija R, Mandal AK, Cortesi A, 2023, A lightweight mutual and transitive authentication mechanism for IoT network. Ad Hoc Netw. 138, 103003.

[42] Koblitz N, Menezes AJ, 2015, The random oracle model: A twenty-year retrospective. Des. Codes Cryptogr. 77(2), 587–610.

[43] Hyla T, El Fray I, Maćków W, Pejaś J, 2015, Implementation of pairing-based cryptographic trust infrastructure in mobile environment. Przegląd Elektrotechniczny 91(2), 93–97.

[44] Zhang X et al., 2023, MIRACL: A multilingual retrieval dataset covering 18 diverse languages. Trans. Assoc. Comput. Linguist. 11, 1114–1131.