nRF52840 - SDK16 - Bonding

Question

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 · Accepted Answer

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

Einar Thorsrud · Answer

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.

Einar Thorsrud · Answer

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

nRF52840 - SDK16 - Bonding

Top Replies