|RFC: Towards secure MAVLink (sMAVLink)||Lorenz Meier||8/5/13 6:18 AM|
This is an official request for comments on an evolution of the MAVLink protocol adding authentication, later potentially encryption, to it. While encryption is more of a long-term goal and there are many ways (including utilizing well-established prototocols to encapsulate the MAVLink stream) to do it, adding authentication does in real-world scenarios provide most safety-relevant aspects:
Nikos Karapanos has created a first early draft / proposal I'm sharing here. He also did an early testing prototype, which is available here:
So essentially we're looking for comments, contributors (= people hacking on code most welcome) and want to have a prototype implementation ready quite soon.
Below is Nikos' draft:
--- DRAFT / Under Construction ----
Secure MAVLink (sMAVLink)
This document describes a security-enhanced version of MAVLink, sMAVLink, with the goal of providing protection (confidentiality, integrity, authenticity) against remote attackers.
sMAVLink enables a ground base station, its associated ground modules (e.g. antennas) and its associated group of MAVs to securely communicate using the MAVLink broadcast protocol. Whenever one of the previously mentioned entities broacasts a messsage through sMAVLink, all of the remaining entities can decrypt and verify the authenticity of the message, but not an external attacker.
II. Current Setting
A ground base station (GBS) coupled with some ground modules (GM) and associated with a group of MAVs. Currently the communication between all these entities occurs using MAVLink, which is a broadcast protocol, that has no security built-in, i.e. everything is sent in the clear and unauthenticated. sMAVLink adds security over the established protocol.
III. Attacker model
The attacker has full, unrestricted access on the communication medium, i.e. the wireless link. She is able to eavesdrop on all the wireless traffic that is generated by the ground station and the MAVs. She is also able to arbitrarily modify, drop or insert new MAVLink frames at will.
sMAVLink does not prevent DoS attacks. Additionally, physical attacks (either on the ground station or any of the MAVs) are currently out of scope. If an attacker gets his hands on the real hardware, we assume the secret keys compromised, as she can extract them relatively easily and hence defeat sMAVLink. In this case an execution of the protocol "bootstrap phase" with fresh secrets is necessary (more on this below).
IV. Employed Cryptographic Primitives
sMAVLink is exclusively based on symmetric key cryptography for performance and energy efficiency reasons. It makes use of the following cryptographic algorithms:
- AES-GCM (Galois Counter Mode): Used for providing authenticated encryption for every sMAVLink frame that is created and broadcast by any entity. AES-GCM takes as input a secret key S, an initialization vector IV, additional authentication data AAD, and the plaintext PT. It ouputs the ciphertext CT and the authentication tag T. The sender sends IV, AAD, CT and T to the recipient, which in turn will process this data using AES-GCM under the same key S, in order to check the authenticity and integrity of the message and recover PT. A couple of notes:
- IV has to be unique for every message encrypted under the same key S
- AAD is data that is sent out in cleartext (not encrypted), but they are nevertheless authenticated, which means if the attacker manipulates AAD then the authentication part of AES-GCM will fail.
- SHA-256: Used in the key derivation functions.
V. Protocol Description
We describe the phases of the protocol in the order that they logically take place:
The purpose of the bootstrap phase is to make sure that all involved entities share the same long-term secret, called Master Key (MK). This phase has to be executed only the very first time that we want to setup sMAVLink, and additionally in the case where for some reason we want to change the MK (e.g. MK was compromised by an attacker who gained physical access, or just precautionary periodic refresh).
The GBS, which acts as the coordinator of the whole protocol, uses a cryptographically secure pseudorandom generator to create a fresh MK and broadcasts MK to the rest of the group (MAVs and GMs) in CLEARTEXT. All entities store MK in persistent storage.
IMPORTANT!: Since MK is just transferred in the clear, this phase requires that all the involved entities are physically connected via a wired link, such as USB, in a physically isolated network, in order to prevent eavesdropping. Nevertheless, the transfer can be performed wirelessly, under the assumption that no attacker is present during the bootstrap phase.
2. Session initialization
The GBS uses a cryptographically secure pseudorandom generator to create a nonce (N). It then broadcasts N. All entities use MK and N in order to derive a Master Session Key (MSK).
Each entity, derives its own session key, called Entity Session Key (ESK), based on the MSK and the entity ID.
Notice that every entity can derive the ESK of every other entity, because it knows the MSK and the respective entity ID.
In total, we have one ESK per entity. For performance reasons, it is recommended that every entity derives once and stores the ESKs of all entities on RAM. Alternatively, an entity could derive the required ESK every time it receives a message originating from a specific entity, but this is expected to hurt performance and energy consumption.
Since the sMAVLink uses AES-GCM, each entity needs to supply a unique IV per encrypted message (sMAVLink frame) it sends. Upon session initialization, every entity sets its IV to 0, and increases the IV monotonically for every message it sends.
Before this phase is considered completed, every entity has to broadcast an encrypted acknowledgment.
#TODO elaborate more
3. Session communication
Assume that an entity i wishes to broadcast a message using sMAVLink, after the session has been initialized (previous step). i uses its ESK, which we call ESKi and the current value of its IV, called IVi, in order to process the packet using AES-GCM. The System ID field of the original MAVLink frame, which is also part of the sMAVLink frame, corresponds to i (i.e. each entity has its own System ID, which is reflected in the respective field of every sMAVLink frame it sends). Addiotionally the sMAVLink frame contains the IV value that was used when performing AES-GCM on this message (IV is not a secret). The various header fields of the sMAVLink frame are part of the AAD that is input to AES-GCM, and hece they are authenticated.
Upon receiving the sMAVLink frame, the rest of the entities look into the System ID field in order to determine the sender i, and then use the respective ESKi and the IV, which is contained in the sMAVLink frame itself, in order to authenticate and decrypt the message. Notice the following:
- If the System ID, the IV, the payload, or any of the AAD of the sMAVLink frame is modified by the attacker, the AES-GCM authentication step will fail.
- In order to prevent replay attacks, each entity keeps not only the ESKi of each entity i, but additionally the last seen IVi. The legitimate entity will using monotonically increasing IV values, so the last seen IVi will be ever increasing. If an attacker tries to replay an old message, its IV value will be less or equal to the last seen IVi and the recipient will just reject this message.
4. Session Reset
#TODO: Initiated by the GBS. Basically more or less the same as session initialization, forces the creation of new session keys and the reset of IVs.
VI. Implementation Details
AAD - Additional Authentication Data
ESK - Entity Session Key
GBS - Ground Base Station
GM - Ground Module
IV - Initialization Vector
MAV - Micro Air Vehicle
MK - Master Key
MSK - Master Session Key
|Re: RFC: Towards secure MAVLink (sMAVLink)||Lorenz Meier||8/5/13 6:36 AM|
One correction due to a slightly misleading wording on my side: The main benefit for everyday users will be the authentication (=safety), however, Nikos' proposal already includes encryption, and the implementation of both in parallel should not take more effort - so please cover both aspects in replies, thanks!
|Re: RFC: Towards secure MAVLink (sMAVLink)||Arthur Benemann||8/5/13 11:53 AM|
I would like to implement the new secure protocol on DroidPlanner, but probably it's better to wait until it is stable.
But since I don't have a clue on cryptography I'll need some help. The biggest problem is that I don't own a PX4 board, is there any way to simulate the code? Currently I do most of the development with ArduPilot code, using the SILT simulator.
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||8/5/13 12:29 PM|
I'm quite happy to assist as I am familiar with crypto and android programming. However, I think we should wait for the implementation to be completed and verified first.
On 5 Aug 2013 19:53, "Arthur Benemann" <arthur....@gmail.com> wrote:
I would like to implement the new secure protocol on DroidPlanner, but probably it's better to wait until it is stable.--
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||PIXHAWK||8/5/13 1:22 PM|
I think we're starting to run with this discussion a bit into a chicken and egg problem. We only can finish the first implementation with more comments, and the comments require the review of the implementation 8).
I think on the cryptographic side we have an integrated approach and so far no reasons to divert from it. The next problems to takle are:
1) Frame formats - preferably in a backwards-compatible fashion to 1.x
2) Related: Scope of the encryption - whole packet, just payload? Just message ID + payload?
I'm sure I have forgotten many more considerations - Gareth, could you maybe take a stab at 1+2, with this as background?
Am 05.08.2013 um 21:29 schrieb Gareth Owen <dr.g...@gmail.com>:
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||dr.g.owen||8/5/13 1:34 PM|
Of course - I've looked through the mavlink document before - but one thing I cannot find is a standard frame structure table like you might find in an RFC.. does this exist? I just wish to know, the order and size of mandatory fields. e.g., magic numbers, length field, crc field, etc.
Is Nikos not participating any more?
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||8/5/13 1:35 PM|
Oh never mind - I've just found it! I swear that wasn't there a few months ago!
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||PIXHAWK||8/5/13 1:42 PM|
No, Nikos will certainly participate further quite actively, but the purpose of putting all this out there is to get some external ideas and some more eyes to look on this. I don't think we have to split the work exclusively, it can (and should in the beginning) also some rather unorganized ad-hoc work until we're fond of the prototype we have. No reason to discuss / try different approaches, in particular on the frame format.
Am 05.08.2013 um 22:35 schrieb dr.g.owen <dr.g...@gmail.com>:
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||PIXHAWK||8/5/13 1:44 PM|
Sorry - I meant no reason to NOT try different things now 8). I think some diversity and then consolidation will make sure we have explored all potential ideas.
Am 05.08.2013 um 22:42 schrieb PIXHAWK <pix...@switched.com>:
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||8/5/13 1:54 PM|
OK, then in that case my suggestion is as follows:
Define two new message types:
Crypto Nonce Broadcast - allowing each node to derive it's session key - need to prevent attackers doing this too via replay (Nikos?)
Crypto Payload - encrypted mavlink payload.
When the message ID is payload, then:
- Header remains the same, but the sequence number should be enlarged to 32bits and used as the IV. There are several ways this could be extended without corrupting the current header structure to maintain backward compt (e.g. using first few bytes of payload - the LSB could be placed in the existing seq number position.)
The CRC should be extended to be the same size as the tag - and replaced with the tag. Although if backward compatability is destroyed by this, the tag should be appended to the payload and the CRC left alone.
When using GCM, the header should be unencrypted but be authenticated by the tag as Additional Data (AD). The payload should be encrypted and authenticated (AE).
That's a fairly simple proposal that maintains backward compatability. Just two new message types.
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||8/5/13 2:14 PM|
When msg type = CRYPTO_PAYLOAD
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Lorenz Meier||8/5/13 2:20 PM|
I've created a Google Document you can freely edit and collected everything so far. Please edit directly!
Institute for Visual Computing
Am 05.08.2013 um 23:14 schrieb "dr.g.owen" <dr.g...@gmail.com<mailto:email@example.com>>:
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Karapanos Nikos||8/5/13 5:45 PM|
- I made the following change in the online document: The bootstrap phase should only take place over a channel that is assumed to be reliable/trusted (e.g. USB). Bootstrap messages received via untrusted channels (e.g. wireless) should be rejected, since they might originate from an attacker that pretends to be the GBS.
- Session initialization should be protected from replay attacks, as Gareth says. Some solutions that come to my mind:
- We need some kind of challenge response protocol. The MAVs will challenge the GBS either with a random value (we have to implement a cryptographically secure RNG on the MAVs) or a monotonically increasing value, in order to verify that it was the GBS, and not the attacker, that sent the nonce N.
- The GBS uses a monotonically increasing value as nonce N, which is tracked by the MAVs.
- Regarding the frame format, I also believe that it should remain unchanged and backwards compatible. I agree on the format that Gareth proposes. I would use different message types for the bootstrap phase and the session initialization phase, though.
- A side note that came to my mind: The simple session initialization protocol that I propose, does not provide perfect forward secrecy (http://en.wikipedia.org/wiki/Perfect_forward_secrecy). This means that if the attacker manages to recover the MK (e.g. by physical attack) he can decrypt any previously captured encrypted traffic. In order to solve this, we would need a more sophisticated key-exchange protocol (some diffie-hellman variant). Probably perfect forward secrecy is not very important in our context, but I am just mentioning it, in case you think it is.
On 5 Aug 2013, at 22:54, dr.g.owen <dr.g...@gmail.com<mailto:firstname.lastname@example.org>>
--Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an mavlink+u...@googlegroups.com<mailto:email@example.com>.
Weitere Optionen: https://groups.google.com/groups/opt_out
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||8/5/13 11:14 PM|
Hi Nikos et al
The reason I mentioned the password is that users sometimes have multiple ground stations, some which they may initialise after the drones have been setup (e.g. andropilot) ... but then we have a nonce sync issue too (see next pt).
I think a monotonically increasing nonce where nodes reject lower values will satisfy requirements and eliminate the need for challenge response.
Forward secrecy isn't important imho.
Do you have a proposal for session init ?
|Re: RFC: Towards secure MAVLink (sMAVLink)||Ye Wang||8/15/13 2:49 AM|
Some suggestions against physical attack:
1. Encrypt the Master Key on both GBS and UAV. The key used to encrypt MK on UAV is stored on GBS together with its entity ID. I call it a ID-Key pair. Those pairs are also encrypted like the MK on GBS with a user key. Like the password we use to log in to our operation system. The user key is required each time establishing connection with UAV.
2. A secure channel is established in prior to sMAVLink Session initialization. This can be done with any asymmetric encryption schemes like D-H or RSA. After the channel established:
a) UAV sends its entity ID to GBS to ask for the key to decrypt MK.
b) GBS asks user to input the user key, then decrypt the ID-Key pairs and lookup for the UAV entity ID.
if (the ID is unknown or someone else gets the UAV!)
GBS denies the UAV's request
else GBS returns the key to UAV, then follows with sMAVLink Session initialization phase.
3. After sMAVLink Session initialization, it's preferred to erase the user key, decrypted ID-Key pairs and MK from memory in GBS, to prevent attack like cold-boot attack.
|Re: RFC: Towards secure MAVLink (sMAVLink)||crashmatt||8/15/13 11:15 PM|
What is wrong with using ssh or whatever well tested encryption is already available? Why reinvent the wheel?
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||PIXHAWK||8/15/13 11:24 PM|
The fact that you propose a solution based on an asymmetric key system (which is computationally likely infeasible and at the least undesirable within the current limitations) implies that you might want to investigate the requirements of the application further before making any claims with respect to the current proposal.
Please also understand that a large part of the internet security layers are built on reliable links (TCP), and the fact that packets can easily drop in our application needs to be considered as well, because a lot of the existing protocols (or at least the implementations of those protocols) potentially fall over once packets drop. Each one would have to be tested.
Last but not least: We're aiming here at a solution the average autopilot can easily implement. If you propose to use an existing solution, would you please be so kind to also point us to a software package that compiles, executes and does not eat up all autopilot resources onboard? Please save us the Rasberry PI argument for this matter, the proposal we have here works everywhere and transparent to user, pulling in the complexity of a companion computer is not at all worth the benefit, nor would I want to rely on Ubuntu not crashing my flight-safety relevant command and control link.
I appreciate your feedback, but if you criticize, you will have to provide something to work with at the same time.
Am 16.08.2013 um 08:15 schrieb crashmatt <uavfligh...@gmail.com>:
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||8/16/13 12:36 AM|
I think we are just waiting for Nikos to suggest session init changes and we are good to go.
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||crashmatt||8/16/13 1:12 AM|
Got it. No co-processors allowed and you are PX4 power limited and aiming at the average user. The existing wheel was not round enough.
Would be interesting to know what level of encryption this is. Is it at the level of the slightly breakable SHA1 or the better SHA256?
None of this helps to protect the keys but that is a different story.
I suspect that anyone with high levels of paranoia will use a secure co-processor with physical barriers against key tampering. I don't believe that are that many users of PX4 in that category.
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||8/16/13 1:16 AM|
All the details are in the first post. Sha1/256 is a hashing function, not an encryption function.
We are using AES in Galois Counter Mode. I suggest you read up on and understand that and then rejoin the discussion.
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||crashmatt||8/16/13 1:28 AM|
I think I just got your motivation for doing this. It is to secure android, not the radio link.
|Re: Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Lorenz Meier||8/16/13 1:36 AM|
I'm not sure if we currently discuss the same thing. The motivation here is to provide a reasonably safe (= not hackable with normal processing power close to real time) link. The one-time safe key exchange is not a problem, since the typical UAV workflow is to configure the system with the GCS connected via USB anyway.
This can mean that the GCS and autopilot handle the encryption (which will be the first stab), and potentially later that a variant of the 3DR radio does this transparently.
Its not related to any particular autopilot, OS or GCS, its an extension to MAVLink. Its also not "weak" or "simple", but rather roughly the current state of the art in UAV industry. You might find solutions that are substantially cryptographically harder, but the vast majority will have no encryption or something along the lines of what we discussed.
Weitere Optionen: https://groups.google.com/groups/opt_out
Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an mavlink+u...@googlegroups.com<mailto:firstname.lastname@example.org>.
|Re: Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||crashmatt||8/16/13 11:13 PM|
Only now did I find the extensive and well written specification in your first post. All the answers were there already.
Apologies for the complete waste of time that was my posts.
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Ralph Hartley||8/21/13 6:29 AM|
On 08/16/2013 04:36 AM, Meier Lorenz wrote:*Everything* has to be re-keyed if the master key is compromised, which could be whenever a
pane is lost. (Including the repeater on the roof etc.)
It would make sense to use public keys for key exchange. Performance and energy use don't
matter, because it is done rarely, and not during flight. The code required for basic RSA
(not including key generation) is tiny. Smartcards (with very limited memory and processor)
In this phase the public and private keys of each entity are set. There are two special
entities: the Key Source (KS normally the GCS or GBS, it should be the component least
likely to be compromised) and Key Generator (KG normally the GCS, but the function can be
performed off line by anything). The KG generates key pairs. The KS stores the public key of
each of the other entities (it needs no key pair of its own). Everything else only stores
its own private key.
As before this phase requires a secure network, but it only needs to be performed once,
unless the KS is compromised, or new entities need to be added (and only the new entities
need to be connected).
The keys of compromised or lost entities can be deleted from the KS, preventing them from
sending or receiving messages on subsequent flights.
2. Session initialization.
The KS uses a cryptographically secure pseudorandom generator to create a Master Session Key
(MSK). It then sends the MSK to each entity encrypted with the entity's "public" key (which
isn't really public as only the KS has it). Each other entity decrypts the MSK with its
The rest of the protocol (starting with the second paragraph of Session initialization)) is
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Hugh||8/21/13 6:41 AM|
Ralf, no idea what is going ion with your signature, not seen anything like it before, but it appears to be corrupt.
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||dr.g.owen||8/23/13 4:17 AM|
We didn't really see PKI as necessary to fulfil the requirements we laid out in post one. Yes it allows key revocation - but most applications are a single, or small set of drones.
BTW Lorenz, I know we've set on libtomcrypt, but I'd just like to point out the STM32F4 has a cryptoprocessor - example code on stm site. Could easily add in a libtomcrypt module for this as a drop in replacement.
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||8/23/13 4:22 AM|
PS, Nikos, the microcontroller has a random number generator which is a true random source.
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Lorenz Meier||8/23/13 4:32 AM|
The AES engine makes it considerably more expensive and our initial assessment is that it won't provide a noticeable performance improvement. That certainly does not rule out to add support for it, and to make sure the software architecture is not intimately bound to one particular crypto backend.
Does the RNG come only with the crypto parts, or is that one also available for the non-crypto devices?
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||8/23/13 5:07 AM|
Ah ok I misread the stm docs and thought it was on all of them. I agree, the mavlink throughput is low enough not to incur a significant computational overhead without a cryptoprocessor.
The docs suggest the rng is part of the cryptoprocessor. But the proposal that Nikos made deliberately does not need one on the nodes.
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Ye Wang||9/28/13 7:37 PM|
According to the datasheet of the STM32 processor on PX4(http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00037051.pdf). It has a "True random number generator" on board. I've also verified it on my STM32F4Discovery board(STM32F407VG onboard, similar to the PX4 one). The RNG worked without the crypto parts.
在 2013年8月23日星期五UTC+8下午7时32分25秒，Lorenz Meier写道：
|Re: [MAVLINK] RFC: Towards secure MAVLink (sMAVLink)||Lorenz Meier||9/29/13 5:20 AM|
Thanks for updating us on this. That will really help.
Computer Vision and Geometry Group
Institute for Visual ComputingAm 29.09.2013 um 04:37 schrieb Ye Wang <wang...@gmail.com<mailto:email@example.com>>:
Weitere Optionen: https://groups.google.com/groups/opt_out
|Re: RFC: Towards secure MAVLink (sMAVLink)||РдҭяЇӨҭ Јѻє||10/1/13 11:46 AM|
Lorenz (and fellow interested MAVLink developers),
You mentioned being able to "encapsulate the MAVLink stream" to integrate encryption... I'm very interested in participating in the development of sMAVLink because it aligns perfectly with my graduate thesis research. However, because I'm afraid the development will not be complete until after my thesis is due, and I still want to experiment on measuring the "cost" of securing the protocol, could IPSec be used to secure the MAVLink stream (for my research purposes during the development of sMAVLink), even though it does not use IP?
I thought IPSec could only be integrated through proper configuration of the operating system, but the APM does not have an operating system... so does that lead to the conclusion that IPSec cannot be integrated in securing the MAVLink stream?
Thank you for your time & assistance in considering my questions. Please let me know how I can help (since my full-time job right now is this thesis research into the cost of securing the MAVLink protocol).
On Monday, August 5, 2013 9:18:13 AM UTC-4, lm wrote:
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||PIXHAWK||10/1/13 11:55 AM|
I think your analysis is correct - close to none of the platforms have IPSec available. Also note that while we appreciate your feedback, our horizon to prototype something workable is rather short - when would you want to conclude your thesis roughly?
Am 01.10.2013 um 20:46 schrieb Јѻє Мдяҭҷ <firstname.lastname@example.org>:
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||РдҭяЇӨҭ Јѻє||10/1/13 12:45 PM|
I suspected so... glad to know that my literature review produced at least one accurate assessment!
I must submit a draft of my thesis by mid-December, so I'd like to have my experiments completed before the end of November (so I can focus on the documentation in December). I have an APM 2.5 I am working with on the bench with an attached 3DR air-module and GPS module (which is useless because I'm working in a secured building), and I'm connecting to the APM with Mission Planner (as the "authorized" GCS) on Windows 7, and "attacking" the protocol from another laptop via mavproxy running in Kali Linux.
Although I am not flying my APM (because I do not have an airframe to use), I do have access to a small UAV with an APM that I think I'll be able to either experiment on their's or swap their APM out with my own. So, TL;DR —> I think I have all the equipment necessary to experiment and test out sMAVLink as it is developed. We have a test flight scheduled in 2 weeks where I will establish the baseline expirement (proving the vulnerability of the MAVLink protocol to eavesdropping, command-injection and DoS). Then another test flight is projected for November which is when I'd like to be able to run the same tests against sMAVLink (or some secured implementation of it if the official sMAVLink is still in development).
One more question still regarding the use of IPSec (then I'll let it go): if IPSec tools can be used to implement IPSec, and the microcontroller on the APM accepts code to be compiled and run (in lieu of an operating system), couldn't IPSec tools be integrated into the firmware that's loaded & run on the APM?? (I realize this might place a significant [possibly overwhelming!] burden on system resources — that's one of the primary objectives of my research: measure the "cost" of securing the protocol.)
Thanks again for the rapid response and including me in the discussion & development!!
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||10/1/13 1:04 PM|
IPSec isn't a viable option for APM for a couple of reasons:
1) The protocol overhead is high for a low bandwidth link.
2) IPSec is implemented in the Linux kernel, ipsec tools are merely the user mode interface code.
3) The APM is unlikely to have spare processor capacity to do any cryptography - reading recent posts we appear to be at the computational as well as flash limit.
Personally, Nikos' proposal for secure mavlink is straight forward and easy to implement. If you're familiar with cryptographic primitives and the AP code, it's possible to code an implementation into ardupilot in a couple of days max - but it'd need to run on a better processor like that offered in the px4 and pixhawk.
--Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "MAVLink" sind.
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||РдҭяЇӨҭ Јѻє||10/1/13 1:18 PM|
Got it.. thank you for the explanation! Again, I suspected as much. I just didn't want to dismiss any ideas assuming you guys had already considered them.
Although I only have a very crude understanding of crypto-primitives, I work in the right place where I should be able to get the help I need in developing a solution. If the development of sMAVLink culminates before I come up with an alternative, my research can at least provide the quantified performance analysis of its implementation — so my involvement could be mutually benficial! (at least that's what I'll tell myself)
Thanks, Dr. O & Lorenz!
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||РдҭяЇӨҭ Јѻє||10/9/13 12:14 PM|
You mentioned that we may have reached "the computational as well as flash limit"... Originally, I had planned to record/monitor the change in power consumption & CPU utilization to quantify the "cost" of securing the MAVLink protocol. Since then, I've discovered that the difference in power consumption is nearly negligible (especially when compared to the power consumption of the motor, servos, etc.), and the micro-controller processor utilization is 100% all of the time — so I'm not going to notice a difference in either. [discards metrics]
What parts of the autopilot (specifically the APM) will be affected by implementing sMAVLink (when compared to MAVLink)? Once I know which parts will "take a hit" I can work on devising a method to monitor those parts in order to evaluate the "cost" of securing the protocol.
Also, do you (or anyone else here) know if Nikos' draft is fully-functional on the PX4 or Pixhawk? I'm just trying to gauge how much modification to his gcm.c might be needed to get it on the APM 2.5 ...
|Re: [MAVLINK] Re: RFC: Towards secure MAVLink (sMAVLink)||Gareth Owen||10/9/13 12:23 PM|
The computational overhead is the problem. AES is likely to take a few ms to encrypt one block on the avr processor. There's just not that spare capacity.
I don't know about the px4 implementation or the status. I've heard nothing.
--Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "MAVLink" sind.
|Re: RFC: Towards secure MAVLink (sMAVLink)||РдҭяЇӨҭ Јѻє||11/4/13 5:48 PM|
Gareth, Lorenz, Nikos: thank you so much for all your help thus far...
Is there anyone in the group who has the time & knowledge/experience to help me work on implementing this endeavor on the APM 2.5? I'm new to arduino development, but I can read C (among other programming languages), understand networking & cryptography, and (most pertinent) I have time to work on this... I have another test flight scheduled in 2 weeks for which I need to secure the MAVLink messages so I can measure the "cost" of securing it (in added latency).
I'm available just about any time of the day, every day of the week (with a couple exceptions) for online collaboration. Please let me know if anyone is interested in working on this... [or if you've already succeeded in securing the protocol]
My main questions are:
(1) In the gcm.c file Nikos provided, where is register_cipher() function declared/defined? I only see it used in line 108...
(2) Does the comment at line 119 (" /* handle us some packets */ ") indicate this code still needs to be completed? or is it just a residual comment?
(3) Do the 2 additionally proposed MAVLink messages need to be defined & implemented to utilize the AES-GCM authenticated encryption? Or could one just modify the MAVLINK_HELPER uint16_t mavlink_finalize_message_chan() function in the mavlink_helpers.h file to add in the gcm functions before transmission?
(4) Once the adjustments are made to the appropriate APM firmware files, similar modifications will need to be made to Mission Planner (or whatever alternative GCS software is used)... Because I haven't looked at those files yet (since this realization just came to me), do these Mission Planner adjustments correspond intuitively? (i.e., will it be any more difficult to implement the AES-GCM implementation in Mission Planner?)
Again, I appreciate the assistance from the "veteran" developers here, and I really hope someone is available to help me work on implementing this on the APM 2.5!
On Monday, August 5, 2013 2:53:00 PM UTC-4, Arthur Benemann wrote:
I would like to implement the new secure protocol on DroidPlanner, but probably it's better to wait until it is stable.
|Re: RFC: Towards secure MAVLink (sMAVLink)||РдҭяЇӨҭ Јѻє||11/17/13 9:09 PM|
Could MAVLink also be secured using AVR-Crypto-lib (for the APM 2.5)? [instead of LibTomCrypt]
I ask because it appears to have support for AES & secure hashing capability (for authentication), optimized for the 8-bit microcontroller family (e.g., the APM)... and, correct me if I'm wrong but, aren't there some OS dependencies in the LibTomCrypt files (e.g., tomcrypt.h &/or tomcrypt_custom.h)? Wouldn't those be a problem trying to include them in the APM code?