Bluetooth & BLE · Study deck

BLE Pairing and MITM Defense

Picture a nurse pairing a tablet with a medicine cabinet.

Radio Remi is your guide for this deck.

securitypairingdeep

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: Many developers assume Numeric Comparison will be used but forget that their peripheral declares NoInputNoOutput (a common default in SDK examples), forcing Just Works regardless of the central's capabilities.
Explain: BLE pairing method selection follows the exchanged IO capability, OOB, MITM, and Secure Connections flags; it does not simply select the strongest method the hardware supports.
Explain: During the Pairing Request and Pairing Response, both devices declare their I/O capabilities: display, keyboard, Yes/No confirmation, and out-of-band support.
Explain: A known passkey removes the practical value of Passkey Entry as a verification step.

Major section

Start With the Story · Protocol Evidence Checklist

The nurse must know that the cabinet, not a nearby attacker's device, helped create that number.

Bluetooth Low Energy, or BLE, is a short-range radio system.
Pairing is the setup talk that creates shared secret material between two devices.
This simple story leaves out the mathematics.

Major section

Deep Dive: IO Capabilities, Legacy Pairing, and Numeric Comparison Evidence · Why Numeric Comparison Beats Active MITM

The pairing method is not only a product preference.

During the Pairing Request and Pairing Response, both devices declare their I/O capabilities: display, keyboard, Yes/No confirmation, and out-of-band support.
Numeric Comparison adds a transcript check after the public-key and nonce exchange.

Numeric Comparison Authentication Stage 1: Device A and Device B each choose a random nonce, Device B computes a confirmation value from both public keys and its own nonce and sends it first, the two nonces are exchanged next, Device A verifies the confirmation and aborts on mismatch, both devices then compute a six-digit value from the shared public keys and nonces, and the user compares the two displayed values before pairing proceeds.

Major section

Passkey Entry Bit Commitments · f5 Key Derivation After ECDH

Passkey Entry does not safely authenticate by sending the six-digit passkey across the radio.

Each round binds one bit of the passkey to fresh random material and the devices' public keys before the bit is effectively checked.
A wrong guess fails a round; repeated failures are visible as pairing failures and should trigger lockout or delay.
This separation protects the protocol design.

Major section

Deep Review Checklist · Worked Example: Comparing Just Works and Numeric Comparison

Scenario: A smart door lock is being paired in an apartment building with many nearby BLE devices.

Just Works pairing: In Just Works mode, there is zero user-authenticated verification.
Attacker (within range) sends pairing request first.
Lock accepts (no verification step).
Attacker now has bonded keys (LTK).

Major section

Common Mistake: Using a Fixed PIN for Passkey Entry Pairing

The same passkey works for every unit or every pairing attempt.

Reverse engineering the firmware or setup app can reveal the passkey.
A known passkey removes the practical value of Passkey Entry as a verification step.
Display the passkey only while the user has intentionally started pairing.

Major section

Common Mistake: Using a Fixed PIN for Passkey Entry Pairing (continued)

This allows an attacker to photograph the PIN from a distance, then initiate pairing later.

Discard the passkey after use; do not reuse it for later sessions.
Lock out or slow down repeated failures so online guessing is noisy and slow.
After 60 seconds or successful pairing, PIN is discarded.

Major section

2. Hardcoding a Static Passkey Instead of Generating Random PINs · 3. Ignoring the IO Capability Negotiation Outcome

BLE pairing method selection follows the exchanged IO capability, OOB, MITM, and Secure Connections flags; it does not simply select the strongest method the hardware supports.

A common development shortcut is to hardcode a fixed passkey for convenience during testing, then ship the same firmware to production.
An attacker who reverse-engineers the firmware or observes the setup flow may learn the passkey.
Many developers assume Numeric Comparison will be used but forget that their peripheral declares NoInputNoOutput (a common default in SDK examples), forcing Just Works regardless of the central's capabilities.

Major section

BLE Pairing Practice Checks

This child chapter contains the practice material split out of Pairing Methods & MITM Protection.

If the lock accepts the first request it hears, setup can finish cleanly for the wrong person.
Bluetooth Low Energy (BLE) is a short-range way for devices to connect while using little power.
The key question is not only whether pairing succeeds.

Major section

BLE Pairing Practice Checks (continued)

If setup uses Just Works by itself, the first nearby central that completes pairing can become the trusted controller.

Pairing is the setup step in which two devices form shared trust.
A screen can show a number.
A button can confirm a match.
A printed code, tap, or account claim can prove physical access.

Major section

BLE Pairing Practice Checks (continued)

This simple check does not cover every radio attack.

The lock advertises a setup service and accepts pairing during a short commissioning window.
The lock stores the attacker's bond keys for later reconnection.
The legitimate user may only see a vague setup failure unless the app explains the problem.

Major section

BLE Pairing Practice Checks (continued)

Firmware updates, customer support, and replacement setup flows become expensive after release.

Trust damage is hard to recover when pairing controls doors, medication, vehicles, or payment workflows.
Security-by-design requirements increasingly expect products to justify why weak pairing is safe for their use case.
Rule of thumb: If the BLE device controls physical access, medication, vehicles, or payment data, Just Works should not be the sole setup control.

Major section

BLE Pairing Practice Checks (continued)

Practice becomes useful when a learner can change the device capabilities and watch the security outcome change.

Just Works and MITM protection: no user-authenticated verification means a nearby attacker can participate in setup unnoticed.
Bonding and stored-key risk: saved LTK/IRK/CSRK values make reconnection convenient but require protected storage and revocation.
A display, a button, an NFC side channel, or no I/O should lead to different pairing evidence.

Deck summary

Key takeaways

The nurse must know that the cabinet, not a nearby attacker's device, helped create that number.

The pairing method is not only a product preference.
Passkey Entry does not safely authenticate by sending the six-digit passkey across the radio.
Scenario: A smart door lock is being paired in an apartment building with many nearby BLE devices.
The same passkey works for every unit or every pairing attempt.

Retrieval practice

Recall check 1 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q1This chapter's Numeric Comparison analysis explains why LE Secure Connections' ECDH exchange alone does not stop an active relay. What extra evidence does Numeric Comparison add that closes that gap?

AA user comparison of the six-digit values derived from both devices.

BA longer ECDH key, assumed to prevent an attacker relaying messages.

CAn automatic pairing retry that treats extra time as attack proof.

DImmediate link encryption before any user confirmation step.

Show answer

Answer: A LE Secure Connections' ECDH exchange defeats passive eavesdroppers but not an active relay running two separate ECDH exchanges.

Retrieval practice

Recall check 2 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q2Per this chapter, why does Passkey Entry authenticate the six-digit passkey through repeated bit-by-bit commitment rounds instead of sending the whole passkey once?

ABecause fresh per-bit commitments keep a relay from reusing an observed whole passkey.

BBecause a Bluetooth radio can transmit only one application-data bit per event.

CBecause sending one bit at a time reduces the six-digit number users must enter.

DBecause the same passkey is then safe to reuse across unlimited pairing attempts.

Show answer

Answer: A The chapter explains that each round of Passkey Entry binds one passkey bit to fresh random material and the devices' public keys before that bit is checked.

Retrieval practice

Recall check 3 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q3The chapter's MITM probability calculator models Just Works risk using an illustrative 75% 'timing race' success rate per attempt. How does the chapter say this number should be treated?

AA teaching assumption, not a measured attack success rate for a product.

BA certified Bluetooth SIG failure rate for real Just Works products.

CAn exact probability computed from the six-digit comparison keyspace.

DA mandatory worst-case rate every BLE product must test before certification.

Show answer

Answer: A see answers page

Retrieval practice

Recall check 4 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q4A displayless smart lock uses Just Works pairing during a commissioning window. Per this chapter's case pattern, what is the actual failure mode?

AA nearby device that pairs first can become trusted because Just Works lacks authentication.

BThe lock crashes when it cannot show a pairing confirmation screen.

CAn attacker must physically hold the lock, so nearby radio pairing cannot win.

DThe owner's phone always wins because it begins its request before attackers.

Show answer

Answer: A see answers page

Retrieval practice

Recall check 5 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q5What retains long-term Bluetooth keys so reconnection can authenticate without full pairing again?

AIO Capability Exchange

BBonding (Key Storage)

CPairing Method Selection

DKey Generation

Show answer

Answer: B It stores long-term keys so reconnection can authenticate without repeating the full ceremony.

Q6Complete the pairing method selector for a BLE product design:

Aif device.has_nfc or device.has_qr:

Bif device.advertises_fast:

Cif device.rssi > -60:

Dif device.name.startswith("BLE"):

Show answer

Answer: A High-risk BLE products should prefer OOB or Numeric Comparison.

Print reference

Answers 1 of 3

Answer key.

A · LE Secure Connections' ECDH exchange defeats passive eavesdroppers but not an active relay running two separate ECDH exchanges.
A · The chapter explains that each round of Passkey Entry binds one passkey bit to fresh random material and the devices' public keys before that bit is checked.
A · The chapter explicitly labels the comparison as illustrative: 'Treat the values as a teaching model, not a measured product failure rate.' The 75% Just Works figure represents an assumed timing-race outcome for teaching purposes, contrasted against Numeric Comparison's 1-in-1,000,000 per-attempt figure and OOB's near-zero figure -- none of these are measured statistics from real deployed products.

Print reference

Answers 2 of 3

Answer key.

A · The chapter's case pattern is explicit: a displayless lock cannot run Numeric Comparison because it has no way to show a confirmation code, so if setup relies on Just Works alone, whichever nearby central completes pairing first becomes the trusted controller and its bond keys are stored -- there is no cryptographic check to reject an attacker who simply pairs before the legitimate owner.

Print reference

Answers 3 of 3

Answer key.

B · It stores long-term keys so reconnection can authenticate without repeating the full ceremony.
A · High-risk BLE products should prefer OOB or Numeric Comparison.