Role changes before encryption

BR/EDR

In a Bluetooth communication there are two defined roles:

  • Master: Is the main role of a “piconet” (network of Bluetooth devices) and defines the physical parameters of the connections.
  • Slave: Device that simply follows the steps of the master.

Role switching can be used by devices that can only act as slaves to avoid being masters of the connection. This role switching procedure usually takes place during the establishment of a connection and always before the authentication phase.

If it takes place between the authentication phase and the encryption phase, it could be used to attack the encryption phase and try to extract the temporary key used during a connection, attacking the confidentiality of the data of that connection. Therefore, it is preferable to deny the use of the role change mechanism after the authentication step if it is not necessary for the normal operation of the device.

Description

Since the role change occurs via a link layer mechanism (LMP or Link Layer), there are two possible options to verify that the device does not allow a role change after authentication:

  • By reviewing the source code of the driver firmware.
  • By sending a role change request after the authentication process, the response is captured to evaluate whether the change is allowed.

In order to send a role change request after the authentication process it is necessary to modify the usual flow of LMP messages and, therefore, it is necessary to have the ability to send and receive LMP messages. For this, it is usually necessary to modify the firmware of the Bluetooth driver used to perform the audit (not that of the audited device).

Modifications are required so that an LMP_switch_req message is sent just after authentication and before the start of encryption. The audited device may respond with an LMP_accepted message, indicating that it has accepted the role change and is not compliant, or with LMP_not_accepted, which would be the expected response from a compliant device.

In addition, to capture the response, it is necessary to be able to capture LMP messages, for which Bluetooth driver debug messages can be used: Broadcom drivers redirect LMP traffic to the host in the form of debug messages.

Para la modificación del firmware, es necesario disponer de un controlador Bluetooth que permita estas modificaciones y del que se disponga del código del firmware (o del que exista un trabajo de ingeniería inversa). Las modificaciones al firmware de la placa de desarrollo Cypress CYW920819EVB-02, realizadas para la investigación de BIAS, son de utilidad en este aspecto.

To check this control, the following resources can 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

Example case

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

There is a laptop with the Scapy tool that is performing pairing with the Peripheral role to another device with the central role. During the connection process, there is the possibility of performing an additional step called role switch.

Bluetooth Core 5.3 Connection Establishment

The Peripheral device receives the central device connection request through the HCI_Connection_Request command.

Wireshark Connection request

The Peripheral device response can accept the connection with the HCI_Accept_Connection_Request command, indicating its preference to work as a Central device by setting the Role field to a value 0x00 (Become Central for this connection. The LM will perform the role switch.).

If the remote device accepts this role switch, it will respond with the HCI_Role_Change command, and the Status field will have a value of 0x00 (A Role change has occurred.). Any other value would indicate an error code for the procedure.

To determine whether this role switch is occurring before or after the authentication process, the HCI_Link_Key_Request_Reply command followed by the HCI_Command_Complete command should be located in the Wireshark capture.

If the HCI_Accept_Connection_Request command appears after the two commands (HCI_Link_Key_Request_Reply / HCI_Command_Complete), it indicates a role switch before the encryption stage.

The check control FAIL if the HCI_Role_Change command with the Status field set to 0x00 is found before the encryption of the devices.