Bluetooth has become one of the most widely used technologies for modern connectivity, powering everything from audio devices to industrial sensors and automotive systems. However, this widespread adoption brings specific security challenges. This article describes the concept of Bluetooth relaying (or relay) attacks and its potential impact.
The concept
The core idea of Bluetooth relaying attacks is to exploit the trust relationship between devices that authenticate each other without strictly verifying their real physical proximity. This enables attackers to gain unauthorized access without necessarily breaking the underlying cryptographic protocols.
Gaining unauthorized access typically involves intercepting and forwarding communication signals between two legitimate parties, such as a smartphone and a smart lock in real-time. The scenario would be the attacking party being in a machine-in-the-middle (MitM) position between the attacked devices, creating an artificial extension of the communication range, thus relaying the communication.
NOTE: Due to the phonetic similarities relay attacks are sometimes confused with replay attacks. Contrary to relay attacks, replay attacks typically replay a previously captured connection to one of the attacked devices.
For such an attack, two Bluetooth devices are used to each impersonate one of the target devices in order to trick the target devices into connecting to the attacking devices. Both attacking devices then act as a transparent bridge by forwarding signals between the target devices in real-time, even over a longer distance. Thus, the attacking devices are effectively tricking the target devices into believing that they are in close proximity, although they might actually be kilometers away.
Targets
The most valuable targets for such an attack are different kind of locks, e.g.:
- Car locks
- Bike locks
- Home locks
- Pad locks
Most manufactures offer some form of proximity-based unlocking, sometimes called keyless unlocking. Even though this is a big selling point for such locks, proximity-based unlocking also makes most of them prone to relay attacks without user interaction.
Exemplary attack
For demonstration purposes, SySS GmbH performed a Bluetooth relay attack on a bike lock.
As a key for the lock, a smartphone – set up with the bike lock’s app – was used. The app was configured to automatically open the lock once the smartphone is in close range to the lock.
The described machine-in-the-middle (MitM) position is achieved using two Bluetooth dongles.
One communicates directly with the lock (hci0) impersonating the phone, while the other (hci1) pretends to be the lock towards the smartphone of the victim.
As a proof of concept, the dongle communicating with the lock was placed together with the lock in a metal box and sealed with aluminum foil to shield the lock from the smartphone, in order to simulate a physical out-of-range distance between the devices:
The second dongle, intended for communication with the smartphone, was connected to a USB extension cable and positioned as far away as possible (Thanks to my feline assistant Bobby for the support):
After that, a relay was started using WHAD:
1
$ sudo wble-proxy -i hci0 -p hci1 <mac-address of the lock>
When the smartphone – with the lock app running in the background – approaches the Bluetooth dongle attached to the USB extension cord sufficiently, the app automatically sends the unlock command. This command is then forwarded to the Bluetooth dongle next to the lock and subsequently transmitted to the lock to open it.
Analogously, attackers can place one Bluetooth-capable device (e.g.: Raspberry Pi, Flipper Zero, Notebook, Smartphone, etc.) near the bicycle lock and the other one near the victim. The two devices are then connected Out-of-Band (OoB) – for instance via the Internet – to perform the relay attack and open the bike lock.
Mitigation possibilities
-
Manual user interaction: The best countermeasure against consequences of relay attacks targeting locks is to simply disable automatic proximity-based unlocks. Requiring explicit manual interaction (e.g., tapping a button in an app) prevents the system from trusting the signal solely based on its presence. The likelihood of triggering relayable unlock signals is thereby drastically reduced. This does not, however, mitigate relay attacks themselves, but rather prevents a realistic exploitation of the attack.
-
Latency measurement: A more technical approach involves measuring the time delay of signals to infer the real distance between devices. This method is already utilized by some car manufacturers to attempt to distinguish between local and relayed signals. However, some circumventions appear to already exist that attempt reducing the delays (caused by the relay) to such an extent that the permissible time window is not exceeded.
-
Additional factors: Some researchers suggest the usage of additional technologies like Ultra-Wideband (UWB). Thanks to UWB’s more precise time-of-flight (ToF) measurements, the permissible time window used for latency measurements could be narrowed to such an extent that the delay caused by a relay would be more clearly detectable.
-
Location comparison: Another idea could be to compare the known location of the lock with the current location of the smartphone after connection. The unlock command is then only sent if the locations match. However, this method could be imprecise and may introduce delays while waiting for a precise localization of the smartphone (e.g. a good GPS signal). It would probably work better for static locks, such as door locks, compared to mobile ones like bicycle locks.
Core problem
Bluetooth locks tend to not support standardized pairing and bonding, as this would stop manufactures from allowing users to share access to their locks between multiple devices.
This is, for example, necessary when a user wants to share the control over a lock with a friend, without pairing the friend’s smartphone with the lock beforehand.
The advantage if bonding could be used would be that an impersonation of the devices would be harder, as a normal Bluetooth connection between the attacking devices and the victim devices would fail.
However, even if manufactures would use paring and bonding, more complex low-level relaying of lower-level Bluetooth signals or even the raw radio signals remains still possible.
The fundamental problem – that Bluetooth communication can be relayed (in one way or another) – is therefore not mitigateable per se! The mitigation possibilities therefore only include either, ways to reduce the realistic exploitation of relay attacks, or ways to detect them.
Conclusion
Generally speaking, to reduce the impact of relay attacks, it is advisable to avoid any form of automatic proximity-based actions. In other words: it is recommended to rely on manual confirmation when performing security relevant tasks, such as opening locks.