9  Pairing Methods and MITM Protection

bluetooth-ble
bt
security
pairing

9.1 Start With the Story

A door lock, a phone, and an attacker in the hallway make pairing method selection concrete. “It connected” is not enough; the review has to know what the user could confirm, what the attacker could imitate, and which keys remain afterward.

Use this chapter by starting with device I/O and threat model. Choose Just Works, passkey, Numeric Comparison, or OOB only after the MITM claim, bonding decision, and recovery path are visible.

In 60 Seconds

BLE security depends on the pairing method, not the encryption cipher. “Just Works” provides zero MITM protection and suits only public data. Numeric Comparison and Out-of-Band (OOB) pairing provide strong MITM resistance for security-sensitive devices. After pairing, bonding stores keys for reconnection, but stored keys become a risk if devices are physically compromised.

Key Concepts
  • OOB (Out-Of-Band) Pairing Data: Cryptographic confirmation values exchanged over NFC, QR code, or other side-channels before BLE connection; prevents MITM by authenticating the BLE channel setup
  • Numeric Comparison (NC): BLE 4.2+ LESC pairing method displaying a 6-digit number on both devices; user confirms they match, providing MITM protection
  • Passkey Entry Display: One device shows a 6-digit passkey; user enters it on the other device; protects against passive eavesdropping; 1-in-10^6 brute-force probability
  • IO Capability Matrix: How the pairing method is selected based on the IO capabilities of both devices; e.g., DisplayYesNo + KeyboardOnly → Passkey Entry; NoInputNoOutput + any → Just Works
  • LE Secure Connections Confirmation: LESC pairing sends a cryptographic commitment (EC-DAKE protocol) before revealing the confirmation value, preventing the TK=0 attack that breaks legacy Just Works
  • Authentication Requirements Bitmask: GAP security parameters field specifying: MITM protection (bit 2), Secure Connections (bit 3), Keypress notification (bit 4), CT2 (bit 5)
  • Key Distribution Phase: After pairing, both devices optionally exchange additional keys: LTKE (Long Term Key Encryption), IRK (Identity), CSRK (Signing) — for peripheral and central separately
  • Bonding Flag: GAP authentication requirement bit 0; if set, both devices store the LTK/IRK/CSRK after pairing for future reconnections without re-pairing

9.2 Learning Objectives

By the end of this chapter, you will be able to:

  • Explain the BLE Pairing Protocol: Describe the three-phase pairing sequence and what keys are exchanged in each phase
  • Compare Pairing Methods: Analyze Just Works, Passkey Entry, Numeric Comparison, and OOB pairing across security level and I/O requirements
  • Diagnose Just Works Vulnerabilities: Justify why TK=0 in legacy Just Works provides no MITM protection and when it is acceptable
  • Select Appropriate Pairing: Evaluate device capabilities and threat model to choose and configure the correct pairing method

Pairing is how two Bluetooth devices establish trust and agree on encryption keys. There are several methods: Just Works (automatic, no user input), Numeric Comparison (confirm matching numbers on both screens), and Passkey Entry (type a PIN). Each method offers a different balance of security and convenience.

Use this chapter as a design checklist:

  • Start from the threat model: public telemetry, private data, physical access, medical control, or payment flow.
  • List the device I/O capabilities: display, Yes/No button, keyboard, NFC, QR label, or no user interface.
  • Choose the strongest pairing method the hardware can support.
  • Add application-layer authorization for sensitive commands after pairing.
  • Decide whether bonding is worth the stored-key risk, then plan key revocation and factory reset.

9.3 Prerequisites

Before diving into this chapter, you should be familiar with:

  • Bluetooth Fundamentals and Architecture: Understanding BLE connection establishment and protocol stack
  • Basic Cryptography Concepts: Familiarity with encryption and key exchange principles (AES, ECDH)

9.4 Minimum Viable Understanding

BLE security is determined by the pairing method, not the encryption cipher. “Just Works” pairing provides zero man-in-the-middle (MITM) protection, making it suitable only for public data. Numeric Comparison and Out-of-Band (OOB) pairing provide strong MITM resistance and should be used for security-sensitive devices. After pairing, bonding stores keys for convenient reconnection, but stored keys become a risk if devices are physically compromised.

Key Takeaway

In one sentence: BLE security depends on the pairing method, not just encryption - “Just Works” provides no MITM protection, while Numeric Comparison and Out-of-Band pairing defend against active attackers during setup.

Remember this: Always match pairing method to threat model: use OOB or Numeric Comparison for security-critical devices (locks, medical, payments).

9.5 Why Bluetooth Security Matters

Analogy: Bluetooth security is like locking your front door.

  • No security = Leaving door wide open (anyone can walk in)
  • Weak security = Cheap lock with key under mat (looks secure, but not really)
  • Strong security = Deadbolt + verified keys (only authorized people enter)

Common failure patterns:

  • Access-control devices: Just Works pairing can allow an attacker nearby during setup to become the trusted device.
  • Wearables: unencrypted or weakly authenticated links can expose private health or location-adjacent data.
  • Medical devices: default or static passkeys weaken the pairing ceremony and can put treatment workflows at risk.
  • Vehicles and tags: weak bonding or revocation logic can leave cloned or stolen devices trusted for too long.

9.6 BLE Pairing Methods Comparison

BLE supports four pairing methods with different security levels:

9.6.1 Four Pairing Methods (Weakest to Strongest)

  • Just Works: no user verification. It is acceptable only when the data and commands are low risk, because it provides no MITM protection.
  • Passkey Entry: one device shows a fresh 6-digit passkey and the user enters it on the other device. It is useful when one side has a display and the other has input.
  • Numeric Comparison: both devices show the same 6-digit value and the user confirms the match. It is the preferred LE Secure Connections choice when both devices can display and confirm.
  • Out of Band (OOB): authentication data is exchanged through a separate channel such as NFC or QR. It is strongest when physical presence should be part of setup.

9.7 “Just Works” Pairing: A Critical Security Flaw

BLE’s “Just Works” pairing mode provides zero authentication and is vulnerable to Man-in-the-Middle (MITM) attacks. In Legacy Pairing, Just Works sets the Temporary Key (TK) to zero, meaning the Short Term Key (STK) derivation has no user-supplied entropy. In LE Secure Connections, no user confirmation occurs, so there is still no MITM protection despite the improved ECDH key exchange:

How the attack works:

  1. Legitimate device advertises BLE service (smart lock, medical device)
  2. Attacker intercepts pairing request before legitimate user connects
  3. Attacker completes “Just Works” pairing (no user verification required)
  4. Attacker gains full access - can read data, send commands, impersonate user

Real consequences:

  • Smart lock: Anyone within range can unlock door during pairing
  • Medical device: Attacker reads private health data or alters treatment
  • Payment terminal: Intercept transaction information
  • Industrial sensor: Inject false data into control systems

Solution: Avoid Just Works for security-sensitive applications. Prefer:

  • Numeric Comparison (BLE 4.2+): Users verify 6-digit code on both devices
  • Passkey Entry: Device displays PIN, user enters on phone
  • Out-of-Band: Exchange keys via NFC tag or QR code

This variant shows the same pairing vulnerability concept as a defense-in-depth diagram:

Defense layers diagram showing how stronger BLE pairing methods (OOB, Numeric Comparison, Passkey) create progressively more barriers against MITM attackers compared to Just Works
Figure 9.1: BLE pairing as defense layers: stronger methods create more barriers against attackers

Key Insight: Think of pairing methods as concentric security layers. “Just Works” is an unlocked door - attackers walk right through. Each stronger method adds a verification barrier.

9.8 BLE Pairing Process

The BLE pairing process establishes secure communication between two devices through a three-phase protocol:

Diagram showing the three phases of BLE pairing between two Bluetooth Low Energy devices. Phase I shows Pairing Request and Pairing Response messages exchanged between Device 1 and Device 2. Phase II establishes Short Term Key (STK) Agreement through STK-based encryption. Phase III performs Secret Key Distribution where Long Term Key (LTK), Identity Resolving Key (IRK), and Connection Signature Resolving Key (CSRK) are exchanged bidirectionally between devices for future secure reconnections.
Figure 9.2: Source: University of Edinburgh IoT Security Course

Phase I - Feature Exchange:

  • Devices exchange pairing capabilities (I/O capabilities, bonding flags)
  • Determines which pairing method will be used (Just Works, Passkey, Numeric Comparison, OOB)

Phase II - Short Term Key (STK) Generation:

  • Temporary encryption key established for current session
  • Based on agreed pairing method and exchanged nonces

Phase III - Key Distribution:

  • LTK (Long Term Key): Stored for future reconnections (bonding)
  • IRK (Identity Resolving Key): Enables MAC address privacy
  • CSRK (Connection Signature Resolving Key): For signed data verification

9.8.1 Pairing Security (v4.2+)

  • ECDH key exchange (LE Secure Connections) — replaces STK derivation in Legacy Pairing with a P-256 Diffie-Hellman exchange
  • AES-CCM (128-bit) link-layer encryption for confidentiality/integrity
  • MITM resistance depends on the pairing method (e.g., Numeric Comparison/Passkey/OOB vs Just Works)
  • Numeric Comparison is exclusive to LE Secure Connections (BLE 4.2+) — it is not available in Legacy Pairing
  • OOB authentication works in both Legacy Pairing and LE Secure Connections
  • Passkey Entry and Just Works are available in both Legacy Pairing and LE Secure Connections
  • Optional privacy features (e.g., resolvable private addresses via IRK) to reduce tracking

Diagram showing the BLE numeric comparison pairing protocol between Initiating Device A and Non-initiating Device B. Shows Authentication Stage 1 (Just Works), random number selection (Na, Nb), confirmation value computation using Cb=f4(PKb, PKa, Nb, 0), exchange of confirmation values (Cb, Na, Nb), and the final user verification step where Va and Vb are computed as 6-digit numbers displayed on each device for the user to confirm they match before proceeding. Source: University of Edinburgh IoT Security Course.

BLE numeric comparison pairing protocol flow

Source: University of Edinburgh - IoT Systems Security Course

This diagram illustrates the cryptographic protocol behind BLE’s Numeric Comparison pairing method. The key security feature is that both devices independently compute 6-digit verification codes (Va and Vb) that must match - if an attacker intercepts the connection, their codes will differ, alerting the user to the MITM attack.

9.9 Bonding: Remembering Trusted Devices

Simple explanation: After pairing, devices can “remember” each other (like saving a contact in your phone).

Trade-off:

  • Convenience (no re-pairing)
  • Risk (if device stolen, attacker has saved keys)

9.9.1 Knowledge Check: Pairing Method Capabilities

9.10 Common Beginner Mistakes

Mistake 1: “My device has Bluetooth, so it’s secure”

  • Wrong! Many BLE devices use “Just Works” pairing (no MITM protection during setup)
  • Check: Does it require PIN or code verification during pairing?

Mistake 2: “I set a strong password, so I’m safe”

  • Wrong! If pairing mode is “Just Works”, password doesn’t help
  • Check: Pairing method matters more than password strength

Mistake 3: “Bluetooth only works 10 meters, so I’m safe from hackers”

  • Wrong! Range depends on environment and hardware; directional antennas can extend it
  • Solution: Use secure pairing regardless of “expected” range

Mistake 4: “My smart lock app requires a password, so it’s secure”

  • Wrong! App password is not equal to Bluetooth pairing security
  • Check: Pairing/transport security and app login are separate controls
Common Misconception: “My Device Has Encryption, So It’s Secure”

The misconception: “If BLE link encryption is enabled, my system is secure.”

The reality: Link encryption protects confidentiality/integrity after two devices agree on keys. The pairing method and your authorization logic determine who gets those keys and what they can do.

What to remember:

  • BLE link-layer encryption is AES-CCM with 128-bit keys (you do not “choose AES-256” at the BLE link layer)
  • “Just Works” provides no user-authenticated verification, so it does not protect against an active MITM during pairing
  • Even with encrypted links, you still need application-layer authentication/authorization for actions like “unlock”, “dose”, or “open valve”

Key takeaway: Choose the pairing method based on your threat model, then layer on authorization and secure updates. Don’t treat “encrypted” as “secure.”

9.10.1 Knowledge Check: BLE Pairing Methods

9.10.2 Knowledge Check: Bonding Security

9.10.3 Knowledge Check: Pairing Method Selection

9.11 Dig Deeper and Practice

This chapter now stays focused on the pairing-method decision. Use the child chapters for the deeper protocol mechanics and exercises:

9.11.1 Summary

  • BLE pairing security is a setup ceremony, not just a cipher choice.
  • Just Works can encrypt a link but gives no user-authenticated MITM protection.
  • LE Secure Connections uses P-256 ECDH to protect against passive key recovery, while Numeric Comparison, Passkey Entry, or OOB evidence is still needed for active MITM resistance.
  • Bonding stores LTK, IRK, and CSRK material for reconnection, so stored-key protection and revocation are part of the pairing design.
  • High-impact products should reject silent fallback to Just Works and explain pairing-security mismatches to users.

9.12 What’s Next

Prioritize these follow-up chapters based on what you need next: