Device manager issues a DM_EVT_SECURITY_SETUP_REFRESH event even though link is not encrypted

[Louis]

Hello, I am using SDK 7.2 with SD110 7.3.0 and I am having a security issue when an attacker is able to steal the BD address of a previously bonded device.

The security issue I am seeing is that if the attacker immediately issues an SMP pairing request before encrypting the link, the device manager will behave as if this was a request for refreshing the link keys from the previously bonded device although the connection was not secured (and therefore the peer is not authentified).

I would have expected this request to be denied unless the link was secured. I am attaching the capture of this problem: SMP_pairing_request_not_denied.pcapng

[Hung Bui]

Hi Louis,

We have that DM_EVT_SECURITY_SETUP_REFRESH, for the use case that when the end user, on central device accidentally click "Forget this device" or "Unpair this device" and want to pair again. In that case, the central device wouldn't be able to encrypt the link with the stored LTK. And the encryption request will come when the link is not encrypted.

I understand that there could be a thread that the attacker can use to replace the old bond information. There are some solutions I can think of:

• Only allow the bonded central to update the bond information when the device in bonding mode (with or without whitelist). If we get an pairing request when we are not in bonding mode we will reject SMP pairing request with sd_ble_gap_sec_params_reply(BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP).

• Don't allow bonded central to update bond information (disconnect and don't store bond info). Erase all/one (by physically pressing a button on device) is required if a old central want to update new bond.

• Simply store new bonding as new device (with same central address) allow the old central to be able to re-bond.

• Having extra (proprietary) authentication after bonding to be able to gain access or store bond information.

All of this require modification in the device manager. I think the solution is largely depended on the application, so it's up to the developer to choose what should be done.

[Hung Bui]

@ Louis:

• Solution 1: No, there is no bonding mode in the DM, I was talking about a mode that is defined in the application in main.c on your own. To be able to enter bonding mode, end user must press a button on the device, or use another bonded device to send the command to start in bonding mode. So that the device can bond or update bond information.

I assume that with your solution, you allow anyone with new phone can bond to your device.

I don't think there is any "refresh" request in Bluetooth LE that update the keys. There is a key refresh request but that simply do the encryption again with the same key (refreshing the counter). The application wouldn't receive any event for that. The application receive BLE_GAP_EVT_CONN_SEC_UPDATE when SMP pairing request (start new bond) is sent. And SMP pairing request should only come if the link is not encrypted.

Also with your solution, when end user accidentally delete bond information on the phone, they will need to erase either all bond information or must have a way to select his bond information on the nRF51 to erase.