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.

[Louis]

Hi Hung Bui,

Thanks for the reply. I have the following remarks on your solutions:

• solution 1: I could not find bonding state anywhere, if you mean when our device is in a mode to accept new bonding requests (like a limited time on a user action), then what will happen if the phone actually wants to refresh the bonding information

• solution 2: what will happen with phones that actually want to refresh the bonding information

• solution 3: I can not implement it and I am not sure the DM supports several entries with the same BD address

• solution 4: I can not comment, it is proprietary