COAu-IoD: A Cloud and Offline Computing-Assisted Authentication Framework for Lightweight UAV Communication in IoD

Abstract

The Internet of Drones (IoD) enables efficient communications among unmanned aerial vehicles (UAV) via wireless links. Restricted by limited onboard computing resources and complicated operating environments, such a network is vulnerable to external or internal security threats. It is therefore urgent to deploy an effective authentication mechanism to isolate malicious attackers prior to UAV communications. Nevertheless, the conventional identity-based IoD authentication schemes must account for total computation and communication overhead, regardless of the effective instant of authentication messages. In this work, we consider the offline precomputation in the authentication phase before the message is available and add cloud servers as an extra component in IoD to assist limited onboard resources to share partial authentication calculation. As a result, this work proposes a new cloud- and offline-computing-assisted authentication framework, known as COAu-IoD, to provide lightweight communication between a UAV and ground station by transferring heavy computation overhead to the offline phase. We give a security model for this authentication framework and provide an efficient construction based on this framework and a known identity-based signature scheme. What is more, we give its security proof and evaluate its performance using the standard and recent state-of-the-art IoD authentication schemes. The results demonstrate that our COAu-IoD scheme achieves lower online computation and communication overhead for UAVs, at the cost of acceptable offline precomputation overhead.

1. Introduction

Unmanned aerial vehicles (UAVs) have undergone substantial evolution from independent remotely controlled equipment to essential nodes within the Internet of Things (IoT) system. Fueled by advances in 6G communication technologies and space-air-ground integrated networks, the interconnected Internet of Drones (IoD) has emerged as vital cyber-physical infrastructure [1,2,3]. Benefiting from highly dynamic three-dimensional mobility and global internet-enabled seamless air-ground connectivity, the IoD supports an extensive range of real-world applications. These use cases span mission-critical disaster rescue and emergency response, intelligent agricultural management, and urban traffic scheduling, alongside military operations, public healthcare services, and real-time traffic monitoring [4,5].

However, the inherent operational flexibility of the IoD also introduces the severe security flaws [6,7,8]. Operating in untrusted and publicly accessible airspace, UAVs rely on wireless communication links with an inherent broadcast nature, which renders them extremely vulnerable to malicious eavesdropping and interception. The adversaries can exploit this open transmission medium to launch man-in-the-middle and replay attacks, forging control commands and stealing the management privileges of the legitimate users. In such scenarios, a compromised UAV may pose a significant security hazard. To mitigate these severe risks, the rigorous and secure authentication for UAV communication is indispensable. As highlighted in recent studies [9,10] on adversarial attacks against UAV visual and control systems, verifying the legitimacy of communication parties before transmitting flight telemetry is an essential prerequisite for all aerial missions.

While strong authentication is indispensable, some traditional authentication schemes are poorly suited for IoD due to hardware limitations. For example, standard public key infrastructure involves complicated certificate chains that consume considerable bandwidth and computing resources. Constrained by weight, battery and onboard storage, UAV cannot support such intensive cryptographic operations [11]. Related research on zero-trust architectures and edge computing also verifies that hardware restrictions impede the deployment of heavy cryptography on UAVs [12,13,14]. Additionally, a single ground station (GS) will face network paralysis when authenticating large-scale drone swarms with certificates. Accordingly, practical authentication protocols for IoD must be lightweight to balance security and operational efficiency [15].

Nevertheless, existing lightweight authentication schemes inevitably need to account for communication and computational overhead throughout the entire authentication procedure [16,17]. These overheads even arise in the offline stage prior to the generation of authentication messages, irrespective of their available time. As a result, resource-constrained hardware suffers from severe computational and communication burdens.

1.1. Our Result

In this work, we propose a new paradigm of the IoD authentication framework, known as COAu-IoD, which integrates offline precomputation and a cloud server to enhance the efficiency of the corresponding schemes by transferring heavy computation overhead to the offline phase. In this framework, offline precomputation serves as a cache to reduce the burden on low-power devices. Meanwhile, the cloud server acts as a powerful computing resource to precompute and store partial cached values.

Our proposed COAu-IoD framework is more than a combination of online/offline cryptographic techniques and identity-based authentication. It utilizes distributed computing consisting of cloud and precomputation, which further reduces the overhead of the computation and storage on a single node. It is noteworthy that this is not trivial for a secure authentication scheme. We need to create a new cloud-side partial key used for offline verification and generate the partial component for distributed computing. The role of cloud is not used for real-time computation in our proposed framework, but for offline preverification. Some steps of both the signing and verifying stages can not only be performed offline, but also be executed by more powerful KGC and cloud instead of UAVs. Cloud has powerful computing and storage resources and is responsible for heavy computation, while UAV only needs lightweight signing. In conclusion, the primary contributions of this work are summarized as follows:

• New Authentication Framework for Achieving Lightweight UAV-to-GS Communication. This paper presents a novel framework for efficient authentication in the IoD system. Unlike conventional identity-based authentication architecture, the proposed model enables lightweight authentication via a different design. First, we adopt the offline precomputation in this model before the message is available and add a cloud server as an extra component to share authentication calculation with limited onboard resources. In addition, we formally define its authentication framework for UAV communication along with its corresponding security model. The framework separates cloud-side preauthorization and local offline verification. Even under the link outage, UAV-to-GS authentication can still proceed locally without requesting real-time responses from cloud or edge nodes.
• A Concrete Instantiation For Our Authentication Framework. Following the proposed offline and could-assisted authentication mechanism, this work presents an efficient instantiation along with rigorous security proofs based on a known identity-based digital signature. Our construction is far from the simple combination of our model and the signature scheme. Some complex authentication operations can be performed offline by distributed computing by the key generation center and cloud servers in this proposed construction. In addition, the UAV in our scheme only holds the partial component for online signing. Even if the UAV node is hijacked, the adversary cannot obtain the full long-term signing material, which reduces the damage scope of node compromise. What is more, by splitting secret credentials between the cloud and UAV, partial verification tasks are offloaded to the cloud, further mitigating the onboard computation and storage overhead of UAVs without leaking private information.
• Low Communication and Computation Overhead. The high efficiency of our scheme is inherently guaranteed by the designed model. Devices with limited resources only need to perform online computations after the authentication message is available. We compared the efficiency between the standard model and our proposed model. Both theoretical analysis and experimental results demonstrate that our authentication scheme achieves UAV-side lightweight online computation and communication overhead, at the expense of increased but acceptable offline and total costs, such as KGC’s processing and data storage.

1.2. Related Works

The evolution of authentication schemes for IoD can be broadly categorized into three distinct paradigms. Initially, the researchers naturally adapted standard public key infrastructure (PKI) frameworks to secure IoD networks due to the mathematically rigorous trust provided by digital certificates [18,19]. However, the lifecycle management of these certificates creates an overwhelming operational burden in practice. Tasks such as continuous issuance, revocation checking, and the transmission of extensive certificate chains consume critical bandwidth and induce severe communication delays. For commercial-off-the-shelf drones that are already constrained by limited battery capacities and onboard memory, verifying massive certificate chains mid-flight is computationally prohibitive.

To address the computational bottlenecks inherent to PKI-based schemes, research efforts have shifted to hardware-assisted lightweight security designs. Physical unclonable functions (PUF) quickly emerged as a prominent solution in this space [20,21,22]. In the domain of IoD security, Alladi et al. [23] first proposed a PUF-based mutual authentication protocol optimized for UAV-ground communication scenarios. On this basis, Bansal and Sikdar [24] further advanced this paradigm by integrating Shamir’s secret sharing scheme with PUF technology, which effectively counteracts environmental noise interference and achieves reliable fault tolerance for practical deployment. Despite these technological advancements, hardware-centric security solutions suffer from an inherent limitation: they require customized modifications to device silicon chips. This mandatory modification severely compromises backward compatibility with existing legacy UAV fleets. Additionally, most symmetric lightweight protocols paired with PUF-based hardware architectures face critical challenges in scalable key distribution and fail to meet fundamental privacy requirements for IoD systems, including UAV identity anonymity and flight trajectory untraceability [25,26].

For application scenarios where hardware modification of drones is impractical, identity-based cryptography (IBC) provides a viable pure-software alternative [27,28]. Different from PKI, IBC eliminates cumbersome certificate management procedures by directly adopting inherent UAV attributes (e.g., media access control addresses) as public keys for identity authentication. However, conventional IBC schemes still rely on computationally intensive bilinear pairing and scalar multiplication operations. To optimize edge-side processing efficiency, researchers have integrated the online/offline signature paradigm into IBC frameworks to reduce computational overhead [29]. The core advantage of the scheme lies in its dual-phase execution mechanism: complex mathematical computations are completed in the offline preprocessing stage, leaving only lightweight arithmetic operations for time-sensitive online authentication processes. Although this hybrid architecture has achieved promising latency optimization in vehicle-to-grid networks [20], its direct migration to IoD scenarios exposes critical architectural defects. For example, the scheme [30] requires resource-constrained edge nodes (including drones and ground stations) to locally generate and cache a large number of precomputed authentication tokens. For drone devices with limited on-board memory, such local caching mechanisms lead to severe storage resource exhaustion, which fundamentally restricts the scalability of IoD security systems.

1.3. Organization

The remainder of this paper is organized as follows: Section 2 introduces the preliminaries. Section 3 formalizes our system framework and security model. Section 4 presents the concrete construction. Section 5 provides the security proof of our scheme and analyzes the security requirement. Section 6 evaluates the performance of our proposed model and its construction. Finally, we conclude the work in Section 7.

2. Preliminaries

2.1. Notations

The notations used in this article are shown in

Table 1. The notations.

Notations	Descriptions
KGC	Key generation center
GS	Ground station
CS	Cloud server
$ID$	Original identity
$PID$	Pseudonym identity
$\mathbb{G}$	Cyclic additive group of prime order q
m	Authentication message
$\sigma$	Generated signature
$T,t_i$	Timestamp
$pp$	Public system parameter
$H_1(·),H_2(·)$	Cryptographic hash functions
$sk$	Private key of a UAV for online signing
${\mathbb{Z}}_p$	Ring of integers modulo p
$x\leftarrow {\mathbb{Z}}_p$	x is uniformly sampled from ${\mathbb{Z}}_p$

.

2.2. System Model

As illustrated in Figure 1, we consider an offline and cloud-assisted IoD architecture. The system comprises four distinct entities, which are known as the key generation center (KGC), ground station (GS), UAV, and cloud server (CS). These entities are interconnected via the internet backbone, enabling flexible data exchange and remote control. The specific roles and functionalities of each entity are defined as follows:

• KGC. KGC serves as the trusted authority of the system and undertakes its initialization tasks. It generates global public parameters and the system master secret key. Prior to mission deployment, it distributes valid cryptographic key pairs to all authenticated entities, including GS and CS, via secure channels.
• GS. It acts as the local authentication authority and edge gateway, governing all UAVs within its communication coverage. Additionally, GS functions as a local command hub, delivering and forwarding control instructions to successfully authenticated UAVs.
• UAV. It functions as a mobile sensing and execution node with limited resources, including battery power, storage space, and computing capability. In the proposed model, each UAV serves as an online signer. It avoids performing computationally intensive cryptographic operations during flight, which guarantees low-latency communication with GS.
• CS. It acts as a high-performance offline auxiliary computing center with abundant storage and computational resources. Within the proposed framework, it is tasked with reducing the computational overhead of edge devices. Specifically, CS runs resource-heavy offline precomputation algorithms to generate preverified parameters, and functions as a verification cache for subsequent tasks.

2.3. Security Requirements

Given that IoD relies on inherently open wireless channels for UAV communication, our scheme must satisfy the following essential security properties:

• Authentication. No unidentified drone shall be allowed to access the IoD network or send telemetry before legitimacy validation. The UAV and GS must perform an identity-based authentication handshake prior to mission execution. It enables the UAV to confirm its authorized status to the GS, and the flight control commands from the GS are only permitted post successful authentication.
• Anonymity. For authentication in IoD, anonymity refers to the protection of user identity against leakage. As a result, all the attackers, as well as GS, cannot establish a connection between flight data and the user identities.
• Traceability. If there is a UAV that was not certified or has transmitted a forged authentication message, KGC can trace this UAV’s original identity information.

2.4. Elliptic Curve Cryptography

Elliptic curve cryptography (ECC) is the foundation for robust encryption and digital signature schemes. Mathematically, let ${\mathbb{F}}_q$ denote a finite field with a prime order q. An elliptic curve E over this field is characterized by the Weierstrass equation $y^2\equiv x^3+ax+b\left(\mathrm{mod}q\right),$ where the coefficients $a,b\in {\mathbb{F}}_q$. To ensure the curve is non-singular, the discriminant must satisfy the condition $4a^3+27b^2\not\equiv 0\left(\mathrm{mod}q\right)$. The system forms a cyclic group $\mathbb{G}$ of prime order q, which consists of the set of points on E generated by a base point P, plus a special identity element known as the point at infinity $\mathcal{O}$. The cryptographic operations in ECC are fundamentally built upon point addition and scalar multiplication within this group in this work:

• Point Addition. Let $P,A\in \mathbb{G}$ be two distinct points lying on elliptic curve E. Their group addition within $\mathbb{G}$ yields the output point $B=P+A$. The doubling operation, i.e., adding point P to itself in $\mathbb{G}$, is written as $B=2P$. Summing P and its inverse $-P$ produces $\mathcal{O}$, the additive group identity element. Accordingly, the identity rule $P+\mathcal{O}=P$ holds for any $P\in \mathbb{G}$.
• Point Multiplication. Given a point $P\in \mathbb{G}$ and a positive scalar $\pi \in {\mathbb{F}}_q$, the notation $\pi P$ refers to iteratively adding P for $\pi$ times. This operation outputs another point belonging to E, where the scalar satisfies $\pi >0$.

We assume that for any probabilistic polynomial-time (PPT) adversary $\mathcal{A}$, the probability of solving this problem is negligible. We now recall the definition of the ECC discrete logarithm problem (ECDLP).

Definition 1

(ECDLP). Let $\mathbb{G}$ be a cyclic group of prime order q generated by $P\in \mathbb{G}$. Suppose $R=aP$ is a random element within $\mathbb{G}$. It is hard to calculate the number a.

2.5. Identity-Based Signature Scheme BNN

The fundamental approach of our authentication scheme is based on identity-based cryptography. Therefore, we recall a known identity-based digital signature scheme, BNN, introduced by Bellare, Namprempre, and Neven [31], which is the basic component of our formal construction. We now describe the BNN scheme in Figure 2.

3. Our Authentication Framework and Security Model

In this section, we present our cloud- and offline-computing-enabled authentication framework COAu-IoD and its security model for UAV-to-GS communication.

3.1. Definition of COAu-IoD

Definition 2

(COAu-IoD). Our definition of COAu-IoD is inspired by identity-based authentication, combined with cloud- and offline-enabled distributed computing. The details consist of the following six PPT algorithms:

• Initialization ($1^{\lambda },ID$): The initialization algorithm takes as input the security parameter λ and the real identity $ID$ of a UAV. It then produces the system public parameters $pp$, the master secret key $msk$, and the pseudonym ID ($PID$). This phase is executed by the trusted authority KGC. Consequently, in our proposed framework, it enables the KGC to trace malicious UAVs by recovering the original $ID$ using the trapdoor mechanism.
• OffKeyExt ($PID,pp,msk$): The offline key extraction algorithm takes as input the pseudonym $PID$, $pp$, and $msk$. It then derives a credential pair, which consists of a key $s{k}_{cloud}$ for CS and the signer’s private key $sk$ for UAV. Where $s{k}_{cloud}$ represents the partial component for distributed computing, while $sk$ denotes the secret key for extracting the online signature. The KGC transmits $s{k}_{cloud}$ to the CS, and sends $sk$ to the signer UAV via secure channels.
• KGC-SignPre ($pp$): The offline precomputation phase for the signing algorithm is executed by KGC, takes as input the public parameters $pp$, and outputs the precalculated value Ω for the UAV-OnSign algorithm.
• CS-OffVer ($pp,PID,s{k}_{cloud}$): The CS-offline verification algorithm takes as input $pp$, $PID$, and the key $s{k}_{cloud}$. It then outputs the transition parameter ω intended for online verification. In this proposed model, the CS can perform this partial offline precomputation alongside the KGC, as this specific algorithm does not leak any private information. Furthermore, this process can be executed in advance, prior to the online signing phase.
• UAV-OnSign ($m,\Omega ,T,PID,sk$): Once the authentication message is given, the UAV-online signing algorithm takes as input the authentication message m, the precalculated value Ω, the current timestamp T, the pseudonym $PID$, and the private key $sk$. It then computes and outputs the final signature σ for the authentication message m.
• GS-OnVer ($pp,PID,\omega ,m,\sigma$): The GS-online verification algorithm takes as input the public parameters $pp$, pseudonym $PID$, the transition value ω, and the message-signature pair $(m,\sigma )$. Based on the verification result, the GS either accepts or rejects the authentication request initiated by the UAV.

3.2. Security Model

Based on the definition of our COAu-IoD authentication framework discussed above, we now formalize its security model via a game played between a challenger $\mathcal{C}$ and an adversary $\mathcal{A}$. In this model, the adversary $\mathcal{A}$ acts as a malicious entity that attempts to exploit unauthorized partial precomputation values and public parameters in place of legitimate ones.

The Game. The game is defined as the interactive protocol detailed below, which is run jointly by the challenger $\mathcal{C}$ and the adversary $\mathcal{A}$:

• Initialization Phase—the challenger $\mathcal{C}$ runs the initialization algorithm to generate system parameters, and subsequently forwards these parameters to the adversary $\mathcal{A}$.
• Query Phase—the adversary $\mathcal{A}$ executes the following queries in this phase:

  –

  Offline Preprocessing Queries: The adversary $\mathcal{A}$ queries on precomputation of $pp$ and $PID$. $\mathcal{C}$ obtains $\Omega$ and $\omega$, then sends them to the adversary $\mathcal{A}$.

  –

  Private Key Queries: The adversary $\mathcal{A}$ issues a private-key extraction query for a given pseudonym $PID$. In response, the challenger $\mathcal{C}$ generates the corresponding secret key $sk$ and delivers it to $\mathcal{A}$.

  –

  Partial Precomputation Replacement Queries: The adversary $\mathcal{A}$ transmits the new precomputation ${\omega }^{\prime }$ of $PID$ to $\mathcal{C}$. Then $\mathcal{C}$ replaces the original $\omega$ with ${\omega }^{\prime }$ and transmits it to $\mathcal{A}$.

  –

  Signing Queries: The adversary $\mathcal{A}$ submits a signing query for pseudonym $PID$ with respect to the selected authentication message m. The challenger $\mathcal{C}$ computes the corresponding signature $\sigma$ and returns it to $\mathcal{A}$.

• Forgery Phase—after performing all the above queries, adversary $\mathcal{A}$ outputs a forged tuple $(PI{D}^{\ast },m^{\ast },{\sigma }^{\ast })$. $\mathcal{A}$ wins the game if all the following conditions hold:

  –

  ${\sigma }^{\ast }$ is a valid signature.

  –

  $\mathcal{A}$ has never queried the signature on the tuple $(PI{D}^{\ast },m^{\ast })$.

  –

  $\mathcal{A}$ has never obtained the corresponding private key $s{k}^{\ast }$ associated with $PI{D}^{\ast }$ via key queries.

Definition 3.

Our proposed COAu-IoD authentication framework is existentially unforgeable under the adaptively chosen authentication message attacks (EU-CMA) if the advantage of winning the above game for $\mathcal{A}$ is negligible.

3.3. Security Models for Other Features

We now discuss the security models of other features such as conditional anonymity, traceability, key-compromise impersonation, and malicious CS for our framework.

The Game of Anonymity. The conditional anonymity game between a challenger $\mathcal{C}$ and a PPT adversary $\mathcal{A}$ is described as follows:

• Setup: $\mathcal{C}$ runs $\mathsf{Initialization}(1^{\lambda },ID)$ and generates public parameters $pp$ and master secret key $msk$. Publish $pp$ to $\mathcal{A}$.
• Phase 1: $\mathcal{A}$ adaptively issues polynomial-bounded queries to oracles ${\mathcal{O}}_{\mathsf{KeyExt}}(·)$ and ${\mathcal{O}}_{\mathsf{Sign}}(·)$.
• Challenge: $\mathcal{A}$ outputs two distinct honest UAV identities $I{D}_0,I{D}_1$ which have never been queried to ${\mathcal{O}}_{\mathsf{KeyExt}}$. $\mathcal{C}$ samples $b\leftarrow \{0,1\}$, generates the corresponding pseudonym $PI{D}_b$, computes challenge signature ${\sigma }^{\ast }\leftarrow \mathsf{UAV}\text{-}\mathsf{OnSign}(m^{\ast },\Omega ,T,PI{D}_b,s{k}_b)$ and sends $(PI{D}_b,m^{\ast },{\sigma }^{\ast })$ to $\mathcal{A}$.
• Phase 2: $\mathcal{A}$ continues oracle queries, while key extraction queries on $I{D}_0$ and $I{D}_1$ are forbidden.
• Guess: $\mathcal{A}$ outputs bit $b^{\prime }$. $\mathcal{A}$ wins if $b^{\prime }=b$.

The advantage is defined as

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathsf{Anon}}\left(\lambda \right)=\left|\mathrm{Pr}[b^{\prime }=b]-{\displaystyle \frac{1}{2}}\right|.$$

COAu-IoD satisfies conditional anonymity if for all PPT adversaries $\mathcal{A}$, ${\mathsf{Adv}}_{\mathcal{A}}^{\mathsf{Anon}}\left(\lambda \right)$ is negligible in security parameter $\lambda$.

The Game of Traceability. The conditional traceability game between a challenger $\mathcal{C}$ and a PPT adversary $\mathcal{A}$ is described as follows:

• Setup: $\mathcal{C}$ executes $\mathsf{Initialization}(1^{\lambda },ID)$ to obtain $pp$ and $msk$, and sends $pp$ to $\mathcal{A}$.
• Phase 1: $\mathcal{A}$ adaptively invokes oracles ${\mathcal{O}}_{\mathsf{KeyExt}}(·)$ and ${\mathcal{O}}_{\mathsf{Sign}}(·)$ for polynomial times.
• Forgery: $\mathcal{A}$ outputs a forgery tuple $(PI{D}^{†},m^{†},{\sigma }^{†})$. The forgery is valid if

  $$\mathsf{GS}\text{-}\mathsf{OnVer}(pp,PI{D}^{†},{\omega }^{†},m^{†},{\sigma }^{†})=\mathsf{Accept}$$

  and $(m^{†},{\sigma }^{†})$ is not obtained from ${\mathcal{O}}_{\mathsf{Sign}}$.
• Trace Test: $\mathcal{C}$ invokes trapdoor recovery algorithm $\mathsf{TrapdoorRecover}(msk,PI{D}^{†})$. The adversary wins the game if the recovery outputs ⊥.

The advantage of adversary $\mathcal{A}$ is

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathsf{Trace}}\left(\lambda \right)=\mathrm{Pr}\left[\mathsf{GS}\text{-}\mathsf{OnVer}=\mathsf{Accept}\wedge \mathsf{TrapdoorRecover}(msk,PI{D}^{†})=\perp \right].$$

COAu-IoD achieves conditional traceability, if for every PPT adversary $\mathcal{A}$, ${\mathsf{Adv}}_{\mathcal{A}}^{\mathsf{Trace}}\left(\lambda \right)$ is a negligible function of $\lambda$.

The Game of Key-Compromise Impersonation (KCI). It demonstrates that compromising one UAV does not allow impersonation of another:

• Setup: $\mathcal{C}$ runs $\mathsf{Initialization}\left(1^{\lambda }\right)$ and publishes $pp$.
• Phase 1: $\mathcal{A}$ adaptively invokes oracle queries. $\mathcal{A}$ is allowed to corrupt one UAV with pseudonym $PI{D}_{\mathrm{corr}}$ and obtain its private key $s{k}_{\mathrm{corr}}$.
• Forgery: $\mathcal{A}$ outputs an authentication transcript ${\Gamma }^{\ast }$ for an uncorrupted target pseudonym $PI{D}^{\ast }\ne PI{D}_{\mathrm{corr}}$. Adversary $\mathcal{A}$ wins if all conditions below hold:

  –

  ${\Gamma }^{\ast }$ passes the verification algorithm;

  –

  $PI{D}^{\ast }$ corresponds to an honest and uncompromised UAV;

  –

  ${\Gamma }^{\ast }$ is not produced by the signing oracle.

The advantage is

$${\mathrm{Adv}}_{\mathcal{A}}^{\mathrm{KCI}}\left(\lambda \right)=\mathrm{Pr}\left[\mathcal{A}\mathrm{wins}\mathrm{the}\mathrm{KCI}\mathrm{game}\right].$$

The scheme is KCI-resistant if ${\mathrm{Adv}}_{\mathcal{A}}^{\mathrm{KCI}}\left(\lambda \right)$ is negligible for all PPT adversaries $\mathcal{A}$.

The Game of Malicious Cloud Server. It shows that even if the CS is fully compromised, it cannot forge valid signatures without KGC’s master key:

• Setup: $\mathcal{C}$ runs system initialization and sends $pp$ to $\mathcal{A}$. Adversary $\mathcal{A}$ corrupts cloud server and obtains cloud-side secret $s{k}_{\mathrm{cloud}}$.
• Query Phase: $\mathcal{A}$ may call ${\mathcal{O}}_{\mathsf{KeyExt}}$, ${\mathcal{O}}_{\mathsf{OfflinePreprocess}}$, and signing queries for honest UAV entities.
• Forgery: $\mathcal{A}$ outputs a valid authentication transcript ${\Gamma }^{\ast }$ for some honest-UAV pseudonym $PI{D}^{\ast }$. Adversary $\mathcal{A}$ wins when the following apply:

  –

  ${\Gamma }^{\ast }$ is a valid transcript passing verification;

  –

  $\mathcal{A}$ has not retrieved the UAV-side private key $sk$ associated with $PI{D}^{\ast }$;

  –

  ${\Gamma }^{\ast }$ is not generated via the signing oracle.

The advantage is

$${\mathrm{Adv}}_{\mathcal{A}}^{\text{Mal-CS}}\left(\lambda \right)=\mathrm{Pr}\left[\mathcal{A}\mathrm{wins}\mathrm{the}\mathrm{malicious}\text{cloud-server}\mathrm{game}\right].$$

The framework resists malicious cloud-server attacks if ${\mathrm{Adv}}_{\mathcal{A}}^{\text{Mal-CS}}\left(\lambda \right)$ is negligible for every PPT adversary $\mathcal{A}$.

4. The Construction

In this section, we formally describe the proposed authentication scheme for IoD, and then discuss the problems caused by this framework.

4.1. Formal Construction

We now propose a concrete and efficient construction for our IoD authentication model, which is instantiated by our COAu-IoD framework and BNN signature scheme. The flowchart of our scheme is shown in Figure 3. We now describe the detailed authentication process as follows:

• Initialization ($1^{\lambda },ID$)—the KGC initializes the environment and generates the public parameters $pp$ and the master secret key $msk$. Subsequently, a UAV submits its original $ID$ to join the network and obtains a corresponding $PID$:
  • The KGC selects the elliptic curve parameters $(E/{\mathbb{F}}_q,p,P)$ as described in the preliminaries.
  • It chooses two cryptographic hash functions, $H_1,H_2$.
  • The KGC randomly selects a master secret $x\leftarrow {\mathbb{Z}}_p$ and computes the system public key $P_0=xP$.
  • It sets the master secret key $msk=x$ and publishes the public parameters

    $$pp=(E/{\mathbb{F}}_q,p,P,P_0,H_1,H_2).$$
  • The UAV registers with the system using its real identity $ID$.
  • The KGC computes and assigns the pseudonym $PID=f_K\left(ID\right)\left|\right|t$ to the UAV, where t denotes the valid timestamp, $f_K$ is a secure one-way trapdoor function, and K is the trapdoor.
• OffKeyExt ($PID,pp,msk$)—for each authentication session or period, the KGC extracts the CS keys for verification and private keys for our authentication scheme:
  • The KGC selects a random number $y\leftarrow {\mathbb{Z}}_p$.
  • It computes the value $Y=yP$, which acts as the public verification component for CS.
  • It calculates $c_1=H_1\left(PID\right|\left|Y\right)$ and the secret value $s=y+c_{1}x$.
  • Let $sk=s$, and $s{k}_{cloud}=Y$, KGC then sends $sk$ and $s{k}_{cloud}\left|\right|PID$ to the UAV and CS respectively.
  • Refreshing y for the same $PID$, the KGC can generate multiple valid key pairs.
• KGC-SignPre ($pp$)—before the authentication message becomes available, KGC can executes the offline signing phase of the authentication signature, as it does not involve the use of the private key:
  • The KGC randomly chooses an ephemeral nonce r.
  • It computes the ephemeral public key $R=rP$.
  • The KGC repeats this process to generate a batch of precomputation $\Omega =\{(r_1,R_1),...,(r_N,R_N)\}$ and sends it to the corresponding UAV.
• CS-OffVer ($pp,PID,s{k}_{cloud}$)—before the verification and even the online signing phase, the CS executes partial verification computations to accelerate the online authentication process of GS:
  • The CS computes the hash $H_1\left(PID\right|\left|Y\right):=c_1$.
  • It then calculates the transition value $\omega =Y+c_1{P}_0$.
  • The CS sends $\omega \left|\right|PID$ to GS for the online verification. This value $\omega$ acts as a preverified aggregated public key for the specific UAV.
• UAV-OnSign ($m,\Omega ,t_i,PID,sk$)—once the authentication message m is ready, the UAV executes the online signing algorithm using the precomputed values and its private key $sk$:
  • The UAV randomly chooses a pair $(r_i,R_i)$ from the set $\Omega$.
  • For a current valid timestamp $t_i$, the UAV computes the signature component $z_i=r_i+c_{2}s$, where $c_2=H_2(R_i,m,PID,t_i)$.
  • The UAV outputs the signature $\sigma =(R_i,z_i)$ and sends it and $t_i$ to GS for a special of interval of time.
• GS-OnVer ($pp,PID,\omega ,m,\sigma$)—upon receiving the request, GS first checks the freshness of the signature, then verifies its validness if it is fresh:
  • The GS verifies whether $|t_i-t_{now}|\le \Delta T$, where $\Delta T$ is the maximum acceptable time delay, and $t_{now}$ is the arrival time of the signature. If $|t_i-t_{now}|>\Delta T$, the signature is expired, then the authentication request is rejected. Otherwise, GS executes the following verifying phase.
  • GS computes $c_2=H_2(R_i,m,PID,t_i)$.
  • GS accepts the authentication request if $z_{i}P=R_i+c_2\omega$. Otherwise, it rejects the request.

4.2. Discussion of the COAu-IoD Scheme

We now discuss our proposed authentication scheme COAu-IoD to analyze its advantages and limitations:

• Cloud and Offline Precomputation Collaboration: Our COAu-IoD scheme proposed above innovatively combines cloud-assisted computation with offline precomputation, shifting heavy cryptographic operations to the preprocessing phase before authentication messages are available. Complex computations are offloaded to the KGC and CS, while resource-constrained UAVs only execute lightweight online signing after the real-time message and timestamp arrive. This design greatly cuts down online computational overhead on UAV onboard devices, which is critical for power-limited UAVs.
• Online Communication Cost Optimization: This framework achieves favorable online communication efficiency. As our proposed scheme is a cloud- and offline-computing-assisted authentication framework, it provides lightweight communication between a UAV and GS by transferring heavy communication overhead to the offline phase. Therefore, compared with the standard schemes that execute all cryptographic operations in the online phase, our proposed scheme can achieve lower online communication cost.
• Balance Between Privacy and Accountability: Our proposed scheme also balances identity privacy and accountability. Pseudonym identities PID are adopted for regular UAV communication to hide real-world identities. Meanwhile, the trapdoor mechanism retained by the KGC supports traceback toward malicious UAVs when security incidents occur, which satisfies the regulatory requirement for auditing misbehaving drones.
• KGC Assumption Constraints: For the KGC’s trust assumption, we divide it into two situations. If KGC is only curious and attempts to exploit unauthorized partial precomputation values and public parameters in place of legitimate ones. That is to say, it acts as a malicious entity in our defined security model; our scheme is still secure by our following Theorem 1. If KGC is completed and compromised and can make any attacks within its capacities, it can issue legitimate certificates and fake warnings or messages with valid signatures. At this point, relying solely on all cryptography-based schemes is completely ineffective. In such a worst-case scenario within IoD, the defense mechanism must transcend cryptographic verification and evolve into a trust-oriented evaluation framework. UAVs assess the credibility of each message source based on physical layers, including neighboring UAVs’ cooperative observations, GS-assisted validation, and track anomaly detection. Based on this assessment, suspicious messages are quarantined, and a distributed consensus among multiple UAVs and GS is reached to revoke the compromised KGC’s identity. In short, from a purely cryptographic perspective, we have to assume that KGC cannot be completely captured. But in practical IoD, UAVs and GS make judgments and responses relying on the trust management system of the whole network besides cryptography.
• Mutual Authentication: Our current scheme only supports one-way authentication. Future research could extend COAu-IoD to support bidirectional mutual authentication within large-scale UAV clusters. In the current framework, only one-way authentication from UAVs to the GS is realized, while direct peer-to-peer verification among UAV nodes is not covered. Enabling pairwise bidirectional authentication would allow UAVs to authenticate each other during collaborative swarm missions. Additionally, it is necessary to adapt the framework to highly dynamic IoD scenarios where UAVs frequently join and leave the network. Dynamic pseudonym update mechanisms should be designed to refresh PID credentials for active UAVs. This helps resist long-term identity tracing attacks and maintains system security when swarm membership changes frequently.
• Fog or Edge Computing for Our Scheme: Fog or edge computing does outperform cloud in terms of transmission latency. However, the role of cloud is not used for real-time computation in our proposed framework, but for offline preverification. Cloud has powerful computing and storage resources and is responsible for heavy computation, while UAV only needs lightweight verification. Moreover, fog or edge nodes are physically vulnerable. UAVs operate in hostile environments where edge nodes can be easily compromised or jammed. If we deploy an online/real-time edge-based authentication framework, the edge server becomes a single point of failure and a prime target for man-in-the-middle attacks. In conclusion, fog or edge computing may further reduce the communication latency of the proposed scheme, but it will be slightly insufficient in terms of storage capacity and security protection.
• Application Scenarios: Our COAu-IoD authentication scheme is best suited for regulated, mission-oriented scenarios such as military surveillance and public security, where flight paths are predictable, UAV fleets remain relatively stable, and centralized identity tracing by the KGC is acceptable. In these contexts, the offline precomputation mechanism effectively reduces online authentication overhead. However, the present scheme is ill-suited for dynamic application scenarios like urban logistics or air taxi services, where frequent handovers and unpredictable trajectories are essential. This is because our current scheme needs to generate a large number of precomputed values. Moreover, the frequent updates of credentials have further reduced the efficiency gains brought about by offline precomputation, making our current scheme a solution specifically for a certain field rather than a universal IoD authentication solution.

4.3. Discussion of the Offline Precomputed Values

We now discuss the problems caused by the offline precomputed values generated in this proposed scheme:

• Distribution and Storage: The KGC produces precomputed intermediate values during the offline phase and delivers these values to authorized UAVs via GS within communication coverage. Each precomputed item is bound to its associated timestamp and pseudonym PID, guaranteeing consistency for subsequent authentication operations. Moreover, a hierarchical storage architecture is adopted: the PID mapping table and private key materials are safeguarded inside a hardware security module, while other precomputed data reside in ordinary flash memory maintained by either the KGC or CS. This design prevents excessive storage and delivery burdens from accumulating on one single central node.
• Freshness: The freshness of pre-computed items obeys PID pseudonym refresh policies, namely periodic fixed renewal and event-driven emergency refresh. Leveraging the offline precomputation design, the periodic refresh interval may be tuned to hundreds of seconds for various deployment scenarios. By contrast, emergency renewal events, including GS handover and security incidents, require a much shorter refresh interval. The refresh cycle might be relatively shorter.
• Reuse and Exhaustion: To prohibit unbounded reuse of precomputed values, our scheme adopts a PID replacement policy that compels UAVs to refresh pseudonyms periodically. Expired PIDs are normally revoked, unless traceability is invoked amid their valid term. Once malicious activity occurs, the KGC can retrieve the UAV’s true identity from relevant precomputed outputs for accountability. Each PID possesses a finite lifetime. Upon completing authentication with a UAV, the KGC produces and caches new PIDs to refill depleted resources and sustain continuous service operation.

4.4. Application

In this section, we briefly illustrate how the COAu-IoD scheme is applicable to practical scenarios with a UAV setting, such as forest-monitoring, which are characterized by limited onboard computation and unstable wild-area wireless connections. Prior to field missions, the trusted KGC completes heavy cryptographic workflows offline. It generates system parameters, pseudonym identities (PID), and split keys via the Initialization and OffKeyExt algorithms. Pre-computation procedures, including KGC-SignPre and CS-OffVer, are executed by the KGC and CS in advance so that computationally expensive operations are offloaded from resource-constrained UAVs.

In forest patrol scenarios, UAVs generate signatures for sensed monitoring data through the lightweight UAV-OnSign primitive with only minor online computational costs. The GS validates incoming data-signature pairs using GS-OnVer. Supported by pseudonym management, the scheme supports dynamic node join-and-leave events. If malicious behaviors occur, the KGC uses the trapdoor mechanism to retrieve the real identity of misbehaving UAVs for accountability. Assisted by cloud-side storage and partial offline verification, this scheme can maintain stable authentication even in systems with limited resources in forest environments.

In other practical use-case scenarios such as emergency rescue, a swarm of UAVs is deployed to collect environmental data and transmit video streams. Low-latency authentication is required to prevent spoofed UAVs from injecting false data. COAu-IoD provides conditional anonymity to protect UAV identity privacy, while the authority can trace malicious drones. The lightweight online authentication meets real-time transmission demands. Likewise, for urban low-altitude drone fleets, the cloud in our scheme continuously authenticates massive UAVs, which reduces the GS-side verification burden. Anonymity protects the operator’s privacy, and traceability is available for accident auditing.

5. Security Analysis

In this section, we first prove the security of our proposed authentication scheme according to our security model, then discuss its attack models and security requirements.

5.1. Security Proof

Theorem 1.

Our scheme satisfies EU-CMA security for every PPT adversary $\mathcal{A}$ described in the security model, assuming the hardness of the ECDLP in the random oracle model.

Proof. 

Suppose an adversary $\mathcal{A}$ is capable of tampering with legitimate partial precomputation results and public parameters, thereby compromising the proposed scheme within the given security model. We construct a simulator $\mathcal{B}$ that solves the ECDLP by interacting with $\mathcal{A}$. Given a discrete logarithm instance $(P,xP)$ defined over cyclic group $\mathbb{G}$. Here, P is the generator of group $\mathbb{G}$, and $x\in {\mathbb{Z}}_q$ is the unknown scalar that simulator $\mathcal{B}$ intends to recover, satisfying $Y=xP$. The simulator $\mathcal{B}$ acts as the controller of random oracles and executes the following interactive procedures with the adversary $\mathcal{A}$ to recover the solution x.

Setup. The simulator $\mathcal{B}$ is given an ECDLP instance $(P,X=xP)$ over the cyclic group $\mathbb{G}$ of prime order q, where $x\in {\mathbb{Z}}_q^{\ast }$ is the unknown scalar that $\mathcal{B}$ aims to recover. $\mathcal{B}$ randomly selects $P_0\in \mathbb{G}$, and chooses two cryptographic hash functions $H_1,H_2$ modeled as random oracles. $\mathcal{B}$ then sets the system public parameters as

$$pp=(E/{\mathbb{F}}_q,p,P,P_0,H_1,H_2)$$

and transmits $pp$ to $\mathcal{A}$.

$H_1$-Queries. The simulator $\mathcal{B}$ initializes an empty hash list $L_{H_1}$ to record all the hash queries and their corresponding responses. For a query on $\left(PI{D}_k\right|\left|y_{k}P\right)$ from $\mathcal{A}$ where $y_k\in {\mathbb{Z}}_q$, if $\left(PI{D}_k\right|\left|y_{k}P\right)$ is already recorded in the list $L_{H_1}$, $\mathcal{B}$ responds to it by recording $c_{1k}$ in $L_{H_1}$. Otherwise, $\mathcal{B}$ sets $c_{1k}=c_{1k}^{\prime }$ for $c_{1k}^{\prime }\leftarrow {\mathbb{Z}}_q$, then adds $\left(PI{D}_k\right||y_{k}P,c_{1k})$ to $L_{H_1}$, then transmits $c_{1k}$ to $\mathcal{A}$.

$H_2$-Queries. The simulator $\mathcal{B}$ initializes an empty hash list $L_{H_2}$ to record all the hash queries and the responses. For a query on $(r_{ik}P,m_k,PI{D}_k,t_{ik})$ from $\mathcal{A}$ where $r_k\in {\mathbb{Z}}_q$, if $(r_{ik}P,m_k,PI{D}_k,t_{ik})$ is already recorded in $L_{H_2}$, $\mathcal{B}$ responds to it by recording $c_{2k}$. Otherwise, $\mathcal{B}$ sets $c_{2k}=c_{2k}^{\prime }$ for $c_{2k}^{\prime }\leftarrow {\mathbb{Z}}_q$, then adds $(r_{ik}P,m_k,PI{D}_k,t_{ik},c_{2k})$ to $L_{H_2}$, then transmits $c_{2k}$ to $\mathcal{A}$.

Offline Preprocessing Queries. The simulator $\mathcal{B}$ initializes an empty list $L_{op}$ to record the queries and their responses. For an offline preprocessing query on $PI{D}_k$ from $\mathcal{A}$, if it is already recorded in $L_{op}$, $\mathcal{B}$ responds to it by $(r_k,r_{k}P)$ and ${\omega }_k$. Otherwise, $\mathcal{B}$ executes $H_1$-queries to obtain $\left(PI{D}_k\right||y_{k}P,c_{1k})$, and computes ${\omega }_k=s{k}_{cloud}+c_{1k}{P}_0$, then add $(PI{D}_k,r_k,r_{k}P,{\omega }_k)$ to $L_{pp}$ and transmits the response to $\mathcal{A}$.

Private Key Queries. The simulator $\mathcal{B}$ initializes an empty list $L_{sk}$ to record the queries and their responses. For a query on $PI{D}_k$, $\mathcal{B}$ aborts and restarts to a new query for $PI{D}_k=PI{D}_k^{\ast }$. For $PI{D}_k\ne PI{D}_k^{\ast }$, $\mathcal{B}$ returns the array $(s_k,y_{k}P)$ to $\mathcal{A}$ where $s_k,y_k\leftarrow {\mathbb{Z}}_q$, and add $(PI{D}_k,s_k,y_{k}P)$ to the list $L_{sk}$.

Partial Precomputation Replacement Queries. When $\mathcal{A}$ initiates a partial precomputation replacement query on $PI{D}_k$, $\mathcal{B}$ replaces the partial precomputation tuple $(PI{D}_k,R_k,{\omega }_k)$ with a new $(PI{D}_k,R_k^{\prime },{\omega }_k^{\prime })$.

Signing Queries. For each query on $(PI{D}_k,m_k)$ made by adversary $\mathcal{A}$ in the online signing, the simulator $\mathcal{B}$ returns the signature ${\sigma }_k=(R_k,z_k)$ by previous queries where $z_k=r_k+s_k{c}_{2k}$. Finally, it returns the signature to the adversary $\mathcal{A}$.

Forgery. In this game, the adversary $\mathcal{A}$ outputs a forged signature ${\sigma }^{\ast }$, where no query operations are performed for the target message $m^{\ast }$ and the corresponding private key $s{k}^{\ast }$. Based on the forking algorithm ${\mathcal{F}}_{PK}\left(\mathcal{A}\right)$ proposed in [32], we can obtain two valid signatures $(z_1,R)$ and $(z_2,R)$ satisfying the verification equations:

$$\left\{\begin{array}{c}{z}_{1}P=R+c_2\omega \hfill \\ z_{2}P=R+c_2^{\ast }\omega \hfill \end{array}\right.$$

where $c_2=H_2(R,m,PID,t_i)$ and $c_2^{\ast }=H_2^{\prime }(R,m,PID,t_i)$ are two distinct hash outputs returned by rewinding the random oracle, i.e., $c_2\ne c_2^{\ast }$. Subtract the two equations on group $\mathbb{G}$:

$$(z_1-z_2)P=(c_2-c_2^{\ast })\omega .$$

Recall that the precomputed term is set as $\omega =xP+c_1{P}_0$, where $Y=xP$ is the ECDLP challenge instance given to simulator $\mathcal{B}$. Substitute $\omega$ into above equation:

$$(z_1-z_2)P=(c_2-c_2^{\ast })\left(xP+c_1{P}_0\right).$$

That is to say,

$$(z_1-z_2)P=(c_2-c_2^{\ast })xP+(c_2-c_2^{\ast })c_1{P}_0.$$

Group-element equality implies scalar equality modulo q for coefficients of basis points $P,P_0$. Isolate the unknown ECDLP scalar x:

$$z_1-z_2\equiv (c_2-c_2^{\ast })·x\left(\mathrm{mod}q\right).$$

Since $c_2\ne c_2^{\ast }$, the term $(c_2-c_2^{\ast })$ is invertible modulo prime q. Compute modular inverse ${(c_2-c_2^{\ast })}^{-1}\in {\mathbb{Z}}_q$, then extract

$$x\leftarrow (z_1-z_2)·{(c_2-c_2^{\ast })}^{-1}\left(\mathrm{mod}q\right).$$

The simulator $\mathcal{B}$ outputs this computed x, which solves the given ECDLP challenge instance.

In summary, suppose a PPT adversary $\mathcal{A}$ is capable of breaking the security of our construction; then, an efficient solver for the ECDLP can be constructed. Consequently, our protocol achieves EU-CMA security under the ECDLP assumption. □

5.2. Attack Models

In this subsection, we will discuss that our scheme is also able to successfully resist the following attacks:

• Replay Attacks: In our scheme, the hash computation for each communication session is inherently bound to the unique random number generated for the current session. Specifically, each generated signature embeds a dedicated timestamp and a session-specific nonce. Even if an adversary intercepts a valid signature, the intercepted signature will be discarded immediately in the subsequent communication round, as the adversary cannot acquire the fresh random number for a new session. Moreover, the adversary defined in our formal security model is endowed with replay attack capabilities, and the proposed scheme is formally proven resilient against such adversarial behaviors. In addition to the theoretical analysis, we also carry out a simulation experiment to validate the replay-attack resistance in the revised manuscript. The simulation was conducted on a workstation equipped with a Qualcomm Snapdragon 778 G processor, 8.0 GB + 2.0 GB RAM, and the Android 12 operating system. During the simulation, one communication session generates a fresh nonce and timestamp, and the UAV outputs a valid message-signature pair. The adversary captures this pair and replays it in the subsequent new session with a distinct nonce and timestamp. We set the timestamp valid time window to 5 s and run 1000 independent replay-attack trials. Experimental results show that all replayed expired message-signature pairs are rejected in the verification phase, and no replayed signature can pass verification. The experimental observation is consistent with our theoretical analysis, which provides practical evidence that our scheme can defend against replay attacks.
• Precomputation Reuse Attacks: The precomputation refresh mechanism is tied to the pseudonym PID replacement policy, under which UAVs are obligated to renew their PIDs periodically. Once a PID expires, both the pseudonym and its associated precomputed materials will be revoked, except when the traceability function is activated within its valid lifecycle. In addition, precomputed items carrying invalid timestamps will be rejected by the system.
• Sybil Attacks: In our proposed scheme, any adversarial entity or untrusted curious KGC is prohibited from generating fake identities via illegal precomputed data. As formally verified by the established security model, the proposed scheme can effectively defend against Sybil attacks launched by such adversaries. Benefiting from the hardness of the ECDLP, our protocol possesses inherent resistance to Sybil impersonation threats in drone network authentication scenarios.

5.3. Security Objectives Analysis

We now discuss the security objectives of our offline and cloud-assisted authentication scheme:

• Authentication: It fundamentally relies on the security proof of the above Theorem 1. With a tight security reduction to ECDLP, we prove that impersonating a legitimate UAV is computationally infeasible. In particular, an adversary who does not possess the legitimate secret signing key cannot forge a valid message-signature pair with non-negligible probability. In practical deployment, GS nodes are physically safeguarded and stationary, making direct compromise extremely hard. Since GS authentication follows the same cryptographic logic as UAV authentication, preventing unauthenticated drones from passing verification is sufficient to protect the authentication process in this scheme.
• Anonymity: In our proposed scheme, authentication is conducted using a generated $PID$ rather than the original real identity. $PID$ is indistinguishable across different communication sessions and discloses no valid identity information of the UAV. Since adversaries cannot recover the original identity from such pseudonyms, they are unable to link a UAV to its historical activities. Furthermore, any identity inquiry received by a UAV will be directly rejected, as only KGC is authorized to initiate legitimate identity queries. Consequently, neither external adversaries nor GS can compromise the UAV’s identity privacy under our scheme. For illustration, suppose a UAV transmits telemetry message $m_1$ at time $T_1$ under pseudo-identity $PI{D}_1$ and corresponding private key $s{k}_{PI{D}_1}$. When the same physical UAV later receives navigation instruction $m_2$ at time $T_2$, it has already switched to an unrelated pseudo-identity $PI{D}_2$ with key $s{k}_{PI{D}_2}$. From the perspective of a passive eavesdropper, these two sessions appear to involve completely distinct devices, rendering session linkage computationally impossible. According to the security model of conditional anonymity, only pseudonym $PID$ rather than real identity $ID$ is exposed in signature and communication payloads. The real identity $ID$ is only bounded inside KGC via the trapdoor mechanism. Without master secret $msk$, the adversary cannot invert $PID$ to retrieve $ID$. The distribution of challenge signature is statistically indistinguishable for $b=0$ and $b=1$, yielding negligible anonymity advantage. That is to say, for all PPT adversaries $\mathcal{A}$, ${\mathsf{Adv}}_{\mathcal{A}}^{\mathsf{Anon}}\left(\lambda \right)$ is negligible.
• Traceability: Suppose a UAV disseminates malicious messages throughout COAu-IoD. When GS verifies these messages, it submits a report to KGC within its communication range. KGC then looks up the corresponding $PID$ of this UAV in its local database. If the $PID$ is registered, KGC leverages the secret key to retrieve the real identity of the malicious UAV. Afterwards, it revokes the UAV’s registration and broadcasts the revocation information to the entire IoD. Therefore, the proposed scheme achieves traceability for UAV communications. According to the security of conditional traceability, each pseudonym $PID$ is deterministically bound to one real UAV identity $ID$ in the initialization phase. A valid signature passing verification must carry a system-valid $PID$. If an adversary produces a valid signature whose $PID$ cannot be recovered to $ID$, it implies breaking the underlying trapdoor primitive. That is ti say, for every PPT adversary $\mathcal{A}$, ${\mathsf{Adv}}_{\mathcal{A}}^{\mathsf{Trace}}\left(\lambda \right)$ is negligible. Thus traceability holds under the trapdoor security assumption.

6. Performance Analysis

This section presents a comprehensive performance comparison with the standard authentication model and five recent state-of-the-art IoD/UAV authentication schemes. The experiment environment is shown in the following

Table 2. The simulation environment.

Category	Configuration
Hardware platform	device: Qualcomm Snapdragon 778 G
	Memory: 8.0 GB + 2.0 GB RAM
	System: Android 12
Software environment	Programming language: Java
	Cryptographic library: JPBC library-2.0.0
Cryptographic setup	Security level: Uniform 128-bit security
	Elliptic curve: $y^2=x^3+x$
Statistical experimental settings	Repeats per primitive operation: 10 times
	Iterations per run: 100 iterations
	Reported metric: Mean value with $95\%$ confidence interval

. For comparisons with other schemes, each operation is executed 10 times with distinct random seeds to mitigate random-measurement bias, and the averaged results are adopted for comparative analysis. Each trial runs for 100 iterations in total. For all quantitative metrics, we report the mean alongside the corresponding 95% confidence interval to guarantee experimental reliability.

6.1. Communication Cost

We first discuss the communication cost between the standard model and our proposed model. In order to analyze the real-time characteristics of the IoD system, we divided the entire process into offline communication before the authentication message is available and online communication. The communication cost of our scheme is shown in Figure 3 of Section 4. According to the hypotheses of 64 bytes of $|{\mathbb{Z}}_q|$ for elements in ring ${\mathbb{Z}}_q$, 16 bytes of $\left|T\right|$ for time-stamps, and 32 bytes of $\left|S\right|$ for random bit strings, 32 bytes of AES block and PUF, the communication overheads between the standard approach and our approach are summarized in

Table 3. Theoretical communication analyses of the standard model and our COAu-IoD model.

Items	Standard Model	COAu-IoD Model
Offline comm. cost	$2\left|S\right|+|{\mathbb{Z}}_q|$	$5\left|S\right|+4|{\mathbb{Z}}_q|$
Online comm. cost	$2\left|S\right|+4|{\mathbb{Z}}_q|+\left|T\right|$	$\left|S\right|+2|{\mathbb{Z}}_q|+\left|T\right|$
Total cost	$4\left|S\right|+5|{\mathbb{Z}}_q|+\left|T\right|$	$6\left|S\right|+6|{\mathbb{Z}}_q|+\left|T\right|$

and Figure 4.

The results show that the offline and total communication costs of our approach are larger than those of the standard approach. However, our approach has shorter online communication cost than the standard approach, as KGC and CS in our model perform partial authentication process in offline precomputation phase.

6.2. Computation Cost

We then analyze the computation costs of the standard IoD authentication model and the proposed offline computing-assisted IoD authentication model. We use $T_h$, $T_a$, $T_r$, $T_m$, $T_p$, $T_f$, $T_e$ to represent the computational overhead that is required for carrying out one-time hashing, addition, random string sampling, multiplication, PUF operation, biometric key generation, and symmetric encryption and decryption. The comparisons of these theoretical computational cost analyses are shown in

Table 4. Theoretical analyses of the computation cost for the standard and our COAu-IoD model.

Items	Standard IoD	COAu-IoD
KGC precomp.	$T_r+2T_m+T_a+2T_h$	$2T_r+3T_m+T_a+2T_h$
CS offline pre-ver.	0	$T_m+T_a+T_h$
UAV online signing.	$2T_r+2T_m+T_a+T_h$	$T_r+T_m+T_a+T_h$
GS online ver.	$3T_m+2T_a+2T_h$	$2T_m+T_a+T_h$
Total online auth.	$2T_r+5T_m+3T_a+3T_h$	$T_r+3T_m+2T_a+2T_h$

, and the corresponding experimental results of the computational costs are given in Figure 5. In addition, we also analyze the computation costs for different devices of each session in these two models in Figure 6.

According to the theoretical and experimental analyses, the online authentication time of our scheme is shorter than that of the standard scheme. What is more, the devices with limited resources in our scheme, such as UAV and GS, have shorter computation time in each session. As our proposed COAu-IoD scheme introduces extra offline computation steps for the KGC and CS, this architectural design is highly intentional. This offline time is safely executed during idle periods before the genuine initiation of the time-critical flight authentication. Therefore, it will not exert any negative impact on the real-time UAV interactions.

6.3. Comparison with Other Schemes

Besides the standard model, we also make comparisons with five recent state-of-the-art IoD/UAV authentication schemes [33,34,35,36,37].

Table 5. Security and functional features comparisons.

Feature	[33]	[34]	[35]	[36]	[37]	Ours
UAV/IoD	UAV	UAV	UAV	UAV	IoD	IoD
IBC	YES	NO	NO	NO	NO	YES
Offline	NO	NO	NO	NO	YES	YES
Cloud/Edge	NO	NO	NO	NO	NO	Cloud
Mutual	YES	YES	YES	YES	YES	NO
Anonymity	YES	NO	YES	YES	YES	YES
Traceability	YES	NO	NO	NO	NO	YES
Replay attack	YES	YES	NO	YES	YES	YES
Batch Verification	NO	NO	NO	YES	NO	NO

describes the security and functional feature comparisons among the schemes. The result shows that in addition to mutual authentication and batch verification, our proposed COAu-IoD scheme meets all the other features.

We then make comparisons for offline precomputation, GS/verification cost, UAV cost, etc. with recent lightweight authentication schemes [33,34,35,36,37]. Theoretical computation cost and experimental result comparisons are presented in

Table 6. Theoretical computation cost comparisons.

Scheme	Precomputation Cost	GS/Verification Cost	UAV Cost	Total
[33]	$14T_h+3T_m$	−	$12T_h+3T_m$	$26T_h+6T_m$
[34]	$5T_h+4T_m+2T_a+T_p$	−	$5T_h+8T_m+4T_a+2T_p$	$10T_h+4T_m+2T_a+T_p$
[35]	$10T_h+2T_f$	−	$10T_h+2T_f+2T_p$	$20T_h+4T_f+2T_p$
[36]	$T_h+2T_e$	−	$14T_h+16T_m+4T_a+2T_p+2T_e$	$T_h+4T_e+2T_p$
[37]	$7T_h+5T_e+2T_f+T_p$	$3T_h+4T_e+T_f+T_p$	$5T_h+3T_e+T_f+T_p$	$15T_h+12T_e+4T_f+3T_p$
Ours	$3T_h+2T_a+4T_m+2T_r$	$T_h+T_a+2T_m$	$T_h+T_a+T_m+T_r$	$5T_h+4T_a+7T_m+3T_r$

and Figure 7, respectively. The comparison demonstrates that COAu-IoD achieves lower online computation and communication costs for UAVs benefiting from the precomputation and distributed computing mechanism, at the cost of higher but acceptable offline precomputation overhead.

In addition, we also compare with these schemes in terms of the communication cost in the authentication process based on the hypotheses in Section 6.1, which is shown in Figure 8. The result shows that our scheme has relatively low communication overhead due to the precomputation mechanism.

Therefore, for real-time applicability analysis in IoD scenarios, real-time authentication requires the total authentication delay to satisfy strict deadlines, typically within tens of milliseconds. According to our experiment, the online processing latency of COAu-IoD is about 4 ms for UAVs. Adding the wireless transmission delay, such as 5–20 ms in short-range aerial communication, the total end-to-end authentication latency is still less than tens of milliseconds, which satisfies the real-time deadline requirement for most IoD applications.

7. Conclusions

We present COAu-IoD, a new paradigm for efficient IoD authentication frameworks. By incorporating offline precomputation and cloud computing resources, the proposed scheme significantly improves authentication efficiency. Specifically, offline precomputation alleviates the computational burden on low-power IoD devices via local caching, while the cloud server precomputes and stores partial cached values to further optimize overall performance. Both theoretical analysis and experimental results demonstrate that our authentication scheme achieves UAV-side lightweight online computation and communication overhead, at the cost of increased but acceptable offline system overhead. In addition, the increased offline overhead optimization may be our future research direction. In future work, we will also discuss the IoD authentication scheme that supports batch verification via some particular signature algorithms [38,39], which is highly suitable for multiple authentication requests from some UAVs in a brief period.