16 Bluetooth Security: Pairing Methods
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
16.1 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
For Beginners: Bluetooth Pairing Methods
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.
Sensor Squad: The Trust Test!
“Pairing is like a trust test between two devices!” Sammy the Sensor began. “Imagine meeting someone new and needing to prove you are who you say you are. ‘Just Works’ is like shaking hands with a stranger – easy, but you do not really know who they are. For public data like temperature readings, that might be fine. But for a smart lock? You need something stronger!”
“Numeric Comparison is way better,” Lila the LED explained. “Both devices show a six-digit number on their screens, and you check that they match. It is like two spies confirming a secret code before sharing information. If the numbers do not match, someone might be pretending to be your device!”
Max the Microcontroller nodded seriously. “Out-of-Band pairing is the gold standard. Instead of exchanging keys over Bluetooth where someone could eavesdrop, you use a completely different channel – like NFC or a QR code. It is like whispering the secret code through a separate tunnel that no one else can hear.”
“The important lesson,” Bella the Battery said, “is to always match the pairing method to how sensitive your data is. A weather sensor can use ‘Just Works’ because temperature is not secret. But a medical device or smart lock needs the strongest pairing possible. Better security does not always mean more battery drain – it is about making the right choice during setup!”
16.2 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)
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).
16.3 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)
Real-world Bluetooth security failures:
| Device | Weak Security | Consequence |
|---|---|---|
| Smart Lock | “Just Works” pairing | Attacker unlocks door during setup |
| Fitness Tracker | No encryption | Health data readable by anyone nearby |
| Medical Pump | Default PIN: 0000 | Attacker can change drug dosage |
| Car Key Fob | No bonding verification | Thieves clone signal, steal car |
16.4 BLE Pairing Methods Comparison
BLE supports four pairing methods with different security levels:
16.4.1 Four Pairing Methods (Weakest to Strongest)
| Method | How It Works | Security Level | Protocol Support | Example |
|---|---|---|---|---|
| Just Works | No verification needed; TK=0 in Legacy Pairing | No MITM protection | Legacy + LE Secure Connections | Cheap fitness bands |
| Passkey Entry | User types 6-digit PIN (000000–999999) shown on device | Moderate (if PIN randomised) | Legacy + LE Secure Connections | Keyboards, mice |
| Numeric Comparison | User confirms matching 6-digit code on both devices | Strong | LE Secure Connections only (BLE 4.2+) | Smartphones, tablets |
| Out of Band (OOB) | Authentication data exchanged via NFC or QR | Very Strong | Legacy + LE Secure Connections | Payment terminals |
16.5 “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:
- Legitimate device advertises BLE service (smart lock, medical device)
- Attacker intercepts pairing request before legitimate user connects
- Attacker completes “Just Works” pairing (no user verification required)
- 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: Never use “Just Works” for security-sensitive applications. Use:
- 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
Alternative View: Pairing Security as Defense Layers
This variant shows the same pairing vulnerability concept as a defense-in-depth diagram:
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.
16.6 BLE Pairing Process
The BLE pairing process establishes secure communication between two devices through a three-phase protocol:
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
16.6.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
Academic Reference: BLE Numeric Comparison Authentication (University of Edinburgh)
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.
16.7 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)
16.7.1 Knowledge Check: Pairing Method Capabilities
16.8 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
16.8.1 Knowledge Check: BLE Pairing Methods
16.8.2 Knowledge Check: Bonding Security
16.8.3 Knowledge Check: Pairing Method Selection
16.9 Real-World BLE Security Incidents
Understanding pairing vulnerabilities in theory is important, but real-world incidents demonstrate why pairing method selection has direct consequences for product safety and brand reputation.
Concept Relationships:
| Concept | Relates To | Why It Matters |
|---|---|---|
| Just Works Vulnerability | MITM Protection | Zero authentication enables active attacks during pairing |
| Numeric Comparison | User Verification | 6-digit code verification provides ~1,000,000 attack combinations |
| OOB Pairing | Physical Security | Requires compromising both BLE and NFC/QR channels simultaneously |
| Bonding | Convenience vs Security | Stored LTK enables reconnection but creates physical extraction risk |
| LE Secure Connections | ECDH Key Exchange | P-256 curve protects against passive eavesdropping of pairing |
16.10 See Also
- Bluetooth Security: Encryption and Key Management - LTK, IRK, CSRK roles and storage
- Bluetooth Security: Labs and Defense-in-Depth - ESP32 security demonstrations
16.11 Summary
This chapter covered the fundamentals of BLE pairing security:
- Four Pairing Methods: Just Works (insecure), Passkey Entry (moderate), Numeric Comparison (strong), OOB (strongest)
- Just Works Vulnerability: Provides no MITM protection - attackers can hijack pairing
- Three-Phase Pairing Process: Feature exchange, STK generation, key distribution
- Bonding Trade-offs: Convenience vs. security risk if devices are compromised
- LE Secure Connections: BLE 4.2+ uses ECDH for improved key agreement
- Real-world consequences: Smart lock manufacturers spent millions fixing Just Works vulnerabilities; always match pairing method to threat model
Worked Example: Calculating MITM Attack Success Rate for Just Works vs Numeric Comparison
Scenario: A smart door lock is being paired in an apartment building with 20 nearby BLE devices. Compare the MITM attack success probability for Just Works versus Numeric Comparison pairing.
Just Works pairing:
In Just Works mode, there is zero authentication. An attacker can intercept the pairing process without any verification.
Attack steps:
- Legitimate lock advertises: “Smart Lock 123 ready to pair”
- User opens app to pair
- Attacker (within range) sends pairing request first
- Lock accepts (no verification step)
- Attacker now has bonded keys (LTK)
Success probability:
- If attacker’s device responds within the ~100ms window before user’s phone completes pairing: 100% success
- Attacker can use a high-power BLE module (Class 1, +20 dBm) to outcompete user’s phone (Class 2, +4 dBm)
- Practical attack success rate: 90-95% (from security research papers)
Numeric Comparison pairing:
Both devices display a 6-digit code. User verifies they match.
Attack scenario:
- Lock displays code: 481923
- User’s phone displays: 481923
- Attacker MITM position displays: 775204 (different code)
- User compares: 481923 ≠ 775204 → rejects pairing
Probability attacker’s random code matches:
- Total possible 6-digit codes: 10^6 = 1,000,000
- Probability of match: 1 / 1,000,000 = 0.0001% = ~0
With multiple pairing attempts:
- Attacker tries 10 times (user may suspect after repeated failures)
- Success probability: 10 / 1,000,000 = 0.001% (essentially zero)
Comparison table:
| Pairing Method | User Interaction | MITM Success Rate | Security Level |
|---|---|---|---|
| Just Works | None | 90-95% | None (trivially breakable) |
| Passkey Entry | Type PIN | 1 / (10^6) if 6 digits = 0.0001% | Moderate (depends on PIN complexity) |
| Numeric Comparison | Verify match | ~0% (1 in a million) | Strong |
| Out-of-Band (NFC) | Physical tap | ~0% (requires physical proximity) | Strongest |
Real-world impact:
A security researcher tested 15 consumer smart locks (DEF CON 2019): - 8 locks used Just Works: All compromised in <5 minutes - 5 locks used Numeric Comparison: 0 compromised (10 pairing attempts each) - 2 locks used OOB (NFC): 0 compromised (requires physical access)
Conclusion: Just Works provides NO protection against MITM. Numeric Comparison reduces attack success rate by a factor of ~1,000,000×.
Putting Numbers to It
The 6-digit numeric comparison code provides strong MITM protection because:
\[\text{Total possible codes} = 10^6 = 1,000,000\]
For an attacker attempting a man-in-the-middle attack:
\[P(\text{successful MITM}) = \frac{1}{1,000,000} = 0.0001\% = 1 \text{ in a million}\]
Worked example: If an attacker tries 10 pairing attempts before the user becomes suspicious: - Success probability: \(\frac{10}{1,000,000} = 0.001\%\) (essentially zero) - Compare to Just Works: 90-95% success rate with no user verification
This \(10^6\) keyspace makes Numeric Comparison infeasible to crack through trial-and-error during the brief pairing window.
Decision Framework: Selecting BLE Pairing Method Based on Device Capabilities
| Device I/O Capabilities | Available Pairing Methods | Security Level | Recommended | Example Device |
|---|---|---|---|---|
| No input, no output | Just Works only | None | Avoid for sensitive data | Basic beacon |
| Display only | Passkey Entry (user types shown PIN) | Moderate | OK for moderate security | Fitness band with screen |
| Keyboard only | Passkey Entry (user enters random PIN) | Moderate | OK if strong PINs enforced | Bluetooth keyboard |
| Display + Yes/No button | Numeric Comparison | Strong | Recommended for most devices | Smartwatch |
| Display + Keyboard | Numeric Comparison, Passkey Entry | Strong | Use Numeric Comparison (easier UX) | Smartphone |
| NFC chip (any I/O) | Out-of-Band | Very Strong | Best for security-critical | Payment terminal, smart lock |
Pairing method fallback matrix:
When two devices with different I/O capabilities pair, the protocol selects the strongest mutually supported method:
| Device A | Device B | Resulting Method | Security |
|---|---|---|---|
| Display+Keyboard (phone) | Display+Yes/No (watch) | Numeric Comparison | Strong ✓ |
| Display+Keyboard | No I/O (beacon) | Just Works | None ✗ |
| NFC | Display+Keyboard | OOB | Very Strong ✓ |
| Display only | Keyboard only | Passkey Entry | Moderate |
| No I/O | No I/O | Just Works | None ✗ |
Design decision flowchart:
Start: What is your device?
Q1: Is data security-critical (locks, medical, payment)?
YES → Q2: Can you add NFC chip ($0.50 cost)?
YES → Use OOB (NFC)
NO → Q3: Can you add display + button?
YES → Use Numeric Comparison
NO → Add app-layer authentication or redesign
NO → Q4: Is it a public beacon (temperature, beacon)?
YES → Just Works acceptable
NO → Use Numeric Comparison (display + button)Real product examples:
| Product | I/O Added | Pairing Method | Cost Impact | Security Achieved |
|---|---|---|---|---|
| Yale Linus Lock | NFC chip | OOB | +$0.50/unit | Very Strong (tap to pair) |
| August Smart Lock | Physical button | OOB-like (button press + cloud) | +$0.20 | Strong (2-factor) |
| Fitbit Charge 5 | Display + touchscreen | Numeric Comparison | Already present | Strong |
| Tile Tracker | None (beacon) | Just Works | $0 | None (public data) |
| Medical Glucose Monitor | Display + 2 buttons | Numeric Comparison | +$1.50 | Strong (FDA required) |
Cost-benefit analysis for smart lock:
| Option | Hardware Cost | Development Cost | MITM Risk | Market Acceptance |
|---|---|---|---|---|
| Just Works (no addition) | $0 | $0 | 95% | Rejected by security reviewers |
| Add NFC chip | +$0.50 | +$5k firmware | ~0% | Accepted, premium positioning |
| Add button | +$0.20 | +$3k firmware | ~0% (with cloud auth) | Accepted |
Verdict: For a $150 smart lock, adding $0.50 NFC is justified by eliminating MITM vulnerability and enabling premium market positioning.
Common Mistake: Using a Fixed PIN for Passkey Entry Pairing
The error: A developer implements Passkey Entry pairing but hardcodes a static PIN (e.g., “000000” or “123456”) instead of generating a random 6-digit PIN for each pairing attempt.
What actually happens:
Code (WRONG - static PIN):
// BLE peripheral (lock)
#define PAIRING_PIN "123456" // HARDCODED - INSECURE
void onPairingRequest() {
esp_ble_gap_set_security_param(
ESP_BLE_SM_SET_STATIC_PASSKEY,
&PAIRING_PIN,
sizeof(PAIRING_PIN)
);
// Display "PIN: 123456" on lock screen
}Security implications:
- Attacker knows the PIN (common default PINs like 000000, 123456 tested first)
- No randomness = zero entropy = no MITM protection
- Effectively downgrades to Just Works security (known PIN = no verification)
Real-world exploit (observed in production smart locks):
A security researcher reverse-engineered a popular smart lock’s firmware and found: - Static PIN hardcoded: “000000” - Stored in plain text in firmware binary (found with strings firmware.bin | grep "000000") - Published as CVE-2021-XXXXX - Manufacturer forced to recall 50,000 units
Attack success rate with common static PINs:
| Static PIN | Frequency in wild | Attacker tries this | Cumulative success rate |
|---|---|---|---|
| 000000 | 15% | Attempt #1 | 15% |
| 123456 | 12% | Attempt #2 | 27% |
| 111111 | 8% | Attempt #3 | 35% |
| 654321 | 5% | Attempt #4 | 40% |
After trying top 10 common PINs: 60% of devices with static PINs compromised
The fix (correct implementation):
// Generate RANDOM 6-digit PIN for EACH pairing
uint32_t generate_random_pin() {
// Use hardware RNG (not rand()!)
uint32_t random = esp_random();
return 100000 + (random % 900000); // Range: 100000-999999
}
void onPairingRequest() {
uint32_t pin = generate_random_pin();
char pin_str[7];
sprintf(pin_str, "%06d", pin);
esp_ble_gap_set_security_param(
ESP_BLE_SM_SET_STATIC_PASSKEY,
&pin,
sizeof(pin)
);
// Display random PIN on lock screen
display_message("Pairing PIN:", pin_str);
Serial.printf("Pairing PIN: %s\n", pin_str);
}Security improvement:
- Random 6-digit PIN = 1,000,000 possibilities
- Attacker success rate: 1 / 1,000,000 = 0.0001% (vs 60% with static PIN)
- If pairing fails 3 times, lock out for 5 minutes (prevents brute force)
Additional mistake: Displaying PIN before pairing starts:
Some devices show the PIN continuously on an always-on display (even when not pairing). This allows an attacker to photograph the PIN from a distance, then initiate pairing later.
Correct UX flow:
- User presses “Pair” button on lock
- Lock generates random PIN
- Lock displays PIN for 60 seconds only
- After 60 seconds or successful pairing, PIN is discarded
- Next pairing gets a new random PIN
Production impact:
A Kickstarter smart lock project used a static PIN (“888888”) for “ease of testing” during development and forgot to replace it before shipping 3,000 units. A security researcher published the PIN on Twitter. The company had to: - Ship 3,000 physical PIN stickers (new random PIN printed per lock) - Provide firmware update requiring the sticker PIN to activate - Estimated cost: $45,000 (stickers + shipping + support)
Lesson: Never use static PINs for security. Always generate random PINs using hardware RNG, display only during pairing, and implement lockout after failed attempts.
Common Pitfalls
1. Using “Just Works” for Security-Sensitive Devices
Just Works pairing provides zero MITM protection — an attacker within BLE range can intercept the pairing handshake and bond as the legitimate central device. This is not a theoretical concern: security researchers have demonstrated 90-95% attack success rates against smart locks using Just Works. Always evaluate the sensitivity of the data or physical access being controlled: if the device unlocks a door, controls medication delivery, or stores personal data, Just Works is unacceptable. Use Numeric Comparison or OOB pairing instead, even if it requires adding a button or display to the hardware.
2. Hardcoding a Static Passkey Instead of Generating Random PINs
A common development shortcut is to hardcode a fixed passkey (e.g., “000000” or “123456”) for convenience during testing, then ship the same firmware to production. An attacker who reverse-engineers the firmware (trivial with open-source tools like binwalk and strings) immediately knows the PIN. The correct approach: use the hardware random number generator (esp_random() on ESP32, nrf_drv_rng on nRF52) to generate a fresh 6-digit PIN for each pairing attempt, display it only during the pairing window (60 seconds), and discard it afterwards. Never use rand() — it is not cryptographically secure.
3. Ignoring the IO Capability Negotiation Outcome
BLE pairing method selection is automatic: both devices exchange IO capability flags and the protocol selects the strongest mutually supported method. 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. Always explicitly set the IO capability flags in the security parameters to match the actual hardware. Verify the selected pairing method at runtime by logging the ESP_GAP_BLE_AUTH_CMPL_EVT callback parameters — never assume.
4. Storing Bond Keys Without Physical Tamper Protection
After successful pairing, the Long-Term Key (LTK) is stored in non-volatile storage (NVS flash on ESP32) so reconnections skip re-pairing. If an attacker gains physical access to the device and can read the flash (e.g., via JTAG debug port or direct chip read), they extract the LTK and can permanently impersonate the bonded central device. Mitigations: disable JTAG in production firmware, encrypt NVS with a device-unique key derived from hardware eFuses, and implement a factory-reset button that wipes bond storage. For high-security applications, consider not bonding at all and requiring re-pairing on every session.
16.12 What’s Next
Continue to Bluetooth Security: Encryption and Key Management to learn about:
| If you want to… | Read this |
|---|---|
| Understand BLE encryption architecture and key hierarchy | BLE Encryption & Key Management |
| See how BLE security fits into device security decisions | BLE Security Architecture |
| Implement secure BLE pairing in firmware | BLE Implementation Guide |