After being in service since 2009, its time to evolve MAVLink and add encryption, starting with a Request for Comments (RFC). The initial MAVLink protocol had only the scope to serve for the PIXHAWK student project at ETH, and hence security was left for the link layer. Obviously the adoption is far beyond the scope of the original design by now. After Arthur's great job on the MAVLink Wikipedia article there is no further need to explain what MAVLink exactly is, but there is one important insight: The adoption and use exceeds by far the original design space, in particular because typical links do not provide authentication and encryption, which was originally assumed.
With more and wider adoption, the exposure of the protocol increases, and so the next revision (which will be backwards compatible if by any means technically possible) will add support for authentication and encryption.
The purpose of this post is to ask for comments on the very early draft of a request for comments call posted today. We're interested in technical contributions (specs, code, testing) but also in general considerations. At this point it is too early to discuss which hardware it can be run on, it will certainly run fine on PX4-generation systems (a first test of the crypto primitives is here), and there is currently no reason to assume that other existing aircraft setups can't be upgraded in a modular fashion as well. Please respond directly for the mailing list thread here for comments on the RFC, for general comments on this post feel free to use the comment box.
Comments
How is this effort going? Is it still active?
one thing that initially will hold back progress in this area is the choice of the STM32 F427 processor for the PIXHAWK processor instead of its hardware crypto brother costing a grand 2 bucks more the STM32 F437.
encryption and authentication pay a crypto tax consisting of processor cycles.. best to export as many of those cycles into hardware as possible especially when its only 2 dollars more.
Ah Chris? would it be possible to get a few PIXHAWKs stuffed with the STM32 F437 variant and into the hands of developers? (ie my market I am looking at is the security/LEO market and I need hardware crypto in as litlte weight and power consumption as possible.
I am awaiting a Y6 config at present due to be delivered with the APM 2.6 hardware and had planned on recycling the APM to another airframe and getting a PIXHAWK for the Y6 but the STM32 F427 is what is holding me back as I definitely want to put in a hand at the secure MAVLINK protocol RFC / development also and hate to waste cycle paying the crypto tax when it isnt necessary.
hzl
I am eager to participate in the development of this, as it aligns perfectly with my thesis research. Please let me know how I can help! I'm working solely on this endeavor for the next 4 months (because I'm doing this in graduate school for my Master's Degree)...
yeah i understand the current mavlink does not, when you were talking about the current design not being adequate i thought you were contemplating designing a new module :)
@Jared Reabow
I don't think MAVLink is the best protocol for transmitting video data.
And with the current telemetry modules you don't have the necessary bandwidth. You could have the bandwidth if you are using something like MAVLink->TCP (or UDP) -> WiFi, but then why restrict yourself to working in the MAVLink layer?
would it b a possibility to have mavlink integrated with a digital video signal, so when you transmit telemetry you can also have a compressed image stream?
This is a big step forward. Hope folks here who are interested in crypto/security can contribute.
Nice feature Lorenz, it's probably the only thing missing on MAVLink for it to become the de facto standard for micro unmanned vehicles. I'm glad to add support for it on DroidPlanner.