BIAS: a Bluetooth attack that allows spoofing a paired device

A few days ago, Researchers from the Federal Polytechnic School of Lausanne released that they have identified vulnerabilities in matchmaking methods devices that meet the standard Bluetooth Classic (Bluetooth BR / EDR).

The vulnerability is codenamed BIAS and the problem allows the attacker to organize the connection of his fake device instead of the device from a previously logged in user and successfully passing the authentication procedure without knowing the channel key (link key) generated during the initial pairing of devices and allowing without repeating the manual confirmation procedure on each connection.

The essence of the method is that when you connect to devices that support Secure Connections mode, the attacker announces the absence of this mode and reverts to using an outdated authentication method ("inherited" mode). In "legacy" mode, the attacker initiates the master-slave role change, and presenting his device as "master", takes over the authentication procedure. Then the attacker sends a notification about the successful completion of the authentication, without even having a channel key, and the device authenticates itself to the other side.

The Bluetooth Spoofing Attack (BIAS) can be performed in two different ways, depending on which Secure Simple Pairing method (either Legacy Secure Connections or Secure Connections) was previously used to establish a connection between two devices. If the pairing procedure was completed using the Secure Connections method, the attacker could claim that it is the previously paired remote device that no longer supports secure connections, reducing authentication security. 

After that, the attacker may succeed in using too short an encryption key, containing only 1 byte of entropy and apply the KNOB attack developed previously by the same researchers to establish an encrypted Bluetooth connection under the guise of a legitimate device (if the device has protection against KNOB attacks and the key size could not be reduced, the attacker will not be able to establish an encrypted communication channel, but will continue to be authenticated to the host).

For a successful exploitation of vulnerability, the attacker's device needs to be in range of the vulnerable Bluetooth device and the attacker you must determine the address of the remote device to which the connection was previously made.

The researchers published a prototype toolkit implementing the proposed attack method and demonstrated how to spoof the connection of a previously paired Pixel 2 smartphone using a Linux laptop and a CYW920819 Bluetooth card.

The BIAS method can be performed for the following reasons: establishing a secure connection Bluetooth is not encrypted and the selection of the secure connection pairing method does not apply for an already established pairing, establishing a secure connection for Legacy Secure Connections does requires mutual authentication, a Bluetooth device can perform a role change at any time after baseband search, and devices that have been paired with Secure Connections can use Legacy Secure Connections while establishing a secure connection.

The problem is caused by a memory defect and manifests itself in multiple Bluetooth stacks and the firmware of the Bluetooth chips, including Intel, Broadcom, Cypress Semiconductor, Qualcomm, Apple and Samsung Tokens used in smartphones, laptops, single-board computers, and peripherals from various manufacturers.

Researchers tested 30 devices (Apple iPhone / iPad / MacBook, Samsung Galaxy, LG, Motorola, Philips, Google Pixel / Nexus, Nokia, Lenovo ThinkPad, HP ProBook, Raspberry Pi 3B +, etc.), which use 28 different chips, and notified manufacturers of vulnerability last December. It is not yet detailed which of the manufacturers has released firmware updates with the solution.

Given this, the organization Bluetooth SIG responsible for the development of Bluetooth standards announced the development of an update to the Bluetooth Core specification. The new edition clearly defines the cases in which a master-slave role switch is allowed, there is a mandatory requirement for mutual authentication when reverting to 'legacy' mode, and it is recommended to check the encryption type to avoid a decrease in the connection protection level.


The content of the article adheres to our principles of editorial ethics. To report an error click here!.

Be the first to comment

Leave a Comment

Your email address will not be published.



  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.