Arthur
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.
Best
Gareth
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.
--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe MAVLink beigetreten sind.
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.
Weitere Optionen: https://groups.google.com/groups/opt_out
Byte Index | Content | Value | Explanation |
---|---|---|---|
0 | Packet start sign | v1.0: 0xFE (v0.9: 0x55) | Indicates the start of a new packet. |
1 | Payload length | 0 - 255 | Indicates length of the following payload. |
2 | Packet sequence | 0 - 255 | LSB OF IV |
3 | System ID | 1 - 255 | ID of the SENDING system. Allows to differentiate different MAVs on the same network. |
4 | Component ID | 0 - 255 | ID of the SENDING component. Allows to differentiate different components of the same system, e.g. the IMU and the autopilot. |
5 | Message ID | 0 - 255 | ID of the message - the id defines what the payload “means” and how it should be correctly decoded. |
6 to (n+6) | Data | (0 - 255) bytes | Data section, 0 .. k bytes. A = tag size Bytes 0-3: Remaining bytes from IV CRYPTO START Byte 4: Actual Message ID Byte 5...k-A: Payload msg CRYPTO STOP Byte k-A .. k: Tag (covering AEAD, where AD is header) |
(n+7) to (n+8) | Checksum (low byte, high byte) | ITU X.25/SAE AS-4 hash, excluding packet start sign, so bytes 1..(n+6) Note: The checksum also includes MAVLINK_CRC_EXTRA (Number computed from message fields. Protects the packet from decoding a different version of the same packet but with different variables). |
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 ?
Best
Gareth
I think we are just waiting for Nikos to suggest session init changes and we are good to go.
Best
Gareth
Crashmat
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.
Best
Gareth
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:mavlink+unsu...@googlegroups.com>.
PS, Nikos, the microcontroller has a random number generator which is a true random source.
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.
... "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, ..."-Lorenz
--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "MAVLink" sind.
--
JoeIPSec 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.BestGareth
On 1 October 2013 20:45, Јѻє Мдяҭҷ <0mnyp...@gmail.com> wrote:
...
Joe
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.
Best
Gareth
--
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.
Hi all,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:
- An UAV only accepts commands from its own ground control station
- Replay attacks can be prevented
- A logfile can be tracked back to be authentic from one particular unit
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:-Lorenz--- DRAFT / Under Construction ----Secure MAVLink (sMAVLink)--------------I. IntroductionThis 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 SettingA 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 modelThe 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 PrimitivessMAVLink 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 DescriptionWe describe the phases of the protocol in the order that they logically take place:1. BootstrapThe 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 initializationThe 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 more3. Session communicationAssume 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#TODOVII. NomenclatureAAD - Additional Authentication DataESK - Entity Session KeyGBS - Ground Base StationGM - Ground ModuleIV - Initialization VectorMAV - Micro Air VehicleMK - Master KeyMSK - Master Session Key