BLE encryption uses AES-CCM with 128-bit keys, but the real security depends on how those keys are generated during pairing. The key hierarchy flows from Temporary Key (TK) to Short Term Key (STK) to Long Term Key (LTK), with IRK for address privacy and CSRK for data signing. Always match your pairing method to data sensitivity: “Just Works” for public data only, Numeric Comparison for personal data, and Out-of-Band (OOB) for medical, financial, or industrial applications.
By the end of this chapter, you will be able to:
Bluetooth encryption protects data by scrambling it so that only devices with the right key can read it. Think of encryption keys as the secret decoder ring that two devices share during pairing. Without the key, intercepted Bluetooth data looks like random noise to an eavesdropper.
“Bluetooth uses a whole family of keys to keep data safe!” Sammy the Sensor said. “It starts with a Temporary Key during pairing, which creates a Short Term Key, which eventually becomes a Long Term Key. It is like getting a day pass, then a weekly pass, then a permanent membership card!”
“Think of the key hierarchy like layers of security at a castle,” Lila the LED suggested. “The outer wall is the Temporary Key. The inner wall is the Short Term Key. And the treasure vault uses the Long Term Key. Each layer makes it harder for intruders to get through!”
Max the Microcontroller explained, “There are also special-purpose keys. The IRK – Identity Resolving Key – lets me change my Bluetooth address periodically so trackers cannot follow me around. And the CSRK – Connection Signature Resolving Key – lets me verify that messages really came from a trusted device and were not tampered with.”
“The most important thing,” Bella the Battery said, “is that stronger encryption methods do not necessarily use more power. AES-CCM encryption with 128-bit keys is built into the Bluetooth hardware, so it runs efficiently. The real energy cost is in the pairing process itself, and once that is done, secure communication barely affects my battery life at all!”
Before diving into this chapter, you should be familiar with:
BLE supports multiple encryption architectures depending on the pairing method and Bluetooth version. The diagram below shows the key generation process for Legacy Pairing, LE Secure Connections, and BR/EDR Secure Connections.
Key Generation Methods:
| Method | Key Function | Input Parameters | Security Level |
|---|---|---|---|
| LE Legacy | s1(AES-128) | TK, Mrand, Srand | Basic (vulnerable to passive eavesdropping) |
| LE Secure Connections | f5(AES-CMAC-128) | DHKey, N1, N2, Addresses | Strong (ECDH with P-256 curve protection) |
| BR/EDR Secure | h6/h7(AES-CMAC-128) | Link Key, SALT | Strong (cross-transport key derivation) |
Understanding the BLE key hierarchy is essential for implementing secure IoT applications:
Key Types Explained:
Use “Just Works” ONLY when:
Use Passkey Entry when:
Use Numeric Comparison when:
Use Out-of-Band (OOB) when:
| Method | Auth Bits | MITM Protection | User Action | Best Use Case |
|---|---|---|---|---|
| Just Works | 0 | None | None | Public beacons only |
| Passkey Entry | ~20 (6-digit PIN) | If passkey is secret | Enter PIN | Keyboards, mice |
| Numeric Comparison | ~20 + visual | Strong (if user verifies) | Verify code | Smartphones, tablets |
| Out of Band (OOB) | Varies | Strong (if OOB channel is secure) | NFC tap / QR scan | Smart locks, commissioning |
Numbers explained:
The brute-force attack time against a passkey depends on entropy and attack rate:
\[T_{attack} = \frac{2^{entropy}}{R_{attempts}} \times 0.5\]
where \(R_{attempts}\) is the number of pairing attempts per second (factor 0.5 assumes average case).
Example: A 6-digit PIN (000000-999999) provides: - Entropy: \(\log_2(1,000,000) = 19.93\) bits - If attacker attempts 10 pairings/second: \(T_{attack} = \frac{2^{19.93}}{10} \times 0.5 = \frac{1,000,000}{10} \times 0.5 = 50,000\) seconds ≈ 13.9 hours
For LE Secure Connections with rate limiting (1 attempt per 30 seconds after 3 failures): - Effective rate: 0.033 attempts/second - \(T_{attack} = \frac{1,000,000}{0.033} \times 0.5 \approx 15,000,000\) seconds ≈ 174 days
Rate limiting transforms a 14-hour attack into a 174-day attack, making brute force impractical. This is why BLE devices MUST implement retry delays.
| Data Sensitivity | Minimum (Link-Layer) | Recommended Controls | Example |
|---|---|---|---|
| Public | None (if acceptable) | Avoid pairing; sign data if integrity matters | Weather beacon |
| Personal | AES-CCM-128 (encrypted link) | LE Secure Connections + bonding + privacy addresses | Fitness tracker |
| Medical / safety | AES-CCM-128 (encrypted link) | Authenticated pairing (Numeric Comparison/OOB), secure firmware updates, strong device identity | Glucose monitor |
| Financial / high-value | AES-CCM-128 (encrypted link) | OOB pairing where possible, hardened key storage, end-to-end authn/authz | Payment terminal |
| Industrial / control | AES-CCM-128 (encrypted link) | Application-layer integrity/authentication, logging, and lifecycle key management | Factory sensor |
Note: Compliance requirements vary by jurisdiction and product. Link-layer encryption is important, but it is not sufficient on its own for most regulated systems.
Do:
Don’t:
The Mistake: Implementing “Just Works” pairing for displayless IoT devices (sensors, beacons, smart plugs) because “there’s no way to show a PIN,” leaving devices permanently vulnerable to MITM attacks during every pairing attempt.
Why It Happens: Developers assume display-based verification (Numeric Comparison, Passkey) is the only option for secure pairing.
The Fix: Use Out-of-Band (OOB) pairing with a physical channel that attackers cannot intercept:
The Mistake: Pairing a BLE device once with strong security (Numeric Comparison or OOB), then assuming the bonded connection is permanently secure - without protecting stored keys or implementing re-authentication for sensitive operations.
Why It Happens: Developers focus security effort on the initial pairing ceremony, but forget that Long Term Keys (LTK) stored in flash memory can be extracted, cloned, or used by anyone with physical access to either device.
The Fix: Implement defense-in-depth beyond pairing: protect key storage, add application-layer authorization, and consider periodic re-authentication:
// Defense layer 1: Secure key storage
// Use hardware-backed keystore when available (iOS Keychain, Android Keystore,
// secure elements on embedded devices)
// Defense layer 2: Application-layer authorization for sensitive commands
typedef enum {
CMD_READ_SENSOR, // Low risk: allow after BLE connection
CMD_UNLOCK_DOOR, // High risk: require app PIN + recent auth
CMD_FACTORY_RESET, // Critical: require physical button + app confirmation
CMD_FIRMWARE_UPDATE // Critical: require signed payload + user consent
} command_security_t;
bool authorize_command(command_t cmd, auth_context_t *ctx) {
switch (get_security_level(cmd)) {
case LOW:
return ctx->ble_authenticated; // BLE pairing sufficient
case HIGH:
return ctx->ble_authenticated &&
ctx->app_pin_verified &&
(time_now() - ctx->last_auth_time) < 300; // 5-min timeout
case CRITICAL:
return ctx->physical_button_pressed &&
ctx->app_confirmation_received;
}
}
// Defense layer 3: Key rotation and revocation
// - Implement "forget this device" that deletes LTK on both sides
// - Consider periodic re-pairing for high-security applications
// - Log pairing events for security auditingScenario: A startup launches a Bluetooth smart lock for Airbnb hosts. During beta testing, security researchers demonstrate they can unlock any door during the initial pairing process by sitting in a car 20 meters away with a laptop. The lock uses “Just Works” pairing for “convenience” - no PIN entry required.
Think about:
Key Insight: Authentication happens BEFORE encryption. “Just Works” provides:
Secure redesign options:
Scenario: You’re managing a fleet of 100 Bluetooth-connected medical devices (insulin pumps) in a hospital. Nurses complain that re-pairing tablets to pumps every shift change (3x/day) wastes 5 minutes per device. IT Security insists that bonding is disabled because “stored keys are a security risk if tablets are lost or stolen.”
Think about:
Key Insight: Bonding = convenience vs. security trade-off, but can be mitigated:
With Bonding (SECURE implementation):
Scenario: A device uses LE Legacy pairing and relies on a short, printed passkey/PIN (“unique per device”) for security. The team assumes “it’s encrypted, so it’s safe.”
Think about:
Key Insight: Strong ciphers don’t help if key agreement/authentication is weak.
Risk framing (order-of-magnitude):
Safer alternatives:
A medical device manufacturer is designing a BLE-connected insulin pump. The pump communicates with a companion smartphone app to receive bolus dose commands. The design team must choose the appropriate BLE security level.
Threat Analysis – What Happens If Pairing is Compromised?
An attacker who performs a MITM during pairing becomes the bonded device. They can then issue insulin dose commands. This is a life-safety risk.
Quantifying Attack Windows by Pairing Method:
| Pairing Method | Attack Type | Effort Required | Time Window |
|---|---|---|---|
| Just Works | Active MITM with commodity hardware | $20 BLE sniffer + laptop | Entire pairing duration (~5 sec) |
| Passkey (6-digit) | Brute-force captured pairing exchange (Legacy only) | Offline in <1 sec (1M combinations) | Must capture pairing exchange |
| Numeric Comparison | Social engineering user to accept wrong code | Must be present + fool user | 10-sec user verification window |
| OOB (NFC tap) | Must physically intercept NFC (<4 cm) | Must be within 4 cm of both devices | Sub-second NFC exchange |
Why OOB + Application-Layer Auth is the Right Answer:
OOB pairing via NFC: The nurse taps the pump to the phone. An attacker must be physically within 4 cm – essentially impossible without being noticed in a clinical setting.
Application-layer dose verification: Even after pairing, the app signs each dose command with the user’s PIN. The pump verifies the signature before executing. An attacker who somehow bonds still cannot issue a valid dose command without the clinician’s PIN.
Key rotation: The pump re-pairs weekly. Compromised keys expire automatically.
Cost of Each Security Layer:
| Layer | Implementation Cost | User Inconvenience | Risk Reduction |
|---|---|---|---|
| OOB pairing (NFC) | +$0.50 NFC chip on pump | One-time tap per pairing | Eliminates remote MITM |
| App-layer PIN | Software only | 4-digit PIN per dose | Eliminates unauthorized commands |
| Weekly re-pairing | Software only | ~10 sec/week NFC tap | Limits key compromise window to 7 days |
| Combined | $0.50 hardware + software | ~15 sec/week | Defense-in-depth |
Key Insight: The $0.50 NFC chip eliminates the primary attack vector (remote MITM during pairing). Application-layer authorization adds a second independent barrier. Neither layer alone is sufficient for a life-safety device, but together they provide defense-in-depth at minimal cost and user friction.
| Concept | Relates To | Why It Matters |
|---|---|---|
| Key Hierarchy (TK→STK→LTK) | Bonding | Session keys (STK) vs stored keys (LTK) determine reconnection security |
| Pairing Methods | Key Generation | Authentication strength during pairing determines overall encryption security |
| IRK (Identity Resolving Key) | Privacy | Enables private address rotation to prevent tracking |
| CSRK (Signature Key) | Data Integrity | Signs unencrypted data for authenticity verification |
| AES-CCM-128 | Link Encryption | 128-bit encryption standard protects all post-pairing traffic |
| P-256 ECDH | LE Secure Connections | Elliptic curve key exchange introduced in BLE 4.2 to prevent passive eavesdropping of pairing |
This chapter covered BLE encryption and key management:
| Topic | Chapter | Why It Matters |
|---|---|---|
| Hands-on BLE security labs | Bluetooth Security: Labs and Defense-in-Depth | Apply key concepts in ESP32 BLE security demonstrations and attack/defense scenarios |
| Pairing methods in depth | Bluetooth Security: Pairing Methods | Compare Just Works, Passkey, Numeric Comparison, and OOB with threat model analysis |
| Cryptography foundations | Encryption Principles and Crypto Basics | Understand AES-CCM, ECDH, and the primitives underlying BLE key generation |
| IoT authentication patterns | Authentication and Access Control | Extend BLE pairing security with application-layer identity and authorization |
| IoT threat landscape | IoT Security Threats Overview | Place BLE attack vectors in the broader context of IoT security risks |