Rejection of legacy pairing

BR/EDR

BLE

Various pairing methods are used in Bluetooth. One of these methods is known as Legacy pairing designed to simplify the connection between devices with limited computational capabilities. Due to this limited computational capability, key generation for Legacy pairing uses obsolete and insecure algorithms.

During the initial phase of pairing, there is an exchange of characteristics called Pairing Feature Exchange, which determines the type of key generation method that can be used, either long term key (LTK) or short term key (STK). STK keys are generated with Legacy Pairings and should, therefore, be avoided.

It is recommended to use pairing in the LE Secure connection mode whenever the device’s capabilities allow for it.

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