BLE stack loads old CCCD values after removing bonds on client side and reconnect

RE: BLE stack loads old CCCD values after removing bonds on client side and reconnect

Hung Bui — Mon, 12 May 2025 12:48:17 GMT

Hi Biliy,
Actually you are right about overwriting bond. I was under the impression that it's not possible but it's actually is if the bond is higher level than level 2 (Just Work).
So only for Just work it's disabled by default and can be enable with CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE. But for bonding with MITM it seems that re-bond is allowed.

I will check internally to see if there is an option to disable that.

Resetting the CCCD value after a new bond would be a good option. It's the server that store the CCCD's value, so the client either need to read the value of the CCCD to know if it should expect notification or reset it with a write.

RE: BLE stack loads old CCCD values after removing bonds on client side and reconnect

vitaliy2034 — Mon, 12 May 2025 06:12:19 GMT

Hi Emil,
Thank you very much for your detailed reply.

For testing, we are using automated scripts that control a Nordic dongle, which has been flashed with a modified BLE Interactive Command Line Interface Example.

If I understand you correctly, there is currently no straightforward solution officially recommended by the Bluetooth SIG for this particular case.

Could you also please confirm if I have correctly understood your suggested possible solutions:

The client should ignore any unsolicited indications/notifications from the peripheral if it did not subscribe to them.
If the peripheral receives a pairing request from the central while a bond already exists, and the requested security level is not higher than the existing bond, the peripheral can treat this as a new bond and reset all relevant data.
As an alternative, both devices can implement the Bluetooth BMS (Bond Management Service) to synchronize bond removal.

Additionally, I have a clarification question regarding option 2:
If a new bond is detected in this way, should the application explicitly reset the CCCD values to 0x0000 in the peripheral firmware, or does the Nordic BLE stack automatically handle the CCCD reset when a new bond replaces the old one?

Thank you again for your help and clarification!

RE: BLE stack loads old CCCD values after removing bonds on client side and reconnect

vitaliy2034 — Mon, 12 May 2025 05:05:04 GMT

Hi Hung,

To perform a new pairing, I pressed the "Bond" button again in the nRF Connect app after reconnecting in step 5:

And after that, the pairing completes successfully:

RE: BLE stack loads old CCCD values after removing bonds on client side and reconnect

Emil Lenngren — Wed, 07 May 2025 10:35:54 GMT

"When this desynchronization occurs, the behavior becomes unpredictable. In my case, when connecting to a commercial device, this mismatch sometimes freezes the BLE stack, regardless of whether the connection is encrypted or not."

This doesn't seem that good. What BLE stack do you have that it is this buggy? The BLE spec says in the same chapter, section 10.3.2.2, that "Any notifications received before the security requirements are met shall be ignored."

The BLE spec doesn't seem to discuss your particular case though. Per the BLE spec, it is theoretically possible that the client did not remove the bond but just wanted to upgrade the security level of its bond by sending a Pairing request, before encryption using the old LTK has been started (see flow chart figure 10.2 in the same chapter), right after the server sent a Peripheral Security Request with the intention to start encryption of the existing LTK rather than pairing. Unfortunately, it is impossible for the peripheral to distinguish between a new bond and an upgraded bond in case the new requested security level is higher than the old one. So, if a client receives unsolicited notifications, the most appropriate action seems to be to just ignore them. The client could also write 0x0000 to the CCCD an extra time in case it is unsynchronised.

That said, if the peripheral receives a Pairing request from a central when a bond already exists, which does not request a higher security level than what is already present in the current bond, it can assume that it is a new bond. In particular, if the peripheral only allows pairing at the highest security level (LESC + MITM with 128-bit key) at all times, it can safely assume it is not an upgrade but a new bond. In that case (assuming the user, after confirmation, even allows a new bond in this case), the peripheral should reset all CCCDs to the default value (0x0000).

In order to synchronise bond removal, you can use the https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/libraries/bluetooth/services/bms.html BMS standard service. But both sides need to implement it in order for it to be useful.

RE: BLE stack loads old CCCD values after removing bonds on client side and reconnect

Hung Bui — Wed, 07 May 2025 08:09:22 GMT

Hi Billy,
As far as I know Zephyr won't allow a re-pairing with the same central (unless you configured so, and only applied for Justwork).

As mentioned earlier, the way it should work in my opinion is that when the central deletes bond, the peripheral need to delete the bond to the same central as well. How the peripheral delete bond depend on the design choice, either having a physical button or having an encrypted command (proprietary) to erase bond.

Could you describe how you did this " I reconnect (as in step 5) and perform a new pairing and bonding additionally, the peripheral still attempts to send indications on value update, " ?

RE: BLE stack loads old CCCD values after removing bonds on client side and reconnect

vitaliy2034 — Wed, 07 May 2025 07:52:28 GMT

Hi Hung and Emil, thank you both for the detailed responses, and apologies for the late reply.

I completely agree that checking the security level before sending notifications or indications is a good safeguard. However, even when the required security level is enforced, the core issue of CCCD desynchronization between the peripheral and central still persists — and that’s where my main concern lies.

To clarify further: even if, after the central deletes the bond, I reconnect (as in step 5) and perform a new pairing and bonding additionally, the peripheral still attempts to send indications on value update, based on the old CCCD state that was cached from the previous bond. This happens before the central has explicitly enabled indications in the current session.

According to the Bluetooth specification, a peripheral must not send notifications or indications unless the client has enabled them via the CCCD. When this desynchronization occurs, the behavior becomes unpredictable. In my case, when connecting to a commercial device, this mismatch sometimes freezes the BLE stack, regardless of whether the connection is encrypted or not.

So the key question remains:
What is the correct and recommended way to handle(on peripheral or central side) or reset the CCCD state when the bond has been removed on the central side but still exists on the peripheral?

Any clarification or best practice from Nordic would be very helpful.

RE: BLE stack loads old CCCD values after removing bonds on client side and reconnect

Emil Lenngren — Tue, 06 May 2025 16:54:56 GMT

The Bluetooth 6.0 spec says the following (Vol 3: Host, Part C: Generic Access Profile, 10.3.1.1):

Handling of GATT indications and notifications

A client “requests” a server to send indications and notifications by appropriately configuring the server via a Client Characteristic Configuration Descriptor. Since the configuration is persistent across a disconnection and reconnection, security requirements shall be checked against the configuration upon a reconnection before sending indications or notifications. When a server reconnects to a client to send an indication or notification for which security is required, the server shall initiate or request encryption with the client prior to sending an indication or notification. If the client does not have an LTK, indicating that the client has lost the bond, enabling encryption will fail.

So yes, if the server is the peripheral role and encryption has not yet been enabled, it should send a Peripheral Security Request, wait for encryption started OR pairing completion (assuming the peripheral allows re-pair attempts at this point, perhaps after user consent) with sufficient security level, THEN send the characteristic notification.

RE: BLE stack loads old CCCD values after removing bonds on client side and reconnect

Hung Bui — Fri, 02 May 2025 11:33:42 GMT

Hi Biliy,

I was thinking of the encryption property of the characteristic would help preventing the notification but it's not true. Even if the connection doesn't meet the encryption requirement of the characteristic , the notification will still be sent if the cache used.

My suggestion is to add a check for the current security level of the connection before sending the notification. This way even if the CCCD is set, you can avoid having the notification being sent when the link is not encrypted at the correct level.

RE: BLE stack loads old CCCD values after removing bonds on client side and reconnect

vitaliy2034 — Thu, 01 May 2025 06:04:22 GMT

Thank you for your reply. I agree with your argument, but this behavior creates a situation where the peripheral device is bonded, and the client is not (bonds are lost, for example, because of application data reset). After that, the same client initiates the pairing again, as it thinks, with a new device. After reconnecting, the peripheral device loads the old (previous) connection with the old CCCD values, but the client assumes it has connected to a new device and does not expect these CCCD values, which, in our case, causes unexpected notifications and, as a result, the client's BLE stack to get stuck.

Please advise the proper way to handle this situation. Maybe there is some way to check if the client has bonds?

I've also tried to send a peripheral security request but got the same behavior.

RE: BLE stack loads old CCCD values after removing bonds on client side and reconnect

Hung Bui — Tue, 29 Apr 2025 13:23:43 GMT

Hi Biliy,

I believe it's not a bug but a feature.
When you connect to a previously bonded device and the device now has removed bond with you, you are not expected to remove the previous bond and remove the gatt cache (CCCD cache)
The reason for that is that an attacker can easily spoof the peer device address and pretend that the bond has been removed (and maybe request a new bond).

You can either allow overwriting using this config CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE (only for just work) or request end user proactively remove bond on the device itself.

So from my point of view GATT cache should not be automatically removed. It should only be remove when delete bond button is pressed/selected on the device itself.