BLERP: Bluetooth Low Energy Re-Pairing Attack😡🛜👿

Source: Dev.to

Introduction

In this post we’ll discuss BLERP – the Bluetooth Low Energy Re‑pairing attack.
We’ll cover what the attack is, how it can be exploited, and possible mitigations.

What is Bluetooth Low Energy Re‑pairing?

During a BLE session the devices generate a secret key (often called the pairing key or PK) that is used to encrypt and authenticate their communication.

When the devices need to reconnect after a disconnection, they typically generate a new key (PK_NEW) for the new session.
The problem is that the old key (PK_OLD) is not used to verify the identity of the peer during the re‑pairing process. This lack of continuity opens the door for several attacks.

Attack Scenarios

Peripheral Impersonation

An attacker can present itself as the legitimate peripheral, causing the central device to connect to the wrong device.

Central Impersonation

Conversely, an attacker can masquerade as the central device, tricking the peripheral into establishing a connection.

Man‑in‑the‑Middle (MitM)

By forcing a re‑pairing, the attacker can insert itself between the two legitimate devices and intercept or modify traffic.

Double MitM

The attacker impersonates both sides simultaneously, creating two separate encrypted channels while controlling the communication flow.

How the Attacks Work

• No authentication during the re‑pairing phase.
• Security downgrade: the new session may use weaker parameters.
• Weak keys: predictable or insufficiently random keys can be guessed.
• Forced re‑pairing: an attacker can trigger a reconnection after a session‑establishment error, causing the devices to generate a new key without verifying the old one.

Mitigation Strategies

1. Bind the new key to the old key – require knowledge of PK_OLD to accept a new pairing.
2. Avoid immediate re‑pairing after a connection failure; introduce a delay or additional verification step.
3. Enforce security level consistency – the security requirements for the new session must be at least as strong as those of the original pairing.
4. Display warnings when suspicious re‑pairing activity is detected.
5. Use cryptographic hashes to provide integrity verification of the exchanged data.
6. Integrate these fixes into the BLE specification – although legacy devices may remain vulnerable if they cannot be updated.

Example Code

printf("Hello world!");

---

That’s a concise overview of the Bluetooth Low Energy Re‑pairing attack (BLERP) and some practical countermeasures.