Technology News

Bluetooth LE’s anti-tracking technology beaten

Researchers have found a way around the Media Access Control (MAC) address randomisation feature used by Bluetooth Low Energy (BLE) to protect users and their devices from being identified and tracked.

For anyone unfamiliar with the ins and outs of BLE security (see below), the first and most surprising issue confirmed by Tracking Anonymized Bluetooth Devices from Boston University’s Johannes Becker, David Li, and David Strobinski, is that device makers have a lot of leeway in how they implement BLE security, or whether they need to bother at all.

But the team has now confirmed that even software where BLE device privacy is implemented carefully – Windows 10, macOS and Apple’s iOS being the stand-out examples – is a lot less secure than everyone has assumed.

Rabbit hole

The under-appreciated fact about Bluetooth is that behind its friendly ‘turn on, connect, forget’ reputation, the technology has gradually become one of security’s rabbit holes.

That’s mainly because it’s a 20-year-old standard that has evolved in a series of jumps, the most significant of which was the arrival of Bluetooth Low Energy (BLE, formerly Bluetooth Smart) in 2011.

Part of Bluetooth 4.0 (and its successor Bluetooth 5), the headline advance of BLE was its improved power consumption as well as its introduction of a sophisticated security and privacy architecture.

However, an unavoidable weak point was the need for a Bluetooth device to publicly ‘advertise’ itself without encryption to other devices around it without leaking details of that device to snoopers – BLE’s answer to which was something called address randomisation.

The principle is simple enough: instead of sending a single unique hardware MAC address during the unencrypted advertising process, you replace it with randomly generated ones that make each device look like lots of different ones so as to preserve its anonymity.

So how does a nearby device know what to pair with? In addition to the stream of randomised MAC addresses, BLE sends a ‘payload’ of identifying tokens.

This data varies by device and operating system (OS), but has to be consistent over time whilst also being unique to that device.

The researchers’ discovery is that data that fulfils these requirements can be isolated algorithmically to a degree of certainty in a given time period for a specific OS and device such as an iPhone.

But identifying devices temporarily isn’t terribly useful, which is why the team’s address-carryover algorithm…

… exploits the fact that identifying tokens and the random address do not change in sync, to continuously track a device despite implementing anonymization measures.

In other words, once you’ve nabbed the identifying tokens (or even the likely MAC address) you can continue tracking that through subsequent transmissions.

The arrival of Bluetooth 5 also expands the range of an adversary to possibly hundreds of metres from the target.

The main complication for an attacker trying to uncloak the identity of a device is that each device design implements the randomisation in a slightly different way, which means the technique isn’t universal. It probably also requires offline analysis.

Smart watching

The team recommends some simple fixes, the biggest of which is to synchronise the changing of randomised MAC addresses with payload tokens so attackers can’t alternate between the two sets of tracking data to extend tracking indefinitely.

Another recommendation is to start using address randomisation on low-power devices that today tend not to bother to save as much energy as possible. Furthermore, OS makers should be more careful about the patterns in their randomisation which can be used to identify one platform from another.

While a lot of this is simply proof-of-concept research, it’s not hard to imagine a world of the near future where BLE devices, including those using very low power modes, are absolutely everywhere. Thanks to research like this, there is still time to fix the teething problems.

[“source=nakedsecurity”]