5 ms·
BlueSteal: Popping GATT Safes
- erohead 9y agoVery informative walk-through of a BT security analysis. Thanks for including links to tools and clear code snippets.
- IshKebab 9y agoBLE isn't actually totally secure in any mode except OOB pairing, which is only supported on Android, and only via NFC. Kind of ridiculous really. I'm pretty sure they didn't make any attempt to fix the issues in Bluetooth 5 either.
- bschwindHN 9y agoWhat 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 agoYeah 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 agoOkay 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 agoWhy use BLE instead of wifi? That's what most devices do (especially with the ESP8266, which doesn't support BLE).
- bschwindHN 9y agoThat'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 agoI 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 agoYeah 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 agoAh, great, because when I last looked at an iOS device, the user had to switch between the WiFi network manually, which was a hassle.
- 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 agoHomeKit implements all its own security on top of BLE
- paulgerhardt 9y agoWe 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 agoThat's encouraging to hear! I'm working on an ESP32 so it should have plenty of power to do it.
- ctz 9y agoBLE Secure Connections, supported on Bluetooth 4.2 and later.
- IshKebab 9y agoNo, 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 agoCould 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 agoSome 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 agoThanks! That's enlightening.
- YouKnowBetter 9y agoYes, security (exclusivity) is on the application layer and user defined. Welcome to BT :)
- bschwindHN 9y agoHow about BLE Secure Connections in BLE 4.2 as ctz mentioned?
- simias 9y agoPretending to use encryption when you don't is pretty damning. Everything else can be blamed on incompetence but it seems hard to imagine that they thought they were using AES256 when they aren't.
- qwerty456127 9y agoI have always believed ALL the BlueTooth connections are encrypted strongly too. And this is why I thought BlueTooth keyboards are safe while common non-BT wireless keyboards can be easily sniffed by a neighbour.
- YouKnowBetter 9y agoBluetooth <> Bluetooth. There are (about) 37 distinct profiles [0]. One of these is HID (Human Interface Device Profile) Keyboard and keypads must be secure. For other HIDs security is optional. [0] https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
- FooHentai 9y agoNah, it differs between the Bluetooth device profiles, and even wildly within each profile. Audio headsets are particularly weak - Ostensibly using a '128 bit' cypher in many instances which turns out to be the c0 stream cypher, proven to be weak and effectively only 56 bit. The situation is exacerbated by how little product manufacturers have to say on the subject.
- IshKebab 9y agoActually having worked a lot with BLE it isn't hard to imagine at all. The way to set up encryption is really very weird, and there isn't any obvious indication that it is enabled.
- weq 9y agoIf u are a non-technical founder and outsource your dev work, and no one audits anything, its very easy to claim stuff that doesnt actually exist. Willful(?) ignorance. At my last employeer we handled legal data over the internet and all the encryption had been disabled and never turned back on. The CTO was a DBA, and the CEO thought he was god and never questioned anything he produced. I came in and almost left straight away, but felt sorry for the clients who paid for this garbage. And the (multiple different) legal software platforms we integrated with was not much better, embedding master passwords / decryption routines in un-obfuscated dlls.
- deleted 9y ago[deleted]
- danesparza 9y agoWhat kind of a world do we live in where a gun safe requires a firmware update to patch a security vulnerability?
- kabdib 9y agoDon't trust electronic locks. Years ago I got a safe that wasn't one of the top-end models of its line. In particular, the manual said that it only had one combination slot. But other models had more premium features, such as multiple combinations, "master" and "slave" combos, etc. -- I acquired the manual for them, and sure enough, these features were present on my cheaper model, with default combinations. My guess is that anyone could walk up to one of these safes in someone's home and open it within seconds. I assume this is well known in the industry. I also have to assume that there are additional hidden combinations, meant for manufacturer convenience, or put there with a wink and a nod to the police, or installed by unscrupulous firmware engineers.
- ufmace 9y agoExactly. This sort of thing is why nobody who owns or uses guns has much interest in so-called "smart guns". A real security audit on what they're supposed to accomplish and how they would physically work will show that it's not a very effective idea.
- ChuckMcM 9y agoSo to be fair I find the idea of a "blue tooth connected gun safe" to be something of a weird product to begin with. I think that because I believe a gun safe serves two purposes; Keeping kids (and others in the house) from getting access to a gun, and making stealing the gun more difficult or less useful. That said, given that I have been approached by, and on occasion done work for, manufacturers who wanted to add some additional "techno" flair to their existing product, I have seen requirements documents which were painfully thin on measurable security requirements. It does not surprise me at all that the implementation of this system was functional and from a security perspective quite flawed. What would surprise me is that the company learned from that and actually upgraded their requirements generating process.