Removing or invalidating a BLE bond when the app is the peripheral (CBPeripheralManager)

Our iOS app runs in the peripheral role. A hardware accessory acts as the central: it connects to the app and bonds in order to read and write characteristics we declare with encryption-required permissions. The app advertises so a previously bonded accessory can reconnect on its own.

The problem is that the bond lives on both sides and we can only clear one of them. The accessory has its own "forget this phone" function, and it can also be told to do so remotely. iOS keeps its half, and we have not found any way for the app to remove or invalidate it.

What we've checked:

CBPeripheralManager and CBCentral expose no unpair or unbond operation. A CBCentral is only visible while connected or subscribed, and its identifier is a resolved handle.

Questions:

  1. Is there a supported way for an app in the peripheral role to remove or invalidate the pairing keys for a bonded central? If we've missed an API, please point us at it.

  2. If not, what's the recommended approach when the peer has discarded its keys and the bond is no longer usable?

  3. Can a peripheral-role app detect that state — a distinguishable error or connection event when encryption fails — so we can tell the user something accurate instead of a generic connection failure?

There is no API to remove the keys by an app. As the LTK is strictly managed at the system level, the only way to remove them is by the user manually "forgetting" the paired device in System Settings.

If the remote side has lost the keys and a secure connection is tried to be established you will see a specific error: peerRemovedPairingInformation

Thank for reply. In our usecase, the iOS app uses CBPeripheralManager and the remote device is the central. Can you please let me know which specific CBPeripheralManagerDelegate callback delivers CBError.peerRemovedPairingInformation to the peripheral-role app?

In the CBPeripheralManagerDelegate documentation, the subscribe, unsubscribe, read, and write callbacks do not include an Error parameter. Is this error available through another callback?

Can this event be delivered while the app is active, suspended/backgrounded, or terminated? If it occurs while the app is not active, will the app receive the error later when it is opened or becomes active again? If so, through which callback?

Thanks!

Thank you for the reply. In our use case, the iOS app uses CBPeripheralManager and the remote device is the central. Can you please let me know which specific CBPeripheralManagerDelegate callback delivers CBError.peerRemovedPairingInformation to the peripheral-role app?

There isn't one. There's no way for the peripheral device to know when a central's connect attempt failed. However, that description is actually somewhat misleading— since the central has destroyed its credentials, it’s not actually trying to (or capable of) "connecting". It actually needs to pair, since destroying its credentials invalidated the previous relationship.

In the CBPeripheralManagerDelegate documentation, the subscribe, unsubscribe, read, and write callbacks do not include an Error parameter. Is this error available through another callback?

None of those could ever happen, since you'd need to be able to connect in order to do any of those things.

Can this event be delivered while the app is active, suspended/backgrounded, or terminated? If it occurs while the app is not active, will the app receive the error later when it is opened or becomes active again? If so, through which callback?

There isn't any event on the peripheral side. Indeed, I'm not sure why your accessory would have done ANYTHING when the iOS device approached. When your accessory destroyed it's keys, I'd expect it to have destroyed the entire "pairing record". Why would it be trying to pair/connect with an accessory it doesn't have any relationship with?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Removing or invalidating a BLE bond when the app is the peripheral (CBPeripheralManager)
 
 
Q