Bluetooth link key removal

BR/EDR

BLE

After pairing between two devices, they store the link keys generated in this process so that they can be used in the future to establish new connections. Bluetooth devices must avoid deleting shared link keys when receiving new pairing requests. This can be exploited by attackers to hijack communications.

There are minor differences in this case between Classic Bluetooth and Low Energy Bluetooth:

  • In Bluetooth Classic (BR/EDR), for authentication and encryption functions, Bluetooth uses a shared key created during pairing, which is stored in a database on each device. Some Bluetooth devices delete this shared key when they receive a new pairing request that appears to come from the original device.

  • In Bluetooth Low Energy (BLE), after the phase 2 pairing, the Long-Term Key (LTK) and Short-Term Key (STK) are distributed, but only the LTK is stored to be reused in future reconnections. The standard does not describe the size and characteristics of the security database, and it is possible that a local device (initiator) whose MAC address is known may initiate a new pairing, leading to remove of this key from the remote device (responder).

sIn either of the two cases, this allows an attacker to force the disconnection between two devices and take advantage of the situation to establish a new pairing, thereby erasing the known key between the two legitimate devices.

This situation also enables the capture of a new legitimate pairing between both devices with the goal of obtaining the connection key, using brute force on the PIN code, which often has lower entropy than other parts of Bluetooth encryption.

This is a method of hijacking communications between two devices commonly referred to as Bluesnarfing. To prevent it, shared key removal should be restricted only when both devices are properly linked in an authenticated connection.

Description

For the following sections, we will consider A and B as two devices paired with each other and C as a device used for control verification.

To check if C can maliciously unpair B from A, different methods can be tried:

  • Impersonate device B and perform a pairing with A
  • Impersonate device B and initiate an authenticated connection with A without having a link key
  • Impersonate device B and initiate an authenticated connection with A with a fake link key

In the first case, if A does not comply with this check, it is possible that A will accept the new pairing and delete the old key.

In the second case, when attempting to initiate authentication, C’s driver will send the error “key or pin missing”. Some devices, upon receiving this error, delete the old key and become unpaired.

In the third case, C will fail authentication with A. Some devices, upon receiving a failed authentication, remove the shared key and become unpaired.

In either case, A should not delete the shared key, to prevent a third party from unpairing the two devices and subsequently trying to capture the link.

To check this control, the following resources may be useful:

ID Description
BSAM-RES-04 Bluetooth connections sniffing
BSAM-RES-05 Capture of a Bluetooth connection
BSAM-RES-06 Enabling debug mode on a Bluetooth controller
BSAM-RES-07 Sending and receiving HCI messages
BSAM-RES-09 Changing the attributes of a controller
BSAM-RES-10 Link key management on the host

Example case

We will use Wireshark with BTVS (btvs.exe -Mode wireshark) to capture packets for analysis.

We have a computer with Scapy installed, and a pair of Bluetooth headphones paired with a mobile phone.

The computer is impersonating the mobile phone using the scapy tool and tries to recover a previous connection with the headphones, which will be denied by the Link Key Request Negative Reply command.

Wireshark Link Key Request Negative Reply

The computer makes a new connection to the headphones, requesting the input/output capabilities -_IO Capability-_ with the IO Capability Request command.

Wireshark IO Caps Request

After sharing the IO Capabilities of both devices, a connection is established, notified by the Simple Pairing Complete command.

Wireshark Simple Pairing

After the establishment, a key negotiation process begins between the two Bluetooth controllers that cannot be recorded in Wireshark, but it ends with the notification of a new link key with the HCI_Link_Key_Notification command.

To verify that the headphones were susceptible to this attack, an attempt is made to connect from the mobile phone, and if they respond with the Link Key Request Negative Reply command, it means that it was possible to erase the link key and therefore a FAIL for this check.

External resources

  • Bluetooth Core V5.3, Vol. 3, Part H, Appendix B.1 DATABASE LOOKUP