14 BLE Encryption: Secure Pairing

14.1 Start With the Decision

This section: Start With the Decision — A sensor with no screen still needs safe pairing, the step that connects it to an approved app.

A sensor with no screen still needs safe pairing, the step that connects it to an approved app. A device-specific QR code is a printed scan code; NFC is a close-range tap link. Either can carry pairing data through a protected out-of-band path. A short button window limits when pairing can start, but does not by itself prove who the peer is.

14.2 Route Overview

This section: Route Overview — This is part 2 of 2.

This is part 2 of 2. Review BLE Encryption: Key Management for the preceding evidence.

14.3 Learning Objectives

This section: Learning Objectives

• Test pitfall: using “just works” pairing because the device has no display with a concrete scenario and pass criteria.
• Validate deep dive: key lifecycle, privacy addresses, and signed data evidence with a concrete scenario and pass criteria.

14.4 Chapter Roadmap

This section: Chapter Roadmap

• Pitfall: Using “Just Works” Pairing Because the Device Has No Display
• Pitfall: Assuming Bonded Keys Are Secure Forever After Initial Pairing
• Knowledge Check
• Knowledge Check: Smart Lock Security Breach
• Knowledge Check: Bonding vs. Pairing Trade-offs
• Knowledge Check: Weak PIN Attack Vector
• Worked Example: Quantifying BLE Pairing Attack Surfaces
• Concept Relationships:
• Practice Activities
• Interactive Quiz: Match BLE Encryption Key Types
• Interactive Quiz: Sequence LE Secure Connections Key Generation
• See Also
• Diagram and Code Practice
• Label the Diagram
• Code Challenge
• Start With the Story
• Deep Dive: Key Lifecycle, Privacy Addresses, and Signed Data Evidence
• Summary
• What’s Next
• Key Takeaway

14.5 Knowledge Check

This section: Knowledge Check

14.6 Worked Example: Quantifying BLE Pairing Attack Surfaces

This section: Worked Example: Quantifying BLE Pairing Attack Surfaces

14.7 Practice Activities

This section: Practice Activities

14.8 See Also

This section: See Also

• Bluetooth Security: Labs and Defense-in-Depth - Hands-on security demonstrations
• Bluetooth Security: Pairing Methods - Choosing appropriate pairing for threat model
• Cryptography Fundamentals for IoT - AES and key exchange basics

14.9 Diagram and Code Practice

This section: Diagram and Code Practice

14.10 Start With the Story

This section: Start With the Story — Pairing is only the start of trust.

Pairing is only the start of trust. The long-term behavior depends on which keys are created, where they are stored, how identity is resolved, what gets encrypted, and what happens when a device is lost or reset.

Read this chapter as a key lifecycle record. Follow LTK, IRK, CSRK, ECDH, bonding, privacy, and revocation from first pairing through reconnection so the security design has an audit trail.

14.11 Deep Dive: Key Lifecycle, Privacy Addresses, and Signed Data Evidence

This section: Deep Dive: Key Lifecycle, Privacy Addresses, and Signed Data Evidence — Encryption is only part of the BLE security record.

Encryption is only part of the BLE security record. When pairing includes bonding, the devices persist a small key hierarchy, and each key supports a different claim:

The table names individual key roles; inspect Figure 14.1 to ask who owns each secret, what single job it performs, and how its trust ends.

+

Follow Figure 14.1 from key creation to setup, the key list, and safe use. A new key for each job limits what one lost key can allow. Key change or trust removal then leads to a checked delete and an audit record. A new owner or risk starts the loop again. For BLE bonds, the list should name the owner, job, state, store, and removal path for each LTK, IRK, and CSRK. Reset, sale, and support faults often come from old bond data, not from the AES cipher itself.

Resolvable Private Addresses make the IRK role concrete. A sensor can rotate its over-the-air address periodically so a passive scanner sees unrelated-looking identifiers, while a bonded gateway uses the stored IRK to resolve those addresses as the same trusted device. If the gateway database is restored without the bond table, increasing transmit power or changing the LTK will not help; the fix is restoring or re-establishing the IRK-bearing bond.

CSRK signed data is a different tradeoff. A peripheral can accept a write over an unencrypted link when the packet includes a signature computed with the CSRK and a monotonically increasing counter. The receiver checks the signature and rejects stale counters, which gives authenticity and replay protection, but not confidentiality. Use this only when the profile supports signed data and the command is not secret; medical readings, credentials, ownership changes, and other sensitive operations should bring up an encrypted LTK-protected link and still apply application authorization.

Bond deletion must remove all relevant keys. Keeping a stale LTK can preserve unwanted encrypted access, keeping a stale IRK can keep an old device recognizable, and keeping a stale CSRK can keep old signed commands trusted after the user thought the bond was gone.

14.12 Summary

This section: Summary

This chapter covered BLE encryption and key management:

• Encryption Architecture: AES-CCM-128 with 128-bit keys for LE links; compare LE Legacy and LE Secure Connections with the separate BR/EDR security path
• Key Hierarchy: In LE Legacy pairing, TK -> STK -> LTK, plus IRK for privacy and CSRK for signatures; legacy pairing uses EDIV+Rand to identify the LTK on reconnection. LE Secure Connections derives the LTK from ECDH
• LE Secure Connections: Introduced in BLE 4.2, uses P-256 ECDH to prevent passive eavesdropping of the pairing exchange; LTK and MacKey derived via the f5 function
• Security Decision Framework: Match pairing method to data sensitivity and device capabilities
• Best Practices: Use secure key storage, implement authorization layers, plan for revocation
• Common Pitfalls: OOB alternatives for displayless devices, defense-in-depth beyond initial pairing

14.13 What’s Next

This section: What’s Next

Prioritize these follow-up chapters based on the security question you need to answer next:

• Hands-on BLE security labs: bt-security-labs-defense-review.html to apply key concepts in ESP32 BLE security demonstrations and attack/defense scenarios.
• Pairing methods in depth: bt-security-pairing-methods.html to compare Just Works, Passkey, Numeric Comparison, and OOB with threat-model analysis.
• Cryptography foundations: ../cryptography/encryption-principles-and-crypto-basics.html to review AES-CCM, ECDH, and the primitives underlying BLE key generation.
• IoT authentication patterns: ../authentication/authentication-access-control-index.html to extend BLE pairing security with application-layer identity and authorization.
• IoT threat landscape: ../security-threats/threats-introduction.html to place BLE attack vectors in the broader context of IoT security risks.

14.14 Key Takeaway

This section: Key Takeaway — Bluetooth encryption is only as strong as key generation, pairing method, storage, and renewal behavior.

Bluetooth encryption is only as strong as key generation, pairing method, storage, and renewal behavior. Protect long-term keys and choose pairing modes that match the threat model and device interface.

14.15 Continue Your Route

This section: Continue Your Route — This is the last part of this chapter.

This is the last part of this chapter. Return to BLE Encryption: Key Management or continue from the bluetooth-ble module index.