12.04 · Wireless & IoT

Bluetooth Security

Two protocols, four pairing modes, a half-dozen named attacks. Your earbuds, badge reader, and car key all rely on getting this right.

"Bluetooth" is two protocols sharing a name and a frequency band. Bluetooth Classic (BR/EDR) is the older one, used for streaming audio and high-throughput tethering. Bluetooth Low Energy (BLE) is the newer one, used for everything that's battery-constrained: wearables, sensors, beacons, smart locks, medical devices. They share the 2.4 GHz band but their stacks, pairing flows, and security models are entirely different — and most attacks are specific to one or the other.

Classic vs BLE

Bluetooth Classic (BR/EDR)

Released: 1999. Used by headsets, speakers, keyboards (older), tethering, file transfer.

Range: 10-100 m depending on power class.

Throughput: up to ~3 Mbps (EDR).

Discovery: Inquiry/page model; devices alternate between "discoverable" and "not." MAC visible while paired.

Security: Secure Simple Pairing (SSP) since v2.1 using ECDH. Per-link encryption keys derived per pairing.

Bluetooth Low Energy (BLE)

Released: 2010 (v4.0). Designed from scratch for battery-powered sensors, wearables, beacons, IoT.

Range: 10-50 m typical; long-range mode (5.0) up to several hundred meters.

Throughput: ~1 Mbps (2 Mbps in 5.0). Optimized for short, infrequent bursts.

Discovery: Advertising channels; devices broadcast advertisements that any scanner can read. MACs typically randomized.

Security: LE Secure Connections since v4.2 (ECDH-based). Earlier "LE Legacy" pairing was weak; still found in cheap devices.

"Bluetooth 5.x" usually refers to the BLE side — the spec keeps adding capabilities to BLE (long range, mesh, direction finding, audio via LE Audio). Classic has been mostly stable since 2010. If you see a device that does audio streaming, it's still probably Classic. Everything else is migrating to BLE.

The four pairing modes

Both Classic SSP and LE Secure Connections support four pairing modes, chosen based on the I/O capabilities the devices report to each other:

ModeWhat happensMitM protectionTypical devices
Just WorksTwo devices pair with no user interaction. ECDH key exchange happens, but neither side authenticates the other's public key.None.Headsets, speakers, beacons, sensors — anything with no display or buttons.
Numeric ComparisonBoth devices display a 6-digit code derived from the ECDH exchange. User confirms they match.Yes — user catches MitM if codes differ.Phone ↔ tablet, phone ↔ laptop pairings.
Passkey EntryOne device displays a 6-digit code, user types it into the other.Yes — passkey is mixed into the key derivation.Keyboards (display on phone, enter on keyboard), printers.
Out-Of-Band (OOB)Pairing parameters are exchanged over a separate channel (typically NFC tap).Yes — if the OOB channel is secure.NFC-pair headphones, smart cards, payment devices.
The Just Works problem: Most low-cost BLE devices (fitness trackers, sensors, beacons, smart bulbs) have no UI and use Just Works. An attacker within range during pairing can MitM the ECDH exchange and end up with both sides' encryption keys. Some devices implement "Numeric Comparison via app" — the comparison happens on a paired phone — which mostly closes this gap when set up correctly.

Named attacks: BlueBorne

BlueBorne
Remote code execution · Armis, 2017 · 8 CVEs
Prereq
Target device with Bluetooth enabled and within RF range (~10 m). No pairing required. No user interaction required.
Move
A family of eight vulnerabilities across Linux BlueZ, Android, iOS, and Windows Bluetooth stacks. Together they allowed remote code execution at the Bluetooth-stack level — meaning kernel-level on Linux/Android, ring 0 on Windows. Attacker doesn't need the device to be discoverable; just having Bluetooth on was enough.
Defense
Patched in September 2017 across all major OSes. Status today: historically important, no longer a live threat on patched devices. But unpatched IoT devices and old Android phones may still be vulnerable — in 2017 estimated 5 billion devices were affected.

Key-negotiation downgrade: KNOB

KNOB · Key Negotiation of Bluetooth
Active downgrade · Antonioli et al., 2019 · CVE-2019-9506
Prereq
MitM position between two devices during a Bluetooth Classic connection. Both devices unpatched.
Move
Bluetooth Classic uses 1-16 bytes of entropy in the encryption key. The spec allowed devices to negotiate down to 1 byte — 256 possible keys, brute-forceable instantly. The attacker MitMs the entropy-negotiation packets and forces 1 byte. Once connected, decrypts everything in real time.
Defense
Bluetooth Core Specification 5.1 mandated minimum 7 bytes. Patched widely in 2019. Status today: patched on modern devices; older Bluetooth Classic stacks may still negotiate down.

Impersonation: BIAS

BIAS · Bluetooth Impersonation Attacks
Authentication bypass · Antonioli et al., 2020 · CVE-2020-10135
Prereq
Within RF range of a target that has previously paired with the device the attacker wishes to impersonate. Target unpatched.
Move
Exploits weaknesses in the legacy authentication procedure of Bluetooth Classic. Attacker impersonates a previously-paired device (say, your trusted headset) by replaying the authentication challenge and skipping the part where it would have to prove it has the link key. Target reconnects and trusts the attacker.
Defense
Bluetooth Core Specification fix in 2020. Patched in major OSes through 2020-2021. Modern Secure Connections pairing (mandatory in newer spec versions) prevents this.

BlueSmacking and BLE eavesdropping

BlueSmacking
DoS · The old ping-of-death adapted
Prereq
Within RF range of a Bluetooth-enabled target. Most defendable against because it's loud and obvious.
Move
Send oversized L2CAP echo requests (Bluetooth ping packets) at high rate. Older Bluetooth stacks crash; newer ones drop the packets but the target's Bluetooth radio still spends cycles dealing with them. DoS, not RCE.
Defense
Patched in modern stacks. Rare in the wild today; included for completeness because the term still appears on certs.
BLE Eavesdropping
Passive interception · The structural BLE problem
Prereq
Within RF range during BLE pairing. Tool: Ubertooth One or nRF52840 dongle with the open-source sniffer firmware.
Move
If devices use LE Legacy pairing (pre-4.2), the temporary key (TK) used to encrypt the pairing exchange is either 0 (Just Works) or a 6-digit passkey (Passkey Entry). 6-digit passkeys are brute-forceable in microseconds. Once the attacker has TK, they derive the long-term key (LTK) and decrypt all future traffic between those two devices.
Defense
LE Secure Connections (4.2+) uses ECDH and is not vulnerable to passive eavesdropping during pairing. But every cheap fitness tracker and smart bulb shipped before ~2017 uses LE Legacy. Check the BLE version when you buy IoT.

The named-attack table on certs

For Security+, CySA+, and similar certs, the test questions are usually "which attack is this?" Here's the recognition cheat sheet:

If you see…It's probably…
"Sending unsolicited data/files to nearby Bluetooth devices for shock value"Bluejacking (largely defunct — modern devices reject unsolicited messages)
"Stealing data from a Bluetooth device by exploiting an OBEX vulnerability"Bluesnarfing (against pre-2004 devices)
"Eavesdropping on or hijacking a Bluetooth headset's audio"Bluebugging
"Crashing Bluetooth via oversized echo packets"BlueSmacking
"No-touch RCE via Bluetooth stack bugs"BlueBorne
"Forcing low-entropy encryption keys during pairing"KNOB
"Impersonating a previously-paired Bluetooth device"BIAS
"Sniffing BLE pairing to recover the link key"BLE eavesdropping (LE Legacy)
What's actually happening at the airport: the AirTags-in-luggage attacks. AirTags advertise BLE beacons constantly. Anyone with a BLE-capable phone in Find My / nearby-tracker mode picks them up. The privacy compromise isn't a Bluetooth flaw — it's the system working as designed. The relevant defenses are Apple's and Google's tracker-detection notifications.

Practical defenses

Takeaway

Bluetooth Classic and BLE are different protocols and most attacks are specific to one. The most consequential attacks of the last decade (BlueBorne, KNOB, BIAS) are patched on modern devices — but unpatched IoT and old phones keep them alive.

The structural weakness is Just Works pairing on devices with no display, which is most IoT. The structural defense is LE Secure Connections with proper user verification when devices have UI. Recognize the named attacks for the cert exam, deploy the patches in real life, and remember that "Bluetooth off" is rarely a realistic answer for users.

Sources

  1. Bluetooth Special Interest Group. (2023). Bluetooth Core Specification 5.4. https://www.bluetooth.com/specifications/specs/core-specification/
  2. Armis Labs. (2017). BlueBorne: The dangers of Bluetooth implementations. https://www.armis.com/research/blueborne/
  3. Antonioli, D., Tippenhauer, N. O., & Rasmussen, K. (2019). The KNOB is broken: Exploiting low entropy in the encryption key negotiation of Bluetooth BR/EDR. USENIX Security. https://www.usenix.org/conference/usenixsecurity19/presentation/antonioli
  4. Antonioli, D., Tippenhauer, N. O., & Rasmussen, K. (2020). BIAS: Bluetooth impersonation attacks. IEEE S&P. https://francozappa.github.io/about-bias/
  5. Ryan, M. (2013). Bluetooth: With low energy comes low security. USENIX WOOT. https://www.usenix.org/conference/woot13/workshop-program/presentation/ryan
  6. NIST. (2022). NIST SP 800-121r2 Rev 1: Guide to Bluetooth Security. https://csrc.nist.gov/publications/detail/sp/800-121/rev-2/final