AES on SiK Firmware

[Linus Casassa]

Hi Lorenz and Andrew,

I would like to discuss the rejecting intruders and encrypting the bytes in the air of the 3D Radios.

So it does not make any sense to me to do all this code in the Pixhawk and in all the GCSs if you look it in a conceptual way. It makes more sense to me that this task should be done by the radio or a new device that should go between the radio and the Pixhawk/GCS.

After talking to Tridgell and seeing that the 3D radios do not have more SRAM and XRAM free I found out that the RFD900u and RFD900p double the XRAM to 8092 bytes instead of 4096 bytes and have AES by hardware.

The price of these radios compared to the 3D radios is higher and they are not open hardware. But we could develop with these radios while 3D Robotics upgrade there radios with a Si1030 chip instead of the Si1000? Is this an option?

Andrew, do you think that with the double of XRAM space we can do AES?

Regards,

Linus

--

Linus Casassa
Fono: 56-9-97776941

[David Pawlak]

Just throwing ideas out.

Could it be possible to simplify the process, perhaps something similar to a DigiPass?

Rather than codify the whole message, perhaps just add 4 bytes to the message that are a time based encryption of some key entered at both ends.

If the code doesn't match for more than a couple of seconds, RTL

Might even be as simple as doing a CRC on a 16 byte key which has the time in text appended.

[Lorenz Meier]

Hi Linux / David,

I suggest to sift again through the sMAVLink RFC which was discussed in the DroneCode TSC meeting:

https://docs.google.com/document/d/1upZ_KnEgK3Hk1j0DfSHl9AdKFMoSqkAQVeK8LsngvEU/edit

The proposal there is an AES-GCM appended to each message, so essentially a cryptographically complete solution similar to what you’re proposing David.

@Linus: The solution you’re proposing is of course the easy way out - it essentially means deferring the issue to the transport layer. There are however a few issues with that:

- The current control model does not involve any authentication. Its like having no password for your email account / computer / bank account and just relying on the transport layer to make it secure. This however poses several issues:

  a) If your network is compromised, the attacker gains control over your drone. With more drones on the internet, that is worrisome.

  b) If the complete security relies on the transport layer, any party offering the transport layer becomes liable for the safety of the drone. This yields some interesting questions which I think will end up requiring a solution.

- It would leave tens of thousands of drones sold last year and this year vulnerable. Of course at the current pace of the technological development these will be flushed at some point out of use. But until then they remain at risk. A safe point to stop supporting the current radio generation in terms of security would be when the next generation is commonly available, which I don’t see quite happening yet.

All in all having some sort of reasonably safe authentication in the core flight control layer would allow us to simplify things on the higher layers, in particular on companion computers. Similar to how apps authenticate against the OS app armor layer on mobile phones it would allow to build some basic security / isolation into the system. Of course there is always the question where to set the layer for an API cut. Given that we can address several issues at once it seems worth a try though.

-Lorenz