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]

The solution I wanted to implement is the simplest one, tell me if you think it could fix the problem correctly.

When the device receives a pairing request (BLE_GAP_EVT_SEC_PARAMS_REQUEST):

• if the requesting central is not bonded: call sd_ble_gap_sec_params_reply(p_ble_evt->evt.gap_evt.conn_handle,BLE_GAP_SEC_STATUS_SUCCESS, &m_application_table[0].sec_param);

• if the requesting central is already bonded:

1. if the link is already encrypted: accept the request

2. if the link is not encrypted: deny the request sd_ble_gap_sec_params_reply(p_ble_evt->evt.gap_evt.conn_handle,BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, NULL)

I thought this would be the easiest and I was expecting to find such code in SDK 8.1.