A Novel Key Distribution for Mobile Patient Authentication Inspired by the Federated Learning Concept and Based on the Diffie–Hellman Elliptic Curve

Abstract

Ensuring secure communication for mobile patients in e-healthcare requires an efficient and robust key distribution mechanism. This study introduces a novel hierarchical key distribution architecture inspired by federated learning (FL), enabling seamless authentication for patients moving across different healthcare centers. Unlike existing approaches, the proposed system allows a central healthcare authority to share global security parameters with subordinate units, which then combine these with their own local parameters to generate and distribute symmetric keys to mobile patients. This FL-inspired method ensures that patients only need to store a single key, significantly reducing storage overhead while maintaining security. The architecture was rigorously evaluated using SPAN-AVISPA for formal security verification and BAN logic for authentication protocol analysis. Performance metrics—including storage, computation, and communication costs—were assessed, demonstrating that the system minimizes the computational load and reduces the number of exchanged messages during authentication compared to traditional methods. By leveraging FL principles, the solution enhances scalability and efficiency, particularly in dynamic healthcare environments where patients frequently switch between facilities. This work bridges a critical gap in e-healthcare security, offering a lightweight, scalable, and secure key distribution framework tailored for mobile patient authentication.

1. Introduction

In the age of interconnected healthcare systems, the Internet of Medical Things (IoMT) has emerged as a transformative force, revolutionizing the way healthcare data are collected, analyzed, and used [1]. From wearable devices that monitor vital signs to smart implants that transmit real-time health information, IoMT has ushered in an era of unprecedented medical data generation [2]. However, with this abundance of data comes a pressing need for robust security and authentication mechanisms to ensure the integrity and privacy of patient information.

The benefits of IoMT are indeed profound. It enables remote patient monitoring, facilitating the continuous collection of health data outside traditional clinical settings [3]. This empowers healthcare providers to offer personalized and proactive care, detect health problems early, and make data-driven decisions, ultimately improving patient outcomes. In addition, IoMT improves the efficiency of medical services, reducing the burden on healthcare facilities by enabling telemedicine, remote consultations, and even the possibility of timely interventions through predictive analytics [4].

At the same time, alongside these remarkable advantages, IoMT introduces a series of complex challenges. Security and privacy vulnerabilities are large as data flows between numerous devices, networks, and cloud platforms [5]. Unauthorized access to medical data poses serious risks, making robust authentication mechanisms paramount. Interoperability issues also arise as various devices and platforms must communicate and share data seamlessly while maintaining data integrity [6].

In this intricate landscape, the need for secure and efficient patient authentication mechanisms becomes increasingly evident. Ensuring that healthcare providers have access to the right patient’s data is not just a matter of convenience, but a fundamental requirement to provide safe and effective care [7]. Traditional methods of patient authentication, often relying on static identifiers such as usernames and passwords, are not suited to the dynamic and interconnected world of IoMT. They leave room for vulnerabilities and may hinder the full realization of IoMT’s potential [8].

Patient authentication within the IoMT ecosystem is a multifaceted challenge with far-reaching implications. It encompasses the methods and technologies used to verify the identity of patients and healthcare providers who access IoMT devices and the data they generate [9]. The fundamental goals of patient authentication in IoMT are twofold: to ensure the security and integrity of medical data and to protect patient privacy [10].

IoMT introduces unique challenges to patient authentication. The diverse array of devices, ranging from wearable sensors to implantable medical devices, requires authentication methods that can accommodate various form factors and communication protocols. These devices must seamlessly integrate into the broader healthcare infrastructure while ensuring the privacy and security of patient data [11].

Additionally, the real-time nature of IoMT data transmission necessitates authentication mechanisms that can operate swiftly and efficiently, without causing delays in medical data access or decision-making processes. Balancing security, speed, and usability is paramount in the IoMT environment [12].

One critical aspect of securing data transmitted within the IoMT ecosystem is the use of robust encryption techniques [10]. Encryption ensures that data are protected from unauthorized access while in transit. However, effective encryption relies on the secure distribution of encryption keys.

Key distribution in the context of IoMT involves the secure exchange and management of cryptographic keys between devices, users, and healthcare systems. These keys are essential for encrypting and decrypting data as they move between IoMT devices, ensuring that sensitive medical information remains confidential and tamper-proof during transmission.

Establishing a secure and efficient key distribution system is paramount for the overall data security within IoMT [13]. It involves addressing challenges such as key management, key generation, and key revocation, while ensuring that patient authentication seamlessly integrates with the encryption process [14].

Federated Learning (FL) is a collaborative, decentralized, and distributed iterative procedure in which individuals work together to train machine learning models while protecting the confidentiality of their personal data [15]. This approach is exemplified by its implementation in Google Gboard [16]. Rather than transmitting raw data, terminal devices (clients) locally process their information and then forward only the modifications to a central system (server). Subsequently, the server compiles and aggregates the modifications from all clients to generate an updated global model, which is then redistributed to the clients [17]. This iterative process persists until an optimal global model is achieved allowing for continuous improvement of the global model without exposing sensitive data to a centralized entity, making federated learning a promising technique for training machine learning models in privacy-sensitive scenarios [18]. FL has applications in various domains, such as healthcare, finance, Internet of Things (IoT), and edge computing, where data privacy, network bandwidth limitations, or regulatory constraints make centralized training impractical or undesirable [19,20].

A privacy-preserving domain refers to an area or context where techniques, methods, or systems are employed to protect and maintain the privacy of individuals’ sensitive information. In such a domain, measures are taken to ensure that personal data are securely handled and are used in a way that minimizes the risk of unauthorized access, disclosure, or misuse [21,22]. This can be achieved using different approaches such as data anonymization, encryption, differential privacy, access controls, secure multi-party computation (SMPC), and FL [23].

The process of FL passes through different steps as illustrates in Figure 1. It begins with the Initialization Phase, where a central server initializes a global model and distributes it to participating devices or servers. In the subsequent local model training phase, each device trains the model independently using its local data, safeguarding the raw data’s privacy [24]. The updated models’ parameters are then transmitted back to the central server during the model aggregation phase, where they are combined from all participating devices or servers [25]. Following this, the central server performs a model update, incorporating the aggregated parameters into the global model. The updated global model is subsequently sent back to the participating devices, commencing the next round of local training [26,27]. This iterative process, including local training, model aggregation, and model updates, continues until the desired level of model performance is achieved or convergence is reached [15,27,28].

1.1. Challenges to Ensuring Authentication and Confidentiality in Healthcare

Securing healthcare systems is a critical endeavor, but it comes with several challenges such as data privacy, cybersecurity threats, interoperability, mobile and IoT devices, human errors, legacy systems, resource constraints, emerging technologies, patient mobility, and regulatory compliance [29].

Ensuring security in various applications, particularly in healthcare systems, has become a prominent area of research. This entails addressing multiple security facets, including confidentiality, authentication, and privacy. Preserving patient privacy is of the utmost importance. Establishing a secure connection through data encryption between the sender and receiver is crucial. Moreover, accommodating patient mobility is a significant consideration [30,31].

In this paper, we will focus on three challenges: patient mobility, privacy, and resource constraints.

1.2. Contributions

• Proposing a hierarchical key distribution architecture in the context of an e-healthcare system to enhance the security and privacy of patients based on FL.
• Proposing a novel key distribution protocol based on FL to exchange the local and global model between the root public key generator $Roo{t}_{PKG}$ and sub-public key generator $Su{b}_{PKG}$.
• Designing a lightweight key establishing approach between $Su{b}_{PKG}$ and mobile patient using Diffie–Hellman elliptic curve algorithm.
• Providing patient authentication using a private key and several secure parameters also providing identity preservation using the concept of a local model for each $Su{b}_{PKG}$.
• Enhancing the performance for the mobile node in terms of the number of exchange messages [32].

Our work primarily follows a scientific approach, as it focuses on enhancing the security and privacy of patients by proposing a hierarchical key distribution architecture in the context of an e-healthcare system with simulation and formal security proofs.

2. Related Work

This section provides a summary of the authentication techniques discussed in the literature, as illustrated in Table 1. It highlights key methodologies, their effectiveness, and the contexts in which they are applied. Additionally, a comparative analysis is presented to examine the authentication techniques and the environments for which they are designed.

Table 2 provides a comparative analysis of different healthcare systems discussed in the literature. The comparisons have been performed using various architectures, security goals, verification methods, and performance aspects, offering insights into their strengths and limitations.

Many authentication techniques have been used in the literature. For instance, the authors of [33] employ fingerprint recognition as a biometric modality and extract specific features to create a shared cryptographic key. Their proposed methodology includes three phases: System Initialization, Patient Registration, and Mutual Authentication with Session Key Agreement. The System Initialization Phase involves two key steps: extracting a cancelable biometric template and generating system parameters. The authors of [34] propose a lightweight and robust authentication scheme utilizing a simple hash cryptographic function, with public–private key pairs designed specifically for IoMT devices. They utilize formal analysis techniques like BAN logic and ProVerif2.02, in conjunction with informal pragmatic illustration, to validate the effectiveness of their proposed protocol. Moreover, the study conducts a performance analysis to showcase the delicate balance achieved between security and efficiency, an aspect frequently overlooked in existing solutions.

Another study that uses biometric data for patient authentication is [35]. The authors propose a framework that integrates wearable sensors to monitor vital signs and authenticate patients using biometric data alongside traditional credentials, secured by the SHA-512 algorithm. Sensor data transmission to the cloud is encrypted with the Substitution-Ceaser cipher and improved Elliptical Curve Cryptography (IECC), with enhanced security from an additional secret key. Despite increased complexity, the approach remains computationally efficient, with encryption and decryption times of 1.032 $\mathsf{\mu }$ and 1.004 $\mathsf{\mu }$, respectively, and performance analysis shows strong algorithm reliability compared to RSA and ECC.

The authors of [36] introduce a lightweight anonymous mutual authentication and key agreement scheme for Wireless Body Area Networks (WBANs). This scheme relies solely on hash function operations and XOR operations. The authors employ the automatic security verification tool ProVerif to verify the security properties of their scheme, complemented by informal security analysis. Furthermore, they conduct a comparative analysis of their proposed scheme against several related works. The results demonstrate that their scheme either offers superior advantages in terms of computation cost, energy consumption, and communication cost, or presents lower security risks compared to existing approaches.

Alzahrani et al. [37] present a review of the patient healthcare monitoring and authentication protocol designed for Wireless Body Area Network (WBAN) environments proposed by Xu et al. in [36]. While Xu et al.’s scheme demonstrates efficiency in terms of computation by employing lightweight operations, the conducted analysis uncovers several security loopholes. It is revealed that Xu et al.’s protocol is susceptible to various threats, including replay attacks, key compromise impersonation (KCI) attacks, and privacy concerns. In response to these vulnerabilities, they propose a new authenticated key agreement protocol tailored for WBANs. The security properties of the improved protocol are formally verified and validated through BAN logic analysis and the ProVerif automated simulation tool.

Table 1. Mobile patient authentication in the literature.

Reference	Authentication Technique	Environment
[38]	Biometric+ECC	Mobile healthcare environments
[34]	Shared key	Wireless Medical Sensor Networks
[35]	ECC	IoT
[37]	Improved mutual authentication	Wireless Body Area Networks
[36]	Lightweight anonymous mutual authentication	Wireless Body Area Networks
[39]	Federated learning and blockchain	IoT healthcare
Our proposal	Federated learning and key distribution	IoT healthcare system

Table 1. Mobile patient authentication in the literature.

Reference	Authentication Technique	Environment
[38]	Biometric+ECC	Mobile healthcare environments
[34]	Shared key	Wireless Medical Sensor Networks
[35]	ECC	IoT
[37]	Improved mutual authentication	Wireless Body Area Networks
[36]	Lightweight anonymous mutual authentication	Wireless Body Area Networks
[39]	Federated learning and blockchain	IoT healthcare
Our proposal	Federated learning and key distribution	IoT healthcare system

The authors of [38] propose a secure and lightweight remote patient authentication scheme tailored for mobile healthcare settings. Their approach translates patient biometric data into Elliptic Curve Cryptography (ECC)-based keys, enabling secure and cost-effective authentication without the need to store or transmit biometric templates. Moreover, the proposed approach provides mutual authentication with session key agreement and resists various types of attacks. Singh et al. in [39] explore the applications of federated learning in establishing a distributed secure environment within smart cities. In addition, they propose a secure architecture for privacy preserving in smart healthcare, utilizing blockchain and FL technologies. Blockchain-based IoT cloud platforms enhance security and privacy, while FL enables scalable machine learning applications, particularly in healthcare. Importantly, users can access well-trained machine learning models without compromising personal data through federated learning.

Table 2. Different healthcare systems in the literature.

Reference	Architecture	Security Goal	Verification Method	Performance Analysis
[40]	Cloud of things	Prevent Man-in-the-Middle (MITM)	Scyther	Anonymity, Authentication, Authorization, Accountability, Confidentiality, Integrity, Non-repudiation
[41]	IoT-based M-Health system	Signature, Encryption, and Signcryption	Mathematical proof	Computational Cost, Communication Cost
[42]	WBANs	Authentication	Mathematical proof	Storage Overhead, Computation Cost, Communication Cost
[43]	E-healthcare	Authentication	AVISPA and BAN logic	Storage Cost, Communication Cost, Computation Cost
Our proposal	IoT healthcare	Authentication, Confidentiality, and Privacy	AVISPA and BAN logic	Storage Cost, Communication Cost, Computation Cost

Table 2. Different healthcare systems in the literature.

Reference	Architecture	Security Goal	Verification Method	Performance Analysis
[40]	Cloud of things	Prevent Man-in-the-Middle (MITM)	Scyther	Anonymity, Authentication, Authorization, Accountability, Confidentiality, Integrity, Non-repudiation
[41]	IoT-based M-Health system	Signature, Encryption, and Signcryption	Mathematical proof	Computational Cost, Communication Cost
[42]	WBANs	Authentication	Mathematical proof	Storage Overhead, Computation Cost, Communication Cost
[43]	E-healthcare	Authentication	AVISPA and BAN logic	Storage Cost, Communication Cost, Computation Cost
Our proposal	IoT healthcare	Authentication, Confidentiality, and Privacy	AVISPA and BAN logic	Storage Cost, Communication Cost, Computation Cost

3. Proposed System

3.1. Architecture Overview

This section proposes a key distribution architecture inspired by FL, as illustrated in Figure 2. Additionally,

Table 3. List of symbols and abbreviations used in the paper for notation and computation purposes.

Notations	Description
GM	Global model
LM	Local model
PKG	Public key generator
$P{K}_{Root}$	Public key for the $Roo{t}_{PKG}$
$P{r}_{Root}$	Private key for the $Roo{t}_{PKG}$
$D{C}_{Root}$	Digital signature for $Roo{t}_{PKG}$
$D{C}_{Sub}$	Digital signature for $Su{b}_{PKG}$
ID	Real identity of the patient
H	Hash function
$ϵ$	Elliptic curve range
$\eta$	Ranges for group signature
$\gamma$	Root sign value
${\rm Y}$	Sub-PKG sign value

presents the abbreviations used in this paper. The architecture consists of Root PKG, several Sub-PKGs, and patients. In each Sub-PKG, there is a local model to keep the data for each patient who belongs to this party. In the Root PKG, there is a global model that handle all local models without having knowledge about the patients in each Sub-PKG. In this architecture, several challenges have been addressed, such as computational complexity, communication demands, and storage requirements for mobile patients. Additionally, it prioritizes the secure key distribution process to safeguard patient privacy, even in situations where patients change their positions, all while minimizing unnecessary complexity.

It can be noticed that the Root PKG has a global model that aims to distribute common parameters for all Sub-PKGs based on the received local models from Sub-PKGs. Moreover, each Sub-PKG authenticates the patient using a shared common key between them. Thus, any mobile patient moving to another Sub-PKG can be authenticated without asking the original Sub-PKG.

In this architecture, we will employ the concept of FL to design a lightweight protocol to provide a secure connection between the patient and the hospital. Thus, the patient can establish a shared key using Elliptic Curve Diffie–Hellman (ECDH) and can be authenticated by the other parts (Sub-PKGs). ECDH is a cryptographic key exchange and authentication protocol commonly used to establish a secure communication channel between two parties over an insecure network [44].

3.2. The Proposed Protocol Overview

The proposed protocol consists of three phases: the first phase, called the Initialization Phase, between $Roo{t}_{PKG}$ and $Su{b}_{PKG}$. In the second phase, the patient registers for an official $Su{b}_{PKG}$. The third phase is the Mobile Patient Authentication Phase, which allows an easy way for any mobile patient node to access any $Su{b}_{PKG}$ without returning to the old one. On the other hand, further details on Elliptic Curve Diffie–Hellman can be found in Appendix A.1. The following subsections discuss each phase in detail.

3.2.1. Initialization Phase Between $Roo{t}_{PKG}$ and $Su{b}_{PKG}$

During this phase, the $Roo{t}_{PKG}$ initializes and distributes specific set of parameters for each $Su{b}_{PKG}$ to assist them in creating their local models. After each $Su{b}_{PKG}$ has finished building its local model, it sends its local model back to the Root PKG. The Root PKG, in turn, utilizes these local models to combine them into the ultimate model, often known as the global model. Figure 3 illustrates the process of the Initialization Phase, which consists of a two-step Initialization Phase and the model aggregation phase.

Each $Su{b}_{PKG}$ has its own public key and private key, while the same applies to the $Roo{t}_{PKG}$. $Roo{t}_{PKG}$ is considered as one trusted point for all other $Su{b}_{PKG}$s. Thus, for any further connection between any $Su{b}_{PKG}$s, they should exchange their digital signature which is represented in Equation (1):

$$DC{\left(SubPKGi\right)}_{(root,su{b}_i)}=\left\{\begin{array}{c}{E}_{P{r}_{root},(P{K}_{su{b}_i},I{D}_{sub},T^{\prime })}\hfill \end{array}\right.$$

(1)

The following steps conclude the details of each connection:

• $Roo{t}_{PKG}$ initiates a request to send information about the whole system, which consists of all Sub-PKGs and patients. This information is essential for the Sub-PKGs to construct their local models while considering these parameters.
• Root parameters are elliptic curve ranges for each Sub-PKG ($ϵ$), ranges for group signature ($\eta$), and root sign value ($\gamma$).
• The parameters are securely handled. Initially, ensuring nonrejection properties, the $Roo{t}_{PKG}$ encrypts these parameters using its private key, to ensure integrity and authentication. Subsequently, it encrypts them once more using the public key provided by the respective Sub-PKG to maintain confidentiality.
• After each $Su{b}_{PKG}$ receives the parameters from the root and based on the number of patients that it needs to deal with, the $Su{b}_{PKG}$ determines the group signature ${\sigma }_{sig}$, Sub-PKG signing value ${\rm Y}$, and identity for the group $I{D}_g$. After that, the $Su{b}_{PKG}$ sends a local model via its private key and encapsulates via the root public key.
• The root aggregates multiple local models from various Sub-PKGs, each equipped with its own set of parameters. This collective information is then used to construct the global model, ensuring a comprehensive consideration of all these individual parameters.

3.2.2. Patient Registration and Key Generation Phase

Figure 4 illustrates this phase; each patient is assigned to their respective $Su{b}_{PKG}$. They must agree on various parameters and establish a shared key. This shared key will then be utilized for future connections. The $Su{b}_{PKG}$ needs to authenticate patients. When the patient asks for the $Su{b}_{PKG}$ for the first time for registration to be part of a group, the patient must show the $Su{b}_{PKG}$ acceptable credentials.

The $Su{b}_{PKG}$ thoroughly reviews it and checks whether anything about the patient is suspicious. If the $Su{b}_{PKG}$ is fully satisfied with the background verification, it accepts the patient’s request to be part of the group. The $Su{b}_{PKG}$ and the patient create a shared key using ECDH as follows:

• The $Su{b}_{PKG}$ selects generator G based on the range that was created by the $Roo{t}_{PKG}$, prime number p, and selects a private number $d_{sub}$ to determine the pubic key as $Psub=G^{d_{sub}}modp$.
• The patient selects the private key $d_{patient}$ then determines its public key as $Ppatient=G^{d_{patient}}modp$ and sends the public key to the $Su{b}_{PKG}$. Moreover, it determines the shared key as $SK=Psub\ast d_{patient}$.
• After the $Su{b}_{PKG}$ receives the patient’s public key it will determine the shared key as $SK=Ppatient\ast d_{sub}$.

After the shared key has been established between the patient and the $Su{b}_{PKG}$, the $Su{b}_{PKG}$ sends an encrypted message using the shared key that holds the group signature (${\sigma }_{GS}$), the identity of the group ($I{D}_g$), the root sign ($\gamma$), and the Sub-PKG sign (${\rm Y}$).

The patient computes their own signature after receiving the parameters from $Su{b}_{PKG}$ using ECDSA Sign based on the following points:

• Compute a message digest of the data you want to sign, often using a cryptographic hash function like SHA-256.
• The patient computes the digest for the message that equals ${\sigma }_{sig}+{\rm Y}+\gamma$; this will be as one block while $\varkappa$ is unique for each patient.

  $$Message={\sigma }_{sig}+{\rm Y}+\gamma +\varkappa$$

  (2)
• Generate a random number k in the range [1, n−1].
• Compute the point ($X_1$,$Y_1$) = k*G.
• Calculate r = $X_1$ mod n.
• Calculate s = ${\displaystyle \frac{H\left(M\right)+d_{patient}\ast r}{K}}$mod n.
• The patient ’s signature ($P_{sig}$) is (r + $\varkappa$,s + $\varkappa$).

3.2.3. Mobile Patient Authentication

Figure 5 illustrates the steps that are needed for any mobile patient that needs to change its location. The bottleneck in [32] is that if any mobile moves to a different Sub-PKG domain, it needs around nine messages to distribute a shared key, and the mobile node should ask the gateway. In this protocol, the patient has a signature and a group identity. Once the patient changes their location and wants to join another Sub-PKG domain, the following procedure is applied.

For verification, the Sub-PKG tries first to extract the patient secret value $\varkappa$ as follows:

• A mobile patient sends a request for $Su{b}_{PKGj}$ to obtain authentication and to be allowed to enter this domain.
• To achieve confidentiality, the mobile patient encrypts its request via $Su{b}_{PKGj}$’s public key.
• The request contains the patient signature, patient public key, group identity, hashed secret value, and nonce.
• $Su{b}_{PKGj}$ extracts the $\varkappa$ assuming that the Sub-PKG has initial values for each ${\sigma }_{sig},{\rm Y},and\gamma$ that exist in the global model. $x=M-({\sigma }_{sig}+{\rm Y}+\gamma$) then checks this value by hashing it then compares it with the received digest. After that, it hashes the message using hash algorithm h = H(M).
• $Su{b}_{PKGj}$ find the exact value of (r,s) after subtracting the patient’s secret value from each $\varkappa$.
• Calculate the modular inverse of the signature proof $s1=s^{(-1)}modn$.
• Recover the random point used during the signing: R’ = (h ∗ s1) ∗ G + (r ∗ s1) ∗ pubKey.
• Take from R’ its x-coordinate: r’ = R’.x.
• Calculate the signature validation result by comparing whether r’ == r.

4. Security Analysis

4.1. Security Proof Using AVISPA Tool

We conduct a comprehensive security verification using Automated Validation of Internet Security Protocols and Applications (AVISPA), which yields outcomes aligned with the protocol’s objectives. Initially scripted in CAS+, the protocol is subsequently translated into HLPSL code to scrutinize the integrity and confidentiality of crucial components such as keys, signatures, and confidential messages. As an illustration of our methodology, we instantiate three entities: $Roo{t}_{pkg}$, $Su{b}_{pkg}$, and the mobile patient. In the first phase, we focus on the authentication between $Roo{t}_{pkg}$ and $Su{b}_{pkg}$ as well as the secrecy of the local model of the $Su{b}_{pkg}$. The next two phases in the proposed protocol are the Patient Authentication Phase and the Patient Registration Phase. The results are simulated and indicate that the protocol is safe against attacks, see Appendix A.2.

4.2. BAN Logic

BAN logic [45,46] is used to formally verify the proposed protocol. BAN logic is a logic of authentication proposed by Burrows, Abadi, and Needham [45]. It uses inference rules and it is based on some initial assumptions to infer new facts that can lead to the aims being achieved. BAN logic has been used to analyze the security of authentication protocols against some of the most common attacks, like the Man-in-the-Middle attack, Intercept-and-Resend attack, and replay attack [47]. The proposed authentication protocol is verified using BAN logic, since it is useful to verify such protocols, which are based on fresh values and trust [48]. For further details regards BAN logic rules and notations, please refer to [45,49]. The full proof and analysis of the BAN logic are included in Appendix A.3.

4.3. Security Analysis Against Well-Known Attack

This section discussed the threat model and how the proposed scheme is secure against the most common attacks.

• Brute Force Attack: The attacker cannot reveal the private keys or the symmetric keys in a reasonable time. The EC private key cannot be calculated from the EC public key since it is an Elliptic Curve Discrete Logarithm Problem (ECDLP) [49,50]. The session key SK is generated using the ECDH algorithm which is based on the use of an EC private key for either the patient node or the SubPKG. Breaking ECDH session keys requires solving ECDLP, which is infeasible with classical computers. Consequently, brute force attacks will fail.
• Man-In-The Middle and Eavesdropping Attack: The attacker can intercept the communication between the patient’s node and the $Su{b}_{PKG}$ to read the data shared between these two entities; however, the attack will fail. In the Patient Authentication Phase, all messages are encrypted either using ECC to encrypt message 5.1 with the $Su{b}_{PKG}$ public key, or ECDH to encrypt messages 5.2 and 5.3 with the symmetric key SK. To decrypt the messages, the attacker should have the $Su{b}_{PKG}$ private key which is known only to the $Su{b}_{PKG}$ and the symmetric key SK which is known only to the patient node and the $Su{b}_{PKG}$. Consequently, this attack will fail.
• Replay Attack: The attacker will try to perform a replay attack by resending a valid message to the $Su{b}_{PKG}$; however, the $Su{b}_{PKG}$ can detect this attack. Replay attacks can be detected using nonce values. In the Patient Authentication Phase, whenever the patient node should be authenticated, a nonce N1 is generated at the node side and passed to the $Su{b}_{PKG}$. Another nonce N2 is also generated at the $Su{b}_{PKG}$ side and passed to the node. By verifying the freshness of these nonce values, both the patient’s node and the $Su{b}_{PKG}$ can detect the replay attack. A similar approach is used to detect replay attacks in the Patient Registration Phase; when the signature is calculated, a nonce value is generated by the node and passed to the $Su{b}_{PKG}$ along with the signature. By verifying the freshness of the nonce value, the $Su{b}_{PKG}$ will make sure that the signature is newly generated; if not, a replay attack is detected due to nonce verification failure.
• Signature Forgery Attack: The attacker tries to impersonate the patient’s node by forging the patient’s node signature; however, this attack will fail. In order to forge a signature, the attacker needs to know the group signature (${\sigma }_{GS}$), the identity of the group ($I{D}_g$), the root sign ($\gamma$), and the Sub-PKG sign (${\rm Y}$). These parameters are shared by the $Su{b}_{PKG}$ in an encrypted message during the Patient Registration Phase. The message is encrypted using a session key SK, which is known only to the patient node and the $Su{b}_{PKG}$; consequently, the attacker will not be able to know the parameters. In addition to these parameters, the attacker should know the patient node’s private key, which is known only to the node.
• Unauthorized Access and Identity Theft: If the attacker gains access to a patient’s signature, they could impersonate a patient and access personal health information. To mitigate this threat, all communication messages between the patient’s node and the $Su{b}_{PKG}$ are encrypted. Consequently, the attacker will not be able to access the patient’s signature.

5. Experimental Results and Discussion

In this section, a deeper analysis of the proposed protocol’s complexity in terms of storage, computation, and communication cost is presented. Moreover, a comparison with other related works in terms of several performance metrics is conducted.

5.1. Storage Cost

The storage cost refers to the amount of memory required to store the parameters necessary for establishing a shared key for the mobile patient node. Furthermore, the incurred cost varies based on the specific type of parameter stored within the mobile node.

The Total Storage Cost (TSC) is measured in bits by using the default sizes for each of them. The size of the symmetric key is fixed to 128 bits, and the identifier and the group signatures are saved in 256 bits for the mobile patient node. The public key size is 256 bits assuming that NIST P-256 curve (secp256r1) has been used [51].

In the proposed architecture, we focus on reducing the memory cost of the mobile node in terms of the number of keys and the number of initial parameters that each node should have. The following equation shows the exact complexity for the mobile patient node.

Table 4. The size in byte for each abbreviation in the proposed protocol.

Abbreviation	Size (Byte)
Digital Signature	64
Public Key	64
Private Key	64
Unique Identifiers	16
Shared Key	32
Patient Signature	64
Root Signature ($\gamma )$	64
Patient Secret Value ($\varkappa )$	64

presents the size of each parameter that has been used in this paper. The digital signature that has been used in the proposed protocol is based on ECDSA and NIST P-256 curve where r and s have 32 bytes. Therefore, the digital signature’s size is 64 bytes, while the public key and the private key have 64 bytes. Unique Identifiers (UIDs: 16 bytes) are used to identify each patient node.

Elliptic Curve Diffie–Hellman (ECDH) is used, so the size of the shared key is 32 bytes. The root and patient signature have 64 bytes while there is 64 bytes for the patient’s secret value [52,53,54].

Table 5. The storage complexity for each node in the proposed protocols.

Node Type	Storage	Size in (Bytes)
$Roo{t}_{PKG}$	$P{K}_{Root}$, $P{r}_{Root}$, $D{C}_{Root}$, root parameters $ϵ$, $\eta$, $\gamma$, n*${\rm Y}$.	384 + 64 n
$Su{b}_{PKG}$	$P{K}_{Sub}$, $P{r}_{Sub}$, $D{C}_{Sub}$, m*SK, $\gamma$, ${\rm Y}$	320 + 32 m
$Mobil{e}_{Patient}$	SK, $I{d}_i$, $P_{sig}$, $\gamma$, $\varkappa$	240

presents the storage complexity for each node in our architecture. It can be seen that the main objective of the proposed protocol is to reduce the storage complexity of the patient node due to the fact that each $Roo{t}_{PKG}$ and $SubPKG$ are considered powerful devices.

Table 6. The total number of shared keys that should be stored in each node.

Scheme	Number of Shared Keys
Our Proposal	1
[57]	1
[55]	2
[32]	3
[56]	2

presents a comparative study in terms of the memory storage costs required by the mobile nodes and different related protocols. The authors of [55] propose a new and improved group signature scheme base on federated learning. The main goal of their proposal is to reduce the commutation and computation cost to provide efficient privacy. In [56], a full dynamic secret sharing is proposed for federated learning. It can be noticed that our approach outperforms the others due to the fact that only one shared key is stored in the patient node. In [57], a Remote Authentication Method (RAM) with Autonomous Shared Keys (ASK) is introduced in the context of medical applications.

5.2. Computation Cost

The proposed scheme aims to authenticate the patient’s mobile node based on the computed patient signature. The computation cost analysis considers the patient signature generation cost $P_{sig}$, which is generated once in the Patient Registration Phase and reused in the Patient Authentication Phase, and the patient signature verification cost which is performed by the $Su{b}_{PKG}$ in the Patient Registration Phase and the Patient Authentication Phase. As discussed in Section 3.2.2, signature generation and verification are based on ECDSA.

Table 7. Notation used in computational cost analysis.

Metric	Description
$TM$	The computing time of the modular multiplication operation.
$TA$	The computing time of the modular addition operation (negligible).
$TIN$	The computing time of the modular inversion operation.
$TEM$	The computing time of the elliptic curve multiplication operation.
$TEA$	The computing time of the elliptic curve addition operation.

presents the notations used to measure the computation cost.

ECDSA Analysis: The cost and efficiency of ECDSA schemes depend on the number of operations used in the methods. Let TM represent the computing time required for the modular multiplication operation, TA the computing time required for the modular addition operation, and TIN the computing time required for the modular inversion operation. TEM represents the computing time required for the elliptic curve multiplication operation. Finally, TEA is the computing time required for the elliptic curve addition operation. According to the literature [58,59], TA is much less than TM and can be negligible. Assuming that TM is the main operation, the computation cost of TIN, TEM, and TEA in terms of modular multiplication operation TM can be calculated as follows: TIN = 11.6 TM, TEM = 29 TM, and TEA = 0.12 TM [58,59,60].

According to the computation cost required for different operations discussed above, we can analyze the computation cost of the ECDSA signature generation and verification as follows: To generate the signature on the mobile patient node, ECDSA requires one modular multiplication operation, one elliptic curve multiplication operation, and one modular inversion operation which equals TM + TEM + TIN = 41.6 TM. To verify the signature on the $Su{b}_{PKG}$ side, ECDSA requires two modular multiplication operations, two elliptic curve multiplication operations, one modular inversion operation, and one elliptic curve addition operation which equals 2TM + 2TEM + TIN + TEA = 71.72 TM. Note that, in our calculation, the modular addition operation is ignored as it is negligible [58,59].

Table 8. Computation cost for signature generation and verification.

Schemes	Signing Cost	Verification Cost	Node Cost	Server Cost
Our scheme	TM + TEM + TIN = 41.6 TM	2TM + 2TEM + TIN + TEA = 71.72 TM	41.6 TM (once)	71.72 TM*n
[58]	TM + TEM + TIN = 41.6 TM	2TM + 2TEM + TIN + TEA = 71.72 TM	41.6 TM*n	71.72 TM*n
[60]	TM + TEM = 30 TM	2 TEM + TEA = 58.12 TM	(30 TM + 58.12 TM)*n	(30 TM + 58.12 TM)*n
[59]	TM + 2TEM = 59 TM	2TEM + TEA = 58.12 TM	59 TM*n	58.12 TM*n

shows the computation cost compared with other signature-based authentication schemes from the literature. Note that n indicates whenever a node needs to be authenticated. The main advantage of our scheme is that even the signature generation cost is slightly higher than some related schemes; however, it is computed once on the mobile patient’s node. On the other hand, in the other schemes, the signature is generated every time a node/client should be authenticated.

5.3. Communication Cost

The communication cost in any network refers to the resources consumed during data transmission between devices or nodes [61]. In this paper, the number of exchanged messages required for any mobile patient node to be authenticated by its associated $Su{b}_{PKG}$ is analyzed. Figure 6 illustrates the differences in communication costs across various protocols for the mobile patient node in terms of the total number of messages and the number of nodes that should work together in order to distribute the key. It can be noticed that our proposed method demonstrates a lower communication overhead compared to the other related proposals.

In [56], the highest number of messages is shown for distributing the key between two nodes. In [32], the proposed approach maintains a moderate balance between the number of messages and nodes, while [57] shows a noticeable increase in total messages, though the number of nodes remains controlled. In contrast, our proposal effectively reduces both message exchanges and node involvement, enhancing efficiency in mobile environments.

6. Conclusions

Maintaining privacy and security is vital in healthcare systems, especially those that support mobile patients who need to be authenticated and protected while on the move. This study investigated the integration of the concept inspired by federated learning and the hierarchical structure of public key generators used in layered healthcare systems to authenticate different mobile patients. Both the BAN logic and the SPAN-AVISPA tool were used to verify the validity of the proposed architecture and the performance of key distribution protocols designed based on it. In addition, the storage requirement and computation and communication costs of the mobile patient nodes were used to assess the performance of the proposed protocol. The effectiveness of the proposed key distribution protocol outperformed other similar protocols in terms of reducing computation and communication costs. In addition, it reduced the number of messages needed for an authentication protocol and the number of shared keys that must be exchanged and stored at each patient’s mobile node to only one key.