BLE MITM Prevention: Securing Against Man-in-the-Middle Attacks

BLE MITM Prevention: Securing Against Man-in-the-Middle Attacks

A Bluetooth Low Energy MITM attack intercepts the pairing exchange and substitutes the attacker's public key for the legitimate device's key. Once established, the attacker decrypts all traffic in both directions while relaying it transparently. Preventing MITM attacks requires authenticated key exchange — something Just Works pairing explicitly does not provide.

MITM Attack Anatomy

Legitimate flow:
  Phone ←────────── LTK encrypted ──────────→ Sensor

MITM attack:
  Phone ←── LTK1 ──→ Attacker ←── LTK2 ──→ Sensor
              |                        |
         Phone thinks             Sensor thinks
         attacker is sensor       attacker is phone

The attacker needs to be present during the initial pairing handshake. After bonding, re-connecting with the stored LTK is secure (the LTK is never retransmitted). MITM attacks target the first pairing or forced re-pairing (via bonding removal).

LE Secure Connections ECDH

LE Secure Connections (LESC) uses P-256 Elliptic Curve Diffie-Hellman (ECDH) for key exchange. The DHKey derived from ECDH is used to generate all session keys:

Phase 1: Feature exchange
  → Both devices share IO capabilities (determines association model)

Phase 2: ECDH key exchange + authentication
  A: generates ephemeral keypair (PrivA, PubA)
  B: generates ephemeral keypair (PrivB, PubB)
  A → B: PubA
  B → A: PubB
  DHKey = ECDH(PrivA, PubB) = ECDH(PrivB, PubA)

Phase 2: Nonce exchange (for Numeric Comparison / Passkey)
  → 20 commitment-reveal rounds confirm passkey bits
  → Displayed 6-digit number derived from:
     g2(PubA, PubB, Na, Nb) mod 10^6

Phase 3: Key distribution
  → LTK, IRK, CSRK exchanged over encrypted link

Why ECDH prevents MITM: If an attacker M substitutes PubM for PubA, then: - Phone computes DHKey_AM = ECDH(PrivA, PubM) - Sensor computes DHKey_MB = ECDH(PrivM, PubB) - DHKey_AM ≠ DHKey_MB → derived nonces differ → Numeric Comparison shows different numbers

Channel Sounding for Relay Prevention

Bluetooth 6.0 (October 2024) introduced Channel Sounding (also called Bluetooth Ranging), enabling sub-meter distance measurement between peers using RTT (Round-Trip Time) and HADM (High Accuracy Distance Measurement).

Channel Sounding prevents relay attacks (Bluetooth distance bounding):

Relay attack (e.g., car key relay):
  Attacker A near car ←→ Attacker B near legitimate key (100m away)
  Car sees key at "1m" (relayed)

Channel Sounding defense:
  Car measures ToF to key: RTT/2 = 0.33 µs → distance 50m (100m round trip)
  Car threshold: 5m → REJECT connection (key not physically present)

Channel Sounding uses Coded Tone Extension (CTE) signals on multiple frequencies with precise timestamp correlation:

Implementation Checklist

// Nordic nRF Connect SDK: enforce MITM protection
static const struct bt_conn_auth_cb auth_callbacks = {
    .passkey_display = auth_passkey_display,
    .passkey_confirm = auth_passkey_confirm,
    .cancel = auth_cancel,
    // No .passkey_entry = NULL means no keyboard → Numeric Comparison
};

// Reject Just Works (no MITM):
static void security_changed(struct bt_conn *conn, bt_security_t level,
                              enum bt_security_err err) {
    if (level < BT_SECURITY_L3) { // L3 = LESC with MITM
        bt_conn_disconnect(conn, BT_HCI_ERR_AUTH_FAIL);
    }
}

Security Levels Reference

For medical devices, always require L4. For smart locks, L3 minimum. See BLE Pairing Methods for IO capability selection and BLE Vulnerabilities for known attacks against pairing.