BLE v4.2: Creating Faster, More Secure, Power-Efficient Designs—Part 2
This file type includes high-resolution graphics and schematics when applicable.
In part one of this article series, we covered the Data Length Extension (DLE) and low-power capabilities of Bluetooth Low Energy (BLE) 4.2. In part two, we will discuss the privacy feature in Bluetooth Low Energy, additions to Bluetooth 4.2, and how these changes makes BLE devices more private and power-efficient.
Privacy is the ability of a BLE device to prevent it from being tracked by an untrusted device. BLE devices use a 48-bit address in the advertisement packets. If this address can be decoded by another device, it can track the movement of the advertising BLE device.
To maintain the privacy of BLE devices, trusted BLE devices use a shared secret known as an Identity Resolving Key. Two BLE devices that contain this shared secret can identify each other. The shared secret is used to generate a random address known as a Resolvable Private Address, which is sent by one device; the same secret is used by the peer device to resolve the private address.
Bluetooth Device Address
Bluetooth devices use a 48-bit device address. Device addresses are classified as Public Device Address and Random Device Address:
• Public Device Address: The Public Device Address is a combination of a company ID and a company-assigned ID per device following the IEEE 802-2001 standard. Company ID and company-assigned ID values are 24 bits each, constituting the total 48 bits of address as shown in Figure 1.
1. Company ID and company-assigned ID values are 24 bits each, constituting the total 48 bits of address in the Public Device Address.
• Random Device Address: As the name suggests, the Random Device Address is a randomly generated address. The Random Device Address is classified in two types, Static Random Address and Private Random Address.
The Static Random Address (Fig. 2) is either preprogrammed on a device before it’s shipped, or may change to a new value after each power cycle. However, a device isn’t supposed to change this address until the device goes through a power cycle. If this address is changed during runtime, the address stored in the peer device will not remain valid and the reconnection using the older address will fail.
2. A Static Random Address is often pre-programmed on a device, or it may change to a new value after each power cycle.
The Static Random Address has the following requirements:
- The two most significant bits are set to 1
- All bits of the random number cannot be 0
- All bits of the random number cannot be 1
There are two types of Private Random Address—Non-Resolvable Private Address and Resolvable Private Address. The Non-Resolvable Private Address is a randomly generated address that changes at every connection. It has the following requirements:
- The two most significant bits are set to 0
- All bits of a random number cannot be 0
- All bits of a random number cannot be 1
- This address shall not be equal to either the static address or the public address
The Resolvable Private Address (RPA) is the backbone for privacy in BLE devices. An RPA is an address that’s generated using a random number and the secret Identity Resolving Key (IRK). This IRK is shared between two devices at the time of pairing and stored in the device’s internal memory during bonding.
Along with IRK, the devices share a fixed address called the Identity Address. This Identity Address can be a Public or Random Static Address type. Because the devices, which have bonded earlier, know the IRK and Identity address, they can easily resolve the peer device's private address. Figure 3 shows the format of the Resolvable Private Address.
In this address, the 24-bit Hash is a function of the IRK and prand. The prand is a 24-bit number that has 22 random bits and whose two most significant bits are fixed as shown in Fig. 3.
3. In a Resolvable Private Address, the 24-bit Hash is a function of the IRK and prand, the latter being a 24-bit number that has 22 random bits and two, fixed most significant bits (MSBs).
Resolvable Private Address Generation
The Resolvable Private Address is generated with the IRK and prand. The prand is randomly generated and has the following requirements:
• The two most significant bits of prand shall be equal to 2b01
• All bits of prand cannot be 0
• All bits of prand cannot be 1
The Hash part of the address is generated using this prand and the device's 128-bit IRK, which are passed to encryption function “e”. The output of this encryption function is then truncated to 24 bits. The 24 least significant bits (LSBs) of the output are used as the Hash:
Hash = e(IRK, prand*), truncated to 24 bits
*To make the length of prand equal to IRK, prand is concatenated with 104 bits of padding, with padding bits set to 0. The LSB of the original prand remains the LSB of prand after padding.
The prand and Hash are then concatenated to generate the random address.
Resolvable Private Address Resolution
A Resolvable Private Address can be resolved by a device if it has the peer device’s IRK. As mentioned earlier, the Resolvable Private Address has a 24-bit prand and 24-bit Hash. The prand and IRK of the peer devices are used to resolve the address. Once a device receives the Resolvable Private Address, it extracts the Hash and prand from it. Then a Local Hash value is generated using the IRK of the peer device and the prand extracted from the address. The Hash is generated exactly the same way as during address generation:
Local Hash = e(Peer IRK, prand), truncated to 24-bits
This Local Hash value is compared with the Hash extracted from the address. The address is resolved if they match. If a device has more than one peer IRK, the device repeats this procedure for each stored IRK to determine if the received Resolvable Private Address is associated with any of the stored IRKs. It does so until either address resolution is successful for one of the IRKs or all have been tried.
Once a device receives the IRK and Identity Address of a peer device during the pairing process, it stores them along with the local IRK in the Resolving List. This list is used to resolve the private address in future.
In Bluetooth 4.1, the Resolving List is maintained in the Host. Address resolution is also done by the Host. This requires the Host's intervention to resolve the address every time an advertisement packet with a Resolvable Private Address is received. However, in Bluetooth 4.2, the Resolving List is maintained in the Controller. The Controller resolves the private address and the Host's intervention isn’t needed if the device is present in the Resolving List.
Because address resolution is done in the Controller, the Host doesn’t need to wake up in devices where the Host is implemented using a separate CPU. This lowers overall power consumption. Even in the devices where both the Controller and Host are implemented using the same CPU, power consumption is reduced as the address needn’t go through the various protocol layers. As a result, fewer CPU cycles are needed to resolve the address. Furthermore, the address is resolved at the Link Layer without the Host's involvement, which enables faster connections. Because address resolution is done at the Link Layer, Privacy 1.2 is also called Link Layer (LL) Privacy.
Resolvable Private Address (RPA) Timeout
The Random Private Address changes over a period of time. Such change further reduces the chances of device tracking. This interval is set by the Host, and a timer is set for RPA timeout. When the timer expires, a new RPA is generated using the IRK and a new prand.
In the case of Privacy 1.1, the RPA timeout is fixed to 15 minutes. Privacy 1.2 in Bluetooth 4.2 reduces the minimum RPA timeout period to 1 second while the maximum timeout period can be 11.5 hours. Frequent changes in Bluetooth 4.2 RPA make it more difficult to track a private device, thus improving privacy.
Even though the Resolvable Private Address was supported in Bluetooth 4.1 and older versions, it had limited usability due to its impact on connection time and power consumption. Features like device filtering and directed connectable advertisement could not be used in Privacy 1.1 while using RPA.
Device Filtering
Device filtering is the process that reduces the number of peer devices needed for a device to respond. Filtering helps in reducing power consumption, since a device needn’t respond to every peer device. When filtering is enabled, the address of the peer devices that a device intends to respond to is stored in a list called the White List. The White List, which stores the address type along with the address, is configured by the Host and maintained at the Link Layer. Once configured, the Link Layer uses it to filter peer devices.
When RPA is used in Bluetooth 4.1, the address can be resolved only by the Host, which means the Link Layer can’t filter devices. Therefore, in the case of Bluetooth 4.1, device filtering can’t be supported when using RPA. This increases the power consumption in private Bluetooth 4.1 devices, as devices need to respond to every peer device.
In Bluetooth 4.2, address resolution is done at the Link Layer, so it can filter devices even when using RPA. Now, the Host's intervention isn’t needed for devices not listed in the White List, leading to lower power consumption.
Directed Connectable Advertisement
The directed-connectable-advertisement power distribution unit (PDU) contains the Advertiser's RPA and the RPA of the device it wants to connect to. This allows for a faster connection between two devices. Also, the peripheral device doesn't need to share device specific details with peer devices it doesn’t intend to connect to. Directed connectable advertisement isn’t possible at the Link Layer. However, Bluetooth 4.2 can support address resolution at the Link Layer, and, hence, support for directed connectable advertisement.
Bluetooth 4.2 includes additional scanning filter policy settings that allow for directed advertisement with a Resolvable Private Address. Before a peripheral device uses directed connectable advertisement, it must check the peer device's Central Address Resolution characteristic. The Central Address Resolution characteristic tells the device if the peer device supports address resolution.
In summary, Bluetooth Low Energy devices are difficult to track when using a Resolvable Private Address. Frequent changes in the RPA and use of directed advertisement make it more difficult to track a private Bluetooth 4.2 device. Address resolution at the Link Layer enables faster connections and reduces power consumption. Also, Bluetooth 4.2 enables device filtering when RPA is used, thus making Private devices more power-efficient versus devices that use Bluetooth 4.1 or older.
