Bonding: What It Is, Process and Security of BLE Pairing

What Is Bonding in BLE?

Bonding is an extension of the pairing process in Bluetooth Low Energy, where devices store encryption keys for subsequent connections. The BLE standard defines three security modes: Security Mode 1 (encryption without authentication), Security Mode 2 (data signing without encryption), and Security Mode 3 (encryption with authentication). Bonding is relevant for modes with encryption where repeated connections without re-keying are required.

Why Bonding Is Needed

The main purpose of bonding is automatic restoration of encrypted connections when devices reconnect. When a user takes earbuds out of their case and puts them on, bonding ensures instant connection to the smartphone without needing to select the device from the Bluetooth menu again. According to the Apple Bluetooth Design Guidelines (2025), bonded devices should connect within no more than 2 seconds from discovery.

What Data Is Stored During Bonding

During bonding, each device stores a set of cryptographic materials: Long Term Key (LTK) for connection encryption, Identity Resolving Key (IRK) for resolving random addresses, and Connection Signature Resolving Key (CSRK) for verifying data signatures. The LTK is the primary 128-bit key generated during pairing and used for all subsequent encrypted sessions.

Bonding vs Pairing: What’s the Difference

Pairing is the temporary negotiation of keys for encrypting the current communication session. When the connection ends, the encryption keys are deleted, and the next connection requires a full pairing process again. Bonding includes all pairing stages but additionally stores the keys for future sessions. Virtually all consumer Bluetooth devices (headphones, speakers, watches) use bonding because without it, each connection would require PIN re-entry.

Three Phases of Pairing and Bonding

The pairing process per the BLE specification consists of three phases. Phase 1 — exchange of device capabilities (IO capabilities, authentication support). Phase 2 — generation and exchange of Short Term Key (STK) or LTK, depending on the pairing method. Phase 3 — key transport: exchange of LTK, IRK, CSRK between devices. If the devices stored the keys after Phase 3 — this is bonding. If not — it is simply pairing.

How the Bonding Process Works

The bonding process is initiated after successful pairing completion, when one device sends a request to store keys. In BLE, the Central (typically a smartphone) and Peripheral (wearable device) exchange keys through the secure channel established in Phase 2. After successful key exchange, each device stores them in non-volatile memory along with the MAC address or Identity Address of the partner.

Key Storage on the Central Side

On the Central side (iOS/Android), keys are stored in the system Bluetooth storage. iOS uses the Core Bluetooth system stack with automatic bonding management: upon first pairing, keys are saved in the device’s NVRAM, and subsequent connections to the same Peripheral happen automatically. The developer does not manage keys directly — the Core Bluetooth system stack handles bonding automatically when connecting to a device that supports key storage.

Connection Restoration via Bonding

Upon reconnection, the Peripheral sends advertising packets containing either its public address or a Resolvable Private Address (RPA). The Central receives the packet, matches the address against stored bonded devices, and if a match is found, initiates session restoration using the stored LTK. If the LTK matches, the encrypted connection is established without re-pairing.

Authentication Methods for Bonding

The BLE specification defines several authentication methods that affect the security level of bonding. The choice of method depends on the IO capabilities of the devices — whether they have a display, keyboard, or the ability to confirm numeric comparison. Secure bonding requires using at least Just Works for non-critical applications and Numeric Comparison or Passkey Entry for tasks requiring protection against Man-in-the-Middle attacks.

Just Works

Just Works is an authentication-free method used when one of the devices has no display or keyboard. Encryption keys are transmitted without verifying the second device’s identity — temperature sensors, heart rate monitors. Just Works is vulnerable to MITM attacks and is therefore only used for devices where data compromise poses no threat.

Numeric Comparison

Numeric Comparison is an authentication method where both devices display a six-digit number, and the user must confirm the match. This method provides protection against MITM attacks and is recommended for devices with a display — smart watches, fitness trackers, remote controls. After confirmation, bonding is stored with the maximum trust level.

Passkey Entry

Passkey Entry requires entering a six-digit PIN on one of the devices. Typically, the code is generated by one device and displayed on it, while the user enters it on the second device. This method is used for medical devices and IoT locks where a high level of security is required but one of the devices lacks a display for Numeric Comparison.

Managing Bonded Devices in iOS and Android

Bonding management is the process of viewing, deleting, and maintaining stored keys of paired devices. In mobile development, it is important to correctly handle bonded device states, especially when a peripheral device is reset or its firmware is replaced. When bonding keys on the Peripheral change, the old keys on the Central must be removed and a fresh pairing performed.

Managing in iOS

iOS automatically manages bonded devices through the system Core Bluetooth stack. The developer does not have a direct API for viewing or deleting individual bonded devices — management is done through system settings (Settings > Bluetooth > device > Forget). If bonding needs to be cleared programmatically, the app can direct the user to the system Bluetooth settings using UIApplication.openSettingsURLString.

Managing in Android

Android provides a direct API for working with bonded devices through the BluetoothAdapter class. The getBondedDevices() method returns a Set<BluetoothDevice> of all paired devices. To remove bonding, the removeBond() method is used via reflection or, on Android 12+, the official API BluetoothDevice.removeBond().

val adapter = BluetoothAdapter.getDefaultAdapter()
val bondedDevices: Set<BluetoothDevice> = adapter.getBondedDevices()
bondedDevices.forEach { device ->
    Log.d("Bonding", "Bonded device: ${device.name}, ${device.address}")
}

Practical Code Example of Bonding Implementation

Bonding implementation on Android requires correct handling of the BroadcastReceiver for BluetoothDevice.ACTION_BOND_STATE_CHANGED events. On the first connection to a device, the Android system automatically initiates bonding if the device supports this capability. The developer must handle three states: BOND_NONE (not paired), BOND_BONDING (pairing in progress), BOND_BONDED (paired).

val bondReceiver = object : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val device = intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE)
        val bondState = intent.getIntExtra(BluetoothDevice.EXTRA_BOND_STATE, -1)
        when (bondState) {
            BluetoothDevice.BOND_BONDED -> Log.d("Bonding", "Bonded: ${device.name}")
            BluetoothDevice.BOND_NONE -> Log.d("Bonding", "Bond removed")
        }
    }
}

Initiating Bonding on Android

To initiate bonding on Android, the createBond() method must be called on the BluetoothDevice object. The method returns a boolean — true if the pairing process started successfully. Starting with Android 12, createBond() requires the BLUETOOTH_CONNECT permission and may be rejected by the system if the app does not have background Bluetooth access.

fun initiateBonding(device: BluetoothDevice) {
    if (device.bondState == BluetoothDevice.BOND_NONE) {
        val success = device.createBond()
        if (success) {
            Toast.makeText(context, "Bonding initiated", Toast.LENGTH_SHORT)
        }
    }
}

Common Bonding Mistakes

Mobile app developers often encounter common mistakes when working with BLE device bonding. Incorrect handling of bonding states can lead to connection failures, inability to re-pair, or data loss. Let’s examine the most frequent issues and their solutions.

Firmware Reset of Peripheral and Stale Bonding

After a BLE device firmware update, its bonding keys may be reset, but the smartphone continues to store the outdated keys (stale bonding). When attempting to connect, the Central tries to restore the session with the old LTK, the Peripheral rejects the key, and the connection fails. The solution is to remove the bonding on the smartphone via Settings > Bluetooth > Forget Device and perform a fresh pairing.

Bonded Device Count Limit

BLE chips have a limit on the number of stored bonding records. For popular Nordic nRF5x chips, the limit is 8-20 records depending on configuration. When the limit is exceeded, the device stops accepting new pairings. The solution is to remove unused bonding records or use a priority-based key ring with cleanup.

Privacy Feature Issues

When using the Privacy Feature (random MAC addresses), the device periodically changes its address. If the Central did not store the IRK, it cannot match the new random address to a known device. The solution is to properly implement IRK storage and use it to resolve RPA on every device discovery.