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.
Treat BLE security as a key lifecycle problem, not just an encryption switch.
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:
s1(AES-128) with TK, Mrand, and Srand. This provides basic protection but can be vulnerable if the temporary key has low entropy or the pairing exchange is captured.f5(AES-CMAC-128) with DHKey, nonces, and device addresses. P-256 ECDH protects the pairing exchange against passive eavesdropping.h6 and h7 based on AES-CMAC-128 to derive cross-transport keys from the BR/EDR link key and salt material.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:
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 short practical attack window into a much longer one. Production BLE devices should implement retry delays and lockout behavior for repeated failed pairing attempts.
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:
Scenario: 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:
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:
Key Insight: OOB pairing removes the primary remote MITM path, while application-layer authorization adds an independent barrier for dose commands. Neither layer alone is sufficient for a life-safety device, but together they provide defense-in-depth with manageable user friction.
This chapter covered BLE encryption and key management:
Prioritize these follow-up chapters based on the security question you need to answer next: