BLE Pairing Security: Encryption Doesn’t Tell You Who You’re Talking To
"The link is encrypted" answers the smaller question. The bigger one: encrypted with whom? The four BLE pairing methods compared, what each assumes about trust, what legacy pairing gives away, and the mistakes we find in wireless assessments.
Bluetooth Low Energy devices almost always end their security story the same way: "the link is encrypted." That is usually true, and it answers the smaller of the two questions a radio link raises. The bigger one: encrypted with whom? Pairing is the moment your device decides who deserves its encryption keys, and it is the moment we attack first in every wireless assessment, because it is where products decide trust with the least scrutiny.
This note compares the BLE pairing methods, shows what each one assumes, and lists the mistakes we keep finding in products that pair "securely".
The pairing methods, honestly compared
BLE offers four association models. The differences matter less in theory than in what each one asks of your user and your hardware, click through the matrix and note the MITM column.
Just Works is the default of convenience: no interaction, no authentication, no protection against an attacker present at pairing time. Passkey adds a six-digit secret, useful only when the number genuinely travels out of band (display on one device, typed on the other) and catastrophic when it is printed in the manual. Numeric Comparison, under LE Secure Connections, has both sides display a value the user compares. MITM-resistant because an attacker in the middle cannot make both displays match. Out-of-Band takes the pairing data over a second channel (NFC, QR, cable) and is the strongest, if that channel deserves the trust.
Legacy pairing vs. LE Secure Connections
The single most consequential detail in BLE security is which pairing generation the product uses. Legacy pairing (pre-Bluetooth 4.2) derives the link key from the TK, a 6-digit temporary key with about 20 bits of entropy. A passive capture of the pairing exchange plus an offline brute-force yields the link key, and with it every session it protected. LE Secure Connections (ECDH) closes exactly this hole: the key agreement is an elliptic-curve exchange, and passive recording no longer breaks it. Products shipping legacy pairing in 2026 are not rare. We find them by capturing one pairing; it takes minutes.
What encryption doesn't protect
Even a perfectly paired, ECDH-encrypted link leaves work undone:
- Identity. Encryption establishes a shared key, not a verified identity. A device that accepts pairing from anyone still trusts anyone, the encryption just makes the impostor's traffic private.
- Replay. Encrypted commands can still be recorded and retransmitted. Replay protection is a protocol design decision, sequence numbers, counters, nonces, independent of the cipher.
- Authorization. After pairing, many products treat the peer as trusted forever. A lost phone, a bench-captured sensor, a reflashed gadget, all still paired. Bonding lifetimes and re-authentication for privileged operations are where the real access control lives.
- Key storage. The LTK ends up stored on both ends. Where the device stores it, readable flash versus a secure element, decides whether physical access reopens the radio channel. See Secure Element vs. Secure Storage.
Mistakes we find in product assessments
Recurring findings, in rough order of frequency: Just Works pairing for a product that then accepts privileged commands; the same passkey printed in the documentation for the entire product line; legacy pairing still enabled for "compatibility", downgrading every connection an old handset touches; bonding that never expires and never re-authenticates; debug services left enumerated in production firmware that re-enter pairing mode on request; and session keys that survive reboots, so one capture of flash memory un encrypts months of recorded traffic.
Testing your own pairing flow
You do not need a laboratory to pressure-test the trust decision. Pair with the device while recording the exchange, does anything force legacy pairing? Pair from a second, unauthorized phone while the legitimate one is out of range, what is the device willing to negotiate? Replay a captured privileged command after re-pairing, does the protocol notice? Unpair, then re-pair with a modified advertised identity, does anything bind the identity to the encryption? Each of these has closed real products; each takes under an hour to try. If your pairing story survives all four, it is probably honest. If nobody at your company can answer how the device decides whom to trust, that is the finding.