Bluetooth LE pairing is the handshake where two devices agree on a secret key so the rest of their conversation can be encrypted. Done right, that key is fresh, strong, and tied to the two devices that actually meant to talk. Done wrong, the key is weak, unauthenticated, or trivially guessed, and a third radio in range can read everything or pretend to be one of the endpoints. The mechanism is small, it runs in milliseconds, and most users never see it. That is exactly why its failures are so quiet. This post walks the pairing flow one step at a time, then walks the real attacks that break it: an entropy downgrade that shrinks a key to a single byte, a spoofing trick that abuses reconnection, an association model that encrypts without authenticating, and a passive sniff that recovers the key offline.
What bluetooth le pairing actually does
When two Bluetooth Low Energy devices first meet, they have no shared secret. A smartphone and an Acme smart lock are radios shouting into the same crowded band, and anyone nearby can hear the same packets. Pairing is the procedure that turns that open exchange into a private channel. It does three jobs in sequence: the devices announce what input and output hardware they have, they pick an association model based on those capabilities, and they run that model to establish a key. Everything that follows, every encrypted read and write, rests on the key that pairing produced.
There are two generations of this procedure, and the difference matters for every attack below.
LE legacy pairing versus LE Secure Connections
LE legacy pairing is the original mechanism, shipped with the first Low Energy specification. In legacy pairing the two devices first agree on a Temporary Key, or TK. They use the TK to derive a Short Term Key, the STK, which protects the rest of the exchange long enough to hand over a Long Term Key, the LTK, that gets stored and reused on later connections. The weakness baked into this design is the TK. Depending on the association model, the TK is either a six digit number the user typed, or it is simply zero. A small number space is a guessable number space, and that is the thread an attacker pulls.
LE Secure Connections arrived in Bluetooth 4.2 and replaces the heart of the exchange with Elliptic Curve Diffie Hellman key agreement on the P-256 curve. Instead of agreeing on a tiny Temporary Key and stretching it, both sides contribute to a shared secret that an eavesdropper cannot reconstruct from the packets alone, because the private scalars never go over the air. The same four association models exist in both generations, but under Secure Connections they protect a real key agreement rather than a six digit guess. If you remember one defensive fact from this entire post, it is that requiring LE Secure Connections removes the foundation that the legacy attacks stand on.
The four association models
An association model is how the two devices authenticate the key they are agreeing on, given whatever buttons and screens they happen to have. The specification defines four, and which one runs is decided automatically from the input and output capabilities each side advertises.
- Just Works is the model for devices with no screen and no keypad, which describes most cheap sensors, tags, and beacons. It runs the key agreement with no human in the loop and no value to compare. In legacy pairing the Temporary Key under Just Works is set to zero. It provides encryption, but it authenticates nothing.
- Passkey Entry has one device display a six digit number and the user types it into the other, or the same number is keyed into both. That shared six digit value feeds the authentication, so a passive listener who never sees the digits cannot complete the handshake the same way.
- Numeric Comparison, available only under LE Secure Connections, shows a six digit value on both screens and asks the user to confirm they match. Because the value is derived from both sides of an authenticated key agreement, confirming it rules out a radio sitting in the middle. This is the strongest model when both devices have a display.
- Out of Band moves the authentication data over a different channel entirely, commonly NFC. If a strong secret travels over that side channel, the over the air handshake can be authenticated against it, and a remote attacker who only hears the Bluetooth radio has nothing to work with.
The split that runs through all four is whether the model provides authentication, often called MITM protection, or only encryption. Just Works gives encryption with no authentication. The other three, used correctly, give both. An attacker reads that capability advertisement as a menu, and Just Works is the cheapest item on it.
How the pairing breaks
Four weaknesses, each attacking a different assumption in the flow above. The first downgrades the key. The second skips authentication on reconnect. The third never had authentication to begin with. The fourth recovers the key by listening.
1. The KNOB attack: negotiating the key down to one byte
The Key Negotiation of Bluetooth attack, KNOB, was published by Daniele Antonioli, Nils Ole Tippenhauer, and Kasper Rasmussen, and it targets a step most descriptions of pairing skip entirely: the negotiation of how long the encryption key will be. Before encryption starts on a Bluetooth BR/EDR link, the two devices agree on the entropy of the key, anywhere from 16 bytes down to a legacy minimum of 1 byte. The problem is that this entropy negotiation is itself unauthenticated. It happens before the strong key protects anything, and nothing signs or checks the proposed length.
An attacker positioned between the two devices rewrites that negotiation in flight. When one side proposes 16 bytes, the attacker lowers the proposal to 1 byte before it reaches the other side, and does the same in reverse. Both devices believe they negotiated honestly and both accept a key with only 8 bits of entropy. That is 256 possible keys. The attacker brute forces it, decrypts the traffic, and injects valid ciphertext, all without either victim noticing, because the downgrade is invisible at the application layer.
The devices agreed on a key. They never agreed on how hard that key would be to guess, and the one negotiation they trusted to set that was the one nobody was protecting.
This is tracked as CVE-2019-9506, scored 8.1 High, and its official description is precise: the specification up to and including version 5.1 permits a sufficiently low encryption key length and does not prevent an attacker from influencing the key negotiation. The researchers tested more than 14 chips from Intel, Broadcom, Apple, and Qualcomm, and nearly all accepted 1 byte of entropy. The full method is documented on the KNOB attack project page. The fix the Bluetooth SIG shipped is a floor: their security notice on key negotiation recommends enforcing a minimum encryption key length of 7 octets so the downgrade has nowhere low to go.
2. BLESA: spoofing a device on reconnect
Pairing is the expensive first meeting. Reconnection is the cheap reunion. Once two devices have stored a Long Term Key, every later session is supposed to skip the full handshake and just resume encryption using that stored key. The Bluetooth Low Energy Spoofing Attack, BLESA, comes from researchers at Purdue’s PurSec Lab with EPFL, and it lives entirely in that reconnection step.
The researchers analyzed the reconnection procedure as written in the specification and found that authentication on reconnect is effectively optional and, worse, poorly enforced by real stacks. When a previously paired device reappears, the client is supposed to insist the connection actually use the keys they share. Instead, several implementations would accept data from a peer that claims to be the known device without the peer proving it holds the Long Term Key. An attacker who has observed the earlier pairing can therefore impersonate the server, the Acme lock or a fitness sensor, and feed the client spoofed data on reconnect. The client trusts it because reconnection is the step everyone designed to be frictionless.
The work won a Best Paper award at the USENIX Workshop on Offensive Technologies in 2020, and the paper estimates it could affect well over a billion devices. The reconnection assumption is the dangerous part: the whole point of storing an LTK was to avoid re proving identity, and skipping that re proof is exactly the hole. The full analysis is in the BLESA paper at USENIX WOOT 2020.
3. Just Works: encryption with nobody on the other end verified
Just Works is not a bug. It is a documented model that does precisely what its design says, which is to encrypt without authenticating. The trouble is what that combination means against an active attacker. Because no value is compared and no secret is shared out of band, there is nothing in the handshake that distinguishes the real Acme lock from a radio impersonating it. An attacker who is present during pairing can sit between the phone and the lock, pair with each side separately, and relay between them. Both ends get an encrypted channel. Both encrypted channels terminate at the attacker.
This is the classic man in the middle, and Just Works is open to it by construction. The reason it is everywhere is hardware economics: a sensor with no screen and no keypad cannot run Passkey Entry or Numeric Comparison, so the capability negotiation falls through to Just Works as the only option both devices support. The defense is not to disable encryption but to refuse Just Works where it matters, by requiring the MITM protection flag during pairing so a device that can only offer Just Works is rejected for sensitive functions rather than silently accepted.
It helps to be precise about what Just Works does and does not give you, because the marketing word is encryption and people stop reading there. The channel is encrypted, so a purely passive listener under LE Secure Connections cannot simply read the plaintext off the air. What is missing is any guarantee about who sits at the other end of that encrypted channel. Encryption answers the question is this traffic readable by an outsider. Authentication answers the question am I talking to the device I think I am. Just Works answers only the first, and an active attacker exploits the gap between the two by being the device you think you are. The phone encrypts faithfully to the attacker, and the attacker encrypts faithfully to the lock, and both sides see a green padlock the whole time.
4. Passive sniffing of LE legacy pairing
The first three attacks need an active radio in the conversation. The last one just listens. Mike Ryan’s tool crackle attacks LE legacy pairing offline, and it works because of the Temporary Key. Under Just Works the TK is zero. Under the six digit Passkey models the TK is a value in the range 0 to 999999, padded out to 128 bits, which sounds like a lot until you count it: one million possibilities is a number a laptop chews through in under a second.
An attacker captures the legacy pairing exchange off the air, including the confirm values the two devices send. Then they compute the confirm value for every candidate TK and keep the one that matches what they captured. Recovering the TK unwinds the rest: the TK yields the Short Term Key, the STK protects the handover of the Long Term Key, and once the LTK is in hand the attacker decrypts the entire session and every future session that reuses it. No injection, no jamming, just a recording and a brute force. The technique is described in the crackle project on GitHub. The single line of defense is the generational one: LE Secure Connections replaces the guessable Temporary Key with a Diffie Hellman exchange that produces nothing for crackle to brute force.
Why this lands hard on IoT
These attacks would be academic if the affected devices were just headphones. They are not. Bluetooth Low Energy is the radio of choice for the cheapest, longest lived, least patched hardware in circulation, and that population maps almost exactly onto the weaknesses above.
Smart locks are the sharpest example. A lock that uses Just Works, or that does not enforce authenticated reconnection, can be spoofed or relayed by an attacker in radio range, and the failure mode is a door that opens. Medical devices such as glucose monitors and insulin pumps carry data and sometimes control that a spoofing or eavesdropping attack turns into a safety problem, not just a privacy one. Wearables and fitness sensors leak a continuous stream of personal data over links that frequently fall back to Just Works because the band on your wrist has no keypad. And trackers, the small tags people attach to keys and bags, are designed to be silent and to reconnect automatically, which is precisely the reconnection behavior BLESA abuses.
The common thread is constraint. These devices are too small for a screen, too cheap for careful firmware, and too long lived to be reliably updated, so they default to the weakest models and the oldest pairing generation. The economics that make them cheap are the same economics that make them vulnerable.
There is a patching problem layered on top. When CVE-2019-9506 landed, the operating system vendors that ship general purpose devices, phones and laptops, pushed enforcement of a minimum key length fairly quickly. A standalone Acme lock or a budget fitness band has no such pipeline. Its firmware was flashed once at the factory and may never be touched again, and many such products have no mechanism to update the Bluetooth stack at all. So a weakness in the specification does not just affect devices for a patch cycle; it affects them for the entire service life of hardware that was never built to be fixed. An attacker does not need a fresh vulnerability against this population. The old ones never closed.
Closing the gaps
Every attack above has a corresponding control, and they stack. None of them requires inventing anything; they require refusing the weak defaults the specification still permits for compatibility.
Require LE Secure Connections
This is the single highest leverage change. Secure Connections mode replaces the legacy Temporary Key and STK chain with ECDH key agreement, which removes the guessable secret that crackle brute forces and strengthens the foundation under every association model. Devices can refuse to pair in legacy mode, and security sensitive products should. The legacy fallback exists for old peers; a lock or a medical device has no business honoring it.
Enforce a minimum key length
KNOB works because the entropy floor sits at 1 byte. Following the Bluetooth SIG guidance and enforcing a minimum encryption key length, 7 octets for BR/EDR, means an attacker who rewrites the negotiation cannot push it down to a brute forceable size. Platform vendors shipped exactly this enforcement after CVE-2019-9506, and devices should reject any negotiated key below the floor rather than accept whatever the negotiation lands on.
Mandate authenticated reconnection
BLESA exists because reconnection skipped the proof that the peer still holds the shared key. The fix is to make that proof mandatory: on every reconnect, require the link to actually use the stored Long Term Key and reject a peer that cannot demonstrate it. The convenience of a frictionless reunion is not worth accepting data from a device that never proved it is the one you paired with.
Set the MITM protection flags
During pairing, devices exchange authentication requirement flags, and one of them requests MITM protection. Setting it forces the capability negotiation toward an authenticated model, Passkey Entry, Numeric Comparison, or Out of Band, instead of letting it slide into Just Works. A device that can only offer Just Works then fails closed for sensitive operations rather than getting an unauthenticated channel by default. Pair this with Out of Band where you have a side channel like NFC, and the over the air handshake gets anchored to a secret the remote attacker never hears.
These controls reinforce one another. Secure Connections kills the offline brute force, the key length floor kills the entropy downgrade, authenticated reconnection kills the spoof, and the MITM flag keeps the whole thing from quietly falling back to the model that authenticates nobody. The same discipline that protects a Bluetooth lock applies to the firmware underneath it; if the device boot chain is also worth trusting, the way the secure boot process verifies each stage is the embedded sibling of these radio side defenses.
The assumption that breaks
Strip the four attacks down and they share one root. Pairing assumes that the two devices negotiating the key are the only two in the conversation, and that the negotiation about the key is itself trustworthy. Both halves of that assumption fail. Just Works and weak reconnection break the first half, because a third radio can insert itself into a handshake that never proves who is on the other end. KNOB breaks the second half directly: the one negotiation that decides how strong the key will be is the one nobody bothered to authenticate, so an attacker edits it in transit and both victims sign off on a key they would never have chosen.
The flaw is never a broken cipher. The ciphers are fine. The flaw is a step that was trusted without being checked, an entropy field nobody signed, a reconnection nobody re proved, a model that encrypts to whoever shows up. That gap between what a protocol assumes about its participants and what an attacker can actually arrange in the same radio band is the kind of weakness you find by asking what each step trusts and why it still trusts it, rather than by scanning for a known bad signature. It is exactly the kind of assumption an autonomous researcher built to test assumptions is meant to surface. Require Secure Connections, floor the key length, prove the peer on reconnect, and never let the handshake fall back to trusting a stranger. Learn more about that approach on our about page.
Frequently asked questions
What is the KNOB attack and what CVE tracks it?
KNOB, the Key Negotiation of Bluetooth attack, lets a nearby attacker rewrite the encryption key length negotiation between two BR/EDR devices because that negotiation is unauthenticated, forcing a key with as little as 1 byte (8 bits) of entropy that is then trivially brute forced. It is tracked as CVE-2019-9506, scored 8.1 High, and the full method is documented on the KNOB attack project page.
How does BLESA spoof a Bluetooth Low Energy device?
BLESA, the Bluetooth Low Energy Spoofing Attack, abuses reconnection. After two devices pair and store a Long Term Key, later sessions resume without a full handshake, and the researchers found that authentication on reconnect is optional and poorly enforced in real stacks. An attacker can impersonate a previously paired device and feed spoofed data to the client. The analysis is in the BLESA paper from USENIX WOOT 2020.
Why is the Just Works association model insecure?
Just Works is the pairing model for devices with no screen or keypad, and it provides encryption without authentication. Because no value is compared and no secret travels out of band, nothing in the handshake distinguishes the real device from an impostor, so an attacker present during pairing can sit in the middle, pair with each side, and relay between them. The model is described in the Bluetooth SIG security overview.
Can someone decrypt Bluetooth LE by just listening?
Yes, against LE legacy pairing. Mike Ryan’s tool crackle recovers the Temporary Key, which is zero under Just Works or a value from 0 to 999999 under the six digit models, by brute forcing all candidates against captured confirm values in under a second. The recovered key unwinds the Short Term Key and then the Long Term Key, decrypting the whole session. The fix is LE Secure Connections. See the crackle project on GitHub.