BLE Pairing and Bonding: How It Works and Where It Can Go Wrong

BLE pairing is the process by which two devices establish a shared secret that enables encrypted communication. Bonding is the persistence of that secret - storing the keys so the devices don't need to pair again on reconnection. Both processes have multiple implementation options, and the security properties vary dramatically between them.

Understanding BLE pairing is necessary for anyone working with BLE security - whether you're assessing IoT device implementations, testing the BLEShark Nano's Bad-BT feature, or trying to understand why some BLE devices are trivially vulnerable to interception while others aren't.

Why Pairing Exists

BLE operates in the 2.4GHz band and anyone nearby with a BLE receiver can capture advertising packets and, if they connect to a peripheral, read its unprotected GATT characteristics. For many applications - a heart rate monitor broadcasting data, a BLE beacon - this is fine. The data isn't sensitive.

sequenceDiagram
    participant I as Initiator (Central)
    participant R as Responder (Peripheral)

    Note over I,R: Phase 1 - Feature Exchange
    I->>R: Pairing Request
    Note right of R: IO capabilities, auth req,
key size, bonding flags
    R->>I: Pairing Response
    Note left of I: IO capabilities, auth req,
key size, bonding flags

    Note over I,R: Phase 2 - Authentication (Just Works example)
    I->>I: Generate random TK = 0
    R->>R: Generate random TK = 0
    I->>R: Pairing Confirm (hash of TK + random)
    R->>I: Pairing Confirm
    I->>R: Pairing Random (reveal random value)
    R->>I: Pairing Random
    Note over I,R: Both verify confirms match

    Note over I,R: Phase 2 - Key Generation
    I->>R: Encrypted with STK
    Note over I,R: Generate LTK, IRK, CSRK

    Note over I,R: Phase 3 - Key Distribution (Bonding)
    I->>R: LTK (Long Term Key)
    I->>R: IRK (Identity Resolving Key)
    R->>I: LTK
    R->>I: IRK
    Note over I,R: Keys stored in flash for reconnection

BLE pairing phases - feature exchange, authentication with key generation, and key distribution for bonding (persistent reconnection)

For applications involving sensitive data or command execution (locks, medical devices, payment-adjacent systems, keyboards), you need encryption and authentication. Pairing establishes the keys for this. After pairing, the BLE connection can be encrypted, and characteristics can require a bonded, authenticated relationship before allowing read/write access.

LE Legacy Pairing vs LE Secure Connections

There are two generations of BLE pairing:

LE Legacy Pairing (BLE 4.0/4.1): Uses ECDH-like key exchange based on a temporary key (TK). The TK is the source of security - it's either 0 (Just Works), a 6-digit number (Passkey), or an out-of-band value. The resulting STK (Short Term Key) and LTK (Long Term Key) are derived from the TK. If the TK is weak or known, the entire pairing can be attacked.

LE Secure Connections (LESC) (BLE 4.2+): Uses ECDH (Elliptic Curve Diffie-Hellman) with P-256 curve for the key exchange. The shared secret is derived from the ECDH exchange and doesn't depend on a weak TK. Even if an attacker captures the pairing exchange, they can't recover the LTK through offline brute force (the ECDH problem is hard). LESC is significantly more secure than Legacy Pairing.

Most modern BLE 5.0 devices support LESC. The BLEShark Nano's ESP32-C3 with BLE 5.0 supports both, but will use LESC when connecting to a device that also supports it.

The Three Pairing Association Methods

Both Legacy Pairing and Secure Connections use one of three association methods to authenticate the key exchange. The available methods depend on the I/O capabilities of each device.

Just Works

Just Works is the default when at least one device has no display and no keyboard. The TK is 0 in Legacy Pairing - meaning the short-term key derivation uses a known value, and anyone who captures the pairing exchange can derive all subsequent session keys.

In LE Secure Connections, Just Works uses the ECDH exchange, which is cryptographically stronger. However, it still provides no MITM protection. An active attacker who can intercept the ECDH exchange can perform a man-in-the-middle attack - establishing separate sessions with each device and relaying traffic while able to read and modify it.

Just Works is unavoidable for many IoT devices - a BLE temperature sensor has no display and no keyboard. You can't enter a passkey. But for any device handling sensitive data or commands, Just Works pairing should be recognized as providing only eavesdropping protection, not MITM protection.

Passkey Entry

Passkey Entry uses a 6-digit numeric PIN. In one variant, the PIN is displayed on one device and entered on the other. In another, both devices generate and display the same random PIN (Numeric Comparison in LESC) and the user confirms they match.

The security comes from the PIN proving that both devices are communicating with the correct counterpart. A MITM attacker who intercepts the connection can't produce the correct PIN without having access to the display/keyboard of the real device.

With Legacy Pairing, the TK is the 6-digit passkey, and an offline attack against a captured pairing exchange with a 6-digit passkey (1,000,000 possible values) is feasible but not immediate. LESC Passkey Entry is substantially stronger - the passkey authenticates the ECDH exchange, and offline attacks aren't practical.

Passkey Entry requires at least one device to have a display and the other to have a keyboard (or at least numeric input). A smartphone to a keyboard pairing uses Passkey Entry - your phone displays the 6-digit code, you type it on the keyboard.

Out-of-Band (OOB)

Out-of-Band uses an external channel - not BLE - to exchange authentication data. NFC is the most common OOB mechanism. You tap two devices together, NFC transfers the pairing data, and BLE pairing completes with MITM protection (because the NFC exchange requires physical proximity and isn't interceptable by a remote BLE attacker).

OOB provides strong MITM protection because the authentication channel is separate from the attack channel. OOB is used in some medical devices and high-security IoT applications. It's less common in consumer devices simply because NFC adds hardware cost.

MITM Resistance Summary

The key property for security assessment:

Bonding: Persisting the Keys

Bonding means storing the LTK (Long Term Key) and other keying material after pairing, so devices can reconnect without repeating the full pairing process. On reconnection, the peripheral sends its bonded identity (via the Identity Address or IRK - Identity Resolving Key), the central finds the matching LTK in its bonding database, and both derive the session key without a new pairing exchange.

Bonding significantly improves usability - you pair once, and subsequent connections are automatic and encrypted. But it also means:

• The LTK is stored persistently on both devices. If one device is compromised, the attacker gets the LTK and can decrypt previously captured sessions (if they have them).
• A device with many bonded relationships stores many LTKs. On some platforms, the bonding database has a size limit - bonding too many new devices can cause old entries to be evicted.
• Removing a bonding on one side doesn't automatically remove it from the other. A device that was told to forget you may still have your LTK. Reconnecting to it works - from that device's perspective, you're still bonded.

Bad-BT and the Pairing Flow

The BLEShark Nano's Bad-BT feature works through a normal BLE pairing flow. The device advertises as a Bluetooth HID keyboard. When a target device (phone, computer, tablet) is nearby, the user initiates pairing on the target. The pairing uses whatever association method the target device supports.

For a computer that shows a passkey display, the user may see a 6-digit code and enter it on the "keyboard" (the BLEShark). The BLEShark's firmware handles this as part of the pairing process. Once paired, the OS treats the BLEShark as a trusted keyboard and accepts keystrokes.

The pairing step is intentional and visible - it requires user action on the target device. This is different from a silent or automatic connection. Bad-BT is a post-pairing HID injection tool, not a pairing exploit. The pairing step is the consent mechanism built into BLE - it requires someone to physically accept the pairing on the target device.

This is one of the key differences between Bad-BT and a physical USB HID attack: USB HID doesn't require pairing. Just plug in a USB device and it works immediately. BLE HID requires the pairing step, which means the target user sees a pairing request and must accept it. In a social engineering scenario, an attacker might convince a user to pair with a "USB keyboard charger" or "wireless keyboard" without realizing what it is. In an authorized security test, the security professional pairs it themselves.

graph TD
    subgraph "BLE Pairing Methods (by IO Capabilities)"
        IO["IO Capability
Exchange"] --> DECIDE{"What can
devices do?"}

        DECIDE -->|"No input, no output"| JW["Just Works
No MITM protection
TK = 0"]
        DECIDE -->|"Display + Keyboard"| NC["Numeric Comparison
(BLE 4.2+ / LE Secure)
Confirm 6-digit code"]
        DECIDE -->|"Display only + Keyboard"| PE["Passkey Entry
Enter 6-digit code
shown on other device"]
        DECIDE -->|"NFC available"| OOB["Out of Band
NFC tap to share TK
Strong MITM protection"]

        JW --> VULN1["Vulnerable to
eavesdropping"]
        JW --> VULN2["Vulnerable to
MITM attack"]

        NC --> SAFE1["MITM protected
(user confirms match)"]
        PE --> SAFE2["MITM protected
(shared secret)"]
        OOB --> SAFE3["Strongest protection
(separate channel)"]
    end

    subgraph "Bonding vs No Bonding"
        BOND_YES["Bonding Enabled"] --> STORE["Store LTK + IRK
in flash memory"]
        STORE --> RECONNECT["Fast reconnection
without re-pairing"]
        STORE --> PRIVACY["IRK enables
address resolution"]

        BOND_NO["No Bonding"] --> TEMP["Temporary encryption
session only"]
        TEMP --> REPAIR["Must re-pair
every connection"]
    end

BLE pairing methods determined by device IO capabilities, ranging from insecure Just Works to strong Out of Band, plus bonding for persistent connections

The "Just Works" Vulnerability in IoT Context

For most IoT security research, the most relevant finding is devices using Just Works pairing for critical functionality.

A BLE lock that uses Just Works pairing is vulnerable to MITM attack: an attacker can position themselves between the phone app and the lock, establish separate authenticated sessions with each side, and both sides think they're talking to the legitimate counterpart. The attacker relays commands and can modify them.

Finding this vulnerability requires a BLE MITM tool (GATTacker, BtleJuice) and physical proximity. But the root cause is visible in the GATT service enumeration: if the lock doesn't require LE Secure Connections and uses Just Works, the vulnerability is present by design.

For the BLEShark BLE scanning workflow: after capturing a device's advertising data and identifying it as security-relevant, the next assessment step is connecting (with authorization) and checking what pairing methods and security modes the device supports. nRF Connect will show you whether the device requires Secure Connections and what association method it uses. This tells you the theoretical attack surface before you've done any active testing.

Get BLEShark Nano - $36.99+

BLE pairing security assessment should only be conducted on devices you own or have explicit authorization to test. Intercepting or manipulating BLE communications without authorization may violate applicable laws.