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.

[Nikosant03]

Hi Einar and thank you for your responce,

I'm a bit confused, to my understanding the higher security is provided by denying repairing (and this is the default value In SDK)

allow_repairing = false;

But if I do not accept repairing and the peer delete bond information, how it will repair again with the peripheral?

You said that in this case the peripheral must delete the bonding information

Einar Thorsrud said:

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

But then you said that this does not provide better security.

Einar Thorsrud said:

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.

So, is there any safe (securiy enhanced) elegant method to work around this issue?

Nick

[Einar Thorsrud]

Hi Nick,

Nikosant03 said:

But if I do not accept repairing and the peer delete bond information, how it will repair again with the peripheral?

Effectively the same thing happens in these two approaches. The old bond is removed and replaced by the new bond with the same device.

Nikosant03 said:

You said that in this case the peripheral must delete the bonding information

One possible approach which is to for instance allow repairing (or delete bonds) after a button press, or other method. That way the user explicitly allows this this to happen.

Nikosant03 said:

So, is there any safe (securiy enhanced) elegant method to work around this issue?

Not other than requiring active and conscious action from the user. As explained, the problem with allowing repairing is that an attacker can cause the existing bond to be deleted. But that is often not a big concern, and in any case it is a risk you have to be willing to take if you need to support repairing without any fuss. I mentioned the security aspect because this is a reason why repairing is disallowed by default. It doesn't mean that allowing repairing is always a bad idea, as requirements (including security) differ vastly from product to product.

Einar

[Nikosant03]

Thank you for your support Einar!!

[Mahfuzur Rahman]

Hello Mr. Einar,

I am trying to solve the static passkey problem with nRF SDK v17 with nrf 52840 evaluation board. However, I can not bond my peripheral in my first attempt. In my second attempt I can bond the peripheral (by using the bond option from nRF connect app).

I am looking for your possible suggestions to solve this issue. Also, is there any other method to start bonding without pressing button 2? I can add the code if you want to look at it. Any help would be greatly appreciated.