This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

  • 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.

  • 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

  • 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.

  • @ 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.

Related