# Bluetooth LE and PQC **Source**: https://quantumsequrity.com/blog/bluetooth-le-pqc **Category**: Industry & Use Cases --- [← Back to Blog](../../blog.html) Industry & Use Cases # Bluetooth LE and PQC 11 min read Bluetooth is everywhere. Wireless earbuds, smartwatches, fitness trackers, car infotainment, hearing aids, smart locks, medical devices, industrial sensors. The Bluetooth Special Interest Group (SIG) reports that more than five billion Bluetooth devices ship every year. The protocol stack used in most of these devices is Bluetooth Low Energy (BLE), introduced in Bluetooth 4.0 and now at version 5.4. BLE is designed for very low power consumption, which means it runs on tiny batteries (some devices for years), with constrained CPUs, limited memory, and limited radio bandwidth. Bluetooth security has had a rough history. The original Bluetooth Classic pairing was famously weak. Bluetooth 4.2 added LE Secure Connections using elliptic curve Diffie-Hellman on the NIST P-256 curve, which significantly improved the security baseline. But P-256 is exactly the kind of elliptic curve cryptography that Shor's algorithm breaks, and BLE's constraints make it one of the harder protocols to migrate to post-quantum cryptography. ## How BLE Pairing Works Today When two BLE devices want to talk securely, they pair. The pairing process establishes a shared secret that both devices use to derive session keys for subsequent encryption. Bluetooth 4.0 and 4.1 used "Legacy Pairing" which had known weaknesses. Bluetooth 4.2 introduced LE Secure Connections (LESC), which uses ECDH P-256 for the initial key exchange. The basic flow is: 1. Each device generates an ephemeral P-256 key pair 2. Devices exchange public keys 3. Each device computes the shared secret using its private key and the other side's public key 4. Both sides derive a Long Term Key (LTK) from the shared secret 5. The LTK is used to derive session keys for encrypting subsequent communications LESC also includes authentication options to prevent man-in-the-middle attacks: numeric comparison, passkey entry, or out-of-band (OOB) data exchange. The exact authentication method depends on the I/O capabilities of the devices. For PQC, the vulnerable surface is the ECDH P-256 step. An attacker who records BLE pairing traffic today and runs it through a future quantum computer can recover the shared secret and decrypt all subsequent BLE traffic between those devices. ## Why BLE Is Hard to Migrate Three constraints make BLE PQC migration harder than most other protocols. **Low power**. BLE is designed to run on coin cell batteries for months or years. Every additional joule of compute matters. ML-KEM-768 on a Cortex-M4 microcontroller takes 5 to 15 milliseconds and consumes meaningful energy compared to a P-256 ECDH which is measured in milliseconds with hardware acceleration. **Low compute**. BLE peripherals often run on Cortex-M0 or Cortex-M0+ microcontrollers with 32 to 256 KB of RAM. ML-KEM-768 requires roughly 4 to 8 KB of RAM during operation, which is a significant fraction of the available memory on these chips. **Limited bandwidth**. BLE has small advertising packets (31 bytes typically, 255 bytes in extended advertising) and small data PDU sizes (default 27 bytes, up to 251 bytes with Data Length Extension). ML-KEM-768 public keys are 1184 bytes and ciphertexts are 1088 bytes. These do not fit in single BLE packets and require fragmentation across multiple packets, which increases pairing time and energy cost. ## What the Bluetooth SIG Is Doing The Bluetooth SIG has been tracking PQC developments. The SIG's Security Working Group has been studying how to evolve LESC for post-quantum security. The current direction includes: 1. A future Bluetooth specification revision that adds PQ-LESC using ML-KEM 2. Hybrid pairing modes that combine ECDH P-256 with ML-KEM during the transition 3. Optimizations to fit PQC artifacts into BLE's bandwidth constraints There is no firm timeline for when PQ-LESC will be normative. Realistically, the spec work is likely to land in Bluetooth 6.x specifications between 2026 and 2028, with consumer devices supporting it by 2028 to 2030. ## The Pairing Bandwidth Problem A typical LESC pairing today exchanges public keys (about 64 bytes for P-256) plus a few authentication messages, totaling around 100 to 200 bytes per direction. With BLE 5.x and Data Length Extension, this fits in a few PDUs and completes in a few hundred milliseconds. A PQC pairing using ML-KEM-768 would exchange public keys (1184 bytes) and ciphertexts (1088 bytes), totaling around 2.5 KB per direction. This requires roughly 10 to 20 BLE PDUs depending on PDU size, taking the pairing time from a few hundred milliseconds to several seconds. For some BLE applications, this is acceptable (pairing is rare). For others (proximity-based applications that pair frequently), it is a serious user experience problem. The SIG is evaluating whether to use ML-KEM-512 for BLE, which has smaller artifacts (800-byte public keys, 768-byte ciphertexts) at the cost of lower security margin. For more on the algorithmic background, see [ML-KEM explained](ml-kem-explained.html). ## Hybrid Pairing as the Bridge The realistic migration path is hybrid pairing. New BLE devices will support hybrid LESC that combines ECDH P-256 with ML-KEM-512 or ML-KEM-768 in parallel. Old devices will continue to use ECDH-only LESC. The pairing protocol negotiates capabilities and uses the strongest mode supported by both sides. This is the same pattern as TLS hybrid migration. The protocol-level discussion is about how to encode capability advertisement, how to combine the two shared secrets, and how to ensure forward security if either algorithm is broken in the future. For details on the hybrid approach generally, see [hybrid encryption](hybrid-encryption.html). ## Authentication Methods and PQC LESC supports four authentication methods: - **Just Works**: No authentication, vulnerable to MITM. Used when neither device has I/O capability. - **Numeric Comparison**: Both devices display a 6-digit number; user confirms they match. - **Passkey Entry**: One device displays a 6-digit number, user enters it on the other. - **Out-of-Band (OOB)**: Authentication data exchanged via another channel (NFC, QR code). For PQC, these authentication methods do not directly use public-key cryptography. They authenticate the ECDH shared secret by binding a hash of the public keys to the user's confirmation step. As long as the underlying key exchange is secure, the authentication works. When LESC migrates to PQ-LESC, the same authentication methods will continue to work. The public keys hashed into the authentication confirmation will be larger (PQC public keys are bigger), but the user-facing experience is unchanged. ## Long Term Keys and Session Keys After pairing, BLE devices store a Long Term Key (LTK) that they reuse for subsequent connections. The LTK is encrypted at rest on each device and protected by device-level security (TPM-equivalent hardware on smartphones, secure key storage on peripherals). When the devices reconnect, they don't repeat the full pairing. They use the LTK to derive session keys directly. This is much faster than re-pairing and is what most BLE traffic actually uses. For PQC, the LTK itself is symmetric (typically 128 bits). It is quantum-resistant against Grover's algorithm in the relevant sense. The vulnerability is the original pairing that established the LTK; if that pairing was vulnerable to quantum attack, the LTK is recoverable. This is one reason why the Bluetooth migration timeline is generous: even after PQC pairing is standardized, deployed devices with classical-pairing-derived LTKs continue to use those LTKs for years. The migration only affects new pairings. ## BLE in Medical and Industrial Devices BLE is widely used in medical devices: hearing aids, glucose monitors, insulin pumps, pacemakers (for telemetry, not for life-critical commands), patient monitoring equipment. These devices have strict regulatory requirements (FDA, MDR in Europe) and long lifecycles (5 to 15 years). For medical PQC, the harvest-now-decrypt-later threat is significant because patient data has long-term sensitivity. A patient's glucose readings from 2025 might be HIPAA-protected forever (or until the patient dies plus the appropriate retention period). PQC migration in medical BLE devices is therefore a priority for newer products. The challenge is regulatory. Updating cryptographic algorithms in a medical device requires re-validation against the original safety case. This adds 12 to 24 months to any PQC migration in medical BLE. For more general medical PQC context, see our other industry articles. ## BLE Mesh Bluetooth Mesh is a separate specification (Bluetooth Mesh Profile 1.1) that builds a multi-hop mesh network on top of BLE. It is used in commercial lighting, building automation, sensor networks, and similar applications. BLE Mesh has its own security model with provisioning (initial trust establishment) using ECDH P-256, plus session-level encryption using AES-CCM. The provisioning step is the PQC migration target, similar to LESC pairing. The data-plane encryption with AES-CCM is quantum-resistant in the symmetric sense. For BLE Mesh PQC, the considerations are similar to standard BLE: bandwidth, energy, and compute constraints make ML-KEM migration challenging. The longer device lifecycles in commercial mesh deployments (10 to 20 years) make migration more important. ## Bluetooth Classic vs LE Bluetooth Classic (BR/EDR) is the older variant used for higher-bandwidth applications like audio streaming. It has its own security model that is also based on ECDH P-256 in modern versions. PQC migration for Bluetooth Classic faces similar challenges to BLE but with somewhat more bandwidth headroom. Most new Bluetooth audio products are migrating to LE Audio (introduced in Bluetooth 5.2), which uses BLE rather than Bluetooth Classic. So the long-term security migration target is BLE, with Bluetooth Classic gradually being deprecated. ## Wearables and Hearables Smartwatches, wireless earbuds, and other wearables present a particular PQC challenge. They have very limited compute, very limited battery, and they pair frequently throughout the day (a typical smartwatch reconnects to a phone many times per day depending on connectivity behavior). Each reconnection uses the cached LTK, but periodic re-pairing (after a factory reset, a phone change, or a device update) goes through the full LESC flow. For PQC, wearables benefit from the cached-LTK pattern: most reconnections are fast and use existing keys. The slow PQ pairing only happens occasionally. The energy cost of occasional PQ pairing is acceptable for most wearables. Hearing aids are a special case. They are medical devices with regulatory requirements (FDA Class II in the US, MDR Class IIa in Europe). They are also typically paired with a single phone for years and rarely re-pair. PQC migration in hearing aids is therefore mostly about the initial pairing security, with a long horizon for production deployment. ## Bluetooth in Vehicles Modern vehicles use Bluetooth extensively: phone calls, audio streaming, navigation app integration, vehicle key (in some systems), and over-the-air update transport. The Bluetooth stack in a car is often part of a larger telematics or infotainment system with its own security boundary. For PQC, vehicle Bluetooth has long lifetimes (cars are operated for 10 to 15+ years) and limited update capability. Some manufacturers offer over-the-air updates that can refresh Bluetooth firmware; others do not. PQC support in new vehicles will arrive as the underlying Bluetooth specifications add it, which is several years out. Digital car keys based on Bluetooth (CCC Digital Key, Apple CarKey via Bluetooth) have additional security requirements. The Car Connectivity Consortium (CCC) is tracking PQC and is expected to publish PQC-aware specifications in line with the broader Bluetooth migration. ## Frequently Asked Questions **Will my Bluetooth earbuds need to be replaced for PQC?** No, not for the foreseeable future. Existing earbuds will continue to work with their current pairing keys. New earbuds in 2027 to 2030 may support hybrid PQ pairing for new pairings going forward. **Is BLE pairing actually a quantum target?** For most users, no. The threat would require an attacker to be in radio range during pairing, record the traffic, and have access to a future quantum computer. For most home and office BLE devices, this is not a credible threat. For high-value targets (executives, journalists, government workers), it may be relevant. **What about smart home BLE devices?** Smart locks, smart bulbs, smart appliances using BLE are similar to other BLE devices. New devices from 2027 onwards may support hybrid PQC pairing. Old devices continue to use classical pairing. **Does PQC affect BLE battery life?** Pairing is infrequent, so the energy cost of PQC pairing has minimal impact on battery life. Steady-state BLE traffic uses AES-CCM, which is unchanged. **What is the timeline for PQ-Bluetooth?** The Bluetooth SIG is studying PQC integration. Realistic specification work is targeting 2026 to 2028, with consumer device support starting around 2028 to 2030. This is later than TLS or 5G PQC migration because BLE's constraints are tighter and the threat priority is lower for most use cases. ## Sources - Bluetooth Core Specification 5.4, https://www.bluetooth.com/specifications/specs/core-specification-5-4/ - Bluetooth LE Secure Connections (Vol 3, Part H, Section 2.3), Bluetooth Core Specification - Bluetooth Mesh Profile 1.1, https://www.bluetooth.com/specifications/specs/mesh-profile-1-1/ - NIST FIPS 203, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", https://csrc.nist.gov/pubs/fips/203/final - IETF RFC 7748, "Elliptic Curves for Security" (Curve25519), https://www.rfc-editor.org/rfc/rfc7748.html - IEEE 802.15.1, "Wireless Personal Area Networks", https://standards.ieee.org/ieee/802.15.1/3018/ ## Related Articles - [What is Post-Quantum Cryptography?](what-is-post-quantum-cryptography.html) - [ML-KEM Explained](ml-kem-explained.html) - [Hybrid Encryption](hybrid-encryption.html) - [PQC IoT Smart Home Devices](pqc-iot-smart-home-devices.html) - [Harvest Now Decrypt Later](harvest-now-decrypt-later.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)