Bluetooth KNOB and BLURtooth, second installment of Bluetooth cyber-attacks

The second installment of the Bluetooth cyber-attacks focuses on two Bluetooth threats that have been gaining momentum in recent times: Bluetooth KNOB and BLURtooth

In this second article of Bluetooth cyber-attacks, the KNOB and BLURtooth attacks discovered by researchers Daniele Antonioli (KNOB, BLURtooth), Nils Ole Tippenhauer (KNOB, BLURtooth), Kasper Rasmussen (KNOB, BLURtooth) and Mathias Payer (BLURtooth) are presented.

1. KNOB: Key Negotiation Of Bluetooth BR/EDR

The Bluetooth cyberattack KNOB is performed on devices using the extended version of classic Bluetooth (Bluetooth Basic Rate/Extended Data Rate (BR/EDR)). The official documentation for this attack is available at https://knobattack.com.

In modern Bluetooth implementations, the Bluetooth protocol stack is separated into two components that will be relevant for this attack: the host and the controller. The host is implemented by the device operating system and controls the upper layers of the stack, while the controller runs in the firmware of the Bluetooth chip and controls the lower layers.

For the explanation of this cyber-attack we will make use of the same roles defined in the BIAS attack: Alice and Bob to indicate the devices of the communication channel to be attacked and Charlie to indicate the attacker.

The objective of the cyberattack is to reduce the entropy of the session key to one byte so that the attacker can listen to the communication and find out the key, by brute force, among the 256 possible ones. This is possible because the key entropy is negotiated at each connection establishment. Since the standard allows keys of between 1 and 16 bytes of entropy, the negotiation can be interfered with to force the choice of 1 byte.

The process is described for Secure Simple Pairing (SSP) mode, although the researchers indicate that it is also effective in Secure Connections (SC) mode.

For each connection, Alice and Bob calculate an encryption key, KC, based on the parameters KL, BTADD (Bluetooth addresses), AU_RAND and EN_RAND, where KL is the link key negotiated during pairing and the rest are public parameters. The entropy of KC is always 16 bytes, but this is not the real key used to encrypt communications; it is K’C, which is derived from KC by reducing its entropy to N, with N being the result of key negotiation, as shown below:

The initiator of the communication, Alice, proposes an entropy between 1 and 16 bytes and Bob accepts it or proposes a smaller value. This negotiation continues until a common agreement is reached. The negotiation takes place without encryption or authentication by the devices.

In this case, Alice and Bob negotiate an entropy of 1 byte for K’C. The protocol introduces this step to adapt it to the regulation on encryption in different countries and to facilitate security updates.

For the realization of the attack, we assume that Charlie, the attacker, does not have access to any secrets shared by Alice and Bob (link key, KL, and encryption key, KC), but can observe the nonces (EN_RAND and AU_RAND), the Bluetooth clock and the exchanged packets. The attacker, therefore, can interfere with the negotiation as follows:

In the image we see that Charlie interferes with Alice’s proposal to set the entropy to 16 bytes and, instead, sends Bob an entropy of 1 byte. Bob accepts the proposal and Charlie sends Alice, pretending to be Bob, another proposal to set the entropy to 1 byte. Both ends accept, thinking that the other has lowered the entropy because it does not support more complex encryption keys. The result is that a 1-byte entropy key has been established without the need to know the secret parameters for communication.

In the images above, it can be seen that the whole negotiation process is done at the controller level, not the host. This is very relevant, because the application using the Bluetooth protocol for communication does not receive any indication that the connection has been interfered with.

Once entropy is successfully established, key discovery is performed by an exhaustive or brute force method. The key K’C, used to encrypt communications, is derived from KC following a procedure called Encryption Key Size Reduction, determined by the following equation:

K’C=g2(N) xor (KC mod g1(N))

In it, N is the traded entropy and g1(N) and g2(N) are polynomials determined by the value of N, according to a table. For value 1 of N, g1(1) is 0x00…0xff and g2(1) is the value 0x00e275a0abd218d4cf928b9bbf6cb08f. Since, for this case, a modulo is made to 0xff, there are only 256 possibilities, which can be precomputed and then tested to decrypt the messages.

2. BLURtooth: Exploiting Cross-Transport Key Derivation in Bluetooth Classic and Bluetooth Low Energy

This type of Bluetooth cyber-attack affects Bluetooth versions 4.2 and 5.0 since a patch has been issued as of version 5.1 that corrects this vulnerability. The official documentation of the attack is available at the link: BLURtooth_paper.

The cyber-attack is based on a security flaw in the specification of the standard related to the Cross-Transport Key Derivation (CTKD) function. This function allows two previously paired devices to generate the Long Term Key (LTK) for Bluetooth Classic (BT) and Bluetooth Low Energy (BLE) from the BLE and BT keys respectively.

As specified in the Bluetooth standard, the LTKs used in both Bluetooth classic (BT) and Bluetooth low energy (BLE) are obtained by means of the CTKD function that accepts as input parameters a key of length 128 bits (16 bytes) and 2 strings of 4 bytes. As a result, the function returns a key of length 128 bits (16 bytes) using AES-CMAC.

For Bluetooth classic (BT), the strings used to derive a BLE key from the BT key (KBT → KBLE) are: tmp2 and brle. On the other hand, the strings used to derive the BT key from BLE (KBLE → KBT) are tmp1 and lebr.

For the realization of the attack, the knowledge is limited to the information available in the channel, i.e., to the information that Alice and Bob send: BT addresses, BT names, authentication requirements, IO capabilities, and device classes. Thus, the attacker (Charlie) does not need to know neither the LTKs (long term keys) nor the session keys of Alice and Bob.

The operation of the high-level attack is as follows:

1. Alice (master) and Bob (slave) are assumed to have established a connection via classic Bluetooth (BT).
2. Charlie discovers that Bob is BLE-pairable. So, he impersonates Alice and sends a connection request to Bob via BLE. As BT and BLE are on different physical channels, there is no collision with the lawful traffic between Alice and Bob (which is on a BT channel).
3. Bob sends Charlie a reply to his pairing request thinking that Alice wants to pair or re-pair via BLE using CTKD.
4. Charlie and Bob use the exchanged public keys to calculate DK (shared Diffie-Helman secret). From the calculated DK and the exchanged nonces (NC, NB) both devices generate the BLE key (KBLE).
5. From KBLE both devices calculate the KBT key using the CTKD function.
6. By overwriting the KBT key, Alice loses the session with Bob. Thus, Charlie is able to hijack the original communication channel.

The attack workflow is independent of whether the original channel of communication between Alice and Bob is over BT or over BLE. In addition, the procedure for attacking Bob is analogous to that of Alice with some slight variations.

Finally, using this type of attack, a more elaborate attack can be constructed resulting in a Man-in-the-middle attack as shown in the image below.

The next article will present the Bluetooth BrakTooth family of attacks as well as some conclusions and critical analysis of all the attacks presented throughout the series.

References

● Antonioli, D., Tippenhauer, N. O., & Rasmussen, K. B. (2019). The {KNOB} is Broken: Exploiting Low Entropy in the Encryption Key Negotiation Of Bluetooth BR/EDR. In 28th {USENIX} Security Symposium ({USENIX} Security 19) (pp. 1047-1061).

● Antonioli, D., Tippenhauer, N. O., Rasmussen, K., & Payer, M. (2020). Blurtooth: Exploiting cross-transport key derivation in bluetooth classic and bluetooth low energy. arXiv preprint arXiv:2009.11776.

Discover our work and cybersecurity services at www.tarlogic.com