A Lightweight and Dynamic Authentication Scheme Based on Blockchain and aSVC for UAV Swarm

Abstract

The rapid development of Unmanned Aerial Vehicle (UAV) swarm technology has led to its increasingly vital role in intelligent transportation, environmental monitoring, and emergency response. However, existing centralized identity authentication mechanisms are susceptible to single points of failure and identity forgery in dynamic environments. While blockchain technology offers a distributed trust architecture, its inherent high storage and computational overhead pose significant challenges for resource-constrained UAV networks. To mitigate these challenges, this paper introduces a novel lightweight and dynamic identity authentication scheme that integrates blockchain with aggregatable subvector commitments (aSVC). This proposed scheme employs aSVC to effectively compress identity states, complemented by efficient batch authentication and asynchronous update mechanisms. Consequently, this approach reduces on-chain storage overhead to a constant level and achieves a statistically significant optimization of the computational complexity for batch authentication, transforming key cryptographic operations from linear dependence on the number of UAVs to a constant level.

1. Introduction

In recent years, rapid advancements in unmanned system technology have positioned UAVs, with their flexible deployment and excellent environmental adaptability, as crucial infrastructure in aerospace information networks [1,2,3]. Particularly in fields such as intelligent transportation, environmental monitoring, emergency response, and logistics delivery, collaborative operation models represented by UAV swarms are progressively transforming traditional operational paradigms [4]. UAV swarms, through heterogeneous networking, can accomplish tasks such as large-scale data collection, complex area inspection, and rapid response rescue, significantly enhancing operational efficiency and coverage [5,6]. However, the widespread application of UAV swarms also introduces new security challenges and technical bottlenecks: on the one hand, open communication links are vulnerable to electromagnetic interference and network attacks, and node identities can be easily forged [7]; on the other hand, frequent changes in dynamic topological structures increase collaborative authentication delays and energy consumption [8]. Furthermore, UAV nodes have limited resources, while traditional blockchain’s storage requirements are extremely high, a contradiction that further restricts the practical implementation of blockchain technology [9]. The aforementioned issues can lead to the proliferation of Byzantine nodes within the UAV swarm network, potentially causing task decision failures or even the collapse of the entire system. Therefore, designing a lightweight, resilient, and distributed identity authentication and trust system becomes a critical prerequisite for achieving reliable collaboration within UAV swarms.

UAV swarms typically adopt a self-organizing network form, completing collaborative decisions and data sharing through inter-node cooperation [10,11]. In this process, the issue of identity authentication between nodes is paramount, as it directly impacts the security and reliability of data transmission. Traditional identity authentication schemes primarily rely on Public Key Infrastructure (PKI) technology [12]. PKI schemes usually issue digital certificates containing unique identifiers and public keys through a centralized Certificate Authority (CA) and rely on periodic updates to maintain communication privileges [13]. Although the PKI architecture performs well in static networks, it still has significant shortcomings in UAV swarm environments: firstly, the CA, as a centralized trust source, is vulnerable to Distributed Denial of Service (DDoS) attacks or insider attacks, which can lead to the paralysis of the entire identity authentication system [14]; secondly, to meet the demand for anonymous communication, UAVs must pre-store a large amount of certificate information, resulting in substantial storage overhead; finally, in dynamic topological environments, frequent issuance, updating, and revocation of certificates lead to a surge in management complexity and are prone to node state conflicts and synchronization delays.

Blockchain technology, as an emerging distributed ledger technology, offers a new solution for identity authentication in UAV networks due to its decentralization, immutability, and traceability [15]. However, directly integrating traditional blockchain technology into UAV networks still confronts two fundamental bottlenecks:

• Storage Constraint: A full node in a blockchain must synchronize and store the complete ledger, which far exceeds the typical storage capacity of UAV nodes, forcing light node modes to sacrifice verification capabilities to accommodate hardware limitations.
• Computational Real-time Bottleneck: Every transaction in a blockchain must be verified prior to being packed into a new block, which can induce delays in the authentication process.

To address these challenges, academia has begun exploring stateless clients or state compression techniques. The core idea is to compress the global state of the entire system (e.g., a list of all UAVs’ public keys) into a concise commitment value and record it on-chain, thereby offloading resource-constrained devices. This can be achieved through RSA accumulators [16] or generic vector commitments [17,18]. However, in the highly dynamic and concurrent specific scenarios characteristic of UAV swarms, these schemes still possess limitations. For instance, when a member’s state is updated, RSA accumulators require recalculating proofs for all other nodes, thereby incurring significant overhead; furthermore, some generic vector commitment schemes do not offer optimal computational overhead or communication burden for other nodes to update their identity proofs when one node’s state changes.

For this purpose, this paper introduces aggregatable subvector commitments (aSVC) [19]. aSVC can compress large-scale identity vectors into a fixed-size on-chain commitment value, achieving constant-level storage overhead and significantly reducing the blockchain burden. Additionally, when a node’s state is updated, all other nodes can independently update their own proofs locally in constant time (O(1)), greatly improving dynamic management efficiency.

Based on aSVC’s unique advantages, this paper proposes a lightweight, dynamic identity authentication scheme integrated with blockchain. This scheme not only achieves constant-level on-chain storage compression but also effectively mitigates authentication delays and synchronization overhead in highly dynamic environments through its efficient batch authentication and asynchronous update mechanisms. Simultaneously, it encompasses full lifecycle management for members, including key updates and UAV entry/exit from the network. While the aSVC technology and its O(1) proof update property have been proposed in other domains, such as for stateless cryptocurrencies, to the best of our knowledge, this paper is the first to apply it to solve the dynamic identity authentication challenges in UAV swarms. Our main contribution lies in constructing a complete “Cloud-Edge-Device” collaborative framework and designing efficient batch authentication and asynchronous update mechanisms, thereby filling the gap in existing schemes regarding dynamic management efficiency and lightweight performance. The main contributions of this paper are as follows:

• Proposing a Lightweight Dynamic Authentication Framework: Addressing the high dynamism and resource-constrained characteristics of UAV swarms, we propose a lightweight dynamic identity authentication framework based on blockchain and aggregatable subvector commitments (aSVC). This framework compresses the swarm’s identity state into a single on-chain commitment value, achieving constant-level on-chain storage overhead, effectively solving the bottleneck problem of traditional blockchain’s high storage demands hindering its application in resource-constrained UAV devices.
• Designing an Efficient and Secure Authentication and Dynamic Management Mechanism: Leveraging the aggregation and O(1) update properties of aSVC, we design a set of efficient batch authentication protocols and a flexible dynamic member management mechanism. This mechanism supports efficient batch authentication for a large number of swarm members. Furthermore, when UAVs join, leave, or update keys, on-chain state updates and local proof synchronization for all UAVs can be achieved with only constant time (O(1)) computation, greatly enhancing the system’s scalability and real-time response capability in highly dynamic environments. Concurrently, this mechanism, combining blockchain characteristics and cryptographic primitives, ensures its decentralization and attack resilience at the design level.
• Comprehensive Validation of Scheme Performance and Security: Through rigorous theoretical analysis and comprehensive experimental evaluation backed by formal statistical testing, we demonstrate that the proposed scheme achieves statistically significant improvements over existing mainstream schemes in terms of computational overhead, and authentication latency. This rigorously substantiates its lightweight nature, efficiency, and robustness in practical UAV swarm applications. Additionally, the security analysis elaborates on how this scheme effectively defends against various common threats such as identity forgery, replay attacks, and Sybil attacks, thereby validating the security and resilience of the designed mechanism.

The remainder of this paper is organized as follows: Section 2 reviews related research on UAV swarm identity authentication and the technical background of aSVC; Section 3 defines the system model and security assumptions; Section 4 details the design process and core modules of the proposed authentication scheme; Section 5 analyzes the scheme’s security from multiple dimensions; Section 6 presents the experimental setup based on NS-3 and comparative evaluation results; and Section 7 concludes the paper.

2. Related Work

This section reviews the evolution of existing authentication schemes and critically analyzes their applicability and limitations within the highly dynamic and resource-constrained environment of UAV swarms.

Early UAV identity authentication schemes predominantly relied on centralized architectures, with Public Key Infrastructure (PKI) being the archetypal example. Raya and Hubaux [20] first introduced PKI into ad hoc networks, achieving node anonymity by pre-loading a large number of key pairs. However, the resulting certificate revocation mechanism required periodic broadcasting of Certificate Revocation Lists (CRLs), leading to a rapid increase in storage overhead as the swarm size grew. Furthermore, the centralized CA node in PKI schemes is inherently susceptible to single points of failure, which severely constrains their applicability in highly dynamic and adversarial environments.

To overcome the centralization drawbacks of PKI schemes, some research has initiated the exploration of decentralized or lightweight methods grounded in traditional cryptography. For example, group signature methods [21,22,23] achieve anonymous identity authentication for members through keys issued by a group manager, which to some extent alleviates node storage pressure. However, when members are revoked, global parameters need to be reconstructed, leading to significant computational and communication burdens. Physical Unclonable Functions (PUFs) [24] utilize the unique physical fingerprints of node hardware for identity authentication, but this method has poor adaptability to key synchronization in dynamic topological networks. To avoid centralized dependency, researchers have also turned to certificateless architectures. Cui et al. [25] proposed a lightweight key agreement scheme based on elliptic curve cryptography, effectively reducing computational overhead; Ming et al. [26] designed a Certificateless Conditional Privacy-Preserving Authentication (CPPA) protocol, further reducing node load by replacing bilinear pairings with hash operations; Xu et al. [27] developed an efficient batch authentication scheme using the Chinese Remainder Theorem, compressing single authentication time to sub-millisecond levels. Nevertheless, while these certificateless methods alleviate the limitations of centralized architectures, in highly dynamic UAV networks, frequent node entry and exit that lead to identity changes still impose significant computational burden and real-time bottlenecks.

In recent years, blockchain technology, with its characteristics of decentralization, data immutability, and traceability, has offered a novel approach to solving identity authentication problems in UAV networks. Toorani et al. [28] first proposed using blockchain to enhance the PKI system, effectively mitigating the single-point-of-failure problem of traditional PKI. However, directly implementing traditional blockchain technology in resource-constrained UAV networks still confronts challenges such as excessive on-chain storage burden and inadequate computational real-time performance, thereby limiting its practical deployment in large-scale, highly dynamic swarms. For instance, Li et al. [29] proposed a CreditCoin protocol based on threshold ring signatures, which, while enhancing anonymity and privacy protection, remained constrained by the ring size and threshold parameters, and did not fundamentally resolve the storage burden issue.

To address the storage and computational challenges of blockchain, academia has begun to explore state compression or stateless client technologies. The core idea of these technologies is to compress the entire system’s global state (e.g., a list of all UAV public keys) into a concise commitment value and record it on-chain, thereby offloading resource-constrained devices. For example, this goal can be achieved through RSA accumulators [30] or generic vector commitments [31,32]. Nevertheless, in the specific scenarios characterized by frequent dynamic entry/exit and high concurrency in UAVs, these solutions still possess considerable limitations. For instance, when a member’s state is updated, RSA accumulators require recomputing proofs for all other nodes, leading to huge computational overhead. Moreover, some generic vector commitment schemes do not offer optimal computational overhead or communication burden for other nodes to update their identity proofs when a single node’s state changes. Additionally, dynamic accumulator technology has also been used to achieve batch certificate updates. The literature [33] utilized dynamic accumulators to build an efficient certificate update model, but in scenarios with frequent transactions and drastic network topology changes, on-chain transaction delays and computational communication overhead still struggled to meet real-time requirements. Kong et al. [34] proposed a stateless blockchain scheme based on triple subvector commitments, which initially achieved dynamic authentication by separately managing normal, revoked, and malicious nodes. However, its two-stage network model and multi-commitment management mechanism exhibit limited adaptability in complex cloud-edge collaboration scenarios and do not fully exploit the performance potential of such commitment technologies in batch authentication.

In conclusion, after reviewing authentication schemes based on PKI, traditional blockchain, and generic vector commitments, it is evident that existing methods generally face comprehensive challenges such as high storage overhead, low dynamic management efficiency, and high update costs when applied to large-scale, highly dynamic UAV swarm scenarios. To illustrate these differences more systematically and intuitively,

Table 1. Performance comparison of different authentication paradigms.

Feature	PKI-Based Scheme	Naive Blockchain Scheme	EDRAX (VC)	Proposed Scheme
Trust Model	Centralized CA	Decentralized	Decentralized	Decentralized
On-chain Storage	N/A (CRL on-chain)	Linear (Full state)	Constant (Commitment)	Constant (Commitment)
Client-side Storage	High (Numerous certificates)	Very High (Full chain data)	Low (Local proofs)	Very Low (Single proof + update key)
Proof Update Overhead	N/A (Revocation mechanism)	N/A	Logarithmic/Linear	O(1) Constant time
Batch Authentication Efficiency	Linear	Linear	Linear	Sub-linear (Aggregated verification)
Dynamic Membership Management	High overhead	High overhead	Medium overhead	Very low overhead

summarizes and compares the key characteristics of these mainstream technical paradigms. This table reveals the limitations of existing schemes and highlights the significant advantages of the proposed scheme in achieving lightweight and efficient dynamic management.

Addressing the limitations of the aforementioned schemes in terms of on-chain storage efficiency, dynamic update efficiency, and proof update overhead, Aggregatable Subvector Commitments (aSVC) technology offers a new solution. aSVC can commit large-scale identity vectors into a fixed-size digest value. Regardless of the swarm size, only this constant-size commitment value needs to be stored on-chain, achieving constant-level on-chain storage compression. More importantly, its core advantage lies in the fact that when any node’s state is updated, all other nodes can independently update their own identity proofs locally in constant time (O(1)). This significantly reduces the frequent proof reconstruction and communication overhead typically required by traditional schemes in dynamic environments. These characteristics endow aSVC with a significant advantage in handling identity management for highly dynamic, large-scale UAV swarms.

In summary, despite active exploration in identity authentication for UAV swarms, existing proposed schemes still face comprehensive challenges in achieving truly decentralized trust management, efficiently adapting to highly dynamic network environments, and performing efficient authentication under node resource constraints. Specifically, the capability to achieve constant-level lightweight on-chain storage while ensuring the computational efficiency of dynamic member management and batch authentication, along with integrating an asynchronous update mechanism, has emerged as a significant research gap and an urgent necessity. The lightweight dynamic authentication scheme proposed in this paper, based on blockchain and aggregatable subvector commitments (aSVC), precisely aims to address this gap, thereby advancing the identity authentication system for UAV swarms toward a more secure, efficient, and scalable paradigm.

3. System Model and Security Assumptions

3.1. Model Design

The proposed authentication system employs a “Cloud-Edge-Device” collaborative architecture, as depicted in Figure 1. This architecture seamlessly integrates blockchain and aggregatable subvector commitment (aSVC) technology to provide a decentralized, lightweight, and dynamically manageable identity authentication and trusted management system for UAV swarms. The system consists of four core entities: cloud server, edge servers, UAV nodes, and the blockchain network, with their responsibilities defined as follows:

• Cloud Server: Trusted Setup Center

The cloud server functions as the trusted root of the entire system, executing a one-time Trusted Setup. It is responsible for running the aSVC’s key generation algorithm to create global public parameters. This includes: a proving key $prk$, a verification key $vrk$ (securely distributed to all edge servers for proof verification); and update keys $upk$ (a unique update key$up{k}_i$ is generated for each possible UAV identity slot $i$ in the system and securely distributed to the corresponding UAV). After completing initialization, the core mission of the cloud server is accomplished, ensuring the singularity and security of the system’s key source.

Notably, the role of the initialization cloud server could also be fulfilled by a high-trust UAV in specific scenarios. This model offers significant deployment flexibility in environments that lack ground infrastructure (e.g., during emergency response), though it also imposes stricter requirements on the designated UAV in terms of physical security and computational resources. The proposed scheme’s architecture is compatible with such a deployment model, thereby enhancing its applicability in diverse scenarios.

• Edge Servers: Efficient Authentication and State Consensus Nodes

Edge servers are central to local authentication and blockchain consensus. Their dual roles are specifically manifested as: Efficient Batch Authentication (acting as an authentication gateway, leveraging aSVC’s advantages to aggregate and batch verify proofs, improving authentication efficiency), and State Update and Consensus (acting as full nodes of the blockchain, they are responsible for processing UAV registration, revocation, or state change requests, updating the global commitment, and broadcasting it to the entire blockchain network via a consensus mechanism). In this manner, the blockchain not only anchors the latest global commitment $C_t$ but also preserves the entire historical sequence of commitments since the genesis block. This ensures that the complete evolution of the system’s state is not erased but is permanently recorded and available for auditing. Any request to verify a historical state can be fulfilled by querying the corresponding commitment value from a past block.

• UAV Nodes: Lightweight Stateless Terminals

UAVs, as terminal devices of the system, are designed as “stateless clients,” achieving extreme lightweight operation. They do not need to store the complete system state or ledger data locally, only securely storing their own update key ($up{k}_i$) and current identity proof (${\pi }_i$). This client-side statelessness is distinct from the blockchain network itself, which maintains the full, immutable history of all state commitments. When there is a state update on the blockchain, the UAV only needs to monitor the broadcast update information Tx to compute its new proof ${\pi }_{i+1}$ locally in constant time, achieving stateless synchronization and avoiding frequent communication with the server and high computational overhead.

• Blockchain Network: Distributed Trust Anchor

Maintained jointly by all edge servers, the blockchain network serves as the system’s distributed trust anchor and trusted bulletin board. It does not store sensitive raw data but immutably records the historical sequence of the global commitment digest $C_t$, containing all necessary public information for local proof updates. Through its chained structure, the blockchain ensures that all identity management changes are public, transparent, and traceable, providing a solid foundation for the dynamic, trusted, and secure operation of the entire system.

The four types of entities cooperate: the cloud performs one-time trusted setup; edge servers enable efficient batch authentication and state consensus; terminal UAVs achieve stateless synchronization through local computation; and the blockchain solidifies state history as a trust anchor. These entities collectively construct a robust, efficient, and scalable dynamic authentication system for UAV swarms. Its overall workflow covers the complete lifecycle from cloud initialization of system parameters, UAV registration, single or batch identity authentication via edge servers, to dynamic management of member states. Figure 2 details the overall workflow of this scheme and the temporal interactions between entities. For the convenience of introducing subsequent methods,

Table 2. The symbol definitions.

Symbol	Definition
G, GT	Cyclic groups of prime order q.
e	A bilinear pairing e: $G\times G\to G_T$.
P	A generator of the group G.
$V$	The vector containing the identity states of all UAVs.
vi	The i-th element of vector $v$, representing the state of $UA{V}_i$.
C	The aSVC commitment to vector $v$.
${\pi }_i$	The aSVC proof that $v_i$ is the i-th element of vector $v$.
$prk$	The proving key for aSVC.
$vrk$	The verification key for aSVC.
$up{k}_i$	The aSVC update key bound to position i, containing $a_i$ and $u_i$.
$\delta$	The delta or change in the state value.
$UI{D}_i$	The unique identifier of $UA{V}_i$.
$P{K}_i, S{K}_i$	The public/private key pair of $UA{V}_i$.

lists the key symbols and their definitions.

3.2. Threat Types

In the dynamic operating environment of UAV swarms, this scheme faces various potential security threats. We assume the existence of a Probabilistic Polynomial Time (PPT) adversary A, whose goal is to disrupt the normal operation of the UAV swarm, for example, through identity forgery, message replay, or denial of service. Specifically, the adversary may possess the following capabilities:

• Eavesdropping: The adversary can eavesdrop on communication channels between UAVs and edge servers, and between UAVs themselves.
• Message Injection and Tampering: The adversary can inject forged messages into the network or tamper with legitimate messages.
• Replay Attack: The adversary can intercept and replay previously valid communication messages.
• Sybil Attack: The adversary may attempt to control or influence swarm decisions by creating a large number of false identities.
• Denial of Service (DoS) Attack: The adversary may attempt to render edge servers or some UAVs unable to provide services by sending a large number of invalid requests or consuming critical resources.
• Malicious UAVs: There may be captured or inherently malicious UAVs within the swarm that might send false data or disobey protocols.
• Physical Dimension Threats: Beyond digital vulnerabilities, this scheme must address the distinct physical threats inherent to UAV swarms. A malicious UAV, despite being digitally revoked from the blockchain, remains physically present in the operational airspace. This persistence enables it to launch kinetic attacks (e.g., collisions), conduct localized electronic warfare, or perform passive surveillance. Unlike in purely digital systems where expulsion neutralizes a node, a revoked UAV persists as a direct physical threat that necessitates dedicated countermeasures.

3.3. Security Assumptions

The overall security of this scheme is based on the following multi-layered assumptions:

• Cryptographic Foundations
  • Underlying Cryptographic Scheme: It is assumed that the adopted aSVC scheme satisfies its stated security properties, namely Position Binding and Update Key Uniqueness. Simultaneously, the standard cryptographic primitives used in the scheme (e.g., ECDSA digital signatures, SHA-256 hash function) are secure under the standard model.
• System and Trust Model Assumptions
  • Trusted Setup and Decentralized Operation: It is assumed that during the one-time initial setup phase, a trusted cloud server correctly generates and distributes system parameters. Thereafter, the cloud server can go offline and does not participate in subsequent operations. The system’s security then relies on the consensus mechanism of the underlying permissioned blockchain. It is assumed that the majority of ledger nodes (e.g., more than 2/3 in PBFT consensus) are honest and can resist consensus attacks from a minority of malicious nodes, ensuring the consistency and immutability of the final data. Furthermore, the single point of trust of the cloud server can be eliminated by distributing the generation of system parameters among multiple participants using a Multi-Party Computation (MPC) protocol; this scheme is compatible with such decentralized setups.
• Endpoint and Environment Assumptions
  • Terminal Key Security: It is assumed that each UAV can securely store its signing private key $S{K}_i$ and update key $up{k}_i$ in its hardware security module.
  • Basic Network Synchronization: It is assumed that UAVs can periodically synchronize with the blockchain network to obtain the latest global commitment $C_t$. In cases of intermittent disconnections, UAVs might use outdated proofs, but this can be mitigated by checking the timestamp of the commitment corresponding to the proof during verification, thereby rejecting requests based on outdated states.

4. Scheme Design

This section elaborates on the key mechanisms and protocols designed in this scheme, based on the “Cloud-Edge-Terminal” architecture and aSVC technology, covering the entire lifecycle of UAV swarm identity authentication, including UAV identity definition, system initialization, identity registration, authentication procedures, and dynamic identity management mechanisms.

4.1. UAV Identity Definition

In this scheme, the identity information and key attributes of each $UA{V}_i$ are encoded as a vector element $v_i$. The state of the entire UAV swarm (assuming a maximum capacity of $N_{max}$) can be represented as a vector $V=\left[v_0,v_1,\dots ,v_{N_{max}-1}\right]$ of length $N_{max}$. Specifically, $v_i$ contains the following information:

$$v_i=\left(UI{D}_i \left| P{K}_i \right| H\left(up{k}_i\right)\right)$$

• $UI{D}_i$: The UAV’s unique identifier, assigned by the edge server during registration.
• $P{K}_i$: The UAV’s traditional public key, used to verify digital signatures of messages it sends. The corresponding private key $S{K}_i$ is securely stored by the UAV.
• $H\left(up{k}_i\right)$: The hash value of the UAV’s aSVC update key $up{k}_i=\left(a_i,u_i\right)$.

These attributes collectively form the UAV’s state representation in the aSVC commitment vector. The edge server maintains this complete vector $V$ and computes a commitment $C$ for it.

4.2. System Initialization

System initialization involves a one-time trusted setup performed by the cloud server prior to system launch. This process establishes the cryptographic foundation, ensuring the security and verifiability of all subsequent operations, as detailed in Algorithm 1.

Algorithm 1: System initialization protocol

Input: Security parameter $\lambda$, maximum UAV capacity $n$

Output: Proving key $prk$ Verification key $vrk$, update key set ${\left(up{k}_i\right)}_{i=1}^n$ and Initial global commitment $C_0$ Process:

Cloud Server executes:

1. Generate public bilinear pairing parameters $params=\left(G_1,G_2,G_T,g,p,e\right)$.

2. Invoke aSVC key generation: $\left(prk,vrk,{\left(up{k}_i\right)}_{i=1}^n\right)\leftarrow VC.KeyGen\left(1^{\lambda },{\mathrm{n}}_{\mathrm{m}\mathrm{a}\mathrm{x}}\right)$.

3. Construct a zero vector $v_0=\left(\mathrm{0,0},\dots ,0\right)$ of dimension $\mathrm{n}$

4. Compute initial global commitment: $C_0\leftarrow VC.Commit\left(prk,v_0\right)$.

5. Write $C_0$ to the blockchain’s genesis block.

The system initialization phase is performed by the cloud server, acting as a trusted root, to establish a secure foundation for the UAV swarm authentication system. This process is completed only before the system goes online, avoiding continuous reliance on a centralized entity during runtime. It involves generating the aSVC’s proving key $prk$, verification key $vrk$, and update key $upk$. An initial zero-vector commitment $C_0$ is then anchored to the blockchain’s genesis block, ensuring the initial state’s public verifiability and immutability. Once this phase is complete, the system’s subsequent secure operation relies on the de centralized blockchain consensus mechanism and the cryptographic properties of aSVC.

4.3. Identity Registration

When a new UAV seeks to join the swarm, it undergoes a secure registration process facilitated by an edge server and recorded on the blockchain. It is important to note that while the cloud server performs the initial one-time trusted setup, it pre-generates cryptographic parameters for the system’s maximum designed capacity ($N_{max}$ including a pool of unique update keys ($upk$)). These parameters are securely distributed to and managed by the edge servers. Consequently, when a new UAV joins, the edge server can assign it a set of unused parameters from this local pool without needing to interact with the cloud server again. This design ensures the system’s dynamic scalability while maintaining the principle that the cloud server’s core mission is completed after the initial setup. This procedure ensures the UAV’s legitimate integration into the system’s identity management framework. The detailed protocol is presented in Algorithm 2 and further illustrated in Figure 3.

Algorithm 2: UAV registration protocol

Input: UAV Side: New UAV $\left({UAV}_{new}\right)$ with generated asymmetric key pair $\left(P{K}_{new},S{K}_{new}\right)$ Edge Server Side: Access to $prk, upk$ pool, current global commitment $C_t$

Output: UAV Side: Securely stored credentials $\left(UI{D}_i,u_i,{\pi }_i\right)$ Edge Server Side: Updated global commitment $C_{t+1}$ on blockchain, ${UAV}_{new}$ added to $V$ Process:

1. UAV Side:   1.1. Generate $nonce$.   1.2. Form registration request: $Re{q}_{reg}=\left({PK}_{new},Sig{n}_{S{K}_{new}}\left(nonce\right)\right)$.   1.3. Send $Re{q}_{reg}$ to Edge Server. 2. Edge Server Side:   2.1. Receive $Re{q}_{reg}$ from $UA{V}_{new}$.   2.2. Verify $Sig{n}_{S{K}_{new}}\left(nonce\right)$ and $nonce$ freshness.   2.3. Assign unique $UI{D}_{new}$ (slot $i$ in $V$) to $UA{V}_{new}$.   2.4. Fetch $up{k}_i=\left(a_i,u_i\right)$ from local pool.   2.5. Construct $v_i=\left(UI{D}_{new},P{K}_{new},H\left(up{k}_i\right)\right)$.   2.6. Calculate state change $\delta =v_i$.   2.7. Update global commitment: $C_{t+1}\leftarrow VC.UpdateComm\left(C_t,\delta ,i,up{k}_i\right)$.   2.8. Generate initial aSVC proof: ${\pi }_i\leftarrow VC.ProvePos\left(prk,i,V\right)$.   2.9. Broadcast transaction $Tx=\left(i,\delta ,a_i\right)$ to Blockchain Network.   2.10. Upon blockchain confirmation of Tx, securely distribute credentials$\left(UI{D}_i,u_i,{\pi }_i\right)$ to $UA{V}_i$. 3.UAV Side (After receiving credentials):   3.1. Securely store $u_i$ and ${\pi }_i$ in secure module. 4.All other UAV Nodes (Asynchronous Update):   4.1. Monitor Blockchain Network for new transactions.   4.2. Upon detecting $Tx=\left(i,\delta ,a_i\right)$, each $UA{V}_j$ (where j ≠ i) locally updates its proof in constant time O(1): ${\pi }_{j,t+1}\leftarrow VC.UpdateProof\left({\pi }_j,\delta ,i,j,a_i,up{k}_j\right)$.

The UAV registration protocol skillfully integrates cryptographic and blockchain mechanisms to ensure new UAVs securely and efficiently join the swarm and are incorporated into identity management. The use of a nonce in the protocol is a key guarantee against replay attacks. The edge server, as the core entity, is responsible for assigning a unique identity index $i$ to the new UAV and constructing its initial identity vector element $v_i$, which includes the UAV ID, public key, and the hash value of its aSVC update key, allowing it to be included in the aSVC commitment. Subsequently, the edge server uses the $VC.UpdateComm$ algorithm to update the global commitment $C_t$ on the blockchain, an operation crucial for maintaining the integrity of the system’s identity state.

A key advantage of this scheme is that all other UAVs can synchronize asynchronously: once the registration transaction is confirmed on-chain, existing UAVs can use the $VC.UpdateProof$ algorithm to update their own aSVC proofs locally in constant time O(1). This stateless synchronization mechanism significantly reduces overall synchronization overhead, ensuring system scalability in highly dynamic environments.

4.4. Lightweight Authentication

Addressing the highly dynamic and dense operational characteristics of UAV swarms, this scheme designs two authentication modes: regular single-node authentication for sporadic interaction requests, and swarm batch authentication specifically optimized for high-concurrency scenarios, fully leveraging the aggregation advantages of aSVC.

4.4.1. Single Node Fast Authentication

The single-node fast authentication mechanism aims to provide efficient, low-latency identity verification services for individual UAVs. The single-node authentication protocol satisfies the sporadic interaction authentication needs of UAVs with its lightweight and high efficiency. A UAV first obtains the latest global commitment $C_t$ from the blockchain, then constructs a signed authentication request containing its identity proof ${\pi }_i$ and a fresh random $nonc{e}_i$, and sends it to the edge server.

Upon receiving the request, the edge server first validates the signature and the nonce to prevent replay attacks and identity forgery. Subsequently, the core verification step involves calling the aSVC’s $VC.VerifyPos$ algorithm. This algorithm can efficiently verify whether the identity proof ${\pi }_i$ provided by the UAV matches the identity $v_i$ recorded in the current on-chain commitment $C_t$. The entire process does not require any blockchain write operations, greatly reducing authentication latency and ensuring that UAVs can quickly receive authentication responses, thereby achieving low-latency business interactions.

4.4.2. Cluster Batch Authentication

In high-density collaborative missions, UAV swarms often experience simultaneous authentication requests from multiple nodes. To circumvent the substantial computational overhead of individual authentication, this scheme leverages aSVC’s aggregation capabilities to design an efficient batch authentication protocol. The detailed protocol is presented in Algorithm 3 and further illustrated by Figure 4.

Algorithm 3: Cluster batch authentication protocol

Input: UAV Side$(\mathit{U}\mathit{A}{\mathit{V}}_{\mathit{i}},\mathit{i}\in \mathit{I}):{\left\{UI{D}_i,S{K}_i,{\pi }_i,nonc{e}_i\right\}}_{i\in I}$ Edge Server Side: Current global commitment $C_t$ verification key $vrk$, UAV identity vector $V$

Output: Edge Server Side: Batch authentication result (Success/Failure). Process:

1. UAV Swarm$(\mathit{U}\mathit{A}{\mathit{V}}_{\mathit{i}},\mathit{i}\in \mathit{I}$):   1.1. Each $UA{V}_i$ gets latest global commitment $C_t$ from blockchain.   1.2. Each $UA{V}_i$ generates: ${Req}_{auth,i}=\left(UI{D}_i,Sig{n}_{S{K}_i}\left({\pi }_i,nonc{e}_i\right)\right)$.   1.3. All $b$ $UA{V}_i$s concurrently send ${Req}_{auth,i}$ to Edge Server. 2. Edge Server Side:   2.1. Receive all $b$ concurrent authentication requests ${\{Req}_{auth,i}\},i\in I$.   2.2. Parallelly verify signatures $Sig{n}_{S{K}_i}\left({\pi }_i,nonc{e}_i\right)$ and $nonc{e}_i$ freshness for all $i\in I$.   2.3. Aggregate all individual proofs: ${\pi }_I\leftarrow VC.AggregateProofs\left(I,{\left({\pi }_i\right)}_{i\in I}\right)$.   2.4. Extract corresponding sub-vector $v_I=\left\{v_i\right\},i\in I$ from $V$.   2.5. Perform single-shot batch verification: $Result\leftarrow VC.VerifyPos\left(vrk,C_t,{\mathit{v}}_I,I,{\pi }_I\right)$

2.6. If all signature verifications, nonce checks, and Result are true, then authentication is successful; Else authentication fails.

The cluster batch authentication protocol is a core optimization of this scheme for handling high-concurrency UAV authentication scenarios. In traditional schemes, batch authenticating b UAVs requires performing b independent, computationally expensive verification operations. This scheme, by leveraging the unique aggregation properties of aSVC, fundamentally changes this paradigm.

After the edge server verifies the digital signatures and nonces in parallel, it calls the $VC.AggregateProofs$ algorithm to aggregate all individual identity proofs into a single aggregated proof ${\pi }_I$ of constant size. The key to efficiency improvement lies in the verification phase: the edge server only needs to perform a single $VC.VerifyPos$ operation on this aggregated proof ${\pi }_I$ to complete identity verification for all b UAVs. This means that the b expensive bilinear pairing operations are sharply reduced to just 1. This optimization significantly reduces the server’s computational pressure, greatly increasing the system’s throughput and response speed in high-concurrency scenarios, demonstrating the excellent performance advantages of this scheme in high-density UAV swarm authentication applications.

4.5. Dynamic Member Management Mechanisms

One of the core advantages of this scheme is its dynamic, lightweight management capability for various state changes throughout the UAV lifecycle. All dynamic management, whether key rotation, reputation changes, or node departure, is uniformly abstracted as state modifications to the global identity vector $V$. This modification is performed by the edge server via $VC.UpdateComm$ and broadcast through the blockchain, finally enabling all UAV nodes to complete local stateless synchronization by calling $VC.UpdateProof$.

4.5.1. Identity State Update

This procedure applies to updating any attribute bound within the UAV identity vector. Key rotation serves as a critical example. The detailed protocol is presented in Algorithm 4.

Algorithm 4: Dynamic state update protocol

Input: UAV Side$\left(\mathit{U}\mathit{A}{\mathit{V}}_{\mathit{i}}\right):UI{D}_i, old P{K}_i, new P{K}_i^{\prime }, S{K}_i, current {\pi }_i, nonc{e}_i, up{k}_i.$ Edge Server Side: Current global commitment $C_t$$,vrk$, UAV identity vector $V$

Output: Edge Server Side: Updated global commitment $C_{t+1}$ on blockchain. All UAV Nodes: Locally updated proofs ${\pi }_{j,t+1}$ for all $j$. Process:

1. UAV Side ($\mathit{U}\mathit{A}{\mathit{V}}_{\mathit{i}}$, for key rotation example):   1.1. Generate new key pair ($P{K}_i^{\prime }, S{K}_i^{\prime }$).   1.2. Construct update request: ${Reg}_{update}=\left(UI{D}_i,Sig{n}_{S{K}_i}\left(P{K}_i^{\prime },{\pi }_i,nonc{e}_i,up{k}_i\right)\right)$.   1.3. Send ${Reg}_{update}$ to Edge Server. 2. Edge Server Side:   2.1. Receive ${Reg}_{update}$ from $UA{V}_i$.   2.2. Verify $Sig{n}_{S{K}_i}$ validity and $nonc{e}_i$ freshness.   2.3. Verify$up{k}_i$ legitimacy: $T/F\leftarrow VC.VerifyUPK\left(vrk,i,up{k}_i\right)$   2.4. If all verifications pass:      2.4.1. Construct new identity element ${v^{\prime }}_i=\left(UI{D}_i,P{K^{\prime }}_i,H\left(up{k}_i\right),nonce\right)$.      2.4.2. Calculate state change $\delta =v_i^{\prime }-v_i$.      2.4.3. Update global commitment: $C_{t+1}\leftarrow VC.UpdateComm\left(C_t,\delta ,i,up{k}_i\right)$      2.4.4. Broadcast transaction $Tx=\left(i,\delta ,a_i\right)$ to the Blockchain Network.   2.5. Else (verifications fail): Reject update request.

3. All UAV Nodes (Stateless Synchronization):   3.1. Monitor the Blockchain Network for new transactions.   3.2. Upon detecting confirmed $Tx=\left(i,\delta ,a_i\right)$, each $UA{V}_j$ (including $UA{V}_i$ itself) locally updates its own proof in constant time O(1): ${\pi }_{j,t+1}\leftarrow VC.UpdateProof\left({\pi }_j,\delta ,i,j,a_i,up{k}_j\right)$

The dynamic member management mechanism is crucial for achieving lightweight and highly dynamic adaptability in UAV swarms. This mechanism uniformly abstracts all state changes throughout the UAV lifecycle (e.g., key rotation, reputation updates, node departure) as modifications to the global identity vector $V$. After verifying the legitimacy of an update request, the edge server calculates the identity element change $\delta$ and uses the $VC.UpdateComm$ algorithm to update the global commitment $C_t$. This update is then encapsulated as a transaction Tx and broadcast to the blockchain network. The most significant advantage of this scheme lies in the “global stateless synchronization” phase. Once the transaction Tx is confirmed on the blockchain, all UAV nodes in the network can use their secret update key ($up{k}_j$) and the broadcast public information to call the $VC.UpdateProof$ algorithm in constant time O(1) to update their own aSVC proofs. This “one broadcast, all synchronize” mechanism significantly reduces the system’s network burden under dynamic management, avoiding frequent end-to-server communication and complex synchronization overhead, greatly enhancing the system’s scalability and response speed in highly dynamic environments.

4.5.2. Deactivation and Revocation

Node departure or removal is considered a special type of state update where an identity slot is set to zero, and its process is entirely consistent with the aforementioned mechanism. When a $UA{V}_i$ wishes to proactively leave the swarm or is detected to exhibit malicious behavior and needs to be forcefully revoked, the edge server (or a trusted cloud server acting as an arbiter) updates its identity state $v_i$ to 0 (or a “revoked” state value). This process is also completed by calculating the state change $\delta =0-v_i$ and broadcasting the corresponding transaction $Tx=\{i,\delta ,a_i$} to the blockchain network, thereby making that identity slot available for new node registration or permanently expelling the node.

5. Security Analysis

This section’s security analysis will elucidate how the scheme leverages the cryptographic assurances of aggregatable subvector commitments (aSVC) and the architectural advantages of blockchain technology to effectively resist the various threats listed in Section 3.2, ensuring the confidentiality, integrity, and availability of UAV swarm identity authentication.

• Identity Forgery and Unauthorized Access

Each UAV’s identity $v_i$ (including $UI{D}_i$, $P{K}_i$, etc.) is committed in the aSVC vector and endorsed by the global commitment $C_t$. An adversary A cannot impersonate a legitimate $UA{V}_i$ without a valid aSVC proof ${\pi }_i$ (which must pass $VC.VerifyPos$ against $C_t$). The Position Binding Security of aSVC ensures that an adversary cannot forge a valid proof for index $i$ under commitment $C_t$ that is different from the true value $v_i$. All critical operations (such as state update requests) require the UAV to use its $S{K}_i$ for signing, and the authenticity of the public key $P{K}_i$ is guaranteed by the aSVC proof. Therefore, an adversary without the corresponding private key cannot initiate legitimate requests.

• Replay Attack

During the authentication process, the UAV generates a unique, unpredictable random nonce and incorporates it into the signed message. This signature encompasses the nonce, thereby binding the request to that specific random number. The edge server maintains a cache of recently utilized nonces and rejects any request where the nonce already exists in the cache, identifying it as a replay attack. For valid requests bearing a new nonce, the server stores that nonce in the cache subsequent to processing. Thus, an attacker who intercepts a legitimate message is unable to replay it because its nonce has been recorded and invalidated. Concurrently, without the UAV’s private key $S{K}_i$, the attacker is precluded from forging a valid signature for a new nonce.

• Sybil Attack

All UAVs are mandated to register through an edge server. The edge server performs identity verification during the registration process and assigns a unique $UI{D}_i$ and a corresponding aSVC slot to each legitimate UAV. An adversary would find it challenging to arbitrarily generate a multitude of false identities and obtain legitimate aSVC proofs without validation by the edge server. The blockchain immutably records all registration events and the current commitment $C_t$, ensuring that any attempt to introduce unregistered identities is readily detected due to the absence of a valid proof corresponding to $C_t$.

• Denial of Service (DoS) Attack

Against Edge Servers: Although edge servers engage in registration and state updates, the authentication process is distributed, enabling UAVs to authenticate directly with other UAVs, thereby reducing the burden on the GCS. For registration and update requests, edge servers can deploy rate limiting, request validation, and other defensive mechanisms.

Against UAVs: aSVC proof verification and update operations are inherently lightweight (O(1) complexity), thereby minimizing the resource consumption of UAVs in cryptographic operations and rendering them more resilient to computation-resource-exhaustion DoS attacks.

DoS on User Registrations: Should registrations be cost-free, an attacker might exhaust the aSVC vector space by submitting a large number of registration requests. In this scheme, registration is governed by the edge server, which can impose registration costs (e.g., mandating physical verification, or requiring endorsement/payment from existing members akin to INITSPEND transactions), or constrain the registration rate, to mitigate such attacks.

• Man-in-the-Middle Attack

The communication channel itself may not be inherently secure; however, since all critical information exchange relies on digital signatures and aSVC proofs, an adversary, even if intercepting or tampering with messages, is unable to forge legitimate signatures or valid aSVC proofs. The verifier consistently validates proofs based on the commitment $C_t$ obtained from the trusted blockchain.

• Data Tampering

The aSVC commitment $C_t$ and associated management transaction records are stored on the blockchain. The immutability of the blockchain guarantees that once this information is confirmed, it cannot be maliciously altered. Any attempt at tampering with historical states would inevitably lead to a mismatch in subsequent block hashes, thereby resulting in rejection by the network.

• Resilience Against Physical Dimension Threats

While this paper’s primary contribution is a digital authentication scheme, its architecture serves as a critical enabling layer for mitigating the physical threats outlined in Section 3.2. Our scheme addresses the challenge of a digitally revoked node remaining a physical entity by providing a cryptographically secure and rapidly disseminated trigger for physical countermeasures. Essentially, the scheme provides the definitive “who” (the threat’s identity), enabling the swarm’s onboard systems to address the “where (its location) and “what” (its actions).

Against Kinetic Attacks: The on-chain revocation of a $UA{V}_i$ acts as an authoritative alert. This trusted information triggers the swarm’s cooperative tracking systems, which then use onboard sensors to monitor the rogue UAV’s location and treat it as a dynamic obstacle for systematic avoidance.

Against Localized Jamming/Spoofing: The scheme helps pinpoint the attack’s source. Anomalous sensor data reported by swarm members can be correlated with the known identity and tracked location of the revoked UAV, allowing edge servers to confidently instruct the swarm to engage alternative navigation methods or reroute to bypass the affected area.

Against Passive Surveillance: The definitive identification of a threat enables a targeted response. Once the swarm’s sensors detect shadowing by the identified rogue UAV, edge servers can initiate dynamic mission re-planning to create an unpredictable trajectory and break contact.

In essence, our authentication framework bridges the gap between digital identity management and physical security. By using the blockchain to immutably identify threats, it provides the trusted, foundational intelligence required for the swarm’s dedicated physical defense and navigation systems to execute effective and targeted countermeasures.

6. Experimental Evaluation

To conduct a comprehensive and objective performance evaluation of the proposed lightweight and dynamic authentication scheme for UAV swarms based on blockchain and aSVC, we established a high-fidelity simulation environment using the NS-3 platform. This evaluation centers on the system’s runtime operational performance, where edge servers and UAVs are the principal active entities. The edge server’s computational load is a key focus, as it processes all authentication and state update tasks. The cloud server, which only performs a one-time trusted setup, is excluded from this analysis of ongoing efficiency metrics like latency and throughput, as its setup cost is a one-time capital expenditure. Through multi-dimensional comparisons with existing mainstream authentication mechanisms, the experiment quantifies the scheme’s advantages in computational overhead, communication load, and energy consumption to validate its efficacy and suitability for resource-constrained, dynamic UAV swarm environments.

6.1. Experimental Environment and Parameter Settings

To ensure the accuracy and reproducibility of experimental results, this experiment established the following simulation environment and configured relevant parameters. The experiment was executed using the network simulation platform NS-3 (Network Simulator 3, version 3.37), running on an Ubuntu 22.04 LTS operating system (equipped with an Intel Core i7-12700H processor and 32 GB DDR5 memory). The performance of underlying cryptographic operations was benchmarked using the Crypto++ 8.2 C++ library, with pairing-based operation performance referencing high-performance test results from the blstrs library on the BLS12-381 curve. On the methodology front, to ensure the reliability and reproducibility of our findings, we performed 30 independent replications for each simulation scenario, using a unique random seed for each run. For each set of 30 replications, we calculated the mean as the measure of central tendency and the standard deviation (SD) as the measure of intrinsic variability, which indicates the stability of our scheme’s performance. Furthermore, we report the 95% confidence interval (CI) to quantify the uncertainty in our estimate of the mean. Given our sample size (n = 30), the CIs were calculated using Student’s t-distribution with n−1 degrees of freedom. The formula is $95\mathrm{\%} CI = Mean \pm \left(t_{critical}\times \left(SD/\sqrt{n}\right)\right)$, where $t_{critical}$ is the two-tailed critical value from the t-distribution for a 95% confidence level and 29 degrees of freedom (t ≈ 2.045). All statistical analyses were conducted using Python (version 3.9) with the SciPy library.

The size of the UAV swarm in the simulation dynamically ranged from 30 to 200 UAVs, with nodes active within a 2 km × 2 km virtual space. Their movement pattern adopted a two-dimensional Random Waypoint Mobility Model to simulate the highly dynamic topological changes in UAVs. The blockchain network consisted of 4 edge server nodes forming a consortium chain, employing the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm to ensure data consistency. The aSVC mechanism of this scheme was built upon a 256-bit prime order elliptic curve, providing a 128-bit security level, with its maximum node index $N_{max}$ set to 1024. Digital signatures in all schemes used the ECDSA algorithm on the same curve to ensure fairness of comparison.

To objectively measure the performance of this scheme, four representative existing identity authentication mechanisms were selected as comparison baselines:

• PROP (Blockchain + aSVC): The lightweight dynamic authentication scheme proposed in this paper, integrating blockchain and aggregatable subvector commitments.
• BASUV [35]: A blockchain-enabled UAV authentication scheme designed for vehicular ad hoc networks.
• BCPPA [36]: A PKI-based conditional privacy-preserving authentication protocol designed for vehicular ad hoc networks.
• EDRAX [37]: A groundbreaking stateless cryptocurrency architecture that uses vector commitments to maintain state.

6.2. Computational Overhead

This section aims to evaluate the efficiency of the proposed scheme in processing UAV swarm authentication requests from the perspective of computational overhead, particularly in high-concurrency scenarios. The analysis specifically models the computational workload on the edge server, as it is the core entity responsible for verifying signatures and proofs during both single and batch authentication processes. To begin,

Table 3. Different cryptographic operations and execution times.

Notation	Time (ms)	Description
$T_{Par}$	0.757	Bilinear pairing in $G_T$
$T_{Mg}$	0.926	Point multiplication in $G$
$T_{Hash}$	0.003	Hash function
$T_{Exp}$	0.098	Exponentiation in $G_T$
$T_{Mt}$	0.001	Multiplication in $G_T$
$T_{Add}$	0.005	Point addition in $G$
$T_{Sign}$	0.929	Digital signature generation
$T_{Ver}$	1.806	Digital signature verification
$T_{Snark-ver}$	2.271	zk-SNARK proof verification

presents the benchmark timings for all underlying cryptographic operations, which were measured in the environment described in Section 6.1.

Subsequently, the computational overhead for each scheme in single authentication and batch authentication (b-Authentication) scenarios was theoretically modeled, as shown in

Table 4. Computational overhead comparison of proposed and existing schemes.

Scheme	1-Authentication	b-Authentication
BASUV [35]	$T_{Add}$ + 4$T_{Mg}$ + 6$T_{Hash}$ + 5$T_{Par}$ + 3$T_{Exp}$ + $T_{Mt}$ ≈ 7.807 ms	$b\cdot$($T_{Add}$ + 4$T_{Mg}$ + 6$T_{Hash}$ + 5$T_{Par}$ + 3$T_{Exp}$ + $T_{Mt}$) ≈ b⋅7.807 ms
BCPPA [36]	$T_{Mg}$ + $T_{Hash}$ + $T_{Sign}$ + 2$T_{Ver}$ ≈ 5.47 ms	$b\cdot (T_{Mg}$ + $T_{Hash}$ + $T_{Sign}$ + 2$T_{Ver}$) ≈ b⋅5.47 ms
EDRAX [37]	$T_{Sign}$ + $T_{Ver}$ + $T_{Snark-ver}$ ≈ 5.006 ms	$b\cdot (T_{Sign}$ + $T_{Ver}$ + $T_{Snark-ver}$) ≈ b⋅5.006 ms
PROP	$T_{Sign}$ + $T_{Ver}$ + 2$T_{Par}$ ≈ 4.249 ms	$b\cdot (T_{Sign}$ + $T\_Ver)$ + $\left(b-1\right)\cdot T_{Mg}$ + $2\cdot T_{Par}$ ≈ $b\cdot$3.661 + 0.588

.

For the batch authentication formula of the PROP scheme: $b\cdot (T_{Sign}+T\_Ver)+\left(b-1\right)\cdot T_{Mg}+ 2\cdot T_{Par}$. Here,$b\cdot (T_{Sign}+T\_Ver)$ represents the edge server verifying all UAV request signatures; $\left(b-1\right)\cdot T_{Mg}$ is the computation for aggregating proofs in $VC.AggregateProofs$ (multiplication of b points requires $b-1$ operations); $2\cdot T_{Par}$ is the overhead of a single $VC.VerifyPos$ operation on the aggregated proof ${\pi }_I$. From the theoretical formulas in Table 4, it can be seen that the core advantage of this scheme lies in batch authentication. For BASUV, BCPPA, and EDRAX, their authentication overhead shows a strictly linear relationship with the number of UAVs b, as the server needs to perform independent cryptographic verifications for each UAV’s proof or signature. In contrast, this scheme leverages the aggregation property of aSVC, compressing b expensive pairing verification operations ($T_{Par}$) into a single one. Its primary computational cost becomes parallel signature verification and a single aggregated proof verification, thereby theoretically demonstrating superior scalability.

To empirically validate the theoretical models, we conducted simulations for each scenario, replicating each 30 times to ensure statistical robustness. The results are presented in Figure 5, which plots the mean computational overhead, and in

Table 5. Descriptive statistics and 95% confidence intervals for computational overhead (ms) at key swarm sizes.

Swarm Size (b)	Scheme	Mean (ms)	Std Dev (ms)	95% CI Lower	95% CI Upper
100	BASUV [35]	776.35	15.28	770.64	782.06
	BCPPA [36]	544.44	12.15	539.90	548.98
	EDRAX [37]	500.68	12.09	496.17	505.20
	PROP	367.81	5.75	365.66	369.95
200	BASUV [35]	1561.12	28.95	1550.31	1571.93
	BCPPA [36]	1095.54	20.73	1087.80	1103.28
	EDRAX [37]	1002.23	16.79	995.96	1008.50
	PROP	736.22	12.21	731.66	740.78

, which details the descriptive statistics for key swarm sizes.

As depicted in Figure 5, the mean computational overhead for all schemes increases linearly with the number of concurrently authenticated UAVs. To determine if the observed differences were statistically significant, we performed a one-way Analysis of Variance (ANOVA) on the data for a swarm size of 200 UAVs. The analysis revealed a significant main effect for the authentication scheme, F(3, 116) = [7768.95], p < 0.001.

Post hoc comparisons using the Tukey HSD test were conducted to examine pairwise differences (see Table 5 for mean and SD values). The results indicated that the mean computational overhead for our proposed PROP scheme (M = 736.22, SD = 12.21]) was statistically significantly lower than that of BASUV (p < 0.001), BCPPA (p < 0.001), and EDRAX (p < 0.001).

Furthermore, the low standard deviation (SD) for the PROP scheme across all conditions demonstrates its high performance stability. The narrow 95% confidence intervals, visible as shaded regions in Figure 5 and detailed in Table 5, indicate a precise estimation of this mean performance. These statistical findings move beyond visual interpretation to rigorously confirm that the aSVC-based aggregation mechanism provides a significant and reliable advantage in reducing computational load, thereby validating the superiority of our scheme in high-concurrency environments.

6.3. Communication Overhead

This section aims to evaluate the lightweight attributes of this scheme, in terms of data transmission, from the perspective of communication overhead. First,

Table 6. Simulation parameter settings.

Notation	Description	Size (byte)
$\left|G\right|$	Size of an Element in Group G	128
$\left|ID\right|$	Size of an entity identity	20
$\left|nonce\right|$	Size of nonce	20
$\left|Sign\right|$	Size of Sign	128
$\left|{\pi }_i\right|$	Size of proof	128
$\left|up{k}_i\right|$	Size of update key	256
$\left|H\right|$	Size of hash	32
$\left|{\pi }_{zk}\right|$	Size of proof zk-SNARK	268
$\left|m\right|$	Size of plaintext	32

defines the standard sizes of various communication elements, referencing settings in the compared schemes to ensure fairness.

6.3.1. Static Interaction Overhead Comparison

First, we compare the communication overhead of each scheme in two static interaction scenarios: registration and single authentication, as shown in

Table 7. Communication cost comparison for static interactions.

Scheme	Registration	Authentication
BASUV [35]	$2\left|G\right|$$+ 3\left|\mathrm{I}D\right|$ = 316	$2\left|G\right|$$+ 4\left|m\right|$ = 384
BCPPA [36]	$\left|G\right|$$+ \left|\mathrm{H}\right| + \left|Sign\right|$ = 288	$\left|Sign\right|$$+ 2\left|m\right|$$+ \left|nonce\right|$ = 212
EDRAX [37]	$\left|G\right|$$+ \left|Sign\right|=$ 256	$2\left|\mathrm{I}D\right|$$+ \left|nonce\right|$$+ \left|Sign\right|$$+ \left|{\pi }_{zk}\right|$= 456
PROP	$2\left|G\right|$ $+\left|Sign\right|$ $+\left|nonce\right|$ $+\left|\mathrm{I}D\right|$ $+\left|{\pi }_i\right|=552$	$\left|G\right|$ $+\left|Sign\right|$ $+\left|nonce\right|$ $+\left|\mathrm{I}D\right|$ $=296$

.

As illustrated in Figure 6, in static interaction scenarios, the communication overhead of each scheme falls within a few hundred bytes, exhibiting no significant order-of-magnitude differences. Specifically, this scheme’s registration phase overhead (552 bytes) is higher than other schemes. This is attributable to the fact that, during registration, this scheme requires a one-time distribution of the complete update key ($upk$), which is necessary for subsequent localized updates, to the UAV in a single, one-time investment to achieve long-term dynamic management efficiency. In the single authentication phase, this scheme’s overhead (296 bytes) is commensurate with that of other schemes.

6.3.2. On-Chain Cost for Dynamic Updates

The on-chain overhead for dynamic updates serves as a decisive indicator for assessing a scheme’s management efficiency and lightweight nature in dynamic environments. It quantifies the minimum amount of data that needs to be broadcast on the blockchain when a node’s state changes (e.g., key rotation, departure) to synchronize the entire distributed network to the latest state.

Table 8. On-chain cost comparison for dynamic updates.

Scheme	On-Chain Cost for Dynamic Updates
BASUV [35]	$2\left|G\right|$ $+ 4\left|\mathrm{I}D\right|$= 336
BCPPA [36]	$2\left|G\right|$ $+ \left|Sign\right|$$+ \left|\mathrm{I}D\right|$= 404
EDRAX [37]	$\left|\mathrm{I}D\right|$ $+ \left|G\right|$$+ \left|Sign\right|$$+ \left|{\pi }_{zk}\right|$= 544
PROP	$2\left|G\right|$ $+\left|\mathrm{I}D\right|=276$

provides this comparison.

As demonstrated in Figure 7, this scheme exhibits excellent lightweight characteristics with an on-chain overhead of 276 bytes when processing dynamic updates. When a UAV’s state is updated, the edge server is only required to publish a minimalist transaction $Tx=\left\{i,\delta ,a_i\right\}$ on-chain. This lightweight transaction suffices for all UAVs in the network to complete proof updates locally. Conversely, although other schemes also support on-chain updates, their implementation mechanisms (e.g., EDRAX mandating a complete proof) or procedures (e.g., BCPPA necessitating multi-step transactions) result in higher on-chain overhead. This comparison conclusively demonstrates that this scheme, through concise on-chain announcements, achieves efficient and low-cost global state synchronization, perfectly fulfilling the application requirements of highly dynamic, resource-constrained UAV swarms.

6.4. Authentication Latency

To further assess the comprehensive performance of each scheme in practical applications, we simulated the end-to-end authentication latency in batch authentication scenarios. This metric quantifies the total time from a UAV initiating an authentication request to receiving final confirmation. Figure 8 illustrates the mean authentication latency for each scheme as the number of concurrently authenticating UAVs increases from 30 to 200. Each data point represents the mean of 30 independent runs, with shaded regions depicting the 95% Confidence Intervals (CIs). The mean reflects the average performance, while the standard deviation (SD), detailed in

Table 9. Descriptive statistics and 95% confidence intervals for authentication latency (ms) at key swarm sizes.

Swarm Size (b)	Scheme	Mean (ms)	Std Dev (ms)	95% CI Lower	95% CI Upper
100	BASUV [35]	986.22	2.39	985.33	987.12
	BCPPA [36]	693.70	2.33	692.82	694.57
	EDRAX [37]	636.13	3.18	634.94	637.32
	PROP	296.47	3.25	295.25	297.69
200	BASUV [35]	2353.63	2.60	2352.66	2354.60
	BCPPA [36]	1651.12	2.48	1650.19	1652.05
	EDRAX [37]	1511.24	2.90	1510.16	1512.33
	PROP	611.43	2.71	610.25	612.62

, serves as the primary indicator of performance stability.

As illustrated in Figure 8, while the authentication latency of all schemes increases with the number of UAVs, the growth trend for our proposed PROP scheme is markedly flatter. To statistically validate this observation, a one-way ANOVA was performed on the latency data for the 200 UAVs scenario. The results confirmed a significant difference among the schemes, F(3, 116) = [1,866,926.94], p < 0.001.

Post hoc analysis using the Tukey HSD test provided further insights into pairwise comparisons. The mean latency for the PROP scheme (M = [611.43], SD = [2.71]) was found to be statistically significantly lower than that of BASUV (p < 0.001), BCPPA (p < 0.001), and EDRAX (p < 0.001), as detailed in Table 9.

An interesting observation arises from the analysis of the standard deviation. While the absolute performance variation resulting from computational tasks is significantly smaller for the PROP scheme due to its much lower mean processing time, its total observed standard deviation is primarily influenced by the inherent randomness of simulated network jitter. This is a fixed source of variance applied to all schemes. In essence, the computational performance of the PROP scheme is so stable that this constant, irreducible network jitter becomes the dominant component of its overall variance. Conversely, for the competing schemes, their high and variable computational overhead is the primary driver of performance instability, far outweighing the impact of network conditions.

This outcome powerfully corroborates the superiority of the aSVC aggregated authentication mechanism. The fundamental reason is that the most time-consuming bilinear pairing verification on the server side is optimized to a single constant-time operation. This dramatically reduces server computation time and mitigates queuing latency under high concurrency.

In summary, these statistical findings, which align with our theoretical analysis of computational overhead, rigorously validate the excellent performance and high scalability of our scheme in large-scale, high-concurrency UAV swarm authentication scenarios.

6.5. Success Rate

To evaluate the capability of each scheme to handle network uncertainty in realistic communication environments, this section presents a simulation analysis of the authentication success rate, a key performance indicator. In wireless communication scenarios such as UAV ad hoc networks, signal interference, node mobility, and network congestion can lead to packet loss, directly impacting the availability of the authentication protocol. The authentication success rate is defined as the proportion of authentication requests initiated by UAVs for which all protocol steps are successfully completed at the verifier within a preset timeout threshold of 500 ms. A high success rate implies that a scheme possesses high robustness under unreliable channel conditions.

The simulation environment for this test was consistent with that described in Section 6.1, conducted on the NS-3 platform. We configured a fixed swarm size of 50 UAVs performing concurrent authentication and progressively increased the network packet loss rate from 0% to 20% to simulate a gradual transition from an ideal channel to a degraded one. To ensure the statistical validity of the results, each packet loss rate scenario was independently replicated 30 times. The final results are presented as the mean of these replications, with the 95% confidence intervals indicating the range of variance.

As depicted in Figure 9, the authentication success rate of all schemes declines as network packet loss increases. To formally evaluate the differences in robustness, we conducted one-way ANOVAs at each tested packet loss level. For instance, at a packet loss rate of 20%, the analysis revealed a statistically significant difference in mean success rates among the schemes, F(3, 116) = [100.07], p < 0.001.

Post hoc comparisons using the Tukey HSD test clarified these differences (see

Table 10. Descriptive statistics and 95% confidence intervals for authentication success rate (%) under key packet loss conditions.

Packet Loss Rate	Scheme	Mean (%)	Std Dev (%)	95% CI Lower	95% CI Upper
10%	BASUV [35]	81.26	4.47	79.59	82.93
	BCPPA [36]	74.13	6.98	71.52	76.74
	EDRAX [37]	89.80	4.55	88.09	91.50
	PROP	89.66	3.82	88.23	91.09
20%	BASUV [35]	64.40	8.68	61.15	67.64
	BCPPA [36]	52.73	7.26	50.01	55.44
	EDRAX [37]	77.86	6.38	75.48	80.25
	PROP	82.33	6.88	79.76	84.90

for detailed statistics). At the 20% packet loss level, the PROP scheme’s success rate was statistically significantly higher than that of the BCPPA (p < 0.001) and BASUV (p < 0.001) schemes. While there was no significant difference between the PROP and EDRAX schemes, both demonstrated superior resilience.

The underlying reasons for these statistically validated differences lie in the protocol designs. The high robustness of the PROP and EDRAX schemes stems from their reliance on a single, self-contained message transmission. The verifier can validate the request using pre-existing on-chain data without further network interaction, making success primarily dependent on the delivery of this single packet. In contrast, the BASUV scheme requires a secondary query to the blockchain, introducing an additional point of failure. The BCPPA scheme is the most vulnerable as its multi-step protocol, requiring at least three separate network interactions, compounds the probability of failure with each step.

In summary, the simulation results, backed by rigorous statistical analysis, validate that the PROP scheme’s concise, one-way authentication process provides superior robustness in unreliable network environments. Its significantly higher success rate is crucial for ensuring mission reliability in dynamic UAV swarm operations.

7. Conclusions

Addressing the identity authentication challenges encountered by UAV swarms in highly dynamic and resource-constrained environments, this paper proposes a lightweight and dynamic authentication scheme that integrates blockchain with aggregatable subvector commitments (aSVC). By constructing a “Cloud-Edge-Device” collaborative architecture, this scheme leverages aSVC technology to compress the overall identity state of the swarm into a single on-chain commitment value, thereby achieving decentralized, secure, and efficient identity management.

The main advantages of this scheme are reflected in the following: constant-level reduction in on-chain storage overhead, significantly alleviating the blockchain burden; a statistically significant optimization of computational complexity for batch authentication, reducing key cryptographic operations from linear dependence on the number of UAVs to a constant level, effectively addressing large-scale concurrent authentication demands; superior scalability in end-to-end authentication latency, with simulation results showing a statistically significant and flatter latency growth curve; high security, by combining aSVC’s position binding and digital signatures; and relying on the blockchain’s tamper-proof characteristics, it can effectively defend against various common threats such as identity forgery, replay attacks, and Sybil attacks.

While our scheme demonstrates significant theoretical and simulated advantages, we acknowledge that its real-world deployment presents unique challenges. For example, ensuring consistent and low-latency network connectivity in dynamic UAV environments is critical for timely blockchain synchronization and authentication. Additionally, the scheme’s reliance on a trusted one-time setup by a cloud server, though decentralized thereafter, still represents a single point of trust at the initial stage, which could be a concern in highly adversarial settings. Finally, practical resource management, including the energy consumption from continuous cryptographic operations and network communication on resource-constrained UAVs, requires careful optimization for long-duration missions.

Meanwhile, this paper also acknowledges that the current scheme’s system capacity is constrained by the initial maximum vector length $N_{max}$ set for aSVC. Future research directions will explore the integration of multiple aSVC instances with cross-commitment proof aggregation techniques to construct an infinitely scalable identity authentication system, capable of adapting to the application requirements of ultra-large-scale UAV swarms. Furthermore, we will investigate methods to enhance the resilience of our scheme against the physical-layer attacks specific to UAVs, such as GPS spoofing and signal jamming, to provide a more comprehensive security solution in real-world scenarios. Crucially, this future work will also focus on developing a tighter integration between the digital identity revocation process proposed herein and the subsequent physical-space countermeasures. This includes designing advanced cooperative tracking, dynamic mission re-planning, and autonomous neutralization strategies to counter malicious UAVs that remain a physical threat post-revocation, thus bridging the gap between digital security and physical operational safety.