Provably Secure Drone-Assisted Authentication Protocol for Emergency Rescue in VANETs

Abstract

After an earthquake or major traffic accident, emergency rescue vehicles may be unable to access the accident site or communicate with the survey drones at the scene. In such cases, an emergency rescue vehicle can select any nearby drone as a communication relay to establish a connection with survey drones at the accident site, thereby forming a drone-assisted Vehicular Ad Hoc Network (VANET) to break through geographical constraints. These networks are characterized by flexible deployment, rapid survey, and real-time transmission of rescue data. However, existing authentication protocols for drone-assisted VANETs are insufficient in security and privacy protection, making them vulnerable to side-channel attacks, device capture attacks, and identity impersonation attacks. In addition, the excessively high computational overhead makes it difficult for them to meet the requirements of low latency and high security for real-time communication in emergency rescue. Therefore, this paper proposes a lightweight drone-assisted emergency rescue authentication protocol based on Physical Unclonable Functions (PUF) and the Chebyshev chaotic map. In this protocol, the authenticating entities, including emergency rescue vehicles, relay drones, and survey drones, register with the Trusted Authority (TA) in a symmetric manner and also authenticate each other’s identities and establish session keys symmetrically. The proposed scheme not only resists side-channel attacks and device capture attacks but also addresses the single point of failure problem of relay drones. Both formal and informal security analyses verify its security, and comparative experiments show that it has lower computational and communication overhead, making it more suitable for emergency rescue application scenarios.

1. Introduction

Emergency communication after a disaster has a narrower requirement than ordinary VANET service: rescue vehicles must exchange road status, task instructions, and victim information while parts of the roadside network are already down. RSUs, Wi-Fi access points, and other fixed facilities can fail together after floods, earthquakes, or large traffic accidents [1,2]. VANETs are effective in normal intelligent transportation systems [3], but they still depend on a usable ground infrastructure. When that infrastructure disappears, rescue vehicles may become disconnected from one another and from the command center. The result is not only slower communication, but poorer route selection and delayed field decisions.

Drones provide a practical means to deploy a temporary aerial communication layer. They can fly over blocked roads, adjust their positions as the rescue area changes, and carry lightweight communication and sensing modules [4]. A drone equipped with a 5G module, ad hoc transceiver, camera, or environmental sensor can relay messages among rescue vehicles, rescue teams, and the command center [5]. It can also collect images, video, and local environmental data for situation assessment [4]. Because these aerial nodes can be deployed on demand, they avoid the cost and delay of rebuilding fixed infrastructure during the early rescue stage [6].

This flexibility also changes the security problem. The vehicle-drone channel is open, short lived, and often established in a place where no stable trust relationship exists. An attacker may listen to traffic, replay old messages, modify rescue commands, or impersonate a legitimate drone to obtain vehicle data [2]. These attacks are more serious in rescue settings because false routing information or leaked victim locations can immediately affect safety. At the same time, drones and vehicles cannot afford heavy authentication procedures: their processors, storage, and batteries are limited [7]. A usable protocol must therefore keep the cryptographic cost low without reducing the authentication strength to a single fragile factor [8].

In addition, the imperfect Authentication and Key Agreement (AKA) schemes are a core shortcoming in the communication security of drone-assisted VANETs for emergency rescue. Traditional VANET AKA schemes have excessive computational and communication overhead [3]; even ECC-based AKA protocols, despite improved performance, cannot meet the stringent delay requirements of emergency rescue. Existing single or two-factor AKA schemes have obvious security vulnerabilities [9], with low-entropy passwords, smart card loss and biometric leakage greatly reducing user-side security. While some three-factor AKA schemes enhance security, they neglect the ability to resist physical attacks [10]. Restricted by size, weight and endurance, drones cannot integrate complex encryption and decryption operations, making them prone to capture by attackers and privacy parameter theft [11]. Moreover, users have an inherent demand for protecting privacy such as driving routes and personal identities [12], yet existing schemes offer poor privacy protection and most fail to achieve the conditional privacy protection required for emergency rescue [13], which cannot meet the practical needs of drone-assisted VANETs.

Motivation and contribution: Designing a lightweight AKA scheme that balances security and privacy for drone-assisted VANETs in emergency rescue is key to ensuring trusted communication and improving rescue efficiency, and remains an urgent core research focus in this field. To address the critical limitations of existing authentication protocols for drone-assisted emergency rescue scenarios, namely:

(1)

Most schemes require a trusted center (TA/dispatching center) to stay online throughout authentication. If the center fails or suffers congestion, a single point of failure emerges exactly when rescue communication is critically needed.

(2)

Most drone-targeted schemes adopt only device-centric single-factor PUF authentication, lacking protection for human-operated rescue vehicles. The presence of drivers brings risks, including offline password guessing, biometric information leakage and OBU theft.

(3)

Existing drone-assisted emergency rescue authentication protocols suffer from one or more security deficiencies, such as being vulnerable to device capture attacks, privacy leakage, forgery attacks, lack of perfect forward secrecy for session keys, and absence of session key security.

We design a secure and lightweight AKA scheme tailored for drone-assisted VANETs in emergency rescue. The main contributions of this paper are summarized as follows:

• A lightweight three-factor authentication and key agreement (AKA) scheme is proposed for emergency rescue in drone-assisted VANETs, which enables emergency rescue vehicles to select any nearby drone as a communication relay to establish a connection and communicate with survey drones at the scene, when the rescue vehicles are unable to access the accident site or communicate with the vehicles or survey drones on site. The authentication process does not require the participation of a trusted center and can avoid communication interruptions caused by a single point of failure or capture of relay drones.
• By integrating the Chebyshev chaotic map and PUF to achieve lightweight mutual authentication among emergency vehicles, relay drones, and survey drones, thus significantly enhancing resistance against impersonation and physical capture attacks, by employing a fuzzy extractor to handle biometric noise and combining hash functions, symmetric encryption, and timestamp freshness verification, the proposed scheme achieves strong robustness against replay and open-channel attacks with ultra-low overhead.
• Rigorous formal security proof is provided under the random oracle model. Information security analysis verifies the security of our protocol, and extensive experiments on Raspberry Pi 4B demonstrate that the protocol achieves lower computational and communication overhead than existing schemes, making it well-suited for resource-constrained emergency scenarios.

The rest of this article is organized as follows. Section 2 summarizes related work. The system model and preliminaries are described in Section 3 and Section 4. The proposed authentication protocol is detailed in Section 5. Subsequently, security proofs, informal security analysis, and performance evaluation are provided in Section 6, Section 7 and Section 8, respectively. Finally, Section 9 summarizes this study.

2. Related Work

To balance the security of drone communications and the resource constraints of terminals, extensive research has been conducted on lightweight Authentication and Key Agreement (AKA) protocols by integrating PUF, ECC, Chebyshev Chaotic Map, blockchain and other techniques. Although existing studies have made progress, they still suffer from security flaws and insufficient scenario adaptability. Based on relevant surveys, this paper summarizes key research outcomes and remaining challenges.

PUF serves as a key hardware security technique against drone physical capture and side-channel attacks, widely used in mutual authentication between drones and various nodes. Alladi et al. further realized drone–ground station and drone–drone mutual authentication but failed to ensure forward and backward secrecy of session keys [14]. Tanveer et al. designed a PUF-enhanced authentication framework for the Internet of Drones (IoD), supporting lightweight device authentication and session key generation [15].

For emergency scenarios, Mall et al. presented a low-cost PUF scheme for unattended environments; however, their scheme does not provide anonymity or key confirmation [16]. Wang et al. developed a three-factor PUF protocol for post-disaster communications vulnerable to impersonation attacks without session key security [17]. Xie and Zhang’s lightweight PUF scheme enabled direct drone-to-drone authentication resistant to capture attacks with zero ground station storage, suitable for infrastructure-damaged scenarios [18]. Pu et al. combined PUF and chaotic maps for AKA to prevent privacy leakage, yet without formal security proofs or guaranteed session key security [19].

ECC is dominant in lightweight authentication due to low overhead. El-Zawawy et al. designed the BDIVE protocol integrating ECC and blockchain, optimized energy and computation costs by over 60% and supported malicious behavior traceability [20]. Chaotic maps are applied in efficient key agreement. Nair and Thampi combined location awareness with PUF and chaotic maps for location-aware authentication in emergencies [21]. To address the coverage limitation of traditional vehicular networks, Guo [22] et al. designed a UAV-assisted mutual authentication scheme, which combines Chebyshev chaotic mapping and elliptic curve cryptography to achieve secure and low-overhead V2X communication. From the perspective of cryptographic building blocks, Xu et al. [23] constructed secure channels among users, smart devices, and control nodes using fuzzy extractors, enabling dynamic joining and user revocation. Meanwhile, ECC-based designs are widely explored but may suffer from nontrivial overhead, Hussain et al. [24] proposed an ECC-based authentication scheme for the Internet of Drones (IoD). However, Zhang et al. [25] demonstrated that the scheme fails to resist drone impersonation attacks, and that an adversary can further compromise the session key between a target user and the corresponding drone.

Blockchain’s decentralization effectively alleviates the inherent drawbacks of centralized architectures. Tan et al. constructed a distributed lightweight authentication service for industrial unmanned aerial vehicles, which reduces central server loads and resists single-point failures [26]. Zhang et al. presented a blockchain-enabled cross-domain multi-factor authentication protocol that integrates PUF and dynamic accumulators to significantly reduce on-chain storage overhead [27]. Nevertheless, most conventional blockchain-assisted VANET authentication schemes excessively rely on digital certificates, resulting in high computational costs and linearly increasing storage overhead as the vehicle scale expands [28]. When a traffic accident occurs, there are also blockchain-based accident handling schemes that use ECC-based digital signatures to authenticate users’ identities and accident reports, which remain applicable even in scenarios without traffic infrastructure or when roadside units are inaccessible [29].

To meet the demands of lightweight and low-latency emergency rescue, numerous dedicated authentication and key agreement (AKA) schemes have been proposed. Cui et al. presented drone-assisted lightweight AKA schemes for VANETs, and provide provable security while satisfying emergency communication, privacy protection, and resource-constrained requirements [30]. Miao et al. designed a UAV-assisted authentication protocol that offloads traffic from base stations, alleviates communication congestion in IoV, and verifies the effectiveness of drones in emergency communication scenarios [31]. Xie et al. devised a lightweight ECC-PUF integrated authentication protocol for VANET emergency vehicle avoidance, achieving traceable privacy protection, multi-attack resistance, and improved authentication efficiency [32]. Ying et al. proposed a lightweight V2ES authentication protocol and optimized Faster-RCNN detection solution, which effectively protects data privacy and reduces computational and communication costs in connected autonomous vehicle scenarios [33]. Tan et al. studied drone-empowered VANETs as mobile base stations for infrastructure-free post-disaster coverage [34].

In 2026, Xie et al. [35] proposed an eVTOL (Electric Vertical Take-Off and Landing) emergency rescue protocol that employs drones as communication relays. When the Dispatch Center (DC) is beyond the direct communication coverage of the rescue eVTOL, the relay drone forwards messages between the DC and the eVTOL, thereby enabling the DC to remotely direct and coordinate the rescue mission. However, in drone-assisted VANET emergency rescue scenarios, the involvement of drivers and rescue vehicles renders the single-factor authentication approach of eVTOL rescue inadequate to address the various attacks that emerge in VANET emergency rescue, including password guessing attacks and biometric information leakage attacks against drivers, and side-channel attacks against OBUs. Therefore, the threat model for drone-assisted VANET emergency rescue authentication protocols must also consider driver identity authentication and adversary attacks against vehicles. It is not only required to satisfy three-factor security, but also to address threats such as vehicle mobility, GPS spoofing, and insider privilege attacks. Moreover, in the face of large-scale deployment of rescue vehicles and drones, and to prevent single points of failure and authentication bottlenecks, the authentication process must remove the participation of the trusted registration center. The adoption of Chebyshev chaotic maps is specifically driven by the application requirements of high mobility, low latency, and constrained computing and storage resources of vehicles and drones. Consequently, the scheme in [35] is not applicable to drone-assisted VANET emergency rescue application scenarios.

In extended security research, Su et al.’s reinforcement learning-based anomaly detection suffered from slow learning and low efficiency [36]. Wang et al.’s blockchain detection mechanism faced forking and delays [29]. Gupta et al.’s private blockchain and SDN-based data sharing could not resist inference attacks [37]. Most such studies neglect confidentiality, unforgeability and session key security, risking forged information misleading rescue operations.

In addition, recent lightweight on-board perception schemes for drone scenarios, such as YOLOv8-based signals-intelligence drone detection and the LD-YOLOv10 lightweight detector [38,39], further evidence the stringent computation and energy constraints of drone platforms; such detection/identification pipelines are complementary to our authentication layer and motivate the lightweight design pursued in this paper. Overall, existing work has made certain progress in leveraging PUF, ECC, Chebyshev Chaotic Map and blockchain to support drone-related authentication. However, some schemes still have many shortcomings, such as the lack of forward security (PFS) guarantee, incomplete support for anonymity, or security vulnerabilities under threat models such as drone capture and theft of verification tables. These issues indicate that there is an urgent need to design a secure and lightweight authentication scheme for emergency rescue scenarios in drone-assisted vehicular networks. Table 1 summarizes notable related works from recent years.

Table 1. Summary of related schemes from recent years.

Scheme	Year	Cryptographic Techniques	Advantages	Limits
[14]	2020	Utilizes PUF	Realizes UAV–ground and UAV–UAV mutual authentication	Lacks forward/backward secrecy of session keys
[19]	2022	Utilizes PUF + Chaotic Maps	Prevents user privacy leakage, lightweight AKA for IoD	No formal security proof, unstable session key security
[20]	2023	Utilizes ECC + Blockchain	60%+ reduction in energy/computation overhead, supports malicious behavior traceability	Blockchain storage cost rises with network scale
[21]	2023	Utilizes PUF + Chebyshev Chaotic Map	Location-aware emergency authentication	Not customized for drone-assisted VANET rescue networking
[22]	2024	Utilizes Chebyshev Chaotic Map + ECC	Secure low-overhead UAV-assisted V2X communication	Oriented to satellite-terrestrial networks, not fully adapted to pure UAV-VANET rescue
[23]	2023	Utilizes Fuzzy Extractor	Multi-user dynamic access and user revocation for industrial IoT	Designed for industrial scenarios, not emergency vehicle-drone networks
[24]	2021	Utilizes ECC	Standard lightweight authentication for IoD	Proven insecure against drone impersonation attacks
[26]	2022	Utilizes Blockchain	Distributed lightweight authentication, reduces central server load, partial anti-single-point-failure	Blockchain consensus brings extra computational delay
[27]	2022	Utilizes Blockchain + PUF + Dynamic Accumulator	Cross-domain multi-factor authentication, low on-chain storage overhead	Centralized cross-domain management node still exists, residual single-point failure hidden danger
[29]	2022	Utilizes Blockchain + ECC	Third-party-free accident handling, works under infrastructure failure	Blockchain forking risk, transmission delay in dynamic rescue topology
[30]	2024	Utilizes PUF + Chebyshev Chaotic Map	Provably secure for UAV-VANET rescue, balances privacy and resource constraints	Does not integrate PUF hardware anti-capture capability
[31]	2024	Utilizes ECC	Offloads base station traffic, eases IoV communication congestion	No three-factor identity verification mechanism
[32]	2026	Utilizes ECC + PUF	Traceable privacy, multi-attack resistance, high-efficiency emergency vehicle authentication	Not optimized for large-scale drone relay topology switching
[33]	2026	Utilizes ECC + PUF	Low-cost privacy protection for autonomous connected vehicles	No drone relay node authentication module
[34]	2023	Utilizes Bilinear Pairing	Infrastructure-free post-disaster IoV coverage via drone base stations	Relies on trusted pre-deployed key pool, no distributed credential update
[35]	2022	Utilizes Blockchain + Reinforcement Learning	Lightweight disaster rescue data sharing	Slow model convergence, low anomaly detection efficiency
[37]	2021	Utilizes Private Blockchain	Green communication data dissemination for UAV networks	Cannot resist inference attacks, weak data confidentiality

3. System Model and Adversary Model

3.1. System Model

The system model of this protocol is illustrated in Figure 1, which consists of four entities: a trusted authority, a relay drone, a field survey drone, and an emergency rescue vehicle.

Figure 1. System model.

• Trusted Authority: The core trusted entity, responsible for entity registration, identity verification, and key distribution to ensure secure and legitimate communication.
• Relay Drone: The core transit node, which receives distress messages from emergency rescue vehicles, forwards them to field survey drones after authentication, and relays on-site data back to vehicles.
• Emergency Rescue Vehicle: The vehicle responsible for rescue, initiator of information requests and rescue executor, which sends distress signals, receives encrypted on-site data and instructions, and performs rescue operations.
• User: The driver is responsible for logging into the vehicle and initiating requests via the vehicle.
• Field Survey Drone: Deployed at the accident core area to collect real-time on-site data (personnel location, environmental risks, road conditions, etc.), encrypt and transmit data to the relay drone for rescue decision support.

The proposed authentication mechanism requires mutual authentication among the three participating parties: the emergency rescue vehicle, the relay drone, and the field survey drone. The relay drone facilitates the establishment of a session key between the rescue vehicle and the field survey drone, but it does not need to establish a session key with either of them. In addition, the TA is only involved in the one-time offline registration of the rescue vehicle and the drones, and does not participate in the mutual authentication process among the three parties. The relay drone serves as an on-demand temporary node and does not store any long-term secrets of the vehicles or field survey drones. Its function is limited to verifying the identity of the rescue vehicle and forwarding messages, by computing the Diffie–Hellman value with the rescue vehicle using its own private key. Furthermore, when the relay drone is revoked or replaced, or when the network topology changes, or when the rescue vehicle fails to receive feedback within a tolerable time threshold, an alternative drone can be selected to assist in establishing a connection with the survey drone.

3.2. Adversary Model

According to the Dolev–Yao model [40] and the security requirements of multiserver authentication, the adversary model is defined as follows.

• An adversary can eavesdrop, intercept, modify or delete the messages transmitted publicly.
• An adversary can launch side-channel attacks, but it is difficult to obtain biological keys and crack PUF.
• Only under the consideration of three-factor secrecy can an adversary obtain any two of the three factors to launch attacks, but it cannot simultaneously acquire all three factors.
• To save memory, the ID and PW chosen by the user are usually low-entropy. The adversary can enumerate the Cartesian product set of the user identity and password spaces to launch a successful offline guessing attack.

3.3. Practical Threat for Drone/VANET Environments

Beyond the standard Dolev–Yao adversary model, the following threats specific to mobile the drone/VANET rescue scheme should be considered.

• Drone mobility and intermittent connectivity: In rescue scenarios, drones are in continuous motion, and communication links may frequently be interrupted due to signal occlusion, battery depletion, or environmental interference.
• Drone failures: Encompassing situations such as drone capture, hardware/software malfunctions, and topology changes that render a drone unable to operate normally.
• Packet loss and synchronization failures: Wireless communication environments are susceptible to channel noise, collisions, and fading, which may cause packet loss or disorder.
• Desynchronization attacks: This attack aims to corrupt the shared state maintained between communicating parties (e.g., sequence numbers, counters, or temporary session identifiers), preventing legitimate users from completing subsequent authentication.
• Denial-of-service attacks: Attackers may exhaust the computational and bandwidth resources of protocol participants by sending a large number of forged or replayed messages.
• GPS spoofing: Attackers may forge GPS signals to provide false location information to drones or vehicles.
• Insider/compromised-drone attacks: Attackers may launch attacks by physically capturing drones.
• PUF tamper-resistance assumption: The device-embedded PUF is assumed to exhibit stable challenge-response behavior after fuzzy extractor error correction and to possess tamper-evident properties.
• Three-factor security: It is assumed that even if an adversary can obtain any two of the three factors (e.g., password, biometrics, device), the scheme remains secure.
• The protocol should resist several attacks relevant to this setting, including forgery, replay, man-in-the-middle, offline password guessing, and device-capture-related attacks, while also supporting anonymity, unlinkability, and forward secrecy.

4. Preliminaries

In this section, we introduce preliminaries, including PUF, Chebyshev Chaotic Map and Fuzzy Extractor.

4.1. Physically Unclonable Function

Based on the uniqueness of physical entities, the Physical Unclonable Function (PUF) ensures that any input triggers a unique and unpredictable response output by extracting the inevitable process parameter deviations in the chip manufacturing process [41]. Given a challenge Cha, the PUF generates a corresponding response Res = PUF(Cha). It is infeasible to predict a specific device’s response even with the known challenge value, and each PUF device yields a different response for the same challenge input.

The PUF is designed with tamper resistance. After fuzzy extractor error correction, the PUF deployed in the device is assumed to be challenge-response stable and tamper-evident. Therefore, any invasive reading attempt alters its behavior and renders the secret recovered from the PUF response unusable.

4.2. Chebyshev Chaotic Map

The n-th degree Chebyshev polynomial over $[-1,1]$ is defined as $T_n\left(x\right)=\mathrm{c}\mathrm{o}\mathrm{s}(n·arccos(x\left)\right)$, where $n\in {\mathbb{Z}}^{+}$ and $x\in [-1, 1]$. It satisfies the recurrence for $n\ge 2$: $T_n\left(x\right)=2x{T}_{n-1}\left(x\right)-T_{n-2}\left(x\right)$, with $T_1\left(x\right)=x$ and $T_0\left(x\right)=1$. For $n>1$, the Chebyshev polynomial ${\mathrm{T}}_{\mathrm{n}}\left(\mathrm{x}\right):[-1,1]\to [-1,1]$ is a chaotic mapping.

To overcome the domain limitation of the original Chebyshev chaotic mapping and enhance its cryptographic characteristics, Zhang [42] proposed the extended Chebyshev polynomial:$T_n\left(x\right)=\left(2x{T}_{n-1}\left(x\right)-T_{n-2}\left(x\right)\right)mod P$, where P is a large prime number and $x\in (-\infty ,+\infty )$. It preserves the semigroup property: $T_m\left(T_n\right(x\left)\right)=T_{mn}\left(x\right)=T_{nm}\left(x\right)=T_n\left(T_m\right(x\left)\right)$, where$m, n\in {\mathbb{Z}}^{+}$.

The cryptographic security of the extended Chebyshev chaotic mapping is rooted in two intractable computational problems, defined as follows:

• Chebyshev Polynomial Discrete Logarithm Problem (CPDLP): Given y, x and ${\mathrm{T}}_{\mathrm{r}}\left(\mathrm{x}\right)$ (where $\mathrm{x}\in (-\mathrm{\infty },+\mathrm{\infty })$), it is computationally infeasible to derive the positive integer r that satisfies $\mathrm{y}={\mathrm{T}}_{\mathrm{r}}\left(\mathrm{x}\right)$.
• Chebyshev Polynomial Computational Diffie–Hellman Problem (CPCDHP): Given x, ${\mathrm{T}}_r\left(\mathrm{x}\right)$ and ${\mathrm{T}}_s\left(\mathrm{x}\right)$ (where $x\in (-\infty ,+\infty )$ and integers $\mathrm{r},\mathrm{s}\ge$ 2), it is computationally infeasible to calculate ${\mathrm{T}}_{rs}\left(\mathrm{x}\right)$, where $T_{rs}\left(x\right)=T_r\left(T_s\left(x\right)\right)=T_s\left(T_r\left(x\right)\right)$.

Compared with other chaotic maps, the extended Chebyshev map is ideal for authentication and key agreement due to CPDLP/CPCDHP intractability and the semigroup property. Its computation cost is only one-third of elliptic curve scalar multiplication [43], greatly reducing overhead for resource-constrained environments.

Notably, our protocol avoids real-valued Chebyshev recurrences over $(-\infty ,+\infty )$ with stability risks. All calculations adopt extended Chebyshev polynomials modulo a large prime P, retaining semigroup properties without real-map orbit collapse or precision errors. Security depends only on hard CPDLP and CPCDHP modulo P, so real-map stability poses no cryptographic flaws.

4.3. Fuzzy Extractor

A fuzzy extractor is a technology capable of extracting a fixed-length, consistent and secure binary string (similar to a key) from noisy or imprecise biometric data, PUF output and other information. As described in [44], this process consists of two steps:

• $Gen\left(Res\right)=(\omega ,\theta )$;
• $\omega =Rep({Res}^{\ast },\theta )$, if ${Res}^{\ast }$ is quite close to $Res$.

Although PUF has uniqueness, its response will fluctuate due to environmental factors such as temperature and voltage changes. By combining error correction coding and random seeds, the fuzzy extractor converts the unstable output of PUF into a stable binary string. Biometric features may vary during collection due to factors such as environment and physiological conditions. The fuzzy extractor extracts stable keys from noisy biometric data, safeguarding privacy.

5. Proposed Scheme

The scheme proposed in this paper consists of four phases: system initialization phase, registration phase, login and authentication phase, and password update phase. Table 2 presents the definitions of the symbols used in this protocol.

Table 2. Notations.

Notations	Description
TA	Trusted Authority
${EV}_i$	i-th Emergency Rescue Vehicle
${\mathrm{U}}_i$	i-th Emergency Rescue Vehicle Driver
$D_j$	j-th Relay Drone
$D_k$	k-th Field Survey Drone
${ID}_{\mathrm{e}i}, { ID}_{ui}, { ID}_{dj}, { ID}_{dk}$	Identity of ${EV}_i,$${\mathrm{U}}_i,$ ${ D}_j$ and $D_k$
${PW}_{ui},$${BIO}_{ui}$	Password and biometric of ${\mathrm{U}}_i$
$s_{TA}/PK$	Secret Key/Public Key of TA
$\mathrm{P}\mathrm{U}\mathrm{F}(·)$	Physical Unclonable Function
Cha, Res	Challenge and Response of $\mathrm{P}\mathrm{U}\mathrm{F}(·)$
$\mathrm{G}\mathrm{e}\mathrm{n}(·), \mathrm{R}\mathrm{e}\mathrm{p}(·)$	Fuzzy extractor generation and reproduction funtions
${\mathsf{\omega }}_i,{\mathsf{\theta }}_i$	Biometric key and biometric parameters
$\mathrm{h}(·)$	Hash function
Enc/Dec	Symmetric Encryption/Decryption
T	Time stamp
SK	Session Key
${MSG}_{req}$	Request message of ${EV}_i$(${\mathrm{U}}_i$)
${MSG}_{res}$	On-site information collected by $D_k$

5.1. Initialization Phase

TA selects an $x\in (-\infty ,+\infty )$, a large prime number q and a private key ${\mathrm{s}}_{TA}$, and calculates the public key: $PK=T_{s_{TA}}\left(x\right)$. TA designates a secure hash function $h(·)$, symmetric encryption/decryption algorithm $Enc/Dec$, a fuzzy extractor $(Gen, Rep)$, and sets a tolerable time delay threshold $∆\mathrm{T}$. TA publishes the parameters $\{x, q,Enc, Dec, Gen, Rep, ∆T, PK, h(·), \}$, and securely stores $s_{TA}$.

5.2. Registration Phase

(1)

Registration of Emergency Rescue Vehicle ${EV}_i$

Each ${EV}_i$ completes its registration procedure with TA via a secure channel. This phase is illustrated in Figure 2.

Figure 2. Registration phase for ${\mathrm{E}\mathrm{V}}_{\mathrm{i}}$.

Step 1: The emergency rescue vehicle ${EV}_i$ sends its identity ${ID}_{ei}$ and a registration request to TA.

Step 2: Upon receipt, TA selects a random number $s_{ei}$ and calculates:

$$Y_{ei}=T_{s_{ei}}\left(x\right),$$

then sends $\{ s_{ei},Y_{ei}\}$ to ${EV}_i$ and publishes $Y_{ei}$.

Step 3: ${EV}_i$ generates a challenge ${Cha}_{ei}$, and calculates:

$${Res}_{ei}={PUF}_{ei}\left({Cha}_{ei}\right),$$

$$B_{ei}=s_{ei}\oplus \mathrm{h}\left({Res}_{ei}\right).$$

Step 4: ${EV}_i$ stores $\{{ID}_{ei},Y_{ei},B_{ei},{Cha}_{ei}\}$ in the On-Board Unit (OBU).

(2)

Registration of Relay Drone $D_j$

Each $D_j$ completes its registration procedure with TA via a secure channel. This phase is illustrated in Figure 3.

Figure 3. Registration phase for ${\mathrm{D}}_{\mathrm{j}}$.

Step 1: The relay drone $D_j$ sends its identity ${ID}_{dj}$ and a registration request to TA.

Step 2: TA selects a secret number $s_{dj}$ and calculates $Y_{dj}=T_{s_{dj}}\left(x\right)$, then sends $\{s_{dj},Y_{dj}\}$ to $D_j$.

Step 3: $D_j$ generates a PUF challenge ${Cha}_{dj}$, calculates the PUF response: ${Res}_{dj}={PUF}_{dj}\left({Cha}_{dj}\right)$, and then calculates:

$$D_{dj}=s_{dj}\oplus h\left({Res}_{dj}\right).$$

Step 4: $D_j$ stores $\{{ID}_{dj},D_{dj},Y_{dj},{Cha}_{dj}\}$, and TA publishes $\left\{Y_{dj}\right\}$.

(3)

Registration of Field Survey Drone $D_k$

Each $D_k$ completes its registration procedure with TA via a secure channel. This phase is illustrated in Figure 4.

Figure 4. Registration phase for ${\mathrm{D}}_{\mathrm{k}}$.

Step 1: The field survey drone $D_k$ sends its identity ${ID}_{dk}$ and a registration request to TA.

Step 2: TA then selects a secret number $s_{dk}$ and calculates ${\mathrm{Y}}_{\mathrm{d}\mathrm{k}}={\mathrm{T}}_{{\mathrm{s}}_{\mathrm{d}\mathrm{k}}}\left(\mathrm{x}\right)$, then sends $\{s_{dk},{\mathrm{Y}}_{\mathrm{d}\mathrm{k}}\}$ to $D_k$.

Step 3: $D_k$ generates a PUF challenge ${Cha}_{dk}$, calculates the PUF response: ${Res}_{dk}={PUF}_{dk}\left({Cha}_{dk}\right)$, and then calculates:

$$D_{dk}=s_{dk}\oplus \mathrm{h}\left({Res}_{dk}\right).$$

Step 4: $D_k$ stores $\{{ ID}_{dk},D_{dk},{\mathrm{Y}}_{\mathrm{d}\mathrm{k}},{Cha}_{dk}\}$.

(4)

Registration of Emergency Rescue Vehicle Driver ${\mathrm{U}}_i$

Step 1: ${\mathrm{U}}_i$ inputs ${ID}_{ui},{PW}_{ui}$ and ${BIO}_{ui}$ into the OBU.

Step 2: OBU calculates $\mathrm{G}\mathrm{e}\mathrm{n}\left({BIO}_{ui}\right)=({\omega }_i,{\theta }_i)$, then selects $n_0\in [2^4,2^8]$ and calculates:

$$H_1=h\left({ID}_{ui}\parallel {PW}_{ui}\parallel {\omega }_i\right)mod n_0,$$

$$H_2=h({Res}_{ei}\parallel {ID}_{ui}\parallel {PW}_{ui}\parallel {\omega }_i).$$

Step 3: ${\mathrm{U}}_i$ stores $\{{\theta }_i,H_1,H_2,n_0\}$ in the OBU, meaning the OBU contains $\{{ID}_{ei},Y_{ei},B_{ei},{Cha}_{ei},{\theta }_i,H_1,H_2,n_0\}$.

5.3. Login and Authentication Phase

When the emergency rescue vehicle ${EV}_i\left({\mathrm{U}}_i\right)$ needs to obtain real-time data from the field survey drone $D_k$, ${EV}_i\left({\mathrm{U}}_i\right)$ selects any nearby drone $D_j$ as a transmission relay. ${EV}_i\left({\mathrm{U}}_i\right)$, $D_j$ and $D_k$ perform mutual identity authentication and negotiate a session key among the three parties. After authentication, ${EV}_i\left({\mathrm{U}}_i\right)$ can communicate legally with $D_k$ through the transmission of $D_j$. The framework of the proposed AKA process is illustrated in Figure 5 and the overall process is shown in Figure 6.

Figure 5. Framework of the proposed AKA process.

Figure 6. The AKA process of ${EV}_i\left({\mathrm{U}}_i\right)$–$D_j$–$D_k$ of our protocol.

Step 1: ${\mathrm{U}}_i$ inputs ${ID}_{ui}^{\prime }, {PW}_{ui}^{\prime }, {BIO}_{ui}^{\prime }$ into the OBU and completes identity verification:

$${{\mathsf{\omega }}^{\prime }}_i=Rep({BIO}_{ui}^{\prime },{\mathsf{\theta }}_i),$$

$$H_1^{\prime }=h\left({ID}_{ui}^{\prime }\parallel {PW}_{ui}^{\prime }\parallel {{\mathsf{\omega }}^{\prime }}_i\right)mod n_0=? H_1 ,$$

$${Res}_{ei}^{\prime }={PUF}_{ei}\left({Cha}_{ei}\right),$$

$$s_{ei}=B_{ei}\oplus h\left({Res}_{ei}^{\prime }\right),$$

$$H_2^{\prime }=h({Res}_{ei}^{\prime }\parallel {ID}_{ui}\parallel {PW}_{ui}\parallel {{\mathsf{\omega }}^{\prime }}_i)=? H_2 .$$

If the verification fails, the process is terminated; otherwise, the OBU generates a random number $r_1$ and a timestamp $T_1$, and calculates:

$$A_1=T_{r_1}\left(x\right), A_2=T_{r_1}\left(Y_{d\mathrm{j}}\right), A_3=T_{s_{ei}}\left(Y_{dk}\right),$$

$${PID}_1=h({ID}_{ei}\parallel A_2\parallel T_1\parallel {MSG}_{req}\parallel A_3),$$

$$A_4={Enc}_{A_2}({ID}_{ei}\parallel {MSG}_{req}\parallel Y_{ei}\parallel {PID}_1).$$

The OBU sends $\{A_1,A_4,T_1\}$ to $D_j$.

Step 2: Upon receiving $\{A_1,A_4,T_1\}$, $D_j$ first checks the freshness of $T_1$ and calculates the PUF response value: ${Res}_{dj}={PUF}_{dj}\left({Cha}_{dj}\right)$. Then $D_j$ recovers $s_{dj}=D_{dj}\oplus h\left({Res}_{dj}\right)$ and calculates $A_2^{\prime }=T_{s_{d\mathrm{j}}}\left(A_1\right)$ to verify the legality of ${EV}_i$:

$$({ID}_{ei}\parallel {MSG}_{req}\parallel Y_{ei}\parallel {PID}_1)={Dec}_{A_2}\left(A_4\right),$$

$${PID}_1^{\prime }=h\left({ID}_{ei}\parallel A_2\parallel T_1\parallel {MSG}_{req}\parallel {\mathrm{T}}_{{\mathrm{s}}_{\mathrm{d}\mathrm{k}}{s}_{ei}}\left(x\right)\right)=? {PID}_1$$

If the verification fails, the process is terminated; otherwise, $D_j$ generates a timestamp $T_2$, analyzes and processes ${MSG}_{req}$, and then selects a field survey drone $D_k$ with a suitable location and matching performance according to the disaster situation and task requirements. Subsequently, $D_j$calculates:

$$A_5={Enc}_{T_{s_{dk}}\left(Y_{dj}\right)}({ID}_{ei}\parallel {MSG}_{req}\parallel {ID}_{dj}\parallel T_2),$$

$$A_6=h({ID}_{ei}\parallel {ID}_{dj}\parallel {MSG}_{req}\parallel A_1\parallel T_2).$$

Specifically, ${MSG}_{req}$ refers to the emergency rescue message, which contains key information such as the disaster type, approximate location of the incident, personnel trapping situation and precise rescue demands.

Then, $D_j$ sends $\{A_5,A_6,T_2\}$ to $D_k$.

Step 3: Upon receiving $\{A_5,A_6,T_2\}$, $D_k$ first checks the freshness of $T_2$ and calculates the PUF response: ${Res}_{dk}={PUF}_{dk}\left({Cha}_{dk}\right)$. Then $D_k$ recovers $s_{dk}=D_{dk}\oplus \mathrm{h}\left({Res}_{dk}\right)$ to verify the legality of $D_j$:

$$\left({\mathrm{I}\mathrm{D}}_{ei}\right|\left|{MSG}_{req}\right|\left|{ID}_{dj}\right|\left|T_2\right)={Dec}_{T_{s_{dk}{s}_{dj}}\left(x\right)}(A_5),$$

$$A_6^{\prime }=h\left({ID}_{ei}\parallel {ID}_{dj}\parallel {MSG}_{req}\parallel A_1\parallel T_2\right)=?A_6.$$

If the verification fails, the process is terminated; otherwise, $D_k$ generates a random number $r_2$ and a timestamp $T_3$, and calculates:

$$A_7=T_{r_2}\left(x\right).$$

Subsequently, $D_k$ constructs the session key between $D_j$ and $D_k$: ${SK}_{kj}=h\left({ID}_{ei}\parallel {ID}_{dk}\parallel T_{r_2}\left(A_1\right)\right)$, and calculates:

$$A_8=h({SK}_{kj}\parallel {ID}_{ei}\parallel {ID}_{dj}\parallel {ID}_{dk}),$$

$$A_9={Enc}_{T_{s_{dk}}\left(Y_{dj}\right)}\left({ID}_{ei}\parallel {ID}_{dj}\parallel {ID}_{dk}\parallel A_8\right),$$

$$A_{10}=h(A_7\parallel A_8\parallel A_9\parallel {{\mathrm{T}}_3\parallel ID}_{ei}\parallel {ID}_{dj}\parallel {ID}_{dk}).$$

$D_k$ sends $\{{ A}_7,A_{10},A_9,T_3\}$ to $D_j$.

Step 4: Upon receiving $\{{ A}_7,A_{10},A_9,T_3\}$, $D_j$ first checks the freshness of $T_3$, and then calculates and verifies:

$$\left({ID}_{ei}\parallel {ID}_{dj}\parallel {ID}_{dk}\parallel A_8\right)={Dec}_{T_{s_{dk}{s}_{dj}}\left(x\right)}\left(A_9\right),$$

$$A_{10}^{\prime }=h\left(A_7\parallel A_8\parallel A_9\parallel {{\mathrm{T}}_3\parallel ID}_{ei}\parallel {ID}_{dj}\parallel {ID}_{dk}\right)=? A_{10}.$$

If the verification fails, the process is terminated; otherwise, $D_j$ generates a timestamp $T_4$ and calculates:

$$A_{11}={Enc}_{A_2^{\prime }}(A_7\parallel {ID}_{ei}\parallel {ID}_{dj}\parallel {ID}_{dk}\parallel A_8),$$

$$A_{12}=h(A_7\parallel A_8\parallel A_{11}\parallel T_4{\parallel ID}_{ei}\parallel {ID}_{dj}\parallel {ID}_{dk}).$$

$D_j$ send $\{A_{11},A_{12},T_4\}$ to ${EV}_i$.

Step 5: Upon receiving $\{A_{11},A_{12},T_4\}$, ${EV}_i$ first checks the freshness of $T_4$, and then calculates and verifies:

$$\left(A_7\parallel {ID}_{ei}\parallel {ID}_{dj}\parallel {ID}_{dk}\parallel A_8\right)={Dec}_{A_2^{\prime }}\left(A_{11}\right)$$

$${A^{\prime }}_{12}=h(A_7\parallel A_8\parallel A_{11}\parallel T_4{\parallel ID}_{ei}\parallel {ID}_{dj}\parallel {ID}_{dk})=?A_{12}$$

$${SK}_{ij}=h\left({ID}_{ei}\parallel {ID}_{dk}\parallel T_{r_1}\left(A_7\right)\right)$$

$${A^{\prime }}_8=h({SK}_{kj}\parallel {ID}_{ei}\parallel {ID}_{dj}\parallel {ID}_{dk})=A_8$$

If it is not established, ${\mathrm{E}\mathrm{V}}_{\mathrm{i}}$ terminates the session; if they are equal, ${\mathrm{E}\mathrm{V}}_{\mathrm{i}}$ confirms that ${\mathrm{S}\mathrm{K}}_{\mathrm{i}\mathrm{j}}$ is valid, $\mathrm{S}\mathrm{K}={\mathrm{S}\mathrm{K}}_{\mathrm{k}\mathrm{j}}={\mathrm{S}\mathrm{K}}_{\mathrm{i}\mathrm{j}}$ and the three-party session key agreement is completed. As a temporary key, the session key is tied to the random numbers and timestamps of each session and independent of long-term data. Once it expires, the rescue vehicle can generate a new key by re-authenticating, with no need to register again with the TA.

5.4. Password Update Phase

Step 1: ${\mathrm{U}}_i$ inputs ${ID}_{ui}$, the old password ${PW}_{ui}^{\prime }$ and ${BIO}_{ui}^{\prime }$, recovers the biometric key and verifies the identity:

$${\omega }_i^{\prime }=Rep({BIO}_{ui}^{\prime },{\theta }_i),$$

$$H_1^{\prime }=h\left({ID}_{ui}\parallel {PW}_{ui}^{\prime }\parallel {\omega }_i^{\prime }\right)mod n_0=?H_1.$$

Step 2: After successful verification, ${\mathrm{U}}_i$ inputs a new password ${PW}_{ui}^{new}$.

Step 3: The OBU calculates the new identity verification value:

$$H_1^{new}=h({ID}_{ui}\parallel {PW}_{ui}^{new}\parallel {\omega }_i^{\prime })mod n_0.$$

Step 4: The OBU replaces the old verification value $H_1$ stored in the OBU with the new verification value $H_1^{new}$, and the password update is completed.

6. Formal Security Proof

In this section, we prove the semantic security of the proposed three-party authentication and key-agreement protocol in the random-oracle model (ROM). Let $\mathcal{A}$ be a probabilistic polynomial-time adversary that controls the public channel and interacts with protocol instances through the oracles defined below. The protocol is considered secure if $\mathcal{A}$ has only negligible advantage in distinguishing the real session key from a random string, assuming that the Chebyshev Polynomial Computational Diffie–Hellman Problem (CPCDHP) and the Chebyshev Polynomial Discrete Logarithm Problem (CPDLP) are hard.

6.1. Definition of Random Oracle Model

Definition 1 (Participants and Partnership).

In the proposed protocol, mutual authentication and key agreement are accomplished through the collaboration of the following participants: the Field Survey Drone ($D_k$), the Relay Drone ($D_j$), and the Emergency Rescue Vehicle/User (${EV}_i\left({\mathrm{U}}_i\right)$). All participants are collectively referred to as P. For the i-th instance, the participants are denoted as follows: $\mathrm{I}{\mathrm{n}}_{\mathrm{P}}^{\mathrm{i}},\mathrm{I}{\mathrm{n}}_{{\mathrm{D}}_{\mathrm{k}}}^{\mathrm{i}},\mathrm{I}{\mathrm{n}}_{{\mathrm{D}}_{\mathrm{j}}}^{\mathrm{i}},\mathrm{I}{\mathrm{n}}_{{\mathrm{E}\mathrm{V}}_{\mathrm{i}}}^{\mathrm{i}}$. Participants with the same session identifier are considered to belong to the same session. When ${EV}_i\left({\mathrm{U}}_i\right)$,$D_j$, and $D_k$ receive valid and legitimate requests and successfully verify the hash values and timestamps, they enter the Accept state. If the three parties belong to the same session, the session keys they negotiate must be identical, i.e., $\mathrm{S}\mathrm{K}={SK}_{kj}={SK}_{ij}$.

Definition 2 (Query).

To simulate the capabilities of an adversary $\mathcal{A}$, the following queries are defined:

• Execute Query ($I{n}_P^i$): When this query is executed, $\mathcal{A}$ can obtain all publicly transmitted parameters.
• Send Query ($\mathrm{I}{\mathrm{n}}_{\mathrm{P}}^{\mathrm{i}},\mathrm{m}$): $\mathcal{A}$ sends a message m to $\mathrm{I}{\mathrm{n}}_{\mathrm{P}}^{\mathrm{i}}$. The instance returns the protocol response if m passes timestamp and identity verification; otherwise, it is ignored.
• Reveal Query ($\mathrm{I}{\mathrm{n}}_{{\mathrm{D}}_{\mathrm{k}}}^{\mathrm{i}},\mathrm{I}{\mathrm{n}}_{{\mathrm{D}}_{\mathrm{j}}}^{\mathrm{i}},\mathrm{I}{\mathrm{n}}_{{\mathrm{E}\mathrm{V}}_{\mathrm{i}}}^{\mathrm{i}}$) : If the Test query has not been executed and the session key has been successfully negotiated, $\mathcal{A}$ can obtain the session key SK by performing this query.
• Corrupt Query ($\mathrm{I}{\mathrm{n}}_{{\mathrm{E}\mathrm{V}}_{\mathrm{i}}}^{\mathrm{i}}$): For PUF-protected devices, Corrupt Query ($\mathrm{I}{\mathrm{n}}_{{\mathrm{E}\mathrm{V}}_{\mathrm{i}}}^{\mathrm{i}}$) does not give the live PUF response unless the $\mathcal{A}$ also physically activates the corresponding unclonable hardware. The OBU of the user stores parameters $\{{ID}_{ei},{ Y}_{ei},B_{ei},{ Cha}_{ei},{ \theta }_i,{ H}_1,{ H}_2,{ n}_0\}$, and $\mathcal{A}$ can obtain these parameters by executing this query.
• Test Query ($\mathrm{I}{\mathrm{n}}_{{\mathrm{D}}_{\mathrm{k}}}^{\mathrm{i}},\mathrm{I}{\mathrm{n}}_{{\mathrm{D}}_{\mathrm{j}}}^{\mathrm{i}},\mathrm{I}{\mathrm{n}}_{{\mathrm{E}\mathrm{V}}_{\mathrm{i}}}^{\mathrm{i}},\mathrm{r}$) : When this query is executed, it first generates a random bit r. If the session key has been generated and r  =  1, the query returns the correct session key to  $\mathcal{A}$. If r  =  0, it returns a random number. If none of the above conditions are met, an empty string is returned. This query can be executed at most once.

Definition 3 (Freshness).

An instance is considered fresh if the following conditions are satisfied:

• P and all of its matching partners have accepted the same sid;
• Neither P* nor any matching partner has been queried by Reveal;
• Corrupt queries, if any, do not expose all factors required to reconstruct the test session, namely the live PUF response, the correct password, the biometric reconstruction value, and the session randomness r₁ and r₂;
• The ephemeral values used in the test session have not been reused in another accepted session.

Definition 4 (Semantic Security).

Generates a random bit ${\mathrm{r}}_{\mathrm{guess}}$ to guess the bit r generated by the Test query. If ${\mathrm{r}}_{\mathrm{guess}}=\mathrm{r}$, it shows that A has determined if the Test query returned the correct session key, and the semantic security of protocol $\mathsf{\Pi }$ is compromised. The probability of this event is defined as: $\mathrm{Ad}{\mathrm{v}}_{\mathsf{\Pi }}^{\mathcal{A}}=|2\mathrm{Pr}[{\mathrm{r}}_{\mathrm{guess}}=\mathrm{r}]-1|=|2\mathrm{Pr}[\mathrm{Sicces}{\mathrm{s}}_{\mathcal{A}}]-1|$. If $\mathrm{Ad}{\mathrm{v}}_{\mathsf{\Pi }}^{\mathcal{A}}<\mathsf{\eta }$, where $\mathsf{\eta }$ is a negligible value, then $\mathsf{\Pi }$ is regarded as possessing semantic security.

6.2. Formal Proof

Theorem 1.

Let ${\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}$, ${\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}$, and ${\mathrm{q}}_{\mathrm{e}\mathrm{x}\mathrm{e}}$ denote the number of hash queries, send queries, and execute queries, respectively. Let ${\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}$, ${\mathrm{l}}_{\mathrm{n}\mathrm{o}\mathrm{n}\mathrm{c}\mathrm{e}}$, and ${\mathrm{l}}_{\mathsf{\sigma }}$ represent the bit lengths of the hash values, random nonces, and biometric keys, respectively. Let ${\mathrm{C}}^{\prime }$ and ${\mathrm{s}}^{\prime }$ be the regression parameters of the password space. The advantage of an adversary $\mathcal{A}$ in breaking the protocol $\mathsf{\Pi }$ satisfies the following bound: 

$$\mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathsf{\Pi }}^{\mathcal{A}}\le {\displaystyle \frac{{\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}^2}{2^{{\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}}}}+{\displaystyle \frac{({\mathrm{q}}_{\mathrm{e}\mathrm{x}\mathrm{e}}+{\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}{)}^2}{2^{{\mathrm{l}}_{\mathrm{n}\mathrm{o}\mathrm{n}\mathrm{c}\mathrm{e}}}}}+{\mathrm{C}}^{\prime }\cdot {\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}^{{\mathrm{s}}^{\prime }}\cdot {\displaystyle \frac{{\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}}{2^{{\mathrm{l}}_{\mathsf{\sigma }}}}}+2{\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}\cdot \left(\mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{P}\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}+{\displaystyle \frac{1}{2^{{\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}}}}\right)+2\mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{P}\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}$$

The proof is conducted through a sequence of games where $\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_{\mathrm{i}}$ denotes the event that $\mathcal{A}$ successfully distinguishes the session key from a random string in $\mathrm{G}\mathrm{a}\mathrm{m}{\mathrm{e}}_{\mathrm{i}}$.

${\mathrm{Game}}_0$: We simulate a real attack initiated by $\mathcal{A}$. Based on the definition of advantage, the probability satisfies:

$$\mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathsf{\Pi }}^{\mathcal{A}}=\left|2\mathrm{Pr}\right[\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_0]-1|$$

$\mathrm{G}\mathrm{a}\mathrm{m}{\mathrm{e}}_1$: In this game, the adversary $A$ issues Execute queries to passively eavesdrop on all messages transmitted over the public open channel. In protocol $\mathsf{\Pi }$, the session key is established as $SK = h\left(I{D}_{\left\{ei\right\}}\parallel I{D}_{\left\{dk\right\}}\parallel T_{\left\{r1\right\}}\left(T_{\left\{r2\right\}\left(x\right)}\right)\right)$. The public communication transcript only exposes the components $A_1= T_{\left\{r1\right\}\left(x\right)}$ and $A_7= T_{\left\{r2\right\}\left(x\right)}$. Deriving the shared secret $T_{\left\{r1\right\}}\left(T_{\left\{r2\right\}\left(x\right)}\right)$ from the exposed values $T_{\left\{r1\right\}\left(x\right)}$ and $\left(T_{\left\{r2\right\}\left(x\right)}\right)$ is directly equivalent to solving an instance of the Chebyshev Polynomial Computational Diffie–Hellman Problem (CPCDHP). Therefore, $A$ cannot gain any advantage in distinguishing the real session key from a random string without solving the CPCDHP. Consequently, the success probability of $A$ in $\mathrm{G}\mathrm{a}\mathrm{m}{\mathrm{e}}_1$ satisfies:

$$\left|\mathrm{Pr}\right[\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_2]-\mathrm{Pr}[\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_1\left]\right|\le \mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{P}\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}$$

$\mathrm{G}\mathrm{a}\mathrm{m}{\mathrm{e}}_2$: In the protocol, messages consist of hash values, the results of exclusive OR operations, and nonce. This simulation contains adversary A executing execute queries to get messages, followed by send and hash queries to launch collision attacks. By the birthday bound, the probability of a hash collision is at most ${\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}^2/2^{{\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}+1}$, and the probability of a repeated nonce or replayed session randomness across Send/Execute queries is at most $({\mathrm{q}}_{\mathrm{e}\mathrm{x}\mathrm{e}}+{\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}{)}^2/2^{{\mathrm{l}}_{\mathrm{n}\mathrm{o}\mathrm{n}\mathrm{c}\mathrm{e}}+1}$. This leads to the following inequality:

$$|\mathrm{Pr}[\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_2]-\mathrm{Pr}[\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_1]|\le {\displaystyle \frac{{\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}^2}{2^{{\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}+1}}}+{\displaystyle \frac{({\mathrm{q}}_{\mathrm{e}\mathrm{x}\mathrm{e}}+{\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}{)}^2}{2^{{\mathrm{l}}_{\mathrm{n}\mathrm{o}\mathrm{n}\mathrm{c}\mathrm{e}}+1}}}$$

$\mathrm{G}\mathrm{a}\mathrm{m}{\mathrm{e}}_3$: We simulate the Corrupt query where $\mathcal{A}$ obtains the internal data $\left\{{ID}_{ei},{ Y}_{ei},B_{ei},{ Cha}_{ei},{ \theta }_i,{ H}_1,{ H}_2,{ n}_0\right\}$ from the on-board unit to extract $H_1=h\left({ID}_{ui}\parallel {PW}_{ui}\parallel {\omega }_i\right)mod n_0,$which necessitates the simultaneous guessing of the password $\mathrm{P}{\mathrm{W}}_{\mathrm{u}\mathrm{i}}$ and the biometric key ${\mathsf{\omega }}_{\mathrm{i}}$. According to Zipf’s law [45], the upper bound of this guessing probability is estimated as follows:

$$|\mathrm{Pr}[\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_3]-\mathrm{Pr}[\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_2]|\le {\displaystyle \frac{{\mathrm{C}}^{\prime }\cdot {\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}^{{\mathrm{s}}^{\prime }}\cdot {\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}}{2\cdot 2^{{\mathrm{l}}_{\mathsf{\sigma }}}}}$$

$\mathrm{G}\mathrm{a}\mathrm{m}{\mathrm{e}}_4$: $\mathcal{A}$ attempts to solve the computational Diffie–Hellman problem directly or exploit the one-way property of the hash function to decrypt ${SK}_{kj}=h\left({ID}_{ei}\parallel {ID}_{dk}\parallel T_{r_2}\left(A_1\right)\right),{SK}_{ij}=h\left({ID}_{ei}\parallel {ID}_{dk}\parallel T_{r_1}\left(A_7\right)\right)$. The simulation models $\mathcal{A}$’s attempts to compute these keys after issuing execute and hash queries. In scenario one, $\mathcal{A}$ performs a hash collision attack, whose maximum probability is ${\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}/2^{{\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}}$. In the second scenario, given $A_1=T_{r_1}\left(x\right)$, $A_2=T_{r_1}\left(Y_{d\mathrm{j}}\right)$, $\mathcal{A}$ attempts to compute $T_{r_2}\left(A_1\right)$, with a maximum probability of ${\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}\cdot \mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}$, where $\mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}<\mathsf{\eta }$ and η is sufficiently small, and the advantage in resolving the Computational Diffie–Hellman Problem (CPCDHP) of the chaotic map is ${\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}\cdot \mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}$. Thus, we obtain:

$$|\mathrm{Pr}[\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_4]-\mathrm{Pr}[\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_3]|\le {\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}\cdot (\mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{P}\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}+{\displaystyle \frac{1}{2^{{\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}}}})$$

As $\mathcal{A}$ gains no information regarding the advantage of $\mathrm{S}\mathrm{K}$ in $\mathrm{G}\mathrm{a}\mathrm{m}{\mathrm{e}}_4$, the success probability is $\mathrm{Pr}\left[\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}{\mathrm{s}}_4\right]=1/2$. To conclude, we combine the probability terms using the triangle inequality:

$$\begin{array}{c}{\displaystyle \frac{1}{2}}Ad{\mathrm{v}}_{\mathsf{\Pi }}^{\mathcal{A}}=|\mathrm{P}\mathrm{r}[Succes{\mathrm{s}}_0]-{\displaystyle \frac{1}{2}}|\hfill \\ \hspace{1em}\hspace{1em}\hspace{1em} \le {\displaystyle \frac{{\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}^2}{2^{{\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}+1}}}+{\displaystyle \frac{({\mathrm{q}}_{\mathrm{e}\mathrm{x}\mathrm{e}}+{\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}{)}^2}{2^{{\mathrm{l}}_{\mathrm{n}\mathrm{o}\mathrm{n}\mathrm{c}\mathrm{e}}+1}}}+{\displaystyle \frac{{\mathrm{C}}^{\prime }\cdot {\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}^{{\mathrm{s}}^{\prime }}\cdot {\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}}{2\cdot 2^{{\mathrm{l}}_{\mathsf{\sigma }}}}}+Ad{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{P}\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}\hfill \\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em} +{\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}\cdot (Ad{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}+{\displaystyle \frac{1}{2^{{\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}}}})\hfill \end{array}$$

That is,

$$\mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathsf{\Pi }}^{\mathcal{A}}\le {\displaystyle \frac{{\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}^2}{2^{{\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}}}}+{\displaystyle \frac{({\mathrm{q}}_{\mathrm{e}\mathrm{x}\mathrm{e}}+{\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}{)}^2}{2^{{\mathrm{l}}_{\mathrm{n}\mathrm{o}\mathrm{n}\mathrm{c}\mathrm{e}}}}}+{\mathrm{C}}^{\prime }\cdot {\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}^{{\mathrm{s}}^{\prime }}\cdot {\displaystyle \frac{{\mathrm{q}}_{\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}}{2^{{\mathrm{l}}_{\mathsf{\sigma }}}}}+2{\mathrm{q}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}\cdot \left(\mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{P}\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}+{\displaystyle \frac{1}{2^{{\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}}}}\right)+2\mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathcal{A}}^{\mathrm{C}\mathrm{P}\mathrm{C}\mathrm{D}\mathrm{H}\mathrm{P}}$$

By substituting the values from each stage and applying the relevant scaling coefficients, the upper bound of the advantage in Theorem 1 is verified. When the security parameters ${\mathrm{l}}_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}$ and ${\mathrm{l}}_{\mathrm{n}\mathrm{o}\mathrm{n}\mathrm{c}\mathrm{e}}$ are sufficiently large, $\mathrm{A}\mathrm{d}{\mathrm{v}}_{\mathsf{\Pi }}^{\mathcal{A}}$ approaches a negligible value, confirming that protocol $\mathsf{\Pi }$ maintains semantic security.

7. Informal Security Analysis

7.1. Verification Table Theft Attack

The TA of the proposed protocol does not store any information related to user passwords or biometrics. Therefore, it can effectively resist verification table theft attacks caused by the compromise of the TA.

7.2. Node Capture Attack

The relay drone, field survey drone, and emergency rescue vehicle operate in an open physical environment and are highly vulnerable to physical capture. This protocol uses physical unclonable functions (PUFs) to protect devices. The values stored in the devices are $B_{ei}=s_{ei}\oplus \mathrm{h}\left({Res}_{ei}\right)$, $D_{dj}=s_{dj}\oplus h\left({Res}_{dj}\right)$, and $D_{dk}=s_{dk}\oplus \mathrm{h}\left({Res}_{dk}\right)$.

Even if an attacker extracts data from non-volatile memory through side-channel attacks, the core secrets $s_{ei}$, $s_{dj}$ and $s_{dk}$ cannot be recovered without the PUF response of the specific device, thus defending against node capture attacks.

7.3. User Device Loss Attack

The OBU of an emergency rescue vehicle stores parameters $\{{ID}_{ei},{ Y}_{ei},B_{ei},{ Cha}_{ei},{ \theta }_i,$ ${ H}_1,{ H}_2,{ n}_0\}$. Both ${ H}_1$ and ${ H}_2$ are strongly associated with the user’s biometric extraction value ${\omega }_i$ and password ${PW}_{ui}$. If an attacker steals the OBU, without the legitimate user’s ${BIO}_{ui}$ and ${PW}_{ui}$, they cannot compute valid verification parameters to initiate login authentication.

7.4. Impersonation Attack

To impersonate a legitimate ${EV}_i$, an attacker must correctly generate message $A_4$ protected by the shared secret $A_2$. Computing $A_2=T_{r_1}\left(Y_{dk}\right)$ requires system parameters, while the decryptor $D_j$ performs verification using the internally recovered $s_{dj}$. Similarly, impersonating a $D_k$ requires the correct PUF response to recover $s_{dk}$. Since the attacker cannot obtain passwords, biometric information, or the PUF characteristics of the device, impersonation attacks are infeasible.

7.5. Mutual Authentication

The protocol achieves strict mutual authentication during the authentication phase. $D_j$ confirms ${EV}_i$ by decrypting $A_4$ and verifying ${PID}_1$; $D_k$ confirms $D_j$ by decrypting $A_5$ and verifying $A_6$. Then $D_k$ sends $A_9$ and $A_{10}$ to $D_j$ to prove its identity, and $D_j$ sends $A_{11}$ and $A_{12}$ protected by $A_2$ to ${EV}_i$. Each message transmission contains a random challenge generated by the peer or cryptographic binding, ensuring the authenticity of each entity’s identity.

7.6. Replay Attack

This protocol constructs replay defense by strictly binding fresh timestamps $(T_1,T_2,T_3,T_4 \mathrm{a}\mathrm{n}\mathrm{d} T_1^{\prime },T_2^{\prime }$ during message delivery) and a random nonce to each transmitted message. After receiving a message, the receiver first verifies the freshness of the timestamp, and then verifies the correctness of the nonce. Stale packets outside the valid time window are directly discarded, effectively preventing malicious replay of historical data.

7.7. Offline Identity/Password Guessing Attack

User identity and password are embedded in $H_1=h\left({ID}_{ui}\parallel {PW}_{ui}\parallel {\omega }_i\right)mod n_0$. Even if an adversary obtains device storage information and user biometrics, and guesses $({ID}_{ui},{ PW}_{ui})$ to satisfy $H_1=h\left({ID}_{ui}\parallel {PW}_{ui}\parallel {\omega }_i\right)mod n_0$, when $n_0=2^8$ [46], the number of candidate $({ID}_{ui},{ PW}_{ui})$ pairs meeting the condition is approximately:

$${\displaystyle \frac{\left|{\mathrm{D}}_{\mathrm{I}\mathrm{D}}\right|·\left|{\mathrm{D}}_{\mathrm{P}\mathrm{W}}\right|}{{\mathrm{n}}_0}}\approx 2^{32}.$$

This means the adversary cannot determine the correct identity–password pair and must confirm it through online verification. The server can restrict the number of online attempts through predefined policies, thus resisting such attacks.

7.8. Perfect Forward Secrecy

The session key is derived from the Chebyshev CDH value and bound to session-specific ephemeral nonces. Its construction is based on the CPCDHP problem, with the session key defined as ${SK}_{ij}=h({ID}_{ei}\parallel {ID}_{dk}\parallel T_{r_1}(A_7\left)\right)$ (where $A_7=T_{r_2}\left(x\right)$). The session key is entirely determined by the ephemeral random numbers $r_1$ and $r_2$ temporarily generated by both communicating parties. Even if the long-term private keys $s_{TA}, s_{ei}, s_{dj} or s_{dk}$ are compromised, an attacker cannot compute $T_{r_1}\left(T_{r_2}\right(x\left)\right)$ without knowledge of the ephemeral random numbers, thus ensuring the absolute security of historical sessions.

7.9. Known-Key Security

Nonces generated for different sessions are mutually independent. Leakage of one session key offers adversaries no advantage in compromising other sessions. Since brand-new random numbers $r_1$ and $r_2$ are generated for each communication session, the derived session keys (SKs) across different sessions exhibit strict mathematical independence. Therefore, even if an attacker happens to obtain the SK of a historical session, they cannot utilize that information to derive the keys for any other sessions.

7.10. Anonymity and Unlinkability

The real identities of users and drones, namely ${ID}_{ei}$, ${ID}_{dj}$, and ${ID}_{dk}$, are never transmitted in plaintext over public channels. Instead, they are embedded within symmetric ciphertexts, such as $A_4={Enc}_{A_2}({ID}_{ei}\parallel {MSG}_{req}\parallel Y_{ei}\parallel {PID}_1)$. The encryption keys (e.g., $A_2$) possess dynamic randomness that is updated per session. This not only guarantees strong anonymity for the devices but also ensures the unlinkability of message trajectories.

7.11. Resistance to Single Point of Failure

In this protocol, the TA only handles pre-deployment registration and initialization, and does not participate in real-time rescue communication or authentication. Emergency rescue vehicles, relay drones, and field survey drones complete authentication and session key agreement without relying on a centralized online node. If a relay drone fails or loses connection, only the current relay path is affected. Since the relay drone does not store the long-term secrets of rescue vehicles or survey drones, a rescue vehicle that receives no valid response within a tolerable time threshold can select another nearby relay and restart authentication. Therefore, the protocol reduces the single point of failure risk associated with an online TA or a fixed relay.

7.12. Three-Factor Security

User authentication relies on three factors: (1) the possessed physical entity (the OBU equipped with PUF), (2) the known password ${PW}_{ui}$, and (3) the inherent biometric attribute ${BIO}_{ui}$. For an attacker to compromise the system, they must simultaneously acquire and crack all three factors; none can be omitted. This achieves a high level of three-factor security.

7.13. Man-in-the-Middle Attack Resistance

All handshake negotiation parameters are subject to strict hash integrity verification. For instance, the parameter $A_{12}$ received by the ${EV}_i$ is a joint hash value generated based on $A_7,{ A}_8,{ A}_{11}, T_4$ and entity identities. Any man-in-the-middle attempt to tamper with $A_1$ or $A_7$ during transmission will result in inconsistent session keys SK derived by both parties, which will be exposed during the key verification phase of the protocol, thereby promptly terminating the connection.

7.14. Session Key Security

The final established session key (SK) is not directly transmitted over the wireless channel and incorporates the identity information of both the ${EV}_i$ and $D_k$. Its security completely relies on Chebyshev Polynomial Computational Diffie–Hellman Problem (CPCDHP). Since an attacker who intercepts $A_1=T_{r_1}\left(x\right)$ and $A_7=T_{r_2}\left(x\right)$ cannot compute $T_{r_1{r}_2}\left(x\right)$ in polynomial time, this protocol provides high-intensity confidentiality guarantees for subsequent transmission of on-site images and environmental data.

7.15. Adaptability to Drone Mobility and Intermittent Connectivity

Each relay drone is selected on demand and stores no long-term secrets of vehicles or survey drones. If the current relay drone becomes unavailable due to unstable links or packet loss, the rescue vehicle can re-authenticate via other nearby relay drones after exceeding the tolerable time threshold.

7.16. Resistance to Desynchronization Attacks

In the proposed protocol, no long-term shared state is updated after each successful session. Therefore, packet loss or relay reselection does not leave the rescue vehicle, helper drone, or survey drone with inconsistent counters or session-dependent credentials, reducing exposure to desynchronization attacks.

7.17. Resistance to Denial-of-Service (DoS) Attacks

During the authentication process, each party verifies the freshness of timestamps and the correctness of nonce upon receiving messages, and performs only lightweight hash, symmetric encryption, and Chebyshev chaotic map operations. Thus, replayed or forged messages can be detected quickly, preventing excessive consumption of bandwidth and computational resources.

7.18. Resistance to GPS Spoofing

Location information is used solely for drone selection and never as an authentication credential. Even in the event of GPS spoofing, if the rescue vehicle does not receive feedback within a tolerable time threshold, it will simply reselect a new drone for authentication. Therefore, forged location information cannot compromise the protocol execution.

8. Performance Evaluation

In this section, we compare the proposed protocol with related schemes from six dimensions: security properties, computational overhead, communication overhead, energy consumption, scalability, and latency/mobility support. The goal is not only to compare primitive counts, but also to clarify whether the protocol remains practical for drone-assisted VANET rescue under resource constraints and changing network topology.

8.1. Security Comparison

We systematically analyze and summarize the security features of existing related protocols. Table 3 clearly presents the detailed comparison results of the proposed protocol in this paper with various protocols in the above literature [17,22,23,27] in terms of security indicators and core functional characteristics.

Table 3. Security feature comparison.

Attacks/Properties	[17]	[22]	[23]	[27]	Ours
Captured Attack	✓	✗	✗	✓	✓
Off-line Password Guessing Attack	✓	-	✓	-	✓
Replay Attack	✓	✓	✓	✓	✓
Man-in-Middle Attack	✓	✓	✓	✓	✓
Stolen-Verifier Attack	✓	✓	✓	✓	✓
Know Session Key Attack	✓	✓	✓	✓	✓
Impersonation Attack	✗	✓	✓	✓	✓
Mutual Authentication	✓	✓	✓	✓	✓
Perfect Forward Secrecy	✗	✓	✓	✓	✓
Session Key Secrecy	✗	✓	✓	✓	✓
Three-factor security	✗	-	✗	-	✓
Malicious Message Tracking	✓	✓	✗	✗	✓
Anonymity and Unlinkability	✓	✓	✗	✗	✓
Single-Point-of-Failure Resistance	✗	✗	✗	✗	✓

8.2. Computational Cost

Let $T_H, T_{AS}, T_{ED}, T_{PUF}, T_{BP}, T_{ECC} and T_{CM}$ denote the execution time of Hash (SHA-256), Asymmetric encryption/decryption (RSA1024), Symmetric encryption/decryption (AES-256), PUF, Bilinear pairing, Elliptic curve multiplication and Chebyshev chaotic map. According to Raspberry Pi 4B quad-core 64-bit ARM Cortex-A72, 1.5 GHz, 2-GB LPDDR4SDARM, the computation results are $T_H\approx 0.009$ ms, $T_{AS}\approx 19.536$ ms, $T_{ED}\approx 0.794$ ms, $T_{PUF}\approx T_H$, $T_{BP}\approx 44.517$ ms, $T_{ECC}\approx 2.610$ ms, and $T_{CM}\approx 0.195$ ms. Table 4 lists these values for performance evaluation.

Table 4. Computation cost.

Operation	Description	Execution Time (ms)
$T_H$	One-way hash function	0.009
$T_{AS}$	Asymmetric encryption/decryption	19.536
$T_{ED}$	Symmetric encryption/decryption	0.794
$T_{PUF}$	Physical unclonable function	$\approx {\mathrm{T}}_{\mathrm{h}}$
$T_{BP}$	Bilinear pairing operation	44.517
$T_{ECC}$	Elliptical curve scalar multiplication	2.610
$T_{CM}$	Chebyshev chaotic map	0.195
$T_{Gen}$	Fuzzy extractor generation function	0.352
$T_{rep}$	Fuzzy extractor reproduction function	0.450

The comparison of computational overhead in Table 5 shows that the proposed scheme takes 9.898 ms, demonstrating better computational performance than the schemes in [17,22,23,27]. Compared with these schemes, the computation cost of our proposed scheme is reduced by 37.90%, 5.62%, 65.72%, and 93.70%, respectively, which indicates that our scheme achieves the optimal computational efficiency among all compared approaches.

Table 5. Comparison of computation cost.

Scheme	Vehicle/User	RSU/Dk	TA/GS/Dj	Time (ms)
[17]	${3T}_{ECC}+10T_H$	2$T_{ECC}+9T_H$	$1T_{ECC}+2T_H$	15.939
[22]	$5T_{CM}+4T_{ED}+9T_H$	$1T_{CM}+3T_{ED}+6T_H$	$6T_{CM}+3T_{ED}+8T_H$	10.487
[23]	$4T_{ECC}+7T_H$	$1T_{ECC}+4T_H$	$T_{ECC}+7T_H$	28.872
[27]	—	${5T}_{ECC}+6T_H+2T_{BP}$	$4T_{ECC}+4T_H+1T_{BP}$	157.131
Ours	$4T_{CM}+2T_{ED}+7T_H$+ 1$T_{rep}$	$6T_H+5T_{CM}+2T_{ED}$	$6T_H+6T_{CM}+4T_{ED}$	9.898

Figure 7 clearly shows the above comparison results of computational overhead in an intuitive visual form.

Figure 7. Comparison of computational costs with existing schemes [17,22,23,27].

8.3. Communication Cost

Data transmission volume also plays an important role in communication performance. In our environment, the lengths are set as follows: SHA-256 outputs 256 bits, AES-128 symmetric encryption works with 128 bits, an ECC point is defined as 160 bits, a random number is 256 bits, and the output of the extended Chebyshev chaotic map is 160 bits. Additionally, identity, password, counter, and timestamp each have a length of 16 bits. In the AKA phase, the cost in our protocol is: $\left\{A_1,A_4,T_1\right\}+\left\{A_5,A_6,T_2\right\}+\left\{A_7,A_9,A_{10},T_3\right\}+\left\{A_{11},A_{12},T_4\right\}=\left(160+128+16\right)+\left(128+256+16\right)+\left(160+128+256+16\right)+\left(160+256+16\right)=304+400+560+432=1696 \mathrm{b}\mathrm{i}\mathrm{t}\mathrm{s}.$

From Table 6, our scheme has a communication cost of 1696 bits. Reference [22] is 1216 bits, reference [17] is 2144 bits, reference [23] is 2360 bits and reference [27] is 5792 bits. Our overhead is slightly higher than [22] but much lower than [17,23,27]. Reference [22] only implements basic two-party authentication between a single drone and vehicle, lacking multi-node relay for rescue missions.

Table 6. Comparison of communication cost.

Scheme	No. of Messages	Bits
[17]	4	2144
[22]	3	1216
[23]	3	2360
[27]	3	5792
Ours	4	1696

8.4. Energy Cost

Drones and vehicular terminals are typical resource-constrained devices with limited battery capacity. The energy consumption of the authentication protocol directly determines device endurance and continuous operating time in post-disaster emergency scenarios. We conduct all measurements on a Raspberry Pi 4B (quad-core ARM Cortex-A72, 1.5 GHz, 2 GB LPDDR4 RAM) to record the energy consumption of core cryptographic primitives.

This scheme employs finite-field Chebyshev chaotic maps for key agreement, combined with AES-128 symmetric encryption, SHA-256 hash, PUFs and fuzzy extractors. The measured energy consumption of each basic operation is as follows: a single SHA-256 hash operation consumes approximately 0.25 μJ, a single AES-128 encryption/decryption operation consumes about 8.6 μJ, and one Chebyshev map iteration consumes around 22 mJ. By contrast, a traditional elliptic curve cryptography (ECC) scalar multiplication costs roughly 80 mJ.

Table 7 compares the total energy consumption of the full authentication process between our scheme and existing related works. The schemes in [17,22,23,27] achieve total energy consumption of 480.00525 mJ, 338.09175 mJ, 1980.175 mJ and 480.00375 mJ, respectively. Benefiting from the low-power feature of Chebyshev chaotic maps, the total energy consumption of the proposed scheme is only 330.07355 mJ, which outperforms all comparative works in energy efficiency.

Table 7. Comparison of energy cost.

Scheme	Cost (mj)
[17]	480.00525
[22]	338.09175
[23]	1980.0025
[27]	480.00375
Ours	330.07355

8.5. Latency

In our proposed drone-assisted authentication scenario for emergency rescue, latency mainly arises from cryptographic computation overhead and transmission hops among rescue vehicles, relay drones, and field survey drones. Our protocol discards high-cost operations, including elliptic curve scalar multiplication and bilinear pairings, and only employs lightweight hash functions, symmetric encryption, PUF response computation and Chebyshev chaotic map operations. The total computation time is less than 10 ms. Switching relay nodes only requires one re-initiated request within the timestamp tolerance window.

Setting of the tolerance threshold (ΔT): Based on our experimental measurements of end-to-end latency along the transmission path of rescue vehicle–relay drone–survey drone (the average computation time for a single authentication is approximately 10 ms), and considering that the maximum end-to-end latency under normal VANET transmission is 25 ms, we set the timestamp freshness threshold to ΔT = 0.5 s. This provides sufficient margin for latency fluctuations caused by severe network congestion, packet loss and device mobility.

8.6. Complexity and Scalability

Single-Session Protocol Complexity: Each entity (EV_i, D_j, D_k) executes a fixed set of hash, symmetric cryptography, PUF and Chebyshev operations per protocol run; message overhead and temporary storage are constant. The scheme achieves O(1) computation, communication and storage complexity per session, ensuring lightweight single interactions.

System Scalability Analysis: With n vehicles and m relays, total load scales as O(n). Ideally each relay bears (n/m)·C cost (C = single-session overhead). More relays disperse authentication tasks, subject to deployment density, packet loss and relay selection rules.

The protocol achieves favorable scalability. When multiple rescue vehicles communicate with survey drones via relays, each relay only executes lightweight hash, PUF and Chebyshev chaotic operations for fast computation. If one relay becomes overloaded by concurrent vehicles, vehicles that receive no feedback within the tolerable time threshold can switch to other relays to relieve the bottleneck.

8.7. Mobility and Relay Replacement

The relay drone is selected on demand and is not bound to a fixed vehicle. If it moves out of range, gets captured or malfunctions, the vehicle that receives no valid response within the timestamp tolerance threshold ΔT re-initiates the request and selects another nearby drone. Because the relay only forwards authentication messages and stores no secret of the vehicle or survey drone, replacing it affects neither past nor future sessions and requires no re-registration, directly addressing the single-point-of-failure problem of the relay node.

For dynamic network conditions, timestamps attached to each message guarantee data freshness; sessions interrupted by intermittent connectivity or packet loss are abandoned after ΔT and transparently re-established through a newly selected relay, keeping the protocol available under post-disaster topology changes.

8.8. Lightweight Mobility Simulation

To evaluate the scalability and mobility for multiple emergency vehicles and relay drones, we build a lightweight discrete-event simulation based on Python 3.12.7. We model relay selection, packet loss, relay reselection, retransmission, relay load, authentication latency and energy consumption. Each test includes four authentication messages with per-hop delay sampled between 2 ms and 10 ms. A total of 2000 authentication events are executed with a fixed random seed for reproducibility.

Figure 8 shows that end-to-end authentication latency remains low as the number of emergency vehicles increases from 20 to 200. The average latency is approximately 35 ms without packet loss and stays below 65 ms under 20% packet loss, indicating that the lightweight authentication design remains usable under non-ideal channel conditions.

Figure 8. Authentication latency under increasing vehicle density.

Figure 9 presents the per-relay authentication load over a 300 s simulation under different vehicle–relay deployment ratios. With fixed relays, per-node load surges as vehicle quantity grows. For 200 vehicles paired with only 2 relays, each node handles 472 authentication requests in 300 s and suffers heavy pressure. Deploying more relays disperses traffic and lowers individual load: expanding relays from 2 to 20 for 200 vehicles reduces average load to 48 events (nearly a 90% drop). For 100 vehicles, relay expansion from 2 to 20 cuts per-relay load from 234 to 24 events.

Figure 9. Relay-load distribution under different vehicle and relay-drone scales.

This proves that scalable relay deployment evenly distributes authentication tasks, avoids single-node overload, and maintains stable performance with massive emergency vehicle access.

We evaluate the overall performance of our scheme under practical vehicular network conditions using four typical urban emergency communication scenarios, as listed in Table 8. All tests adopt a vehicle speed of 50 km/h and a 10% urban packet loss rate. Vehicles and relays grow at a 10:1 ratio, covering scenarios with 20 to 200 vehicles.

Table 8. Performance metrics for typical deployment scenarios.

Vehicles	Relay Drones	Packet Loss	Speed (km/h)	Success Rate	Latency (ms)	Relay Load (Enents/300 s)
20	2	10%	50	96.65%	53.17	47.83
50	5	10%	50	95.20%	52.83	47.60
100	10	10%	50	94.95%	51.84	47.47
200	20	10%	50	96.30%	52.05	48.15

The results show that, when relay drones scale with the number of emergency vehicles, the mean authentication latency remains close to 52–53 ms under 10% packet loss and 50 km/h mobility. The mean relay load remains near 48 authentication events per relay over 300 s, supporting the scalability of the relay-based authentication design under the simulated assumptions.

9. Conclusions

When direct communication between an emergency rescue vehicle and a field survey drone is unavailable, the proposed protocol enables emergency rescue communication by using nearby drones as temporary relays. Based on Chebyshev Diffie–Hellman values, the protocol achieves mutual authentication among the emergency rescue vehicle, the relay drone, and the survey drone, and negotiates a session key for subsequent encrypted communication. The protocol provides lightweight authentication, resistance to forgery and replay attacks, forward secrecy of the session key, and three-factor security. It also reduces dependence on a fixed relay and an online trusted authority by supporting relay reselection under intermittent connectivity. Theoretical analysis and experimental results show that the proposed scheme maintains low computational overhead and is suitable for drone-assisted emergency rescue scenarios.