Bluetooth link key removal

BR/EDR

BLE

After pairing, devices store the generated link keys so they can be reused in future connections. Bluetooth devices should avoid deleting these shared keys when receiving new pairing requests, as removing previously established keys can create scenarios that compromise the device’s security.

• If an attacker forces a disconnection and triggers a new pairing process, the device may erase the previously stored link key and generate a new one. This re‑pairing scenario allows the attacker to replace the legitimate key with one negotiated under their control, effectively enabling them to intercept or manipulate future communications.

• By forcing the user to repeat the pairing procedure, an attacker can also capture the new pairing attempt and exploit weaknesses in the process itself. This includes brute‑forcing the PIN code, whose entropy is typically lower than other components of Bluetooth security, or leveraging user confusion to trick them into approving an unauthorized pairing request.

This technique, commonly known as Bluesnarfing, allows an attacker to take control of the communication between two devices. To mitigate this risk, shared key removal must only occur when both devices are properly linked through 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.

Related resources

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

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.

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

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

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