Skip to content
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

Closed
gfwilliams opened this issue Jan 7, 2020 · 19 comments
Closed

settings: Bluetooth whitelisting #78

gfwilliams opened this issue Jan 7, 2020 · 19 comments

Comments

@gfwilliams
Copy link
Member

@gfwilliams gfwilliams commented Jan 7, 2020

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

@profriemke
Copy link

@profriemke profriemke commented Mar 25, 2020

I think this is a very important issue to adress to make Bangle.js waterproof for everyday use.

@profriemke
Copy link

@profriemke profriemke commented Mar 25, 2020

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.

@gfwilliams
Copy link
Member Author

@gfwilliams gfwilliams commented Mar 26, 2020

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

@profriemke
Copy link

@profriemke profriemke commented Mar 26, 2020

Bangle.js does it better! 🥇

@unmotivatedgene
Copy link
Contributor

@unmotivatedgene unmotivatedgene commented Apr 11, 2020

An easy gap fix may be to add a setting that forces the "Programmable" setting to OFF when Bluetooth becomes disconnected.

@gfwilliams
Copy link
Member Author

@gfwilliams gfwilliams commented May 15, 2020

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?

@profriemke
Copy link

@profriemke profriemke commented May 15, 2020

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.

@gfwilliams
Copy link
Member Author

@gfwilliams gfwilliams commented May 15, 2020

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.

@Jasper-Ben
Copy link
Contributor

@Jasper-Ben Jasper-Ben commented Jul 7, 2020

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?).

@Jasper-Ben
Copy link
Contributor

@Jasper-Ben Jasper-Ben commented Jul 7, 2020

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.

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.

@gfwilliams
Copy link
Member Author

@gfwilliams gfwilliams commented Jul 7, 2020

Maybe this should be communicated clearer on the website

The very first item on the Troubleshooting page does suggest turning Programmable to on: https://www.espruino.com/Troubleshooting+Bangle.js

I think maybe the thing to do would be to move Programmable to 'Advanced' options - there's no reason a normal user would want to turn that to off right now - if you don't want anything accessing the watch you should just turn BLE off. Programmable is really if you've defined some custom service, are using the Bluetooth UART yourself, or something like that - but right now I'm not aware of any apps that do that

@Jasper-Ben
Copy link
Contributor

@Jasper-Ben Jasper-Ben commented Jul 7, 2020

@kuleszdl
Copy link
Contributor

@kuleszdl kuleszdl commented Jul 29, 2020

@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.

@gfwilliams
Copy link
Member Author

@gfwilliams gfwilliams commented Jul 30, 2020

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'.

@Jasper-Ben
Copy link
Contributor

@Jasper-Ben Jasper-Ben commented Jul 30, 2020

Thank you for working on this @gfwilliams 👍

@gfwilliams
Copy link
Member Author

@gfwilliams gfwilliams commented Jul 30, 2020

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.

@kuleszdl
Copy link
Contributor

@kuleszdl kuleszdl commented Jul 30, 2020

Thanks a lot @gfwilliams !

I tested this but Gadgetbridge does not work for me in the following constellation:

  • Passkey mode enabled
  • Programmable off
  • Device whitelisted

Turning programmable to on makes it work. However, as long as whitelisting works I can live with Gadgetbridge requiring the programmable permission.

@kuleszdl
Copy link
Contributor

@kuleszdl kuleszdl commented Jul 30, 2020

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!

@gfwilliams
Copy link
Member Author

@gfwilliams gfwilliams commented Jul 30, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants