nRF52840 - SDK16 - Bonding

[Nikosant03]

Hi everyone,

I am interacting with the ble_app_hrs in order to learn about bonding. I am using nRF52840 DK as a peripheral and donggle (nRF52840) as central along with the nRF Connect for Desktop.

I can perform pairing and bonding with success. However I've noticed that when I select "Delete bond information" then I am not able neither to pair nor to bond anymore and the Error "BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP" is appeard on the log menu. 

In order to work around this issue I have delete bonds from peripheral's side by pressing Button 2 during resetting .. Why I have to do this? I mean, this is the case when central deletes bond information (the peripheral must delete too)? How can I automate this procedure (my future application won't have any button to erase bonds)?

Thanks in advance 

Nick

[Einar Thorsrud]

Hi Nick,

Repairing is not allowed by default as that gives the best security, but it that not suitable for all products. You can typically allow it by adding the following in pm_evt_handler() in main.c of most BLE examples:

case PM_EVT_CONN_SEC_CONFIG_REQ:
{
    // Allow or reject pairing request from an already bonded peer.
    pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true};
    pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
} break;

Einar

[Nikosant03]

Hi Einar,

Your solution works great!! Thanks!!

In case I won't allow repairing then the only work around solution is to delete bonds on peripheral and try pairing with the central?

[Einar Thorsrud]

Good to hear.

Yes, if you do not allow repairing the only way is to delete the bonding information before you can bond again with the same peer.

[Nikosant03]

Thank you for your assistance!!

Is this approach ok to work around and delete bonds in case of traying repairing?

case PM_EVT_CONN_SEC_CONFIG_REQ: {
    // Reject pairing request from an already bonded peer.
    pm_conn_sec_config_t conn_sec_config = {.allow_repairing = false};
    pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
    advertising_start(true)
  } break;

static void delete_bonds(void) {
  ret_code_t err_code;

  NRF_LOG_INFO("Erase bonds!");

  err_code = pm_peers_delete();
  APP_ERROR_CHECK(err_code);
}

static void advertising_start(bool erase_bonds) {
  if (erase_bonds == true) {
    delete_bonds();
  } else {
    ret_code_t err_code = ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST);
    APP_ERROR_CHECK(err_code);
  }
}

[Einar Thorsrud]

Hi,

This effectively does the same thing, just less elegantly. Instead of allowing to repair you delete bonds, so that the peer would have to connect again and then pairing would succeed. This does not provide better security, as the security issue with allowing repairing is that an attacker can spoof a peered device and that way replace it's bond. This would also be the case here.

The way you describe it you need to support repairing, and then it is better to do as I suggested initially instead of doing it this way.