There are several ways to secure BLE device communications. One way is to randomize the MAC address of the device. This is an effective way to thwart passive tracking and device spoofing attacks.
If you are developing a BLE device, make sure to implement MAC address randomization in conjunction with other security measures, such as the passkey entry or numeric comparison LE secure connections’ pairing methods, to provide the best security for your device and its data.
The Problem With The Static Bluetooth MAC Address
The Bluetooth MAC address is a unique identifier assigned to each Bluetooth device. This 48-bit MAC address is typically assigned by the manufacturer and is hard-coded into the device hardware. So it never changes. This is the first problem.
This static BLE MAC address is included in the advertisement packets of the device and is how other devices know how to connect to it. Remember that advertisement packets are not encrypted. They are always sent in the clear plaintext and can be easily monitored by anyone within range. This is the second problem.
These two problems make it possible for someone to passively track a BLE device by monitoring the advertisement packets and looking for the static MAC address.
For example, consider a scenario where you are using a BLE-enabled fitness tracker. The fitness tracker continuously broadcasts advertisement packets as it looks to announce its presence for a connection to the smartphone. These packets include the static MAC address of the device.
An attacker could use a sniffer to monitor the advertisement packets and record the MAC addresses of devices in range. Later, when you walk by the same location, the attacker sees the same MAC address in the sniffer logs, they would know that it is likely the same device (i.e. the fitness tracker) and therefore you.
The attacker is using the static MAC address to track the location of the device over time. This is how passive tracking works.
The example we just shared was actually discovered by a group of researchers in this recent study. User tracking by monitoring the device’s static BLE address is feasible.
How can we mitigate this problem? I am glad you asked.
The Solution: Bluetooth MAC Address Randomization
MAC address randomization is a process of generating MAC addresses that cannot be traced back to a specific device. MAC addresses are randomly generated and changed periodically, making it difficult for someone to track down a specific device.
The Bluetooth specification includes a feature known as Bluetooth LE Privacy, which causes the MAC address within the advertising packets to be replaced with a random number. This number changes periodically at intervals determined by the manufacturer, although the specification recommends that these intervals should be less than 15 minutes.
MAC address randomization helps prevent third-party observers from tracking your device. By randomly generating a MAC address, it appears as though multiple devices are being used, rather than just one. This makes it difficult to track an individual based on their MAC address.
As a result, MAC address randomization disguises a device’s identity and provides an additional layer of privacy and security for users.
Implementing MAC Address Randomization
To implement MAC address randomization in BLE, we have to use the random private address instead of the public address or the random static address.
Why should BLE device developers stay away from public addresses?
The public address is the MAC address that is bought from the IEEE and is used as the device’s identity. The public address does not change.
What’s wrong with that?
The problem is that the public address can be sniffed and used to track the device. Also, it is possible to infer the identity of the manufacturer through the public address. This could be useful for an attacker who wants to target a particular manufacturer’s devices.
Random static addresses, on the other hand, are generated randomly, but they stay the same over time. They do not change during the power cycle of the device. So while they are not as easy to track as public addresses, they are still static and can be used to track a device’s location over time.
The only way to truly prevent tracking is to use a random private address. There are two types of random private addresses you can choose from during device development: resolvable private addresses and non-resolvable private addresses.
You can find more information about the different BLE device addresses in our previous post.
1. Resolvable Private Addresses (RPA)
A resolvable private address is generated randomly, so an attacker cannot trace it back to a particular manufacturer. It is also not static, so it cannot be used to track a device’s location over time.
The benefits of using an RPA are not just limited to its ability to hide the device’s real address. It is resolvable.
Your device can broadcast random RPA MAC addresses to other devices. If these devices are paired with or explicitly trusted by your device, they will be able to resolve the MAC addresses into your device’s real MAC address.
The way that RPAs are resolved is through the use of an Identity Resolving Key (IRK). A device using RPA generates the IRK and distributes it to trusted devices during paring.
2. Non-Resolvable Private Addresses (NRPA)
A non-resolvable private address is also generated randomly and cannot be traced back to a specific manufacturer. It is also not static, so it cannot be used to track a device’s location over time.
The benefits of using an NRPA are that it is truly private and cannot be resolved by any other devices, even if they are paired with or explicitly trusted by your device. It always hides the real address of the device.
MAC address randomization is becoming more and more important as the number of Bluetooth-enabled devices increases. If you’re not already using it, we urge you to start implementing it on your devices as soon as possible. Not only will this keep your device safe from eavesdropping and tracking, but it will also help to ensure that your customers’ data remains confidential.