BLURtooth: BLUR Attacks on CTKD
The Cross-transport Key Derivation (CTKD) between Bluetooth LE and Classic (BR/EDR) transports introduces various security issues depending on the actual configuration and use that have been recently brought forward by researchers of Purdue University. CTKD allows to pair on one transport, and use derivation of this key for other transport, i.e., as a link key for classic, or long term key for LE transport.
The key idea for the BLURtooth attacks is to pair on the transport with lower authentication requirements, and then connect on the transport with the higher authentication requirements which may not check the authentication requirements, and so gain access to its services. For example, one attack variant is facilitated by allowing pairing via LE without user interaction, e.g. by holding a button for a few seconds to enter pairing mode. In this case, an attacker may access also all Classic services without user interaction.
Another attack variant is for an attacker to impersonate a previously bonded and trusted device A to a device B by using A’s Bluetooth address. If pairing with device B over on transport is possible without user interaction and the host stack allows to overwrite a previously stored key, the attacker can fully impersonate device A on both transports and use its authorization.
For further details, please check the references bellow.
Vulnerability
BTstack (v1.1 and before) only supports CTKD from Bluetooth LE to Bluetooth Classic, and it wasn’t fully implemented until now. Therefore, it was not vulnerable to CTKD attacks. With the next master merge, tentatively called v1.2, the configuration for CTKD will be activated.
In response to the BLURtooth attacks, we made the following changes:
- The use of CTKD requires the new #define
ENABLE_CROSS_TRANSPORT_KEY_DERIVATION - Instead of disabling key overwrites as suggested by the authors, BTstack allows key overwrites only if the new key has at least the same security level as the overwritten one. As a result, a key derived from unauthenticated LE pairing (i.e. Just Works pairing) cannot overwrite an authenticated Classic link key.
Action
We recommend to enable CTKD only if needed/useful. If enabled, the authentication requirements on both transports should be the same, e.g. if MITM-protection is required for Classic transport, this should also be configured for LE. In this case, please make sure to set LEVEL3 (authenticated) for all Classic services in the corresponding register service call and also call gap_set_security_level(LEVEL3) for outgoing connections as well.