Скрытие имен устройств bluetooth low energy

How to Protect the Privacy of Your Bluetooth Low Energy Device

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.

Conclusion

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.

Источник

Bluetooth Low Energy encryption and data safety

I can’t seem to find any documents that answer these questions unambiguously. Any ideas or pointers will be most welcome.

3 Answers 3

1. AFAIK, BLE pairing/encryption process is not flawed. There are however three levels of MITM protection available with encryption:
   • None, this uses a known key == 0, so if an eavesdropper catches all your packets in the pairing process, he can follow your encrypted connection.
   • Low MITM protection, this is when you use a user input pass key for pairing, with key < 1.000.000. Here the eavesdropper would only need to try a million keys.
   • High MITM protection, using an out-of-band key. This would give a full 128-bit strength for your encryption, and an eavesdropper would need to know the key to follow the conversation even if catching the whole pairing process. As there is no key-exchange method in BLE (yet, at least), the weakest point here would be the key distribution, but that would be the same problem as when having an additional layer of encryption at the application level.
2. This is implementation dependant. Your device doesn’t have to bond, i.e. establish a permanent relationship with the host. If the devices don’t bond, there is no state telling about earlier connections (other than exchanged data, but that is application domain, not BLE stack). If the devices are not bonded, they would have to pair again the next time they connect to exchange protected data. If the devices are bonded, the encrypted connection can be continued without app/user interaction, with the same security level as earlier. For one-time-connect devices, bonding doesn’t make sense, so you can have a stateless implementation with no restrictions on number of connected devices. For multiple-times-connect, you could also have a stateless implementation, depending on how you distribute/store the key(s) which is then independent of BLE. The availability of the different options here depends on the device/BLE stack implementation you are using, though, but the spec allows all this.
3. If you bond and thus exchange long term keys etc, these can, dependent on the BLE implementation you’re building on, be stored however you like.
4. As I said under 2., you can establish a secure (encrypted) connection without bonding. The devices then need to pair again the next time they want to establish a secure connection. If you don’t want to/aren’t able to pair for some reason, then you can have only plaintext communication.

Hi @Pappnese, Your points are much in the line of what we have found ourselves. For the moment, we have landed on a decision to add out own encryption layer on top of the BT protocol stack, and then go for the non-bonding BLE comm protocol. Thanks for your answer.

Thanks, that is very informative. Just to clarify: In LE/Smart, there is no equivalent to Bluetooth secure simple pairing, which uses a Diffie-Hellman exchange to avoid passive key eavesdropping?

I have a related fundamental question: is encryption on BLE (4.0+) actually mandatory by design? IIRC, Bluetooth 2.1 offers encryption as an option since there’s a non-secure mode.

I’ll take a stab at this one.

1) My understanding of the pairing process is the same. If the data were sensitive enough, I would add an independent layer of encryption of my own in my application.

2) For connections, the BLE protocol is limited to one host per device at the same time, even when the connection is not bonded/paired. The only way for a single device to establish a connection to more than one host at the same time is if the device somehow ‘pretends’ to be multiple devices. Whether or not this can be done will be hardware dependent and it is definitely not one of the standard ways to use a device. Even if you can trick the hardware into doing that, you may run into unavoidable problems such as the occurrence of (nearly) overlapping connection intervals, which may cause you to lose data and eventually even established connections.

Another way for a device to communicate with multiple hosts is to regularly disconnect and let another host establish connection. AFAIK, there is no special protocol support for this technique, so beyond perhaps using directed advertising you may not have much control over which host connects next and when it does so.

See also Section 4.1.2 in Volume 1, Part A of the ‘Core_V4.0’ bluetooth spec (e.g. from here https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737 )

3) Most likely yes, the details will vary by vendor, but with the limitations mentioned above.

4) You can establish a connection without bonding/pairing. That connection will allow communication, but it will be plaintext without any security. AFAICS, the only way to do this right is to use you own data protection at the application level.

Источник