Secure Mavlink
1,065 views
Skip to first unread message
Gareth Owen
May 23, 2013, 9:37:33 AM5/23/13
to drones-...@googlegroups.com
Dear all
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
Curtis Olson
May 23, 2013, 9:52:36 AM5/23/13
to drones-...@googlegroups.com
My random thought is that the project needs to decide if they are designing around a cooperative environment or an adversarial environment. If it is the latter, you really need to go whole hog, or you'll spend too much of your time chasing embarrassing oversights.
Curt.
Eventually we all may be forced to design for adversarial environments, but there is a whole lot to think about, not just cracking the encryption, but adversaries replaying your packets to confuse the vehicle, denial of service, gps spoofing/jamming, etc. etc. For a hobby community, are those the things everyone wants to focus on? On the other hand we don't want to be naive and assume a perfect world...
As you suggest, the more sophisticated the security scheme, the more processing power is required. Also these things tend to require supporting libraries on the development side which adds managment/setup complexity, and also these layers get in the way of debugging and testing ...
Lot's to ponder if that is the direction the community eventually needs to follow.
Curt.
Gareth--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Curtis Olson:
Anish Mohammed
May 23, 2013, 10:01:06 AM5/23/13
to drones-...@googlegroups.com
Hi Gareth,
I should admit I too have some interests, I am a RHUL alumni ;) with stints in three different crypto/security groups. It was discussed during 3dr radio protocol was looked into. Memory and computational constrains implied, a suggestion of somthing like TEA . At the last moment my understanding was there want enough of apetite to look into it, given the constrains.regards
Anish
Gareth--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Anish Mohammed
May 23, 2013, 10:08:23 AM5/23/13
to drones-...@googlegroups.com
HI Curt,
I agree with you on your observations. I guess one could look at it from a legal requirement perspective, what is the equivalent in terms of security for normal R/C that could be the starting point. As for the rest of the challenges, key managment, proivsioning etc, these are all well studied problems with solutions that we already use ( e.g. mobile phones). We could surely leverage expertise in the community and use pre existing frameworks.
Meier Lorenz
May 23, 2013, 10:12:09 AM5/23/13
to <drones-discuss@googlegroups.com>
Hi Gareth,
I've started to look into this some time ago together with the System Security Group at ETH (Prof. Srdjan Capkun, http://www.infsec.ethz.ch). This is however more a spare-time open-source collaboration than a research project, and so you're warmly welcome to join.
The outcome of this effort will be the official secure MAVLink version (dubbed sMAVLink), and my planning horizon is 6-12 months, as its a very important topic, but nothing I could work on full-time.
We wanted to first embed authentication, then encryption (since taking over is worse than being able to listen). If during implementation it shows that full encryption is a low-hanging fruit, we'd surely take it.
On an orthogonal, but related topic I wanted to be able to authenticate individual boards, so that we can provide the user a tool to validate a digital signature of the manufacturer. For this I plan to use the one-time-programmable memory of the F4 (512 bytes) to store a signed version of the unique chip ID.
To facilitate this, I've started to incorporate libtomcrypt. Its still work in progress, but I'm making good progress. I will incorporate it into QGroundControl accordingly.
LibTomCrypt:
http://libtom.org/?page=features
My current WIP state:
https://github.com/px4/firmware/tree/auth/
I'd be interested to hear about additional details / ideas / proposals. I have a rough idea what could be promising, but I don't want to bias the discussion upfront.
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
On May 23, 2013, at 3:52 PM, Curtis Olson <curt...@flightgear.org<mailto:curt...@flightgear.org>> wrote:
My random thought is that the project needs to decide if they are designing around a cooperative environment or an adversarial environment. If it is the latter, you really need to go whole hog, or you'll spend too much of your time chasing embarrassing oversights.
Eventually we all may be forced to design for adversarial environments, but there is a whole lot to think about, not just cracking the encryption, but adversaries replaying your packets to confuse the vehicle, denial of service, gps spoofing/jamming, etc. etc. For a hobby community, are those the things everyone wants to focus on? On the other hand we don't want to be naive and assume a perfect world...
As you suggest, the more sophisticated the security scheme, the more processing power is required. Also these things tend to require supporting libraries on the development side which adds managment/setup complexity, and also these layers get in the way of debugging and testing ...
Lot's to ponder if that is the direction the community eventually needs to follow.
Curt.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.
http://www.atiak.com<http://www.atiak.com/> - http://aem.umn.edu/~uav/
http://www.flightgear.org<http://www.flightgear.org/> - http://gallinazo.flightgear.org<http://gallinazo.flightgear.org/>
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.
I've started to look into this some time ago together with the System Security Group at ETH (Prof. Srdjan Capkun, http://www.infsec.ethz.ch). This is however more a spare-time open-source collaboration than a research project, and so you're warmly welcome to join.
The outcome of this effort will be the official secure MAVLink version (dubbed sMAVLink), and my planning horizon is 6-12 months, as its a very important topic, but nothing I could work on full-time.
We wanted to first embed authentication, then encryption (since taking over is worse than being able to listen). If during implementation it shows that full encryption is a low-hanging fruit, we'd surely take it.
On an orthogonal, but related topic I wanted to be able to authenticate individual boards, so that we can provide the user a tool to validate a digital signature of the manufacturer. For this I plan to use the one-time-programmable memory of the F4 (512 bytes) to store a signed version of the unique chip ID.
To facilitate this, I've started to incorporate libtomcrypt. Its still work in progress, but I'm making good progress. I will incorporate it into QGroundControl accordingly.
LibTomCrypt:
http://libtom.org/?page=features
My current WIP state:
https://github.com/px4/firmware/tree/auth/
I'd be interested to hear about additional details / ideas / proposals. I have a rough idea what could be promising, but I don't want to bias the discussion upfront.
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
On May 23, 2013, at 3:52 PM, Curtis Olson <curt...@flightgear.org<mailto:curt...@flightgear.org>> wrote:
My random thought is that the project needs to decide if they are designing around a cooperative environment or an adversarial environment. If it is the latter, you really need to go whole hog, or you'll spend too much of your time chasing embarrassing oversights.
Eventually we all may be forced to design for adversarial environments, but there is a whole lot to think about, not just cracking the encryption, but adversaries replaying your packets to confuse the vehicle, denial of service, gps spoofing/jamming, etc. etc. For a hobby community, are those the things everyone wants to focus on? On the other hand we don't want to be naive and assume a perfect world...
As you suggest, the more sophisticated the security scheme, the more processing power is required. Also these things tend to require supporting libraries on the development side which adds managment/setup complexity, and also these layers get in the way of debugging and testing ...
Lot's to ponder if that is the direction the community eventually needs to follow.
Curt.
On Thu, May 23, 2013 at 8:37 AM, Gareth Owen <dr.g...@gmail.com<mailto:dr.g...@gmail.com>> wrote:
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf> with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
http://www.atiak.com<http://www.atiak.com/> - http://aem.umn.edu/~uav/
http://www.flightgear.org<http://www.flightgear.org/> - http://gallinazo.flightgear.org<http://gallinazo.flightgear.org/>
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
Meier Lorenz
May 23, 2013, 10:14:34 AM5/23/13
to <drones-discuss@googlegroups.com>
I forgot to mention: The 3DR Radio runs an Intel 8051 8-bit type, and I don't think we should degenerate security over trying to fit it to a platform it can't really work on.
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
On May 23, 2013, at 4:08 PM, Anish Mohammed <anish.m...@gmail.com<mailto:anish.m...@gmail.com>>
wrote:
HI Curt,
I agree with you on your observations. I guess one could look at it from a legal requirement perspective, what is the equivalent in terms of security for normal R/C that could be the starting point. As for the rest of the challenges, key managment, proivsioning etc, these are all well studied problems with solutions that we already use ( e.g. mobile phones). We could surely leverage expertise in the community and use pre existing frameworks.
My two cents worth.
Anish
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
wrote:
HI Curt,
I agree with you on your observations. I guess one could look at it from a legal requirement perspective, what is the equivalent in terms of security for normal R/C that could be the starting point. As for the rest of the challenges, key managment, proivsioning etc, these are all well studied problems with solutions that we already use ( e.g. mobile phones). We could surely leverage expertise in the community and use pre existing frameworks.
My two cents worth.
Anish
On Thu, May 23, 2013 at 2:52 PM, Curtis Olson <curt...@flightgear.org<mailto:curt...@flightgear.org>> wrote:
My random thought is that the project needs to decide if they are designing around a cooperative environment or an adversarial environment. If it is the latter, you really need to go whole hog, or you'll spend too much of your time chasing embarrassing oversights.
Eventually we all may be forced to design for adversarial environments, but there is a whole lot to think about, not just cracking the encryption, but adversaries replaying your packets to confuse the vehicle, denial of service, gps spoofing/jamming, etc. etc. For a hobby community, are those the things everyone wants to focus on? On the other hand we don't want to be naive and assume a perfect world...
As you suggest, the more sophisticated the security scheme, the more processing power is required. Also these things tend to require supporting libraries on the development side which adds managment/setup complexity, and also these layers get in the way of debugging and testing ...
Lot's to ponder if that is the direction the community eventually needs to follow.
Curt.
My random thought is that the project needs to decide if they are designing around a cooperative environment or an adversarial environment. If it is the latter, you really need to go whole hog, or you'll spend too much of your time chasing embarrassing oversights.
Eventually we all may be forced to design for adversarial environments, but there is a whole lot to think about, not just cracking the encryption, but adversaries replaying your packets to confuse the vehicle, denial of service, gps spoofing/jamming, etc. etc. For a hobby community, are those the things everyone wants to focus on? On the other hand we don't want to be naive and assume a perfect world...
As you suggest, the more sophisticated the security scheme, the more processing power is required. Also these things tend to require supporting libraries on the development side which adds managment/setup complexity, and also these layers get in the way of debugging and testing ...
Lot's to ponder if that is the direction the community eventually needs to follow.
Curt.
On Thu, May 23, 2013 at 8:37 AM, Gareth Owen <dr.g...@gmail.com<mailto:dr.g...@gmail.com>> wrote:
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf> with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
http://www.atiak.com<http://www.atiak.com/> - http://aem.umn.edu/~uav/
http://www.flightgear.org<http://www.flightgear.org/> - http://gallinazo.flightgear.org<http://gallinazo.flightgear.org/>
http://www.flightgear.org<http://www.flightgear.org/> - http://gallinazo.flightgear.org<http://gallinazo.flightgear.org/>
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
For more options, visit https://groups.google.com/groups/opt_out.
--
Anish Mohammed
http://uk.linkedin.com/in/anishmohammed
@anishmohammed
--
Anish Mohammed
http://uk.linkedin.com/in/anishmohammed
@anishmohammed
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
Gareth Owen
May 23, 2013, 10:20:51 AM5/23/13
to drones-...@googlegroups.com
Curt, Anish
Curt: Very good points - particularly about GPS spoofing which is very hard to protect against - that I hadn't considered! At present, it's fairly easy to steal someone's drone from the sky with < $50 of [legal] equipment. A secure mavlink+rclink would raise the bar.
Anish: I was under the impression TEA was fairly weak by today's standards. It has a small implementation, but AES can be small depending on your choices with lookup tables (albeit nowhere near as small). As MAVLINK is packetised, I'm not sure a stream cipher is necessary, and if we did use a stream cipher we'd have to worry about synchronization and authentication (+ bit flipping attacks). I'm not sure any authenticated modes of operation for stream ciphers have been standardised - and if we were to do this properly I think we should stick with a standardised authenticated mode.
Lorenz: Seems like you're well ahead of these discussions with something. So yes, I'd be interested in participating with what you've already started.
Best
Gareth
--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/3xPmB3O2lPA/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.
Meier Lorenz
May 23, 2013, 10:27:58 AM5/23/13
to <drones-discuss@googlegroups.com>
James Goppert has started to look into characterizing attacks on GPS, and the combined attitude / position EKF has an in-built metric to report (and it does report) supposedly wrong looking GPS readings. Combine that with fusing it with PX4FLOW measurements and you're extremely close to being able to reject such attacks, at least as long its not dark you should be able to roughly RTL and land or land on the current location, even if GPS and radio are both completely jammed.
James' filter is here:
https://github.com/px4/firmware/tree/master/src/modules/att_pos_estimator_ekf
I'd be very interested to see this being picked up.
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.
--
Anish Mohammed
http://uk.linkedin.com/in/anishmohammed
@anishmohammed
--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/3xPmB3O2lPA/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.
James' filter is here:
https://github.com/px4/firmware/tree/master/src/modules/att_pos_estimator_ekf
I'd be very interested to see this being picked up.
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
On May 23, 2013, at 4:20 PM, Gareth Owen <dr.g...@gmail.com<mailto:dr.g...@gmail.com>> wrote:
Curt, Anish
Curt: Very good points - particularly about GPS spoofing which is very hard to protect against - that I hadn't considered! At present, it's fairly easy to steal someone's drone from the sky with < $50 of [legal] equipment. A secure mavlink+rclink would raise the bar.
Anish: I was under the impression TEA was fairly weak by today's standards. It has a small implementation, but AES can be small depending on your choices with lookup tables (albeit nowhere near as small). As MAVLINK is packetised, I'm not sure a stream cipher is necessary, and if we did use a stream cipher we'd have to worry about synchronization and authentication (+ bit flipping attacks). I'm not sure any authenticated modes of operation for stream ciphers have been standardised - and if we were to do this properly I think we should stick with a standardised authenticated mode.
Lorenz: Seems like you're well ahead of these discussions with something. So yes, I'd be interested in participating with what you've already started.
Best
Gareth
Curt, Anish
Curt: Very good points - particularly about GPS spoofing which is very hard to protect against - that I hadn't considered! At present, it's fairly easy to steal someone's drone from the sky with < $50 of [legal] equipment. A secure mavlink+rclink would raise the bar.
Anish: I was under the impression TEA was fairly weak by today's standards. It has a small implementation, but AES can be small depending on your choices with lookup tables (albeit nowhere near as small). As MAVLINK is packetised, I'm not sure a stream cipher is necessary, and if we did use a stream cipher we'd have to worry about synchronization and authentication (+ bit flipping attacks). I'm not sure any authenticated modes of operation for stream ciphers have been standardised - and if we were to do this properly I think we should stick with a standardised authenticated mode.
Lorenz: Seems like you're well ahead of these discussions with something. So yes, I'd be interested in participating with what you've already started.
Best
Gareth
On 23 May 2013 15:01, Anish Mohammed <anish.m...@gmail.com<mailto:anish.m...@gmail.com>> wrote:
Hi Gareth,
I should admit I too have some interests, I am a RHUL alumni ;) with stints in three different crypto/security groups. It was discussed during 3dr radio protocol was looked into. Memory and computational constrains implied, a suggestion of somthing like TEA . At the last moment my understanding was there want enough of apetite to look into it, given the constrains.
Unrelated note block ciphers generally are heavier than stream, and this is a good use case for stream cipher.
regards
Anish
Hi Gareth,
I should admit I too have some interests, I am a RHUL alumni ;) with stints in three different crypto/security groups. It was discussed during 3dr radio protocol was looked into. Memory and computational constrains implied, a suggestion of somthing like TEA . At the last moment my understanding was there want enough of apetite to look into it, given the constrains.
Unrelated note block ciphers generally are heavier than stream, and this is a good use case for stream cipher.
regards
Anish
On Thu, May 23, 2013 at 2:37 PM, Gareth Owen <dr.g...@gmail.com<mailto:dr.g...@gmail.com>> wrote:
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf> with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
For more options, visit https://groups.google.com/groups/opt_out.
--
Anish Mohammed
http://uk.linkedin.com/in/anishmohammed
@anishmohammed
--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/3xPmB3O2lPA/unsubscribe?hl=en.
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.
Gareth Owen
May 23, 2013, 10:42:21 AM5/23/13
to drones-...@googlegroups.com
Interesting - has he published any work on the rejection of bad GPS with this or have any results? It could also avoid bad-GPS fly aways.
On Thursday, May 23, 2013 3:27:58 PM UTC+1, Lorenz Meier wrote:
Adding this level of sophistication would bring ardupilot closer to military ready. Seems I need to convince my partner that I need to invest in a PX4 having only just bought APM2.5 - that could be the greatest challenge :-)
Best
Gareth
On Thursday, May 23, 2013 3:27:58 PM UTC+1, Lorenz Meier wrote:
James Goppert has started to look into characterizing attacks on GPS, and the combined attitude / position EKF has an in-built metric to report (and it does report) supposedly wrong looking GPS readings. Combine that with fusing it with PX4FLOW measurements and you're extremely close to being able to reject such attacks, at least as long its not dark you should be able to roughly RTL and land or land on the current location, even if GPS and radio are both completely jammed.
James' filter is here:
https://github.com/px4/firmware/tree/master/src/modules/att_pos_estimator_ekf
I'd be very interested to see this being picked up.
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
On May 23, 2013, at 4:20 PM, Gareth Owen <> wrote:
Curt, Anish
Curt: Very good points - particularly about GPS spoofing which is very hard to protect against - that I hadn't considered! At present, it's fairly easy to steal someone's drone from the sky with < $50 of [legal] equipment. A secure mavlink+rclink would raise the bar.
Anish: I was under the impression TEA was fairly weak by today's standards. It has a small implementation, but AES can be small depending on your choices with lookup tables (albeit nowhere near as small). As MAVLINK is packetised, I'm not sure a stream cipher is necessary, and if we did use a stream cipher we'd have to worry about synchronization and authentication (+ bit flipping attacks). I'm not sure any authenticated modes of operation for stream ciphers have been standardised - and if we were to do this properly I think we should stick with a standardised authenticated mode.
Lorenz: Seems like you're well ahead of these discussions with something. So yes, I'd be interested in participating with what you've already started.
Best
Gareth
On 23 May 2013 15:01, Anish Mohammed <anish.m...@gmail.com<mailto:anish.m...@gmail.com>> wrote:
Hi Gareth,
I should admit I too have some interests, I am a RHUL alumni ;) with stints in three different crypto/security groups. It was discussed during 3dr radio protocol was looked into. Memory and computational constrains implied, a suggestion of somthing like TEA . At the last moment my understanding was there want enough of apetite to look into it, given the constrains.
Unrelated note block ciphers generally are heavier than stream, and this is a good use case for stream cipher.
regards
Anish
On Thu, May 23, 2013 at 2:37 PM, Gareth Owen <dr.g...@gmail.com<mailto:dr.g.owen@gmail.com>> wrote:
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf> with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.
--
Anish Mohammed
http://uk.linkedin.com/in/anishmohammed
@anishmohammed
--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/3xPmB3O2lPA/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss+unsubscribe@googlegroups.com>.
Meier Lorenz
May 24, 2013, 3:04:03 AM5/24/13
to <drones-discuss@googlegroups.com>
C.
Thanks for sharing. @all: I would be interested in more detailed proposals, in particular on key management as well. I think with the building blocks I have in place it would be trivial to add encryption right now, but the goal is obviously to make it convenient to set up but also safe. I'm not particularly worried about the performance on the F4, but it would still be helpful to have some feedback on runtime vs. strength of the potential algorithms (look at libtomcrypt, it supports all the common algorithms).
Also think about which algorithms are likely to be available as part of a non-embedded standard package (thinking about non-C GCS).
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
Am 24.05.2013 um 00:09 schrieb C Wong <cwce...@gmail.com<mailto:cwce...@gmail.com>>:
Just to share, granted I haven't taken a deep dive into the Digi firmware, but we're using their AES feature on the Xbee's in API mode. I've profiled around <1ms delay from it looking at our GCS routines (yes it can be 1ms in certain situations!). It's acceptable for our multicopter fleet running telemetry @ 2Hz. And for point to point GCS-UAV setup, that's not going to impact performance of even 5Hz telemetry data (e.g. in MissionPlanner to a single drone).
So, in summary, we're using Digi's built-in AES (128bit, ugh), specific checks on source and dest addresses since we're in API mode and we're using both GCSID and SYSID in MavLink using a private numbering scheme (aka security through obscurity). So the only security holes remaining in the system are GPS spoofing, and of course, compass EMI (!).
Aside from compass EMI, we could expand the PXFlow-coupled-to-GPS idea Lorenz mentioned and couple it to compass+flight plan as well. And if the calibration is done well enough, we are currently testing a way to roughly measure heading through gyros alone for geofence purposes. Tracking error is an easy thing to measure from that aspect and notify you if something is off course (aka hacked).
On Thursday, May 23, 2013 6:37:33 AM UTC-7, Gareth Owen wrote:
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf> with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
Thanks for sharing. @all: I would be interested in more detailed proposals, in particular on key management as well. I think with the building blocks I have in place it would be trivial to add encryption right now, but the goal is obviously to make it convenient to set up but also safe. I'm not particularly worried about the performance on the F4, but it would still be helpful to have some feedback on runtime vs. strength of the potential algorithms (look at libtomcrypt, it supports all the common algorithms).
Also think about which algorithms are likely to be available as part of a non-embedded standard package (thinking about non-C GCS).
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
Just to share, granted I haven't taken a deep dive into the Digi firmware, but we're using their AES feature on the Xbee's in API mode. I've profiled around <1ms delay from it looking at our GCS routines (yes it can be 1ms in certain situations!). It's acceptable for our multicopter fleet running telemetry @ 2Hz. And for point to point GCS-UAV setup, that's not going to impact performance of even 5Hz telemetry data (e.g. in MissionPlanner to a single drone).
So, in summary, we're using Digi's built-in AES (128bit, ugh), specific checks on source and dest addresses since we're in API mode and we're using both GCSID and SYSID in MavLink using a private numbering scheme (aka security through obscurity). So the only security holes remaining in the system are GPS spoofing, and of course, compass EMI (!).
Aside from compass EMI, we could expand the PXFlow-coupled-to-GPS idea Lorenz mentioned and couple it to compass+flight plan as well. And if the calibration is done well enough, we are currently testing a way to roughly measure heading through gyros alone for geofence purposes. Tracking error is an easy thing to measure from that aspect and notify you if something is off course (aka hacked).
On Thursday, May 23, 2013 6:37:33 AM UTC-7, Gareth Owen wrote:
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
Meier Lorenz
May 24, 2013, 3:06:19 AM5/24/13
to <drones-discuss@googlegroups.com>
You would have to ask him, this particular implementation hasn't been published yet I think.
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
For more options, visit https://groups.google.com/groups/opt_out.
--
Anish Mohammed
http://uk.linkedin.com/in/anishmohammed
@anishmohammed
--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/3xPmB3O2lPA/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com<javascript:><mailto:drones-discuss%2Bunsu...@googlegroups.com<javascript:>>.
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
Am 23.05.2013 um 16:42 schrieb Gareth Owen <dr.g...@gmail.com<mailto:dr.g...@gmail.com>>:
Interesting - has he published any work on the rejection of bad GPS with this or have any results? It could also avoid bad-GPS fly aways.
Adding this level of sophistication would bring ardupilot closer to military ready. Seems I need to convince my partner that I need to invest in a PX4 having only just bought APM2.5 - that could be the greatest challenge :-)
Best
Gareth
On Thursday, May 23, 2013 3:27:58 PM UTC+1, Lorenz Meier wrote:
James Goppert has started to look into characterizing attacks on GPS, and the combined attitude / position EKF has an in-built metric to report (and it does report) supposedly wrong looking GPS readings. Combine that with fusing it with PX4FLOW measurements and you're extremely close to being able to reject such attacks, at least as long its not dark you should be able to roughly RTL and land or land on the current location, even if GPS and radio are both completely jammed.
James' filter is here:
https://github.com/px4/firmware/tree/master/src/modules/att_pos_estimator_ekf
I'd be very interested to see this being picked up.
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
On May 23, 2013, at 4:20 PM, Gareth Owen <> wrote:
Curt, Anish
Curt: Very good points - particularly about GPS spoofing which is very hard to protect against - that I hadn't considered! At present, it's fairly easy to steal someone's drone from the sky with < $50 of [legal] equipment. A secure mavlink+rclink would raise the bar.
Anish: I was under the impression TEA was fairly weak by today's standards. It has a small implementation, but AES can be small depending on your choices with lookup tables (albeit nowhere near as small). As MAVLINK is packetised, I'm not sure a stream cipher is necessary, and if we did use a stream cipher we'd have to worry about synchronization and authentication (+ bit flipping attacks). I'm not sure any authenticated modes of operation for stream ciphers have been standardised - and if we were to do this properly I think we should stick with a standardised authenticated mode.
Lorenz: Seems like you're well ahead of these discussions with something. So yes, I'd be interested in participating with what you've already started.
Best
Gareth
Interesting - has he published any work on the rejection of bad GPS with this or have any results? It could also avoid bad-GPS fly aways.
Adding this level of sophistication would bring ardupilot closer to military ready. Seems I need to convince my partner that I need to invest in a PX4 having only just bought APM2.5 - that could be the greatest challenge :-)
Best
Gareth
On Thursday, May 23, 2013 3:27:58 PM UTC+1, Lorenz Meier wrote:
James Goppert has started to look into characterizing attacks on GPS, and the combined attitude / position EKF has an in-built metric to report (and it does report) supposedly wrong looking GPS readings. Combine that with fusing it with PX4FLOW measurements and you're extremely close to being able to reject such attacks, at least as long its not dark you should be able to roughly RTL and land or land on the current location, even if GPS and radio are both completely jammed.
James' filter is here:
https://github.com/px4/firmware/tree/master/src/modules/att_pos_estimator_ekf
I'd be very interested to see this being picked up.
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
On May 23, 2013, at 4:20 PM, Gareth Owen <> wrote:
Curt, Anish
Curt: Very good points - particularly about GPS spoofing which is very hard to protect against - that I hadn't considered! At present, it's fairly easy to steal someone's drone from the sky with < $50 of [legal] equipment. A secure mavlink+rclink would raise the bar.
Anish: I was under the impression TEA was fairly weak by today's standards. It has a small implementation, but AES can be small depending on your choices with lookup tables (albeit nowhere near as small). As MAVLINK is packetised, I'm not sure a stream cipher is necessary, and if we did use a stream cipher we'd have to worry about synchronization and authentication (+ bit flipping attacks). I'm not sure any authenticated modes of operation for stream ciphers have been standardised - and if we were to do this properly I think we should stick with a standardised authenticated mode.
Lorenz: Seems like you're well ahead of these discussions with something. So yes, I'd be interested in participating with what you've already started.
Best
Gareth
On 23 May 2013 15:01, Anish Mohammed <anish.m...@gmail.com<javascript:><mailto:anish.m...@gmail.com<javascript:>>> wrote:
Hi Gareth,
I should admit I too have some interests, I am a RHUL alumni ;) with stints in three different crypto/security groups. It was discussed during 3dr radio protocol was looked into. Memory and computational constrains implied, a suggestion of somthing like TEA . At the last moment my understanding was there want enough of apetite to look into it, given the constrains.
Unrelated note block ciphers generally are heavier than stream, and this is a good use case for stream cipher.
regards
Anish
Hi Gareth,
I should admit I too have some interests, I am a RHUL alumni ;) with stints in three different crypto/security groups. It was discussed during 3dr radio protocol was looked into. Memory and computational constrains implied, a suggestion of somthing like TEA . At the last moment my understanding was there want enough of apetite to look into it, given the constrains.
Unrelated note block ciphers generally are heavier than stream, and this is a good use case for stream cipher.
regards
Anish
On Thu, May 23, 2013 at 2:37 PM, Gareth Owen <dr.g...@gmail.com<javascript:><mailto:dr.g...@gmail.com<javascript:>>> wrote:
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf> with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<javascript:><mailto:drones-discuss%2Bunsu...@googlegroups.com<javascript:>>.
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf> with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
For more options, visit https://groups.google.com/groups/opt_out.
--
Anish Mohammed
http://uk.linkedin.com/in/anishmohammed
@anishmohammed
--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/3xPmB3O2lPA/unsubscribe?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<javascript:><mailto:drones-discus...@googlegroups.com<javascript:>>.
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
Andrew Tridgell
May 24, 2013, 4:53:44 AM5/24/13
to Gareth Owen, drones-...@googlegroups.com
Hi All,
Some random thoughts on encrypting telemetry:
- I think we'd be crazy to do it at the MAVLink layer. We don't have a
stream protocol in MAVLink, we have a set of unordered packets with a
lossy transport. Trying to shoehorn an encryption wrapper around that
would be both painful and I think very hard to get right, especially
with potential compromises in the negotiation
- if we did it at the MAVLink layer then it would also break other
users of the MAVLink stream, including OSD devices and the 3DR radios
themselves (which inject RADIO packets and have protocol knowledge)
- instead I think we need to do the encryption using a block cipher in
the transport layer, inside the radios, protecting only the
over-the-air protocol.
- I've previously suggested we use TEA with the existing 3DR
radios. It's not state of the art, but it will get us started with
encryption in the transport layer.
- later I think 3DR should consider switching to a Si102x part, which
comes with hardware AES support (among other things). I think Seppo
is thinking of switching to a part with hardware AES for the RFD900
too.
Cheers, Tridge
Some random thoughts on encrypting telemetry:
- I think we'd be crazy to do it at the MAVLink layer. We don't have a
stream protocol in MAVLink, we have a set of unordered packets with a
lossy transport. Trying to shoehorn an encryption wrapper around that
would be both painful and I think very hard to get right, especially
with potential compromises in the negotiation
- if we did it at the MAVLink layer then it would also break other
users of the MAVLink stream, including OSD devices and the 3DR radios
themselves (which inject RADIO packets and have protocol knowledge)
- instead I think we need to do the encryption using a block cipher in
the transport layer, inside the radios, protecting only the
over-the-air protocol.
- I've previously suggested we use TEA with the existing 3DR
radios. It's not state of the art, but it will get us started with
encryption in the transport layer.
- later I think 3DR should consider switching to a Si102x part, which
comes with hardware AES support (among other things). I think Seppo
is thinking of switching to a part with hardware AES for the RFD900
too.
Cheers, Tridge
Gareth Owen
May 24, 2013, 5:15:59 AM5/24/13
to drones-...@googlegroups.com, Gareth Owen, and...@tridgell.net
Tridge, C,
I actually agree with this point that it's done better on the radios, it hides it from the programmers working on the autopilot and hence reduces the risk for later error (presuming the implementation is right from the start). Key management then just becomes a matter of pairing/provisioning the radios in the same 'group'.
For the mavlink, authentication / integrity are more important than confidentiality (imho), so I think it important that something like AES-CCM is used. Just encrypting the traffic adds very little security without the auth/integ check (replay attacks are easy). Zigbee protocol appears to use AES-CCM too.
Best
Gareth
Meier Lorenz
May 24, 2013, 5:32:34 AM5/24/13
to drones-...@googlegroups.com, Gareth Owen
Tridge,
I think its obvious that even a very weak encryption scheme would buy most of the wanted properties for hobby applications, since it rules out the most likely same-channel-same-area misconfiguration case.
If this happens on the transport layer, this is however somewhat orthogonal to a fair share of the scope of this discussion, since its transparent and its sensible to do and should be done anyway.
I start to disagree when we talk about state of the art solutions and key management. I think building support for basic negotiation into the protocol can dramatically help with keeping the configuration interoperable and manageable.
There is also no reason the 3DR radio can't apply protocol knowledge on encrypted frames.
And with the steadily increasing number of UARTs I think one can afford an unencrypted onboard serial link (which at least I on my systems typically anyway already have, thus the reason for channels and component IDs).
Last I'm not sure I follow you on the transport layer argument. The radio also sends frames and those can and do drop, so apart from a lower latency in detecting drops, you have fundamentally the same setup as when looking at packets on the MCU.
The bottom line is: I want to avoid to have to configure the radios separately and make it confusing for users, in particular since misconfigured encryption looks (if done right) like garbage. It would be good if there is some notion of link encryption and a potential MCU based fallback for a state of the art choice in setups where the radio can't pull it off.
-Lorenz
Von Samsung Mobile gesendet
-------- Ursprüngliche Nachricht --------
Von: Andrew Tridgell <tri...@samba.org>
Datum: 24.05.2013 10:53 (GMT+01:00)
An: Gareth Owen <dr.g...@gmail.com>,drones-...@googlegroups.com
Betreff: Re: [drones-discuss] Secure Mavlink
I think its obvious that even a very weak encryption scheme would buy most of the wanted properties for hobby applications, since it rules out the most likely same-channel-same-area misconfiguration case.
If this happens on the transport layer, this is however somewhat orthogonal to a fair share of the scope of this discussion, since its transparent and its sensible to do and should be done anyway.
I start to disagree when we talk about state of the art solutions and key management. I think building support for basic negotiation into the protocol can dramatically help with keeping the configuration interoperable and manageable.
There is also no reason the 3DR radio can't apply protocol knowledge on encrypted frames.
And with the steadily increasing number of UARTs I think one can afford an unencrypted onboard serial link (which at least I on my systems typically anyway already have, thus the reason for channels and component IDs).
Last I'm not sure I follow you on the transport layer argument. The radio also sends frames and those can and do drop, so apart from a lower latency in detecting drops, you have fundamentally the same setup as when looking at packets on the MCU.
The bottom line is: I want to avoid to have to configure the radios separately and make it confusing for users, in particular since misconfigured encryption looks (if done right) like garbage. It would be good if there is some notion of link encryption and a potential MCU based fallback for a state of the art choice in setups where the radio can't pull it off.
-Lorenz
Von Samsung Mobile gesendet
-------- Ursprüngliche Nachricht --------
Von: Andrew Tridgell <tri...@samba.org>
Datum: 24.05.2013 10:53 (GMT+01:00)
An: Gareth Owen <dr.g...@gmail.com>,drones-...@googlegroups.com
Betreff: Re: [drones-discuss] Secure Mavlink
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
Chris Gough
May 24, 2013, 8:08:17 AM5/24/13
to drones-...@googlegroups.com, drones-...@googlegroups.com, Gareth Owen
same-channel-same-area misconfiguration case is valuable but not the same as protection against malicious attack. See for example the paparazzi protocol with signatures based on checksums of various things - not secure in terms of "defense against the dark arts", but effective in terms of preventing lazy students from accidentally shooting down each others planes when they copy and paste config from each other.
For protection against malicious attack, it might be better to have a native "opaque block protocol" on the radios, and put a Linux SOC between the radio and the autopilot. I think this inherently better than baking-in an opinion about cryptosystems, even a well informed/considered opinion.
If I really, really needed strong crypto on the telemetry / telecommand link, I might want to use a one time pad. I'm sure there are more sophistocated ways to do it with many advantages over OTP, but if I don't fully understand them I can't be sure I didnt somehow screw up and destroy my security. At 56Kbps, a modest SD card full of OTP will last longer than my flight batteries, so there are situations where I wouldn't care about that kind of efficiency. For example, I don't need any key exchange see-you-at-the-railway-station-I'll-be-wearing-the-carnation trickery when both radios are physically secured in my possession right up until launch.
I'm not advocating OTP or anything else, I'm advocating a design that is cryptosystem agnostic. I think that means a wire protocol for blocks, and a new way to deal with the RSSI packet injection, and moving the protocol-aware block packing upstream.
What if the RSSI packet was sent in the other direction, back to the node rather than over air, and RSSI packet node joined the outbound stream further back. For example, just upstream of the plaintext block-packing?
If the reverse flow RSSI packet opens up an attack vector, maybe the RSSI info could be communicated to the crypto node on a different channel (analog voltages?)
Of course, this suggestion is just a cunning ploy to get a MavProxy node into every airframe, without all the wires :)
Chris Gough
>
For protection against malicious attack, it might be better to have a native "opaque block protocol" on the radios, and put a Linux SOC between the radio and the autopilot. I think this inherently better than baking-in an opinion about cryptosystems, even a well informed/considered opinion.
If I really, really needed strong crypto on the telemetry / telecommand link, I might want to use a one time pad. I'm sure there are more sophistocated ways to do it with many advantages over OTP, but if I don't fully understand them I can't be sure I didnt somehow screw up and destroy my security. At 56Kbps, a modest SD card full of OTP will last longer than my flight batteries, so there are situations where I wouldn't care about that kind of efficiency. For example, I don't need any key exchange see-you-at-the-railway-station-I'll-be-wearing-the-carnation trickery when both radios are physically secured in my possession right up until launch.
I'm not advocating OTP or anything else, I'm advocating a design that is cryptosystem agnostic. I think that means a wire protocol for blocks, and a new way to deal with the RSSI packet injection, and moving the protocol-aware block packing upstream.
What if the RSSI packet was sent in the other direction, back to the node rather than over air, and RSSI packet node joined the outbound stream further back. For example, just upstream of the plaintext block-packing?
If the reverse flow RSSI packet opens up an attack vector, maybe the RSSI info could be communicated to the crypto node on a different channel (analog voltages?)
Of course, this suggestion is just a cunning ploy to get a MavProxy node into every airframe, without all the wires :)
Chris Gough
>
Ritchie Wilson
May 24, 2013, 8:28:39 AM5/24/13
to drones-...@googlegroups.com
This seems fun but a waste of talent. Aside from accidental spoofing which is stopped by setting up the Xbee properly. Adding extras to do proper encryption as you suggest is well above our remit.
Military grade tech is not just software standards but hardware and we won't pass the environmental tests.
Regards
Ritchie.
Military grade tech is not just software standards but hardware and we won't pass the environmental tests.
Regards
Ritchie.
Gareth Owen
May 24, 2013, 9:10:22 AM5/24/13
to drones-...@googlegroups.com
I'm not sure how we got onto talking about OTPs which are not at all suitable - but could I just summarise what I'm trying to point out - that doing it right is EASY. Why bother with anything else?
We need, in order of priority:
1) Protection against spoofing (integrity/authentication/replay prevention)
2) Confidentiality (encrypted)
The first one is by far the most important, just encrypting the traffic, whether it be with OTPs or TEA won't solve that problem. The cryptography community has put some effort in the recent years to make it easier to produce sound secure systems by introducing authenticated encryption modes (like CCM) that provide the above two points.
You get two functions
Encrypt(data, key) = ciphertext
and
Decrypt(ciphertext, key) = plaintext or explicit invalid error if message didn't pass auth/integ checks.
This stuff is library code and it couldn't get any simpler. The code is small and it is fast - there is no need to faff about with anything else. If the decrypt() function succeeded process the packet.
The only two cons are:
- You need packet sequence numbers to prevent replays (I expect you do this already for error handling).
- You need a few extra bytes in the packet for the tag (a signed cryptographic checksum).
any secure protocol will require these two in any case.
In terms of user experience, a connection over USB can cause a key sync between mission planner and the copter entirely automatically - zero user interaction.
I can't see the logic in attempting any other method to make it simpler. CCM is provably secure, standardised and couldn't be easier. CCM even allows parts of the packet to be unencrypted (e.g. the header) and still provides authentication and integrity over the non-encrypted part.
Best
Gareth
Olivier ADLER
May 24, 2013, 9:25:36 AM5/24/13
to drones-...@googlegroups.com
This is an interesting task but do we really need strong encryption ? Is it desirable to have that ?
An argument against that is that the project is open and should not be used for military or aggressive purpose.
Another one is that we don't have personal privacy to protect in the radio transmission between the ground and the UAV.
Would it be enough to have a simple authentication with a unique identification number to prevent conflicts between users ?
For those that need strong encryption, they can jump on open protocols or commercial hardware to do that. Is it really necessary for commercial and scientific use ? Perhaps for some sensitive uses, but don't forget that a radio link can be jamed regardless the encryption method.
From the DIYDrone Five rules :
We are focused on non-commercial ("recreational") projects by amateurs, although pros are always welcome too. Reasons to make your own UAV range from a fun technical challenge, student contests, aerial photography and mapping (what we call "GeoCrawling"), and scientific sensing. We are primarily interested in civilian, not military, UAV uses here.
And rule number 6 :
- No discussion of military or weaponized applications of UAVs. This site is just about amateur and civilian use.
Chris Gough
May 24, 2013, 9:52:34 AM5/24/13
to drones-...@googlegroups.com
On 24/05/2013, at 10:28 PM, Ritchie Wilson <originaln...@gmail.com> wrote:
> This seems fun but a waste of talent.
I dont understand that concept :)
> This seems fun but a waste of talent.
> Aside from accidental spoofing which is stopped by setting up the Xbee properly.
> Adding extras to do proper encryption as you suggest is well above our remit.
> Military grade tech is not just software standards but hardware and we won't pass the environmental tests.
I'm not convinced link encryption is a priority, but in some ways committing to a flawed implementation is worse than none.
Chris Gough
Chris Gough
May 24, 2013, 10:15:23 AM5/24/13
to drones-...@googlegroups.com
On 24/05/2013, at 11:10 PM, Gareth Owen <dr.g...@gmail.com> wrote:
> I'm not sure how we got onto talking about OTPs which are not at all suitable
LibTom looks neat, exactly the sort of thing to wrap up in a MavProxy module on said Linux node.
Sure it might be possible to jam a cryptosystem into the autopilot or modem firmware. But given the cost of SOCs, why not have one as gatekeeper between trusted and untrusted segments. Defence in depth and all that.
Chris Gough
Chris Gough
May 24, 2013, 10:33:45 AM5/24/13
to drones-...@googlegroups.com, drones-...@googlegroups.com
> The only two cons are:
> - You need packet sequence numbers to prevent replays (I expect you do this already for error handling).
> - You need a few extra bytes in the packet for the tag (a signed cryptographic checksum).
>
> any secure protocol will require these two in any case.
The current radio firmware is protocol aware. It injects RSSI data, which is very usefull. It also manages the framing cleverly to minimize the impact of dropped packets, which improves performance when noise is high and/or signal is low (I.e. long range).
> - You need packet sequence numbers to prevent replays (I expect you do this already for error handling).
> - You need a few extra bytes in the packet for the tag (a signed cryptographic checksum).
>
> any secure protocol will require these two in any case.
So, unless the radio is applying the encryption after doing those things, the encryption won't actually be invisible to the end user. They will see a penalty in effective range. But the processor on the radio is meek, that's why weak systems like TEA are being seriously considered. It might just be possible to run them on the radio hardware.
This is why I'm advocating frame-packing and encryption be shifted onto another, abundantly powerful computer. No reason to compromise then.
Chris Gough
Ritchie Wilson
May 24, 2013, 10:33:02 AM5/24/13
to drones-...@googlegroups.com
We already have the Xbee channel and encryption stuff to inhibit spoofing. Whilst this is interesting it is well above our remit.
Regards
Ritchie.
Regards
Ritchie.
Gareth Owen
May 24, 2013, 10:47:51 AM5/24/13
to drones-...@googlegroups.com
Chris et al,
On Friday, May 24, 2013 3:33:45 PM UTC+1, Chris Gough wrote:
Here are some figures at http://perso.uclouvain.be/fstandae/lightweight_ciphers/ about crypto on an AVR.
AES is faster than TEA, but TEA is about a third of the code size. AES can achieve throughput of 70kbytes/sec+ on a 16Mhz AVR - a SoC Linux chip is not needed. Maybe even the 3DR 8051 can do it. Although with CCM mode, the rate is halved because two operations are required per block.
Ritchie: The ZigBee does has adequate security (although I haven't checked the implementation) - but we're using 3dr radios - hence the discussion.
Best
Gareth
On Friday, May 24, 2013 3:33:45 PM UTC+1, Chris Gough wrote:
> The only two cons are:
> - You need packet sequence numbers to prevent replays (I expect you do this already for error handling).
> - You need a it.
few extra bytes in the packet for the tag (a signed cryptographic checksum).
>
> any secure protocol will require these two in any case.
The current radio ito firmware is protocol aware. It injects RSSI data, which is very usefull. It also manages the framing cleverly to minimize the impact of dropped packets, which improves performance when noise is high and/or signal is low (I.e. long range).
Ritchie Wilson
May 24, 2013, 11:04:11 AM5/24/13
to drones-...@googlegroups.com
Ah. I was unaware that the 3DRs didn't support this natively. I'm still using the Xbees from when I started three years ago.
This also raises an issue. People still using Xbees or something else need a flag to turn it off.
Regards
Regards
Ritchie.
--
Chris Gough
May 24, 2013, 11:21:55 AM5/24/13
to drones-...@googlegroups.com
> AES is faster than TEA, but TEA is about a third of the code size. AES can achieve throughput of 70kbytes/sec+ on a 16Mhz AVR - a SoC Linux chip is not needed. Maybe even the 3DR 8051 can do it.
If adding a new node to the comms subsystem, why would we chose an avr? It's not a hard realtime problem, we have a reasonable power budget (heck, it's hooked up to a transmitter).
A Linux SOC might be computational overkill, but that's not a bad problem to have. As an environment for munging data on the fly, what could be more developer-friendly?
Chris Gough
Lorenz Meier
May 24, 2013, 12:40:36 PM5/24/13
to drones-...@googlegroups.com
Hi all,
We will have results on CCM (PX4FMU + QGC in the best case, timings on PX4FMU in the expected case) hopefully mid of next week. I didn't want to guide the discussion in any particular direction, but this is what our crypt partner already started working on, with pretty much the same objectives that Gareth had.
As I initially posted we're first after authentication and then would consider (a few months down the road) looking at real encryption. The primary objective is to prevent that someone else can hijack or crash your system by hacking / replay / any of the typical attacks.
MAVLink has a packet sequence number and since e.g. QGC keeps track of them per component, you can even route messages from multiple onboard sources without requiring them to be touched by the radio.
I'm still not sure why the encryption would have to happen on the radio. No-one said encrypted packets can't have a non-encrypted STX sign and a length (which is all you need for framing), and you send the RSS in plaintext to the autopilot, which can return that info to his comm partner encrypted if needed (or you just send it as plaintext, which gives away some info, but not much). I'm not in general objecting it, its just that I haven't seen a convincing technical explanation that made really clear what required this (other than providing a transparent encryption).
I also propose to go to the Digikey website and check AVR vs. Cortex-M3 vs. BeagleBone vs. (the really not useful) Raspberry Pi pricing (at Farnell) before jumping to conclusions on the platform required. Please also keep in mind that the platform should be decent to work with for crypto developers (!= flight code developers or general users).
At the end of the day I would be surprised if the F4 (or the SiLabs radio Tride proposed) can't pull off AES in SW (you can even buy the F4 variant with HW AES if you're desperate), and any other solution which doesn't have the crypto engine in the autopilot or radio seems to just add complexity.
But again, this is down the road. Please keep the discussion active and contribute, and the more we disagree, the more we'll eventually learn.
We will have results on CCM (PX4FMU + QGC in the best case, timings on PX4FMU in the expected case) hopefully mid of next week. I didn't want to guide the discussion in any particular direction, but this is what our crypt partner already started working on, with pretty much the same objectives that Gareth had.
As I initially posted we're first after authentication and then would consider (a few months down the road) looking at real encryption. The primary objective is to prevent that someone else can hijack or crash your system by hacking / replay / any of the typical attacks.
MAVLink has a packet sequence number and since e.g. QGC keeps track of them per component, you can even route messages from multiple onboard sources without requiring them to be touched by the radio.
I'm still not sure why the encryption would have to happen on the radio. No-one said encrypted packets can't have a non-encrypted STX sign and a length (which is all you need for framing), and you send the RSS in plaintext to the autopilot, which can return that info to his comm partner encrypted if needed (or you just send it as plaintext, which gives away some info, but not much). I'm not in general objecting it, its just that I haven't seen a convincing technical explanation that made really clear what required this (other than providing a transparent encryption).
I also propose to go to the Digikey website and check AVR vs. Cortex-M3 vs. BeagleBone vs. (the really not useful) Raspberry Pi pricing (at Farnell) before jumping to conclusions on the platform required. Please also keep in mind that the platform should be decent to work with for crypto developers (!= flight code developers or general users).
At the end of the day I would be surprised if the F4 (or the SiLabs radio Tride proposed) can't pull off AES in SW (you can even buy the F4 variant with HW AES if you're desperate), and any other solution which doesn't have the crypto engine in the autopilot or radio seems to just add complexity.
But again, this is down the road. Please keep the discussion active and contribute, and the more we disagree, the more we'll eventually learn.
Chris Gough
May 25, 2013, 1:43:21 AM5/25/13
to drones-...@googlegroups.com
> I'm not in general objecting it, its just that I haven't seen a convincing technical explanation that made really clear what required this (other than providing a transparent encryption).
Transparency is compelling; it makes the encrypting-modem more versatile, e.g. The existing autopilot fleet, different applications...
> I also propose to go to the Digikey website and check AVR vs. Cortex-M3 vs. BeagleBone vs. (the really not useful) Raspberry Pi pricing (at Farnell) before jumping to conclusions on the platform required.
Quality of the distribution/community matters too. Don't want to manage and distributes software packages if it can be avoided.
> ...any other solution which doesn't have the crypto engine in the autopilot or radio seems to just add complexity.
The complexity we most need to avoid is wires and plugs. In the simplest (typical) configuration, a few extra chips on the same PCB as the radio seems rather harmless. For complex setups (onboard Ethernet connecting payloads, redundant links, etc) it might actually reduce component count by 1.
Chris Gough
john...@gmail.com
May 26, 2013, 9:56:45 AM5/26/13
to drones-...@googlegroups.com
I am not saying encryption is useless, but at the moment I think there are many of other cases that are more much important to use our limited resources on.
- JAB
On Thursday, May 23, 2013 3:37:33 PM UTC+2, Gareth Owen wrote:
- JAB
On Thursday, May 23, 2013 3:37:33 PM UTC+2, Gareth Owen wrote:
Dear allWith the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
john...@gmail.com
May 26, 2013, 10:03:47 AM5/26/13
to drones-...@googlegroups.com
Also, if one of the reasons for using encryption is to prevent accidental MAVlink conflicts/takeovers, just hash a user generated password and use that as a ID to validate each command. Trying to prevent malicious attacks is a MUCH more complicated topic, and FAR outside the scope of the APM platform if you ask me.
Meier Lorenz
May 26, 2013, 11:52:55 AM5/26/13
to <drones-discuss@googlegroups.com>
JAB,
I think you're also completely overestimating the runtime and implementation overhead of a solid auth solution. There is a library doing all the hard work (libtomcrypt), PX4 has the processing power to handle it, and implementing CCM with AES is less complex than implementing some home-grown semi-smart solution that can be easily hacked. It only becomes arduous if you try to fit it to an already pretty much loaded system like APM 2.5 or the 3DR radio (with the current chip, there is an AES-enabled one that should be able to pull it off). This is just one instance of many where the additional processing power of PX4 will allow to get us with less effort to quite good solutions.
The killer argument for doing it right vs doing it half is this: I'm not going to put my name on the line (nor should anybody else) for calling something "secure" or just even "robust" that inherently is not, when a proper, well-understood solution is within reach. Right now the situation is very simple: There is no security, and its within your responsibility.
Doing that would be like selling a customer a door without a lock for his house. You can still close it, but the first random guy who tries to open it will make you as Engineer look really bad, because the customer assumed he would be safe, since a door is a door, right?
Also keep in mind that not everybody on this list (or at my university) is interested in flight code development and so the developer pools are not the same. Obviously what should not happen is that Tridge or I go dark for four weeks to implement this. Last but not least evolving the protocol could mean attracting "protocol people", which would help us to distribute the flight-related protocol work better.
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
I think you're also completely overestimating the runtime and implementation overhead of a solid auth solution. There is a library doing all the hard work (libtomcrypt), PX4 has the processing power to handle it, and implementing CCM with AES is less complex than implementing some home-grown semi-smart solution that can be easily hacked. It only becomes arduous if you try to fit it to an already pretty much loaded system like APM 2.5 or the 3DR radio (with the current chip, there is an AES-enabled one that should be able to pull it off). This is just one instance of many where the additional processing power of PX4 will allow to get us with less effort to quite good solutions.
The killer argument for doing it right vs doing it half is this: I'm not going to put my name on the line (nor should anybody else) for calling something "secure" or just even "robust" that inherently is not, when a proper, well-understood solution is within reach. Right now the situation is very simple: There is no security, and its within your responsibility.
Doing that would be like selling a customer a door without a lock for his house. You can still close it, but the first random guy who tries to open it will make you as Engineer look really bad, because the customer assumed he would be safe, since a door is a door, right?
Also keep in mind that not everybody on this list (or at my university) is interested in flight code development and so the developer pools are not the same. Obviously what should not happen is that Tridge or I go dark for four weeks to implement this. Last but not least evolving the protocol could mean attracting "protocol people", which would help us to distribute the flight-related protocol work better.
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
Am 26.05.2013 um 16:03 schrieb john...@gmail.com<mailto:john...@gmail.com>:
Also, if one of the reasons for using encryption is to prevent accidental MAVlink conflicts/takeovers, just hash a user generated password and use that as a ID to validate each command. Trying to prevent malicious attacks is a MUCH more complicated topic, and FAR outside the scope of the APM platform if you ask me.
- JAB
On Thursday, May 23, 2013 3:37:33 PM UTC+2, Gareth Owen wrote:
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf> with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
Also, if one of the reasons for using encryption is to prevent accidental MAVlink conflicts/takeovers, just hash a user generated password and use that as a ID to validate each command. Trying to prevent malicious attacks is a MUCH more complicated topic, and FAR outside the scope of the APM platform if you ask me.
- JAB
On Thursday, May 23, 2013 3:37:33 PM UTC+2, Gareth Owen wrote:
Dear all
With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
It might also be worth knowing more about the 3dr radios and what processing power they have.
Best
Gareth
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
Anish Mohammed
May 26, 2013, 12:18:52 PM5/26/13
to l...@inf.ethz.ch, <drones-discuss@googlegroups.com>
Hi Lorenz,
I hope to look into the implementation once it done and shall share my findings :). If i find anything interesting I shall offer implementers some early warning ahead of publishing, if there is anything interesting enough to be published.
Regards
Anish
PS:- as i had mentioned in my previous mail, libtomcrypt has never undergone cryptographic scrutiny as openssl or similar crypto libraries
Anish Mohammed
Twitter: anishmohammed
http://uk.linkedin.com/in/anishmohammed
On 26 May 2013, at 16:52, "Meier Lorenz" <l...@inf.ethz.ch> wrote:
> JAB,
>
> I think you're also completely overestimating the runtime and implementation overhead of a solid auth solution. There is a library doing all the hard work (libtomcrypt), PX4 has the processing power to handle it, and implementing CCM with AES is less complex than implementing some home-grown semi-smart solution that can be easily hacked. It only becomes arduous if you try to fit it to an already pretty much loaded system like APM 2.5 or the 3DR radio (with the current chip, there is an AES-enabled one that should be able to pull it off). This is just one instance of many where the additional processing power of PX4 will allow to get us with less effort to quite good solutions.
>
> The killer argument for doing it right vs doing it half is this: I'm not going to put my name on the line (nor should anybody else) for calling something "secure" or just even "robust" that inherently is not, when a proper, well-understood solution is within reach. Right now the situation is very simple: There is no security, and its within your responsibility.
> Doing that would be like selling a customer a door without a lock for his house. You can still close it, but the first random guy who tries to open it will make you as Engineer look really bad, because the customer assumed he would be safe, since a door is a door, right?
>
> Also keep in mind that not everybody on this list (or at my university) is interested in flight code development and so the developer pools are not the same. Obviously what should not happen is that Tridge or I go dark for four weeks to implement this. Last but not least evolving the protocol could mean attracting "protocol people", which would help us to distribute the flight-related protocol work better.
>
> -
>
I hope to look into the implementation once it done and shall share my findings :). If i find anything interesting I shall offer implementers some early warning ahead of publishing, if there is anything interesting enough to be published.
Regards
Anish
PS:- as i had mentioned in my previous mail, libtomcrypt has never undergone cryptographic scrutiny as openssl or similar crypto libraries
Anish Mohammed
Twitter: anishmohammed
http://uk.linkedin.com/in/anishmohammed
On 26 May 2013, at 16:52, "Meier Lorenz" <l...@inf.ethz.ch> wrote:
> JAB,
>
> I think you're also completely overestimating the runtime and implementation overhead of a solid auth solution. There is a library doing all the hard work (libtomcrypt), PX4 has the processing power to handle it, and implementing CCM with AES is less complex than implementing some home-grown semi-smart solution that can be easily hacked. It only becomes arduous if you try to fit it to an already pretty much loaded system like APM 2.5 or the 3DR radio (with the current chip, there is an AES-enabled one that should be able to pull it off). This is just one instance of many where the additional processing power of PX4 will allow to get us with less effort to quite good solutions.
>
> The killer argument for doing it right vs doing it half is this: I'm not going to put my name on the line (nor should anybody else) for calling something "secure" or just even "robust" that inherently is not, when a proper, well-understood solution is within reach. Right now the situation is very simple: There is no security, and its within your responsibility.
> Doing that would be like selling a customer a door without a lock for his house. You can still close it, but the first random guy who tries to open it will make you as Engineer look really bad, because the customer assumed he would be safe, since a door is a door, right?
>
> Also keep in mind that not everybody on this list (or at my university) is interested in flight code development and so the developer pools are not the same. Obviously what should not happen is that Tridge or I go dark for four weeks to implement this. Last but not least evolving the protocol could mean attracting "protocol people", which would help us to distribute the flight-related protocol work better.
>
> -
>
> ------------------------------------------------------
> Lorenz Meier
> Institute for Visual Computing
> ETH Zurich
> http://www.inf.ethz.ch/personal/lomeier/
>
> Am 26.05.2013 um 16:03 schrieb john...@gmail.com<mailto:john...@gmail.com>:
>
> Also, if one of the reasons for using encryption is to prevent accidental MAVlink conflicts/takeovers, just hash a user generated password and use that as a ID to validate each command. Trying to prevent malicious attacks is a MUCH more complicated topic, and FAR outside the scope of the APM platform if you ask me.
>
> - JAB
>
> On Thursday, May 23, 2013 3:37:33 PM UTC+2, Gareth Owen wrote:
> Dear all
>
> With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
>
> Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
>
> My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf> with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
>
> It might also be worth knowing more about the 3dr radios and what processing power they have.
>
> Best
> Gareth
>
> --
> You received this message because you are subscribed to the Google Groups "drones-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "drones-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
> Lorenz Meier
> Institute for Visual Computing
> ETH Zurich
> http://www.inf.ethz.ch/personal/lomeier/
>
> Am 26.05.2013 um 16:03 schrieb john...@gmail.com<mailto:john...@gmail.com>:
>
> Also, if one of the reasons for using encryption is to prevent accidental MAVlink conflicts/takeovers, just hash a user generated password and use that as a ID to validate each command. Trying to prevent malicious attacks is a MUCH more complicated topic, and FAR outside the scope of the APM platform if you ask me.
>
> - JAB
>
> On Thursday, May 23, 2013 3:37:33 PM UTC+2, Gareth Owen wrote:
> Dear all
>
> With the increasing popularity of the ardupilot project and increasing usage for commercial applications - I think we should start thinking about authenticating and protecting communication over the 3dr radios. At present, it is trivially easy to steal someone else's quadcopter or cause it to crash (I know the RC link is vulnerable too but we could think about that too).
>
> Last year I showed how to take control of a weaponised bomb disposal robot (no names) due to a poor cryptography implementation - they'd used AES so badly that you didn't even need to know it was encrypted.
>
> My expertise is in Cryptography - does anyone else on the list have expertise in this area and interested in coming up with some draft designs for a secure mavlink (probably using authenticated encryption like CCM<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf> with AES)? We'd need to do some performance and CPU load experiments on the PX4. I don't think the APM2.5 has enough CPU for a cryptoed link - but the PX4 may do. So it's very much a feature that would be 6-12 months down the line, if not more.
>
> It might also be worth knowing more about the 3dr radios and what processing power they have.
>
> Best
> Gareth
>
> --
> You received this message because you are subscribed to the Google Groups "drones-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "drones-discuss" group.
Gareth Owen
May 26, 2013, 12:47:05 PM5/26/13
to drones-...@googlegroups.com
I'm in agreement here. Doing it right is easy (on the px4) - a few days work. It's also implement and forget.
Adding it to the apm is probably not practical although I suspect none of us know this for sure - OCB mode is twice as fast as CCM but has patent issues for anyone wishing to commercialise the software (IANAL). My guesstimate is a 1-2ms overhead per packet with OCB.
Gareth
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/3xPmB3O2lPA/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.
Meier Lorenz
May 26, 2013, 12:54:28 PM5/26/13
to <drones-discuss@googlegroups.com>
Thanks Anish,
> PS:- as i had mentioned in my previous mail, libtomcrypt has never undergone cryptographic scrutiny as openssl or similar crypto libraries
I'm not too worried about this aspect. First, its license is quite permissive, second there is this hint:
http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-55010/Source/libtomcrypt/doc/libTomCryptDoc.pdf
If you then read up about CommonCrypto:
https://developer.apple.com/library/mac/#documentation/security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html
Citing from the page:
"In OS X v10.5 and later and iOS 5.0 and later, Common Crypto provides low-level C support for encryption and decryption. "
So we're probably speaking about all Mac OS X 10.5+ and iOS 5.0+ devices that have some parts of libtomcrypt deployed and probably in use. So far Apple's security track record isn't too bad if I recall correctly, and they certainly how to code efficient and fast, which we very much care about.
-Lorenz
> PS:- as i had mentioned in my previous mail, libtomcrypt has never undergone cryptographic scrutiny as openssl or similar crypto libraries
http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-55010/Source/libtomcrypt/doc/libTomCryptDoc.pdf
If you then read up about CommonCrypto:
https://developer.apple.com/library/mac/#documentation/security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html
Citing from the page:
"In OS X v10.5 and later and iOS 5.0 and later, Common Crypto provides low-level C support for encryption and decryption. "
So we're probably speaking about all Mac OS X 10.5+ and iOS 5.0+ devices that have some parts of libtomcrypt deployed and probably in use. So far Apple's security track record isn't too bad if I recall correctly, and they certainly how to code efficient and fast, which we very much care about.
-Lorenz
Meier Lorenz
May 26, 2013, 12:59:53 PM5/26/13
to <drones-discuss@googlegroups.com>
Just for reference: I'm not opposing to use any other library that is BSD compatible (preferably) and which we can benchmark.
As the end of the day and if we have enough time, we should just benchmark and base our decision based on this (and the security track record, of course).
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
As the end of the day and if we have enough time, we should just benchmark and base our decision based on this (and the security track record, of course).
-Lorenz
------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/
Robert Lefebvre
May 27, 2013, 10:01:36 AM5/27/13
to drones-discuss
I don't have a lot of input on this subject other than to say I think it's worthwhile if somebody wants to take this on and... this is difficult to say but, you should really consider involving Kevin Finisterre in this effort in some way. He's very interested in this subject, it's what he does for a living (penetration testing). I don't know if he can help develop the right solution, per se, but can at least prevent you from going too far down the wrong path. When I say he's interested in the subject, I mean that he and a few others are already working on hacking these links. This is not done for evil reasons, but actually to expose weaknesses so that people can fix them before a truly evil person can exploit the weakness. This is what he does for a living.
Fact is, it's easier to involve him now, and get his positive input. Rather than not involving him, and just throwing something out there that he'll just see as a challenge and try to crack anyway. And then if he does... I'm sure everybody knows exactly how that will go down.
I think if you engage him with the right attitude, he'd be on our side, and we'll have a better result.
Craig Elder
May 31, 2013, 5:03:27 PM5/31/13
to drones-discuss
Robert,
Kevin Finisterre is not a friend. Anybody proclaiming a personal vendetta against any one of our team members is somebody we need to avoid.
witness...@gmail.com
Nov 4, 2013, 6:25:16 PM11/4/13
to drones-...@googlegroups.com
Hi All,
only problem with the PIXHAWK is that it uses the none crypto variant of the STM32 F427 instead of the more expensive by 2.00 us STM32 F437 which supports AES and hashing primitives.
things might be a lot easier on the processor load(the crypto tax) if the STM32 F437 was used instead(pin compatible).
more later
witness digital
only problem with the PIXHAWK is that it uses the none crypto variant of the STM32 F427 instead of the more expensive by 2.00 us STM32 F437 which supports AES and hashing primitives.
things might be a lot easier on the processor load(the crypto tax) if the STM32 F437 was used instead(pin compatible).
more later
witness digital
Reply all
Reply to author
Forward
0 new messages