BLE Security: Pairing, Bonding, and Encryption

BLE Security

Security in Bluetooth Low Energy is enforced by the Security Manager Protocol (SMP), which negotiates authentication, key generation, and encryption. Choosing the wrong pairing method leaves user data exposed; choosing an overly strict method breaks usability. This guide walks through every pairing method, explains bonding, and shows how LE Secure Connections closes the classic MITM gap.

Pairing Methods

Pairing establishes a temporary encrypted session. The Security Manager selects one of four association models based on the I/O capabilities each device advertises:

Just Works is the fallback when neither device can display or enter a PIN. It provides encryption but zero authentication — a man-in-the-middle can intercept the key exchange undetected. Use it only for non-sensitive data like beacons or HID keyboards without displays.

Passkey Entry shows a 6-digit number on one device (or both) and requires the user to type it on the other. The passkey is committed into the key derivation, making MITM attacks computationally infeasible.

Numeric Comparison (available with LE Secure Connections only) displays the same 6-digit number on both devices and asks the user to confirm they match. It is the most user-friendly MITM-resistant method for devices with screens.

Bonding

Bonding extends pairing by persisting the keys so reconnection is instant and silent. After a successful pairing, both devices exchange their Long-Term Key (LTK), IRK (Identity Resolving Key), and optionally CSRK (Connection Signature Resolving Key). These keys are stored in non-volatile memory.

On reconnect, the peripheral advertises with its resolvable private address (RPA), which only bonded centrals can decode using the stored IRK. This makes passive tracking by third parties impossible — a feature called LE Privacy.

Key storage best practices:

• Encrypt LTK storage with a device-level key (e.g., hardware secure enclave or TrustZone)
• Implement a maximum bond list size with LRU eviction
• Expose a "forget device" flow so users can clear bonds

LE Secure Connections

LE Secure Connections (LESC, introduced in Bluetooth 4.2) replaces the legacy key exchange with Elliptic Curve Diffie-Hellman (ECDH) on the P-256 curve. This closes the fundamental weakness in Legacy Pairing, where a passive eavesdropper who captured the pairing exchange could brute-force the TK (Temporary Key) offline.

With LESC, both devices generate a public/private key pair and perform a ECDH handshake. The shared secret is never transmitted — only public keys cross the air. Even full capture of every pairing packet does not reveal the LTK.

MITM Protection in Practice

Enabling LESC alone is not sufficient for MITM protection — you must also require an authenticated pairing method. A common mistake is advertising high security capabilities but accepting Just Works fallback when the peer claims no I/O capability.

Implement these defenses:

1. Reject Just Works when authentication matters. Set the minimum security level requirement on your ATT">GATT characteristics (e.g., BT_SECURITY_HIGH in Zephyr).
2. Validate OOB data integrity. When using OOB Pairing, transmit a hash of the public key over the out-of-band channel (NFC, QR) so tampering is detectable.
3. Log pairing failures. Repeated pairing failures from a single address can indicate a probe attack; implement rate limiting.
4. Use LE Privacy. Always rotate the resolvable private address to prevent correlating advertising packets across time.