BLERP: BLE Re-Pairing Attacks and Defenses

BLERP: BLE Re-Pairing Attacks and Defenses

Speakers: Tommaso Sacchetti

Conference: NDSS Symposium 2026

YouTube: https://www.youtube.com/watch?v=q7n2Kn0Rdo8

Overview

Bluetooth Low Energy (BLE) pairing security has been extensively studied, but every prior attack assumed the devices were pairing for the first time. This talk reveals that re-pairing -- when two previously bonded devices establish a new pairing key -- is fundamentally insecure. The researchers discovered six vulnerabilities (four new) in the BLE specification itself, affecting all compliant devices, and developed four attacks that enable unauthenticated central and peripheral impersonation, security level downgrade, and man-in-the-middle interception.

Testing against 22 real-world devices -- including Apple, Android, and open-source BLE stacks -- found that all devices were vulnerable to at least two vulnerabilities. The attacks are zero-click or one-click depending on the target device's input/output capabilities. Notably, Apple and the Apache NimBLE open-source stack had implementation-specific bugs that allowed re-pairing to be triggered in even more scenarios. NimBLE assigned CVE with CVSS 8.8. The researchers also designed and formally verified two fixes using ProVerif, but acknowledge that a complete solution requires the Bluetooth SIG to redesign the security protocol.

Background

▶ Watch: BLE basics: central/peripheral roles, pairing and session protocols (0:00)

Bluetooth Low Energy (BLE) is the most widely deployed short-range wireless communication technology, used by billions of devices including smartphones, laptops, smartwatches, and IoT devices. BLE defines two connection roles: the central (connection manager that initiates scans and procedures) and the peripheral (which advertises its presence and responds to central-initiated procedures).

BLE security relies on two key protocols. Pairing establishes a long-term key (the pairing key) that serves as the root of trust between devices. During pairing, devices negotiate a security level (including choice of elliptic curve Diffie-Hellman versus legacy crypto, and authentication) and key entropy (the effective length of the pairing key, which can be reduced by zeroing bytes). Session establishment occurs between already-paired devices at each reconnection, using a challenge-response protocol to derive a session encryption key from the existing pairing key.

Prior attacks on BLE pairing include the KNOB attack (forcing low entropy negotiation to enable brute-force), Invalid Curve (hijacking ECDH to derive a zero secret), Method Confusion and NINO (bypassing optional authentication), and CRACKLE (downgrading to legacy insecure protocol). All of these attacks target the initial pairing -- they assume the devices are connecting for the first time. Since pairing is supposed to happen once, this seemed reasonable.

However, the BLE specification allows devices to re-pair and overwrite an existing pairing key. The only prior mention of re-pairing in the literature was the BLUR paper, which worked at the intersection of BLE and Bluetooth Classic. No one had systematically examined whether re-pairing itself introduces vulnerabilities.

Key Findings

▶ Watch: The overlooked attack vector: re-pairing and overwriting existing bonds (4:00)

The researchers discovered six protocol-level vulnerabilities in BLE re-pairing:

1. Unauthenticated Central Re-pairing: A peripheral will accept a new pairing from an impersonating central without any authentication. The peripheral does not verify that the central holds the existing pairing key before overwriting the bond. The new pairing can use a lower security level than the original.

2. Unauthenticated Peripheral Re-pairing: More complex to exploit because centrals always initiate procedures. The attacker first rejects the central's encryption request with a random error (e.g., claiming no crypto support), then immediately sends a security request that triggers the central to initiate re-pairing. The central does not check whether re-pairing was triggered after a crypto failure.

3. Security Level Downgrade (Central): The security level negotiated during re-pairing can be lower than the original pairing, enabling removal of authentication or downgrade to legacy crypto.

4. Security Level Downgrade (Peripheral): The peripheral can request a high security level in the security request to trigger re-pairing, then downgrade the actual negotiated level during the pairing procedure itself. This two-step downgrade is permitted by the specification.

5. Re-pairing After Encryption Failure: An extension of prior work -- the ability to reject encryption and remain connected was known, but combining it with triggering a new pairing was not.

6. Entropy Downgrade During Re-pairing: The KNOB attack applies to re-pairing -- key entropy is not enforced between pairings, allowing an attacker to reduce entropy, brute-force the key, and gain control over an existing connection at any time.

Technical Deep Dive

▶ Watch: Peripheral impersonation with security level downgrade trick (8:00)

The central impersonation attack is straightforward: since peripherals are always listening for connections, an attacker impersonating a trusted central simply initiates a new pairing. The peripheral accepts without authenticating the central's knowledge of the existing pairing key and allows the bond to be overwritten. The security level for the new pairing can be set independently of the original pairing's security level.

The peripheral impersonation attack requires more sophistication. Upon reconnection, the legitimate central sends an encryption request to establish a session. The attacking peripheral rejects this with a random error code (e.g., "encryption not supported"), then immediately sends a security request with a high security level value. This triggers the central to initiate re-pairing. During the re-pairing negotiation, the attacker then downgrades the security level below what was specified in the security request. The specification permits this because the security request only sets a minimum threshold that the central uses to decide whether to re-pair, but the actual pairing negotiation is independent.

These attacks combine into a man-in-the-middle configuration. Two variants exist: a single-channel MITM where the attacker sits in the middle only during feature negotiation, weakening security while letting devices derive the same key; and a double-channel MITM where the attacker maintains two separate connections and actively relays/modifies traffic.

The formal verification of proposed fixes used ProVerif to prove that key chaining (requiring knowledge of the old key to derive the new one) combined with transcript hashing (embedding the full negotiation transcript in the derived key) prevents both unauthenticated re-pairing and single-channel MITM attacks.

Demo / Proof of Concept

▶ Watch: Results: all 22 devices vulnerable, Apple and NimBLE worst affected (10:00)

The attacks were evaluated against 22 commercial and open-source BLE devices, covering the most common Bluetooth versions and all security settings. Results:

• All 22 devices were vulnerable to at least two vulnerabilities
• Apple devices had implementation-specific issues allowing re-pairing to be triggered in all cases (fix in progress)
• Apache NimBLE (open-source stack) had similar implementation bugs -- assigned CVE with CVSS ~8.8
• Android had a bug where rejecting the encryption request twice caused it to delete the pairing key from memory, effectively destroying the bond and forcing the user to re-pair
• Zephyr (open-source BLE stack) was the only implementation that blocked security level downgrade during re-pairing, though it still allowed unauthenticated re-pairing

All attacks are zero-click or one-click depending on the device's I/O capabilities. The BLERP toolkit is open-source and available for testing.

Defensive Implications

▶ Watch: Q&A: formal methods and practical path forward for the Bluetooth SIG (14:00)

The researchers propose two levels of fixes:

Immediate mitigation (backward-compatible): Enforce that the security level during re-pairing must be equal to or higher than the original pairing. Disconnect on encryption errors rather than allowing fallback to re-pairing. This is implementable by vendors without specification changes and significantly reduces the attack surface.

Specification-level fix: Authenticate re-pairing using key chaining -- the new pairing key must be derived using the old pairing key, proving that both devices held the previous root of trust. Additionally, transcript hashing embeds the negotiation transcript into the key derivation, providing integrity protection against MITM attacks during the negotiation phase. The researchers note that without transcript hashing, single-channel MITM remains possible even with key chaining.

The fundamental message to vendors is that BLE threat models must be updated to include re-pairing as an attack vector. Every prior security analysis assumed pairing happens once, but the specification explicitly allows re-pairing, and attackers can trigger it at any time against any bonded device pair. Vendors should implement the backward-compatible hardening immediately while the Bluetooth SIG works on a protocol redesign.

Key Takeaways

• BLE re-pairing is fundamentally insecure: devices accept new pairings without authenticating the existing bond, and security levels can be downgraded
• Six protocol-level vulnerabilities found, four new -- all affect the BLE specification itself, not just specific implementations
• All 22 tested devices (Apple, Android, NimBLE, Zephyr, others) vulnerable to at least two attacks
• Attacks are zero-click or one-click and can be combined into full man-in-the-middle
• The KNOB entropy attack applies to re-pairing, meaning any bonded connection can be attacked at any time
• Apple working on fixes; NimBLE assigned CVE with CVSS 8.8; Android had a bond deletion bug
• Backward-compatible fix: enforce security level consistency and disconnect on crypto errors
• Full fix requires key chaining plus transcript hashing, verified with ProVerif

About the Speaker(s)

Tommaso Sacchetti conducted this research under the supervision of Daniele Antonioli, who is known for foundational BLE security research. The team has expertise in Bluetooth protocol analysis, formal verification of security protocols using ProVerif, and practical wireless attack tooling. Their BLERP toolkit is open-source, continuing a tradition of releasing practical tools alongside protocol vulnerability research.