UAV Communication Security: A Narrative Review of Lightweight Authentication, ECC, and Hardware-Software Trade-Offs

1. Introduction

Unmanned aerial vehicle (UAV) networks connect mobile platforms to ground stations, peer aircraft, and Internet services. Surveys of UAV networking identify mobility, topology variation, and communication design as central concerns, while cellular integration extends the range of infrastructure and service relationships that a UAV may encounter [1,2]. For security, this means that identifying the communicating parties and their trust relationships is at least as important as selecting a cipher.

A secure telemetry channel, an authenticated command channel, a user-to-drone service session, and a peer-to-peer swarm link are different problems. They may have different credential authorities, availability requirements, and consequences of state loss. A security design that assumes an online trusted ground station cannot be treated as interchangeable with one that permits disconnected peer operation. Likewise, a calculation performed on a desktop processor is not automatically evidence of suitability for a constrained flight platform.

The literature includes hardware-rooted authentication, edge-assisted key agreement, and lightweight user-to-drone protocols, among other approaches [3,4,5]. ECC is frequently considered in this design space, but its role must be stated precisely. Digital signatures and key establishment are distinct services, with separate assumptions and implementation requirements [6,7]. Choosing a curve does not by itself specify how a peer is authenticated, how an application message is protected, or how an expired credential is revoked.

This review organizes UAV communication security around those distinctions. Its contributions are a layered taxonomy of security responsibilities, a structured comparison of representative authentication studies, an implementation-aware discussion of software and hardware options, and a reporting framework for future evaluations. The treatment retains lightweight cryptography and ECC as central topics while avoiding a claim that one primitive is universally preferable. It incorporates the 2025 Ascon standard and the 2024 NIST post-quantum standards as complementary, rather than interchangeable, mechanisms [8,9,10,11].

2. Review Approach and Evidence Boundaries

2.1. Scope and Source Selection

This is a focused narrative review, not a systematic review or meta-analysis. The starting corpus concerns UAV authentication, lightweight cryptography, and software/hardware implementation. It was supplemented during preparation by targeted searches for the named protocols, recent UAV authentication studies, and current official cryptographic specifications. Publisher pages, author-hosted publications, institutional repositories, NIST publications, and RFC Editor documents were consulted. The literature and standards update was completed on 23 September 2026.

Selection favored sources with a clearly identifiable communication setting, an explicit security mechanism, or direct relevance to implementation and evaluation. The recent illustrative studies span PUF-assisted authentication, infrastructure-assisted swarm authentication, and a Kyber-based proposal. Standards documents are used to establish terminology and specified cryptographic functions, not as evidence that a particular UAV deployment has been validated. Where a publication has a correction, the correction is cited with the original study.

The review does not claim database completeness, duplicate-independent screening, a preregistered search protocol, or a reproducible count of all eligible publications. No PRISMA flow diagram is supplied because no systematic screening process is claimed. Consequently, observations about the selected studies should not be interpreted as prevalence estimates for the entire research field. The supplementary reference ledger records the selected-source roles and distinctions used in the synthesis.

2.2. How Evidence Is Interpreted

Three types of statements are distinguished throughout. A standard specifies a cryptographic or protocol mechanism. A research publication reports a design, analysis, or implementation under its own assumptions. The present review provides cross-source interpretation and identifies questions that remain important for implementation. A published assertion of security is attributed to its authors and is not represented as independently reproduced cryptanalysis.

Table 1. Evidence categories used in this review. These categories are complementary, not a universal ranking of study quality.

Evidence type	What it can support	What it does not establish alone
Primitive specification	Defined algorithms, parameters, interfaces, and stated security considerations.	Correct system composition or a secure UAV implementation.
Protocol analysis	Properties within the modeled adversary, state, and assumptions.	Unmodeled implementation leakage, radio availability, or compromised enrollment.
Software evaluation	Timing and memory behavior for the reported processor, library, and workload.	Equivalent performance on other hardware or during flight.
Hardware realization	Feasibility and implementation costs for the reported device and design.	End-to-end security, physical-attack resistance, or complete flight energy.
Network/operational evaluation	Behavior under the reported link, mobility, and deployment conditions.	General guarantees beyond the tested population of conditions.

Table 1. Evidence categories used in this review. These categories are complementary, not a universal ranking of study quality.

Evidence type	What it can support	What it does not establish alone
Primitive specification	Defined algorithms, parameters, interfaces, and stated security considerations.	Correct system composition or a secure UAV implementation.
Protocol analysis	Properties within the modeled adversary, state, and assumptions.	Unmodeled implementation leakage, radio availability, or compromised enrollment.
Software evaluation	Timing and memory behavior for the reported processor, library, and workload.	Equivalent performance on other hardware or during flight.
Hardware realization	Feasibility and implementation costs for the reported device and design.	End-to-end security, physical-attack resistance, or complete flight energy.
Network/operational evaluation	Behavior under the reported link, mobility, and deployment conditions.	General guarantees beyond the tested population of conditions.

3. Network Setting, Threats, and Security Responsibilities

3.1. Communicating Parties and Trust Boundaries

The review distinguishes UAV-to-ground-station, UAV-to-UAV, and remote-user-to-UAV communication. A ground station may register devices and authorize missions; an edge service may assist authentication; a peer link may continue after infrastructure contact is lost. These roles appear in different combinations across the selected authentication studies [3,4,5]. A protocol description should identify which role possesses a long-term secret, which role can create valid credentials, and which role must be reachable for a new session.

The communication medium and the security association must not be conflated. A UART or SPI connection is an onboard interface, whereas a cellular or mesh connection can provide network transport. An encrypted radio link may terminate at a gateway rather than at the application service. The relevant trust boundary is determined by where authentication and decryption occur, not merely by whether the packet travels wirelessly.

Figure 1. Review synthesis of the security responsibilities between device enrollment and operational recovery. The layers describe design questions; they do not constitute a new authentication protocol.

Figure 1. Review synthesis of the security responsibilities between device enrollment and operational recovery. The layers describe design questions; they do not constitute a new authentication protocol.

3.2. Threat Model and Required Properties

At the network layer, a useful starting adversary can observe, inject, alter, delay, replay, and suppress traffic. Stronger models additionally allow capture of a device, disclosure of stored credentials, compromise of an infrastructure database, or collusion between an insider and an external observer. These capabilities must be stated separately. An algorithm that protects messages from an external eavesdropper may offer no protection after its endpoint key has been extracted.

Authentication verifies the claimed peer or origin under a credential model; authorization determines the actions that peer may perform. A message authentication code can protect integrity and origin among parties sharing a key, whereas a digital signature provides publicly verifiable evidence tied to a private signing key [6,12]. Neither result implies that a command is operationally authorized, that a sensor reading is true, or that a radio link will remain available.

Table 2. Threat-to-requirement mapping used for the review. The last column states a design question, not a guarantee of any reviewed scheme.

Threat or failure	Relevant requirement	Implementation question
Impersonation / active interception	Peer authentication and binding of session context.	How is the credential trusted, and are identities and roles bound to the exchange?
Replay / delayed commands	Freshness and application-level acceptance policy.	Which counter or nonce survives reboot, and what happens after state loss?
Payload modification / disclosure	Authenticated encryption and key separation.	Which fields are encrypted, which are authenticated, and how are nonces formed?
Device capture	Explicit compromise model and revocation.	Which secrets or PUF-derived values become accessible, and who can revoke the device?
Infrastructure compromise	Restricted trust and recovery procedures.	Does a database leak enable impersonation, tracking, or future-session compromise?
Resource exhaustion / link loss	Admission control, bounded state, and recovery.	Can invalid requests trigger expensive work or desynchronize persistent state?

Table 2. Threat-to-requirement mapping used for the review. The last column states a design question, not a guarantee of any reviewed scheme.

Threat or failure	Relevant requirement	Implementation question
Impersonation / active interception	Peer authentication and binding of session context.	How is the credential trusted, and are identities and roles bound to the exchange?
Replay / delayed commands	Freshness and application-level acceptance policy.	Which counter or nonce survives reboot, and what happens after state loss?
Payload modification / disclosure	Authenticated encryption and key separation.	Which fields are encrypted, which are authenticated, and how are nonces formed?
Device capture	Explicit compromise model and revocation.	Which secrets or PUF-derived values become accessible, and who can revoke the device?
Infrastructure compromise	Restricted trust and recovery procedures.	Does a database leak enable impersonation, tracking, or future-session compromise?
Resource exhaustion / link loss	Admission control, bounded state, and recovery.	Can invalid requests trigger expensive work or desynchronize persistent state?

Privacy is also multidimensional. Hiding a permanent identifier in one protocol message does not automatically prevent tracking through addresses, repeated pseudonyms, timing, or traffic patterns. Similarly, resistance to device capture is not an inherent property of a short key or a particular curve. The selected PUF and infrastructure-assisted studies motivate examining where identity material and enrollment records remain exposed [3,4].

4. Cryptographic Building Blocks and the Role of ECC

4.1. Symmetric Protection, Hashes, and Key Derivation

Symmetric encryption, message authentication, key derivation, and public-key authentication solve different parts of the channel-security problem. AES-GCM and ChaCha20-Poly1305 are authenticated-encryption constructions, rather than alternatives to an identity infrastructure [13,14]. A hash function such as SHA-256 does not, by itself, authenticate a sender. Keyed constructions and a specified key-management procedure are needed when message origin is part of the requirement [12].

The 2025 NIST Ascon publication specifies Ascon-AEAD128, Ascon-Hash256, Ascon-XOF128, and Ascon-CXOF128 for constrained settings [8]. Its presence changes the current landscape from a list of historical lightweight candidates to a standards-based design choice. However, Ascon is not a public-key key-exchange replacement for ECC, and the label lightweight does not establish that it will outperform a hardware-accelerated alternative on every UAV processor.

Table 3. Functional classification of cryptographic mechanisms. The roles must be composed in a complete protocol.

Mechanism	Primary role	Boundary of the role
AES-GCM / ChaCha20-Poly1305 [13,14]	Authenticated encryption of messages.	Requires established keys, correct nonce handling, and application context.
Ascon-AEAD128 [8]	Standardized authenticated encryption for constrained settings.	Does not establish public-key identity or provide an authentication infrastructure.
HMAC [12]	Message authentication using a shared secret.	Shared-key holders can generate tags; this is not public-key non-repudiation.
HKDF [15]	Extract-and-expand key derivation.	Does not authenticate the input keying material or create entropy from nothing.
ECDH / X25519 [7,16]	Classical public-key shared-secret establishment.	Unauthenticated use does not establish the identity of the peer.
ECDSA [6]	Classical public-key digital signatures.	Requires trustworthy public-key binding and correct signature generation/verification.
ML-KEM [9]	Post-quantum-oriented key encapsulation.	A KEM is not a digital signature or a complete authenticated session protocol.
ML-DSA / SLH-DSA [10,11]	Post-quantum-oriented digital signatures.	Do not replace the authenticated-encryption layer for application traffic.

Table 3. Functional classification of cryptographic mechanisms. The roles must be composed in a complete protocol.

Mechanism	Primary role	Boundary of the role
AES-GCM / ChaCha20-Poly1305 [13,14]	Authenticated encryption of messages.	Requires established keys, correct nonce handling, and application context.
Ascon-AEAD128 [8]	Standardized authenticated encryption for constrained settings.	Does not establish public-key identity or provide an authentication infrastructure.
HMAC [12]	Message authentication using a shared secret.	Shared-key holders can generate tags; this is not public-key non-repudiation.
HKDF [15]	Extract-and-expand key derivation.	Does not authenticate the input keying material or create entropy from nothing.
ECDH / X25519 [7,16]	Classical public-key shared-secret establishment.	Unauthenticated use does not establish the identity of the peer.
ECDSA [6]	Classical public-key digital signatures.	Requires trustworthy public-key binding and correct signature generation/verification.
ML-KEM [9]	Post-quantum-oriented key encapsulation.	A KEM is not a digital signature or a complete authenticated session protocol.
ML-DSA / SLH-DSA [10,11]	Post-quantum-oriented digital signatures.	Do not replace the authenticated-encryption layer for application traffic.

4.2. ECC Without Overstating Its Guarantees

For an illustrative prime-field short-Weierstrass curve, the mathematical relation is y^2 = x^3 + ax + b (mod p), with 4a^3 + 27b^2 not congruent to zero modulo p and suitable domain parameters. A private scalar d and base point G define a public point Q = dG. In elliptic-curve Diffie-Hellman, two correctly formed contributions allow the peers to compute related shared-secret material. Domain-parameter selection, public-key assurance, and the surrounding protocol are essential parts of the construction [7].

This description is not a recommendation to implement point arithmetic or invent a curve. X25519 and X448 have their own curve forms and encoding rules; they must not be described as a literal implementation of the illustrative short-Weierstrass equation [16]. Likewise, ECDSA signature generation and verification are separate algorithms, and the handling of the per-signature value is security-critical [6]. The safest comparison in a review names the actual primitive and parameter set rather than referring to an unspecified ECC algorithm.

ECC can offer compact classical public-key representations, but its cost is implementation dependent. Public-key operations are often used to authenticate and establish a session, while symmetric authenticated encryption protects the subsequent traffic. A fair comparison therefore separates handshake frequency and cost from the amount of protected data. The review does not infer a universal ECC-versus-RSA speed ordering or label all ECC-based protocols lightweight.

An authenticated session must bind the peer identities, roles, algorithm choices, and exchanged contributions to the resulting keys. Derived traffic keys should be separated by purpose and direction. HKDF provides a defined mechanism for deriving keys from suitable input material [15]; it is not a substitute for authenticating that input. A fitness-based search for an optimal secret key has no role in the reviewed standards and is not presented here as a secure key-generation technique.

4.3. Standardized Protocols as Comparison Baselines

EDHOC specifies compact authenticated ephemeral Diffie-Hellman key exchange for constrained deployments and supports establishment of a security context usable with OSCORE [17]. OSCORE protects CoAP application messages across suitable intermediary arrangements [18]. They provide useful reference mechanisms when evaluating whether a custom IoD design reduces communication or credential costs under comparable assumptions. This does not imply that every UAV communication stack uses CoAP or that the standards themselves constitute a UAV benchmark.

DTLS 1.3 provides another relevant reference for datagram-based secure communication, while preserving datagram transport semantics [19]. Application requirements for ordering, delayed-command rejection, and recovery still require explicit treatment. A proposed UAV protocol should explain why a particular established protocol does not meet its requirements before claiming that a new exchange is necessary. The comparison should include authentication mode, credential provisioning, and retransmission behavior, not only the byte count of one successful message sequence.

5. Representative Authentication Approaches

5.1. ECC-Based and Privacy-Oriented Designs

Teng et al. examine a lightweight authentication mechanism for UAV networks, addressing key consistency under calculation faults or packet loss and reporting runtime and attack-oriented evaluation [20]. The study is relevant to the ECC discussion because authentication must maintain consistent state across the communicating parties, not merely compute a shared value. Any claimed improvement should remain tied to the compared baseline and the conditions of that evaluation.

Constantinescu et al. combine ECC with a hierarchical drone-swarm communication framework and ongoing assessment of participating entities [21]. This illustrates an architectural use of cryptography alongside an additional decision mechanism. The review distinguishes those layers: cryptographic authentication and risk assessment need different validation criteria. A favorable entity assessment does not replace a valid credential or an authenticated message.

Koulianos et al. investigate zk-SNARK-based authentication and location proofs using a blockchain-related implementation [22]. Their work extends the discussion from concealing a message to selectively proving a statement. Its practical evaluation must distinguish proof generation, verification, and infrastructure costs. A proof is only as informative as the encoded statement and its inputs; it is not, by itself, an independent guarantee that a physical location sensor was truthful. This observation is a scope distinction, not a reported attack on the scheme.

5.2. Hardware-Rooted and Infrastructure-Assisted Authentication

SecAuthUAV addresses both UAV-ground-station and UAV-UAV authentication using PUF-assisted mechanisms [3]. Its relevance is the integration of a hardware-dependent identity mechanism into a larger exchange. The review does not infer that PUF presence alone establishes authentication in both directions. Mutual authentication concerns the claims each peer can justify after completing the protocol; it does not require the two peers to possess identical hardware.

Gope and Sikdar study privacy-preserving authenticated key agreement for edge-assisted IoD, using a PUF-based design to address device and service relationships [4]. The architectural question is how the edge service participates and what the privacy and compromise assumptions permit. An evaluation must distinguish the absence of a stored long-term drone secret from the security of enrollment data, helper information, and the trusted service itself.

LAKE-IoD considers authentication of a mobile user and session-key establishment with a drone through server assistance [5]. This is a different communicating-party model from direct peer UAV authentication. It should therefore be compared with schemes serving the same role, not treated as a drop-in replacement for every swarm link. The present review classifies it by its communicating parties and server dependency rather than treating all lightweight key-exchange protocols as ECC-based.

Zhang et al. combine RAM-based PUF behavior with quasi-cyclic low-density parity-check (QC-LDPC) coding and ground-station support [23]. The work makes PUF response reconstruction part of the authentication design. It also places important information and trust at the ground station. This motivates evaluating reliability, helper-data exposure, and enrollment availability together; reducing information stored on a drone does not eliminate the security significance of the remaining database.

5.3. Post-Quantum and Dynamic-Swarm Proposals

Xia et al. propose a UAV identity-authentication and key-agreement scheme using Kyber and HMAC [24]. A subsequent correction modifies parts of the publication and must be consulted with it [25]. The design illustrates interest in post-quantum key establishment, but a paper using the name Kyber is not automatically a conforming implementation of the later standardized ML-KEM specification. Parameter sets, encodings, implementation versions, and authentication composition require separate verification.

Jiao et al. study dynamic swarm authentication using blockchain and aggregatable subvector commitments [26]. Such designs shift some authentication state and update responsibilities to infrastructure. Their claimed savings must be interpreted at the level actually analyzed: a reduced proof-update cost is not equivalent to constant total network, ledger, and device cost. The relevance to an intermittently connected swarm depends on the freshness and availability of the information needed by verifiers.

5.4. Implementation-Oriented Studies

Sen et al. report a PUF-assisted authentication design refined using Scyther analysis, including an off-path ticket mechanism for UAV-UAV communication [27]. Their study is useful because it connects protocol revision with implementation-oriented evaluation rather than presenting a primitive alone. The claims remain tied to the modeled exchanges, device assumptions, and experimental settings. A ticket can reduce continuous infrastructure involvement during peer interaction without removing the original credential and authorization dependency.

Alsulieman et al. report a PUF-assisted scheme with pseudo-identities and symmetric cryptographic components, evaluated in software and implemented on a Nexys A7-100T FPGA [28]. This provides an example of reported hardware realization rather than only operation-count estimates. It does not establish a general conclusion that FPGA implementations are always more efficient or that physical implementation alone proves forward secrecy. Those questions still require the specific key-evolution argument and the boundary of the power and timing measurements.

Table 4. Selected study map. Descriptions report the publications' stated design focus; interpretation questions are the present review's synthesis. This is not an exhaustive protocol inventory.

Study	Setting / mechanism	Interpretation question
Teng et al. (2019) [20]	UAV authentication with key-consistency considerations.	Are cryptographic cost and recovery after packet loss measured under comparable conditions?
Constantinescu et al. (2024) [21]	ECC within hierarchical swarm authentication and entity assessment.	Are authentication and assessment validated as separate responsibilities?
Koulianos et al. (2024) [22]	Zero-knowledge authentication and location proofs.	Which statements are proven, and which inputs and services must be trusted?
SecAuthUAV (2020) [3]	UAV-GS and UAV-UAV; PUF-assisted authentication.	What enrollment records and trusted infrastructure are required?
Gope and Sikdar (2020) [4]	Edge-assisted IoD; privacy-preserving PUF-based key agreement.	Which parties can observe or reconstruct identity/session information?
LAKE-IoD (2020) [5]	Mobile-user-to-drone key exchange with server assistance.	Are the peer roles and server dependency matched in comparisons?
Zhang et al. (2024) [23]	RAM-PUF and QC-LDPC response reconstruction.	How do reconstruction reliability and ground-station trust affect operation?
Xia et al. (2024; corrected 2025) [24,25]	Kyber-based UAV authentication and key agreement.	Which version/parameters are used, and is current standard conformance established?
Jiao et al. (2025) [26]	Blockchain and aSVC for dynamic swarm authentication.	Does claimed efficiency include infrastructure, updates, and disconnected operation?
Sen et al. (2026) [27]	Verification-guided PUF design and peer tickets.	Which modeled properties and platform conditions support the reported conclusions?
Alsulieman et al. (2026) [28]	PUF-assisted design with software and FPGA realization.	Which costs are measured, and which system-security properties require separate analysis?

Table 4. Selected study map. Descriptions report the publications' stated design focus; interpretation questions are the present review's synthesis. This is not an exhaustive protocol inventory.

Study	Setting / mechanism	Interpretation question
Teng et al. (2019) [20]	UAV authentication with key-consistency considerations.	Are cryptographic cost and recovery after packet loss measured under comparable conditions?
Constantinescu et al. (2024) [21]	ECC within hierarchical swarm authentication and entity assessment.	Are authentication and assessment validated as separate responsibilities?
Koulianos et al. (2024) [22]	Zero-knowledge authentication and location proofs.	Which statements are proven, and which inputs and services must be trusted?
SecAuthUAV (2020) [3]	UAV-GS and UAV-UAV; PUF-assisted authentication.	What enrollment records and trusted infrastructure are required?
Gope and Sikdar (2020) [4]	Edge-assisted IoD; privacy-preserving PUF-based key agreement.	Which parties can observe or reconstruct identity/session information?
LAKE-IoD (2020) [5]	Mobile-user-to-drone key exchange with server assistance.	Are the peer roles and server dependency matched in comparisons?
Zhang et al. (2024) [23]	RAM-PUF and QC-LDPC response reconstruction.	How do reconstruction reliability and ground-station trust affect operation?
Xia et al. (2024; corrected 2025) [24,25]	Kyber-based UAV authentication and key agreement.	Which version/parameters are used, and is current standard conformance established?
Jiao et al. (2025) [26]	Blockchain and aSVC for dynamic swarm authentication.	Does claimed efficiency include infrastructure, updates, and disconnected operation?
Sen et al. (2026) [27]	Verification-guided PUF design and peer tickets.	Which modeled properties and platform conditions support the reported conclusions?
Alsulieman et al. (2026) [28]	PUF-assisted design with software and FPGA realization.	Which costs are measured, and which system-security properties require separate analysis?

The studies should not be ranked by a single label such as low overhead or high security. They address different peer roles and use different trust arrangements. The defensible cross-study finding is therefore structural: a comparison becomes meaningful only after those roles, assumptions, and evidence types are aligned. The review does not supply a numerical meta-analysis because the selected results do not form a matched experimental dataset.

6. Software, FPGA, ASIC, and Hybrid Implementation Trade-Offs

6.1. Defining the Measurement Boundary

An implementation may execute all cryptographic operations in software, use a dedicated accelerator, or split control and arithmetic across a processor and programmable logic. A claimed speedup should identify whether its baseline is interpreted code, optimized native code, a hardware-assisted library, or an existing FPGA core. Similarly, a reported power figure may be a tool estimate, device-level measurement, or whole-platform measurement. These are different quantities and should not be pooled without adjustment.

The implementation-oriented studies above motivate including actual platform details rather than constructing a generic improvement factor from arbitrary parallelism, adaptability, and efficiency multipliers [27,28]. Multiplying such qualitative factors does not produce a validated communication-capacity metric. This review presents no derived throughput or energy improvement from placeholder numbers.

6.2. Software and Dedicated Hardware

Software supports updating libraries and protocol state machines without redesigning a datapath. Its evaluation should specify the processor, operating system, library version, compiler options, cryptographic parameter set, and concurrency. The relevant security work includes validation of untrusted input, management of secrets, and correct failure handling. A fast primitive call is insufficient evidence if authentication retries or memory pressure dominate the complete session.

FPGA implementations can expose parallel arithmetic and hardware-dependent identity structures, but integration introduces transfer, driver, and synchronization costs. A report should separate the cryptographic core from its input/output logic and protocol controller. Resource counts should name the target device and include LUTs, registers, memory blocks, and any arithmetic blocks. Timing closure and clock frequency must accompany a cycle count. Static configuration and key storage must be included in the security boundary.

An application-specific integrated circuit (ASIC) is a separate implementation option, not simply an FPGA with a larger hypothetical improvement coefficient. A meaningful comparison requires a technology-specific design and stated area, frequency, power, and measurement conditions. The present corpus is not used to claim an ASIC performance advantage; such a claim would require a matched implementation study that this review does not provide.

6.3. Hybrid Systems and Trust Distribution

A hybrid arrangement can keep protocol control in software while offloading a defined operation to hardware. The appropriate unit of comparison is a completed authenticated operation or protected message at the application boundary, including data movement and waiting. If a hardware accelerator temporarily receives key material, the lifetime and ownership of that material must be defined. A design that reduces processor cycles can still incur additional platform energy through transfer and idle waiting.

Table 5. Implementation reporting requirements. The entries specify information needed to evaluate a choice, not presumed winners.

Implementation	Cost information to report	Assurance information to report
Software	CPU, library/compiler, wall time and cycles, memory, concurrency, energy boundary.	Input validation, secret lifetime, randomness source, side-channel assumptions, recovery.
FPGA	Device/tool version, LUT/FF/BRAM/DSP, clock, core plus transfer latency, power method.	Key storage, bitstream/update trust, interface ownership, reset and fault behavior.
ASIC	Process node, architecture, area, operating conditions, implementation/measurement stage.	Key provisioning, hardware trust, test/debug exposure, lifecycle and fault assumptions.
Hybrid	Processor and accelerator costs, transfers, driver delay, total latency and energy.	CPU-device trust boundary, key movement, synchronization, failure propagation.

Table 5. Implementation reporting requirements. The entries specify information needed to evaluate a choice, not presumed winners.

Implementation	Cost information to report	Assurance information to report
Software	CPU, library/compiler, wall time and cycles, memory, concurrency, energy boundary.	Input validation, secret lifetime, randomness source, side-channel assumptions, recovery.
FPGA	Device/tool version, LUT/FF/BRAM/DSP, clock, core plus transfer latency, power method.	Key storage, bitstream/update trust, interface ownership, reset and fault behavior.
ASIC	Process node, architecture, area, operating conditions, implementation/measurement stage.	Key provisioning, hardware trust, test/debug exposure, lifecycle and fault assumptions.
Hybrid	Processor and accelerator costs, transfers, driver delay, total latency and energy.	CPU-device trust boundary, key movement, synchronization, failure propagation.

7. Evaluation Framework for Comparable UAV Security Studies

7.1. Security Analysis and Implementation Testing

A future study should first state its entities, credential authority, initial secrets, trusted channels, and adversary capabilities. Formal-analysis artifacts should identify the modeled protocol version, sessions, claims, and compromise events. Symbolic analysis is useful for checking modeled message relationships, but its result must not be restated as complete resistance to all physical, implementation, and availability attacks. The verification-guided development reported by Sen et al. illustrates the importance of connecting a model to a particular exchange [27].

Implementation testing should then check malformed messages, rejected credentials, repeated nonces, stale counters, interrupted updates, and inconsistent local state. Credential provisioning and revocation are not outside the security system merely because they occur before or after a successful handshake. Key-management guidance treats these lifecycle responsibilities as part of the management problem [29]. An operational system also needs a defined response when a device cannot complete authentication without exhausting its communication or computation budget.

7.2. Performance and Communication Accounting

Comparisons should report the security level and parameter set, session-establishment frequency, payload size, authentication roles, and hardware acceleration available to each baseline. Communication overhead should be counted over the entire specified exchange, including certificates or other credentials when required. A best-case successful exchange and an exchange with retransmission or invalid traffic should be reported separately. Energy measurements should identify the endpoint, measurement interval, and whether radio transmission and waiting are included.

Table 6. Minimum reporting framework proposed by this review.

Dimension	Required report
Protocol identity	Version, exact messages, communicating roles, algorithms, parameters, credential format.
Trust and compromise	Enrollment authority, online-service dependency, captured-node capabilities, infrastructure disclosure assumptions.
Formal evidence	Model files or precise model description, claims, verification scope, limitations, and unresolved results.
Implementation	Source/configuration availability, processor or FPGA, software/tools, frequency, libraries, measurement method.
Communication	Total exchange bytes and messages, credential inclusion, link/transport assumptions, retry and fragmentation conditions.
Latency and energy	Sampling/repetitions, distribution rather than one unexplained value, endpoint and subsystem boundaries.
Lifecycle behavior	Rekeying, revocation, reboot, counter persistence, failed exchanges, desynchronization, restoration.
Comparison fairness	Matched peers, security goals, workload, parameter sets, and implementation effort; explicit differences.

Table 6. Minimum reporting framework proposed by this review.

Dimension	Required report
Protocol identity	Version, exact messages, communicating roles, algorithms, parameters, credential format.
Trust and compromise	Enrollment authority, online-service dependency, captured-node capabilities, infrastructure disclosure assumptions.
Formal evidence	Model files or precise model description, claims, verification scope, limitations, and unresolved results.
Implementation	Source/configuration availability, processor or FPGA, software/tools, frequency, libraries, measurement method.
Communication	Total exchange bytes and messages, credential inclusion, link/transport assumptions, retry and fragmentation conditions.
Latency and energy	Sampling/repetitions, distribution rather than one unexplained value, endpoint and subsystem boundaries.
Lifecycle behavior	Rekeying, revocation, reboot, counter persistence, failed exchanges, desynchronization, restoration.
Comparison fairness	Matched peers, security goals, workload, parameter sets, and implementation effort; explicit differences.

A useful reproducibility package would contain protocol transcripts with synthetic test identities, verification models where available, benchmark configuration, and raw timing or energy observations with their units. It should not publish production private keys or deployment credentials. Negative results are informative: a configuration that cannot complete a handshake under the tested loss or memory conditions should be reported as such rather than omitted from the comparison.

7.3. Interpreting Claimed Security Properties

Forward secrecy, post-compromise recovery, and routine key rotation are distinct claims. A key-update mechanism should be analyzed against the exact secrets disclosed and the time of compromise. Merely replacing one stored value with another does not establish every one of these properties. Similarly, an encrypted database can remain an impersonation risk if the service holding its decryption key is compromised. The reporting framework therefore asks authors to state compromise events explicitly instead of assigning a single secure/insecure label.

For PUF-assisted systems, the protocol and physical component require complementary evidence. Authentication analysis should cover challenge handling, helper information, enrollment records, and response reconstruction. Implementation evidence should characterize the conditions under which reconstruction succeeds. A physical identifier cannot, by itself, authorize an operation or authenticate an arbitrary remote party; those functions belong to the surrounding protocol. Zhang et al. and Alsulieman et al. provide different examples of addressing this interface between protocol and hardware [23,28].

8. Post-Quantum Readiness and Research Directions

8.1. Distinguishing Standardized Functions

ECC-based key agreement is a classical public-key mechanism and is not quantum-resistant against a sufficiently capable quantum adversary [16]. NIST finalized ML-KEM, ML-DSA, and SLH-DSA in 2024, separating key encapsulation from lattice-based and hash-based signatures [9,10,11]. A contemporary review should not describe these algorithms only through obsolete competition-round categories. Implementations should identify the final specification, relevant errata, and parameter set they actually use.

Post-quantum readiness is not achieved by replacing every occurrence of ECC with the name of a KEM. Authentication, credential binding, derived traffic keys, and message protection still need a complete protocol. The Kyber-based UAV study and its correction offer a concrete example of the need to track exact versions and published amendments [24,25]. This review does not assert interoperability with FIPS 203 or independent security validation of that scheme.

8.2. Implementation and Operational Questions

For constrained UAV links, research should measure the effect of the selected public-key representation on complete exchanges, including credential transport, packetization, and retry behavior. The comparison should cover both computation and communication on the intended platform rather than extrapolating from a desktop operation count. Hybrid classical/post-quantum arrangements require a specified composition and downgrade policy; combining algorithm names is not a security argument.

A second direction is lifecycle-aware authentication in intermittent networks. Peer tickets, edge assistance, and ledger-based state distribution can reduce some forms of online interaction, but they create questions about expiry, revocation knowledge, and stale authorization. The selected ticket-based and dynamic-swarm proposals provide settings in which those questions can be evaluated [26,27]. An offline success case and recovery after prolonged disconnection should be distinguished.

A third direction is reproducible cross-platform implementation with a consistent application boundary. The same authentication role and security parameter set should be evaluated in software, FPGA, and hybrid forms where feasible. The study should report key storage, reset behavior, error paths, and radio-inclusive energy, not merely acceleration of one arithmetic routine. Such matched evaluations would make the hardware/software discussion more informative than generic assertions about parallelism.

9. Discussion and Limitations

The central synthesis is that lightweight authentication is a system property. It depends on the workload, where trust resides, how frequently keys are established, and which costs the measurement includes. ECC, symmetric authentication, PUFs, edge services, and post-quantum primitives occupy different roles in that system. A design may combine them, but no single item in that list supplies every required property.

The evidence also supports a distinction between protocol feasibility and deployment assurance. A specified primitive provides a stable building block; a formal model examines selected protocol behavior; a benchmark establishes costs under stated conditions; and a hardware realization demonstrates a particular implementation. Combining evidence types is more informative than replacing their qualifications with a general high-security label. This conclusion is the review's interpretation of the selected sources rather than a statistical finding about all UAV security publications.

Several limitations follow from the narrative approach. Source selection is targeted and not exhaustive. The review does not reproduce the referenced implementations or verification models, perform new cryptanalysis, or normalize heterogeneous benchmark results into a common score. Some threat classes, including detailed radio-frequency countermeasures and flight-control safety analysis, are outside scope. Standards evolve, so pinned references and published corrections must be checked again when a concrete implementation is selected.

10. Conclusions

This narrative review examined UAV communication security through lightweight authentication, ECC, and hardware/software implementation. Its taxonomy separates identity and trust, authenticated key establishment, protected traffic, and operational lifecycle. The selected studies show different ways of distributing those responsibilities across devices, PUFs, ground stations, and services. ECC remains a relevant classical public-key mechanism, but neither its compact representation nor a lightweight label establishes complete communication security. Current symmetric and post-quantum standards address complementary functions. Future work should align threat models, compare complete exchanges on matched platforms, and publish implementation and lifecycle evidence sufficient to evaluate reported benefits. No new protocol, experimental benchmark, or universal performance ranking is claimed in this review.