Cannot re-bond when peer is deleted from nRF52 but not from iOS

[BretH]

Our project is using SDK 15.3.0 on a nRF25840. Similar to this post, we'd like to be able to re-bond if the bond has been deleted on the Nordic side but not on the phone side. Given iOS restrictions that prevent an iOS app from deleting a bond from the system, requiring a non-tech-savvy user to go to their system BT settings is less than ideal.

Our specific application has an entire security layer built at the application level, so we are not concerned about the security implications. Yet we want bonding so that we can use LE privacy. We also whitelist with our advertising. Our normal bonding trigger is to rely on insufficient authentication/encryption on our GATT chars.

We desire to maintain a relationship with 1 mobile device at a time, therefore, we delete a previous bond with each new bonding. As a result, the follow scenario could be common: phone A bonds with our device, then phone B bonds (phone A bonding is deleted), then phone A attempts to re-bond but fails.

Our nRF device only allows new bonds if the user puts the device into a specific bonding-allowed mode. Given this and our application-security layer, we'd like to be able to bond without the user needing to delete our device from the iOS system BT menu.

Is there a way to allow the SDK to repair without removing the bond from the phone? We see the PM_EVT_CONN_SEC_FAILED event, but it's unclear if it's too late to recover. We have "allow_repairing = true" in PM_EVT_CONN_SEC_CONFIG_REQ. 

Our alternative is to maintain a larger peer list (rather than delete the previous peer with each new bond) and only add our single desired device to the whitelist, but we'll still need to limit the peer count and we may eventually encounter the limit and need to delete a peer. Meanwhile, the phone's bond may still be present.

[Einar Thorsrud]

Hi,

Is there a way to allow the SDK to repair without removing the bond from the phone?

In the case you describe, the bonding information is removed on the nRF but not on the iPhone. There is no to pair these devices again without removing the bond on the iPhone as well in this case. This is for security reasons, and unlike the nRF SoftDevice, the BLE API on the iOS does not allow you to specify that bonds can be overwritten (or even delete bonds from an app, as you write). So in other words, there is nothing you can do with this issue from the nRF side if you use bonding.

Our alternative is to maintain a larger peer list (rather than delete the previous peer with each new bond) and only add our single desired device to the whitelist, but we'll still need to limit the peer count and we may eventually encounter the limit and need to delete a peer. Meanwhile, the phone's bond may still be present.

This approach is viable. I do not see any problem with this. As you write, you may need to delete bonds at some point (though if you have a lot of flash space available that may be more theoretical then practical depending on how your product is used). If so, you would be back to a situation where the bond would have to be deleted on the phone for any deleted bonds. Note that the peer manager library has a concept of peer ranking, so you can easily find out which bonds are recently used or not, and only delete bonds that have not been recently used.