unam.яe

When you are working on cybersecurity as evaluator (analyst, penetration tester, and so on); sometimes you will be in front of test cases that they have not been performed before. These tests are always challenges for us; and what is more gratifying for a ethical hacker that a hacking challenge.

This specific case is relative to a Security Functional Requirement (SFR) of a NIAP protection profile about Bluetooth.

* Same tests for LE.

In a previous post, additional information and some differences about LE and BR/EDR can be found; in this post we will see more differences, relative to about how the encryption key size is negotiated.

A bit of story about the encryption key size

The Bluetooth specification core specified an encryption key size of between 7 and 16 octecs for LE and 1 and 16 octecs for BR/EDR.

In 2019, a vulnerability CVE-2019-9506 was published and it was called KNOB attack (Key Negotiation of Bluetooth Attack). As summary, this vulnerability takes advantage that the devices supports encryption key sizes from 1 to 16 bytes (BR/EDR) and performing a MITM, try to downgrade the encryption key size to 1 byte during the negotiation, and forcing to the both legacy parties to negotiate an encryption key size of 1 byte.

When the vulnerability was released, a lot of devices were vulnerable to this.

The Bluetooth SIG published a security recommendation through a Security Notice that recommends a minimum encryption key length of 7 octets for BR/EDR connections. It should be implemented in the Controllers since in BR/EDR the encryption key size is negotiated in LMP (Link Manager Protocol) which is a communication between Controllers. The Bluetooth SIG also expedited an Expedited Errata Correction 11838 to handle this vulnerability and it applied to the specification core the following:

• The minimum encryption key size used for the LMP_encryption_key_size_req PDU shall be set to at least 7 octets
• All BR/EDR Controllers shall implement the Read Encryption Key Size command (0x1408).

Although some vendors implements the LMP_encryption_key_size_req to read the encryption key size, it is the Host which need to implement a security verification in order to avoid encryption key size with length under 7 bytes. An example of this is Intel, which published a white paper called "Intel® Bluetooth® Security –
Encryption Key Size Recommendation" after the vulnerability was published. In this white paper, Intel implements the Errata 11838 and the HCI event for read the encryption key size, but Intel Bluetooth Controllers allows the encryption key size from 1 byte to 16 bytes. Thus, It is the Host which need to verify that the encryption key size is not 1 byte (or better, is not lower than 7 bytes)

Encryption key size negotiation with Bluetooth LE

Roughly, the encryption key size is negotiated between Hosts.

In this case, like the "Max encryption key size" can be handle in Host; performing some modifications in the Linux Kernel we can send arbitrary value (from 1 to 16 bytes). In the following repository we can see the modifications. I have added the parameter "smp_encryption_key_size" to the subdirecotry core of /proc/sys/net; This parameter will be the encryption key size that our Host will use.

After the modification, the value can be retrieved using btmgm:

After this, if we perform a connection using LE, we can see through a packet sniffer (like Wireshark) that we are using the encryption key size we configured.

As I mentioned before, it is valid for LE, for BR/EDR the encryption key size is negotiated between Controllers and with this Kernel patch we can accept Encryption key size of that size, but We have not chance to set the value we want to negotiate via SMP.

Encryption key size negotiation with Bluetooth BR/EDR (classic)

Taking advantage through Internalblue vulnerability

Internalblue is a framework used to patch the Bluetooth firmware for Broadcom chips and It is used to implements tests and demos for known vulnerabilities.

As In our case we need to send 1 byte encryption key size, We need to patch the firmware of the Controller using this framework.
Once the firmware is patched, when we perform a pairing, during the LMP negotiation of the key size, 1 byte encryption key size will be sent.

Testing KNOB attack

Although It is possible to perform the connection using the Internalblue framework, once the encryption key size is configured to 1 byte. Always that We perform a connection with a new device and the LMP encryption key size is negotiated, 1 byte encryption key size will be sent.

Thus, in the following images we can see that the remote Bluetooth device reject the connection in the Controller.

A lot of Controllers still accepting 1 byte encryption key size, and recommend implements a mitigation in the Host side.

In the following image we can observe how Raspberry Pi (foobar) tries to negotiate 1 byte key size:

Differences

As you can see; the differences are notorious; and you can not apply the same Proof of Concept for LE than BR/EDR

Bonus

Coming back to the SFRs, looking the certificates emited in CC and how there have been performed. Certificates have fullfill the SFR by performed doing modifications in Linux Kernel, which is correct for LE. But only performing modification in the kernel is not enough for BR...