Skip to content

On Link Security and Vulnerability Reports

As of late, the ExpressLRS project has received several "security disclosures" from "cybersecurity experts" suggesting certain changes to the project. While we welcome security disclosures that make sense with the project's goals, the majority that we've seen boil down to fearmongering around the undisputed fact that ExpressLRS is unencrypted.

"ExpressLRS is unencrypted!! zomg!!"

Yes. We know. That's a deliberate design choice by the project's authors. We are fully aware of how to implement secure cryptography and have discussed openly for several years why we choose not to. Put simply, ExpressLRS is an RC link for hobby and professional use. Hobby and professional users would see more harm than good from adding ill-advised changes that don't fit their reality.

There's an underappreciated concept in cybersecurity known as "threat modeling": sure, your small business could hypothetically be the target of nation-state attackers that burn a zero-day... but it's far more likely that Brenda in accounting or Dan in marketing clicks on a link they shouldn't have. So, you focus your attention where it makes a difference by putting yourself in the shoes of a would-be attacker.

Who could we imagine that might be interested in disturbing a model in flight?

People near the flight path that have privacy/noise complaints

It's a real possibility but usually they lack technical knowledge and will simply call the police, yell at you, shoot at the model, or use a jammer. The possibility of a very advanced neighbor that has enough skill and criminal energy to hack your RF link is roughly zero.

Cheaters at racing events

Probably the most reasonable one here; skilled people with a motive and equipment, selective attacks make more sense than a jammer... but people in the pits plugging in on your video channel is way more likely than this scenario.

Law enforcement to enforce no-fly zones/illegal activity

Law enforcement would more likely jam the band or shoot the model down, and frankly we're not here to help you skirt the law.

What are the actual risks?

It breaks down to two things: the first is information disclosure. ExpressLRS, when attached to a flight controller with sensors, will transmit back to your handset the GPS location, altitude, flight mode, and other telemetry details about your flight (which, let's be honest, is probably in your video OSD too). An attacker with the right equipment, knowledge, and motive can decode those packets and ascertain where your aircraft is. The standard defense against this is encryption.

The second is forged inputs. Stick controls from your transmitter arrive at the aircraft and tell it where to go. An attacker with the right equipment, knowledge, and motive can follow your hop sequence, and transmit more powerful packets with controls to change the flight path of your aircraft. The standard defense against this is not encryption, but signing. Your stick positions aren't secret, you just want authentication and integrity.

What would a bad guy actually do?

Is it strictly possible that an attacker goes out after you, a hobby pilot flying around a forest or bando, armed with a specially-crafted firmware on a $300 SDR and amplifier setup, or a modified ExpressLRS transmitter designed to follow your hop sequence, waits in place with everything ready to go, intercepts your link, transmits with more power to override your controls and flies off with your drone? I guess, sure. They could also:

  • Use a $10 RF jammer from AliExpress to kill the whole band
  • Use a $5 pipe wrench to hit you on the head while you're in the goggles
  • Use their $0 eyes to look up and see where your aircraft is and then use a $0.50 buckshot shell to shoot your aircraft down

All of these are more likely, and just as illegal.

"But what about in military use??"

It is the explicit goal of the ExpressLRS project not to support use cases in military or warfare applications. Period. Having to comply with ITAR is, and you can quote us on this, "bad vibes". We will not harden ExpressLRS against that kind of adversary, and we won't entertain proposals that would do so.

"But why not add encryption anyway?"

We've got a bunch of great reasons.

First, ExpressLRS works as well as it does because we keep packets short. 8 bytes over the air. For any kind of actually defensible security that would stand up better than a wet paper bag, you need 4-8 bytes for the authentication tag alone, so that would come at the cost of range, and not a small impact.

Side note

We've independently audited several publicly available "encrypted" RC links and found trivially exploitable flaws in them that render their real-world security null. It's hard to do proper security over a slow, unreliable link.

Side side note: we're choosing not to publish these. Don't ask.

Second, it's another thing that could break, and we'd rather you not failsafe. How do you reconcile replay protection against link recovery after a brownout on an inherently lossy link? Either one is a compromise on the other, and link confidence is our #1 priority.

Third, many pilots run their gear under amateur radio license rules. In the US, 47 CFR 97.113(a)(4) prohibits "messages encoded to obscure their meaning" aka encryption. Most other countries have similar laws. That'd make ExpressLRS illegal to use at power levels you want to use it at, on the gear you want to use it on.

Fourth, and we cannot state this enough, export control is a bad vibe, and the authors are uncompensated. You would have to pay us very well to deal with the relevant paperwork, and $0 is a bad place to start.

"But why not add authentication?"

Just like above, we'd be trading reliability for a defense against an issue that'll, statistically, never happen to our target users. Replay protection means we'd need to failsafe on power loss - even in a real attack you can't do anything except failsafe. So you'd gain functionally no benefit in exchange for the real risk of introducing new bugs and issues.

Priors

The following is a list of things we know. If your "security report" boils down to this, we've probably sent you a link to this section. Your input will be taken under advisement.

  • ELRS packets can be received and decoded
    • Man we hope so. If all goes according to plan, yes.
  • The FHSS sequence can be reconstructed from over-the-air traffic or the binding phrase
    • The FHSS sequence isn't a secret either.
  • The CRC is designed to catch random bit flips
  • The UID or binding phrase can be recovered or brute forced
    • Yep. The UID seeds the CRC and FHSS, so it can be teased out, and the UID can be MD5 lookup table'd to obtain the binding phrase. If your phrase is a dictionary word, we already built the table btw.
    • Half of the development team's binding phrases and UIDs are in the source code's git history. I mean, deadbyte's binding phrase is on expresslrs.org.
  • A second transmitter using the link's UID and hop sequence can take over the receiver
    • You'd need higher power, at which point you're already running a jammer so...
  • ELRS links can be detected and fingerprinted
    • Yeah, it's mostly FHSS 812kHz/500kHz LoRa on fixed channels, 8B or 13B packets. Pretty unique.
  • The firmware update WiFi networks use the same password
    • It's expresslrs btw. Anyone who's actually connected to it knows the range is about 5-10 meters. We recommend personal space.

Things we actually care about

Did you put in real effort and find something that's actually relevant? We'd love to hear from you. You can file GitHub issues, or email info@ this website. We'll gladly credit you for the change in our patch notes, and, for particularly compelling vulnerabilities, at the project's sole discretion, a $20 Olive Garden gift card will be offered.

  • A malformed packet hangs a receiver or transmitter
  • Configuration or state corrupted via a malformed packet or behavior
  • A receiver accepting control from a packet sequence with a different UID than the one it's bound to
  • Something on our website, web updater, Discord config/bots, etc.

For pilots flying ExpressLRS

  • Your binding phrase is not a password, it's a unique ID so you don't collide with friends. Pick something unique but public.
  • If you're flying somewhere that you're worried about an attacker with an SDR forging packets, fly somewhere else.
  • Set up reasonable failsafe behavior for the environment you fly in and test it.
  • Using MAVLink and truly paranoid? You can enable message signing between your autopilot and ground station. I mean... I don't, but you do you.