New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
settings: Bluetooth whitelisting #78
Comments
I think this is a very important issue to adress to make Bangle.js waterproof for everyday use. |
I have been thinking about this since yesterday. I think only some users are aware of this. In my opinion it is a potential security risk which should be adressed as soon as possible. |
Yes - however sadly this is common in Smartwatches. In a lot of cases you'd be running Gadgetbridge on your phone so that would be connected all the time and would stop other devices connecting. But yes, this would be a good option to add |
Bangle.js does it better! 🥇 |
An easy gap fix may be to add a setting that forces the "Programmable" setting to OFF when Bluetooth becomes disconnected. |
New firmwares now auto-encrypt the UART, so we could actually just provide an option to set a Bluetooth pairing passkey. That might be preferable to whitelisting? |
This sounds great. Is it compatible with all common scenarios e.g. Gadgetbridge, Web IDE, connecting to other Espruinos? I think pairing with more than one of these devices would be necessary. |
Added this branch: https://github.com/espruino/BangleApps/tree/passkey_pairing But it doesn't seem to work well with Web Bluetooth. It might be we need to force pairing first somehow. |
As a smartwatch noobie I just spent multiple hours trying to figure out how gadgetbridge works, as I was not aware that the watch has to be set to programmable for the phone to be able to communicate with it. I always assumed the "programmable" part was merely related to the ability to flash new apps, thus I always had it turned off out of safety reasons. Maybe this should be communicated clearer on the website (maybe in the FAQ?). |
TBH this lack in basic security was always the reason why I continuously refused to get a smart watch (that is to say until this awesome OSS smart watch project came into existence 😄) I believe if Bangle.js fixes this, it would constitute a major advantage over their competitors. |
The very first item on the Troubleshooting page does suggest turning Programmable to I think maybe the thing to do would be to move |
That is true, however I understood this FAQ entry to concern resetting the Bangle.js if you cannot connect via BLE at all. And it again puts the programmable settings in context of connecting to the app launcher. As I didn't have issues connecting with my devices, I never would have guessed from that FAQ entry, that setting programmable has an effect on the app capabilities. Imo this could be stated more clearly in the FAQ.
|
@gfwilliams I have spent way too much time figuring out why GB did not work, too. In general, the programmable mode is quite dangerous since virtually anybody can flash and run arbitrary code on your watch. And with programmable mode off, the watch is virtually dumb. I highly appreciate this "passkey pairing setup" effort and would like to share the following suggestion: Why not make it configurable to switch between passkey pairing mode and open mode? I assume most people don't update their apps all the times. In addition, the attack vector at home is probably much lower for most folks. Therefore: When I'm at home and really want to update some apps via web bluetooth, I turn the "insecure" mode on. Once I'm done, I switch it off (or it could be auto-switched after a timeout). This way, the watch would be secure to use on the go while remaining updateable via web-bluetooth if required. Of course, a more elegant solution would be nice in the future, but for the meantime, I would consider this an acceptable fix for the imho most concerning issue at the moment. |
Ok, I just pushed a new bootloader version 0v20 - this actually lets Gadgetbridge work even with programmable:off - so should at least help with some of that confusion, and allow you to have a secure mode that works with Gadgetbridge. I'll add the passkey mode too, I'll just tag it with 'beta'. Nothing stops you from turning it on/off just as you might with 'programmable'. |
Thank you for working on this @gfwilliams 👍 |
Ok, there's now a whitelist option in settings as well, which seems to work pretty reliably. However I know some devices do implement Address Randomisation as a privacy thing, and that will obviously break the whitelist. |
Thanks a lot @gfwilliams ! I tested this but Gadgetbridge does not work for me in the following constellation:
Turning programmable to on makes it work. However, as long as whitelisting works I can live with Gadgetbridge requiring the programmable permission. |
Sorry, false alarm - it required a reboot. After the reboot, gadgetbridge didn't want to connect anymore, so I had to remove the device in bluetooth and re-pair it. This time it asked for the passkey code and now even if I turn programmable to off Gadgetbridge works. Great job! |
Just to add, the intention wasn't that you turn all of them on. Glad it still works though! Pretty much one by itself should be enough for most people |
Add the ability to whitelist certain Bluetooth devices for connections. When Bangle.js is set to programmable all the time (eg for Gadgetbridge) this is really needed for security.
http://forum.espruino.com/conversations/341437/#comment15029127
The text was updated successfully, but these errors were encountered: