11.1 Interactive: MITM Attack Probability Calculator
Compare an illustrative MITM risk model across pairing methods and attacker attempts. Treat the values as a teaching model, not a measured product failure rate.
Understanding pairing vulnerabilities in theory is important, but the design pattern is what matters for learners: the same mistake repeats across access-control, health, and industrial devices when setup accepts the first nearby device without strong verification.
11.3 Case Pattern: Displayless Lock Setup
A displayless lock often cannot run Numeric Comparison because the lock cannot show a confirmation code. If setup uses Just Works by itself, the first nearby central that completes pairing can become the trusted controller.
Attack timeline:
The lock advertises a setup service and accepts pairing during a short commissioning window.
An attacker nearby completes pairing before the owner’s phone.
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.
Design fix: Add a physical setup action, NFC/QR OOB data, cloud-backed ownership claim, or a short-lived setup token so pairing requires proof of physical presence or account ownership.
11.4 Pairing Method Selection Decision Framework
When designing a BLE IoT product, use this framework to select the appropriate pairing method based on device capabilities and threat model:
No display, no input, public telemetry: Just Works can be acceptable if no sensitive commands are exposed.
No display, has NFC or QR label: use OOB for private or safety-critical setup.
Display plus Yes/No input: use Numeric Comparison when both peers can show and confirm the same value.
Display plus keyboard/keypad: use Numeric Comparison when possible; use Passkey Entry when one device displays and the other enters the passkey.
Safety-critical device with no local UI: add a setup control, OOB channel, or account claim before shipping.
Cost of getting it wrong:
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.
11.5 Concept Relationships
Just Works and MITM protection: no user-authenticated verification means a nearby attacker can participate in setup unnoticed.
Numeric Comparison and user verification: the 6-digit comparison value turns MITM detection into a visible user decision.
OOB pairing and physical presence: NFC, QR, or setup tokens move authentication data outside the BLE radio channel.
Bonding and stored-key risk: saved LTK/IRK/CSRK values make reconnection convenient but require protected storage and revocation.
LE Secure Connections and ECDH: P-256 key agreement protects against passive recovery of the link keys, while the pairing method determines MITM resistance.
Practice becomes useful when a learner can change the device capabilities and watch the security outcome change. A display, a button, an NFC side channel, or no I/O should lead to different pairing evidence.
Use this page as a decision rehearsal. Try the cases, name the pairing method, explain the MITM boundary, and write down what the device would still need before deployment.