Crackle: Breaking BLE Encryption by Exploiting Legacy Pairing's 20-Bit Keyspace

Hook

The 128-bit encryption key protecting millions of Bluetooth Low Energy devices can be cracked in milliseconds because it's actually chosen from a pool of just 1,000,000 possibilities.

Context

When Bluetooth Low Energy arrived in 2010 with Bluetooth 4.0, it promised secure, low-power wireless communication for everything from fitness trackers to door locks. The specification included encryption to protect data in transit, but it also included a fatal compromise: to support devices without displays or keyboards, BLE offered "Just Works" pairing that required zero user interaction. The problem? Just Works pairing, along with 6-digit PIN pairing, uses a Temporary Key (TK) that's supposed to be 128 bits but is actually constrained to values between 0 and 999,999—a mere 20 bits of entropy.

Mike Ryan created crackle to demonstrate just how catastrophic this design flaw is. If you can capture the initial pairing handshake between two BLE devices using Legacy pairing, you can brute-force the TK in under a second on modern hardware, derive all subsequent encryption keys, and decrypt every encrypted packet in the session. This isn't a theoretical attack or a sophisticated cryptanalytic breakthrough—it's a straightforward brute-force attack made possible by a keyspace smaller than the population of Rhode Island. The tool has become essential for security researchers auditing BLE devices, and its existence has pushed the industry toward Bluetooth 4.2's Secure Connections pairing, which uses ECDH key exchange with actual cryptographic strength.

Technical Insight

Crackle operates on PCAP or PcapNG files containing captured BLE traffic, typically obtained using Ubertooth or other BLE sniffing hardware. The tool's architecture revolves around reconstructing the BLE pairing process and exploiting the key derivation chain that flows from the weak TK.

The BLE Legacy pairing process works like this: two devices exchange pairing requests and responses, then exchange "confirm" values (computed as AES-128 encryption of a random value XORed with the TK), followed by the random values themselves. Once both sides verify the confirm values match, they derive the Short Term Key (STK) using the s1 function with inputs TK, Srand (slave random), and Mrand (master random). The STK encrypts the connection, and optionally a Long Term Key (LTK) is distributed for future reconnections.

Crackle implements two cracking strategies. The "fast" method works when you have complete pairing data including both confirm and random values. Here's the core logic: for each candidate TK from 0 to 999,999, crackle computes what the confirm value should be and compares it to the captured confirm value. When it finds a match, it's found the correct TK:

// Simplified representation of the fast cracking method
for (uint32_t tk_candidate = 0; tk_candidate <= 999999; tk_candidate++) {
    uint8_t tk[16] = {0};
    // TK is stored as little-endian 32-bit value in 128-bit array
    tk[0] = tk_candidate & 0xff;
    tk[1] = (tk_candidate >> 8) & 0xff;
    tk[2] = (tk_candidate >> 16) & 0xff;
    
    // Compute expected confirm: e(TK, r XOR preq || pres)
    uint8_t p[16];
    memcpy(p, pairing_req, 7);
    memcpy(p + 7, pairing_res, 7);
    p[14] = 0; p[15] = 0;
    
    for (int i = 0; i < 16; i++)
        p[i] ^= random_value[i];
    
    uint8_t calculated_confirm[16];
    aes_encrypt(tk, p, calculated_confirm);
    
    if (memcmp(calculated_confirm, captured_confirm, 16) == 0) {
        // Found the TK!
        derive_stk(tk, srand, mrand, &stk);
        return SUCCESS;
    }
}

The "slow" method works when confirm values are missing but you have the encrypted session data. It brute-forces TK candidates, derives the STK for each, and attempts to decrypt captured packets. If decrypted packets have valid L2CAP headers or recognizable patterns, that TK is likely correct. This method is significantly slower but still completes in seconds.

Once crackle recovers the TK, it walks through the complete key derivation chain. The STK is derived using the s1 cryptographic function (defined in the Bluetooth spec) with the TK and both random values. If the capture includes the LL_ENC_REQ and LL_ENC_RSP packets that distribute the LTK, crackle decrypts those using the STK to recover the LTK. This is crucial because the LTK is what devices use for reconnections—crack one pairing session, and you can decrypt all future sessions between those devices until they re-pair.

The decryption process itself is elegant. BLE encryption uses AES-128-CCM (Counter with CBC-MAC), an authenticated encryption mode. Crackle implements the counter mode decryption, walking through encrypted packets and applying the keystream generated from the session key and packet counter. The tool outputs a new PCAP file with decrypted packets, preserving the original unencrypted packets as-is.

One clever implementation detail: crackle automatically detects which cracking strategy to use based on available packets in the capture. It searches for the critical pairing packets (opcodes 0x01, 0x02, 0x03, 0x04, 0x05 for pairing request/response/confirm/random), and if it finds the full set, it uses the fast method. If pairing data is incomplete but encrypted packets exist, it falls back to the slow method. This automatic mode selection makes the tool easy to use—just point it at a capture file and let it work.

The tool's simplicity is also its strength. It's around 2,000 lines of C with minimal dependencies, compiling to a single binary. The code is straightforward to audit, and the cryptographic implementations (AES, key derivation functions) closely follow the Bluetooth specification, making it a useful reference for understanding BLE security mechanics.

Gotcha

Crackle's effectiveness has a hard cutoff: it works exclusively against Legacy pairing and fails completely against Secure Connections. When Bluetooth 4.2 introduced Secure Connections pairing in 2014, it replaced the weak TK with ECDH (Elliptic Curve Diffie-Hellman) key exchange, providing genuine 128-bit security. If a device uses Secure Connections—and most modern implementations do—crackle cannot crack it, period. There's no fallback, no slower method, no workaround. This means crackle is increasingly targeting legacy devices, though plenty of those still exist in the wild, especially in low-cost IoT devices that haven't been updated.

The tool is also entirely dependent on capture quality. You need a complete or near-complete pairing handshake. Missing the pairing request, pairing response, or the confirm/random exchanges renders the fast method useless. Missing the LL_ENC_REQ/RSP packets means you won't recover the LTK (though you can still decrypt the current session with the STK). Bluetooth operates at 2.4GHz with frequency hopping, making reliable packet capture challenging without specialized hardware like Ubertooth. Even with proper hardware, interference, distance, or timing issues can cause critical packets to be lost. A final quirk: crackle doesn't recalculate CRCs for decrypted packets, so the output PCAP will have incorrect checksums. This usually doesn't matter for analysis in Wireshark, but it means you can't retransmit or use the decrypted packets for certain testing scenarios without manual CRC fixing.

Verdict

Use if you're conducting security assessments of BLE devices and need to demonstrate the weakness of Legacy pairing, reverse-engineering IoT devices that use Just Works or PIN pairing, or recovering encryption keys from captured pairing sessions for forensic analysis. Crackle excels at its narrow purpose: proving that Legacy BLE pairing is fundamentally broken and extracting keys to decrypt traffic. Skip if you're targeting devices that implement Secure Connections (check by attempting to crack—if it fails instantly, they're using modern pairing), you can't reliably capture the initial pairing handshake (no pairing = no cracking), or you need a general-purpose BLE development tool rather than a security exploitation tool. For everyday BLE debugging with known keys, Wireshark's built-in BLE decryption is more appropriate. For attacking modern BLE implementations, you'll need different techniques entirely—crackle is purpose-built for exploiting one specific, though still prevalent, cryptographic failure.