KNOB a new attack to intercept encrypted Bluetooth traffic

bluetooth knob

Recientemente important information was released about a new attack called KNOB (Key Negotiation Of Bluetooth), which allows an attacker to organize the interception and substitution of information in encrypted Bluetooth traffic.

By having the ability to block direct packet transmission in the process of negotiating the connection of Bluetooth devices, the attacker can achieve the use of keys containing only 1 byte of entropy for the session, which allows you to be able to use the brute force method to determine the encryption key.

About KNOB

Daniele antonioli from SUTD, Dr. Nils Tippenhauer from CISPA and Professor Kasper Rasmussen from the University of Oxford discovered this new KNOB vulnerability and it affects Bluetooth BR / EDR devices, also known as Bluetooth Classic, using specification versions 1.0 - 5.1.

Researchers reported the vulnerability to ICASI members, Microsoft, Apple, Intel, Cisco, and Amazon, who issued a coordinated vulnerability disclosure.

The problem (CVE-2019-9506) It is caused by flaws in the Bluetooth BR / EDR Core 5.1 specification and earlier versions They allow the use of encryption keys that are too short and do not prevent an attacker from interfering with the connection negotiation step to revert to those untrusted keys (packets can be substituted by an unauthenticated attacker).

An attack can be carried out when negotiating the connection of a device (already established sessions cannot be attacked) and is effective only for connections in BR / EDR (Bluetooth Basic Rate / Enhanced Data Rate) modes if both devices are vulnerable.

If the key is selected successfully, the attacker can decrypt the transmitted data and silently perform arbitrary ciphertext substitution on the traffic from the victim.

How does the attack work?

To reproduce the vulnerability in the lab (the attacker's activity was broadcast on one of the devices), a prototype toolkit was proposed to carry out the attack.

For a real attack, the attacker must be in the receiving zone of the victims' devices and have the ability to briefly block the signal from each device, which he intends to implement through signal manipulation or reactive interference.

Exploiting this vulnerability is not an easy task, as it requires specific conditions to be established. This includes:

  • Both devices must be Bluetooth BR / EDR.
  • An attacker would need to be within range of the devices while establishing a connection.
  • "The attacking device would need to intercept, manipulate and retransmit key length negotiation messages between the two devices while simultaneously blocking the transmissions of both, all within a narrow time window."
  • The encryption key would need to be shortened successfully and then forced to decrypt the decryption key.
  • The attacker would need to repeat this attack every time the devices were paired.

When establishing a connection between two Bluetooth controllers A and B, controller A, after authentication with a channel key (bind key), can offer to use 16 bytes of entropy for the key encryption, and controller B can accept this value or specify a lower value, in itself it is not possible to generate a key of the proposed size.

In response, controller A can accept the response and activate the encrypted communication channel.

At this stage of parameter negotiation, encryption is not applied, so the attacker has the opportunity to get into the data exchange between controllers and replace the packet with the proposed entropy size.

Since the allowed key size ranges from 1 to 16 bytes, the second driver will accept this value and send its commit with an indication of a similar size.

The organization Bluetooth SIG responsible for the development of Bluetooth standards has released a specification update with number 11838, in which manufacturers have proposed measures to block the vulnerability (the minimum size of the encryption key has been increased from 1 to 7).

For the Linux kernel a solution was proposed in the kernel stack that allows you to change the minimum size of an encryption key.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.