Bonding

What Is BLE Bonding?

Bonding is the process of persisting the encryption keys generated during pairing into non-volatile storage so that two BLE devices can reconnect securely in the future without repeating the pairing procedure. A bonded relationship is essentially a "remembered" pairing.

What Gets Stored

After a successful pairing with bonding enabled, each device stores several keys:

• LTK -- the Long Term Key used to encrypt future connections.
• IRK -- the Identity Resolving Key, used to resolve Resolvable Private Addresses and identify the peer.
• EDIV + Rand -- diversifiers that help locate the correct LTK during reconnection (Legacy Pairing only).
• CCCD state -- per-client ATT">GATT & ATT">notification/indication subscription preferences.
• Peer address -- the identity address (public or static random) of the bonded device.

Bonding vs. Pairing

The terms are often confused. Pairing is the real-time key-exchange procedure. Bonding is the decision to store those keys persistently. A device can pair without bonding (keys discarded after disconnection) or pair with bonding (keys saved). The SMP feature exchange includes a "Bonding Flags" field where each device indicates whether it wants to bond.

Reconnection Flow

When a bonded device reconnects, the central sends an LE Start Encryption request referencing the stored LTK. The peripheral's SMP looks up the LTK by the peer's identity and responds. If successful, the link is encrypted within a single connection event, typically adding less than 10 ms of overhead. This is dramatically faster than full pairing, which can take several seconds.

Bond Storage Limits

Embedded BLE SoCs have finite flash storage for bond records. Common limits range from 8 to 20 bonds. When storage is full, the device must either reject new pairings or evict the oldest bond (Least Recently Used policy). Firmware should implement a clear-bonds mechanism (e.g., holding a button for 10 seconds) and handle the "bond database full" event gracefully.

Cross-Transport Bonding

Bluetooth 4.2 introduced Cross-Transport Key Derivation (CTKD), allowing a device that bonds over BLE to derive keys for Bluetooth Classic and vice versa, avoiding the need to pair separately on each transport. This is particularly useful for dual-mode peripherals such as wireless earbuds that use Classic for audio streaming and BLE for control.

Common Issues

Bond corruption is a frequent field issue. If one device clears its bond database (e.g., after a factory reset) but the other retains the old keys, reconnection fails silently because the LTKs no longer match. The symptom is an encryption setup failure after connection. Mobile platforms handle this differently: iOS prompts the user to re-pair, while Android often requires the user to manually "Forget" the device in Bluetooth settings.