BLE Pairing (SMP)
The Security Manager exchange that turns an open BLE connection into an encrypted, optionally authenticated one, and why its legacy half falls to an offline brute force in seconds.
Pairing is the Security Manager Protocol exchange that gives a BLE connection a key. It runs over L2CAP channel 0x0006, in the clear, before there is any encryption to hide it. Two things come out of it: a key good enough to encrypt this session, and, if the devices bond, a set of long-lived keys stored on both sides for next time.
What it is
Pairing has three phases.
Phase 1, feature exchange. Pairing Request and Pairing Response, seven bytes each, carrying the IO capability, whether out-of-band data exists, the authentication requirements (bonding, MITM protection, Secure Connections), the maximum key size and which keys each side will distribute. Those two PDUs decide everything that follows, and both are visible to anyone listening.
Phase 2, key agreement. This is where the two generations diverge.
LE legacy pairing agrees a Temporary Key, then uses it to protect a random exchange:
| Model | TK |
|---|---|
| Just Works | 0 |
| Passkey Entry | a 6-digit number, 0 to 999999 |
| Out of band | 128 bits from another channel |
Each side sends a Pairing Confirm, computed with the c1 function over its own random value, both Pairing Request and Pairing Response, and both addresses; then a Pairing Random, revealing the value the confirm committed to. The Short Term Key is s1(TK, Srand, Mrand), and the link is encrypted with it.
LE Secure Connections, from Bluetooth 4.2, replaces that with an ECDH key agreement on P-256. The public keys go over the air, the shared secret never does, and a listener who recorded the entire exchange still cannot derive the key.
Phase 3, key distribution. Over the now-encrypted link, each side sends the keys it promised: Encryption Information (the LTK), Master Identification (EDIV and Rand), Identity Information (the IRK), Identity Address Information and Signing Information. Under LESC the LTK is not distributed, because both ends already computed it.
Why it matters
Legacy pairing is breakable offline, and the arithmetic is not close. The TK carries at most about 20 bits of entropy, and every input to the confirm calculation except the TK is on the air. So you try each candidate TK, compute what the confirm would have been, and stop when it matches the one you captured. Just Works, where the TK is zero, is one try.
crackle is the tool that does exactly this, and once it has the TK it derives the STK, then the session key, and decrypts the rest of the connection:
crackle -i legacy_pairing.pcap -o decrypted.pcap
# TK found: 000000
# Decrypted 89 packets
# LTK found: bd7181759291ac5fdb5475aa9d6395e3
It needs the whole handshake: both Pairing Request and Pairing Response, both confirms, both randoms, and LL_ENC_REQ with LL_ENC_RSP. Miss the pairing and it says so and stops, which is the correct answer for a bonded reconnect where no pairing happened on camera.
LESC closes that door against a passive listener, but it fixes only what it fixes. Just Works under LESC still has no MITM protection, because there is nothing for a user to compare. A device that still accepts legacy when offered can be pushed back to it. And none of this touches an attribute the firmware never marked as requiring encryption: a writable control characteristic left open is reachable by anyone who connects, with or without pairing.
How to work with it
# The whole SMP exchange, decoded, including the IO capabilities that chose the model
tshark -r cap.pcap -Y btsmp
# On a Linux host, watch it live with the association model spelled out
btmon
The field to read first is the IO capability in the Pairing Request. NoInputNoOutput (0x03) on either side forces Just Works whatever the authentication requirements claim, and that single byte tells you the strength of everything downstream.
Pitfalls
- A confirm is not a MITM defence on its own. It commits each side to its random value so neither can choose theirs after seeing the other's. Against a passive listener with a 20-bit TK it buys nothing.
- Encrypted does not mean authenticated. Just Works produces a properly encrypted link with no idea who is on the far end. Both are useful; only one of them is what the marketing copy means.
- Key distribution is above encryption, not below it. An air sniff shows the LTK exchange as ciphertext; an HCI snoop on the host shows it in the clear. Same event, two completely different outcomes for you.
- Bonded reconnects have no pairing at all.
LL_ENC_REQwith a non-zero EDIV and Rand means the key was agreed in some session you did not capture. No pairing cracker applies. - Byte order, again. The confirm, the randoms and the pairing PDUs are little-endian on the wire and most significant octet first in the
c1ands1formulas.