Please refrain from tasting the KNOB.

As a Bluetooth guy, and as someone who just posted a bunch of DEFCON 27 stuff, I feel compelled to say something about the Key Negotiation of Bluetooth Attack (aka KNOB) which has been getting a lot of attention the past few days.

Here’s the actual paper from the USENIX Security Symposium.

The attack allows a third party, without knowledge of any secret material (such as link and encryption keys), to make two (or more) victims agree on an encryption key with only 1 byte (8 bits) of entropy. Such low entropy enables the attacker to easily brute force the negotiated encryption keys, decrypt the eavesdropped ciphertext, and inject valid encrypted messages (in real-time). The attack is stealthy because the encryption key negotiation is transparent to the Bluetooth users. The attack is standard-compliant because all Bluetooth BR/EDR versions require to support encryption keys with entropy between 1 and 16 bytes and do not secure the key negotiation protocol. As a result, the attacker completely breaks Bluetooth BR/EDR security without being detected. [Emphasis in the original – DB]

Here’s a higher level overview of how the attack works.

Also of interest, also from USENIX, also getting some media attention: “Please Pay Inside: Evaluating Bluetooth-based Detection of Gas Pump Skimmers“. What’s cool about this is that the authors have developed Bluetana, an Android app that scans for Bluetooth devices in the area (every five seconds), displays a list of devices it found, and highlights ones that show characteristics similar to those of Bluetooth skimmers.

First, the app checks the device’s class. All skimmers studied within this work, whether discovered by Bluetana or not, had a device class of Uncategorized. If the device class is not uncategorized, the data is saved for later analysis. The device’s MAC prefix is then compared against a “hitlist” of prefixes used in skimming devices recovered by law enforcement. If the device has a MAC that is not on this hitlist, it is unlikely to be a skimmer, and the app highlights the record yellow. Next, if the device name matches a common product using the same MAC prefix, the record highlights in orange. If all three fields (MAC prefix, Class-of-Device, and Device Name) indicate the device is likely to be a skimmer, Bluetana highlights the record in red. The highlighting procedure is the result of a year of refinements based on our experience finding skimmers in the field, and Bluetana includes a remote update procedure to account for these incremental changes.

I’m fascinated by both of these papers, just based on a preliminary skimming. I’m hoping to do a detailed reading at that mythical point in the future when I have more free time…

Comments are closed.