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.
Thereβll be quite a few ifs here:
β¦then it βmayβ be possible to compromise the session key.
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).
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.