The rapid evolution of Unmanned Aerial Vehicle (UAV) technology has unlocked transformative applications across military reconnaissance, emergency response, precision agriculture, and logistics. A key operational paradigm emerging for these unmanned drone systems is the execution of missions that span multiple administrative or geographical domains. This cross-domain capability enhances mission flexibility and coverage but introduces a critical security challenge: how to ensure secure, efficient, and trustworthy mutual authentication when an unmanned drone from one domain needs to access services or communicate within a foreign, potentially untrusted, domain. Traditional authentication schemes often rely heavily on centralized third-party key authorities, creating single points of failure and trust bottlenecks. Furthermore, many proposed solutions employ computationally intensive cryptographic primitives, making them unsuitable for the resource-constrained processors and limited energy budgets typical of unmanned drone platforms. There is a clear and pressing need for a lightweight, decentralized, and privacy-preserving authentication mechanism tailored for the dynamic and resource-scarce environment of cross-domain unmanned drone operations.
To address these challenges, I propose a novel lightweight cross-domain identity authentication scheme for unmanned drone networks that synergistically integrates dynamic pseudonyms with consortium blockchain technology. The core innovation lies in decoupling the drone’s persistent identity from its operational identifiers. Instead of using a static credential, each unmanned drone is provisioned with cryptographically generated, frequently changing pseudonyms. This dynamic pseudonym mechanism fundamentally enhances privacy and system resilience against tracking and identity forgery attacks. Crucially, to eliminate dependence on a centralized trust anchor, a permissioned blockchain network is established among participating domain authorities (Ground Control Units – GCUs). This blockchain serves as an immutable, decentralized ledger for managing drone public keys, pseudonym seeds, and revocation lists, enabling transparent and verifiable trust across domains. The authentication protocol itself is designed using lightweight Elliptic Curve Cryptography (ECC), minimizing computational overhead on the unmanned drone. The security of the proposed protocol is rigorously analyzed using formal methods, including BAN logic and the automated tool ProVerif, proving its resilience against common threats like impersonation, replay, and man-in-the-middle attacks. A comprehensive performance evaluation demonstrates significant advantages: the scheme reduces computational overhead by approximately 55.6% to 87.7% compared to contemporary solutions, maintains low communication (288 bytes) and storage (120 bytes) footprints, and leverages blockchain for efficient, trustless cross-domain verification. This work presents a holistic solution that balances strong security, operational privacy, and practical efficiency, making it highly suitable for the next generation of mobile, cross-domain unmanned drone applications.
1. Preliminaries and System Design
The proposed scheme is built upon well-established cryptographic primitives and a decentralized architecture. The security and efficiency of the authentication process hinge on the proper integration of these components.
1.1 Cryptographic Foundations
The scheme utilizes the Elliptic Curve Digital Signature Algorithm (ECDSA) for digital signatures and key generation. ECDSA offers a high level of security with relatively short key lengths, which is ideal for unmanned drone platforms. Let \(E\) be an elliptic curve defined over a finite field \(\mathbb{F}_p\), with a base point \(G\) of prime order \(n\). A private key is a randomly selected integer \(d_A\) in \([1, n-1]\), and the corresponding public key is the curve point \(Q_A = d_A \cdot G\). Signing and verification follow the standard ECDSA process. Furthermore, secure cryptographic hash functions (e.g., modeled as \(H_1, H_2, H_3, H_4\)) are employed for various operations such as key derivation and pseudonym generation.
The second foundational pillar is the immutability property of blockchain. A blockchain is a distributed, append-only ledger consisting of blocks linked via cryptographic hashes. Each block contains a batch of transactions, a timestamp, and the hash of the previous block. This structure, maintained through a consensus mechanism among participating nodes, ensures that once data is recorded, it cannot be altered retroactively without altering all subsequent blocks and colluding with the majority of the network. This property is leveraged to create a tamper-proof record for unmanned drone public credentials and revocation status.
1.2 System Model and Threat Assumptions
The system architecture comprises four core entities: the Consortium Blockchain Network, the Ground Control Unit (GCU), the Communication Unit, and the Unmanned Drone. The GCU acts as the domain authority, managing drones within its jurisdiction. The blockchain network, formed by GCUs from different domains, provides a shared, trusted platform for cross-domain identity management.
For security analysis, the protocol is examined under the Dolev-Yao adversarial model. In this model, the adversary \(\mathcal{A}\) has complete control over the communication network. \(\mathcal{A}\) can eavesdrop on, intercept, modify, delete, or inject arbitrary messages. However, \(\mathcal{A}\) is bound by computational limits and cannot break the underlying cryptographic primitives (i.e., hash functions are collision-resistant, ECDSA is secure). The primary security goals are to prevent:
1. Identity Impersonation: \(\mathcal{A}\) cannot successfully masquerade as a legitimate unmanned drone or GCU.
2. Replay Attacks: \(\mathcal{A}\) cannot reuse old messages from a previous session to gain unauthorized access.
3. Man-in-the-Middle (MitM) Attacks: \(\mathcal{A}\) cannot establish separate sessions with the drone and GCU while making them believe they are communicating directly.
4. Session Key Disclosure: \(\mathcal{A}\) cannot compute or learn the negotiated session key.
The system security is based on the following assumptions: the consortium blockchain platform is trusted and operates correctly; the ledger is immutable; smart contracts (chaincode) execute as programmed; all entities possess the necessary computational capability for lightweight ECC operations; and the adversary cannot compromise the mathematical security of the cryptographic algorithms.
2. The Proposed Cross-Domain Authentication Scheme
The proposed protocol is executed in five distinct phases: System Initialization, Unmanned Drone Registration, Pseudonym Material Generation & Distribution, Cross-Domain Authentication, and Unmanned Drone Revocation. Table 1 summarizes the key notations used throughout the protocol description.
| Symbol | Description |
|---|---|
| \(D_{id}\) | Domain Identifier |
| \(RID_i\) | Real Identity of Drone \(i\) |
| \(dsk_i / Dpk_i\) | Private/Public Key Pair of Drone \(i\) |
| \(SID_i\) | Pseudonym Material for Drone \(i\) |
| \(PID_i\) | Dynamic Pseudonym for Drone \(i\) |
| \(H_1, H_2, H_3, H_4\) | Cryptographic Hash Functions |
| \(p, G, n, G\) | ECC Domain Parameters (prime, group, order, generator) |
| \(T_{reg}, T_{auth}\) | Registration and Authentication Timestamps |
| \(gsk_{B} / Gpk_{B}\) | Private/Public Key Pair of GCU in Domain B |
2.1 Phase 1: System Initialization
The system parameters are globally defined and embedded in the blockchain’s genesis block. These include the elliptic curve parameters \((p, E, G, n)\), the set of hash functions \(\{H_1, H_2, H_3, H_4\}\), and the initial list of trusted GCU public keys. Each GCU, say \(GU_A\), generates its long-term ECDSA key pair \((gsk_A, Gpk_A)\). The public key \(Gpk_A\) is published and recorded on the blockchain. This establishes a decentralized trust root, where the validity of a GCU is verified by checking its presence and status on the immutable ledger, rather than querying a central certificate authority.
2.2 Phase 2: Unmanned Drone Registration
When a new unmanned drone \(Dr_A\) manufactured with a unique hardware identity \(RID_A\) joins a domain (e.g., Domain A), it must register with its local GCU (\(GU_A\)). The drone submits its \(RID_A\) to \(GU_A\). Upon verifying the drone’s legitimacy, \(GU_A\) performs the following steps:
1. Generate a random nonce \(a\) and get the current timestamp \(T_{reg}\).
2. Compute the drone’s private key: \(dsk_A = H_1(a \parallel RID_A \parallel T_{reg})\).
3. Compute the corresponding public key: \(Dpk_A = dsk_A \cdot G\).
4. Generate a secret parameter \(x_i\) and compute \(X_i = x_i \cdot G\).
5. Store the tuple \(\{RID_A, dsk_A, Dpk_A, T_{reg}, seed_1\}\) securely locally as the drone’s registration proof.
6. Upload the drone’s license \(\{D_{id}^A, Dpk_A, X_i, T_{reg}\}\) to the blockchain.
This phase ensures the initial identity binding and makes the drone’s public credential globally verifiable via the blockchain.
2.3 Phase 3: Pseudonym Material Generation & Distribution
To provide anonymity and unlinkability across different sessions, \(GU_A\) generates and distributes pseudonym materials to the unmanned drone. \(GU_A\) first generates a set of random seeds \(\{seed_1, seed_2, …, seed_k\}\). For each seed, a hash chain is pre-computed: \(h^n(seed_i) \leftarrow h^{n-1}(seed_i) \leftarrow … \leftarrow h^1(seed_i) \leftarrow seed_i\). A combined key for batch \(k\) is derived as \(e_k = \sum_{i=1}^{k} h^1(seed_i) \mod n\).
When the drone \(Dr_A\) needs pseudonym material, it sends a request \(D_{req} = \{D_{id}^A, Dpk_A, T_{req}\}\) along with a signature proof \(\alpha_i = dsk_A + x_i \cdot H_3(Gpk_A \parallel h_i)\). \(GU_A\) retrieves the drone’s license from the blockchain, extracts \(X_i\), and verifies the proof by checking \(\alpha_i \cdot G \stackrel{?}{=} Dpk_A + X_i \cdot H_3(Gpk_A \parallel D_{req})\). If valid, \(GU_A\) generates the pseudonym material: \(SID_i = RID_A \oplus H_2(e_k \cdot T_{res})\), where \(T_{res}\) is the current timestamp. \(GU_A\) sends \(\{SID_i, T_{res}\}\) to the drone and records a hash of the pseudonym material along with the drone’s public key on the blockchain. The seed \(seed_i\) allows \(GU_A\) to later revoke this specific batch of pseudonyms.
2.4 Phase 4: Cross-Domain Authentication & Key Agreement
This is the core phase where an unmanned drone \(Dr_A\) from Domain A authenticates itself to a GCU \(GU_B\) in a target Domain B. The process, also illustrated in the textual flowchart description, involves the following steps:
Step 1 (Authentication Request): \(Dr_A\) generates a dynamic pseudonym for the session. It chooses a random nonce \(l_{ik}\) and computes \(L_{ik} = l_{ik} \cdot G\). It then constructs its pseudonym \(PID_i = \{L_{ik}, SID_i, T_{res}\}\). \(Dr_A\) generates a random number \(N_d\) and current timestamp \(T_{auth}^i\). It computes a signature \(y = l_{ik} + dsk_A \cdot H_3(PID_i \parallel M \parallel T_{auth}^i)\), where \(M\) is a context message. Finally, \(Dr_A\) sends the authentication request message \(Msg_1 = \{D_{id}^A, PID_i, L_{ik}, M, y, T_{auth}^i, N_d\}\) to \(GU_B\).
Step 2 (Authentication Verification): Upon receiving \(Msg_1\), \(GU_B\) performs the following checks:
1. Validate the freshness using \(T_{auth}^i\).
2. Query the blockchain using \(D_{id}^A\) to retrieve \(Dr_A\)’s public key \(Dpk_A\) and the hashed pseudonym material.
3. Verify the signature by checking: $$y \cdot G \stackrel{?}{=} L_{ik} + Dpk_A \cdot H_3(PID_i \parallel M \parallel T_{auth}^i)$$
If the equation holds, the unmanned drone is successfully authenticated. \(GU_B\) then generates a random number \(N_g\) and creates a signed response to prove its own authenticity. It computes \(y_{reply} = gsk_B \cdot H_3(M_Y \parallel T_{rep})\) where \(M_Y\) is a “success” message and \(T_{rep}\) is a new timestamp. \(GU_B\) sends the response \(Msg_2 = \{M_Y, T_{rep}, N_d+1, N_g, y_{reply}\}\) back to \(Dr_A\).
Step 3 (GCU Verification & Session Key Establishment): \(Dr_A\) verifies \(Msg_2\) by checking the incremented nonce \(N_d+1\) and validating \(GU_B\)’s signature: $$y_{reply} \cdot G \stackrel{?}{=} Gpk_B \cdot H_3(M_Y \parallel T_{rep})$$
Upon successful verification, mutual authentication is complete. Both parties now compute the same session key using the exchanged random nonces: $$SK = H_4(N_g \parallel N_d)$$
To confirm key synchronization, a classic challenge-response using the new key can be performed (e.g., encrypt a nonce with \(SK\)). This lightweight key provides confidentiality and integrity for subsequent communications between the unmanned drone and Domain B’s infrastructure.
2.5 Phase 5: Unmanned Drone Revocation
If a drone’s operational period expires or it is reported as compromised/rogue, its associated GCU can revoke its identity. The GCU simply retrieves the specific seed \(seed_i\) linked to that drone’s current pseudonym batch and submits a transaction to the blockchain, adding that seed’s identifier to a public revocation list. Any other GCU can then check this list during authentication. Since future pseudonyms for that drone depend on the revoked seed or its hash chain, the drone can no longer generate valid credentials, effectively and instantly revoking its access across all domains without needing to contact each domain individually.
3. Formal Security Analysis
To rigorously evaluate the security claims, the proposed protocol is analyzed using two formal methods: BAN logic for belief-based analysis and the automated protocol verifier ProVerif.
3.1 BAN Logic Analysis
BAN logic is used to prove the mutual authentication and key agreement properties. The analysis involves idealizing the messages, stating initial assumptions (A), defining security goals (G), and applying logical postulates to derive the goals. Key BAN logic symbols and rules used are listed below.
| Notation | Meaning | Rule Name | Rule Form |
|---|---|---|---|
| \(P \mid\equiv X\) | P believes X | Message-Meaning | \(\frac{P \mid\equiv Q \stackrel{K}{\longleftrightarrow} P, \quad P \triangleleft \{X\}_K}{P \mid\equiv Q \mid\sim X}\) |
| \(P \triangleleft X\) | P sees X | Nonce-Verification | \(\frac{P \mid\equiv \#(X), \quad P \mid\equiv Q \mid\sim X}{P \mid\equiv Q \mid\equiv X}\) |
| \(P \mid\sim X\) | P once said X | Jurisdiction | \(\frac{P \mid\equiv Q \Rightarrow X, \quad P \mid\equiv Q \mid\equiv X}{P \mid\equiv X}\) |
| \(\#(X)\) | X is fresh | Freshness | \(\frac{P \mid\equiv \#(X)}{P \mid\equiv \#(X,Y)}\) |
| \(P \stackrel{K}{\longleftrightarrow} Q\) | P and Q share K | ||
| \(\{X\}_K\) | X encrypted under K |
The primary goals for the cross-domain authentication phase between unmanned drone \(Dr\) and GCU \(GU\) are:
– \(G1: GU \mid\equiv Dr \mid\sim AuthRequest\)
– \(G2: Dr \mid\equiv GU \mid\sim AuthResponse\)
– \(G3: Dr \mid\equiv GU \mid\equiv SK\)
– \(G4: GU \mid\equiv Dr \mid\equiv SK\)
– \(G5: Dr \mid\equiv Valid(PID)\)
Based on standard assumptions about belief in public keys, freshness of nonces, and jurisdiction, and applying the BAN logic rules sequentially to the idealized protocol messages, all five goals are successfully derived. This proves logically that the protocol achieves mutual belief in each other’s transmitted messages and in the shared session key \(SK\), and that the drone rightly believes in the validity of its pseudonym.
3.2 ProVerif Automated Verification
To complement the BAN logic analysis and check for more subtle attacks, the protocol was modeled in the Pi-calculus and verified using the ProVerif tool. Two main queries were defined: 1) the injective correspondence between authentication events, and 2) the secrecy of the session key \(SK\).
The ProVerif results confirm the security properties:
– For authentication: The event `event_GU_Authenticates_Drone` is true only if `event_Drone_Initiated_Auth` has occurred, proving injective agreement.
– For secrecy: The query `query attacker(sk[])` returns `false`, meaning the session key \(sk[]\) remains secret against the Dolev-Yao attacker.
These outputs from the ProVerif tool provide strong, automated evidence that the protocol is secure against impersonation, replay, and MitM attacks, and that it preserves the confidentiality of the negotiated session keys.
4. Performance Evaluation and Comparison
A comprehensive performance analysis is conducted, focusing on computational overhead, communication cost, storage requirements, and blockchain-specific metrics. The proposed scheme is compared with three recent and relevant authentication schemes for unmanned drone or IoT networks.
4.1 Computational Overhead Analysis
Computational cost is measured by the time required for cryptographic operations on a typical resource-constrained platform. Benchmark timings from established literature are used: Elliptic Curve Scalar Multiplication (\(T_{ecsm} = 0.556 ms\)), Point Addition (\(T_{ecpa} = 0.012 ms\)), Hash (\(T_h \approx 0.0003 ms\)), AES Encryption/Decryption (\(T_{enc}/T_{dec} \approx 0.035/0.035 ms\)), Bilinear Pairing (\(T_{bp} = 9.9 ms\)), Modular Inverse (\(T_{inv} = 0.15 ms\)). The total cost for the authentication and key agreement phases is calculated for each scheme.
| Scheme | Authentication Phase Cost | Key Agreement Cost | Total Cost (ms) |
|---|---|---|---|
| Scheme [A] | \(T_{bp} + 3T_{dec} + 3T_{enc} + 2T_h \approx 10.056\) | \(2(T_{enc}+T_{dec}+T_h) \approx 0.105\) | \(\approx 10.161\) |
| Scheme [B] | \(4T_{ecsm} + T_{dec} + 16T_h + T_{inv} + T_{enc} \approx 2.969\) | \(T_h \approx 0.0003\) | \(\approx 2.972\) |
| Scheme [C] | \(2T_{ecsm} + T_{enc} + T_{dec} + 4T_h \approx 1.704\) | \(2T_{ecsm} + 2T_h \approx 1.113\) | \(\approx 2.817\) |
| Proposed Scheme | \(2T_{ecsm} + 2T_{ecpa} + 3T_h \approx 1.146\) | \(2(T_h + T_{enc} + T_{dec}) \approx 0.105\) | \(\approx \mathbf{1.251}\) |
The proposed scheme demonstrates a significant reduction in computational overhead, approximately 55.6% to 87.7% lower than the compared schemes. This is primarily because it avoids expensive operations like bilinear pairings and uses a minimal number of ECC multiplications, making it highly suitable for the processing capabilities of an unmanned drone.
4.2 Communication and Storage Overhead
Communication cost is measured in total bytes transmitted during a full authentication and key agreement run. Storage overhead refers to the essential credentials a drone must persistently store. Standard sizes are assumed: Hash output (32B), ECC point (64B), Timestamp/Nonce (4B), AES block (32B), Identity (16B).
| Scheme | Total Communication (Bytes) | # of Messages | Storage on Drone (Bytes) |
|---|---|---|---|
| Scheme [A] | 444 | 3 | 283 |
| Scheme [B] | 1216 | 4 | 136 |
| Scheme [C] | 496 | 3 | 160 |
| Proposed Scheme | 288 | 3 | 120 |
The proposed scheme achieves the lowest communication overhead (288 bytes, 35-76% reduction) by employing a compact message structure with dynamic pseudonyms and ECDSA signatures. Its storage requirement (120 bytes) is also the smallest, as the unmanned drone only needs to store its private key, current pseudonym material, and session states, leveraging the blockchain for public credential storage.
4.3 Blockchain Performance Evaluation
A prototype was implemented using Hyperledger Fabric v2.4.9 with a Raft consensus mechanism. The performance of key blockchain operations—Upload License, Query License, and Update License (for revocation)—was benchmarked using the Caliper tool under varying transaction loads.
The results show that query operations, which are the most frequent during unmanned drone authentication, exhibit low latency (consistently below 20 ms) and high, scalable throughput. Write operations (Upload, Update) have higher latency and lower throughput, as expected due to consensus and ledger commitment overhead. However, since these writes occur infrequently (during drone registration or revocation), they do not impact the real-time performance of the cross-domain authentication process. The “read-heavy” nature of the authentication workflow aligns perfectly with the high-performance query capability of the permissioned blockchain, validating its practical feasibility for this use case.
5. Conclusion
This work presents a lightweight, secure, and practical cross-domain identity authentication scheme for unmanned drone networks. By innovatively combining dynamic pseudonyms with consortium blockchain technology, the scheme effectively addresses the critical triad of challenges: centralization dependency, high computational cost, and privacy vulnerability. The dynamic pseudonym mechanism provides robust anonymity and efficient revocation, while the blockchain establishes a decentralized, tamper-proof trust root that enables seamless verification across administrative boundaries. Formal security verification using BAN logic and ProVerif confirms the protocol’s resilience against impersonation, replay, and MitM attacks. Comprehensive performance evaluations demonstrate its superior efficiency, with significantly lower computational, communication, and storage overhead compared to state-of-the-art alternatives, making it particularly well-suited for resource-constrained unmanned drone platforms. The blockchain performance analysis further confirms the practicality of the approach for real-time, cross-domain operations. Future work will focus on optimizing the consensus mechanism for even lower latency in mobile ad-hoc unmanned drone swarm scenarios and investigating post-quantum cryptographic alternatives to ensure long-term security.