Hardwear.io Interview: BlueMirror – Defeating Authentication in Bluetooth protocols
Bluetooth communication has become a standard for many handheld devices, personal computers, and local area networks. Since the protocol was first published, it has gone through many improvements. Security researchers and hackers have subjected Bluetooth devices and the protocol to security tests and analysis. The most recent discovery has to do with the key agreement protocols of Bluetooth. This topic will be presented at Hardwear.io by Tristan Claverie and Jose Lopes Esteves. We have asked both of them a few questions:
Bluetooth has come a long way from the first attacks almost twenty years ago. Are there fundamental design weaknesses that impact Bluetooth security up to newer protocols?
If we look at recent protocols (the most recent ones being the ones standardized for Bluetooth Mesh), there is still the ability for two devices to perform an unauthenticated key agreement and implementations must support this case. Although devices may be configured otherwise (e.g. only accepting authenticated connections), this element is common to all Bluetooth technologies : BR/EDR,
BLE and BM. Because of that, an active attacker is able, no matter the technology, to downgrade the key agreement from authenticated protocols to unauthenticated ones, and to complete a MitM on it. Protecting against that would require either to discard unauthenticated protocols from the standard/from implementations or to provide the user leverage to not use them. As it is now, it is the device manufacturers’ responsibility to be aware of the quirks of Bluetooth key agreements and to properly configure their devices. This is (in our opinion), the most impactful design weakness in terms of security for Bluetooth protocols, although it is not the subject of our study.
Can you give a brief description of how the weaknesses your discovered impact Bluetooth communication?
If we’re talking about BLE and BR/EDR, the main weakness we found impacts the initial key agreement (Pairing) between two devices. Even if two devices were configured to accept only the most secure mode, we showed that it’s possible to still complete one of the secure key agreement and to access security-sensitive services on one of the legitimate device.
If we’re talking about Bluetooth Mesh, the attacks discovered also impact the initial key agreement (Provisioning) when a device joins a Mesh network. Unless the device is configured to transmit its public key out of band (i.e. using an unspecified communication mean, but not on the Bluetooth channel), it’s possible for an attacker to pose as this device and to illegitimately join the Mesh network.
Bluetooth devices require firmware. How critical is vendor cooperation for Bluetooth security?
Vendor cooperation is necessary, but not enough.
The industrial ecosystem ranging from the consortium elaborating the standard to the end user devices implementing parts of the protocol and integrating dedicated hardware share responsibility in the effective security for the end user’s information.
As a result, many actors have a role in the overall security of the protocol.
Interestingly, in the case of the Bluetooth protocol family, the end user is explicitly made responsible and involved in the security procedures but is unfortunately provided with too few information about his role and what is technically happening to endorse this responsibility properly.
On the responsible disclosure side, the national CERTs and the inter-CERT collaborations are getting structured to face this complexity and contribute to the coordination of the vulnerability disclosure in a way that (ideally) allows to rapidly reach every impacted entity (of the aforementioned ecosystem) and to perform remediation and public communication in the appropriate
timeline.
What are your recommendations to secure Bluetooth device communication against the attacks you found?
As always, when you have to pair or provision your Bluetooth devices, try to do so in a controlled environment. Be wary of elements that may look strange during the process : one device that appear paired but not the other, devices disconnecting by themselves, …
Due to the design choices of Bluetooth, the strength of underlying cryptographic mechanisms (authentication, integrity protection, encryption key size, …) is inherently limited and not up to today’s standards of 128 bits. As such, in case of significant security needs the security of the Bluetooth link can’t be relied upon and should be considered as untrusted.