BLERP: BLE Re-Pairing Attacks and Defenses Paper Review
BLE Protocol Stack and Architecture Layer Analysis
The BLE protocol stack is broadly divided into the lower layer, the “Controller,” which controls physical wireless signals and real-time timing, and the upper layer, the “Host,” which handles high-level data processing and protocol multiplexing. These two layers communicate with each other through the Host Controller Interface (HCI).
Controller Layer Role
The Controller consists of the Physical Layer (PHY) and the Link Layer (LL). The Physical Layer uses the 2.4 GHz ISM band divided into 40 channels, each spaced 2 MHz apart, and converts digital data into wireless signals through Gaussian Frequency Shift Keying (GFSK).
The Link Layer controls the core state machine of BLE communication. It maintains a device in one of the following states: Standby, Advertising, Scanning, Initiating, or Connection. Communication begins in the “Advertising” state, where one device broadcasts packets through the three primary advertising channels, channels 37, 38, and 39. Another device “scans” and discovers this broadcast, then transitions to the “Initiating” state and sends a connection request, such as CONNECT_IND or AUX_CONNECT_REQ, thereby entering the “Connection” state. In addition, the Link Layer minimizes radio interference using Adaptive Frequency Hopping (AFH) and verifies packet integrity at the hardware level through Cyclic Redundancy Check (CRC).
Host Layer and Definition of Logical Roles
The Host layer multiplexes multiple protocols based on L2CAP (Logical Link Control and Adaptation Protocol) and performs packet Segmentation and Reassembly. Above L2CAP are ATT (Attribute Protocol) and GATT (Generic Attribute Profile), which handle data structuring and exchange, as well as GAP (Generic Access Profile), which defines device discovery and connection topology.
GAP defines four logical roles for devices based on the state of the Link Layer.
Broadcaster: A role that only transmits data without allowing connections.
Observer: A role that only receives data without initiating connections.
Peripheral: A role that performs advertising and accepts connections from other devices, generally power-constrained devices such as sensors and smartwatches.
Central: A leading role that performs scanning and initiates connections, generally resource-rich devices such as smartphones and laptops.
In the Connection topology, which is the main target of BLERP attacks, an asymmetric relationship between Central and Peripheral is always established. This role asymmetry directly affects the key distribution logic of the security protocol SMP.
In-Depth Analysis of the Security Manager Protocol (SMP) and Pairing Mechanism
The trust relationship between Bluetooth devices is established by the Security Manager Protocol (SMP), which is located in the Host layer. SMP communicates through L2CAP’s fixed channel, 0x0006, and controls the entire process of negotiating security parameters and generating and distributing encryption keys between two devices.
The commonly confused terms “Pairing” and “Bonding” are clearly different concepts. Pairing is an active procedure that negotiates and generates short-term keys to encrypt the current communication session. In contrast, bonding is a follow-up action that permanently stores the Long-Term Key (LTK) and various identity keys generated during pairing in the device’s non-volatile memory, the Security Database, so that future reconnections can establish an encrypted session immediately without repeating the complex pairing procedure.
The BLE pairing procedure is performed in the following three clearly defined phases according to the standard specification.
Phase 1: Pairing Feature Exchange
The first phase of pairing begins when the Central device sends an SMP_PAIR_REQ (Pairing Request) packet to the Peripheral device, and the Peripheral responds with an SMP_PAIR_RSP (Pairing Response) packet. If the Peripheral wants to prompt the Central to initiate pairing first, it can send an SMP_SEC_REQ (Security Request) packet instead of a pairing request, triggering the Central to send SMP_PAIR_REQ.
During this exchange, the devices mutually exchange their input/output (IO) capabilities, OOB (Out-of-Band) data support, maximum encryption key size, types of keys to be distributed, and the most important Authentication Requirements (AuthReq) flags.
AuthReq is an 8-bit, one-octet bit field that defines the security properties required by a device in great detail. BLERP attackers use Security Downgrade techniques by manipulating this very field to forcibly lower the security level. The meaning of each bit field is as follows.
| Bit position (LSB->MSB) |
Flag name |
Meaning |
| Bit 0-1 |
bonding (Bonding Flags) |
A 2-bit flag that determines whether the device will exchange a Long-Term Key (LTK) and store it in the Security Database for future use, that is, perform bonding. 00 means No Bonding, 01 means Bonding, and the remaining values are reserved for future use (RFU). |
| Bit 2 |
mitm (Man-in-the-Middle) |
A 1-bit flag that requires Man-in-the-Middle (MitM) protection. If this value is set to 1, the device must require a pairing model that involves user authentication, such as Passkey Entry or Numeric Comparison. If this flag is 0 or the device does not have appropriate input/output capabilities (IO Capability), the “Just Works” method is selected, in which keys are exchanged without any authentication, exposing the device to serious security threats. |
| Bit 3 |
sc (Secure Connections) |
Indicates support for LE Secure Connections (LESC), introduced in Bluetooth 4.2. Only when both devices set this bit to 1 does pairing proceed using the FIPS-compliant elliptic curve cryptography algorithm ECDH P-256. If either side sets it to 0, the process falls back to the weaker older encryption method, LE Legacy Pairing. |
| Bit 4 |
keypress |
A flag used only in the Passkey Entry model. It determines whether a Keypress Notification is sent one bit at a time whenever the user enters a password. This was introduced to prevent the entire passkey from being stolen at once. |
| Bit 5 |
ct2 |
A flag indicating support for the h7 hash function used for cryptographic key conversion between Bluetooth Classic and BLE during Cross-Transport Key Derivation (CTKD). |
| Bit 6-7 |
rfu (Reserved for Future Use) |
Currently unused in the standard and reserved for future feature expansion. |
Phase 2: Cryptographic Key Generation and Authentication (Key Generation Method Selection)
In Phase 2, the cryptographic key generation algorithm branches into two paths depending on the value of the sc flag negotiated in Phase 1.
-
LE Legacy Pairing (sc=0): This is the standard method used in older Bluetooth 4.0/4.1. A Temporary Key (TK) is generated according to the selected association model. For example, in Just Works, TK is fixed to 0. Then, the Central and Peripheral each generate and exchange random nonces, Mrand and Srand, and pass them together with TK into an AES-128 encryption function to derive a 128-bit Short Term Key (STK), expressed as STK = AES128(TK, Srand || Mrand). The critical weakness of legacy pairing is that when TK is simple, such as 0 or a six-digit PIN, an attacker who collects the nonces exposed over the air through passive eavesdropping can easily reverse-calculate the STK.
-
LE Secure Connections (LESC, sc=1): Introduced in Bluetooth 4.2 to overcome the weakness of STK, this method uses the FIPS-approved Elliptic Curve Diffie-Hellman (ECDH) P-256 curve. Both devices generate their own private key and public key, and only exchange public keys over the air. Each device then safely computes the same 256-bit Shared Secret (DHKey) by combining its own private key with the other party’s public key. In this process, AES-CMAC-based cryptographic hash functions f4, f5, and f6 are used for signature verification and authentication. The shared secret passes through the f5 function, a KDF, and is derived into the Long Term Key (LTK) used for final communication encryption and MacKey used to verify message integrity in the next step. As a result, in LESC, the LTK is never transmitted over the air, so even if an attacker eavesdrops on the entire public key exchange process, they cannot reverse-calculate the LTK without knowing the private key.
Phase 3: Transport Specific Key Distribution
Once the communication link is encrypted using the STK generated in Phase 2 for legacy pairing or the LTK generated in Phase 2 for LESC, Phase 3, key distribution, finally begins. According to the values set in the Initiator Key Distribution and Responder Key Distribution fields requested by both parties in Phase 1, several cryptographic keys and information essential for future sessions and identification are delivered to the other party through the securely encrypted channel.
The key elements exchanged and stored in this phase are as follows.
Long Term Key (LTK): In legacy pairing, the Peripheral independently generates a random 128-bit LTK and sends it to the Central. In LESC, it is not transmitted because it has already been mutually derived in Phase 2. After the pairing procedure ends, this LTK is used as a Root Key to derive encryption session keys when the devices reconnect in the future.
EDIV (Encrypted Diversifier) & Rand (Random Number): In legacy pairing, these are identifiers generated by the Peripheral together with the LTK and delivered to the Central. The 16-bit EDIV and 64-bit Rand values serve as indexes for identifying and looking up the exact LTK that matches the Central attempting the current connection among many LTKs stored in the Peripheral’s Security Database.
IRK (Identity Resolving Key): A 128-bit identity verification key. BLE devices use the Resolvable Private Address (RPA) mechanism, which periodically changes their MAC address to protect privacy and prevent location tracking. An RPA is generated by concatenating a random value, prand, with a hash value created by hashing it using the IRK, hash = AES128(IRK, prand). Only trusted devices that have received the IRK and stored it in their Security Database can reverse-check the hash of a received RPA and determine the device’s immutable Identity Address.
CSRK (Connection Signature Resolving Key): A 128-bit Data Signing key used to authenticate the source of data and prevent tampering, that is, ensure integrity, when transmitting data in plaintext without encrypting the communication link. When the sender attaches a cryptographic signature to the data using the CSRK, the receiver verifies it.
When Phase 3 is successfully completed, both devices permanently record the exchanged keys, such as LTK, IRK, and CSRK, in the Security Database, which is non-volatile storage implemented inside their Host stacks. This act is “Bonding,” and once bonding is completed, the devices can completely skip the heavy pairing operations, Phase 1 through Phase 3, in future connections.
Session Establishment and Logical Separation from Pairing
The most noteworthy point in the BLE protocol design is that the “Pairing (SMP)” process, which generates and exchanges the Long-Term Key (LTK), and the “Session Establishment (Link Layer)” process, in which already bonded devices reconnect and begin encrypted communication, are architecturally completely separated. This logical disconnect in the architecture becomes the main target of the BLERP attack discussed later.
When two bonded devices, Alice and Bob, physically reconnect, the session establishment procedure proceeds directly at the Controller’s Link Layer (LL) level without going through SMP.
Encryption Request (LL_ENC_REQ): The Central device sends an LL_ENC_REQ packet containing its random values, the Session Key Diversifier (SKD_C, 8 bytes), and Initialization Vector (IV_C, 4 bytes). In legacy connections, EDIV and Rand values are also included in plaintext in this packet so that the Peripheral can find the correct LTK in the database.
Encryption Response (LL_ENC_RSP): The Peripheral looks up the 128-bit LTK in the Security Database using the received EDIV and Rand. If it successfully finds the LTK, the Peripheral also replies to the Central with LL_ENC_RSP containing its random values, SKD_P (8 bytes) and IV_P (4 bytes).
Session Key (SK) Derivation: The two devices concatenate the exchanged SKD_C and SKD_P values to form the full 16-byte SKD. Then, using the stored Long-Term Key (LTK) as the master key, they input the SKD as plaintext into the AES-ECB encryption algorithm to derive a unique 128-bit Session Key (SK), expressed as SK = AES-ECB(LTK, SKD_C || SKD_P). In other words, the session key is generated completely anew for every connection by combining plaintext nonces exchanged in that connection, SKD, with the secret key stored inside the device, LTK.
Encryption Start Three-Way Handshake: Once the session key is ready, the Central sends LL_START_ENC_REQ in plaintext. The Peripheral initializes the AES-CCM algorithm by combining the newly generated Session Key (SK) with both parties’ IVs, and based on this, sends an LL_START_ENC_RSP packet that contains no payload but includes encryption and authentication (MIC) code. The Central replies with an encrypted LL_START_ENC_RSP in the same way, completing the handshake. All subsequent L2CAP and GATT data communication is strongly encrypted with AES-CCM using this Session Key (SK).
BLE Standard Re-Pairing Mechanism and Decision Tree Logic
The Bluetooth Core Specification v6.1, Vol 3, Part H, specifies a “Re-pairing” mechanism that allows two devices that have already completed bonding and share a Pairing Key/Long-Term Key (PK/LTK) to discard the existing key and overwrite it with a new key in order to negotiate a higher level of security. For example, this supports legitimate use cases where a device that was previously bonded using “Just Works” without authentication because it lacked a display gains OOB support through a firmware update and wants to update to a stronger security level.
The decision tree in the standard specification, Vol 3, Part H, Figure 2.7, defines the logic, shown in Listing 1 as pseudocode, for how the Central device should handle an SMP_SEC_REQ (Security Request) packet requesting re-pairing from the Peripheral.
If the two devices are already currently performing a pairing procedure, the duplicate security request is ignored (ignore_security_request).
If the two devices are already bonded and have a PK (LTK):
The Central compares the security level (AR_SR) in the AuthReq field included in the received SMP_SEC_REQ packet with the security level (AR_PK) of the existing key currently stored in the database.
If the requested security level is strictly higher than the existing level (AR_SR > AR_PK), the Central initiates the re-pairing procedure to overwrite the existing PK by sending SMP_PAIR_REQ (repair()).
If AR_SR <= AR_PK and the current connection session is already encrypted, the Central pauses the session through an encryption pause request such as LL_PAUSE_ENC_REQ and refreshes the session key (stop_session_and_restart()).
If AR_SR <= AR_PK but the current connection session is still unencrypted, the Central simply starts the session establishment procedure using the existing PK instead of pairing (session_establishment()).
If the device is not bonded, the normal initial pairing procedure is initiated (pair()).
This decision tree logic specifically describes only how the Central handles security requests from the Peripheral. However, it is severely underspecified regarding how the Peripheral should handle re-pairing requests from the Central, or what the exact comparison algorithm between AR_SR and AR_PK should be. This gap in the specification is the root cause of the BLERP vulnerability.
Analysis of BLERP (BLE Re-Pairing) Design Vulnerabilities (V1 ~ V6)
As a result of analyzing the logical flaws inherent in the standard design of BLE pairing, session establishment, and re-pairing logic discussed above, researchers identified a total of six serious design vulnerabilities. These are not implementation mistakes by a specific vendor but flaws in the Bluetooth v6.1 standard itself, and therefore broadly affect all compliant versions, from 4.2 to 5.4, as well as devices using the highest security settings, including LESC and SCO.
BLERP Attack Scenarios and Protocol Exploitation Mechanisms
Peripheral Impersonation (PI)
The PI attack is an attack in which the attacker Charlie disguises himself as Bob, a trusted Peripheral such as a smart keyboard, to Central Alice and deceives Alice into deleting the genuine LTK stored in her database and overwriting it with a fake PK shared with Charlie. This attack is especially notable as the first attack technique that regresses from the “Session Establishment” phase back to the “Pairing” state, and the abuse of the SMP_SEC_REQ message is particularly prominent.
MAC Address Spoofing and Connection: Charlie clones Bob’s MAC address and advertising data and broadcasts them. Alice attempts to connect to Bob but ends up establishing a physical connection with Charlie.
Blocking Session Establishment (Exploiting V5): Since Alice has an LTK from the previously bonded Bob, she sends LL_ENC_REQ, containing her diversifier SKD_A, to Charlie at the Link Layer for encrypted communication. Because Charlie does not have the LTK, he cannot send a valid LL_ENC_RSP. Therefore, he immediately injects an LL_REJECT_IND packet, including an error code such as command rejected, to forcibly stop the session establishment procedure. Alice’s stack does not disconnect and instead waits in plaintext communication state.
Injecting a Forged Security Request (Exploiting V1): Charlie immediately sends SMP_SEC_REQ to Alice to trigger re-pairing. To pass Alice’s decision tree logic, AR_SR > AR_PK, Charlie intentionally sets the AuthReq field (AR_SR) in the packet to a high value, for example by manipulating reserved bits or enabling the SC flag, before sending it. Alice accepts this without authentication and sends SMP_PAIR_REQ to begin re-pairing.
Security Level Downgrade and Key Overwrite (Exploiting V3 and V4): Charlie responds to Alice’s SMP_PAIR_REQ with SMP_PAIR_RSP, but this time sets both the mitm and sc flags in the actual AuthReq field to 0. Due to vulnerabilities V3 and V4, Alice’s system fails to verify this and ultimately downgrades the association model to the weakest “Just Works” method.
Objective Achieved: A new PK is derived between Charlie and Alice without an authentication procedure, and Alice overwrites it in the Security Database together with Bob’s identifier. Charlie now fully obtains Bob’s privileges and can inject arbitrary keyboard inputs into Alice or read plaintext data.
Central Impersonation (CI)
The CI attack is a method in which Charlie disguises himself as Alice, the trusted Central, and attacks Peripheral Bob. Peripheral devices are generally resource-constrained and have weak authentication logic, as described in V2, making this attack much more direct than PI.
Forged Connection Initiation: Charlie sends a connection request (CONNECT_IND) to Bob, who is scanning, while spoofing Alice’s MAC address.
Forcing Direct Re-Pairing (Exploiting V2 and V4): Without going through the session establishment phase, Charlie immediately sends SMP_PAIR_REQ to Bob containing AuthReq manipulated to mitm=0 and sc=0, Just Works. Bob’s standard stack has no ability to authenticate the received re-pairing request from the Central, and even though the request is lower than the existing security level (AR_PK), V4, it accepts it unconditionally.
Key Overwrite: Bob derives a new PK with Charlie using the Just Works method and deletes Alice’s existing LTK. Charlie now obtains Alice’s privileges and can extract sensitive health information from Bob, such as a smartwatch, or change its settings.
Single-Channel MitM
This attack is a technique in which Charlie physically intervenes between Alice and Bob, deceives both devices into believing they are communicating normally, and drastically lowers the strength of encryption in order to crack the key offline.
Charlie uses the PI attack technique to interrupt Alice’s session establishment and induce re-pairing.
Then, when Alice and Bob exchange pairing packets, SMP_PAIR_REQ and SMP_PAIR_RSP, Charlie relays them while subtly modifying only the contents of the packets. Specifically, by exploiting V6, Charlie reduces the “Maximum Encryption Key Size” negotiated by the two devices to only 7 bytes or forces the LSC, legacy pairing, method.
The two victims successfully complete pairing, PK generation, with weakened encryption strength without realizing Charlie’s intervention.
Charlie takes advantage of the fact that the negotiated key entropy is only 56 bits, 7 bytes, and applies a KNOB-like method based on previously collected nonce exchange packets to find the new PK in a short time through offline brute-force computation. All subsequent session traffic is decrypted in real time by Charlie.
Double-Channel MitM
Double-Channel MitM is the maximized form of the BLERP vulnerability, in which Charlie establishes independent PKs with each of the two victims and gains complete active traffic control. This attack is extremely critical because it can work even in the highest security modes, such as SCO (Secure Connections Only).
Charlie performs the PI attack against Alice, the Central, and the CI attack against Bob, the Peripheral, simultaneously in parallel. Unlike the single-channel attack, he does not relay packets. Instead, he completes entirely separate pairing procedures with each victim.
As a result, Alice’s Security Database stores PK_C1 shared with Charlie as Bob’s key, and Bob’s Security Database stores PK_C2 shared with Charlie as Alice’s key.
Afterward, all encrypted GATT traffic sent from Alice to Bob actually enters Charlie’s Link Layer. Charlie decrypts the traffic with PK_C1, reads and maliciously modifies the data, and then encrypts it again with PK_C2 before delivering it to Bob. Because both victims believe they have normally established sessions using their own LTKs, they do not notice any security warning or disconnection.
Impact in Real Environments and Manufacturer Implementation Flaws
The researchers built a low-cost open-source test environment based on nRF52, Mynewt, NimBLE, and a custom Python host using Scapy, and conducted a large-scale evaluation on 22 commercially available BLE devices. The test targets included recent smartphones, laptops, mice, and other devices from major vendors such as Google, Microsoft, Samsung, Qualcomm, Apple, and Logitech, covering Bluetooth versions from 4.2 to 5.4.
All 15 BLE host stacks and 12 controllers evaluated were proven vulnerable to BLERP attacks, and the attacks succeeded regardless of device hardware specifications, software versions, or security settings such as SC, SCO, or enabled MitM protection. As mentioned above, this is because the flaw is not a bug in the cryptographic algorithms themselves, such as AES-CCM or ECDH, but stems from a logical flaw in the State Machine Transition specified by the standard.
Furthermore, during the experiments, additional critical software flaws were discovered in BLE protocol stack implementations from Android, Apple, and Apache NimBLE that behaved even more vulnerably than the standard.
Apple stack: There was a bug that violated the standard logic AR_SR > AR_PK and allowed re-pairing even under the condition AR_SR >= AR_PK. As a result, even devices with the highest level of security, including MitM protection and SC, were forcibly exposed to re-pairing attacks.
Android (Fluoride stack): If the PI attacker rejects LL_ENC_REQ twice in a row using LL_REJECT_IND, the Android stack permanently deletes the stored LTK of the trusted Peripheral from the database for an unknown reason. Since the LTK is deleted, the comparison logic with AR_PK itself is neutralized, causing the attacker’s SMP_SEC_REQ to be approved unconditionally.
Apache NimBLE: A logical bug was confirmed in which, when SMP_SEC_REQ is received, if the bonding flag bit is not set, re-pairing is blindly initiated regardless of the security level. CVE-2025-62235 was assigned to this issue.
Countermeasures: Strengthening and Redesigning Protocol Logic
To eliminate the root cause of BLERP attacks, state verification must be strengthened between the Controller’s session establishment phase and the Host’s pairing negotiation phase. The paper presents two types of countermeasures: an immediately deployable backward-compatible defense and a cryptographic defense requiring fundamental revision of the Bluetooth standard.
Hardened Re-Pairing Logic
This is a heuristic defense technique that can achieve immediate mitigation through firmware updates while maintaining backward compatibility with existing Bluetooth devices. It strengthens the standard’s ambiguous comparison and verification algorithm into a strict three-step rule.
Immediate Disconnection on Encryption Failure (Defending against PI attacks / Mitigating V5): If the Controller receives an LL_REJECT_IND packet, encryption rejection, from the other party during session establishment or if the encryption procedure fails, it should not fall back to plaintext state and wait for SMP_SEC_REQ. Instead, it should generate an LL_TERMINATE_IND message and immediately terminate the Bluetooth physical connection. This fundamentally blocks entry into PI attacks through the V5 vulnerability.
Introducing Consistency Verification Logic (Mitigating V3): The Central’s SMP state machine caches the AR_SR value from the initial SMP_SEC_REQ sent by the Peripheral in memory. Later, when the re-pairing procedure begins and the Peripheral responds with an SMP_PAIR_RSP packet, the Central strictly verifies whether the actual AuthReq value in this packet matches the cached AR_SR. If they do not match and the security level has been downgraded, the connection is immediately terminated with an Authentication Requirements error.
Enforcing a Strong Lower Bound (Mitigating V4 and V6): Immediately before deriving a new Long-Term Key (PK/LTK) and overwriting the existing key, a barrier is established so that the newly negotiated security level and packet entropy size can never be lower than the AR_PK and previous entropy stored in the existing Security Database.
Authenticated and Integrity-Protected Re-Pairing
“Hardened Re-Pairing Logic” is an effective mitigation, but it does not fully suppress the fundamental problems of V1 and V2, namely the lack of authentication for the request itself and unnecessary re-pairing attempts through fake security requests. To solve this by design-by-default, the researchers proposed a new cryptographic re-pairing protocol as an amendment to the Bluetooth standard.
The core idea of this proposal is to use the previously stored Long-Term Key (PK_old) as a “cryptographic proof mechanism” for deriving the new key.
Key Chaining: In the KDF (Key Derivation Function) algorithm that generates the new pairing key (PK_new), not only the newly exchanged ECDH Shared Secret (ss), but also the previously trusted Long-Term Key (PK_old) is added as a required input parameter, expressed as PK_new = KDF(ss, h_{transcript} || PK_old). Through this, an attacker, Charlie, who does not know PK_old cannot mathematically derive the correct PK_new, causing the re-pairing attempt to fail unconditionally and guaranteeing implicit authentication.
Transcript Hashing: All SMP message packets exchanged during the pairing process, such as AuthReq flags and entropy size, are cumulatively hashed to generate h_{transcript}, and this is combined into the key derivation process, expressed as h = hash(h || msg). If an attacker modifies even one bit of an AuthReq packet through a relay attack in the middle, the h_{transcript} values calculated by the two devices will differ, and therefore the final derived PK_new will not match. This provides integrity protection that fundamentally blocks MitM attacks, including relay-based single-channel attacks.
This method adds almost no overhead, and formal verification tools such as ProVerif mathematically proved that it defends against replay and reflection attacks and guarantees strong mutual authentication. However, when a device is factory reset and loses PK_old, there is a UX trade-off in that user intervention is required for exception handling.
Reference
http://www.ktword.co.kr/test/view/view.php?no=1082
The Bluetooth® Low Energy Primer Document