Multiple Pairing

[LMf]

I am working with a custom board based on nrf52833 , SDK 17.1.0 and ble_nus service implemented.

Final goal is to be able to connect to devices only if they provide the correct password.

To do that, I have implemented peer_manager library with:

#define SEC_PARAM_BOND 1 /**< Perform bonding. */
#define SEC_PARAM_MITM 1 /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC 0 /**< LE Secure Connections enabled. */
#define SEC_PARAM_KEYPRESS 0 /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES BLE_GAP_IO_CAPS_DISPLAY_ONLY /**< No I/O capabilities. BLE_GAP_IO_CAPS_DISPLAY_ONLY */
#define SEC_PARAM_OOB 0 /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE 7 /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE 16

and a static STATIC_PASSKEY.

After implementation, device requires password to make a bond with a central but it does not require any security for connections.

After reading some threads, I mix peer_manager implementation with whitelist so as to limit connection to devices bonded.

Now, I am able to pair with one central and then only connections with that central are allowed. However, I would like to pair with more central devices and it seems that I need to delete whitelist in order to include a new pair device. I checked MAX_BOND devices and it is 8, so theoretically, application should be able to have a whitelist of 8 device

As I said, final goal is to be able to connect to devices only if they provide the correct password.

[Einar Thorsrud]

Hi,

First of all, please note that using a static passkey is not secure. It can be very easily brute forced. There may be use cases where it makes sense none he less, but it is important to be aware of this.

Regarding whitelist, it is possible to temporarily disable the whitelist when you want to bond with a new device without deleting the old bonds. You can see this done in several of the BLE examples in the nRF5 SDK, where they call ble_advertising_restart_without_whitelist(). Typically this is upon a button press that indicate that the device should enter pairing mode and allow connections from anywhere for a short time.

[LMf]

Thank you so much for your reply!
Regarding the static passkey, what other solutions would you suggest to add some level of security while bonding? My current device (peripheral) does not have display capacity that's the reason why I have implemented a static passkey that should be written in the central.
Regarding whitelist, I saw the function that you comment but I don't have a button or some peripheral to enable or disable the whitelist. However, after checking the behavior of typical BLE devices, I guess this is the most suitable option and I will re design the PCB to include a button which allows restart without whitelist.

[Einar Thorsrud]

Hi,

If you do not have any display or keyboard, there is no other simple alternative to a static passkey if you want some form of man in the middle protection.

There are however more complex custom solutiosn that could be considered, but the design of these would be up to you, and it would typically requier a cloud service of some sort. An idea here could be that each device is provisioned with a private key in production, and you keed the corresponding public key and an identifier on the clouad. And then your custom app running on a phone sees which peripheral it is, and retrieves the public key for this device from the cloud service. With that, your phone can use that to verify the identity and encrypte the link at the application layer (and for instance transmitt secrets that can subsequently be used for bonding). But this is far from straight-forward, and as mentionned, would be up to you.

Parially due to this complexity, it is not unusual to use static passkey, and if the goal is to prevent accidental bonding to a wrong devie it may be good enough. But it is important to be aware that it will not stop a competent attacker.