Like a MAC address for LAN connected devices, Bluetooth devices also have an identity address associated with each device. Understanding how Bluetooth addresses work is crucial for every BLE developer, especially when device privacy is a concern.
So, what is a Bluetooth Address?
A Bluetooth address sometimes referred to as a Bluetooth MAC address, is a 48-bit value that uniquely identifies a Bluetooth device. In the Bluetooth specification, it is referred to as
Per the Bluetooth Core specification document, there are two main types of Bluetooth addresses: public and random addresses.
A Bluetooth device must use one of these types of addresses, and in some cases, it contains both types.
Let’s take a look at a diagram that summarizes the different types of Bluetooth addresses available:
The above diagram shows the hierarchy of Bluetooth address types. To summarize, the four Bluetooth address types are:
- Public Address
- Random Private Address
- Random Static Resolvable Static Address
- Random Static Non-Resolvable Static Address
Random Address and Static Address, as shown in the diagram, are simply classifications and are not types used in and of themselves in implementation.
A Bluetooth Public address is a global fixed address that must be registered with the IEEE. It follows the same guidelines as MAC Addresses and shall be a 48-bit extended unique identifier (EUI-48).
Creation of a valid EUI-48 requires one of the following MAC Address Block types to be obtained from the IEEE Registration Authority:
- MAC Address Block Large (MA-L)
- MAC Address Block Medium (MA-M)
- MAC Address Block Small (MA-S)
This address never changes and is guaranteed to be unique for a Bluetooth device. However, there is a fee associated with obtaining/reserving a block with the IEEE.
The following diagram represents the simplified format of a Public Bluetooth Address.
- Company ID: the publicly assigned portion of the address by the IEEE
- Company Assigned: the internally assigned ID as part of the allocated block.
To learn more about the details of IEEE-assigned MAC address blocks, refer to the following links:
Random addresses are more popular than Public addresses since they do not require registration with the IEEE. A Random address is an identifier that’s either programmed into the device or generated at runtime (depending on the subtype).
The two subtypes of Random addresses are:
- Random Static Address
- Random Private Address
Let’s dig into each of these types in more detail.
Random Static Address
This specific type of Bluetooth addresses serves as a popular alternative to Public addresses since there are no fees involved with using it.
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:
- 1 and 1 are fixed in the least significant bits
- The remaining 46 bits are chosen randomly by the developer/manufacturer
IMPORTANT NOTE: All Bluetooth devices must use one of either type: a Public Address or a Random Static Address.
The next type of address (Private Address) is optional and is solely used to address privacy concerns (i.e. device may use one of them in addition to either a Public or Random Static Address).
Random Private Address
There are two types of Random Private addresses: resolvable and non-resolvable. Random Private addresses are used specifically for protecting the privacy of a Bluetooth device, to hide the identity, and to prevent tracking of the device.
Let’s take a look at each of these types:
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 from identifying the Bluetooth device of interest.
A Resolvable Random Private address is “resolvable” using a key shared with a trusted device. This key is referred to as the IRK (Identity Resolving Key).
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 BLE devices. The Bonding process involves the storage of keys by each of the devices that are bonded with each other. Bonding also allows the two devices to pair seamlessly in connection subsequent to the original connection when the two devices were paired. One of the keys exchanged by the two bonded BLE devices is the IRK of each device involved.
This type of address changes periodically. The recommendation per the Bluetooth specification is to have it change every 15 minutes (this is evident in all iOS devices).
A Resolvable Random Private address is made up of the following fields:
- 0 and 1 are fixed in the least significant bits
- The next 22 bits are randomly generated
- The prand constitutes of these least significant 24 bits
- The upper 24 bits represent a hash value which generated using the prand and the IRK
Non-Resolvable Random Private Address
The other type of Random Private addresses is the Non-Resolvable Random Private Address.
This type of addresses also changes periodically. However, unlike resolvable addresses, it is not resolvable by any other device. The sole purpose of this type of addresses is to prevent tracking by any other BLE device.
This type is not very common, but sometimes used in beacon applications.
The format of Non-Resolvable Random Private Addresses is as follows:
- 0 and 0 are fixed in the least significant bits
- The remaining 46 bits are chosen at random
Privacy in BLE
Privacy is a major concern for users of Bluetooth devices, and it needs be taken seriously. What we mean by privacy in this context is making sure that untrusted parties are not able to track a device by its Bluetooth address.
If no careful measures are put in place, this Address can be used to track users. Fortunately, BLE provides Privacy features to safeguard against such attacks.
Privacy for Bluetooth devices is achieved by using a resolvable private address. This type of addresses requires bonding of the two Bluetooth devices in order for one to resolve the address of the other.
Here are the steps involved in implementing privacy for BLE devices:
- A key referred to as the IRK (Identity Resolving Key) is used in generating and resolving the resolvable random private address.
- The IRK generated by each device locally either randomly or assigned during manufacturing.
- During bonding, each device stores its peer’s IRK in what’s called a resolving list.
- The IRK is then used to resolve the private address of a peer device. For example, when it receives the peer’s advertising packets at a later time.
- This is done by verifying that the hash included in the private address matches the output of the local hash computation according to the following equation:
hash = ah(IRK, prand)
- Since the device has the IRK stored locally and has access to the prand included as part of the private address which is included in the BLE packets, it can perform this computation.
It’s important to note that the IRK is not used to reveal the peer’s Identity Address which is either a Public Address or a Random Static Address, but rather for verification purposes only.
Take your BLE knowledge to the next level!
If you’re looking to learn more about the Security in BLE, then I encourage you to check out the Bluetooth Developer Academy.
By joining the Bluetooth Developer Academy, you will get access to a growing library of courses and tutorials.
Here’s what one Academy member has to say:
If you’re developing a BLE project, you need two things, a good BLE sniffer and the Bluetooth Developer Academy. I am very happy to be part of this community and look forward to what comes next.– Christopher Gates, Principal System Security Architect – Velentium
The current courses include:
- The Basics of Bluetooth Low Energy
- Analysis of BLE events using a BLE sniffer
- Long-range mode (Coded PHY) using Bluetooth 5.0
- Developing nRF52 applications using Visual Studio Code
- Over the Air Device Firmware Update (OTA DFU) – nRF52 use case
- Getting Started with Zephyr (including adding custom GATT Services and Characteristics)
- The Developer’s Guide to what’s new in Bluetooth 5.2
- SweynTooth: A Summary for BLE Developers
- Introduction to BLE Security
- Getting Started with BlueZ development
- Introduction to BLE Development for iOS
- …and more courses added each month!
For a full list of courses included, check out the Courses Library here:
The Academy also features a thriving community of Bluetooth experts, developers, and innovators. You’ll get to connect and interact with other experts in the Bluetooth space, learn from others’ experience and knowledge, and share yours.
Also included in the Academy is access to private support from me personally.
In the community, you will find:
- Discussions around new features such as long-range mode (Bluetooth 5.0) and direction-finding (Bluetooth 5.1).
- Discussions around the capabilities of different BLE sniffers.
- Comparisons of BLE support and restrictions in iOS and Android.
- Various technical questions and answers to these questions.
- Listing of Bluetooth-related job openings.
- And many more discussions!