Quick disclaimer: I'm still learning this stuff. This comes out of a small personal project where I'm trying to secure the link between a hobby drone and its ground station. Everything below was tested in simulation (ArduPilot SITL) and a little on real hardware, on a very modest setup — so please take my own results with a grain of salt.
Context: a protocol everywhere, secured nowhere
If you build an open-source drone today, chances are it speaks MAVLink — the communication protocol between the drone and its ground control station (GCS), used by ArduPilot and PX4, running on millions of devices.
The catch: MAVLink was designed for one thing — performance. Compact packets, low latency, long range. Security wasn't part of the original spec, and it shows.
MAVLink in 30 seconds
The drone and the GCS constantly exchange two kinds of messages: commands going down (take off, go to this point, land) and telemetry coming up (position, altitude, battery, status). It all starts with a HEARTBEAT sent every second to keep the link alive.
Simple, efficient… and, as far as I can tell, wide open.
The problem: MAVLink v1 protects nothing
MAVLink version 1 has no encryption, no authentication, no signing. From what I understand, an attacker within radio range can:
- listen to all telemetry in clear (your position, your flight plan);
- inject fake commands, since nothing checks who sends them;
- run a man-in-the-middle attack, or replay old packets.
This isn't just theory — it's documented in CVE-2020-10282 (CWE-306, "Missing Authentication for Critical Function"), rated around 9.6/10. The weakness isn't an implementation bug; it's in the protocol design itself.
The catch with v2
MAVLink 2 added optional signing based on HMAC-SHA256. On paper that's the right idea: a shared secret key, and each message carries an authentication code over its content plus a timestamp; unsigned or badly signed messages get rejected.
But, from what I've read:
- Signing is optional and off by default.
- To stay backward-compatible, the GCS and drone negotiate the version — and an attacker can craft packets that force a fallback to MAVLink v1, where there's no protection at all. The classic downgrade attack.
So just turning signing on isn't enough if you don't also force v2 and block the downgrade. (I'm honestly still figuring out the cleanest way to do that.)
What about the radio link?
Telemetry is only half the picture. On a lot of FPV drones the control link runs over ExpressLRS (ELRS). Back in 2022, NCC Group published an analysis worth knowing about: the ELRS binding phrase is not a security mechanism — the developers say so themselves, it's anti-collision.
The uncomfortable detail: a single sync packet apparently leaks about 75% of the unique identifier needed to take over the link, and the rest can be brute-forced. With a standard ELRS radio, an attacker could hijack the control link. (Worth noting the ELRS team pushed back on parts of how this was reported — but the core point stands.)
The general lesson I'm taking from this: don't confuse "pairing" with "authentication."
What I tried on my own build
I'm not trying to reinvent cryptography — way above my level. I just wanted to see whether I could reproduce, on a hobby budget, the basic ideas you find in proper solutions. I went for layered defense on the telemetry link:
Layer 1 — Authentication: MAVLink2 signing (HMAC-SHA256).
Enabled on the autopilot side, it should block injection: without the key you can't forge a valid command, and the timestamp kills replays.
# Force MAVLink2 on the telemetry port (no v1 fallback)
SERIAL1_PROTOCOL = 2
# Signing (32-byte key) is set on the GCS side
Layer 2 — Confidentiality: AES-256-GCM encryption.
Signing authenticates but doesn't encrypt — telemetry stays readable. So I added an encryption proxy on a small companion computer, between the flight controller and the radio. GCM also gives integrity (a tampered packet is rejected).
Layer 3 — Stacking.
Both layers add up: signature and encryption. If one fails, the other still stands. That's the whole idea of defense in depth — at least as I understand it.
Rough takeaway: signing blocks injection, encryption blocks eavesdropping, and together they cover the link. I want to stress these were small tests, not a rigorous evaluation.
The real hard part: keys, not the algorithm
Picking AES or ChaCha20 is the easy bit. The hard part — and the part I'm least sure about — is key management. If a symmetric key sits in the drone's flash and someone gets hold of the drone, they can pull the key and impersonate a legit drone to your GCS.
One idea I find interesting (still reading about it): a drone that stores no permanent secret, deriving an ephemeral session key in RAM at each boot via a Diffie-Hellman exchange, so everything disappears on power-off. If the drone is captured, you'd recover generic hardware and an empty RAM. I haven't implemented this properly yet — it's on my "learn this next" list.
Takeaways (from a beginner)
MAVLink is a great protocol — open, efficient, universal. But "open and efficient" doesn't mean "safe." Security isn't built in; it has to be added on top, ideally from the design stage, and on every link, not just telemetry.
If you run an open-source drone for anything beyond fun, maybe ask yourself: is my telemetry encrypted? are my commands signed and is v1 blocked? does my control link rely on real authentication, or on a "binding phrase" that isn't one?
I'm still early in this, so if you spot something I got wrong, please tell me in the comments — I'd genuinely like to learn.
Next time: the other half of the problem — GPS. How to spot spoofing, and how to keep flying with no satellite signal.
Questions or corrections very welcome below.