You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Rodrigo Lorenzo Leal <ro...@pilloxa.com> on 2016/11/30 09:55:39 UTC
Subscription Request and Question.
To whom it might concern.
My name is Rodrigo Lorenzo Leal, and I'm the lead hardware and firmware
developer at Pilloxa <http://pilloxa.com/>.
We're currently using the Nordic nRF52 with it's SDK and recently
discovered ynewt. We're really exited about it and will give it a
try.Additionally
I have a couple of question.
In the NimBLE description <https://mynewt.apache.org/pages/ble/> it says
that mynewt offers a Security Manager (SM) with support for LE Legacy
Pairing (Just Works, Numeric Comparison, Passkey Entry, OOB), LE Secure
Connections, Transport Specific Key Distribution, but in the documentation
<https://mynewt.apache.org/latest/network/ble/ble_sec/> is says Apache
mynewt has first implemented support for "Just Works" only.
Since security is a big need for our product, we are currently considering
OOB for the key exchange. Is this implemented? and if is not, will this be
implemented in the future?
And finally, do you support Firmware Over the Air? If you do, do you have
any documentation on how to implement it? and if you don't will be
implemented in the future?
Re: Subscription Request and Question.
Posted by Christopher Collins <cc...@apache.org>.
On Wed, Nov 30, 2016 at 08:08:58AM -0800, aditi hilbert wrote:
> Rodrigo,
>
> The NimBLE description is accurate. Mynewt offers SM. The second one is woefully outdated - I\u2019ll fix that today.
> Yes, NimBLE supports OOB.
A small clarification - nimble supports OOB for legacy pairing, but not for
secure connections.
Chris
Re: Subscription Request and Question.
Posted by aditi hilbert <ad...@runtime.io>.
Rodrigo,
The NimBLE description is accurate. Mynewt offers SM. The second one is woefully outdated - I’ll fix that today.
Yes, NimBLE supports OOB.
Yes, we support over the air upgrade via BLE. Sorry there is no tutorial on it yet but we can certainly help you with that.
thanks,
aditi
> On Nov 30, 2016, at 1:55 AM, Rodrigo Lorenzo Leal <ro...@pilloxa.com> wrote:
>
> To whom it might concern.
>
> My name is Rodrigo Lorenzo Leal, and I'm the lead hardware and firmware
> developer at Pilloxa <http://pilloxa.com/>.
>
> We're currently using the Nordic nRF52 with it's SDK and recently
> discovered ynewt. We're really exited about it and will give it a
> try.Additionally
> I have a couple of question.
>
> In the NimBLE description <https://mynewt.apache.org/pages/ble/> it says
> that mynewt offers a Security Manager (SM) with support for LE Legacy
> Pairing (Just Works, Numeric Comparison, Passkey Entry, OOB), LE Secure
> Connections, Transport Specific Key Distribution, but in the documentation
> <https://mynewt.apache.org/latest/network/ble/ble_sec/> is says Apache
> mynewt has first implemented support for "Just Works" only.
>
> Since security is a big need for our product, we are currently considering
> OOB for the key exchange. Is this implemented? and if is not, will this be
> implemented in the future?
>
> And finally, do you support Firmware Over the Air? If you do, do you have
> any documentation on how to implement it? and if you don't will be
> implemented in the future?
Re: Subscription Request and Question.
Posted by Sterling Hughes <st...@apache.org>.
> +1
>
> I think even a PSK example would be helpful.
>
> On the NRF52, I think it would be practical to run DTLS over the
> transport, even if a bit heavyweight. It would be great to have an
> example of that.
>
Speaking of this, I was wondering if folks had experience with embedded
TLS libraries. Right now we bundle with mbedtls, which supports TLS,
and, as far as I can tell, DTLS as well.
I\u2019ve noticed there is tinydtls out there, has anyone compared the two?
Sterling
Re: Subscription Request and Question.
Posted by Sterling Hughes <st...@apache.org>.
On 3 Dec 2016, at 6:38, Kevin Townsend wrote:
> On 03/12/16 11:54, Tim Hutt wrote:
>> Android and iOS don't allow you to specify the keys used by BLE's
>> native
>> encryption, but there is nothing stopping you using BLE as an
>> insecure
>> transport and implementing your own encryption on top of it (well
>> apart
>> from time, skill, and flash & RAM constraints). If you did that you
>> would
>> be able to use whatever keys you wanted because you implemented it.
>>
> This seems like something that would be nice to have as a proof of
> concept demo in the core repo. I'm always interested in security, but
> it's far enough outside my own core area of competence (HW design, RF
> and sensors) that I know trying to roll my own code would do more harm
> than good and give a false sense of security. If there are people on
> the dev list with up to date experience in the field, I suspect a
> decent number of end users would benefit from a basic starting point
> to encrypt BLE communication across a simple service and
> characteristic set. The nRF52 isn't 'fast' in terms of clock speed but
> it's still a reasonably capable chip with on board AES and single
> precision HW floating point acceleration, and there is a decent amount
> of flash and SRAM available.
+1
I think even a PSK example would be helpful.
On the NRF52, I think it would be practical to run DTLS over the
transport, even if a bit heavyweight. It would be great to have an
example of that.
Sterling
Re: Subscription Request and Question.
Posted by David Simmons <sa...@mac.com>.
I'm happy to look into doing a tutorial/app on this once I'm done with the ADC, I2C and SPI ones. I could then roll it all up into the iOS demo app as well if folks think that would be a useful addition.
Best regards,
dg
--
I'll take credit For the funny typos, the rest I blame on the iPhone spell wrecker.
> On Dec 3, 2016, at 9:38 AM, Kevin Townsend <ke...@adafruit.com> wrote:
>
>
>
>> On 03/12/16 11:54, Tim Hutt wrote:
>> Android and iOS don't allow you to specify the keys used by BLE's native
>> encryption, but there is nothing stopping you using BLE as an insecure
>> transport and implementing your own encryption on top of it (well apart
>> from time, skill, and flash & RAM constraints). If you did that you would
>> be able to use whatever keys you wanted because you implemented it.
>>
> This seems like something that would be nice to have as a proof of concept demo in the core repo. I'm always interested in security, but it's far enough outside my own core area of competence (HW design, RF and sensors) that I know trying to roll my own code would do more harm than good and give a false sense of security. If there are people on the dev list with up to date experience in the field, I suspect a decent number of end users would benefit from a basic starting point to encrypt BLE communication across a simple service and characteristic set. The nRF52 isn't 'fast' in terms of clock speed but it's still a reasonably capable chip with on board AES and single precision HW floating point acceleration, and there is a decent amount of flash and SRAM available.
Re: Subscription Request and Question.
Posted by Kevin Townsend <ke...@adafruit.com>.
On 03/12/16 11:54, Tim Hutt wrote:
> Android and iOS don't allow you to specify the keys used by BLE's native
> encryption, but there is nothing stopping you using BLE as an insecure
> transport and implementing your own encryption on top of it (well apart
> from time, skill, and flash & RAM constraints). If you did that you would
> be able to use whatever keys you wanted because you implemented it.
>
This seems like something that would be nice to have as a proof of
concept demo in the core repo. I'm always interested in security, but
it's far enough outside my own core area of competence (HW design, RF
and sensors) that I know trying to roll my own code would do more harm
than good and give a false sense of security. If there are people on the
dev list with up to date experience in the field, I suspect a decent
number of end users would benefit from a basic starting point to encrypt
BLE communication across a simple service and characteristic set. The
nRF52 isn't 'fast' in terms of clock speed but it's still a reasonably
capable chip with on board AES and single precision HW floating point
acceleration, and there is a decent amount of flash and SRAM available.
Re: Subscription Request and Question.
Posted by Tim Hutt <td...@gmail.com>.
Android and iOS don't allow you to specify the keys used by BLE's native
encryption, but there is nothing stopping you using BLE as an insecure
transport and implementing your own encryption on top of it (well apart
from time, skill, and flash & RAM constraints). If you did that you would
be able to use whatever keys you wanted because you implemented it.
On 2 December 2016 at 18:49, Rodrigo Lorenzo Leal <rodrigoelorenzo@gmail.com
> wrote:
> Well those are bad news I guess.
>
> Tim, sorry to be so persisten with this but again, if neither Android nor
> iOS allow you to specify your own keys, how can you use pre-shared keys?
>
> If I understood correctly, I can install a unique key on each device at
> manufacture and keep a copy of it in the cloud. And you said that this will
> give me an out-of-the-box secure channel.
>
> 2016-12-02 19:22 GMT+01:00 Tim Hutt <td...@gmail.com>:
>
> > On 2 December 2016 at 17:09, Christopher Collins <cc...@apache.org>
> > wrote:
> >
> > > Sorry if I missed this earlier in the thread, but will iOS really let
> > > you use an external key for BLE encryption? Just based on my limited
> > > experience with CoreBluetooth, I wouldn't expect this functionality to
> > > be exposed.
> > >
> >
> > You are correct. Neither Android nor iOS allow you to specify your own
> > keys.
> >
>
>
>
> --
> Rodrigo Lorenzo Leal
>
Re: Subscription Request and Question.
Posted by Rodrigo Lorenzo Leal <ro...@gmail.com>.
Well those are bad news I guess.
Tim, sorry to be so persisten with this but again, if neither Android nor
iOS allow you to specify your own keys, how can you use pre-shared keys?
If I understood correctly, I can install a unique key on each device at
manufacture and keep a copy of it in the cloud. And you said that this will
give me an out-of-the-box secure channel.
2016-12-02 19:22 GMT+01:00 Tim Hutt <td...@gmail.com>:
> On 2 December 2016 at 17:09, Christopher Collins <cc...@apache.org>
> wrote:
>
> > Sorry if I missed this earlier in the thread, but will iOS really let
> > you use an external key for BLE encryption? Just based on my limited
> > experience with CoreBluetooth, I wouldn't expect this functionality to
> > be exposed.
> >
>
> You are correct. Neither Android nor iOS allow you to specify your own
> keys.
>
--
Rodrigo Lorenzo Leal
Re: Subscription Request and Question.
Posted by Tim Hutt <td...@gmail.com>.
On 2 December 2016 at 17:09, Christopher Collins <cc...@apache.org>
wrote:
> Sorry if I missed this earlier in the thread, but will iOS really let
> you use an external key for BLE encryption? Just based on my limited
> experience with CoreBluetooth, I wouldn't expect this functionality to
> be exposed.
>
You are correct. Neither Android nor iOS allow you to specify your own keys.
Re: Subscription Request and Question.
Posted by Christopher Collins <cc...@apache.org>.
Hi Rodrigo,
On Fri, Dec 02, 2016 at 12:30:12PM +0100, Rodrigo Lorenzo Leal wrote:
> OK so pre shared key is my best option I guess.
>
> What I don't understand is, if is possible to have pre-shared key, that is
> accesible through the cloud, why I cannot generate a key on the cloud and
> access it doing a request, from both the app and the device (through GPRS).
>
> Maybe is not a OOB pairing in the strict Bluetooth protocol definition of
> the word, but what I want to do is encrypt the BLE communication with a key
> that is not exchange via Bluetooth.
Mynewt does not currently support this. The nimble host only issues an
LE Start Encryption HCI command to the controller after a successful
pairing or bonding restoration, and the application has no say over the
specified key. In other words, there is no way bypass the pairing
process and inject a key of your own. That said, I don't think it would
be too much work to implement this feature.
Sorry if I missed this earlier in the thread, but will iOS really let
you use an external key for BLE encryption? Just based on my limited
experience with CoreBluetooth, I wouldn't expect this functionality to
be exposed.
Thanks,
Chris
Re: Subscription Request and Question.
Posted by Rodrigo Lorenzo Leal <ro...@gmail.com>.
OK so pre shared key is my best option I guess.
What I don't understand is, if is possible to have pre-shared key, that is
accesible through the cloud, why I cannot generate a key on the cloud and
access it doing a request, from both the app and the device (through GPRS).
Maybe is not a OOB pairing in the strict Bluetooth protocol definition of
the word, but what I want to do is encrypt the BLE communication with a key
that is not exchange via Bluetooth.
2016-12-02 11:59 GMT+01:00 Tim Hutt <td...@gmail.com>:
> On 2 Dec 2016 10:52 a.m., "Rodrigo Lorenzo Leal" <ro...@pilloxa.com>
> wrote:
> >
> > Tim.
> >
> > Thanks for the reply! So there's no way for the BLE library on iOS and
> > Android to get the key from an external source? (like a server request)
> and
> > use that?
>
> Correct.
>
> > Also, how does an in house developed crypto will work and how could be
> > implemented?
>
> With difficulty! The simplest way is to use a Notify characteristic and a
> Write Without Response characteristic to form a normal TCP-like channel
> (there are supposed to be native Channel-Oriented Connections coming but I
> wouldn't hold my breath). Then you can use any crypto, e.g. (D)TLS or QUIC
> or whatever. Maybe use DTLS as it is more designed for this sort of thing.
> For key exchange I would use ECJPAKE.
>
> All of that uses a ton of flash and ram so it may not be possible on a
> small micro.
>
--
Rodrigo Lorenzo Leal
Re: Subscription Request and Question.
Posted by Christopher Collins <cc...@apache.org>.
On Fri, Dec 02, 2016 at 10:59:13AM +0000, Tim Hutt wrote:
[...]
> (there are supposed to be native Channel-Oriented Connections coming but I
> wouldn't hold my breath).
Just a small clarification: connection-oriented channels were already
added in bluetooth 4.1. However, Nimble doesn't support them yet, and I
believe neither iOS nor Android supports them as well.
This may be what you meant. As I said, it was just a small
clarification :). I just wanted to mention this, because we do plan on
adding CoC support to Nimble in the future.
Chris
Re: Subscription Request and Question.
Posted by Tim Hutt <td...@gmail.com>.
On 2 Dec 2016 10:52 a.m., "Rodrigo Lorenzo Leal" <ro...@pilloxa.com>
wrote:
>
> Tim.
>
> Thanks for the reply! So there's no way for the BLE library on iOS and
> Android to get the key from an external source? (like a server request)
and
> use that?
Correct.
> Also, how does an in house developed crypto will work and how could be
> implemented?
With difficulty! The simplest way is to use a Notify characteristic and a
Write Without Response characteristic to form a normal TCP-like channel
(there are supposed to be native Channel-Oriented Connections coming but I
wouldn't hold my breath). Then you can use any crypto, e.g. (D)TLS or QUIC
or whatever. Maybe use DTLS as it is more designed for this sort of thing.
For key exchange I would use ECJPAKE.
All of that uses a ton of flash and ram so it may not be possible on a
small micro.
Re: Subscription Request and Question.
Posted by Rodrigo Lorenzo Leal <ro...@pilloxa.com>.
Tim.
Thanks for the reply! So there's no way for the BLE library on iOS and
Android to get the key from an external source? (like a server request) and
use that?
I'm more experienced on the firmware/peripheral side than in the app one (I
just did some minor test projects on Android).
Also, how does an in house developed crypto will work and how could be
implemented?
2016-12-02 11:22 GMT+01:00 Tim Hutt <td...@gmail.com>:
> Yes I know it is only against the pairing phase (I did say that in my
> previous email), but as Rodrigo said you can (apparently) force re-pairing
> so that is a small comfort. And I have read the spec and as far as I can
> tell, Francisco Corella is correct: 'LE Secure Connections' in BLE 4.2 uses
> the same Passkey Entry method as in Bluetooth Classic 2.1, which has been
> broken.
>
> Specifically compare page 6 of the 2008 Lindell attack
> <https://www.blackhat.com/presentations/bh-usa-08/
> Lindell/BH_US_08_Lindell_Bluetooth_2.1_New_Vulnerabilities.pdf>
> on Bluetooth 2.1 to Volume 3, Part H, Section 2.3.5.6.3 (lol) of the
> Bluetooth
> 4.2 Core spec
> <https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439
> >.
> The only difference I can see is that they changed from `f1` (HMAC-SHA256)
> to `f4` (AES-CMAC), presumably because BLE devices have hardware AES
> support. I can't see how that defeats the attack.
>
> Admittedly I'm not a crypto expert so I could be wrong but it's not exactly
> a complicated attack. Maybe I'll have ago at implementing it!
>
> Cheers,
>
> Tim
>
> On 1 December 2016 at 17:49, Mike Ryan <mi...@lacklustre.net> wrote:
>
> > Your link confounds different Bluetooth versions and different attacks.
> > The TL;DR:
> >
> > LE Legacy Pairing is broken and has been known to be broken since its
> > inception. I wrote on it in 2013[1] and released crackle[2] to
> > demonstrate it.
> >
> > LE Secure Connections address all the weaknesses of legacy pairing. If
> > both hosts support LE SC, you are invulnerable to a _passive_ attacker.
> > Without a display, an _active_ attacker can still MitM you. This is a
> > much more challenging attack.
> >
> > Based on my reading of the spec, it's not possible to mandate LE SC even
> > if both stacks support it. Thus an active attacker can attempt a pairing
> > downgrade attack to force the use of the weaker legacy pairing. However
> > in this scenario the attacker can fully MitM the connection, so a
> > pairing downgrade is basically pointless.
> >
> > Finally, all of these attacks are only against the pairing phase. Once
> > two devices have paired and exchanged keys, the runtime
> > encryption/authentication (based on AES-CCM) is not vulnerable to any
> > attacks.
> >
> > [1] https://www.usenix.org/conference/woot13/workshop-
> > program/presentation/ryan
> > [2] https://github.com/mikeryan/crackle
> >
> > On Thu, Dec 01, 2016 at 11:18:30AM +0000, Tim Hutt wrote:
> > > See https://pomcor.com/2015/06/03/has-bluetooth-become-secure/
> > >
> > > Basically its a mess. As far as I can tell, the actual encryption
> > (AES-128
> > > CCM) is fine, but the key exchange (pairing) methods are all broken in
> > > various ways. Just Works is vulnerable to MitM by design (a reasonable
> > > trade-off for the improved usability in some cases). Numeric Comparison
> > is
> > > actually secure, but it requires Bluetooth 4.2, a screen and "yes/no"
> > > buttons on both devices which is very often not possible. Passkey Entry
> > > (i.e. a PIN) is totallly broken. OOB is secure but you can't use it
> > anyway
> > > because of lack of support on Android and iOS.
> > >
> > > Also note that the 'LE Secure Connections' feature is optional even in
> > > Bluetooth 4.2. So even if you have a phone or peripheral that supports
> > > Bluetooth 4.2, it might still use the legacy methods.
> > >
> > > On 30 November 2016 at 17:06, Mike Ryan <mi...@lacklustre.net>
> wrote:
> > >
> > > > This is the first I've heard of LE Secure Connections having any
> > > > weakness. Can you elaborate and/or provide a citation?
> > > >
> > > > On Wed, Nov 30, 2016 at 12:23:06PM +0000, Tim Hutt wrote:
> > > > > Just in case you weren't aware, OOB is not available on iOS or
> > Android
> > > > > (except via NFC). Also all BLE pairing methods except OOB and
> Numeric
> > > > > Comparison (which requires a screen) are apparently broken in
> various
> > > > ways,
> > > > > even with LE Secure Connections.
> > > >
> >
>
Re: Subscription Request and Question.
Posted by Tim Hutt <td...@gmail.com>.
Yes I know it is only against the pairing phase (I did say that in my
previous email), but as Rodrigo said you can (apparently) force re-pairing
so that is a small comfort. And I have read the spec and as far as I can
tell, Francisco Corella is correct: 'LE Secure Connections' in BLE 4.2 uses
the same Passkey Entry method as in Bluetooth Classic 2.1, which has been
broken.
Specifically compare page 6 of the 2008 Lindell attack
<https://www.blackhat.com/presentations/bh-usa-08/Lindell/BH_US_08_Lindell_Bluetooth_2.1_New_Vulnerabilities.pdf>
on Bluetooth 2.1 to Volume 3, Part H, Section 2.3.5.6.3 (lol) of the Bluetooth
4.2 Core spec
<https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439>.
The only difference I can see is that they changed from `f1` (HMAC-SHA256)
to `f4` (AES-CMAC), presumably because BLE devices have hardware AES
support. I can't see how that defeats the attack.
Admittedly I'm not a crypto expert so I could be wrong but it's not exactly
a complicated attack. Maybe I'll have ago at implementing it!
Cheers,
Tim
On 1 December 2016 at 17:49, Mike Ryan <mi...@lacklustre.net> wrote:
> Your link confounds different Bluetooth versions and different attacks.
> The TL;DR:
>
> LE Legacy Pairing is broken and has been known to be broken since its
> inception. I wrote on it in 2013[1] and released crackle[2] to
> demonstrate it.
>
> LE Secure Connections address all the weaknesses of legacy pairing. If
> both hosts support LE SC, you are invulnerable to a _passive_ attacker.
> Without a display, an _active_ attacker can still MitM you. This is a
> much more challenging attack.
>
> Based on my reading of the spec, it's not possible to mandate LE SC even
> if both stacks support it. Thus an active attacker can attempt a pairing
> downgrade attack to force the use of the weaker legacy pairing. However
> in this scenario the attacker can fully MitM the connection, so a
> pairing downgrade is basically pointless.
>
> Finally, all of these attacks are only against the pairing phase. Once
> two devices have paired and exchanged keys, the runtime
> encryption/authentication (based on AES-CCM) is not vulnerable to any
> attacks.
>
> [1] https://www.usenix.org/conference/woot13/workshop-
> program/presentation/ryan
> [2] https://github.com/mikeryan/crackle
>
> On Thu, Dec 01, 2016 at 11:18:30AM +0000, Tim Hutt wrote:
> > See https://pomcor.com/2015/06/03/has-bluetooth-become-secure/
> >
> > Basically its a mess. As far as I can tell, the actual encryption
> (AES-128
> > CCM) is fine, but the key exchange (pairing) methods are all broken in
> > various ways. Just Works is vulnerable to MitM by design (a reasonable
> > trade-off for the improved usability in some cases). Numeric Comparison
> is
> > actually secure, but it requires Bluetooth 4.2, a screen and "yes/no"
> > buttons on both devices which is very often not possible. Passkey Entry
> > (i.e. a PIN) is totallly broken. OOB is secure but you can't use it
> anyway
> > because of lack of support on Android and iOS.
> >
> > Also note that the 'LE Secure Connections' feature is optional even in
> > Bluetooth 4.2. So even if you have a phone or peripheral that supports
> > Bluetooth 4.2, it might still use the legacy methods.
> >
> > On 30 November 2016 at 17:06, Mike Ryan <mi...@lacklustre.net> wrote:
> >
> > > This is the first I've heard of LE Secure Connections having any
> > > weakness. Can you elaborate and/or provide a citation?
> > >
> > > On Wed, Nov 30, 2016 at 12:23:06PM +0000, Tim Hutt wrote:
> > > > Just in case you weren't aware, OOB is not available on iOS or
> Android
> > > > (except via NFC). Also all BLE pairing methods except OOB and Numeric
> > > > Comparison (which requires a screen) are apparently broken in various
> > > ways,
> > > > even with LE Secure Connections.
> > >
>
Re: Subscription Request and Question.
Posted by Tim Hutt <td...@gmail.com>.
Rodrigo, GPRS will allow you to avoid MitM, but you'll still have to do
your own crypto unfortunately because OOB isn't supported on iOS or
Android. Also you might want to check if GPRS itself is secure! I expect it
probably isn't but you may not care about that depending on your paranoia
level.
There is also another option: use pre-shared keys. If you control the
device you can just install a unique key on each one at manufacture and
keep a copy of it in the cloud. That gives you an out-of-the-box secure
channel between the cloud and device (via GPRS or BLE) that you can use to
distribute more keys. It's not exactly elegant though.
Cheers,
Tim
On 2 December 2016 at 09:34, Rodrigo Lorenzo Leal <ro...@pilloxa.com>
wrote:
> Hi guys!
>
> This is actually a problem we will need to solve in the product I'm
> currently developing at my company.
>
> In our case, we have a peripheral with no screen or I/O capabilities that
> connects to an app via BLE.
>
> As I understand it (and mike explained very well in his videos), once the
> key are generated, the communication is secure. The problem is you can do
> an attack that forces a reconnection with the smartphone, and forces to
> generate new keys, and then the system is completely vulnerable.
>
> As Tim said, the more secure way of doing the pairing is NFC, but the
> problem is that is not available on iOS. In our case, because we have GPRS
> communication with a server, we can try to do the key exchange with a
> server request, therefore protecting the system from the MITM /
> reconnection hack.
>
> Does anyone have experience doing this? Do you believe is a viable option?
>
> Thanks beforehand.
>
> 2016-12-01 18:49 GMT+01:00 Mike Ryan <mi...@lacklustre.net>:
>
> > Your link confounds different Bluetooth versions and different attacks.
> > The TL;DR:
> >
> > LE Legacy Pairing is broken and has been known to be broken since its
> > inception. I wrote on it in 2013[1] and released crackle[2] to
> > demonstrate it.
> >
> > LE Secure Connections address all the weaknesses of legacy pairing. If
> > both hosts support LE SC, you are invulnerable to a _passive_ attacker.
> > Without a display, an _active_ attacker can still MitM you. This is a
> > much more challenging attack.
> >
> > Based on my reading of the spec, it's not possible to mandate LE SC even
> > if both stacks support it. Thus an active attacker can attempt a pairing
> > downgrade attack to force the use of the weaker legacy pairing. However
> > in this scenario the attacker can fully MitM the connection, so a
> > pairing downgrade is basically pointless.
> >
> > Finally, all of these attacks are only against the pairing phase. Once
> > two devices have paired and exchanged keys, the runtime
> > encryption/authentication (based on AES-CCM) is not vulnerable to any
> > attacks.
> >
> > [1] https://www.usenix.org/conference/woot13/workshop-
> > program/presentation/ryan
> > [2] https://github.com/mikeryan/crackle
> >
> > On Thu, Dec 01, 2016 at 11:18:30AM +0000, Tim Hutt wrote:
> > > See https://pomcor.com/2015/06/03/has-bluetooth-become-secure/
> > >
> > > Basically its a mess. As far as I can tell, the actual encryption
> > (AES-128
> > > CCM) is fine, but the key exchange (pairing) methods are all broken in
> > > various ways. Just Works is vulnerable to MitM by design (a reasonable
> > > trade-off for the improved usability in some cases). Numeric Comparison
> > is
> > > actually secure, but it requires Bluetooth 4.2, a screen and "yes/no"
> > > buttons on both devices which is very often not possible. Passkey Entry
> > > (i.e. a PIN) is totallly broken. OOB is secure but you can't use it
> > anyway
> > > because of lack of support on Android and iOS.
> > >
> > > Also note that the 'LE Secure Connections' feature is optional even in
> > > Bluetooth 4.2. So even if you have a phone or peripheral that supports
> > > Bluetooth 4.2, it might still use the legacy methods.
> > >
> > > On 30 November 2016 at 17:06, Mike Ryan <mi...@lacklustre.net>
> wrote:
> > >
> > > > This is the first I've heard of LE Secure Connections having any
> > > > weakness. Can you elaborate and/or provide a citation?
> > > >
> > > > On Wed, Nov 30, 2016 at 12:23:06PM +0000, Tim Hutt wrote:
> > > > > Just in case you weren't aware, OOB is not available on iOS or
> > Android
> > > > > (except via NFC). Also all BLE pairing methods except OOB and
> Numeric
> > > > > Comparison (which requires a screen) are apparently broken in
> various
> > > > ways,
> > > > > even with LE Secure Connections.
> > > >
> >
>
Re: Subscription Request and Question.
Posted by Rodrigo Lorenzo Leal <ro...@pilloxa.com>.
Hi guys!
This is actually a problem we will need to solve in the product I'm
currently developing at my company.
In our case, we have a peripheral with no screen or I/O capabilities that
connects to an app via BLE.
As I understand it (and mike explained very well in his videos), once the
key are generated, the communication is secure. The problem is you can do
an attack that forces a reconnection with the smartphone, and forces to
generate new keys, and then the system is completely vulnerable.
As Tim said, the more secure way of doing the pairing is NFC, but the
problem is that is not available on iOS. In our case, because we have GPRS
communication with a server, we can try to do the key exchange with a
server request, therefore protecting the system from the MITM /
reconnection hack.
Does anyone have experience doing this? Do you believe is a viable option?
Thanks beforehand.
2016-12-01 18:49 GMT+01:00 Mike Ryan <mi...@lacklustre.net>:
> Your link confounds different Bluetooth versions and different attacks.
> The TL;DR:
>
> LE Legacy Pairing is broken and has been known to be broken since its
> inception. I wrote on it in 2013[1] and released crackle[2] to
> demonstrate it.
>
> LE Secure Connections address all the weaknesses of legacy pairing. If
> both hosts support LE SC, you are invulnerable to a _passive_ attacker.
> Without a display, an _active_ attacker can still MitM you. This is a
> much more challenging attack.
>
> Based on my reading of the spec, it's not possible to mandate LE SC even
> if both stacks support it. Thus an active attacker can attempt a pairing
> downgrade attack to force the use of the weaker legacy pairing. However
> in this scenario the attacker can fully MitM the connection, so a
> pairing downgrade is basically pointless.
>
> Finally, all of these attacks are only against the pairing phase. Once
> two devices have paired and exchanged keys, the runtime
> encryption/authentication (based on AES-CCM) is not vulnerable to any
> attacks.
>
> [1] https://www.usenix.org/conference/woot13/workshop-
> program/presentation/ryan
> [2] https://github.com/mikeryan/crackle
>
> On Thu, Dec 01, 2016 at 11:18:30AM +0000, Tim Hutt wrote:
> > See https://pomcor.com/2015/06/03/has-bluetooth-become-secure/
> >
> > Basically its a mess. As far as I can tell, the actual encryption
> (AES-128
> > CCM) is fine, but the key exchange (pairing) methods are all broken in
> > various ways. Just Works is vulnerable to MitM by design (a reasonable
> > trade-off for the improved usability in some cases). Numeric Comparison
> is
> > actually secure, but it requires Bluetooth 4.2, a screen and "yes/no"
> > buttons on both devices which is very often not possible. Passkey Entry
> > (i.e. a PIN) is totallly broken. OOB is secure but you can't use it
> anyway
> > because of lack of support on Android and iOS.
> >
> > Also note that the 'LE Secure Connections' feature is optional even in
> > Bluetooth 4.2. So even if you have a phone or peripheral that supports
> > Bluetooth 4.2, it might still use the legacy methods.
> >
> > On 30 November 2016 at 17:06, Mike Ryan <mi...@lacklustre.net> wrote:
> >
> > > This is the first I've heard of LE Secure Connections having any
> > > weakness. Can you elaborate and/or provide a citation?
> > >
> > > On Wed, Nov 30, 2016 at 12:23:06PM +0000, Tim Hutt wrote:
> > > > Just in case you weren't aware, OOB is not available on iOS or
> Android
> > > > (except via NFC). Also all BLE pairing methods except OOB and Numeric
> > > > Comparison (which requires a screen) are apparently broken in various
> > > ways,
> > > > even with LE Secure Connections.
> > >
>
Re: Subscription Request and Question.
Posted by Mike Ryan <mi...@lacklustre.net>.
Your link confounds different Bluetooth versions and different attacks.
The TL;DR:
LE Legacy Pairing is broken and has been known to be broken since its
inception. I wrote on it in 2013[1] and released crackle[2] to
demonstrate it.
LE Secure Connections address all the weaknesses of legacy pairing. If
both hosts support LE SC, you are invulnerable to a _passive_ attacker.
Without a display, an _active_ attacker can still MitM you. This is a
much more challenging attack.
Based on my reading of the spec, it's not possible to mandate LE SC even
if both stacks support it. Thus an active attacker can attempt a pairing
downgrade attack to force the use of the weaker legacy pairing. However
in this scenario the attacker can fully MitM the connection, so a
pairing downgrade is basically pointless.
Finally, all of these attacks are only against the pairing phase. Once
two devices have paired and exchanged keys, the runtime
encryption/authentication (based on AES-CCM) is not vulnerable to any
attacks.
[1] https://www.usenix.org/conference/woot13/workshop-program/presentation/ryan
[2] https://github.com/mikeryan/crackle
On Thu, Dec 01, 2016 at 11:18:30AM +0000, Tim Hutt wrote:
> See https://pomcor.com/2015/06/03/has-bluetooth-become-secure/
>
> Basically its a mess. As far as I can tell, the actual encryption (AES-128
> CCM) is fine, but the key exchange (pairing) methods are all broken in
> various ways. Just Works is vulnerable to MitM by design (a reasonable
> trade-off for the improved usability in some cases). Numeric Comparison is
> actually secure, but it requires Bluetooth 4.2, a screen and "yes/no"
> buttons on both devices which is very often not possible. Passkey Entry
> (i.e. a PIN) is totallly broken. OOB is secure but you can't use it anyway
> because of lack of support on Android and iOS.
>
> Also note that the 'LE Secure Connections' feature is optional even in
> Bluetooth 4.2. So even if you have a phone or peripheral that supports
> Bluetooth 4.2, it might still use the legacy methods.
>
> On 30 November 2016 at 17:06, Mike Ryan <mi...@lacklustre.net> wrote:
>
> > This is the first I've heard of LE Secure Connections having any
> > weakness. Can you elaborate and/or provide a citation?
> >
> > On Wed, Nov 30, 2016 at 12:23:06PM +0000, Tim Hutt wrote:
> > > Just in case you weren't aware, OOB is not available on iOS or Android
> > > (except via NFC). Also all BLE pairing methods except OOB and Numeric
> > > Comparison (which requires a screen) are apparently broken in various
> > ways,
> > > even with LE Secure Connections.
> >
Re: Subscription Request and Question.
Posted by Tim Hutt <td...@gmail.com>.
See https://pomcor.com/2015/06/03/has-bluetooth-become-secure/
Basically its a mess. As far as I can tell, the actual encryption (AES-128
CCM) is fine, but the key exchange (pairing) methods are all broken in
various ways. Just Works is vulnerable to MitM by design (a reasonable
trade-off for the improved usability in some cases). Numeric Comparison is
actually secure, but it requires Bluetooth 4.2, a screen and "yes/no"
buttons on both devices which is very often not possible. Passkey Entry
(i.e. a PIN) is totallly broken. OOB is secure but you can't use it anyway
because of lack of support on Android and iOS.
Also note that the 'LE Secure Connections' feature is optional even in
Bluetooth 4.2. So even if you have a phone or peripheral that supports
Bluetooth 4.2, it might still use the legacy methods.
On 30 November 2016 at 17:06, Mike Ryan <mi...@lacklustre.net> wrote:
> This is the first I've heard of LE Secure Connections having any
> weakness. Can you elaborate and/or provide a citation?
>
> On Wed, Nov 30, 2016 at 12:23:06PM +0000, Tim Hutt wrote:
> > Just in case you weren't aware, OOB is not available on iOS or Android
> > (except via NFC). Also all BLE pairing methods except OOB and Numeric
> > Comparison (which requires a screen) are apparently broken in various
> ways,
> > even with LE Secure Connections.
>
Re: Subscription Request and Question.
Posted by Mike Ryan <mi...@lacklustre.net>.
This is the first I've heard of LE Secure Connections having any
weakness. Can you elaborate and/or provide a citation?
On Wed, Nov 30, 2016 at 12:23:06PM +0000, Tim Hutt wrote:
> Just in case you weren't aware, OOB is not available on iOS or Android
> (except via NFC). Also all BLE pairing methods except OOB and Numeric
> Comparison (which requires a screen) are apparently broken in various ways,
> even with LE Secure Connections.
Re: Subscription Request and Question.
Posted by Tim Hutt <td...@gmail.com>.
Just in case you weren't aware, OOB is not available on iOS or Android
(except via NFC). Also all BLE pairing methods except OOB and Numeric
Comparison (which requires a screen) are apparently broken in various ways,
even with LE Secure Connections.
If security is really important I would consider doing your own crypto,
e.g. mBedTLS has an easy to use implementation of ECJPAKE for key exchange,
and then you can use BLE's standard AES-128 CCM for encryption and
authentication - the hardware implementation is easily accessible on Nordic
chips.
On 30 Nov 2016 11:33 a.m., "Rodrigo Lorenzo Leal" <ro...@pilloxa.com>
wrote:
To whom it might concern.
My name is Rodrigo Lorenzo Leal, and I'm the lead hardware and firmware
developer at Pilloxa <http://pilloxa.com/>.
We're currently using the Nordic nRF52 with it's SDK and recently
discovered ynewt. We're really exited about it and will give it a
try.Additionally
I have a couple of question.
In the NimBLE description <https://mynewt.apache.org/pages/ble/> it says
that mynewt offers a Security Manager (SM) with support for LE Legacy
Pairing (Just Works, Numeric Comparison, Passkey Entry, OOB), LE Secure
Connections, Transport Specific Key Distribution, but in the documentation
<https://mynewt.apache.org/latest/network/ble/ble_sec/> is says Apache
mynewt has first implemented support for "Just Works" only.
Since security is a big need for our product, we are currently considering
OOB for the key exchange. Is this implemented? and if is not, will this be
implemented in the future?
And finally, do you support Firmware Over the Air? If you do, do you have
any documentation on how to implement it? and if you don't will be
implemented in the future?