Introduction
Last week Daniele Antonioli posted an interesting paper and tooling (two nRF52840 boards, custom NimBLE btshell + Scapy-based Python Host for the double-channel MitM), he did with Tommaso Sacchetti on BLE Re-pairing attacks which probably deserves more attention than it got.
This work was presented after 1.5 year of research at Network and Distributed System Security (NDSS) Symposium 2026, and could actually answer some people’s questions → How secure is the re-pairing process in BLE? And here the two researchers looked at an interesting surface.
Indeed, they discovered 6 flaws including 4 novel ones that allow to do:
- Peripheral Impersonation (PI): The attacker spoofs a trusted peripheral (e.g., a keyboard), rejects the encryption request, then sends a crafted security request to trick the Central into re-pairing. This is the first attack to exploit pairing from session establishment.
- Central Impersonation (CI): The attacker spoofs a trusted Central and sends an unauthenticated pairing request → the Peripheral always accepts.
- Single-channel MitM: The attacker relays and tampers with re-pairing messages between victims, compromising the key offline.
- Double-channel MitM: The attacker runs PI against one victim and CI against the other, establishing separate keys with each.
These attacks are 0-click against devices without I/O (keyboards, mice) and 1-click (a simple Yes/No dialog) against smartphones and laptops.
source: BLERP: BLE Re-Pairing Attacks and Defenses | Daniele Antonioli
Let’s now talk about these different attacks.
Attack 1: Peripheral Impersonation (PI)
Source: Paper BLERP: BLE Re-Pairing Attacks and Defenses, from Tommaso Sacchetti
(EURECOM) and Daniele Antonioli (EURECOM)
Alice (Central, e.g., a laptop) is paired with Bob (Peripheral, e.g., a keyboard). Charlie takes Bob’s place by spoofing his MAC address, name, and device type via advertisements. When Alice auto-reconnects and initiates session establishment by sending an ENC_REQ, Charlie doesn’t have the shared PK so he can’t complete it. Instead, he replies with a REJECT_IND carrying an error code like “Unsupported Remote Feature.” This aborts session establishment (V5).
Charlie immediately sends an SMP_SEC_REQ with a crafted security level (ARSR) designed to be higher than the stored ARPK. The standard’s decision tree (Listing 1 in the paper) says the Central must compare ARSR against ARPK. if higher, it initiates re-pairing. Charlie can easily craft this value without knowing the actual PK, for instance by setting the reserved-for-future-use bits high, or promising an upgrade from LSC to SC.
Alice, following the standard faithfully, interprets this as a legitimate re-pairing request from Bob and sends a SMP_PAIR_REQ. Charlie responds with a SMP_PAIR_RSP where he can downgrade the security level (V3, V4), the standard never requires the Central to check consistency between the security request and the subsequent pairing response. So Charlie can force JustWorks association, meaning no numeric comparison, no passkey, just a simple “Yes/No” dialog on devices with I/O, or nothing at all on devices without I/O.
Alice completes pairing with Charlie and overwrites her stored PK. Charlie now has full read/write access as if he were the legitimate keyboard. This is 0-click against IoT devices and 1-click (unauthenticated Yes/No) against smartphones and laptops.
A critical detail: none of the tested devices notify the user when encryption fails, even though the standard requires it. So the rejection + re-pairing sequence happens silently.
Attack 2: Central Impersonation (CI)
Source: Paper BLERP: BLE Re-Pairing Attacks and Defenses, from Tommaso Sacchetti
(EURECOM) and Daniele Antonioli (EURECOM)
Bob (Peripheral) is waiting for connections. Charlie spoofs Alice’s MAC address and sends a connection request, then immediately sends an unauthenticated SMP_PAIR_REQ with a crafted security level.
The fundamental problem here is V2: Peripherals have no mechanism at all to authenticate re-pairing requests from Centrals. The standard only defines how Centrals should process security requests from Peripherals (the decision tree in Listing 1), but says nothing about how Peripherals should validate incoming pairing requests against existing keys. Bob just accepts, regardless of whether the new security level is lower than the existing ARPK.
Charlie can again downgrade the security level via V4 to force JustWorks, making the attack silent against peripherals without I/O (which is most of them, mice, keyboards, IoT sensors, fitness trackers). Bob overwrites his PK with the new one shared with Charlie.
This is particularly dangerous because peripherals are typically “dumb” devices with no display and no way to alert the user. The paper showed it working against Logitech mice/keyboards, Xbox controllers, and Garmin smartwatches.
Attack 3: Single-Channel MitM
Source: Paper BLERP: BLE Re-Pairing Attacks and Defenses, from Tommaso Sacchetti
(EURECOM) and Daniele Antonioli (EURECOM)
This combines the PI attack with message relaying. Charlie positions himself between Alice and Bob, performs the PI attack against Alice to trigger re-pairing, then instead of completing pairing himself, he relays the pairing messages between Alice and Bob while tampering with them.
The key insight is that Charlie controls the feature negotiation phase. He can modify the pairing request/response to weaken security in several ways:
- Force LSC instead of SC, then recover the PK using known weaknesses in the legacy key exchange
- Reduce the entropy negotiation value (V6) and then brute-force the PK via the KNOB attack
- Downgrade the association method to JustWorks to eliminate authentication
Alice and Bob end up sharing a single PK that they derived together, so Charlie doesn’t have it directly. But because he’s compromised the derivation (weak crypto, low entropy), he can recover it offline afterwards. This is a more subtle attack, the victims do pair with each other, but under conditions the attacker controlled.
Attack 4: Double-Channel MitM
This is the full active MitM. Charlie runs PI against Alice and CI against Bob simultaneously, using two radio interfaces (two nRF52 boards in their toolkit). He establishes separate PKs with each victim: PKC₁ with Alice and PKC₂ with Bob.
After this, when Alice and Bob think they’re communicating with each other, Charlie sits in the middle: he decrypts traffic from Alice using PKC₁, reads/modifies it, then re-encrypts and forwards to Bob using PKC₂, and vice versa. This gives the attacker full real-time eavesdropping, injection, and modification capabilities.
The practical challenge here is the race condition, when the victims disconnect, Charlie needs to connect to the Peripheral before the legitimate Central does. The authors tested this and won the race 55% of the time without any optimization. With selective jamming of the legitimate Peripheral’s advertisements or aggressive advertising from the malicious Peripheral, this rate would increase significantly.
Results
22 devices tested across BT 4.2–5.4, including the most secure configurations (SC, SCO, authenticated pairing), and… → All vulnerable!:
Source: Paper BLERP: BLE Re-Pairing Attacks and Defenses, from Tommaso Sacchetti
(EURECOM) and Daniele Antonioli (EURECOM)
Implementation-specific bugs
Beyond the design flaws, they found that Apple triggers re-pairing on ARSR ≥ ARPK instead of strictly >, Android’s Fluoride stack deletes the PK after two failed encryption attempts (bypassing security checks entirely), and NimBLE’s bonding flag bypass.
Defense
Source: Paper BLERP: BLE Re-Pairing Attacks and Defenses, from Tommaso Sacchetti
(EURECOM) and Daniele Antonioli (EURECOM)
They propose two complementary fixes: hardened re-pairing (backward-compatible, stricter checks on security level consistency + mandatory disconnect on encryption failure, fixes V3–V6) and authenticated re-pairing (key chaining where new PK is derived from old PK + fresh ECDH, plus transcript hashing, verified with ProVerif, fixes everything but requires a standard update).
Hardened re-pairing alone doesn’t fix V1/V2 (the lack of authentication), so an attacker can still force a security upgrade and then attack the association phase
Resources
- Link to the paper: https://www.ndss-symposium.org/wp-content/uploads/2026-f121-paper.pdf
- The PoC called BLERP: GitHub - sacca97/blerp: BLERP: BLE Re-Pairing Attacks and Defenses