5

Let's say I have a drone that is controlled through radio and I would like to make sure that nobody else can control and gain data from it except for me.

I could encrypt the data with a cipher and only send encrypted data back and forth, which solves the problem of securing data. It does not however help me with controlling my drone. For example, if I tell my drone to move to the right, couldn't someone else intercept that command and execute it again at an undesirable moment by just resending the exact same data?

How can I prevent this? Also, will this solution still be valid with a not insignificant amount of packet loss?

techraf
  • 9,141
  • 11
  • 44
  • 62
user50213
  • 53
  • 5
  • 1
    Can the drone communicate back to the controller? Can it acknowledge a packet receipt? – Neil Smithline Jul 09 '16 at 23:24
  • Yes, there is two way communication. – user50213 Jul 10 '16 at 00:34
  • you can use shared secrets to authenticate. – dandavis Jul 10 '16 at 02:59
  • One of the classical solution to deter replay attacks is the use of a nonce. Or in your case, a simple sequential number could help: you are at position X of stream of commands, so drone is waiting for command labeled with position X+1 (encrypted) and nothing else. If someone intercepts old packets they would be discarded because out of sequence. – Patrick Mevzek Jun 04 '18 at 22:29

2 Answers2

4

There are commonly two methods of controlling drones. Radio receivers and data transceivers (traditionally telemetry links). This really varies by device, autopilot hardware, etc. Some even use WiFi for everything. Receivers typically are receive-only, and convert received signals into PPM or PWM signals to speed controllers, servos, etc. Transceivers typically convert data into serial or possibly connect to another data bus such as I²C.

But let's say you have a traditional drone with both a receiver and a telemetry radio to the autopilot, you may need to address security of both. You mention encryption, and this provides confidentiality, but I think what you're really after is authentication. How can you ensure the radio sending the commands is really yours?

Radio receivers typically use a pairing method, similar to a garage door, where a key or sequence is exchanged prior to use. In this way, a transmitter (handheld unit by the pilot) is paired to a receiver or multiple receivers in the drone. There are a number of ways this pairing is accomplished, you can look at the source code of Deviation which supports many protocols and pairing methods. These are frequently vulnerable to replay attacks.

Transceivers come in all sorts of configurations. In the past, many used FHSS to "secure" the communication. More realistically, FHSS provides interference avoidance. Some proof of concept take-over methods have been demonstrated. Some common sense things here to protect the radio communication would be using a mutually authenticated protocol such as TLS. Each protocol will require their own solution, but I would focus on authentication, and that likely involves encryption to achieve. Certainly a pre-shared key may meet your solution.

However, there is little you can do to avoid interference and should have some failsafe for when communication is lost or significant interference occurs. Receivers typically need very little bandwidth, and frequently many receivers can operate in the same space safely. So even with unintended interference, it may not be a problem. Data transceivers and WiFi-based units will be much more susceptible to interference and at risk with dropped communications.

mike_b
  • 156
  • 1
  • I understand up to the key exchange part, but what I'm asking about is how that prevents someone from replicating data you send. For example, lets say that the drone and I have exchanged keys and I am authenticated. When I tell the drone to veer left, another person might intercept the packets and replay the exact sequence to the drone. The drone will recognize these packets as a veer left command, and it will also be authenticated because this person is using the packets that I sent before. – user50213 Jul 10 '16 at 00:46
  • 3
    It depends on what you do after key exchange. TLS itself is not vulnerable to replay attacks, so things you wrap in it shoudl be protected. You can read more here http://security.stackexchange.com/questions/20105/are-ssl-encrypted-requests-vulnerable-to-replay-attacks – mike_b Jul 10 '16 at 01:29
  • 1
    FHSS (or more specifically, DSSS) when used properly can _completely_ prevent interference. Creating white noise interference on a wide band would require a _lot_ of power. Think: plugged directly into a power plant. If the sequence key is not known, it can be extremely successful at blocking interference. – forest Jun 05 '18 at 02:56
-2

The solution is a time sensitive evolving key. No identical subinterval is encrypted the same way twice. Another way to look at it is that the entire flight time is the interval that has a data transmission rate. The rate multiplied by the time gives total bits. For example, if it requires 1 gigabyte per second of encrypted transmitted data to control the drone, and the flight time is 480 hours, then the key that encrypts the flight control data literally gets consumed as the drone flys. In this particular case, the bit stream would have to be 1.728 Million gigabytes of random data recorded as a single stream key before takeoff. The entropy introduced into the transmission prevents hacking by copycats, because no two seconds of flight has the same random bit stream modulation. However, this is military level intelligence. Not your common remote control toy. These drones can carry anything, including nukes.

  • 2
    This complex and unwieldy "solution" can be achieved instead by using one of any number of trivial replay and reflection attack mitigations. There is no need to go to such lengths when replay attacks have been mitigated in standard protocols for decades. – forest Jun 05 '18 at 02:58
  • 2
    ... also what kind of remote control needs one gigabyte per second? – user253751 Jun 05 '18 at 05:23
  • @benjamin - your post makes no sense in the context of the question, not even in the context of a military nuke. Remember military level isn't really a thing when it comes to encryption. Everyone has access to strong encryption. – Rory Alsop Jun 05 '18 at 08:55