What I miss in the device manager

[Marcel Mulder]

Hi,

I have used several Bluetooth Low Energy solutions and I looked into several examples and something is missing. What I miss is to prevent pairing. It is something quite obvious. At least from my point of view. You don't want you neighbor to be able to pair with your device.

Most examples I see is that you activate (turn on) the device and you can pair with your phone. Some devices are limited to pair only with one device so you have your security settled now. But what if it can pair with more than one device? When it is turned on other people can pair as long as it is not connected.

What I want is to confirm the pairing or to initiate the pairing from my device. My device only has one button. I have looked into static pin pairing but as the iPhone has a display it will pop-up with a random pin code which I can't type because I have only one button. As far as I know it is not possible in iOS the say that it has only keyboard capabilities. So I end up with a device having no capabilities and therefore only supports it "just works". But this is a security issue in my opinion. I want to be in control to who or what my devices pairs to.

The nicest solution would be to initiate the pairing and than confirm it on my device with the button. This is however, a scenario they did not thought of when writing the Bluetooth Low Energy specification. There is no defined (or unlimited) timeout between initiate pairing and confirming. So between SMP Pairing Request and SMP Pairing Response. Because of the user interaction the timeout here should be quite large.

The other scenario (and I have used this one on anther device) is to press the button so it can be paired for e.g. 30 seconds. If the button is not pressed only devices which have bond information are allowed to connect. All other devices are disconnected immediately. The drawback here is that if you have multiple devices it is hard to choose the correct device on your smart phone.

Anyway, the device manager has no hooks or events I can use to prevent the device manager from pairing and directly disconnect when not in pairing mode and no bonding information is found.

Now finally my question. Does somebody else thought about this or am I the only one. Are there other possibilities I overlooked? Please let me know.

Best Regards, Marcel

[Hung Bui]

Hi Marcel,

What I understand here is that you want to allow your neighbor's phone to connect to your device but don't want his phone to be able to pair with the device ?

If it is the case, you can simply catch the BLE_GAP_EVT_SEC_PARAMS_REQUEST and send the sd_ble_gap_sec_params_reply with and error (from BLE_GAP_SEC_STATUS) to avoid pairing. You can have a look here. This event handled automatically in device manager with a success reply for any master, but you can add your code here to wait for the confirmation from end user before sending the reply.

If it's not the case, and you don't want your neighbor to connect (and bond) to your device, then you can use white list to avoid unwanted connection.

To build the whitelist, you can set an option for the device to enter bonding mode (that accept all devices to connect and bond). You can also use RSSI (that only accepts connection from device let's say in the range of 3m) to avoid your neighbour to connect to your device when in this bonding mode. The bonding mode period can be started by holding the button when starting, or by sending a command with the app on the phone.

After you have done with bonding, you can use the address information for the whitelist and avoid unwanted connection.

[EDITED with correct information on case #1. ]

[Hung Bui]

Actually whitelist can do the task.

We feed data to the whitelist from the bond information we store in device manager. It's true that we don't know the BT address up front, but we do know after bonding.

Even if the central device use random BT address and change it every 15 minutes (iOS devices), the IRK number will remain the same and we can use IRK to recognized a bonded device when doing whitelist. You can have a look at Resolvable Private Address in the Bluetooth spec (section 10.8 Vol 3 Part C Core spec 4.1).

What I ment with "bonding period" is advertising without whitelist, it's pretty much not related to device manager.

We tried to make the device manager as generic as possible, so it may not have all the features that you wanted. But I think it is quite straight forward to modify the code and add your needed features in.