LSAP-IoHT: Lightweight Secure Authentication Protocol for the Internet of Healthcare Things

1  Introduction

The Internet of Health Things (IoHT) represents a major innovation that integrates information technologies with medical care, forming an intelligent ecosystem of connected devices dedicated to health monitoring and management [1,2]. It encompasses a broad spectrum of technologies and application domains, ranging from biometric sensors and wearable devices to remote health monitoring platforms and connected medical equipment. IoHT is actively deployed in scenarios such as chronic disease management, emergency response, elderly care, postoperative recovery, and telemedicine. As illustrated in Fig. 1, these systems interact through wireless communication technologies, including Wi-Fi, Bluetooth, and cellular networks to collect, transmit, and analyze health data in real time [3,4]. By enabling continuous tracking of vital parameters like heart rate, blood pressure, glucose levels, and respiratory signals, IoHT supports mobile health (mHealth), intelligent drug delivery, and personalized healthcare services.

Figure 1: Internet of health things

However, the sensitive nature of health data, combined with the heterogeneity of interconnected devices, introduces substantial challenges regarding security and privacy [5–7]. Adversaries may exploit vulnerabilities through cyberattacks such as data interception, unauthorized access, and device tampering, all of which pose serious risks. In the absence of robust security mechanisms, sensitive medical information may be exposed to privacy breaches, thereby compromising patient confidentiality. Furthermore, compromised device integrity can result in erroneous diagnoses, inappropriate treatments, or even life threatening outcomes for patients [8,9].

1.1 Motivation and Contribution

With the increasing reliance on Internet of Health Things (IoHT) systems, securing sensitive medical data against cyber threats has become a critical concern, particularly given the potential consequences for patient safety. Although Chen et al. [10] introduced LAT-IoHT, an authentication protocol combining three-factor authentication, asymmetric encryption, and biometric data, our cryptanalysis has revealed significant security flaws. Specifically, LAT-IoHT is vulnerable to smart card theft, privileged insider attacks, and user impersonation.

To address these limitations, we propose LSAP-IoHT, a lightweight and secure authentication protocol tailored for IoHT environments, which offers the following advantages:

•   Our scheme combines Elliptic Curve Cryptography (ECC), Three-Factor Authentication (3FA), and hardware-level protection based on Physical Unclonable Functions (PUFs), enhancing resistance to duplication and physical attacks.

•   Through formal and informal analysis using the Real-Or-Random (ROR) model and the Scyther tool, our scheme is shown to ensure mutual authentication, session key confidentiality, and strong resistance to a wide range of attacks, including stolen smart device attacks, identity spoofing, replay attacks, man-in-the-middle (MITM) attacks, and privileged insider threats.

•   Our scheme achieves these security properties while maintaining low computational and communication overhead, making it particularly suitable for deployment in resource constrained IoHT environments.

•   Comparative evaluation with related authentication protocols confirms that our scheme provides enhanced security guarantees with low computational complexity and communication cost.

1.2 Paper Outline

This article is structured as follows. Section 2 discusses existing authentication mechanisms developed for IoHT, emphasizing their main features and limitations. Section 3 investigates the authentication scheme introduced by Chen et al. [10], highlighting the cryptographic vulnerabilities identified through a detailed security evaluation. Section 5 presents our proposed authentication scheme, referred to as LSAP-IoHT. Section 6 describes the results of the security verification conducted using the Scyther tool and the Real-Or-Random (ROR) model. Section 7 provides a comparative assessment of LSAP-IoHT and other protocols designed for IoHT environments. Finally, Section 8 concludes the paper by summarizing the main contributions.

2  Related Works

This section reviews key literature on authentication protocols for the Internet of Health Things (IoHT), focusing on foundational contributions, recent advancements, and emerging trends relevant to this study.

Kumar et al. [11] introduced RAPCHI, a robust protocol for cloud-based connected health infrastructures. By employing digital signatures, it secures authentication and key agreement among patients, cloud servers, and doctors. RAPCHI resists man-in-the-middle and replay attacks, as validated through AVISPA simulation.

Aghili et al. [12] developed an access control and ownership transfer protocol for IoHT, addressing vulnerabilities in the ZZTL protocol [13] related to user traceability, denial-of-service (DoS), insider threats, and desynchronization attacks. Their architecture involves users, medical servers, and patients, ensuring authentication, confidentiality, and seamless privilege transfer. Focusing on lightweight designs for sensor networks,

Soni et al. [14] developed an authentication protocol using smart cards, improving upon the weaknesses identified in Challa et al.’s work [15] by integrating a three-factor approach suited to remote patient monitoring. To accommodate heterogeneous IoHT environments and enhance efficiency, Ullah et al. [16] proposed a certificate-less authentication scheme that employs hyperelliptic curve cryptography (HECC) with 80-bit keys. This construction is particularly appropriate for resource-constrained wireless body area networks (WBANs), offering robust protection against common cyber threats while reducing computational overhead.

Rabie et al. [17] proposed a distributed, privacy-preserving protocol for certificate-less medical sensor networks. Using XOR operations, it aggregates signatures from sensor nodes, thereby reducing centralization. The system includes wearable sensors, zonal nodes, and medical servers, and it prioritizes data privacy during transmission. Xie et al. [18] introduced CasCP, an enhanced certificate-less authentication scheme for WBANs, which addresses weaknesses in Ji et al.’s protocol [19]. It ensures conditional privacy preservation and improves security. Thakur et al. [20] proposed an authentication scheme for WMSN-based medical systems that counters identity spoofing and password guessing attacks. Building on the protocol of Servati and Safkhani [21], it retains a five-phase structure while enhancing security properties. Li et al. [22] developed a three-factor authentication protocol for WMSNs, improving upon the scheme of Amin and Biswas scheme [23] after identifying several vulnerabilities. Based on ECC, the protocol ensures secure transmission of sensitive medical data. Sureshkumar et al. [24] proposed a lightweight ECC-based authentication scheme for WMSNs. Its correctness was formally verified using Burrows-Abadi-Needham (BAN) logic.

In [25], the authors propose a secure communication approach for IoT networks based on key management and authentication. Their method improves data protection, energy efficiency, and overall network performance. In [26], the authors propose an improved lightweight authentication protocol to address security and privacy issues in IoT-based smart healthcare systems. The protocol ensures mutual authentication and secure session key establishment between doctors, gateways, and sensor nodes. Security analysis confirms its efficiency and resistance to various attacks, including identity anonymity and untraceability.

Finally, Chen et al. [10] introduced LAP-IoHT, a three-factor authentication protocol that combines asymmetric encryption and biometric data to ensure confidentiality. It authenticates users and sensors through a gateway, establishes a shared session key, and encrypts biometric features to preserve user anonymity. Its security was analyzed using the Real-or-Random (ROR) model.

Table 1 summarizes the reviewed works by emphasizing their cryptographic features, verification tools, and protocol phases. It also compares them by highlighting their advantages and limitations. In the next section, we detail the workings of LAP-IoHT in particular and reveal its vulnerabilities.

3  LAP-IoHT Cryptanalysis

This section provides an overview of the LAP-IoHT protocol and highlights its security weaknesses, despite its original claim of being secure in the study by Chen et al. [10].

3.1 Review of LAP-IoHT

The LAP-IoHT protocol [10] is a lightweight authentication scheme designed for the Internet of Health Things (IoHT). It employs three-factor authentication, asymmetric encryption, and biometric verification to secure the transmission of sensitive health information. The protocol is structured into two main phases: the registration phase (covering both user and sensor registration) and the authentication phase. In what follows, we denote the user, gateway, and sensor by Ua, GWb, and SNc, respectively. The user and sensor identities are represented as IDa and IDc, and the user’s password is noted PWa. Biometric data is referred to as bio, the random nonces used throughout the protocol are denoted ra, rb, rc, and ri and Gj represents the secret key of the gateway.

3.1.1 Registration Phase

User Registration Phase

If the user Ua wishes to be a legitimate user, this user must register with the GWb. Messages are transmitted via a secure channel.

Step 1: The user Ua possesses IDa, PWa, and the biometric data Bio and chooses a random number ri. Ua computes HIDa=h(IDa∥ri), Gen(Bio)=(σa,τa), HPWa=h(PWa∥σa), and N=PWa⊕h(IDa∥σa). Ua sends to GWb the message {HIDa,HPWa,N}.

Step 2: GWb verifies if HIDa has already been registered. Then, computes D1=h(HIDa∥N), D2=(D1∥Gj)⊕HPWa, D3=D2⊕N, D4=h(HIDa∥Gj)⊕D1. GWb sends to Ua the message {D1,D3,D4}. GWb stores (HIDa,D1) in its database.

Step 3: Ua computes Ωa=N⊕ri and M=h(N∥ri)⊕HIDa. Ua stores {D1,D3,D4,Ωi,M} in its smart card.

Sensor Registration Phase

A sensor must also be registered before it can join the network with GWb. Messages are transmitted via a secure channel.

Step 1: The sensor SNc sends its identity IDc to GWb.

Step 2: GWc generates a random number b and computes the pseudo-identity of SNc, PIDc=h(IDc∥b)andHSIDc=h(IDc∥Gj). Then, it calculates SG=h(HSIDc∥Gj)⊕PIDcandL=ENCpbs(PIDc). GWb sends to SNc the message {SG, L}. GWb stores (SIDc,PIDc) in its database.

Step 3: SNc stores {SG, L} in its own memory.

3.1.2 Authentication Phase

If Ua requests a connection to a specific portable sensor SNc, GWb must verify the legitimacy of the user.

Step 1: Ua inserts its smart card into a computer or card reader and provides its IDa, PWa, and Bio. The computer computes σa=Rep(Bio,τa),N=PWa⊕h(IDa∥σa), and M′=h(N∥ri)⊕HIDa,whereri=N⊕Ωa. Then, it determines if M′ is equal to M stored in the smart card. If so, it generates a random number ra and a timestamp T1 and computes HPWa=h(PWa∥σa),K1=D3⊕N⊕HPWa, K2=K1⊕ra,Xug=h(T1∥ra∥HIDa∥K2). Ua sends to GWb the message {HIDa,K2,Xug,T1}.

Step 2: GWb verifies the freshness of T1. Then, it computes K1=h(D1∥Gj),ra=K1⊕K2, and Xug′=h(T1∥ra∥HIDa∥K2). If the received Xug is equal to the calculated Xug′, GWc computes a random number rc and a timestamp T2, HSIDc=h(IDc∥Gj),K3=ra⊕h(HSIDc∥Gj), K4=D1⊕h(K3∥IDc∥ra),K5=rc⊕h(D1∥ra), K6=K3⊕PIDc,Xgs=h(T2∥ra∥rc∥IDc∥K5). GWb sends to SNc the message {K4,K5,K6,Xgs,T2}.

Step 3: SNb verifies the freshness of T2. Then, SNc obtains PIDc by decrypting L using the private key, computes K3=K6⊕PIDc,ra=K3⊕SG⊕PIDc, D1=K4⊕h(K3∥IDc∥ra),rc=K5⊕h(D1∥ra), Xgs′=h(T2∥ra∥rc∥IDc∥K5). If the received Xgs is equal to the calculated Xgs′, SNb calculates a random number rb and a timestamp T3, K7=rb⊕h(SG∥D1∥rc),K8=PIDc⊕K7, Xsg=h(T3∥rc∥rb∥K7∥SG),Xsu=h(ra∥rb∥IDc∥D1). Finally, SNc calculates the session key SK=h(ra∥rb∥rc). SNc sends to GWb the message {K8,Xsg,Xsu,T3}.

Step 4: GWb verifies the freshness of T3. Then, it computes K7=PIDc⊕K8,SG=h(HSIDc∥Gj)⊕PIDc, rb=K7⊕h(SG∥D1∥rc),Xsg′=h(T3∥rc∥rb∥K7∥SG). If the received Xsg is equal to the calculated Xsg′, GWb computes a timestamp T4, K9=D1⊕K1,K10=K9⊕h(HIDa∥Gj)⊕rb, K11=IDc⊕h(K1∥rb),Xgu=h(T4∥ra∥rc∥K10)for mutual authentication. Finally, GWb calculates the session key SK=h(ra∥rb∥rc). GWb sends to Ua the message {K5,K10,K11,Xgu,Xsu,T4}.

Step 5: Ua verifies the freshness of T4. Then, it calculates rb=K1⊕K10⊕D4,rc=K5⊕h(D1∥ra), and calculates Xgu=h(T4∥ra∥rc∥K10). If the received Xgu is equal to the calculated Xgu′, Ua calculates the session key SK=h(ra∥rb∥rc).

3.2 Security Weaknesses of LAP-IoHT

3.2.1 Smart Card Theft Attack

The attacker A obtains {D1,D3,D4,Ωa,M} stored in the stolen smart card.

3.2.2 Privileged Insider Attack

Suppose the attacker A is a privileged insider of the system. The attacker will take HPWa and N. Knowing that K1=h(D1∥Gj), the attacker can find K1 from D2 of the previous attack. The attacker already has D3, so they also have D2 since D3=D2⊕N. Knowing that D2=h(D1∥Gj)⊕HPWa, by applying another ⊕HPWa, the attacker obtains h(D1∥Gj), which is K1. Now, K2=K1⊕ra, the attacker could find K1, so from K2, we can say that the attacker possesses ra.

3.2.3 User Identity Impersonation Attack

Fig. 2 illustrates the user impersonation attack where the attacker A seeks to generate a valid Message 1 containing {HIDa,K2,Xug,T1} in the connection and authentication phase, while knowing that the attacker already possesses {ru,K1,K2,D1,D3,D4,Ωa,M,HPWa}. Since HIDa was sent via a public channel, they can also obtain it. We have Xug=h(T1∥ra∥HIDa∥K2) and the attacker has obtained all of these. Since the generated Message 1 by the attacker contains the original identification information of user Ua, the generated message will pass the verification phase. Attacker A has successfully impersonated the identity of the user. In Message 5, K5=rc⊕h(D1∥ra) the attacker possesses D1 and ra, so they can obtain rc. rb=K1⊕K10⊕D4=K1⊕K9⊕h(HIDa∥Gj)⊕D4=K1⊕D1⊕K1⊕h(HIDa∥Gj)⊕h(HIDa∥Gj)⊕D1⊕rb thus the attacker can also obtain rb. As the attacker possesses ra, rb, and rc, they now have the secret key SK=h(ra∥rb∥rc).

Figure 2: User identity impersonation attack

4  Preliminaries and System Model

This part presents the necessary background to enhance the clarity of the article.

4.1 Elliptic Curve Cryptography (ECC)

Elliptic Curve Cryptography (ECC) is a method based on elliptic curves defined over a finite field. Consider two large prime numbers p and q; an elliptic curve Eq(u,v) is defined by the equation: y2=x3+ux+v(modq) where u,v∈Zq, and the discriminant Δ=4u3+27v2≢0(modq) ensures that the curve is non singular. The set of all points (x,y) satisfying the curve equation, along with the point at infinity O, form an additive group G of order p. Let P be a generator of this group. Scalar multiplication over the group is defined by repeated addition: x⋅P=P+P+⋯+P⏟x times. The group operation satisfies the property: x⋅P+y⋅P=(x+y)⋅Pfor all x,y∈Zq.

4.2 Physical Unclonable Function (PUF)

Due to physical variations during chip fabrication, a Physical Unclonable Function (PUF) generates a unique, non-replicable output for each input, following a challenge-response approach. Unlike conventional cryptographic systems that store fixed keys, PUFs dynamically produce device-specific secrets, eliminating the need for key storage. If a device is compromised, the internal structure of the PUF is affected, altering its output and ensuring security without consuming memory. Given a challenge Ci and a corresponding response Ri, the relation is defined as Ri=PUF(Ci). The LSAP-IoHT protocol leverages this capability by integrating PUF into the gateway, sensor nodes, and user side to protect against physical attacks.

4.3 Network Model

The proposed health system model is illustrated in Fig. 3. In this paradigm, the workflow of the proposed protocol consists of three main entities: sensors, users, and the gateway.

Figure 3: Proposed health system model

4.3.1 Sensors

These sensors are placed or implanted in the human body, and their main role is to collect various health-related data, such as ECG, blood pressure, blood glucose, respiratory rate, and body temperature.

4.3.2 Users

In the proposed system model, users are primarily represented as doctors who have authorized access to patients medical data. These doctors use the system to monitor and analyze patients conditions, prescribe treatments, and make informed therapeutic decisions based on the data provided by the sensors.

4.3.3 Gateway

The gateway acts as a pivot to orchestrate communication between users and sensors, serving as a trusted intermediary that facilitates transparent communication. It constitutes a main unit where information is authenticated and securely linked among the various components of the system.

4.4 Adversary Model

In Internet of Health Things (IoHT) systems, the Dolev–Yao model [27] is applied to represent hostile network conditions. This framework presumes that an attacker, labeled A, can access all exchanges over unsecured links. Moreover, A is capable of discarding transmissions, changing message content, or introducing counterfeit data into the flow of communication.

5  The Proposed LSAP-IoHT Protocol

To address the security vulnerabilities we identified in LAP-IoHT [10], we propose a new reliable and efficient authentication scheme for the IoHT called: Lightweight Secure Authentication Protocol for the IoHT (LSAP-IoHT). The LSAP-IoHT protocol ensures secure authentication between the user, the gateway, and the sensor. Fig. 4 outlines the message exchanges leading to mutual verification and the establishment of a session key.

Figure 4: Sequence diagram of the authentication steps in the proposed scheme

5.1 Protocol Phases

The improved system incorporates the following four phases:

•   Initiation phase

•   User registration phase

•   Sensor registration phase

•   Authentication phase

Table 2 summarizes the different annotations used for our protocol.

5.1.1 Initiation Phase

This phase is considered to be applied before the commencement of the protocol in a secure environment. Each entity gateway, sensor, and user is equipped with PUF (Physical Unclonable Function) technology and has a Challenge-Response based on PUF, referred to as CRP. The gateway has the CRPs of both the sensors and the users (CRPs, CRPa), while both the sensors and users possess the CRP of the gateway (CRPb). This protocol uses a lightweight ECC (Elliptic-Curve Cryptography) system for smart devices as shown in Fig. 5.

Figure 5: Initialization phase

5.1.2 User Registration Phase

For the user Ua to be recognized as a legitimate user, they must be registered with GWb. Once this registration is completed, all exchanged messages will be transmitted via a secure channel to ensure the confidentiality and integrity of the communications as shown in Fig. 6.

Figure 6: User registration phase

Step 1: The user Ua has IDa, PWa, and the PUF generates the unique challenge-response CRPa(Ca,Ra) and chooses a random number NA. Ua calculates V1=PWa⊕NA, V2=IDa⊕NA, C1=h(V1‖V2).P. Ua sends to GWb: { C1 }

Step 2: GWb has IDb and the PUF generates the unique challenge-response CRPb(Cb,Rb) and chooses a random number NB, then calculates V3=IDb⊕NB, C2=h(V3‖Rb).P. The session key SKug=C1⋅h(V3‖Rb). GWb sends to Ua: { C2 }

Step 3: Ua can now calculate the session key SKug=C2⋅h(V1‖V2). Ua calculates HIDa=h(IDa‖Ra), HPWa=h(PWa‖Ra). Ua sends to GWb: ENCSKug{HIDa,HPWa,CRPa(Ca,Ra)}

Step 4: GWb verifies Ua’s identity using the PUF, then calculates D1=h(HIDa‖HPWa), D2=(D1‖HIDa‖Rb), D3=D2⊕D1. GWb sends to Ua: ENCSKug{D1,D2,D3,CRPb(Cb,Rb)}

Step 5: Ua verifies GWb’s identity using the PUF, then Ua calculates M=h(IDa‖NA)⊕HIDa

5.1.3 Sensor Registration Phase

A portable sensor must also be registered with GWb before it can connect to the network. Once registered, messages are transmitted via a secure channel, thereby ensuring the security of communications as shown in Fig. 7.

Figure 7: Sensor registration phase

Step 1: The sensor SNc has IDc, PWc, and the PUF generates the unique challenge-response CRPc(Cc,Rc) and chooses a random number Ns. SNc calculates G1=PWc⊕Ns, G2=IDa⊕Ns, F1=h(G1‖G2).P. SNc sends to GWb: { F1 }

Step 2: GWb has IDb and the PUF generates the unique challenge-response CRPb(Cb,Rb) and chooses a random number NB1, then calculates G3=IDb⊕NB1, F2=h(G3‖Rb).P. The session key SKsg=F1⋅h(G3‖Rb). GWb sends to SNc: { F2 }

Step 3: SNc can now calculate the session key SKsg=F2⋅h(G1‖G2). SNc sends to GWb: ENCSKsg{IDc,CRPc(Cc,Rc)}

Step 4: GWc generates a random number NB2 and calculates the pseudo-identity of SNc: PIDc=h(IDc‖NB2) and HSIDc=h(IDc‖NB2‖Rb), SG=h(HSIDc‖Rb)⊕PIDc. GWb sends to SNc: ENCSKsg{PIDc,HSIDc,SG,CRPb(Cb,Rb)}

5.1.4 Authentication Phase

Fig. 8 depicts the steps of the authentication phase. When Ua requests a connection to a specific portable sensor SNc, GWb must confirm that the user is legitimate.

Figure 8: Authentication phase

Step 1: Authentication request

Ua inserts its smart card into a computer or smart card reader, providing its IDa, PWa, CRPa(Ca,Ra). This computer calculates M′=h(IDa‖NA)⊕HIDa, then determines if M′ is equal to M stored in the smart card. If so, it generates a random number ra and a timestamp T1 and calculates K1=h(D1‖Ra), K2=K1⊕ra, Z1=h(IDa‖PWa‖Ra).P, Xug=h(T1‖ra‖Z1). Ua sends to GWb: { K2,Xug,Z1,T1 }

Step 2: Verification of authentication parameters and forward the authentication request

GWb verifies the freshness of T1. Then, it calculates K1′=h(D1‖Ra), ra=K1′⊕K2, Xug′=h(T1‖ra‖Z1). If the received Xug equals the calculated Xug′, GWc calculates a random number rb and a timestamp T2: K3=ra⊕h(HSIDc‖Rb), K4=K3⊕PIDc, K5=rb⊕HSIDc⊕ra, Xgs=h(T2‖ra‖rb‖Z1‖IDc). GWb sends to SNc: { K4,K5,Xgs,Z1,T2 }

Step 3: Verification of the authentication request, authenticity verification response and generate the session key

SNc verifies the freshness of T2. Then, SNc calculates K3′=K4⊕PIDc, ra=K3′⊕SG⊕PIDc, rb=K5⊕HSIDc⊕ra, Xgs′=h(T2‖ra‖rb‖Z1‖IDc). If the received Xgs equals the calculated Xgs′, SNc calculates a random number rc and a timestamp T3: K6=rc⊕h(SG‖Rc‖rb), K7=PIDc⊕K6, Z2=h(PWc‖IDc‖Rc).P. Xsg=h(T3‖rc‖rb‖Z2‖SG). Finally, SNc calculates the session key SKsu=ra⋅rc⋅Z1⋅h(PWc‖IDc‖Rc). SNc sends to GWb: { K7,Xsg,Z2,T3 }

Step 4: Verification of the authenticity response and forward the authentication response

GWb verifies the freshness of T3. Then, it calculates K6′=PIDc⊕K7, rc=K6′⊕h(SG‖Rc‖rb), Xsg′=h(T3‖rc‖rb‖Z2‖SG). If the received Xsg equals the calculated Xsg′, GWb calculates a timestamp T4: K8=rc⊕h(D1‖K1), K9=K8⊕h(HIDa‖Rb), and calculates Xgu=h(T4‖rc‖Z2‖Rb‖ra) for another mutual authentication. GWb sends to Ua: {K9,Xgu,Z2,T4 }

Step 5: Verification of authentication parameters and generate the session key

Ua verifies the freshness of T4. Then, it calculates K8′=K9⊕h(HIDa‖Rb), rc=K8′⊕h(D1‖B1), and calculates Xgu=h(T4‖rc‖Z2‖Rb‖ra). If the received Xgu equals the calculated Xgu′, Ua calculates the session key SKsu=ra⋅rc⋅Z2⋅h(PWa‖IDa‖Ra)

6  LSAP-IoHT Security Analysis

This part thoroughly investigates the protection mechanisms embedded in LSAP-IoHT, highlighting its ability to withstand diverse cyber threats. In addition to an intuitive evaluation underscoring the scheme’s strength, we apply structured verification techniques. Leveraging the Real-or-Random model, we perform an in depth theoretical validation of the protocol. Furthermore, we employ Scyther, a widely recognized verification framework, to test the protocol’s resilience through automated analysis.

6.1 Informal Analysis

In this analysis, we prove the LSAP-IoHT protocol resistance to known attacks.

6.1.1 Forward Secrecy Property

If persistent credentials are exposed, earlier session information must remain protected. Within our protocol, secret values such as Skug and SKsg are independently and randomly selected. As a result, obtaining SKSU does not enable reconstruction of any prior session secrets.

6.1.2 Replay Attack

In our proposed protocol, transmitted messages include timestamps and random numbers, such as T1,T2,NA, and NB. Timestamps and random numbers are two effective means of preventing replay attacks. By incorporating these mechanisms, our protocol ensures resistance to replay attacks, thus preserving the security and integrity of communications.

6.1.3 Identity Spoofing Attack

For each entity in the system, gateway node, sensor node, and user we used double authentication verification for each transmitted message. Additionally, we adopted a three-factor authentication. Each entity is equipped with an identity, password, and a unique Challenge-Response Pair (CRP) from the PUF. This multi-level security approach ensures that even if an attacker tries to infiltrate the system, they will fail to bypass the double authentication verification.

6.1.4 Insider Attack

The proposed protocol is secure against insider attacks through the implementation of PUF (Physically Unclonable Functions). Each system entity is authenticated using a unique PUF Challenge-Response Pair (CRP), which cannot be duplicated or predicted. This ensures that even privileged insiders, who might have access to other authentication details, cannot replicate the unique PUF responses of other entities. Even if an attacker obtains some data, they will not be able to find the keys since some of the data used to generate the keys was never transmitted.

6.1.5 Physical Attack

The simplicity of IoHT devices makes them highly vulnerable to adversaries. During a physical attack, an attacker may obtain direct access to an IoT device, retrieve its secret keys, and even clone it. The protocol is considered secure against these types of attacks because PUFs and device authentication are implemented on the same chip, ensuring a trusted and secure communication process.

6.1.6 Man-in-the-Middle Attack (MITM)

Our proposed protocol is deemed resistant to MITM attacks because it needs to know specific information to construct valid data and initiate the attack. Discovering all this information is not feasible for an active adversary positioned on the communication line between the three parties involved in the communication.

6.1.7 Stolen Smart Device Attack

The LSAP-IoHT protocol is resilient to stolen device attacks due to its use of physically unclonable functions (PUFs), session dependent secrets, and mutual authentication. Even if an attacker obtains a user’s smart card or a registered sensor, critical values such as session keys, pseudo-identities, and challenge-response pairs remain protected through dynamic nonces and device specific computations. Without knowledge of the user’s password, random nonces, and the unique PUF-based secrets, an adversary cannot impersonate a legitimate entity or reconstruct valid authentication messages.

6.2 Security Evaluation under the ROR Framework

The Real-or-Random approach represents a commonly adopted technique for formally demonstrating the confidentiality of session keys within cryptographic protocols [28]. The LSAP-IoHT protocol involves three main participants: Ua, GWb, and SNc. We denote the x-th instance of the user as θUax, the y-th instance of the gateway as θGWby, and the z-th instance of the sensor as θSNcz. The complete set of protocol participants is represented as: ℱ={θUax, θGWby, θSNcz}.

•   Execute (ℱ) Query: When this operation is invoked, the adversary is able to eavesdrop on the communication exchanged between the participants Ua, GWb, and SNc via an open transmission medium.

•   Send (θi, m): This query allows the adversary to transmit a message m to instance θi. The adversary then observes the corresponding output, as generated by the protocol in response.

•   Corrupt (θi): When this request is performed, the adversary acquires confidential elements linked to a specific participant. These may include persistent secrets, ephemeral data, or stored credentials within a smart device.

•   Hash (): Using this function, the adversary is able to compute the digest corresponding to a given input of predetermined size.

•   Test (θi): Suppose the adversary initiates this request to evaluate the confidentiality of a session key. A virtual coin C is flipped. If C=1, the challenger provides the genuine session key; otherwise, a randomly chosen value is returned to the adversary.

Theorem 1: In the ROR model [28], we define AdvALSAP−IoHT as a function of the attacker’s ability to compromise the protocol through query operations; that is, the probability that 𝒜 can distinguish the session key from a random value. The advantage is bounded as follows: Within the Real-or-Random framework, the adversary’s success metric, denoted as AdvALSAP−IoHT, quantifies its potential to undermine the protocol by interacting with various oracles. In particular, this value represents the likelihood that the attacker retrieves a valid session secret via the allowed query mechanism.

AdvALSAP−IoHT≤qh2|Hash|+qp2|PUF|+2⋅AdvECDLP(1)

•   qh2: total number of queries made to the hash function,

•   qp2: number of times the adversary queries the PUF component,

•   |Hash|: domain size of the hashing function output,

•   |PUF|: range of values producible by the PUF responses,

•   AdvAECDLP(): success probability of adversary A in solving the elliptic curve discrete logarithm problem.

To validate the correctness of the Theorem, the proof proceeds through five game stages, denoted as GMi for i=0,1,2,3,4. Let SuccGMiA represent the probability that adversary A succeeds in each respective phase. The sequence is outlined as follows:

Game 0: At this initial game, the adversary attempts to guess a hidden bit b without issuing any oracle requests. Hence, the advantage is calculated as:

AdvALSAP−IoHT=|2⋅Pr[SuccGM0A]−1|(2)

Game 1: The adversary gains access to the Execute oracle, which allows it to passively observe full protocol executions between the user, gateway, and sensor. This includes all exchanged messages such as { K2,Xug,Z1,T1 }, { K4,K5,Xgs,Z1,T2 }, and the final messages that lead to session key derivation. Despite having access to the complete message transcript, the adversary cannot compute the session key SKsu=ra⋅rc⋅Z2⋅h(PWc∥IDc∥Rc) because it depends on the hardness of the elliptic curve discrete logarithm problem, the random nonces ra, rc, and PUF-protected values, which are never transmitted in clear. Hence, the adversary’s ability to distinguish the session key does not increase:

Pr[Succ1]=Pr[Succ0](3)

Game 2: In this game, the adversary is allowed to interact with the Hash oracle, attempting to infer internal values involved in session key derivation. For instance, values such as Z1=h(IDa∥PWa∥ra)⋅PandZ2=h(PWc∥IDc∥Rc)⋅P depend on secrets and random nonces that are not available to the adversary. Without being able to guess or find collisions on these internal values, the adversary’s view in this game remains indistinguishable from that in Game 1. According to the birthday bound, the probability that a collision occurs is bounded as follows:

|Pr[Succ2]−Pr[Succ1]|≤qh22⋅|Hash|(4)

Game 3: This game models a stronger adversary who can invoke the Corrupt oracle on a participant (e.g., sensor or user), thereby retrieving stored values such as challenge-response pairs, encrypted identities, or PUF-related secrets. However, the session key relies on PUF-derived data, such as Rc whose outputs are inherently unstable or context dependent due to the physical properties of strong PUFs. Therefore, even with access to stored values, the adversary cannot reproduce valid responses or derive session secrets without replicating the exact environmental conditions under which the PUF was originally evaluated.

The difference in advantage between this game and the previous one is bounded by:

|Pr[Succ3]−Pr[Succ2]|≤qp22⋅|PUF|(5)

Game 4: In the final game, the adversary has access to all protocol transcripts and internal values, including those retrieved through Corrupt and Execute queries. The only remaining unknowns are secrets derived through elliptic curve multiplication, such as recovering h(PWa∥IDa∥ra)orh(PWc∥IDc∥Rc) from the values Z2 and Z1, respectively. This problem directly reduces to solving the Elliptic Curve Discrete Logarithm Problem (ECDLP). Under standard cryptographic assumptions, solving ECDLP in polynomial time is considered infeasible. Therefore, the difference in advantage between this game and the previous one is bounded by:

|Pr[Succ4]−Pr[Succ3]|≤AdvAECDLP(6)

After simulating the sequence of games Game0 to Game4, we apply the triangle inequality to bound the adversary’s overall advantage. Each game introduces a new capability for the adversary 𝒜, and at each step, we carefully bound the difference in success probability.

Based on the individual game transitions Eqs. (1)–(6), we obtain:

|Pr[Succ0]−Pr[Succ4]|≤qh22|Hash|+qp22|PUF|+AdvAECDLP(7)

We conclude: AdvALSAP−IoHT≤qh22|Hash|+qp22|PUF|+AdvAECDLP

6.3 Formal Analysis

In this section, we conduct an in-depth analysis of the proposed protocol, performing formal verification using the SCYTHER tool. This approach aims to assess the robustness and reliability of the protocol in various scenarios and identify potential vulnerabilities. Using SCYTHER allows us to model the protocol in a simulated environment, where we can explore different parameters and configurations to evaluate its performance and security. This methodical approach provides valuable insights into the protocol’s strength, allowing us to take corrective measures if necessary and ensure optimal security for our system. Scyther is a sophisticated verification tool tailored specifically for security protocols, operating under the assumption that all cryptographic functions are flawless [29]. It stands out with its intuitive graphical user interface, making it simple to verify and understand protocols. Whenever an attack is detected concerning a specific claim, Scyther generates corresponding attack graphs, providing a clear visualization of potential vulnerabilities. Furthermore, Scyther can examine all conceivable claims regarding a given protocol. This tool is also valuable in identifying issues arising from protocol design. Additionally, Scyther is capable of generating all possible trace models, allowing for an exhaustive analysis of potential scenarios. The verification can be performed with a limited or unlimited number of sessions, providing optimal flexibility in security assessment [30]. To write protocols in Scyther, we use the SPDL Language(Security Protocol Description Language), which ensures clear syntax and precise protocol representation.

Fig. 9 illustrates an example of SPDL, representing a section of the connection and authentication phase of our proposed protocol. In this excerpt, the three main roles of the system are declared: the “gateway,” the “sensor,” and the “user.” The messages exchanged between these entities are also specified, describing the flow of information during the login and connection phase.

Figure 9: Authentication phase in SPDL

After subjecting our protocol to an in-depth formal analysis using the Scyther tool, which is widely used by researchers to evaluate various security systems in related previous works, we can confirm that our system meets the highest security standards. The results of the analysis conclusively demonstrated that our protocol is robust and resilient against various potential attacks, as shown in Fig. 10. By using Scyther, we were able to model and simulate different situations and interactions, thoroughly verifying every aspect of the protocol and identifying any potential weaknesses.

Figure 10: Result of formal verification

In summary, the formal analysis conducted using the Scyther tool confirms the security and reliability of our protocol, further strengthening our confidence in its ability to protect data and ensure the integrity of communications.

7  Comparative Analysis

In this section, we compare the security features of similar IoHT authentication protocols and we evaluate the computational and Communication costs of each one. Our analysis focuses on how well these protocols resist various attacks and the efficiency of their operations, highlighting the balance between security and performance.

7.1 Security Comparisons

We compare LSAP-IoHT with several related protocols that follow similar architectures. In the comparison table, a “Y” indicates that the protocol is resistant to a specific attack, while an “X” indicates vulnerability. The attack types considered are as follows:

•   R1: replay attack

•   R2: impersonation attack

•   R3: insider attack

•   R4: man-in-the-middle attack

•   R5: known session-specific temporary information attack

•   R6: stolen smart card attack

•   R7: offline password guessing attack

•   R8: sensor node capture attack

•   R9: de-synchronization attack

•   R10: session key disclosure attack

•   R11: denial of service (DoS) attack

•   R12: message modification attack

The results presented in Table 3, show that many existing protocols are susceptible to these types of attacks. In contrast, LSAP-IoHT demonstrates stronger resistance against these threats, providing enhanced security and robustness for communication sessions in IoHT environments. Our cryptanalysis revealed that LAP-IoHT is vulnerable to a wide range of cyberattacks, including man-in-the-middle attacks, replay attacks, and identity spoofing. Despite their claims of robustness, we identified several critical weaknesses that compromise the integrity and confidentiality of the exchanged data. These vulnerabilities indicate that the protocol fails to provide the level of security required for sensitive healthcare applications, leaving them exposed to significant risks.

7.2 Computation Cost Analysis

In this section, we evaluate the performance of the LSAP-IoHT protocol by comparing it with other related protocols in terms of computational and communication efficiency. Specifically, in Table 4, we analyze the number of cryptographic operations required, based on the findings in [10]. The time to perform a single hash function operation (HF) is 0.0031 ms for the gateway and 0.0022 ms for the sensor node. For fuzzy extraction operations (FE), it takes 2.2823 ms for the gateway and 1.6197 ms for the sensor node. A single elliptic curve point multiplication (ECCM) requires 16 ms for the gateway and 13 ms for the sensor node, while an elliptic curve point addition (ECCA) takes 0.016 ms for the sensor node and 0.002 ms for the gateway. Additionally, symmetric encryption or decryption operations (AC) require 5.2520 ms for the gateway and 3.7272 ms for the sensor node. We also examine the number of messages exchanged between the user (U), gateway (G), and sensor (S), as well as the total computation time (in milliseconds). According to Table 4, LSAP-IoHT achieves a total computation time of 58.0566 ms, which is lower than [12] (58.5637 ms), [15] (87.0212 ms), [17] (84.9694 ms), and [18] (106.038 ms). This clearly highlights its superior efficiency. Fig. 11 illustrates the computation cost analysis curves.

Figure 11: The result of computational cost between our scheme and other schemes existing in the literature [1,13,14,17,19]

The combined analysis of Tables 3 and 4 highlights the critical importance of LSAP-IoHT in IoHT systems. Although reference [10] achieves better performance in terms of total computational time, it remains vulnerable to several major security threats. In contrast, LSAP-IoHT successfully resists a wide range of attacks while maintaining a lower computational cost compared to references [12,15,17,18]. It is also the only protocol that withstands all evaluated threats, offering stronger security with acceptable performance, making it well-suited for resource constrained healthcare environments.

7.3 Communication Cost Analysis

The communication cost of the proposed LSAP-IoHT protocol is compared with existing schemes in terms of bit complexity, as shown in Table 5. The total cost for each protocol is calculated based on the number of times each cryptographic component appears in the protocol messages. Specifically, the following assumptions were used: each identifier (ID) is 160 bits, a nonce is 128 bits, a hash function output is 256 bits, a timestamp is 32 bits, and an ECC public key is 160 bits. By applying these values, we obtain the total communication overhead for each protocol. As shown, LSAP-IoHT achieves a significantly lower communication cost (2560 bits) compared to others, while still incorporating strong security primitives.

8  Conclusion

In this paper, we provided an in depth analysis of security in IoHT, highlighting the specific challenges and potential risks associated with this emerging technology. We conducted a cryptanalysis of LAP-IoHT, identifying its vulnerabilities and security limitations. Based on this analysis, we proposed a new authentication scheme tailored to the unique needs of IoHT. By employing advanced cryptographic techniques such as Physical Unclonable Functions (PUF), Elliptic Curve Cryptography (ECC), and three-factor authentication (3FA), our protocol offers robust protection against potential threats. Both our formal and informal analyses confirmed the strong security guarantees of the proposed protocol. We first applied the Real-Or-Random (ROR) model to assess the protocol’s resistance to various attack scenarios, demonstrating its theoretical robustness. In addition, we performed a formal verification using the Scyther tool, which allowed us to validate the protocol’s security properties within an automated symbolic analysis framework. The combined results highlight the protocol’s resilience and reliability, making it well-suited for securing communications in Internet of Healthcare Things (IoHT) environments.

Acknowledgement: Not applicable.

Funding Statement: The authors received no specific funding for this study.

Author Contributions: The authors confirm contribution to the paper as follows: Conceptualization, Marwa Ahmim, Nour Ouafi and Ahmed Ahmim; methodology, Insaf Ullah and Reham Almukhlifi; validation, Marwa Ahmim, Djalel Chefrour, Nour Ouafi and Reham Almukhlifi; formal analysis, Ahmed Ahmim, Insaf Ullah and Marwa Ahmim; writing—original draft preparation, Marwa Ahmim, Ahmed Ahmim, Insaf Ullah, Djalel Chefrour and Nour Ouafi; writing—review and editing, Marwa Ahmim, Ahmed Ahmim and Nour Ouafi; visualization, Djalel Chefrour, Insaf Ullah and Reham Almukhlifi; supervision, Ahmed Ahmim, Insaf Ullah and Djalel Chefrour. All authors reviewed the results and approved the final version of the manuscript.

Availability of Data and Materials: Data available within the article.

Ethics Approval: Not applicable.

Conflicts of Interest: The authors declare no conflicts of interest to report regarding the present study.

References

1. Coelho KK, Nogueira M, Marim MC, Silva EF, Vieira AB, Nacif JAM. Lorena: low memory symmetric-key generation method for based on group cryptography protocol applied to the internet of healthcare things. IEEE Access. 2022;10:12564–79. doi:10.1109/access.2022.3143210. [Google Scholar] [CrossRef]

2. Khan MA, Ullah S, Ahmad T, Jawad K, Buriro A. Enhancing security and privacy in healthcare systems using a lightweight RFID protocol. Sensors. 2023;23(12):5518. doi:10.3390/s23125518. [Google Scholar] [PubMed] [CrossRef]

3. Wu TY, Wang L, Chen CM. Enhancing the security: a lightweight authentication and key agreement protocol for smart medical services in the ioht. Mathematics. 2023;11(17):3701. doi:10.3390/math11173701. [Google Scholar] [CrossRef]

4. Khan HU, Ali Y, Khan F. A features-based privacy preserving assessment model for authentication of internet of medical things (IoMT) devices in healthcare. Mathematics. 2023;11(5):1197. doi:10.3390/math11051197. [Google Scholar] [CrossRef]

5. Ahmim A, Maazouzi F, Ahmim M, Namane S, Dhaou IB. Distributed denial of service attack detection for the Internet of Things using hybrid deep learning model. IEEE Access. 2023;11:119862–75. doi:10.1109/access.2023.3327620. [Google Scholar] [CrossRef]

6. Ahmim I, Ghoualmi-Zine N, Ahmim A, Ahmim M. Security analysis on “three-factor authentication protocol using physical unclonable function for IoV”. Int J Inf Secur. 2022;21(5):1019–26. doi:10.1007/s10207-022-00595-6. [Google Scholar] [CrossRef]

7. Sakraoui S, Ahmim A, Derdour M, Ahmim M, Namane S, Dhaou IB. FBMP-IDS: FL-based blockchain-powered lightweight MPC-secured IDS for 6G networks. IEEE Access. 2024;12:105887–905. doi:10.1109/access.2024.3435920. [Google Scholar] [CrossRef]

8. Ahmim M, Ahmim A, Ferrag MA, Ghoualmi-Zine N, Maglaras L. ESIKE: an efficient and secure internet key exchange protocol. Wirel Pers Commun. 2023;128(2):1309–24. doi:10.1007/s11277-022-10001-y. [Google Scholar] [CrossRef]

9. Ahmim I, Ghoualmi-Zine N, Ahmim M, Ahmim A. Lightweight authentication protocols for internet of vehicles: network model, taxonomy and challenges. In: 2022 4th International Conference on Pattern Analysis and Intelligent Systems (PAIS); 2022 Oct 12–13; Oum El Bouaghi, Algeria. p. 1–6. [Google Scholar]

10. Chen CM, Chen Z, Kumari S, Lin MC. LAP-IoHT: a lightweight authentication protocol for the internet of health things. Sensors. 2022;22(14):5401. doi:10.3390/s22145401. [Google Scholar] [PubMed] [CrossRef]

11. Kumar V, Mahmoud MS, Alkhayyat A, Srinivas J, Ahmad M, Kumari A. RAPCHI: robust authentication protocol for IoMT-based cloud-healthcare infrastructure. J Supercomput. 2022;78(14):16167–96. doi:10.1007/s11227-022-04513-4. [Google Scholar] [PubMed] [CrossRef]

12. Aghili SF, Mala H, Shojafar M, Peris-Lopez P. LACO: lightweight three-factor authentication, access control and ownership transfer scheme for e-health systems in IoT. Future Gener Comput Syst. 2019;96(1):410–24. doi:10.1016/j.future.2019.02.020. [Google Scholar] [CrossRef]

13. Zhang L, Zhang Y, Tang S, Luo H. Privacy protection for e-health systems by means of dynamic authentication and three-factor key agreement. IEEE Trans Ind Electron. 2018;65(3):2795–805. doi:10.1109/tie.2017.2739683. [Google Scholar] [CrossRef]

14. Soni P, Pal AK, Islam SH. An improved three-factor authentication scheme for patient monitoring using WSN in remote health-care system. Comput Methods Programs Biomed. 2019;182(1):105054. doi:10.1016/j.cmpb.2019.105054. [Google Scholar] [PubMed] [CrossRef]

15. Challa S, Das AK, Odelu V, Kumar N, Kumari S, Khan MK, et al. An efficient ECC-based provably secure three-factor user authentication and key agreement protocol for wireless healthcare sensor networks. Comput Electr Eng. 2018;69(6):534–54. doi:10.1016/j.compeleceng.2017.08.003. [Google Scholar] [CrossRef]

16. Ullah I, Khan MA, Abdullah AM, Noor F, Innab N, Chen CM. Enabling secure communication in wireless body area networks with heterogeneous authentication scheme. Sensors. 2023;23(3):1121. doi:10.3390/s23031121. [Google Scholar] [PubMed] [CrossRef]

17. Rabie OBJ, Selvarajan S, Hasanin T, Mohammed GB, Alshareef AM, Uddin M. A full privacy-preserving distributed batch-based certificate-less aggregate signature authentication scheme for healthcare wearable wireless medical sensor networks (HWMSNs). Int J Inf Secur. 2024;23(1):51–80. doi:10.1007/s10207-023-00798-5. [Google Scholar] [CrossRef]

18. Xie Y, Zhang S, Li X, Li Y, Chai Y. CasCP: efficient and secure certificateless authentication scheme for wireless body area networks with conditional privacy-preserving. Secur Commun Netw. 2019;2019(1):5860286. doi:10.1155/2019/5860286. [Google Scholar] [CrossRef]

19. Ji S, Gui Z, Zhou T, Yan H, Shen J. An efficient and certificateless conditional privacy-preserving authentication scheme for wireless body area networks big data services. IEEE Access. 2018;6:69603–11. doi:10.1109/access.2018.2880898. [Google Scholar] [CrossRef]

20. Thakur G, Prajapat S, Kumar P, Das AK, Shetty S. An efficient lightweight provably secure authentication protocol for patient monitoring using wireless medical sensor networks. IEEE Access. 2023;11:114662–79. doi:10.1109/access.2023.3325130. [Google Scholar] [CrossRef]

21. Servati MR, Safkhani M. ECCbAS: an ECC based authentication scheme for healthcare IoT systems. Pervasive Mob Comput. 2023;90(15):101753. doi:10.1016/j.pmcj.2023.101753. [Google Scholar] [CrossRef]

22. Li X, Peng J, Obaidat MS, Wu F, Khan MK, Chen C. A secure three-factor user authentication protocol with forward secrecy for wireless medical sensor network systems. IEEE Syst J. 2019;14(1):39–50. doi:10.1109/jsyst.2019.2899580. [Google Scholar] [CrossRef]

23. Amin R, Biswas G. A secure light weight scheme for user authentication and key agreement in multi-gateway based wireless sensor networks. Ad Hoc Netw. 2016;36(4):58–80. doi:10.1016/j.adhoc.2015.05.020. [Google Scholar] [CrossRef]

24. Sureshkumar V, Amin R, Vijaykumar V, Sekar SR. Robust secure communication protocol for smart healthcare system with FPGA implementation. Future Gener Comput Syst. 2019;100(4):938–51. doi:10.1016/j.future.2019.05.058. [Google Scholar] [CrossRef]

25. Ataei Nezhad M, Barati H, Barati A. An authentication-based secure data aggregation method in internet of things. J Grid Comput. 2022;20(3):29. doi:10.1007/s10723-022-09619-w. [Google Scholar] [PubMed] [CrossRef]

26. Khajehzadeh L, Barati H, Barati A. A lightweight authentication and authorization method in IoT-based medical care. Multimed Tools Appl. 2025;84(12):11137–76. doi:10.1007/s11042-024-19379-2. [Google Scholar] [CrossRef]

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

28. Ma H, Wang C, Xu G, Cao Q, Xu G, Duan L. Anonymous authentication protocol based on physical unclonable function and elliptic curve cryptography for smart grid. IEEE Syst J. 2023;17(4):6425–36. doi:10.1109/jsyst.2023.3289492. [Google Scholar] [CrossRef]

29. Cremers CJ. The scyther tool: verification, falsification, and analysis of security protocols: tool paper. In: International Conference on Computer Aided Verification. Cham, Switzerland: Springer; 2008. p. 414–8. [Google Scholar]

30. Cao J, Ma M, Fu Y, Li H, Zhang Y. CPPHA: capability-based privacy-protection handover authentication mechanism for SDN-based 5G HetNets. IEEE Trans Depend Secure Comput. 2019;18(3):1182–95. doi:10.1109/tdsc.2019.2916593. [Google Scholar] [CrossRef]