The OpenHD project has a potential security flaw when using the system with Mavlink telemetry uplink.
All Mavlink messages are send from a connected Ground Control Station to the air unit (and therefore to the flight controller) without any authentification or encryption. Therefore, any other OpenHD sender in range can transmit Mavlink messages with valid commands on itself, and the flight controller will accept them, if they are setup correctly.
So, it is possible with very little efford to inject valid Mavlink messages over-the-air. Due the nature of Mavlink, it is possible to control the complete drone using command messages, it is easy to even hijack the system.
In this proposal, we describe a simple encryption mechanism to avoid this and to secure the relevant uplink channel from ground to air, using the libsodium lib and XChaCha20 encryption with a simple one key signing.
- First, we define a 32 byte long secret key. We use the same key for en- and decryption.
- Second, every Mavlink message paket gets encrypted and extended with the an authentication tag and theencryption nounce. The libsodium encrypts the message with this nounce (that can be public visible) and the secret key. The result of this enrcyption is a data paket and authentication tag. It’s length is MAVLINK_MESSAGE_SIZE + MACBYTES). for the final data paket that will be sent over the air, we add the public visible nounce in front of the encrypted data.
- So, our final paket will be: NOUNCE (24 bytes) + MACBYTES (16 bytes) + encrypted Mavlink message. The Nounce is discarded after the paket encryption, abd a new nounce will be created for the next package.
Advantages:
- Every single Mavlink message is enrcypted with a very secure algorithm with a unique nounce.
- You have to handle only one key.
- The encryption and decryption is fast and resource-saving.
- In case of pakets getting lost over the air, the mechanism is totally undisturbed, because unlike a stream encryption, every paket is handled seperatly.
Disadvantages:
- Every paket is extended with 40 additional bytes of data. In case of a Heartbeat Mavlink1 message, this leads to 40 additional bytes for a simple 17 bytes long Mavlink message. Not very effective.
Conclusion:
Since the goal is to secure the command stucture of the Mavlink telemetry, it is only necessary to encrypt the uplink channel from ground to air. Since the number of messages from ground during normal operation is very little (unlike the high amount of messages sent from air downto ground), the disadvantage of the message size blow up seems to be quite acceptable.
In practice, other encryption methods, based on streams, are are very prone to interferences from paket losts. So the approach to single paket encryption and its robustness seems to seems to outweigh the disadvantages.
Current Status:
The patches are available and we are currently testing this practically in real. Any thoughts and comments on this proposal are very welcome.
