BLE security

[Anne]

Yo!

I'm very concerned by what I hear about Bluetooth Low Energy security. According to this guy, who presented a paper on the subject at a USENIX conference last year, the protection provided by the Just Works and Passkey Entry key exchange methods is extremely poor. They also describe ways to make devices which have already bonded renegotiate long-term keys - somewhat undermining the argument that once bonding has taken place data is secure.

That leaves Out-Of-Band which, according to this thread, isn't supported by common centrals > _ <

I guess my question is "How do I securely transfer data using Bluetooth Low Energy?" Do I need to completely give up on the 'protection' provided by BLE and implement something at the application layer? Also, who makes common centrals and how can I send them pleading letters begging for OOB support? (this last question is only semi-serious btw ;))

Thanks for your comments!

[Ulrich Myhre]

Hi,

Yes, the difference between Just Works and MITM-protected pairing is very minor. With MITM, the PIN is a randomly generated 6-digit number, and in Just Works it is always 000000. This leaves the devices vulnerable to passive sniffers - if they are able to catch the connection request and all the packets in the pairing procedure. Once the procedure is done, the keys used for future encryptions are pretty solid, so your security should lie in protecting the intitial setup.

There are a few ways to do this, and one of them is to simply reduce TX power and hold the devices close during the pairing. This is no silver bullet, but any packet lost for the sniffer will make it very hard to regenerate the temporary session key used to exchange long-term keys.

Another way is to make your own authentication scheme based on GATT, and invalidate the bond once a peer misbehaves. This requires some APP-support on both ends, and is sort of vulnerable to reverse-engineering, so a well-tested algorithm suited for the purpose should be used. Also consider that low-power chips are generally a bit slow and limited for advanced crypto, so I would try to avoid e.g. elliptic curves unless you're basically not doing anything else than encrypting :)

The best way is of course to use OOB together with e.g. NFC to exchange a key, but since a certain big brand of mobile phones do not yet have NFC capability, and very few (none?) support OOB key generation and usage, you're out of luck on that one. Hackers are already interested in the technology, which is widespread, so I hope the vendors are starting to see the need for better encryption options.

[Anne]

Thanks for that answer, it's good to see my options clearly laid out. The one reservation I have about the "secure your initial session" philosophy is that section 6.1 of the paper I cited theorises an attack which forces long-term key re-negotiation :P Thanks for the tip about reducing TX power, I guess that will need to do until the day OOB support becomes a thing.

[Ulrich Myhre]

Yes, it is possible, but it should be quite tricky and intrusive. You have to pretend to be the other device and respond with an LL_REJECT_IND before the other device can send its encryption response. Then, depending on the devices, you must either jam them into a disconnection or hope they can continue with a new pairing - given that they are now in two different SMP states.

As long as the second pairing is secured in the same manner as the first, this should be fine, although bothersome for the user. But it is good to have this in the back of your head if you want to make an application that can recognize such attacks and provide warnings when you suspect that they happen.