Bluetooth vuln CVE-2018-5383 explained

Yesterday a vulnerability, CVE-2018-5383 (https://www.kb.cert.org/vuls/id/304725) was released in the security specification for Bluetooth, with the title “Bluetooth implementations may not sufficiently validate elliptic curve parameters during Diffie-Hellman key exchange”. It was given an adjusted CVSSv2 score of 5.7 – so roughly a medium risk.

TL;DR

So, what does this really mean for an attacker?

There’ll be quite a few ifs here:

• if the device is being paired (or bonded)
• if the device doesn’t validate public keys
• if the devices uses LE Secure Connections or BR/EDR Secure Simple Pairing

…then it “may” be possible to compromise the session key.

In detail…

The vulnerability only effects BR/EDR Secure Simple Pairing and LE Secure Connections which use elliptic-curve Diffie-Hellman (ECDH) key exchange to swap keys to set up a private encryption key.

The vulnerability is that the specification does not require validation of the public key passed during the ECDH key exchange. This means that if an attacker is within Bluetooth range (~10 metres depending on a number of factors) during a key exchange then they could inject an invalid public key, which makes it easier to discover the actual shared key used to encrypt the communication.

As the specification doesn’t require validation, the impact depends on the device itself: if it validates the public key then things should be fine. If it doesn’t then it may be vulnerable.

The version of Bluetooth is also important.

For BLE, it affects only LE Secure Connections, this requires a device that supports Bluetooth 4.2 and uses LE Secure Connections on one or more of its characteristics. I have tested a lot of BLE devices and have still yet to see a device which requires pairing to access a characteristic.

For BR/EDR (i.e. Bluetooth classic) this requires a device that uses Bluetooth 2.1 (which is most things) and uses BR/EDR Secure Simple Pairing (which, again, is most things).

Conclusion

For the BLE side, the attack won’t affect many devices as most devices don’t use LE Secure Connections.

For classic Bluetooth (BR/EDR), then there may be vulnerable devices depending on the exact implementation.

In all cases the attacker has to be present during pairing and we’re not aware of a depairing/deauth attack.

However it’s an interesting attack showing omissions within the standards, a lack of public key validation and you should update your Bluetooth stack.