6 ms·

What can you do to ensure security on a BLE connection? Do your own key exchange and encrypt on top of the BLE layer?

IshKebab 9y ago
Yeah the only way really is to totally reimplement your own key exchange and encryption on top of unencrypted BLE. That is an absolute mountain of work though, unless you happen to have an uncharacteristically powerful BLE device. I seriously doubt anyone would ever attempt it. Maybe Google would, but last I looked at their IoT stuff they still hadn't got around to supporting BLE at all so... I think the best compromise is to use "just works" pairing which doesn't have any flaws that I know of, but allows MitM by design. And then add a QR code so you have at least some vague protection against connecting to the wrong device. Oh also there is a 'numeric comparison' authentication method but it requires your device to have a screen, which is not very common.
- bschwindHN 9y ago
  Okay so I'm implementing a device which connects to Wifi, and I'm using BLE to hand off Wifi creds from a phone app to the device. This is based on the esp32 chip. They actually have something similar to what I described that they call "blufi" but it's poorly documented and seems difficult to use: http://esp-idf.readthedocs.io/en/latest/api-reference/bluetooth/esp_blufi.html http://esp-idf.readthedocs.io/en/latest/api-reference/blueto... Right now I'm just using the "just works" pairing as you've described. A QR code might be a good addition to that, though the product then needs a unique sticker for each device which is kinda lame. Without the QR code, the threat model is basically someone eavesdropping on the connection and discovering the Wifi credentials when the user first sets up the device. Not the worst but still not great...
  - StavrosK 9y ago
    Why use BLE instead of wifi? That's what most devices do (especially with the ESP8266, which doesn't support BLE).
    - bschwindHN 9y ago
      That's a good question, actually. As far as I'm aware, it's not particularly well supported to programmatically connect to another access point, but that may have changed recently. But that aside, using BLE seems like a better user experience. There's no changing of the user's currently connected access point, and it _might_ be faster, though I haven't tested. If I can make the setup over Wifi completely transparent to the user then that would be acceptable for me. I actually don't own any ESP8266-based devices, maybe I should buy one and see how it is.
      - StavrosK 9y ago
        I don't think the ESP8266 wifi story is different from the ESP32, but it might be. You do have to connect to another access point, yes, but if you have an Android app, the app can handle that itself. I think the iOS UX is a bit worse, though, so BLE might be worth it there. A lot of firmware for the ESP8266 has been using the access point method, and it's worked great all the times I've tried it.
        bschwindHN 9y ago
        Yeah the Wifi story is pretty much the same between the two chips. I agree about Android, I don't think I'd have much problem configuring it there, but my first focus is on iOS. There seems to be some better support for that in iOS 11 though: https://developer.apple.com/library/content/qa/qa1942/_index.html https://developer.apple.com/library/content/qa/qa1942/_index... So that might be a good option in the near future!
        StavrosK 9y ago
        Ah, great, because when I last looked at an iOS device, the user had to switch between the WiFi network manually, which was a hassle.
    - danesparza 9y ago
      I would think power consumption would come into play, considering the safe is most likely not constantly connected to power. BLE is an order of magnitude more efficient with power than Wifi is: https://www.digikey.com/en/articles/techzone/2011/aug/comparing-low-power-wireless-technologies https://www.digikey.com/en/articles/techzone/2011/aug/compar...
- koolba 9y ago
  > Oh also there is a 'numeric comparison' authentication method but it requires your device to have a screen, which is not very common. It doesn't have to be a screen, it can be any form of user facing output. If you have an audio output (ex: speaker or headphone jack) you can use text to speech to output the pin code. I've seen VOIP devices with a similar setup using land line phones (i.e. the output is delivered over telephone wire on a RJ11 jack).
- mrpippy 9y ago
  HomeKit implements all its own security on top of BLE
- paulgerhardt 9y ago
  We did this a few years ago with Lockitron. It's a small hill of work. Don't need a device more powerful than a standard Nordic or TI chip.
  - bschwindHN 9y ago
    That's encouraging to hear! I'm working on an ESP32 so it should have plenty of power to do it.
ctz 9y ago
BLE Secure Connections, supported on Bluetooth 4.2 and later.
- IshKebab 9y ago
  No, those are what I am talking about. The connection is secure but the key exchange is not. There are various flaws depending on the mode used. There is an Out-of-Band mode which means you could implement your own actually-secure key exchange but for extremely annoying reasons it isn't implemented on iOS or Android (except via NFC on Android).
  - ctz 9y ago
    Could you provide some references to how the LESC key exchange is insecure? That is notably different information from that in (eg.) NIST SP800-121.
    - IshKebab 9y ago
      Some links here: https://devzone.nordicsemi.com/question/83373/secure-ble-pairing-is-it-possible/ https://devzone.nordicsemi.com/question/83373/secure-ble-pai... Not 100% sure how accurate it all is but it's not exactly reassuring and I never found anyone claiming that it is inaccurate.
      - ctz 9y ago
        Thanks! That's enlightening.
YouKnowBetter 9y ago
Yes, security (exclusivity) is on the application layer and user defined. Welcome to BT :)
- bschwindHN 9y ago
  How about BLE Secure Connections in BLE 4.2 as ctz mentioned?

Yeah the only way really is to totally reimplement your own key exchange and encryption on top of unencrypted BLE. That is an absolute mountain of work though, unless you happen to have an uncharacteristically powerful BLE device. I seriously doubt anyone would ever attempt it. Maybe Google would, but last I looked at their IoT stuff they still hadn't got around to supporting BLE at all so... I think the best compromise is to use "just works" pairing which doesn't have any flaws that I know of, but allows MitM by design. And then add a QR code so you have at least some vague protection against connecting to the wrong device. Oh also there is a 'numeric comparison' authentication method but it requires your device to have a screen, which is not very common.

bschwindHN 9y ago
Okay so I'm implementing a device which connects to Wifi, and I'm using BLE to hand off Wifi creds from a phone app to the device. This is based on the esp32 chip. They actually have something similar to what I described that they call "blufi" but it's poorly documented and seems difficult to use: http://esp-idf.readthedocs.io/en/latest/api-reference/bluetooth/esp_blufi.html http://esp-idf.readthedocs.io/en/latest/api-reference/blueto... Right now I'm just using the "just works" pairing as you've described. A QR code might be a good addition to that, though the product then needs a unique sticker for each device which is kinda lame. Without the QR code, the threat model is basically someone eavesdropping on the connection and discovering the Wifi credentials when the user first sets up the device. Not the worst but still not great...
- StavrosK 9y ago
  Why use BLE instead of wifi? That's what most devices do (especially with the ESP8266, which doesn't support BLE).
  - bschwindHN 9y ago
    That's a good question, actually. As far as I'm aware, it's not particularly well supported to programmatically connect to another access point, but that may have changed recently. But that aside, using BLE seems like a better user experience. There's no changing of the user's currently connected access point, and it _might_ be faster, though I haven't tested. If I can make the setup over Wifi completely transparent to the user then that would be acceptable for me. I actually don't own any ESP8266-based devices, maybe I should buy one and see how it is.
    - StavrosK 9y ago
      I don't think the ESP8266 wifi story is different from the ESP32, but it might be. You do have to connect to another access point, yes, but if you have an Android app, the app can handle that itself. I think the iOS UX is a bit worse, though, so BLE might be worth it there. A lot of firmware for the ESP8266 has been using the access point method, and it's worked great all the times I've tried it.
      - bschwindHN 9y ago
        Yeah the Wifi story is pretty much the same between the two chips. I agree about Android, I don't think I'd have much problem configuring it there, but my first focus is on iOS. There seems to be some better support for that in iOS 11 though: https://developer.apple.com/library/content/qa/qa1942/_index.html https://developer.apple.com/library/content/qa/qa1942/_index... So that might be a good option in the near future!
        StavrosK 9y ago
        Ah, great, because when I last looked at an iOS device, the user had to switch between the WiFi network manually, which was a hassle.
  - danesparza 9y ago
    I would think power consumption would come into play, considering the safe is most likely not constantly connected to power. BLE is an order of magnitude more efficient with power than Wifi is: https://www.digikey.com/en/articles/techzone/2011/aug/comparing-low-power-wireless-technologies https://www.digikey.com/en/articles/techzone/2011/aug/compar...
koolba 9y ago
> Oh also there is a 'numeric comparison' authentication method but it requires your device to have a screen, which is not very common. It doesn't have to be a screen, it can be any form of user facing output. If you have an audio output (ex: speaker or headphone jack) you can use text to speech to output the pin code. I've seen VOIP devices with a similar setup using land line phones (i.e. the output is delivered over telephone wire on a RJ11 jack).
mrpippy 9y ago
HomeKit implements all its own security on top of BLE
paulgerhardt 9y ago
We did this a few years ago with Lockitron. It's a small hill of work. Don't need a device more powerful than a standard Nordic or TI chip.
- bschwindHN 9y ago
  That's encouraging to hear! I'm working on an ESP32 so it should have plenty of power to do it.

ctz 9y ago

BLE Secure Connections, supported on Bluetooth 4.2 and later.

IshKebab 9y ago
No, those are what I am talking about. The connection is secure but the key exchange is not. There are various flaws depending on the mode used. There is an Out-of-Band mode which means you could implement your own actually-secure key exchange but for extremely annoying reasons it isn't implemented on iOS or Android (except via NFC on Android).
- ctz 9y ago
  Could you provide some references to how the LESC key exchange is insecure? That is notably different information from that in (eg.) NIST SP800-121.
  - IshKebab 9y ago
    Some links here: https://devzone.nordicsemi.com/question/83373/secure-ble-pairing-is-it-possible/ https://devzone.nordicsemi.com/question/83373/secure-ble-pai... Not 100% sure how accurate it all is but it's not exactly reassuring and I never found anyone claiming that it is inaccurate.
    - ctz 9y ago
      Thanks! That's enlightening.

YouKnowBetter 9y ago

Yes, security (exclusivity) is on the application layer and user defined. Welcome to BT :)

bschwindHN 9y ago
How about BLE Secure Connections in BLE 4.2 as ctz mentioned?