16  Bluetooth Security: Pairing Methods

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

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.

Pairing Method Selection Checklist

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.

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)

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.

16.4 BLE Pairing Methods Comparison

BLE supports four pairing methods with different security levels:

16.4.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.

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:

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

Alternative View: Pairing Security as Defense Layers

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

Figure 16.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.

16.6 BLE Pairing Process

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

Figure 16.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

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)

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.

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

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.”

16.8.1 Knowledge Check: BLE Pairing Methods

16.8.2 Knowledge Check: Bonding Security

16.8.3 Knowledge Check: Pairing Method Selection

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.

viewof numAttempts = Inputs.range([1, 100], {
  value: 10,
  step: 1,
  label: "Attacker Pairing Attempts"
})

viewof numDevices = Inputs.range([1, 1000], {
  value: 100,
  step: 10,
  label: "Devices in Deployment"
})

{
  const codeSpace = 1000000; // 6-digit code
  const justWorksRate = 0.75; // illustrative: timing race is the main barrier
  const pNumericPerAttempt = 1 / codeSpace;
  const pOobPerAttempt = 0.000001; // effectively 0

  // Per-device success over N attempts
  const pJustWorks = 1 - Math.pow(1 - justWorksRate, numAttempts);
  const pNumeric = 1 - Math.pow(1 - pNumericPerAttempt, numAttempts);
  const pOob = 1 - Math.pow(1 - pOobPerAttempt, numAttempts);

  // Fleet-wide: expected devices compromised
  const fleetJW = Math.min(numDevices * pJustWorks, numDevices);
  const fleetNC = numDevices * pNumeric;
  const fleetOOB = numDevices * pOob;

  const color1 = "#2C3E50";
  const colorJW = "#E74C3C";
  const colorNC = "#16A085";

  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 1.2rem; font-family: Arial, sans-serif;">
    <h4 style="margin: 0 0 1rem 0; color: ${color1};">Illustrative per-device MITM risk (${numAttempts} attempts)</h4>
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 1rem; margin-bottom: 1rem;">
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${colorJW};">
        <div style="font-size: 0.85rem; color: #666;">Just Works</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${colorJW};">${(pJustWorks * 100).toFixed(1)}%</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid #E67E22;">
        <div style="font-size: 0.85rem; color: #666;">Numeric Comparison</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: #E67E22;">${(pNumeric * 100).toFixed(6)}%</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${colorNC};">
        <div style="font-size: 0.85rem; color: #666;">Out-of-Band (NFC)</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${colorNC};">${(pOob * 100).toFixed(8)}%</div>
      </div>
    </div>
    <h4 style="margin: 1rem 0; color: ${color1};">Illustrative fleet exposure (${numDevices} devices)</h4>
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 1rem; margin-bottom: 1rem;">
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${colorJW};">
        <div style="font-size: 0.85rem; color: #666;">Just Works</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${colorJW};">${fleetJW.toFixed(0)} devices</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid #E67E22;">
        <div style="font-size: 0.85rem; color: #666;">Numeric Comparison</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: #E67E22;">${fleetNC.toFixed(6)} devices</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${colorNC};">
        <div style="font-size: 0.85rem; color: #666;">Out-of-Band (NFC)</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${colorNC};">${fleetOOB.toFixed(8)} devices</div>
      </div>
    </div>
    <div style="font-size: 0.8rem; color: #666;">Just Works has no cryptographic user verification, so this model treats each setup attempt as a timing race. Numeric Comparison uses a 6-digit check value. OOB adds a separate physical or visual channel.</div>
  </div>`;
}

Interactive: BLE Pairing and Key Exchange Animation

16.9 Pairing Failure Patterns

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.

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.

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.

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.

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

Label the Diagram

Code Challenge

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
• Product consequences: weak setup flows are expensive to repair after release, so match pairing method to threat model before shipping

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. Compare the security behavior of Just Works versus Numeric Comparison pairing.

Just Works pairing:

In Just Works mode, there is zero user-authenticated verification. If an attacker wins the setup timing race, the protocol does not give the user a number, passkey, or OOB proof to compare.

Attack steps:

1. Legitimate lock advertises: “Smart Lock 123 ready to pair”
2. User opens app to pair
3. Attacker (within range) sends pairing request first
4. Lock accepts (no verification step)
5. Attacker now has bonded keys (LTK)

Why this is dangerous: The defense depends on setup timing, app UX, and physical controls rather than a cryptographic user-verification step.

Numeric Comparison pairing:

Both devices display a 6-digit code. User verifies they match.

Attack scenario:

1. Lock displays code: 481923
2. User’s phone displays: 481923
3. Attacker MITM position displays: 775204 (different code)
4. 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 repeated attempts:

• Attacker tries 10 times (user may suspect after repeated failures)
• Success probability: 10 / 1,000,000 = 0.001% (essentially zero)

Conclusion: Just Works provides no protocol-level MITM detection. Numeric Comparison adds a user-visible check that makes an undetected MITM require guessing the same 6-digit value during setup.

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: no user-verification challenge to guess or compare

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

Use this order when selecting a pairing method:

1. If an OOB channel exists, use it for security-sensitive setup. NFC, QR, wired provisioning, or a short-lived setup token can prove physical presence.
2. If both devices can display and confirm, use Numeric Comparison under LE Secure Connections.
3. If one device displays and the other can enter digits, use Passkey Entry with a fresh random passkey for each pairing attempt.
4. If neither device can verify the user, Just Works is the protocol fallback. Use it only for low-risk public data, or add another control before release.

Typical outcomes:

• A phone paired with a watch that has a display and Yes/No control should use Numeric Comparison.
• A phone paired with an NFC-enabled lock should use OOB setup.
• A phone paired with a basic beacon may fall back to Just Works, but the beacon should not expose sensitive commands.
• A safety-critical displayless device should add a physical setup button, OOB tag, account claim, or commissioning station.

Common Mistake: Using a Fixed PIN for Passkey Entry Pairing

The error: A developer implements Passkey Entry pairing but hardcodes a static PIN instead of generating a fresh 6-digit passkey for each pairing attempt.

What actually happens:

• The same passkey works for every unit or every pairing attempt.
• Attackers try common default values first.
• 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.

The fix (correct implementation):

• Generate a fresh 6-digit passkey from a hardware-backed random source for each pairing attempt.
• Display the passkey only while the user has intentionally started pairing.
• Expire the passkey after a short setup window or after successful pairing.
• 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.

Security improvement:

• Random 6-digit PIN = 1,000,000 possibilities
• Attacker success rate for one random guess: 1 / 1,000,000 = 0.0001%
• 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:

1. User presses “Pair” button on lock
2. Lock generates random PIN
3. Lock displays PIN for 60 seconds only
4. After 60 seconds or successful pairing, PIN is discarded
5. Next pairing gets a new random PIN

Lesson: Do not ship static passkeys for security. Generate random passkeys, display them only during intentional pairing, and implement lockout after failed attempts.

Interactive Quiz: Match Pairing Concepts

Interactive Quiz: Sequence the Steps

Common Pitfalls

1. Using “Just Works” for Security-Sensitive Devices

Just Works pairing provides zero MITM protection: an attacker within BLE range can participate in the setup exchange and bond as the trusted central device if no other setup control is present. Evaluate the sensitivity of the data or physical access being controlled. If the device unlocks a door, controls medication delivery, or stores personal data, use Numeric Comparison, OOB pairing, or another setup proof instead of relying on Just Works alone.

2. Hardcoding a Static Passkey Instead of Generating Random PINs

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. Do not use a general-purpose pseudo-random function for security decisions.

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:

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

• Bluetooth Security: Encryption and Key Management: learn how LTK, IRK, CSRK, AES-CCM, and LE Secure Connections support the pairing method you selected here.
• Bluetooth Security: Labs and Defense-in-Depth: apply pairing decisions in ESP32 security demonstrations and layered BLE defenses.
• Bluetooth Comprehensive Review: test your Bluetooth security understanding with integrated case studies and assessment questions.