SMP

HEADER (1 Byte)          DATA (Variable)
+------------------+---------------------------------------+
|                  |                                       |
|       CODE       |           DATA / PAYLOAD              |
|     (Opcode)     |                                       |
|                  |                                       |
+------------------+---------------------------------------+
         ^                         ^
         |                         |
 0x01 = Pairing Req        Keys, Nonces, Capabilities
 0x02 = Pairing Rsp
 0x04 = Confirm

Context: If the Link Layer is the road and L2CAP is the truck, SMP (Security Manager Protocol) is the armored car transfer. It is responsible for Pairing (generating keys) and Bonding (saving keys for later).

For security researchers, SMP is the "Holy Grail." This is where the keys are exchanged. If you break SMP, you don't need to jam or fuzz—you just login as the admin. Most critical BLE hacks (like the Google Titan Key vulnerability or KNOB attack) target the negotiation phase of SMP to downgrade security before the keys are even generated.

---

1. The Three Phases of Pairing

SMP doesn't just "connect." It follows a strict 3-phase process.

1. Phase 1: Feature Exchange: "I support encryption," "I have a screen," "I have a keyboard."

2. Phase 2: Key Generation (The Vulnerable Part): They agree on a Temporary Key (TK) or Short Term Key (STK). This is where MITM happens.

3. Phase 3: Transport Specific Key Distribution: They exchange the real keys (LTK, IRK, CSRK) encrypted by the result of Phase 2.

Security Perspective

If Phase 2 is weak (e.g., "Just Works" pairing), the "encryption" protecting Phase 3 is useless. An attacker sniffing Phase 2 can derive the key used to encrypt Phase 3 and steal the permanent keys (LTK).

---

2. Legacy Pairing vs. Secure Connections (SC)

This is the single most important distinction in BLE security.

• Legacy Pairing (BLE < 4.2): Uses standard AES. Vulnerable to passive sniffing. If you capture the pairing packets, you can crack the Short Term Key (STK) in seconds.

• Secure Connections (BLE 4.2+): Uses ECDH (Elliptic Curve Diffie-Hellman). Immune to passive sniffing. Even if you capture the handshake, you cannot derive the Session Key.

🛡️ Security Checks & Testing

• Downgrade Attack Check:

  • Test: During the "Phase 1: Feature Exchange," intercept the Pairing Request and flip the "Secure Connections Support" bit to 0.

  • Goal: Does the device accept the downgrade and switch to Legacy Pairing? If yes, you can now sniff the connection passively.

  • Tool: Bettercap (MITM mode) or GATTacker.

• Sniff & Crack:

  • Test: Use Ubertooth or Wireshark to capture a pairing event.

  • Goal: Load the capture into CrackLE (for Legacy) or Wireshark. If it's Legacy Pairing, the tool will derive the LTK instantly.

---

3. Association Models: "Just Works" vs. The Rest

How do devices prove they are who they say they are? They use the IO Capabilities (Input/Output) exchanged in Phase 1.

• Just Works: No screen, no keyboard. (e.g., Headset). Risk: Zero authentication. MITM is trivial.

• Passkey Entry: "Type 123456." Risk: Secure against passive sniffing (in Legacy) but vulnerable if the attacker can see the screen.

• Numeric Comparison (SC Only): "Does 123456 match?" Risk: Very secure, protects against MITM.

Security Perspective

The "IO Capability" is not a physical fact; it's just a byte in a packet. Attack: You can lie. If a Smart Lock says "I have a Display" (expecting Numeric Comparison), an attacker can MITM the connection and tell the Phone "I have No Input/No Output." The Phone will downgrade the method to Just Works, bypassing the authentication check.

🛡️ Security Checks & Testing

• IO Capability Spoofing (MITM):

  • Test: Perform an active MITM. When the target sends Pairing Request with IO Cap: DisplayYesNo, change it to NoInputNoOutput.

  • Goal: Does the phone pop up a pairing dialog without asking for a code? (Success).

  • Tool: GATTacker, BtleJuice.

---

4. Key Distribution (The Loot)

In Phase 3, devices hand over the "keys to the kingdom."

• LTK (Long Term Key): Used to encrypt future data.

• IRK (Identity Resolving Key): Used to track the device (resolve privacy addresses).

• CSRK (Connection Signature Resolving Key): Used for data signing.

Security Perspective

Developers often mishandle these keys on the mobile side. They save the LTK in plain text in the Android SharedPrefs or iOS .plist. If you root/jailbreak the phone, you can extract these keys and clone the device's identity.

🛡️ Security Checks & Testing

• Mobile App Audit:

  • Test: Pair the device with an Android phone. Pull the APK data (adb pull /data/data/com.app.package).

  • Goal: Grep for the LTK (usually a 16-byte hex string). If it's stored in plain text, it's a fail.

---

5. CTKD (Cross-Transport Key Derivation)

In newer devices (BLE 5+), pairing over BLE can also generate keys for Bluetooth Classic (BR/EDR). This is called CTKD. Vulnerability (BLURtooth): If an attacker can overwrite the Authenticated Key of a device with an Unauthenticated Key via BLE, they might gain access to the Bluetooth Classic profile (e.g., Audio, Handsfree) without pairing again.

🛡️ Security Checks & Testing

• Key Overwriting:

  • Test: Bond with a device using "Just Works" (Unauthenticated).

  • Goal: Check if this overwrites a previously bonded "Authenticated" session. (Requires specialized setups like InternalBlue).

---