Reflected public keys: recovering the six digits of Bluetooth Passkey Entry
- Identifier
- CVE-2020-26558
- Software
- Bluetooth Core Spec
- Affected
- BR/EDR Secure Simple Pairing, Bluetooth Core Specification 2.1 through
- Reported by
- Tristan Claverie and José Lopes Esteves, ANSSI
- Disclosed
- 15 June 2021
You've done the six-digit dance. Your laptop puts a number on screen and your headphones want you to type it in, or the other way round. Once both ends agree, you're paired. That number is not there for convenience. It is the only thing standing between you and a man in the middle.
Bluetooth pairing starts with an anonymous Diffie-Hellman exchange. Two devices that have never met swap public keys over the air and derive a shared secret. On its own that gets you encryption against a passive listener and nothing at all against an active one. An attacker sitting between the two radios can run one exchange with each side and read everything. So the specification bolts an authentication step on top. The six digits are how the user supplies the out-of-band evidence that the key you agreed is the key the other device agreed. Bluetooth calls this method Passkey Entry.
Tristan Claverie and José Lopes Esteves work at the French national cybersecurity agency ANSSI. They went looking at the authenticated key agreement protocols in Bluetooth Classic, Bluetooth Low Energy and Bluetooth Mesh, using a single technique: reflection. Their paper is BlueMirror: Reflections on Bluetooth Pairing and Provisioning Protocols, presented at WOOT in May 2021. Seven attacks, validated against real implementations, disclosed to the Bluetooth SIG in September 2020, six CVEs. This post is about one of them, CVE-2020-26558, which is the Passkey Entry one.
The passkey is six decimal digits. Call it 20 bits, which is what the ANSSI slides call it, and which is not very many. Suppose the protocol simply hashed the passkey into the confirmation values and sent them. A man in the middle could grab the exchange and try all million possibilities offline in no time at all. The designers knew this. The defence is that the passkey is used one bit at a time.
How one round works#
After the Diffie-Hellman exchange, Passkey Entry runs twenty rounds. In each round both sides pick a fresh random nonce. Each then sends a commitment: a value computed over the two public keys, that nonce, and exactly one bit of the passkey. Commitments go first, in both directions. Only then do the two sides reveal their nonces, at which point each can recompute the other's commitment and check it matches.
The ordering is the point. You committed before you saw your peer's nonce, so you can't choose your bit after the fact to make the round succeed. Each round involves one bit only. An attacker who guesses wrong gets caught at the first round they guess wrong on, having learned nothing they could take away and grind offline. Twenty rounds, one bit each, and the protocol aborts the moment a check fails.
Andrew Lindell presented an analysis of Bluetooth 2.1 pairing at BlackHat in 2008. The rule the field took away from it was that a fresh, perfectly random passkey made Passkey Entry safe. The ANSSI work is a direct answer to that. Their own summary of the state of the art, before and after:
Before: If passkey is perfectly random, no problem. This work: If passkey is perfectly random, problems remain.
Reflecting the public key#
Here's the move. The attacker sits between an initiator and a responder. The initiator sends its public key. Instead of substituting one of its own, the attacker sends that same public key straight back at the initiator, as if the attacker were the responder and this were its key. Then it does the same thing to every message in every subsequent round. Whatever the initiator sends, the attacker returns it.
Reflection attacks are an old idea. They work whenever a protocol is symmetric enough that a party can't tell its own message from its peer's. Nir Drucker and Shay Gueron found one in TLS 1.3's PSK mode, which they called Selfie. The Bluetooth case bites because of what falls out of it.
The commitment in each round is a function of both public keys, a nonce, and a passkey bit. Reflect the public key and both of those key inputs are now values the attacker knows exactly. The initiator commits, then, as the protocol demands, reveals its nonce. That's everything but the bit. There are two possible bits. Compute both candidate commitments, see which one matches, and you know the bit. Do it twenty times and you have the passkey.
The ANSSI slides state it as recovering the passkey from the round's commitment and nonce pair, citing Lindell's 2008 analysis for that step.
CERT's note describes the same thing in vendor-advisory register. An attacker "could use a crafted series of responses to determine each bit of the randomly generated Passkey."
At the end of all this the initiator's pairing fails. The ANSSI slides record that outcome on that side of the attack. That looks like an error. Meanwhile the attacker now knows the six digits the user typed. It can turn round and run a correct Passkey Entry against the responder, which will complete, authenticated, with an encryption key. The user is looking at a failed pairing on the device in their hand and a paired accessory across the room.
The affected version ranges show how structural this is. CERT lists BR/EDR Secure Simple Pairing from Core 2.1 through 5.2, BR/EDR Secure Connections from 4.1 through 5.2, and LE Secure Connections from 4.2 through 5.2. That's not a range of releases with a bug in them. That's every version that has ever had the feature.
The other five CVEs#
VU#799380 covers six CVEs, not one, and CVE-2020-26558 is the least dramatic-sounding of them. Its sibling CVE-2020-26559 is about Bluetooth Mesh provisioning, the procedure by which a new device joins a mesh network and receives the network key. There the researchers found that an attacker holding the Provisioner's public key, the provisioning confirmation value and the provisioning random value can work out the AuthValue directly. No brute force at all, even when the AuthValue has a full 128 bits of entropy. The other four are CVE-2020-26555 (impersonation in legacy BR/EDR PIN pairing), CVE-2020-26556 and CVE-2020-26557 (malleable commitment and predictable AuthValue in Mesh), and CVE-2020-26560 (Mesh provisioning impersonation).
Six CVEs landing in one CERT note on one day is a good way to be ignored. There's no logo and no name that a journalist can use, "BlueMirror" being a paper title rather than a brand, and the individual entries read like paperwork.
The ANSSI conclusions end on two points. Most of the reflection attacks they found can be patched in implementations. Some of them can't, and need the specification itself redesigned. The one pairing method that came through the study intact was Numeric Comparison. Both devices display a number and the human confirms the two match. In their words it "appears (again) to be the most resistant Pairing method."