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: The correct approach is to use the platform hardware random source to generate a fresh 6-digit passkey for each pairing attempt, display it only during the pairing window, and discard it afterwards.
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: Rule of thumb:: If the BLE device controls physical access, medication, vehicles, or payment data, Just Works should not be the sole setup control.
Explain: Pairing is the setup talk that creates shared secret material between two devices.

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)

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.
This allows an attacker to photograph the PIN from a distance, then initiate pairing later.
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

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.
The correct approach is to use the platform hardware random source to generate a fresh 6-digit passkey for each pairing attempt, display it only during the pairing window, and discard it afterwards.
BLE pairing method selection is automatic: both devices exchange IO capability flags and the protocol selects the strongest mutually supported method.

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 six-digit value computed from the exchanged public keys and nonces, which the user confirms matches on both devices

BA longer ECDH key size that a relay cannot compute in real time

CAn automatic retry that disconnects if the pairing takes longer than expected

DEncrypting the link immediately after the DHKey is computed, before any 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?

ASo a relay cannot observe the full passkey and reuse it on its other connection; each round binds one bit to fresh random material and the public keys before that bit is checked

BBecause the Bluetooth radio can only transmit one bit of application data per connection event

CTo make the six-digit passkey shorter and quicker for the user to type

DSo the same passkey can be safely reused across many pairing attempts without regenerating it

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?

AAs a teaching model to contrast the mechanisms, not as a measured real-world attack success rate for any product

BAs a certified failure rate published by the Bluetooth SIG

CAs the exact probability derived from the 6-digit Numeric Comparison keyspace

DAs a worst-case number that every BLE product must test against before certification

Show answer

Answer: A

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?

AAny nearby device that completes pairing first during the commissioning window becomes the trusted controller, because Just Works has no confirmation step to reject an unexpected pairer

BThe lock's firmware crashes because it cannot render a confirmation screen

CThe attacker must physically hold the lock to pair with it, so remote attacks are impossible

DThe owner's phone always wins the pairing race because it initiates the connection request first

Show answer

Answer: A see answers page

Retrieval practice

Recall check 5 of 5

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

Q5Place each pairing artifact where it lives so you can choose a method and know what survives reconnection.

AIO Capability Exchange

BPairing Method Selection

CKey Generation

DBonding (Key Storage)

Show answer

Answer: A Place negotiation, key creation, and retained trust correctly so you can tell pairing from bonding and choose protection that matches device I/O.

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

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.

A · Place negotiation, key creation, and retained trust correctly so you can tell pairing from bonding and choose protection that matches device I/O.
A · High-risk BLE products should prefer OOB or Numeric Comparison.