Assess BLE pairing and decrypt weak pairings

Mechanism

BLE confidentiality is decided entirely at pairing. Two regimes exist: LE Legacy pairing (4.0/4.1, still selectable on later devices) and LE Secure Connections (LESC, added in 4.2). They differ in how the key that protects the session is established, and that difference is the whole of this control.

In LE Legacy pairing the link is bootstrapped from a 128-bit Temporary Key (TK). For Just Works the TK is fixed at zero; for the 6-digit passkey method the TK is the passkey value, so at most 999999 — about 20 bits of entropy [ryan2013woot]. From the TK and the random/confirm values exchanged in the pairing packets, the Short Term Key and then the Long Term Key are derived. Because every input except the TK is sent in the clear, an observer who captured the pairing exchange can brute-force the TK offline, rederive the keys, and decrypt the whole session — the method Mike Ryan published with the crackle tool [ryan2013woot]. LESC replaces this with an Elliptic-Curve Diffie–Hellman (P-256) key agreement, so the session key is never derivable from the captured exchange; crackle and the LE-Legacy TK brute-force do not apply to it [ryan2013woot].

Two further weaknesses sit beside the legacy-vs-LESC split. The key-size negotiation is itself unprotected: the BLE feature/SMP exchange that sets the encryption key size is neither encrypted nor integrity-protected and permits a minimum of 7 bytes, so an attacker impersonating each peer can force both down to 7-byte entropy without violating the spec — the BLE form of the KNOB key-negotiation downgrade [antonioli2020knobble]. The KNOB family is tracked under CVE-2019-9506 [cve-2019-9506]; the NVD text is written against Bluetooth BR/EDR, while the BLE applicability — downgrading any BLE long-term and session key to 7-byte entropy — comes from the Antonioli et al. follow-up analysis [antonioli2020knobble], for which no separate CVE was assigned. And even where LESC is selected, the SoC’s Security Manager state machine can be flawed: SweynTooth Zero-LTK Installation installs an all-zero LTK when an out-of-order encryption request arrives during Secure Connections pairing on affected Telink SDKs, fully bypassing LESC [garbelini2020sweyntooth], tracked as CVE-2019-19194 [cve-2019-19194].

So the security-relevant questions this control answers are: did the link pair with LE Legacy or LESC; if Legacy, can the session be decrypted from a passive capture; and what key size was negotiated. The judgement on whether the device should have rejected legacy pairing, required interaction, or enforced a key-size floor belongs to BSAM (BSAM-PA-01 device pairing mode, BSAM-PA-04 rejection of legacy pairing, BSAM-EN-02 force use of encryption, BSAM-EN-03 minimum encryption key size); RFSAM supplies only the RF capture that reaches those checks.

Procedure

Authorised testing only: capture, decrypt and key-recovery steps must be run against your own equipment or test devices, with explicit written permission, ideally inside RF shielding so you do not touch third-party links.

1. Capture the pairing exchange. A session can only be cracked if its pairing packets were recorded. Drive a Sniffle-class sniffer to follow the target and trigger a fresh pairing (power-cycle / forget-and-re-pair on your test device) while capturing (RFSAM-RES-04):

   python3 -m sniffle.sniff_receiver -s <SERIAL> -e -l -o ble_pairing.pcap

   Sniffle follows connections by default (CONN_FOLLOW mode, unless -a/-A is given), so the connection-following that this capture relies on needs no extra flag; -e adds BT5 extended (auxiliary) advertising capture, -l enables the long-range (coded) PHY on the primary advertising channels, and -o writes the PCAP. Confirm the capture contains the SMP exchange — in Wireshark, filter btsmp and look for Pairing Request / Pairing Response.

2. Read the pairing mode straight from the capture. In the Pairing Request/Response, inspect the AuthReq flags and the SC (Secure Connections) bit:

   wireshark ble_pairing.pcap
   # filter: btsmp.opcode == 0x01 || btsmp.opcode == 0x02

   SC = 0 → LE Legacy (crackable below). SC = 1 → LE Secure Connections (ECDH; not crackable from the capture — record it and stop at step 5). Also read the Maximum Encryption Key Size field: a value of 7 is the KNOB-relevant floor [antonioli2020knobble]; 16 is full strength.

3. Confirm the association model. From the same packets read IO Capability and the MITM AuthReq bit. MITM = 0 with IO NoInputNoOutput is Just Works (TK = 0). MITM = 1 with a display/keyboard is passkey (TK = the 6-digit value). This tells crackle how hard the TK search is.

4. Crack the LE Legacy session (Legacy only). Feed the PCAP to crackle; it brute-forces the TK and, on success, derives the keys:

   crackle -i ble_pairing.pcap

   Expected output names the recovered TK/keys, e.g. TK found: 0 (Just Works) or a 6-digit value (passkey), followed by LTK found: <16 bytes>. If it prints Specify a pcap file with -i or reports it could not find a complete pairing, the capture is missing packets — re-capture a full exchange.

5. Decrypt the session and confirm. Use the recovered keys to produce a cleartext capture, then verify the decrypted GATT traffic is readable:

   crackle -i ble_pairing.pcap -o ble_decrypted.pcap

   Open ble_decrypted.pcap in Wireshark and confirm post-encryption ATT/GATT operations (e.g. Write Request, Handle Value Notification) are now in cleartext — that is the proof the link’s confidentiality was broken from a passive capture. Enumerating the now-readable GATT table is the hand-off to RFSAM-RES-05 and to the BSAM service-access checks. For LESC captures, record SC = 1 and the key size and defer the pairing-strength judgement to BSAM-PA/EN with no decryption claim.

Field case

A documented public example exercises exactly this control end to end. The crackle source tree ships a sample LE Legacy Just Works pairing capture (pairing_and_ltk_exchange.pcap) in its tests/01_crack/ fixture, and the project’s own recorded expected output shows the full crack [crackle-tests-01]. Run the same step this control specifies:

crackle -i ble_pairing.pcap

against that capture and crackle analyses connection 0 between the link endpoints 08:3e:8e:e1:0b:3e (public) and 78:c5:e5:6e:dd:e8 (public), reports Found 3 encrypted packets, brute-forces the TK in strategy 0, 20 bits of entropy, and prints TK found: 000000 — the Just-Works case — followed by LTK found: 7f62c053f104a5bbe68b1d896a2ed49c [crackle-tests-01]. Re-running with -o ble_decrypted.pcap decrypts the 3 encrypted packets (Done, processed 713 total packets, decrypted 3) and dumps a cleartext PCAP, confirming the session was decryptable from the passive capture alone. The same recovered key and the same address pair are independently documented in the project’s tests/02_ltk_decrypt/ fixture, which feeds the value back as -l 7f62c053f104a5bbe68b1d896a2ed49c to decrypt the session directly — confirming 7f62c053f104a5bbe68b1d896a2ed49c as the repository’s canonical shipped result [crackle-tests-01]. In your own engagement, the recovered LTK and the connecting device addresses will instead be those of the link you captured.

Remediation

• Developer (firmware / stack). Require LE Secure Connections and reject LE Legacy pairing for any link carrying sensitive data or control — LESC’s ECDH defeats the captured-pairing TK brute-force entirely [ryan2013woot]. Enforce a minimum encryption key size of 16 bytes and refuse a negotiated maximum below that, closing the BLE KNOB downgrade [antonioli2020knobble]. Keep the SoC’s SMP/Security-Manager up to date and verify it against the SweynTooth class — in particular that it checks pairing state before honouring an encryption request, so a zero LTK can never be installed [garbelini2020sweyntooth].
• Integrator. Select SoCs/modules whose vendor has patched the SweynTooth Zero-LTK and related SMP flaws [cve-2019-19194], and disable Just-Works association on devices that have any input/output capability so authenticated pairing (passkey/OOB, with MITM protection) is used. Treat key size and pairing mode as procurement requirements, not defaults.
• Operator. Pair sensitive devices once, in a controlled (low-RF-exposure) environment, since the offline crack needs the pairing exchange to have been captured; avoid repeated re-pairing in public. Where the platform allows, prefer devices that advertise LESC support and reject downgrades, and monitor for unexpected re-pairing prompts that could indicate a forced re-pair to harvest a fresh exchange.