Mavlink security problem

#1

Dear All,
I’m sorry if I am off topic. But I don’t know exactly which section is more appropriate for MAVLINK discussion.
I’m a newbie in MAVLINK, and I read, in old posts on Internet, that it presents a security problem. In particular, the security problem seems to be the lack of encryption for the transmission of “netid” field. This would permit a prowler to gain control of our drone

About the topic see i.e.

My question is if this problem, in MAVLINK 2.0, is still present. In this case what kind of workaround is possible to carry out?

Thank you so much.

#2

air interface is exposed to public attack so it is not a surprise if someone can hack into an radio protocol as Mavlink.

In 2.0 signature mechanism is introduced to make it more difficult to hack into, but not implemented so far as i know.

Enabling the signature will slow down the CPU if it is not supported by hardware locally, that is also one practical problem one need to take consider into.

#3

Hi,
I have found this link

What do you think about? It seems that there is an implementation but the setup is still missing. Am I right?

Sorry for the stupid question: if I implement the signature (in the flight controller) it will impact on ground station and radio controller? If Yes which change have I take into account?

Considering the development of the laws for UAV usage and aviation safety standards, how is it possible to not take into account such issues? Sorry for the newbie questions, but I’m trying to understand the context and the possible problems to be compliant with the norms.

Thank you for your kind reply and for your help to understand.

#4

If we keep digging into the issue then at then end of it most probably is cost.

air interface security is a critical challenge to all radio protocols, not only Mavlink. In civil aviation the threaten are less as airplane does not rely on ground remote control and all main lines are in closed loop inside the plane. That been said, you can still easily hack into the UHF/VHF channels.

Radios on UAV started with low cost radios like 433/900 MHz, which you can find them widely used in wireless door bells, TV remotes, car remotes, etc. These radios are almost ‘naked’ in front of hackers, but you just do not notice them in daily life as that even not worth caring.

Comprehensive encryption techniques can be added into eventually, but that would require hardware upgrade at both ends of the remote control system, which will increase the cost for sure.

And for advanced radios like Wifi, protected under comprehensive encryption, and still have the chance to be broken into.

So for UAV radio security is more notable than other scenario as it relies on remote radio control. But if you would like a serious implementation that will go beyond the scope of hobby applications, mainly in sense of cost.

#5

Hello,
I think you have framed the question very well. The point is that being a professional UAV user, I would like to start producing my own fleet. But in this case, I cannot ignore security issues. Assuming that the cost is not an unsurpassable problem while remaining with an open platform like PX4, what should I do to insert cryptography in data transmission? PX4-based flight controller solutions would not be sufficiently CPU-efficient? Which radio controllers should I use?

Thank you so much, you helped me!

#6

You can try to enable signature in mavlink 2.0 first. I personally did not test SHA256 hash performance but i will not surprise if that slow the processor down, and, as more bits needs to be transferred over air, you may suffer larger probability of packets loss. I do not think current main stream processor has hardware acceleration for that. If you try to use a different processor then you need to port the PX4 stack to that processor.

The other aspect will be to find a radio channel with robust encryption support like AES/RSA, etc., cipher. Again as more information needs to be exchanged you will experience more chance of link broken or packet loss, which, basically ask you to use more complicated channel coding scheme to reduce that effect.

All these i do not think are available in open source space and needs to be explored other than simple insertion of one or more components to accomplish a pro solution.

#7

You could try a completely different radio system that has built in encryption. It will cost a fair bit of money though. eg: Microhard pDDL devices.

#8

ArduPilot has MAVLink v2.0 signing implemented, it was the reference platform that demonstrated it. Works fine and is efficient.

#9

Hello guys,

is there any implementation of security communication between QGroundControl and PX4 using MAVLink ? I must have a secured communication in my academic project between QGroundControl and an UAV on PX4. I was first searching to encrypt all the messages exchange between each parts. There is a better way that already implemented ?

Thank you in advance.

Louis

1 Like
#10

MAVLink v2 can have signed packets

#11

Hi,
Im new in this fieled, how can i change from MAVLink V1 to MAVLink V2?
I have noticed that MAVLink V2 added a feature for packet signing, but it still not be implemented, If no how can i enable packet signing?

#12

Hi magicrub
im working on securing MAVLink , i noticed that MAVLink v2.0 includes packet signing function.
So first, when checking my current MAVLink version, i get confused because in ardupilot folder ardupilot/build/sitl/libraries/GCS_MAVLink/include/mavlink/v2.0. indicates that mavlink is v2.0, but packets sent by Ardupilot begins with 0xFE (the protocol start-of-frame: 0xFE) which indicates that this corresponds to MAVLink v1.0.

Also, i checked the mavlink-helpers.h file and it contains the function packet-signing which is probably related to MAVLink v2.0.

Really i get confused
I want to ask you when i immigrate from v1.0 to v2.0, how can i enable packet-signing?

#13

Ardupilot has the ability to auto-detect your MAvlink version and promote itself up/down if you have yourself set one one, but talking and understanding on the other version. This is on a per-port basis.

Most of that logic is in here

Search for “AP_SerialManager::SerialProtocol_MAVLink” or “AP_SerialManager::SerialProtocol_MAVLink”. For help setting it up, check the Ardupilot wiki http://ardupilot.org/plane/docs/common-telemetry-port-setup-for-apm-px4-and-pixhawk.html and ping us on discuss.ardupilot.org.

Here on PX4, I don’t think that auto-detect logic exists. You force it to one or the other. ArduPilot has a just-works detection ability that helps with migrating people. Since ArduPilot’s market is a few orders of magnitude larger, we have to worry about how a “simple” change like that could disable millions drone’s datalink.