BLE Pairing Methods Compared: Just Works vs Passkey vs OOB

BLE Pairing Methods Compared: Just Works vs Passkey vs OOB

BLE pairing establishes the cryptographic keys used to encrypt a connection. The Bluetooth SIG defines four association models under the Security Manager Protocol (SMP), each making different trade-offs between user friction and protection against man-in-the-middle (MITM) attacks.

The Four Pairing Models

Just Works

Mechanism: Devices exchange public keys via ECDH (LE Secure Connections) or a fixed TK=0 (Legacy Pairing). No user confirmation.

Security analysis: - LESC Just Works: ECDH key exchange is mathematically secure but no authentication — neither device verifies the other's identity - Vulnerable to MITM: attacker intercepts and substitutes their own public key - Suitable for: headless IoT devices, connections that never transmit sensitive data, cases where physical access security provides the MITM prevention

Just Works LESC flow:
  A → B: Pairing Request (IO=NoInputNoOutput)
  B → A: Pairing Response (IO=NoInputNoOutput)
  A, B: Generate ECDH keypair
  A → B: Public Key (Xa, Ya)
  B → A: Public Key (Xb, Yb)
  A, B: Compute DHKey = ECDH(own_private, peer_public)
  A, B: Derive LTK from DHKey + nonces (no numeric confirmation)

Passkey Entry

Mechanism: One device displays a 6-digit passkey (000000–999999); the user enters it on the other device. Both devices use the passkey to derive the pairing nonce, making the exchange MITM-resistant.

Security analysis: - 1 in 10⁶ brute-force probability per attempt - BT spec allows 20-bit passkey (1,048,576 values); displayed as 6-decimal digits - Each bit of the passkey is confirmed separately via 20 rounds of commitment-reveal, preventing brute force during pairing - BLE eavesdropping reveals the commitment exchanges but not the passkey bits

IO capability matrix (determines which model is selected):

(I = initiator inputs, R = responder displays)

Numeric Comparison

Mechanism: Both devices display a 6-digit number. The user confirms they match on both devices. Available only with LE Secure Connections.

Security analysis: - Strongest interactable model — provides authentication AND prevents MITM - The displayed number is derived from the ECDH exchange; a MITM's substituted keys produce different numbers on each device - Requires two devices with displays — not applicable to most IoT sensors

OOB Pairing

Mechanism: Pairing data (random nonce, address, confirm value) exchanged via an out-of-band channel. NFC is the most common OOB channel for BLE accessories.

Security analysis: - Security level = security of OOB channel - NFC OOB: MITM-resistant (physical proximity required to eavesdrop NFC) - QR code OOB: vulnerable if attacker photographs QR - Static QR on device (common in IoT) provides no MITM protection — same as Just Works

Selecting the Right Model

Decision tree:

Does device have a display?
  No → Does peer have keyboard?
         No → Just Works (no MITM protection — accept risk or use OOB)
         Yes → Passkey Entry (device displays, user types)
  Yes → Does device have yes/no buttons?
          No → Passkey Entry (device displays)
          Yes → Does peer also have a display?
                  Yes → Numeric Comparison (best UX + security)
                  No → Passkey Entry

Is NFC available on device?
  Yes → Prefer OOB (NFC with per-session nonce) for frictionless MITM protection

For smart locks and medical devices, always use Numeric Comparison or OOB-NFC. See BLE MITM Prevention for the full attack surface analysis.