In recent years, the Internet of Drones (IoD) technology has seen widespread application across numerous fields such as logistics, agriculture, aerial photography, and disaster rescue. This network, composed of distributed UAV drone nodes, demonstrates significant value in building smart cities by undertaking tasks in intelligent traffic management, public safety, and environmental monitoring, often replacing traditional labor-intensive and high-risk operations. However, the dynamic and open nature of IoD, coupled with its reliance on open wireless communication channels like Wi-Fi and Bluetooth for real-time data transmission between UAV drones, introduces substantial security challenges. As the number of UAV drones increases in collaborative missions, traditional one-to-one authentication mechanisms incur prohibitive computational overhead. Furthermore, data transmitted over open channels is vulnerable to severe security threats, including illegal access, data interception, and privacy breaches. Sensitive information collected by UAV drones, if maliciously intercepted or tampered with, could lead to dire consequences, such as traffic accidents or even its exploitation for terrorist activities. Therefore, establishing a reliable identity authentication mechanism is the paramount prerequisite for ensuring secure IoD communications. It prevents identity forgery and man-in-the-middle attacks, thereby fortifying the security of multi-drone collaborative tasks. Building upon this, designing an efficient Authentication and Key Agreement (AKA) protocol is crucial for enhancing authentication efficiency and ensuring the reliable operation of IoD systems.
The primary solution to the aforementioned problems lies in AKA schemes. The core objectives of an AKA protocol are twofold: first, mutual entity authentication, which verifies the authenticity of communicating entities to ensure they are legitimate and not malicious impersonators; and second, session key agreement, where the communicating parties jointly generate a temporary session key valid only for the current specific communication session to ensure subsequent confidential communication. Over the past years, researchers have proposed numerous AKA schemes aimed at protecting data during wireless transmission from illegal access by adversaries. However, existing protocols often face a critical trade-off. Some protocols, in pursuit of lightweight design, have been found vulnerable to various attacks specific to IoD systems, fail to guarantee user anonymity, or are susceptible to denial-of-service attacks. Other protocols achieve the required security and privacy features but consume significant resources through complex operations like bilinear pairings or physical unclonable functions (PUFs), which may not be stable in harsh environments typical for UAV drones. Moreover, many studies primarily focus on one-to-one authentication scenarios for UAV drones. While claiming low computational overhead for a single session, their efficiency drastically degrades when multiple UAV drones need to be authenticated for collaborative tasks, as the protocol must be executed numerous times sequentially.
To address these pressing issues—securing wireless data transmission among UAV drones against potential threats and meeting the practical need for authenticating multiple drones efficiently—this work proposes a lightweight batch authentication and key agreement protocol tailored for drone swarms in the IoD environment. The proposed protocol is based on Elliptic Curve Cryptography (ECC) and is designed to enable rapid batch identity verification and key agreement.
The main contributions of this work are as follows:
- We propose a lightweight batch AKA protocol suitable for IoD environments. This protocol supports batch signature verification for fast identity authentication, significantly improving operational efficiency. Furthermore, the Ground Station (GS) does not participate in the AKA phase, greatly reducing its workload and saving substantial resource overhead.
- The protocol facilitates one-to-one session key agreement rather than a single shared group key, ensuring the uniqueness of the session key for each participating UAV drone. Additionally, considering protocol usability and the flexibility of UAV drones, the protocol allows for periodic updates of identity credentials.
- The semantic security of the session key is formally proven under the widely adopted Random Oracle Model (ROM). Furthermore, the automated verification tool ProVerif is employed to assess the scheme’s security. Finally, an informal security analysis demonstrates that our scheme provides enhanced security and functionality, meeting the security requirements of the IoD environment.
- The performance of the protocol is evaluated by measuring the execution time of common cryptographic operations using the OpenSSL and PBC libraries. The protocol is compared with five related authentication schemes across three aspects: computational overhead, communication overhead, and security features. Comparative analysis shows that our protocol not only exhibits lower computational and communication costs but also provides more security properties and functionalities.
Preliminaries
Elliptic Curve Cryptography
Elliptic Curve Cryptography is an asymmetric encryption system built upon the mathematical theory of elliptic curves. It can provide security equivalent to traditional algorithms (e.g., RSA) while significantly reducing key length. Let $\mathbb{F}_p$ be a finite field, where $p$ is a large prime. A non-singular elliptic curve $E(a, b)$ over $\mathbb{F}_p$ is defined by the equation $$y^2 \mod p = (x^3 + ax + b) \mod p,$$ where $a$ and $b$ are non-negative integers satisfying $4a^3 + 27b^2 \neq 0$ to ensure the curve is non-singular. Its security relies on the computational hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP) and the Elliptic Curve Diffie-Hellman Problem (ECDHP). We describe the computational problems and assumptions on elliptic curves below.
Definition 1 (Elliptic Curve Discrete Logarithm Problem – ECDLP): Given a point $X$ and $aX$, where $X \in G$, $a \in \mathbb{Z}_q^*$, finding $a$ is computationally infeasible. The advantage of an adversary $\mathcal{A}$ in solving the discrete logarithm problem within probabilistic polynomial time $t$ is defined as:
$$Adv_{\mathcal{A}}^{ECDLP}(t) = \Pr[\mathcal{A}(X, aX) = a : a \xleftarrow{R} \mathbb{Z}_q^*, X \in G].$$
Definition 2 (Elliptic Curve Diffie-Hellman Problem – ECDHP): Given points $aX$ and $bX$, where $X \in G$, $a, b \in \mathbb{Z}_q^*$, finding $abX$ is computationally infeasible. The advantage of an adversary $\mathcal{A}$ in solving the Diffie-Hellman problem within time $t$ is defined as:
$$Adv_{\mathcal{A}}^{ECDHP}(t) = \Pr[\mathcal{A}(X, aX, bX) = abX : a, b \xleftarrow{R} \mathbb{Z}_q^*, X \in G].$$
Definition 3 (ECDLP and ECDHP Assumption): For any probabilistic polynomial-time adversary $\mathcal{A}$, the values $Adv_{\mathcal{A}}^{ECDLP}(t)$ and $Adv_{\mathcal{A}}^{ECDHP}(t)$ are negligible. That is, there exists a sufficiently small $\epsilon > 0$ such that:
$$Adv_{\mathcal{A}}^{ECDLP/ECDHP}(t) \leq \epsilon.$$
Network Model
The network model considered in this work consists of three types of communication entities: the Ground Station (GS), a Leader Drone (LD), and multiple Member Drones (MDs). Legitimate UAV drones can authenticate each other and negotiate session keys to ensure the security of subsequent communications, while unregistered illegal drones fail authentication. The GS is deployed in a secure geographical and network location, is considered a fully trusted entity with sufficient computational and communication resources, and is responsible for system initialization and the registration of the LD and MDs. After registration, it does not participate in the AKA phase but knows the real identities of all entities. The LD possesses stronger computational and communication resources than ordinary member drones and is responsible for commanding, scheduling, and controlling its subordinate drone swarm. The LD initiates the AKA protocol to establish secure communication channels with the member drone cluster. The MDs are equipped with sensors (e.g., cameras, radar, gas sensors) to perform environmental perception and data collection tasks according to the LD’s instructions. They encrypt the collected data using the session key before transmission to the LD. However, their computational power and storage space are limited.
Threat Model
In the proposed protocol, we adopt the widely used Dolev-Yao (DY) adversary model. The adversary $\mathcal{A}$ is a probabilistic polynomial-time entity whose goal is to obtain the legitimate session key generated after protocol execution or to impersonate a legitimate UAV drone to send forged messages to others. $\mathcal{A}$ is powerful and has complete control over the public communication channel. It can eavesdrop on, intercept, replay, delete, or tamper with communication messages over the public channel. Furthermore, it can obtain the session state information, session key, or long-term private key of a session instance $\Pi^*$. The GS is a fully trusted entity, and all secret parameters stored on it cannot be obtained by $\mathcal{A}$. The other two entities (LD and MDs) are considered untrustworthy; $\mathcal{A}$ can obtain their long-term credentials through physical capture attacks and power analysis and then use these long-term secrets for identity impersonation.
The Proposed Protocol
This section details a lightweight one-to-many batch authentication and key agreement protocol designed for UAV drone swarms. The protocol is constructed based on the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement mechanism, utilizing the participants’ public keys for identity authentication. To enhance security, hashed secret values are embedded in authentication messages to resist key-compromise impersonation attacks effectively. The message generation process incorporates a random number and timestamp joint mechanism to ensure dynamic randomness for each session interaction, avoiding potential vulnerabilities from fixed parameters. Simultaneously, one-way hash functions protect static parameters, preventing their exposure in plaintext over the communication channel. This design collectively ensures the untraceability of the protocol, making it impossible for external adversaries to correlate communication entities across different sessions. The proposed protocol consists of five phases: System Initialization, Leader Drone Registration, Member Drone Registration, Authentication and Key Agreement (AKA), and Identity Update. The notations used are summarized in Table 1.
| Symbol | Description |
|---|---|
| $h_i(\cdot) (i \in \{1,2,3,4,5,6\})$ | Cryptographic hash functions |
| $LID$ | Real identity of the Leader Drone (LD) |
| $MID_j (j \in [1, n])$ | Real identity of the $j^{th}$ Member Drone (MD) |
| $TLID, TMID_j$ | Temporary identities of LD and the $j^{th}$ MD |
| $s, PK$ | Private and public keys of the Ground Station (GS) |
| $HLID$ | Pseudo-identity of the LD |
| $r_i, r_{LD}, r_{MD_j}, y_j, m_j$ | Random numbers |
| $SK_{ij}$ | Session key between LD and the $j^{th}$ MD |
| $ENC(K, \cdot)/DEC(K, \cdot)$ | Symmetric encryption/decryption with key $K$ |
| $G$ | Additive cyclic group of order $q$ |
| $P$ | Generator (base point) of group $G$ |
| $\sigma_j$ | Signature generated by $MD_j$ |
| $TS_{LD}, TS_j$ | Timestamps |
| $\Delta t$ | Maximum transmission delay |
| $\oplus, ||$ | Bitwise XOR and concatenation operations |
| $*$ | Elliptic curve scalar multiplication |
System Initialization Phase
This phase is executed only once by the GS, which generates and publishes the system parameters. The GS selects a non-singular elliptic curve $E(a, b)$ defined over a finite field $\mathbb{F}_p$. It then chooses a cyclic subgroup $G$ of $E(a, b)$ generated by a base point $P$ of order $q$, a large prime. Next, the GS selects six secure one-way hash functions: $h_1: \{0,1\}^* \rightarrow \mathbb{Z}_q^*$, $h_2: \{0,1\}^* \rightarrow G$, $h_3: \{0,1\}^* \rightarrow \{0,1\}^*$, $h_4: \{0,1\}^* \times \{0,1\}^* \times G \times \{0,1\}^* \rightarrow \{0,1\}^*$, $h_5: \{0,1\}^* \times \{0,1\}^* \times G \rightarrow \{0,1\}^*$, $h_6: \{0,1\}^* \times \{0,1\}^* \times G \rightarrow \{0,1\}^*$. The GS randomly selects a private key $s \in \mathbb{Z}_q^*$, computes the public key $PK = sP$, and chooses a symmetric encryption/decryption algorithm $(ENC(\cdot)/DEC(\cdot))$. Finally, the GS secretly stores $s$ and publishes the system parameters: $\{E, p, q, a, b, P, G, PK, h_1, h_2, h_3, h_4, h_5, h_6, ENC(\cdot), DEC(\cdot)\}$.
Leader Drone Registration Phase
All UAV drones must register with the GS before mutual communication. After this phase, the LD obtains its pseudo-identity, and the GS records its real identity. Symmetric encryption is used to ensure secure data transmission during registration over an open channel.
- The LD selects a random number $r_{LD}$ and a temporary identity $TLID$. It computes $Z_1 = h_1(TLID || r_{LD})P$ and the symmetric encryption key $K_{LG} = h_1(TLID || r_{LD})PK$. It then encrypts its temporary identity $E_1 = ENC(K_{LG}, TLID)$ and sends $\{Z_1, E_1\}$ to the GS.
- Upon receipt, the GS computes the key $K_{LG} = Z_1 * s$, decrypts $E_1$ to get $TLID$. The GS then selects a random number $x_{LD} \in \mathbb{Z}_q^*$, a common random number $x \in \{0,1\}^*$, and a real identity $LID \in \{0,1\}^*$. It computes the pseudo-identity $HLID = h_1(LID || x)$ and $A_1 = x \oplus LID$. The GS then generates ciphertext $E_2 = ENC(K_{LG}, LID || HLID || A_1)$, stores $(HLID, LID, x)$ in its database, and sends $\{E_2, TLID\}$ back to the LD.
- The LD checks if the received $TLID$ matches its own. If it does, it decrypts $E_2$ to obtain $(LID || HLID || A_1) = DEC(K_{LG}, E_2)$ and securely stores $(LID, HLID, A_1)$.
Member Drone Registration Phase
Similar to the LD, each Member Drone $MD_j$ registers with the GS to obtain a private key for signing its messages.
- $MD_j$ selects a random number $r_{MD_j}$ and a temporary identity $TMID_j$. It computes $Z_1 = h_1(TMID_j || r_{MD_j})P$, $K_{MG} = h_1(TMID_j || r_{MD_j})PK$, and $E_1 = ENC(K_{MG}, TMID_j)$. It sends $\{Z_1, E_1\}$ to the GS.
- The GS computes $K_{MG} = Z_1 * s$ and decrypts $E_1$ to get $TMID_j$. If $MD_j$ is already registered, the request is rejected. Otherwise, the GS selects a random number $m_j \in \mathbb{Z}_q^*$ and a real identity $MID_j \in \{0,1\}^*$. It computes $N_j = m_jP$ and a private key $d_j = (m_j + h_2(HLID || N_j) * s) \mod q$. The GS then generates ciphertext $E_2 = ENC(K_{MG}, HLID || N_j || d_j || B_1)$, where $B_1 = x \oplus MID_j$. It stores $MID_j$ and sends $\{E_2, TMID_j\}$ to $MD_j$.
- $MD_j$ verifies the received $TMID_j$. If correct, it decrypts $E_2$ to get $(HLID || N_j || d_j || B_1) = DEC(K_{MG}, E_2)$ and stores $(B_1, N_j, d_j)$ securely.
Authentication and Key Agreement (AKA) Phase
This phase aims to mutually authenticate the identities of the LD and $MD_j$ via a public channel, verify the authenticity of signatures, and establish unique session keys. Given the LD’s role, it knows the identities of all drones. Due to the high mobility of UAV drones, entities frequently disconnect and reconnect, making batch authentication crucial. The detailed steps are as follows and summarized in Figure 2.
- LD Initiation: The LD, as the initiator, selects a random number $r_i \in \mathbb{Z}_q^*$, computes $R_i = r_iP$. It retrieves $x = LID \oplus A_1$. It then computes $M_1 = h_3(HLID || x) \oplus R_i$, generates a timestamp $TS_{LD}$, and computes a verification parameter $V_1 = h_4(R_i || x || M_1 || TS_{LD})$. Finally, the LD broadcasts the message $msg1 = \{V_1, M_1, HLID, TS_{LD}\}$.
- MD Authentication of LD: Upon receiving $msg1$, $MD_j$ first checks the freshness of $TS_{LD}$. It then computes $x = B_1 \oplus HLID$ and retrieves $R_i = M_1 \oplus h_3(HLID || x)$. Next, it computes $V_1′ = h_4(R_i || x || M_1 || TS_{LD})$ and checks if $V_1′ \stackrel{?}{=} V_1$. If not equal, the session is terminated. Otherwise, $MD_j$ successfully authenticates the LD.
- MD Response: After authenticating the LD, $MD_j$ selects a random number $y_j \in \mathbb{Z}_q^*$, computes $Y_j = y_jP$, and generates a timestamp $TS_j$. It then computes a temporary session key $SK_{ji} = h_5(y_j R_i || HLID || MID_j)$. Next, it computes $\alpha_j = h_6(SK_{ji} || TS_j || R_i)$, $M_{2j} = h_3(HLID || x) \oplus Y_j$, and a signature $\sigma_j = (d_j + \alpha_j * y_j) \mod q$. $MD_j$ sends the response message $msg2_j = \{M_{2j}, N_j, \sigma_j, TS_j\}$ back to the LD.
- LD Batch Verification and Key Agreement: Upon receiving multiple $msg2_j$ responses, the LD first checks the freshness of each $TS_j$. For each $MD_j$, it computes $Y_j = M_{2j} \oplus h_3(HLID || x)$ and the session key $SK_{ij} = h_5(r_i Y_j || HLID || MID_j)$. It then computes $\alpha_j = h_6(SK_{ij} || TS_j || R_i)$. To perform efficient batch verification of all received signatures, the LD uses the small exponent test technique. It generates a vector of small random integers $\vec{u} = \{u_1, u_2, …, u_n\}$ where $u_j \in [1, 2^t]$. The LD verifies the validity of the following equation to accept the batch of messages:
$$\sum_{j=1}^{n} (u_j * \sigma_j)P \stackrel{?}{=} \sum_{j=1}^{n} (u_j * N_j) + \sum_{j=1}^{n} (u_j * h_2(HLID || N_j))PK + \sum_{j=1}^{n} (u_j * \alpha_j * Y_j).$$
If the equation holds, the batch is accepted, and $SK_{ij} = SK_{ji}$. If the batch verification fails, a binary search algorithm can be employed to efficiently identify and discard invalid signatures without verifying each one individually.
Identity Update Phase
To prevent credential leakage attacks due to potential long-term exposure or cryptanalysis, this phase allows entities to periodically update their identities with the GS’s assistance. The process for the LD is described below (similar for MDs). The LD initiates the update by sending an encrypted request with a new random number to the GS. The GS verifies the LD’s current identity, generates new random parameters and a new pseudo-identity $NHLID$, encrypts them, and sends them back. The LD decrypts the message and replaces its old credentials $(HLID, A_1)$ with the new ones $(NHLID, NA_1)$. The GS also updates its database accordingly.
Security Analysis
Formal Security Analysis under the ROR Model
We adopt the Real-Or-Random (ROR) model for formal security analysis. The semantic security of the session key is proven based on the BRP2000 and Bresson models. The adversary $\mathcal{A}$ can perform various queries: $Hash(m)$, $Execute(\Pi^*)$, $Send(\Pi^*, Msg)$, $Reveal(\Pi^*)$, $CorruptLD(\Pi_{LD}^u)$, $CorruptMD(\Pi_{MD_j}^v)$, and $Test(\Pi^*)$. $\mathcal{A}$’s advantage in breaking the semantic security of the session key in the proposed protocol $\mathcal{P}$ is defined as $Adv_{\mathcal{A}}^{AKA}(t) = |2 \cdot Pr[Succ] – 1|$.
Theorem 1: Let $\mathcal{A}$ be an adversary running in polynomial time $t$ against the proposed protocol $\mathcal{P}$. The advantage of $\mathcal{A}$ in breaking the semantic security of the session key is:
$$Adv_{\mathcal{A}}^{AKA}(t) \leq \frac{q_h^2}{2|Hash|} + \frac{(q_s + q_e)^2}{2p} + \frac{q_s}{|Hash|} + \sum_{i=1}^{6} (q_{h_i} \cdot Adv^{CDH}(t)),$$
where $q_h$, $q_s$, $q_e$ represent the maximum number of hash, send, and execute queries, respectively; $|Hash|$ is the range space of the hash function; and $Adv^{CDH}(t)$ is the advantage in solving the ECCDH problem.
Proof Sketch: The proof is constructed using a sequence of games, $G_0$ to $G_5$. $G_0$ is the real attack game. $G_1$ simulates eavesdropping via $Execute$ queries, but the eavesdropped messages do not help compute the session key $SK_{ij}=h_5(r_i Y_j || HLID || MID_j)$. $G_2$ adds $Send$ and $Hash$ queries, and the probability difference from $G_1$ is bounded by the birthday paradox due to potential hash collisions. $G_3$ accounts for the adversary forging a valid authentication message without making the corresponding hash query. $G_4$ simulates physical capture attacks ($Corrupt$ queries). Even with long-term secrets $(A_1, HLID)$ or $(B_1, N_j, d_j)$, the adversary cannot derive the ephemeral random numbers or the specific $MID_j$ to compute $SK$. $G_5$ reduces the security to the hardness of the ECCDH problem. If the adversary could distinguish the session key from random without solving ECCDH, we could construct an algorithm to solve the ECCDH instance $(P, aP, bP)$ by embedding it into the protocol simulation. The final advantage is derived by combining the bounds from all game transitions, concluding that $Adv_{\mathcal{A}}^{AKA}(t)$ is negligible if the ECCDH problem is hard, thus proving the protocol’s semantic security. $$\tag*{$\blacksquare$}$$
Automated Verification using ProVerif
We further analyzed the protocol using the automated cryptographic protocol verifier ProVerif (version 2.05) under the Dolev-Yao model. The protocol processes for the LD and MD were formally modeled using ProVerif’s process calculus. Key security properties were specified as queries:
- Secrecy of session key: `query attacker(SessionKey)`.
- Secrecy of ephemeral/private values: `weaksecret ri`, `weaksecret yj`, `weaksecret MIDj`.
- Mutual authentication events: `event(LDAuthenticated) ==> event(MDStart)` and `event(MDAuthenticated) ==> event(LDStart)`.
The ProVerif verification results, as shown in Figure 4, confirm that all specified queries are satisfied. The tool reports that the secret values ($r_i$, $y_j$, $MID_j$) are not derivable by the attacker, the session key (`SessionKey`) remains secret, and the mutual authentication events hold. This provides strong automated evidence that our protocol resists active and passive attacks within its formal model.
Informal Security Analysis
We now provide a heuristic analysis of the security properties achieved by our protocol, comparing its resilience against common attacks with five related schemes [22-26] in Table 2.
| Property/Attack | IBA[22] | SMA[23] | SAA[24] | UAK[25] | BKA[26] | Ours |
|---|---|---|---|---|---|---|
| P1: Mutual Authentication | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| P2: Anonymity | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| P3: Untraceability | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| P4: Conditional Privacy | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ |
| P5: Trusted Entity Offline in AKA | ✓ | ✗ | ✗ | ✗ | ✗ | ✓ |
| P6: Forward Secrecy | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ |
| P7: Identity/Secret Update | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ |
| P8: Formal Verification | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| S1: Impersonation Attack | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| S2: Replay Attack | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| S3: Man-in-the-Middle Attack | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| S4: Known Session Key Attack | ✗ | ✓ | ✗ | ✓ | ✓ | ✓ |
| S5: Key-Compromise Impersonation | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ |
Key Security Attributes:
Mutual Authentication: Achieved through the verification of $V_1$ by MDs and the batch verification of signatures $\sigma_j$ by the LD.
Anonymity & Untraceability: Real identities ($LID$, $MID_j$) are never transmitted. Pseudo-identity $HLID$ is used, and all messages incorporate fresh random numbers and timestamps, making different sessions unlinkable.
Conditional Privacy & Trusted Entity Offline: The fully trusted GS knows the real identity mapping but is offline during AKA, reducing its attack surface. If a drone misbehaves, the GS can revoke it.
Session Key Security & Forward Secrecy: The session key $SK_{ij}=h_5(r_i Y_j || HLID || MID_j)$ depends on ephemeral secrets $r_i$ and $y_j$. Compromising long-term secrets does not reveal past session keys.
Resistance to Attacks: The protocol resists impersonation, replay, and man-in-the-middle attacks due to the use of timestamps, hashed secret values, and signatures. It resists known session key attacks because deriving $r_i$ or $y_j$ from $SK_{ij}$ is infeasible due to the one-way hash and ECDHP. It resists key-compromise impersonation (KCI) attacks because even with $LD$’s long-term secret $A_1$, an adversary cannot generate a valid signature $\sigma_j$ without $MD_j$’s private key $d_j$.
Performance Evaluation
Computational Overhead Analysis
We compare the computational cost of our protocol with five related schemes [22-26] during their AKA phase. The execution times of cryptographic operations, measured using OpenSSL and PBC libraries on a standard PC, are listed in Table 3.
| Operation | Description | Time (ms) |
|---|---|---|
| $T_{Ga}$ | Elliptic curve point addition | 0.0017 |
| $T_{Gm}$ | Elliptic curve scalar multiplication | 0.6297 |
| $T_h$ | Hash function operation | 0.0006 |
| $T_{E/D}$ | Symmetric encryption/decryption | 0.0057 |
| $T_{fe}$ | Fuzzy extractor operation (≈ $T_{Gm}$) | 0.6297 |
| $T_{bp}$ | Bilinear pairing operation | 5.5706 |
| $T_{ch}$ | Chebyshev polynomial computation | 0.8242 |
The total computational cost for establishing $n$ session keys (i.e., authenticating $n$ member UAV drones) for each scheme is derived and summarized in Table 4.
| Scheme | Total Computational Cost |
|---|---|
| IBAAS [22] | $(9n+10)T_{Gm} + 3T_{Ga} + T_{bp}$ |
| SMAKA [23] | $(22n+4)T_h + (5n+3)T_{Gm} + 2nT_{E/D}$ |
| SAAF-IoD [24] | $(11n+2)T_h + 5nT_{ch} + (6n+1)T_{fe} + T_{E/D}$ |
| UAKMS-NIB [25] | $(24n+8)T_h + 13nT_{Gm} + 3T_{Ga} + T_{fe}$ |
| BioKA-ASVN [26] | $(27n+6)T_h + 9nT_{Gm} + 3T_{Ga} + T_{fe}$ |
| Ours | $(9n+2)T_h + (4n+1)T_{Gm} + 2nT_{Ga}$ |
Figure 5 plots the total time cost against the number of devices $n$. For a single session ($n=1$), the costs are relatively close. However, as $n$ increases, the advantage of our lightweight batch protocol becomes pronounced. Our protocol avoids expensive operations like bilinear pairings ($T_{bp}$), Chebyshev polynomials ($T_{ch}$), and symmetric encryption in the AKA phase, relying instead on efficient hash functions and elliptic curve operations. This results in significantly lower computational overhead for authenticating a swarm of UAV drones.
Communication Overhead Analysis
We estimate the communication cost based on standard parameter sizes: $|G|$ = 1024 bits (Elliptic curve point), $|ID|$ = 256 bits, $|H|$ = 256 bits (Hash output), $|Z_q^*|$ = 128 bits (Random number), $|T|$ = 32 bits (Timestamp). The total communication overhead for establishing $n$ session keys is summarized in Table 5.
| Scheme | Total Communication Overhead (bits) |
|---|---|
| IBAAS [22] | $4n|G| + 3n|Z_q^*| + 2n|T|$ |
| SMAKA [23] | $(2n+1)|G| + (6n+1)|H| + (4n+1)|ID| + (5n+1)|T|$ |
| SAAF-IoD [24] | $2n|C| + 5n|H| + 2n|ID| + 3n|T|$ |
| UAKMS-NIB [25] | $3n|G| + 9n|H| + 5n|ID| + 5n|T|$ |
| BioKA-ASVN [26] | $2n|G| + 10n|H| + n|Z_q^*| + 7n|T|$ |
| Ours | $(2n+1)|G| + (n+1)|H| + n|Z_q^*| + (n+1)|T|$ |
The comparison of total communication overhead for varying $n$ is shown in Figure 6. For a single session, costs are comparable. However, for批量认证 of multiple UAV drones, our protocol demonstrates superior efficiency. A detailed comparison for $n=30$ (Figure 7) shows our protocol incurs an overhead of 67,680 bits, which is approximately 50.4%, 53.2%, 6.0%, 66.9%, and 54.5% lower than the schemes in [22], [23], [24], [25], and [26], respectively. This significant reduction is primarily because our protocol transmits fewer parameters per drone during the AKA phase (mainly $M_{2j}$, $N_j$, $\sigma_j$, $TS_j$) and uses a single broadcast message from the LD to initiate authentication with all drones.
Security and Functionality Summary
As evidenced by Table 2, our protocol not only achieves lower computational and communication overhead but also provides a more comprehensive set of security properties and functionalities compared to the related schemes. It uniquely offers all the following: mutual authentication, anonymity, untraceability, conditional privacy preservation, trusted entity being offline during AKA, perfect forward secrecy, support for identity/secret update, formal security proof (ROM), automated verification (ProVerif), and resistance to key-compromise impersonation attacks. This makes it particularly suitable for secure and efficient large-scale deployments of UAV drones in IoD applications.
Conclusion
Collaborative operations using UAV drone swarms have become an important trend, bringing to the forefront concerns regarding data transmission security and efficiency. This paper proposed a lightweight batch authentication and key agreement protocol designed for the Internet of Drones environment. The protocol aims to efficiently achieve identity authentication and key agreement within a drone cluster. It supports secure registration of UAV drones over a public channel, enhancing flexibility. Its security is based on the computational hardness of the Elliptic Curve Discrete Logarithm Problem and the Elliptic Curve Diffie-Hellman Problem. Formal security analysis under the Random Oracle Model and automated verification using the ProVerif tool demonstrate that the protocol achieves semantic security and meets relevant security evaluation criteria. Performance comparisons with existing state-of-the-art schemes show that the proposed protocol has significantly lower computational and communication overhead, especially when authenticating a large number of UAV drones, while providing a richer set of security features and functionalities.
Future work could explore extending the protocol to scenarios involving multiple semi-trusted leader drones or to three-party key agreement settings for more complex hierarchical drone swarm architectures. Additionally, investigating integration with intrusion detection systems for UAV drone networks could further enhance the overall security posture.