1. Security concerns with Bluetooth® LE
Bluetooth® LE devices are constantly advertising.
Their advertisement data may contain information related to the device: type, manufacturer, capabilities, and advertising address.
This address is a unique identifier, represented by the 6-byte MAC address.
A static MAC address associated with the signal strength of the advertisement may result in the location of the device.
| Bluetooth® LE devices tracking |
|---|
 |
Bluetooth® LE specification provides a way to randomize and change periodically the MAC address in advertising packets.
This is allowed by the feature Bluetooth® LE privacy.
| Bluetooth® LE tracking protection using random private address |
|---|
 |
2. Bluetooth® LE privacy
The Bluetooth® LE privacy feature reduces the ability to track a device over a period of time by changing the device address on a frequent basis.
The address of a device using privacy mode is either resolvable private address (RPA), or non-resolvable private address (NRPA).
A resolvable private address (RPA) can be resolved using the identity resolving key (IRK), which is one of the encryption keys exchanged during the pairing process. The IRK is derived from Identity Root (IR) value, according to Bluetooth® Core Specification the IRK can be assigned, or randomly generated by the device during manufacturing, that's why IR value shall be different from device to device.
There are two variants of the privacy feature:
- Host-based privacy: private addresses are resolved and generated by the Host
- Controller-based privacy: private addresses are resolved and generated by the Controller without involving the Host. Host only provides the device identity information.
When controller privacy is supported, device filtering is possible since address resolution is performed in the controller (the peer's device identity address can be resolved prior to checking whether it is in the filter list).
The local device adds the remote devices in the resolving list (to maintain remote device identity addresses) along with the IRKs. Controller privacy also enables the resolution, allows to set the privacy mode, and allows connections to the remote device by specifying the remote identity address.
Refer to Bluetooth® Core Specifications [1] for more details.
3. Bluetooth® LE Addresses and Privacy
Bluetooth® LE devices have an identity address associated with each device.
A Bluetooth® LE address is a 48-bit value that uniquely identifies a Bluetooth® LE device.
There are two main types of Bluetooth® LE addresses: public and random addresses.
| Bluetooth® LE Address types |
|---|
 |
The four Bluetooth address types are:
- Public Address
- Random Static Address
- Random Private Resolvable Address
- Random Private Non-Resolvable Address
Random Address and Private Address, as shown in the diagram, are simply classifications.
3.1. Public address
Bluetooth’s LE public address is a constant worldwide address, that is, it never changes and is registered with IEEE. The public device address must conform with the IEEE 802-2001 standard, using a valid organization unique identifier (OUI) obtained from the IEEE registration authority. It abides by the same guidelines as MAC addresses, and is an extended unique identifier EUI-48.
The following diagram represents the simplified format of a public Bluetooth® LE address (LSB first):
| Bluetooth® LE public address | ||||
|---|---|---|---|---|
|
- Company ID: the publicly assigned portion of the address by the IEEE (MSB)
- Company assigned: the internally assigned ID as part of the allocated block (LSB)
3.2. Random address
Random addresses do not require any registration with the IEEE.
A random address is an identifier that is either programmed into the device, or generated at runtime. The latter depends on the subtype.
The two subtypes of Random addresses are:
- Random static address
- Random private address
3.2.1. Random static address
This specific type of Bluetooth® LE address serves as a popular alternative to public addresses since there are no fees involved with its use.
Random static addresses can be used in one of two ways:
- It can be assigned and fixed for the lifetime of the device.
- It can be changed at bootup.
However, it cannot be changed during runtime.
The format of random static addresses looks like this (LSB first):
| Bluetooth® LE random static address | |||
|---|---|---|---|
|
- The two most significant bits (MSB) need to be set to 1.
- The remaining 46 bits are chosen randomly by the developer/manufacturer and have to meet the following requirements:
- At least one bit of the random part of the address must be 0.
- At least one bit of the random part of the address must be 1.
There are two types of random private addresses:
- Resolvable
- Nonresolvable
Random private addresses are used specifically for protecting the privacy of a Bluetooth® LE device to hide the identity and prevent the tracking of the device.
3.2.2. Resolvable random private address
The purpose of a resolvable random private address is to prevent malicious third-parties from tracking a Bluetooth device while still allowing one or more trusted parties to identify the Bluetooth® LE device of interest.
A resolvable random private address is “'resolvable”' by using a key shared with a trusted device.
This key is referred to as the identity resolving key (IRK).
The address is originally generated using this IRK and a random number.
So, what makes a device “trusted” by another device?
In this case, a trusted device is a bonded device. Bonding is the optional step that takes place after the pairing of two Bluetooth® LE devices.
The bonding process involves the storage of keys inside the devices that are bonded with each other.
One of the keys exchanged by the two bonded Bluetooth® LE devices is the IRK.
This type of address changes periodically. The recommendation per the Bluetooth specification is to have it change every 15 minutes.
The format of resolvable private addresses looks like this (LSB first):
| Bluetooth® LE resolvable private address | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
- 0 and 1 are fixed in the most significant bits (MSB).
- The next 22 bits are randomly generated.
- The prand constitutes most of the significant 24 bits
- The lower 24 bits represent a hash value, which is generated using the prand and the IRK.
3.2.3. Non-resolvable random private address
The other type of random private address is the non-resolvable random private address.
This type of address also changes periodically. However, unlike resolvable addresses, it is not resolvable by any other device.
The only purpose of this type of address is to prevent tracking by any other Bluetooth® LE device.
This type is not very common, but it is sometimes used in beacon applications.
The format of nonresolvable random private addresses is as follows:
| Bluetooth® LE nonresolvable private address | |||
|---|---|---|---|
|
- Bits 0 and 0 are fixed in the most significant bits (MSB). - The remaining 46 bits are chosen at random.
4. How to configure and use private address
In this section all the steps needed to configure and use a private address are described.
4.1. Chose identity address type
Even if privacy is enabled, there is still the need to chose the type of the identity address of the device. In fact the identity address is sent to the peer during the Transport Specific Key Distribution phase of the pairing. It may be either a public address or a static random address. It is defined with CFG_BD_ADDRESS_TYPE in app_conf.h. If public address is chosen as the identity address (CFG_BD_ADDRESS_TYPE defined as HCI_ADDR_PUBLIC), the address must be specified by the application with aci_hal_write_config_data(). This is usually done inside BLE_Init() function.
void BLE_Init(void) {
...
// write public address at public address offset
aci_hal_write_config_data(CONFIG_DATA_PUBADDR_OFFSET, CONFIG_DATA_PUBADDR_LEN, bd_address);
...
}
If a static random address is used as the identity address (CFG_BD_ADDRESS_TYPE defined as HCI_ADDR_STATIC_RANDOM_ADDR ), there is no need to specify a public address. In this case, whenever it is needed, the Bluetooth stack will use a static random address automatically generated after first call to aci_gap_init(). This address is usually stored in last sector of Flash memory by the NVMDB module.
4.2. Initialize the GAP layer
The privacy must be enabled by specifying the appropriate privacy type while initializing the GAP layer. Privacy type 0x02, which means "Controller privacy enabled", is recommended in this case. This allows the Link Layer to automatically resolve the private addresses by using the resoling list and it also make it possible to use the Filter Accept List, if needed.
To enable privacy, CFG_BLE_PRIVACY_ENABLED macro can be set to 1 in app_conf.h. If this is done aci_gap_init() and aci_gap_profile_init() are called with privacy type set to 0x02.
privacy_type = 0x02;
aci_gap_init(privacy_type, CFG_BD_ADDRESS_TYPE);
aci_gap_profile_init(role, privacy_type,
&gap_dev_name_char_handle,
&gap_appearance_char_handle,
&gap_periph_pref_conn_param_char_handle);
4.3. Using private addresses
If privacy is enabled at GAP layer, the Bluetooth stack will only use a private address whenever an address must be present in any packet over-the-air. This means that private addresses will be used for advertising packets, scan requests and connection requests. In particular, only resolvable private addresses (RPA) will be used.
5. Resolving private addresses
The local device may decide to use or not private addresses. But what does it happen if peer device is using privacy? In this case, for several reasons, the local device could be interested in resolving the peer address to identify it.
If privacy is enabled by using controller privacy (privacy_type=0x02), address resolution is automatically enabled in the Link Layer. If privacy is not enabled on the local device, address resolution can still be enabled by calling hci_le_set_address_resolution_enable().
If Controller address resolution is enabled and the peer identity address is added to the Resolving List, the Bluetooth stack can automatically report the resolved address inside the LE Enhanced Connection Complete event. Identity addresses can be also specified when initiating connections: the Link Layer will be able to connect to the specified device even if the peer is using a resolvable private address. The identity address of a bonded device can be added to the Resolving List with one of the following methods:
- implicitly, by using aci_gap_configure_filter_accept_and_resolving_list(), which can add all the bonded devices to the Filter Accept and/or the Resolving Lists.
- explicitly, by using aci_gap_add_devices_to_filter_accept_and_resolving_list().
If a device is not added to the Resolving List or Controller address resolution is not enabled, aci_gap_resolve_private_addr() may still be used to resolve the peer address. However, the Filter Accept List cannot be used for devices not added to the Resolving List. Moreover, identity addresses cannot be used as a parameter for the peer address when initiating a connection.
6. References