Analysis of Bluetooth Impersonation Attack (BIAS) Vulnerability Principle

Preface

Boffins disclosed a Bluetooth security vulnerability called BIAS (CVE-2020-10135), which can be used by attackers to spoof remote pairing devices. Researchers at Hat Laboratory made a detailed analysis of the vulnerability.

In the world of Bluetooth Classic, link key is the cornerstone of security. According to Bluetooth Core Specification 5.2, we have three types of link keys, which are:

  • Combination key
  • Temporary key
  • Initialization key

In this article, we focus on the combination key. The link key is shared by two paired BR/EDR devices and it mainly has the following two functions:

  1. When the paired device connects to the other party again, it will use link key authentication:

image.png

  1. After the authentication is passed, both parties can use the link key to export the encryption key used to encrypt the subsequent communication data.

image.png

The BIAS (Bluetooth Impersonation AttackS) vulnerability analyzed in this paper has affected the former, while the latter has also exposed KNOB (Key Negotiation Of Bluetooth) vulnerability. In summary, BIAS bypasses the authentication mechanism of BR/EDR devices by using the following three points:

  1. Legacy authentication allows unilateral authentication

  2. Secure authentication is negotiable for demotion to Legacy authentication

  3. Classic Bluetooth allows master and slave roles to be switched

The following will analyze these three weaknesses respectively.

Legacy Authenticationd Unilateral Authentication

Legacy authentication defines two roles: verifier and claimant. The specific authentication process is as follows:

image.png

At first, verifier sends a random number RAND to claimant to challenge it. After that, verifier and claimant will use the fixed algorithm E1 locally to calculate SRES (Signed Response):

SRES = E1 (link_key, claimant_bd_addr, RAND)

At the same time, claimant will pass back the calculated SRES to verifier. Verifier compares the SRES to its own SRES ‘if the SRES is the same. If the SRES’ is the same, the authentication passes.

It can be seen that legacy authentication does not force claimant to verify verifier’s identity in turn. Then the attacker can disguise himself as a verifier, skip the comparison between SRES ’and SRES without knowing the link key, and directly let the claimant pass the authentication.

Secure Authentication Demotion

In 2020, the vast majority of BD/EDR devices support secure authentication and are enabled by default. The specific authentication process is as follows:

image.png

As can be seen from the above figure, this authentication method is bidirectional, so the weakness of unilateral authentication of Legacy AuthenticationD cannot be directly exploited. However, in order to be compatible with older devices that only support legacy authentication, Classic Bluetooth allows devices to negotiate authentication methods. If one device only supports legacy authentication, secure authentication will not be enabled.

Specifically, secure authentication is enabled only when the controller and host of both devices support the secure connection feature. An attacker can then spoof a device that does not support the secure connection feature, thereby downgrading secure authentication to legacy authentication, thus continuing to exploit the weakness of one-sided authentication of the old authentication methods:

image.png

Remarks:

  1. Modify it to be False here.

Master and Slave Role Transition

When an attacker exploits the unilateral authentication vulnerability of legacy authentication to attack a target, he may not know whether the target’s upper application requires master authentication slave or slave authentication master, that is, he is not sure whether he should play slave or master.

However, Classic Bluetooth allows the role conversion between master and slave. The specific process is as follows:

image.png

In this way, attackers can flexibly switch their roles, make themselves verifier, and always take the initiative.

Summary

What needs to be made clear is that although BIAS can bypass authentication, it still cannot obtain link key, that is, it cannot interact with the target for encrypted data after authentication. However, this restriction can be broken through by KNOB, so the combination of BIAS + KNOB is powerful and has shaken the foundation of classic Bluetooth security.

In addition, the premise of BIAS attack is to obtain the addresses of other devices that have been paired with the target device. This address is used to skip the pairing process and directly enter the authentication process with vulnerabilities after initiating the connection.

References

  • BIAS
  • BLUETOOTH CORE SPECIFICATION Version 5.2 Vol 2, Part F page 723, 4.1 AUTHENTICATION REQUESTED
  • BLUETOOTH CORE SPECIFICATION Version 5.2 Vol 2, Part H page 972, 5 AUTHENTICATION
  • BLUETOOTH CORE SPECIFICATION Version 5.2 Vol 2, Part H page 982, 6.4 E3-KEY GENERATION FUNCTION FOR ENCRYPTION

Author

Sourcell.xu @ HatLab - DBAPPSecurity