BlueSteal: Popping GATT Safes
twosixlabs.com
twosixlabs.com
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.
[0] https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
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.
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.
It seems like it doesn't actually do any of what it claims to do. It's like putting your guns in a normal safe, setting it to 0-0-0-0-0 and writing the code on the outside.
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.
Kind of ridiculous really. I'm pretty sure they didn't make any attempt to fix the issues in Bluetooth 5 either.
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.
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...
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.
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.
https://developer.apple.com/library/content/qa/qa1942/_index...
So that might be a good option in the near future!
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).
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).
Not 100% sure how accurate it all is but it's not exactly reassuring and I never found anyone claiming that it is inaccurate.