Bluetooth is really two protocols under one name. Bluetooth Classic (BR/EDR) handles higher-bandwidth links like audio streaming. Bluetooth Low Energy (BLE), introduced with version 4.0, is built for small, infrequent bursts of data from low-power sensors, wearables, and beacons. They share a brand and a radio band but have different pairing procedures and different weaknesses. Most modern phones speak both.
The attack surface breaks into three rough areas: bugs in the code that parses Bluetooth packets, weaknesses in how devices establish and protect a session key, and the everyday risk of weak pairing choices. Each has produced named, real-world attacks.
BlueBorne: code execution without pairing
In 2017, the security firm Armis disclosed BlueBorne, a set of eight vulnerabilities across the Bluetooth implementations in Android, iOS, Windows, and Linux. What made BlueBorne notable was the reach. Several of the bugs allowed an attacker within radio range to run code on a target device without pairing, without the target accepting a connection, and without any user interaction at all. The only requirement was that Bluetooth be turned on.
BlueBorne exploited flaws in the software that processes incoming Bluetooth packets, before any authentication step. Armis estimated it affected billions of devices at disclosure. Patches followed across the major platforms, and BlueBorne is now mostly historical, but it demonstrated the core risk: the Bluetooth stack is a large, complex piece of code exposed to any nearby radio, and a memory-safety bug there can bypass every higher-level protection. This is the same category of exposure that our piece on the memory-safety CVE crisis examines across the industry.
KNOB: negotiating the key down to nothing
Where BlueBorne attacked the code, the 2019 KNOB attack (Key Negotiation of Bluetooth) attacked the cryptography's setup. Bluetooth Classic lets two devices negotiate the length of their encryption key, historically anywhere from 16 bytes down to a single byte. That negotiation was not itself authenticated.
A KNOB attacker positioned between two pairing devices forces the negotiated key length down to one byte of entropy. A one-byte key has only 256 possibilities, which is brute-forced almost instantly. The two victim devices believe they have an encrypted link, and they do, but with a key so short the attacker can decrypt and inject traffic in real time. The fix was to enforce a sensible minimum key length (the specification was updated to require at least seven bytes), which patched devices now do.
KNOB is a downgrade attack: the target is not the encryption but the unauthenticated step that decides how strong the encryption will be. The same shape appears in TLS stripping and in cipher-suite downgrades. Any security negotiation that is not itself protected becomes the weakest link.
BIAS: impersonating a device you already trust
In 2020, the BIAS attack (Bluetooth Impersonation AttackS) took aim at reconnection. When two devices have paired once, they store a long-term key and skip the full pairing dance on future connections. BIAS abused weaknesses in that reconnection authentication to let an attacker impersonate a previously paired device without knowing the long-term key. Combined with KNOB, the two attacks chained into a strong position against the older Bluetooth security model. As with the others, specification and implementation fixes followed.
Where weak pairing invites trouble
Beyond the named research attacks, the everyday weak spot is the pairing method. BLE offers several association models, and they are not equally safe:
| Pairing method | Protection against a nearby attacker |
|---|---|
| Just Works | No man-in-the-middle protection. Used by devices with no screen or keypad. Convenient and common, and the weakest option. |
| Passkey Entry | A six-digit code is entered on one device, giving real man-in-the-middle resistance. |
| Numeric Comparison | Both devices show a number and you confirm they match. Strong, available on devices with displays. |
| Out of Band | Key material exchanged over another channel such as NFC. Strong, less common. |
A great many BLE gadgets use Just Works because they have no way to show or enter a code. That is a reasonable engineering tradeoff for a fitness band, but it means the link has no defense against an attacker who is present during pairing. The lesson is not to avoid such devices, but to pair them in a place and moment you control, not in a crowded public space, and to treat the link as unauthenticated for anything sensitive.
Tracking is a separate Bluetooth problem
Not every Bluetooth risk is an exploit. BLE beacons broadcast identifiers that can be used to follow a device around a store or a city, and consumer trackers have been misused for stalking. That is a privacy and safety issue distinct from the code and crypto flaws above, and we cover it separately in Bluetooth tracker stalking. It is worth keeping the two categories apart: one is about someone taking control of a link, the other is about a device leaking a trackable identity simply by being on.
Practical steps that actually help
- Keep devices patched. BlueBorne, KNOB, and BIAS were all fixed in updates. An unpatched phone or laptop is where these live on.
- Turn Bluetooth off when you are not using it. A radio that is off has no attack surface. This also cuts beacon-based tracking.
- Do not stay discoverable. Only enter pairing or discoverable mode when you are actively adding a device, then leave it.
- Pair in a controlled setting. The pairing moment is when downgrade and impersonation attacks are easiest. Do it at home, not at a conference.
- Remove old pairings. Devices you no longer use are stored keys that can be abused later. Clear them.
- Do not trust the link for secrets. Treat the Bluetooth connection as a transport, not as a secure channel. Sensitive data should be encrypted by the application riding on top.
The underlying principle
Every one of these attacks succeeds by breaking a lower layer that a higher layer assumed was safe. BlueBorne breaks the packet parser under the authentication. KNOB breaks the key-length negotiation under the encryption. BIAS breaks the reconnection under the pairing. The defense that survives all of them is the same principle that shows up in BadUSB and in Wi-Fi attacks: never let a convenient local link be the thing that guarantees your security. Assume the transport can fail, and put the real protection in the layer you control.
Where Haven fits
This principle is exactly how Haven treats every network, radio, and cable between you and the person you are talking to. Message and email content is encrypted end to end on the device, with PGP for email and the MLS protocol for group chat, before it reaches any transport. A compromised Bluetooth link, a hostile Wi-Fi network, or a bug in a lower layer does not expose what you wrote, because the confidentiality lives above the transport rather than inside it. The transport can be as untrustworthy as it wants to be.