So 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.
Pretending 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.
If 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.
Actually 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.
I 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.
Bluetooth <> 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.
Nah, 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.
Seems like the FTC could go after them for false advertising. I'd go as far as saying that this product is a scam.
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.
Exactly. 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.
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.
> 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).
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:
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...
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.
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.
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:
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/compar...
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).
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.