August 11, 2026 · How-To

BLE Pairing and Bonding: Security Explained

By Dzulfikar Ats Tsauri, founder of Voltrus / JoyoDigitama. He builds the protocol tools covered in these posts. Updated October 28, 2026.

BLE ships encrypted by default, sort of. The link layer can run with no encryption at all (Security Mode 1 Level 1), with unauthenticated encryption (Level 2), with authenticated encryption (Level 3), or with authenticated encryption plus a 128-bit ECDH-protected key exchange (Level 4). What gets your connection from Level 1 to Level 4 is the pairing process, and the most common cause of the device will not reconnect is a broken bond.

This guide covers the difference between pairing and bonding, the LE Legacy vs LE Secure Connections key exchanges, the four association models, the STK vs LTK key hierarchy, AES-CCM encryption, the random-private-address privacy model, security mode levels, and how to debug authentication failures from macOS.

If you want to pair first and understand the GATT tree your encrypted connection unlocks, our guide to GATT services and characteristics picks up exactly where this one leaves off. For connectionless BLE broadcasts that bypass pairing entirely, see BLE advertising packets, including iBeacon and Eddystone.

Why Pairing Exists

Without pairing, BLE traffic is sent in the clear on the link layer. Anyone with a sniffer and a compatible capture adapter can read every GATT transaction. They can also inject their own packets if they are willing to be active. The threat model BLE assumes is therefore:

• Passive eavesdropper: an attacker who listens but does not transmit.
• Active man-in-the-middle (MITM): an attacker who relays, modifies, or injects packets between the two legitimate devices.
• Tracking: an attacker who follows a device across space by observing its stable MAC address.

Pairing addresses the first two threats by establishing an encryption key. The Random Private Address (RPA) mechanism addresses the third.

Pairing vs Bonding

The two words get used interchangeably but they are distinct:

• Pairing is the in-session exchange where two devices negotiate an encryption key and turn on encryption for the current connection. After the central and peripheral complete pairing, the link is encrypted for the rest of that connection.
• Bonding is pairing plus persistent storage. Both devices save the long-term key (LTK) and associated identity information (IRK, identity address) to non-volatile memory. On reconnect, they skip the pairing exchange and re-encrypt directly from the stored keys.

A paired-but-not-bonded connection drops back to plaintext every time it disconnects. Many peripherals will not even let you re-pair without first deleting the bond on the central side, which is a frequent source of won't-reconnect bugs.

The Phases of LE Pairing

LE pairing runs in the Security Manager Protocol (SMP) in three phases:

1. Pairing Feature Exchange: the central and peripheral exchange their capabilities in a Pairing Request and Pairing Response: IO capabilities (display, keyboard, none), whether they support LE Secure Connections, whether they have an out-of-band key available, the bonding and MITM requirements, and the maximum encryption key size (7 to 16 bytes).
2. Authentication and Key Generation: based on the association model selected from the IO capabilities (Just Works, Numeric Comparison, Passkey Entry, Out of Band), the two devices perform a key exchange and produce a short-term key (LE Legacy) or a long-term key directly (LE Secure Connections).
3. Transport Specific Key Distribution: over the now-encrypted link the devices distribute the keys they need to bond, such as the LTK (Legacy only), the IRK and the identity address.

LE Legacy vs LE Secure Connections

The most consequential design choice in BLE security happened in version 4.2: the introduction of LE Secure Connections (LESC) alongside the original LE Legacy Pairing.

LE Legacy Pairing produces a temporary key (TK) through one of three mechanisms: Just Works (TK = 0), a 6-digit Passkey (TK derived from the 20-bit passkey), or Out of Band (TK delivered via NFC, QR code, etc.). Both devices then derive a short-term key (STK) from the TK and a random number exchange, and use the STK to encrypt the link. The fatal problem: the TK is short (0 bits for Just Works, 20 bits for the passkey). A passive attacker who records the pairing exchange can brute-force the TK offline and decrypt the entire session. For Just Works, no brute forcing is even needed; TK = 0 is known.

LE Secure Connections (LESC) replaces the symmetric TK exchange with an Elliptic Curve Diffie-Hellman (ECDH) key agreement on the P-256 curve. Each side generates an ephemeral key pair, exchanges public keys, computes the shared secret DHKey, and uses it (with commitments F5, F6) to derive the LTK directly. A passive attacker observing the exchange cannot recover DHKey without solving the elliptic-curve discrete logarithm problem, which is intractable on current hardware.

LESC is optional in the Bluetooth Core Specification, but a device can enforce it with Secure Connections Only mode, and it is strongly recommended wherever both devices support it. The remaining risk in LESC is an active MITM during pairing, which the association models below are designed to defeat.

Association Models

The association model is how the two devices verify each other's identity during pairing and detect an active MITM.

Just Works

Just Works performs no MITM protection. The two devices exchange public keys (in LESC) or TK = 0 (in Legacy) and proceed. There is no user interaction. Use it only when the threat model excludes active attackers (for example, a peripheral that has no display or keyboard and is being paired in a physically private setting). Just Works is secure against passive eavesdropping under LESC, but it provides zero protection against an active relay.

Numeric Comparison

Numeric Comparison is LESC-only (BLE 4.2+). Both devices compute a 6-digit confirmation value from the ECDH exchange and display it. The user confirms yes on both devices if the numbers match. A MITM cannot make both displays match without breaking the underlying ECDH commitment, so a matching number is strong evidence that no MITM is present. This is the recommended association model for devices with a display and a yes/no button.

Passkey Entry

A 6-digit passkey is shown on one device and entered on the other. Under LE Legacy the passkey is used directly as the TK, so a passive attacker who records the exchange can brute-force it offline. Under LESC, the 20-bit passkey is committed one bit at a time over 20 rounds, mixed with the ECDH public keys, which stops an active attacker from learning more than one bit of the passkey per attempt. Use Passkey Entry when one device has a display and the other has a keyboard (for example, a phone and a peripheral with a keypad).

Out of Band (OOB)

The TK or LESC confirmation data is delivered over a separate channel: typically NFC or a QR code scanned between the two devices. OOB inherits the MITM protection of the out-of-band channel, so it is only as strong as that channel. It is the strongest association model when both devices support it and the channel is trustworthy.

Key Hierarchy: STK vs LTK

Under LE Legacy Pairing:

• TK (Temporary Key): 128-bit, but low-entropy (0 bits for Just Works, 20 bits for passkey). Ephemeral.
• STK (Short-Term Key): 128-bit, derived from TK and a random number exchange. Used to encrypt the link for the current connection.
• LTK (Long-Term Key): 128-bit, generated by the peripheral and distributed to the central over the encrypted link. Stored by both for re-encryption on reconnect.

Under LE Secure Connections:

• LTK: 128-bit, derived directly from the ECDH shared secret (DHKey). No STK or TK intermediate. Stored by both for re-encryption on reconnect.

The LTK is what makes bonding possible. Lose the LTK and you must re-pair.

Encryption (AES-CCM)

Once the LTK (or STK) is in place, both sides encrypt the link using AES-CCM with a 128-bit session key derived from the LTK and a session key diversifier exchanged at encryption start; the IV is built from the same exchange. Each link-layer packet carries a 4-byte MIC (Message Integrity Check), which authenticates both the packet's integrity and its origin.

Replay protection comes from a 39-bit packet counter on the master and a 39-bit counter on the slave. The MIC fails if the counter is out of sequence, so an attacker cannot replay a previously captured packet without invalidating the MIC.

Privacy: Random Private Addresses and IRK

A BLE device that always advertises its public MAC address is trivially trackable across space. The BLE privacy feature replaces the public address with a Random Private Address (RPA) that changes on a schedule (default every 15 minutes).

There are two flavors:

• Non-resolvable private address: random, changes frequently, no way to link back to the public identity. The peer just sees a new address every time.
• Resolvable private address (RPA): derived from a 128-bit Identity Resolving Key (IRK) and a 24-bit random number, using the ah cryptographic function (AES-based). A scanner that knows the IRK can verify that the RPA belongs to the same device, but an observer who does not know the IRK cannot link two RPAs to the same device.

The IRK is exchanged during pairing and stored as part of the bond. A bonded central can resolve the peripheral's RPAs transparently and reconnect without the user noticing the address change.

Authentication vs Authorization

These two terms are easy to confuse:

• Authentication verifies who the peer is. In BLE, this happens at pairing time (the key exchange and the association model together authenticate the peer). A link counts as authenticated only when pairing used an MITM-protected model (Security Mode 1 Level 3 or 4); Just Works pairing is unauthenticated.
• Authorization decides what an authenticated peer is allowed to do. It is a decision made by the peripheral's application, not by the pairing procedure, and the specification does not define how it is made.

A characteristic that requires authentication is refused with ATT error 0x05 (Insufficient Authentication) until the link has been paired with an MITM-protected model. A characteristic that requires authorization is refused with ATT error 0x08 (Insufficient Authorization) until the peripheral's application allows the access. Encryption alone is a third requirement, reported as 0x0F (Insufficient Encryption).

Security Mode 1, Levels 1 to 4

BLE defines Security Mode 1 with four levels:

• Level 1 (No security): no authentication, no encryption. Open access.
• Level 2 (Unauthenticated pairing with encryption): pairing without MITM (Just Works), link encrypted with the LTK.
• Level 3 (Authenticated pairing with encryption): pairing with MITM protection (Numeric Comparison, Passkey, or OOB), link encrypted.
• Level 4 (Authenticated LE Secure Connections pairing with encryption): LESC with MITM protection and a 128-bit (16-byte) encryption key, link encrypted with the ECDH-derived LTK.

Each GATT operation declares its required security level. The peripheral returns an ATT error (Insufficient Authentication, 0x05) if the link does not meet the requirement. To see where these requirements live in the data model, see our GATT services and characteristics guide.

Debugging Auth Failures on macOS

Most BLE auth issues fall into a small set of cases:

• Wrong PIN / wrong passkey: entered incorrectly or not entered on the other side. The pairing fails with the SMP reason Passkey Entry Failed (0x01), or Confirm Value Failed (0x04) when the commitment check does not match. Retry the pairing.
• Missing bond after factory reset: one device's bond was cleared (factory reset, settings toggle, app uninstall). The other device still holds the LTK and waits for an encrypted packet that never arrives. Delete the bond on both sides and re-pair. On macOS, remove the device from System Settings > Bluetooth; on iOS, Settings > Bluetooth > the (i) > Forget This Device.
• Association model or requirement mismatch: the model is chosen from the IO capabilities and AuthReq flags of both sides, so a display-less peripheral ends up with Just Works. If one side requires MITM protection and the result is Just Works, that side can abort with Authentication Requirements (0x03). Align the IO capabilities and security requirements on both sides.
• SMP timeout (30 seconds): the Security Manager has a 30-second timer. If a side does not answer an SMP PDU in time, the procedure is considered failed and no further SMP commands are sent on that connection; a new pairing attempt needs a new connection. Look for a peripheral that is too slow to respond, often because the application is busy on another task.
• Key size mismatch: the central supports a 16-byte key, the peripheral only 7 bytes. The negotiated size is the minimum, and a device that requires a larger size rejects the pairing with Encryption Key Size (0x06). Align the key size on both sides.
• IRK / RPA mismatch: the peripheral uses an RPA that the central cannot resolve because the IRK stored in the bond is stale (after a re-flash, for example), so the central does not recognize the device as the bonded one. Delete and re-bond.

macOS apps use CoreBluetooth, which does not expose SMP traffic or SMP reason codes; an app only sees the resulting ATT or CoreBluetooth error (for example insufficient authentication). To see the SMP exchange itself you need a BLE sniffer. A native macOS tool like MacTools BLE Inspector logs read, write and notification events with timestamps, which shows where an operation started failing. For more on the broader macOS BLE debugging workflow, see BLE Debugging on macOS.

LE Legacy vs LE Secure Connections

Further Reading

• BLE Debugging on macOS: nRF Connect vs BLE Inspector and Other Tools
• BLE GATT Services and Characteristics Explained: How Every BLE Device Is Structured
• BLE Advertising Packets Explained: AD Structures, iBeacon and Eddystone
• Industrial Protocol Comparison: Modbus, OPC UA, MQTT, S7, DNP3, EtherNet/IP and PROFINET