securing the bluetooth pairing with pin code

[sle118]

Discussed in #217

^{Originally posted by DariBer January 14, 2023}
I have a question regarding securing Bluetooth pairing a device like iPhone with a Squeezelite-ESP32 . When pairing an iPhone or what ever using bluetooth, do you know if I can secure that process with maybe a 4 digit code? Cause now anyone who’s near (like on the street, neighbours in the house) can connect to it and start to play music, as it doesn’t need any code. So is there a chance to set a pin code and only the one who know that code can pair and start use the device for streaming?

[sle118]

Code change is implemented locally but I need to carefully think about impacts to existing users

[DariBer]

@sle118 great news, hope you'll release it soon, I can test it if you want, I don't care if I need to repair everything.

[emlynmac]

Code change is implemented locally but I need to carefully think about impacts to existing users

I'd love to have a look at this; it's one of the things I really want- anyone outside my place can hook into my garage speakers….
Is there a branch with the feature you could push up?

[loicloic]

@sle118 Any news on this feature ? Is it available in any other branch ?

[sle118]

@sle118 Any news on this feature ? Is it available in any other branch ?

Spare time has been sparse in the past few months so no update. Three main issue with this change is that pin code security is a compile time configuration that will break everyone's config.

[loicloic]

I understand now this would be a breaking changes. But what if it's clearly stated as such or even in another branch ? I get that you might not want to have to support it but if the code is written already would you mind sharing it over in a gist for other to look at or decide to compile on their own ?

As some people mentioned having Bluetooth wide open is far from ideal in certain physical setup conditions.

[Chaostheorie]

So, as far as I can tell, the relevant sdkconfig parameter is CONFIG_BT_SINK_PIN. This is used in components/driver_bt/bt_app_sink.c with the BT Legacy Pairing. So it will be skipped when using SSP. This parameter is also shown in the NVS editor as bt_sink_pin.

I tried to disable SSP, with CONFIG_BT_SSP_ENABLED=n. This works so far as that the initiator sees the sink and can initiate a static pin-based pairing however this lead to a BT Auth failure on the server (E (93643) BT_AV: authentication failed, status:9), which results in an error within squeeze lite. This seems like a bug.

Would it maybe be possible to adjust the sink driver to look up the pin during boot, like the device name, from the NVS config? If you want to stay fully backwards compatible, make the default behavior for BT GAP a dynamic pin and only request a fixed pin w/o SSP when explicitly configured by the user.

I'm not too familiar with the esp-idf API for BT, but this seems doable and not necessarily a breaking change. It would require changes to the bt_app_sink.c, the Web UI and how the sdkconfig is handled tough.

[Axolord]

I want to leave this here, so that other people can find it more easily:
#421 (comment)

Still haven't had a chance to do a proper review with competing life priorities. Pin code is problematic because it will likely break most people's configuration. Instead of a pin code, it would be best to instead do something similar to what homeassistant does for pairing ZigBee or zwave devices, which is a "pair" button in the UI (or a hardware button key, like gpio0 that could be bound to that function via the existing JSON configuration for buttons and rotary). Pairing mode would activate for a limited time and associated devices hardware address stored in nvm. This is also how some devices like headsets, Bluetooth speakers, etc. Work

I also share the opinion, that implementing some kind of pairing mode should be preferred over pin pairing, not only because it can use modern Secure Simple Pairing, but also because it is more in line with what traditional bluetooth audio devices do.