RE: fixed passkey and nRFConnect

Emil Lenngren — Thu, 04 Aug 2022 22:37:48 GMT

In BLE, connections are allowed to be established even if the devices are not paired/bonded. Instead, you can configure a required security level for each service and characteristic. If a non-paired client interacts with a protected characteristic, the server will send a security error to the client, usually causing the client to initiate the pairing procedure. So what you must do to secure the characteristics is to require encryption for them in the characteristic definition.

Regarding fixed passkeys, the standard says the device with a display should generate a new passkey on every pairing attempt. Fixed passkeys are totally broken security-wise due to how the protocol works. When the remote device enters the wrong passkey, the first bit that was wrong will be revealed, which will make a brute-force attempt succeed in at most 20 attempts. See https://insinuator.net/2021/10/change-your-ble-passkey-like-you-change-your-underwear/ for more info. So the security is basically equal to "Just Works", except that it might keep away non-technical people trying to pair. Unfortunately the Bluetooth standard does not offer any security feature to "login with a password". You can add such a security layer yourself on top of the application layer, using a PAKE algorithm, but this is far from trivial.

RE: fixed passkey and nRFConnect

Sigurd Hellesvik — Thu, 04 Aug 2022 14:04:17 GMT

Hi,

I will have a look into your case and return with more information tomorrow.

Regards,
Sigurd Hellesvik