internet of drones: Why Most Drone Authentication Protocols Still Fail

Analysis by the aitrendblend editorial team · 13 min read · Robotics and autonomous systems
internet of drones authentication protocols impersonation attacks drone testbed post quantum cryptography
Quadcopter drone connected through a wireless link to a ground control station with a padlock icon representing authentication verification
Of the roughly fifty protocols this survey compared, none had been run on an actual drone before the authors built their own testbed to check.
A research group at Johns Hopkins once showed they could interfere with a drone’s normal operation using nothing more exotic than a mobile phone. That anecdote opens a new survey out of Manchester Metropolitan University and the University of Bristol, and it sets the tone for everything that follows. The authors read through dozens of published authentication schemes built specifically to stop that kind of interference, and what they found is that most of these schemes have never been tried on a real drone at all.

Key points

  • Shamshad, Belguith, and Oracevic screened 557 papers down to 78 core studies on authentication and key agreement for the Internet of Drones, published between 2018 and early 2025.
  • They propose a three tier taxonomy splitting authentication into hardware level, network level, and application level mechanisms, arguing that prior taxonomies lumped conceptually distinct techniques into the same broad category.
  • Across four comparison tables covering roughly fifty three individual protocols, a column called Realistic Implementation shows not a single one had actually been tested on physical drone hardware before this survey.
  • Resistance to impersonation attacks, arguably the most basic requirement of an authentication protocol, is marked unavailable for essentially every protocol reviewed.
  • The authors built their own testbed with a Holybro QAV250 quadcopter and shortlisted two protocols for real hardware testing, finding one protocol’s ground station took over fourteen seconds to complete its side of the exchange while the drone finished its part in a quarter of a second.

A phone call that should not be able to hijack a drone

Start with why this matters. A drone that collects footage over a wildfire, tracks livestock across a farm, or inspects a bridge for cracks is only useful if the person receiving its data can trust where that data came from and the drone can trust who is sending it commands. Without that trust, in either direction, an attacker can inject false commands, intercept sensitive footage, or clone a drone’s identity outright. The paper cites a demonstration from Johns Hopkins University where researchers showed an adversary could interfere with a drone’s normal operation using a mobile phone, a vivid reminder that the wireless link connecting a drone to its ground control station is an open channel unless something actively defends it.

Authentication and key agreement mechanisms are the something. The idea is simple to state and hard to execute well. Two parties, say a drone and a ground station, need to confirm each other’s identity and then agree on a shared secret key they can use to encrypt everything that follows. Get that handshake wrong and every later message inherits the weakness. Get it right while also respecting a drone’s limited battery, memory, and processing power, and you have a genuinely difficult engineering problem, since the heavyweight cryptography that works fine on a server can be entirely impractical on a device that has to stay airborne.

The drone’s physical exposure compounds the problem in a way that a typical networked device does not face. Drones fly through terrain nobody is actively watching, from dense city blocks to open countryside, which gives an attacker time and privacy to physically capture a downed or landed unit and probe its circuitry directly. Unlike a server sitting in a locked data center, a drone’s hardware often has no defense against someone opening it up and reading secrets out of memory, which is exactly why the authors argue security has to be designed in from the earliest architectural decisions rather than bolted on afterward.

Where the search actually landed

The authors followed Kitchenham’s established systematic review guidelines, building a search string around Internet of Drones, Unmanned Aerial Vehicle, and authentication related terms, then running it across IEEE Xplore, Elsevier, Springer, ACM, Scopus, and Web of Science. That search returned 557 papers published between 2018 and the first quarter of 2025, broken down as 174 from IEEE, 152 from Scopus, 99 from Web of Science, 70 from Springer, 37 from ACM, and 25 from Elsevier.

Removing 185 duplicate titles left 372 unique papers. Screening titles and abstracts against the study’s scope brought that down to 101 candidates for full text reading. A further 26 papers turned out to be unrelated to the study’s actual scope once read in full, leaving a final core set of 78 papers, individually cross referenced throughout the survey.

A gap in the funnel worth flagging. The text states that 58 papers, including 7 flagged as doubtful, were excluded during the abstract and conclusion screening stage, which supposedly produced the 101 papers that moved to full text reading. But 372 minus 58 is 314, not 101, so roughly 271 exclusions at that stage go unaccounted for in the narrative even though the flow diagram confirms 101 as the correct output number. This does not undermine the final count of 78, which the diagram supports consistently, but it is the kind of detail a careful reader should notice rather than take every intermediate sentence at face value.

What earlier surveys missed

This is not the first attempt to organize the Internet of Drones authentication literature, and the paper includes a genuinely useful comparison table scoring seventeen prior reviews against six criteria, whether they focus on security, focus specifically on authentication, present a protocol taxonomy, review security analysis tools, include hardware implementation, and offer comparative analysis of existing protocols.

Wazid and colleagues presented an early taxonomy of security solutions back in 2018, but many of the protocols they discussed were built for wireless sensor networks generally rather than drones specifically. Michailidis and Vouyioukas split authentication into software based and hardware based categories, covering physically unclonable functions, hardware security modules, and tamper proof memory, but the new survey argues this taxonomy still groups conceptually distinct mechanisms together. Device fingerprinting, firmware integrity verification, lightweight cryptographic authentication, and drone to drone authentication all end up filed under the same broad heading in that scheme, which limits how much analytical insight a reader can extract from it.

Derhab and colleagues took a different angle in 2023, building a taxonomy around fine grained and coarse grained assets and the threats targeting each. Escobar and colleagues, publishing in 2024, split authentication approaches into traditional cryptographic primitives and machine learning based techniques. According to the new survey’s scoring in its comparison table, none of these seventeen prior efforts covers all six criteria at once, and only this new work claims full coverage across security focus, authentication focus, taxonomy, security analysis tools, hardware implementation, and comparative analysis.

Their taxonomy classifies AKA mechanisms based on the underlying technique and overlooks how AKA operates across different layers of IoD ecosystem. This method often groups conceptually distinct mechanisms within the same broad category. From the paper’s critique of prior taxonomies, explaining the motivation for its own three tier structure

A taxonomy built around where trust actually lives

The paper’s central organizing idea is that authentication in a drone network is not one problem, it is three, and each one lives at a different layer of the system. Hardware level authentication establishes that a physical device is what it claims to be. Network level authentication establishes that only legitimate users, drones, and ground stations can open a communication channel. Application level authentication governs what a verified participant is actually allowed to do once connected, whether that is a drone talking to a ground station, a user talking to a drone, or drones coordinating with each other in a swarm.

The authors are careful to draw a specific comparison here that helps clarify what makes their layered approach different from something like the OSI networking model. The OSI model protects data and its transmission. It does not ask whether the operator issuing a command is actually authorized or whether a drone responding to that command is the one it claims to be. The taxonomy in this paper layers identity verification on top of that transmission security, treating trust in the participants themselves as a separate concern from trust in the channel they are using.

Hardware level, the physical anchor

At the base sits hardware level authentication, built around the idea that a device’s physical characteristics can serve as an identity that is extremely hard to fake. Physically unclonable functions exploit random microscopic variations that occur during chip manufacturing, meaning even two chips built on the same production line end up with subtly different electrical fingerprints. Radio frequency fingerprinting works similarly but at the level of a device’s radio hardware, picking up on tiny imperfections in a power amplifier or oscillator that show up as a signature in every transmission. Secure boot and hardware security modules round out this tier, ensuring a drone only runs firmware it can cryptographically verify and that its private keys never leave a tamper resistant enclosure.

Network level, the handshake itself

The middle tier covers the actual authentication and key agreement handshake, and it is where most of the cryptographic variety in the literature shows up. Lightweight primitives such as hash functions and symmetric ciphers like AES keep computational cost low, which matters enormously on a battery powered flying device. Asymmetric methods such as elliptic curve cryptography and public key infrastructure trade higher computational cost for stronger guarantees. Privacy preserving techniques such as zero knowledge proofs let a drone prove its legitimacy without revealing its actual identity, which matters in surveillance or battlefield contexts where tracking a specific drone’s movements would itself be a security risk. Decentralized approaches built on blockchain or distributed ledgers remove the single ground station as a point of failure entirely, letting drones verify each other without a central authority in the loop.

Application level, who gets to do what

The top tier is where context finally enters the picture. UAV to ground station authentication governs command and control links, the most sensitive channel in the whole system since a compromised command link can mean a hijacked drone. User to UAV authentication covers how a human operator proves their identity, ranging from a single password to full multi factor schemes combining a password, a physical token, and a biometric trait. UAV to UAV authentication matters specifically for swarms, where drones need to verify each other on the fly as they join or leave a formation without waiting for a central authority to vouch for every new arrival. Adaptive authentication sits above all of this, adjusting how strict verification needs to be based on context such as an operator’s location, the sensitivity of the current mission, or whether recent behavior looks unusual enough to warrant a fresh round of verification.

The uncomfortable pattern across four comparison tables

This is the part of the survey that deserves the most attention from anyone actually choosing a protocol to implement. The authors built four separate comparison tables, sorting reviewed protocols into single or two factor user initiated schemes, three factor user initiated schemes, certificate based device initiated schemes, and physically unclonable function based device initiated schemes. Each table scores every protocol against the same set of functionality goals, mutual authentication, forward secrecy, and resistance to a long list of specific attacks including man in the middle, replay, stolen verifier, stolen device, impersonation, desynchronization, and ephemeral secret leakage.

Working through the raw counts in these tables surfaces a pattern the authors describe but that becomes more striking once you actually tally it. In the first table, covering ten single and two factor protocols, only one scheme resists stolen verifier attacks and only two resist stolen device attacks. Every single protocol in that table, all ten, fails to resist impersonation. The certificate based table tells a similar story, with the large majority failing against stolen device and impersonation attacks alike. The pattern holds across all four tables. Impersonation resistance, which is essentially the entire point of an authentication protocol, shows up as available in close to zero cases across every category the authors examined.

Comparison tableProtocols scoredResist stolen verifier attackResist impersonation attackRealistic implementation reported
Single or two factor user initiated101 of 100 of 100 of 10
Three factor user initiated150 of 150 of 150 of 15
Certificate based device initiated155 of 150 of 150 of 15
PUF based device initiated132 of 131 of 130 of 13

Read that last column again. Across fifty three protocols spanning six years of published research, not one had been demonstrated on physical drone hardware before this survey’s authors built their own testbed to check. Every prior claim of practicality rested on simulation, formal proof, or theoretical analysis alone. That is not necessarily damning on its own, formal verification tools like AVISPA and Scyther genuinely do catch real design flaws, and several of the protocols in these tables were caught making false security claims precisely because a later paper ran that kind of formal analysis against them. But it does mean that questions specific to real hardware, how much memory a protocol actually consumes on a Raspberry Pi, how long a full handshake actually takes when radio latency and processor scheduling are real rather than modeled, went unanswered across the entire literature until now.

Putting two protocols on an actual drone

Having identified the protocols with the strongest security coverage from their tables, the authors picked two for hands on testing, a heterogeneous authenticated key establishment scheme by Jin and colleagues and a computational framework for drone assisted aerial computing by Tanveer and colleagues. The testbed itself is worth describing because it is unusually concrete for this kind of survey. The drone side ran on a Holybro QAV250 quadcopter kit fitted with a PIX32 6C Mini flight controller and a Raspberry Pi 4 Model B, using its Broadcom BCM2711 quad core processor clocked at 1.5 gigahertz. The ground control station ran on a virtual machine hosted on a laptop with a twelfth generation Intel Core i7 processor and 18 gigabytes of memory. A separate Raspberry Pi 4 stood in for the user side of the exchange. Every component talked to the others over TCP sockets using Python, and the authors made their implementation code publicly available.

Protocol and roleMemory consumedCPU timeTotal execution timeMessage size
Jin et al. protocol, drone side0.95 MB0.046 s0.265 s106 bytes
Jin et al. protocol, ground station side0.50 MB0.013 s14.63 s508 bytes
Tanveer et al. protocol, user side20.23 MB0.0075 s0.204 s357 bytes
Tanveer et al. protocol, ground station side62.24 MB0.0018 s0.148 s272 bytes
Tanveer et al. protocol, drone side18.46 MB0.0014 s0.111 s391 bytes

Two things jump out from these numbers. First, the Tanveer protocol’s ground station consumed sixty two megabytes of memory, more than a hundred times what the drone side of the Jin protocol used, a reminder that the same broad category of authentication scheme can carry wildly different resource footprints depending on implementation choices that a taxonomy alone cannot capture. Second, and more strikingly, the Jin protocol’s ground station took over fourteen and a half seconds to complete its side of the exchange while the drone finished its half in roughly a quarter of a second. The paper reports these figures without dwelling on the gap, but a fourteen second wait on the ground station side for what should be a fast cryptographic handshake is the kind of anomaly that would matter enormously in a time sensitive mission and deserves scrutiny beyond what a single benchmark run can offer.

The authors are upfront that this experiment measures protocol level metrics rather than system level ones. Things like how a slow handshake affects actual flight time, how performance holds up as radio conditions degrade, or how the numbers change once dozens of drones are authenticating simultaneously all fall outside what a single quadcopter testbed can tell you, and the paper says as much rather than overselling its scope.

Where the field needs to go next

The paper closes with a set of future directions that read less like a wish list and more like a checklist of gaps its own comparison tables just exposed. Post quantum cryptography gets particular emphasis, since most existing protocols lean on elliptic curve cryptography or RSA, both of which Shor’s algorithm could break given a sufficiently capable quantum computer. The authors specifically recommend that future authentication mechanisms be built with crypto agility in mind, meaning the underlying cryptographic primitives could be swapped out for quantum resistant alternatives without redesigning the entire protocol from scratch, since drones and their supporting infrastructure tend to stay in service for years.

Stolen verifier attacks get their own dedicated call to action, and given how often that exact vulnerability shows up across all four comparison tables, it is easy to see why. Many protocols store long term secrets or credential tables directly on the ground station without meaningful access control, meaning a single insider or a single successful breach of that one machine compromises the identity of every drone and user that has ever registered with it. The authors also push for post authentication trust management built on zero trust principles, arguing that most current schemes treat authentication as a one time event rather than something that should be continuously reverified as a mission unfolds. Secure firmware verification, context aware adaptive authentication, and simply more realistic testing on physical hardware round out the list, the last item being a direct callback to the empty column that ran through every one of the paper’s own comparison tables.

Conclusion

What makes this survey worth reading is not the taxonomy diagram itself, useful as it is, but the discipline the authors bring to actually counting how many of the protocols organized by that taxonomy hold up under scrutiny. A three tier structure separating hardware, network, and application level trust is a genuinely clearer way to think about drone authentication than lumping every technique into one undifferentiated pile. But the real contribution is turning dozens of individual security claims into a set of comparison tables anyone can scan, and letting the empty cells in those tables do the talking.

The conceptual shift worth carrying forward is that a security protocol’s theoretical elegance and its practical trustworthiness are two different questions, and the literature this survey covers has mostly only been answering the first one. A scheme can survive a formal verification tool like AVISPA or Scyther and still store long term secrets in a database with no access control, a flaw that shows up as a stolen verifier vulnerability in table after table here. Formal proof and real world resilience are complementary, not substitutes for each other, and this survey is one of the few in the space to actually check both.

This pattern is not unique to drones. Any authentication literature for resource constrained, physically exposed devices, industrial sensors, implanted medical devices, autonomous vehicles, tends to accumulate the same gap between protocols that look secure on paper and protocols that have actually been run on the hardware they claim to protect. The specific attack surface differs from domain to domain, but the discipline of demanding a realistic implementation column before trusting a security claim travels well beyond drones specifically.

What remains genuinely open is exactly what the authors say is open. Nobody in this literature has yet built and tested a protocol that is simultaneously post quantum resistant, resilient against stolen verifier and impersonation attacks, lightweight enough for a battery powered drone, and validated on physical hardware at any meaningful scale. Two protocols surviving a single quadcopter benchmark is a real start, not a finish line, and the fourteen second anomaly buried in the paper’s own results table is a small reminder that even the protocols judged strongest by this survey’s own criteria still have surprises waiting once they leave the page.

The next time a vendor or a paper claims a drone authentication scheme is secure, the question this survey equips a reader to ask is not whether it survived a formal proof, but which of the three taxonomy tiers it actually addresses, which specific attacks in tables like these it has been shown to resist, and whether anyone has run it on a real drone yet.

Frequently asked questions

What is the Internet of Drones and why does it need its own authentication research

The Internet of Drones refers to networks of unmanned aerial vehicles that communicate with each other, ground control stations, and cloud infrastructure over wireless channels. It needs dedicated authentication research because drones combine severe resource constraints in memory and processing power with unusual physical exposure, since they often operate unsupervised in locations where an attacker could capture and probe the hardware directly.

How many studies did this survey actually review

The authors screened 557 papers published between 2018 and the first quarter of 2025 across six digital libraries, removing duplicates and papers outside the study’s scope through title, abstract, and full text screening, arriving at a final core set of 78 papers that are individually discussed and compared throughout the survey.

What are the three tiers in the paper’s proposed taxonomy

The taxonomy splits authentication into hardware level mechanisms that verify a physical device’s legitimacy through techniques like physically unclonable functions, network level mechanisms that verify users, drones, and ground stations before allowing communication, and application level mechanisms that govern what an already verified participant is allowed to do based on context such as drone to drone or user to drone interaction.

Why do so many reviewed protocols fail against impersonation attacks

Across the survey’s four comparison tables covering roughly fifty three protocols, resistance to impersonation attacks is marked as unavailable in nearly every case, largely because many protocols store long term secrets or credential tables on the ground station without meaningful access control, allowing an attacker who compromises that single point to impersonate any registered drone or user.

Had any of these authentication protocols actually been tested on a real drone before this survey

According to the Realistic Implementation column that appears in all four of the survey’s comparison tables, none of the roughly fifty three protocols scored had been demonstrated on physical drone hardware previously, which is why the authors built their own Holybro QAV250 quadcopter testbed to benchmark two shortlisted protocols directly.

What do the authors recommend for future drone authentication research

The paper calls for post quantum resistant cryptography built with crypto agility in mind, stronger defenses specifically against stolen verifier attacks, continuous zero trust style reverification rather than one time authentication, secure firmware integrity checks, context aware adaptive authentication, and more testing on physical hardware rather than simulation alone.

Read the full open access survey for the complete taxonomy figures and all four comparison tables.

Read the paper (DOI, open access) Testbed implementation code on GitHub

The complete open access article, including all four attack resistance comparison tables and the full 78 paper reference set, is available through its DOI at Elsevier’s Computer Science Review, published under a Creative Commons Attribution license.

Shamshad, S., Belguith, S., and Oracevic, A. Authentication and key agreement mechanisms for internet of drones, a novel taxonomy, critical review, and experimental performance analysis. Computer Science Review, volume 63, 2027, article 101046.
This analysis is based on the published paper and an independent evaluation of its claims.

Related reading

Leave a Comment

Your email address will not be published. Required fields are marked *