Rejection of legacy pairing

BR/EDR

BLE

Various pairing methods can be used in Bluetooth. One of them is legacy pairing, designed for devices with limited computational capabilities. Due to these limitations, legacy pairing relies on obsolete and insecure key generation algorithms.

During the initial phase of the pairing procedure, devices exchange their respective capabilities through the Pairing Feature Exchange process. This exchange determines the derivation of the Long-Term Key (LTK), which is subsequently used to establish new connections in future sessions.

Whenever device capabilities allow it, pairing should rely exclusively on Secure Connections Only mode, as Legacy Pairing is considered insecure and should not be used in any scenario. Secure Connections provides modern cryptographic security that prevents known attacks targeting older pairing methods.

Description

In a Bluetooth pairing, a distinction is made between the device that initiates the Pairing Feature Exchange, referred to as the initiator, and the device that responds to these requests, known as the responder. During this exchange of features, one of the fields is called authentication requirements (AuthReq), and within this, we find the Secure Connections (SC) subfield of 1 bit. A value of 0 indicates that the device will use Legacy Pairing, while a value of 1 enables the use of LE Secure Connections.

It’s important to note that a device that supports the capability of LE Secure Connections can theoretically support connections of the Legacy pairing type, but this is not recommended based on the type of device and its intended use, which will be evaluated by an auditor.

To verify compliance with security controls, the following scenarios should be considered:

  • If the SC field is 0 in the initiator, it should result in a Pairing Failure response from the responder. This is considered satisfactory for the responder.

  • If the SC field is 0 in the responder, it should result in a Pairing Failure response from the initiatior. This is considered satisfactory for the initiatior.

  • If both devices have an SC field of 1, and the initiatior requests Legacy pairing, it should receive a Pairing Failure response from the responder. This is considered satisfactory for the responder.

  • If both devices have an SC field of 1, and the responder requests Legacy pairing, it should receive a Pairing Failure response from the initiatior. This is considered satisfactory for the initiatior.

Example case

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

During the Bluetooth pairing process between two devices, they exchange capabilities, initiated by the Pairing Request command. To indicate whether the connection is LE Secure Connection or Legacy pairing, the Secure Connection flag is used. In this case, it is set to 0 (False).

Wireshark Legacy Pairing Response

The device responding to the Pairing Request command has two options: disconnect because it does not support Legacy pairing, or continue with the connection using the Pairing Response command, indicating its supported Secure Connection flag. In this case, it is set to 0 (False).

Wireshark Legacy Pairing Request

Finally, both devices accept the insecure connection.

Wireshark Legacy Pairing Confirm

The result of the control will be FAIL if the device returns the Secure Connection flag with a value of 0 (False), or if it returns 1 (True) but we can respond that we will use the value 0 (False) and it accepts.

External references

  • Bluetooth Core V5.3, Vol. 3, Part H, Section 2.1 Introduction
  • Bluetooth Core V5.3, Vol. 3, Part H, Section 2.3.2 - IO capabilities
  • Bluetooth Core V5.3, Vol. 3, Part H, Section 2.3. Pairing Methods
  • Bluetooth Core V5.3, Vol. 3, Part H, Section 2.3.5.1 Selecting Key Generation Method
  • Bluetooth Core V5.3, Vol. 3, Part H, Section 2.3.5.5 LE Legacy pairing phase 2
  • Bluetooth Core V5.3, Vol. 3, Part H, Section 2.3.5.6 LE Secure Connections pairing phase 2