At reelyActive, we often get asked questions like "how much can one know about a person's smartphone from its Bluetooth packets?" or "can I recognise subsequent visits of the same device?" This is intended to be a just-technical-enough reference for anyone to not only find answers to such questions but, more importantly, to understand why.
The following is a primer on radio-frequency identification using BLE. Specifics on the identifiers can be found below..
The advertiser address is the one and only mandatory identifier in a BLE advertising packet. It has the form 12:34:56:78:9a:bc.
BLE includes a feature which allows this identifier to be either public (IEEE-assigned) or random (manufacturer-assigned). Moreover, when random, the device manufacturer is free to change the identifier dynamically, should they so choose. The result is the following three flavours:
There IS a mandatory flag to indicate whether the address is public or random. However, there IS NOT a flag to indicate whether a random address is static or dynamic. In other words:
the only way to know if a device's random advertiser address will periodically change is through observation
|Question||public static||random static||random dynamic|
|Can I implicitly recognise the product?||No*||No||No|
|Can I explicitly associate with a person/product?||Yes||Yes||No|
|Can I recognise the device again if it leaves and comes back?||Yes||Yes||No|
|Is the identifier guaranteed to be unique?||Yes||No||No|
*it is nonetheless possible to look up the chip manufacturer from this registry.
Beyond the mandatory identifier, the standard BLE advertising packet supports up to 31 bytes more payload which may contain additional identifiers.
A 16-bit UUID represents a defined service. It has the form 0x1234.
The Bluetooth SIG has reserved a block of 512 such UUIDs for member companies, listed here. It is therefore possible to look up the member company from the UUID. reelyActive maintains this lookup feature in Sniffypedia. Notable examples include:
Google's Eddystone service uses the UUID 0xfeaa. An open specification, Eddystone includes several flavours that are free for use. These include:
Tile devices advertise the UUID 0xfeed.
Devices implementing the Contact Tracing service, a collaboration between Apple and Google in response to the COVID-19 pandemic (specification), advertise the UUID 0xfd6f.
A 128-bit UUID represents a service and/or acts as a device identifier. It has the form 12345678-1234-1234-1234-123456789abc. Unlike the 16-bit UUID and the 16-bit company identifier used in Manufacturer Specific Data, the Bluetooth SIG does not assign 128-bit UUIDs, leaving vendors and programmers free to choose. Notable examples include:
Fitbit devices advertise the UUID adabXXXX-6e7d-4601-bda2-bffaa68956ba where the XXXX represents a specific product type such as the Charge HR.
Manufacturer Specific Data is accompanied by a 16-bit company identifier. It has the form 0x1234.
The Bluetooth SIG assigns the company identifiers which are listed here. It is therefore possible to look up the member company from the company identifier. reelyActive maintains this lookup feature in Sniffypedia. Notable examples include:
Apple is assigned the company code 0x004c and their devices make extensive use of Manufacturer Specific Data for a variety of functions. While Apple does not openly document most of these functions, the iBeacon specification is a notable exception.
An iBeacon encodes a 128-bit UUID, a 16-bit Major and a 16-bit Minor identifier. Typically, the Major represents a superclass (ex: a physical venue) and the Minor represents a subclass (ex: points of interest within the venue), while the UUID is unique to a beacon vendor or operator, for example:
The above highlights that although all iBeacons must, by definition, transmit Apple's company code (0x004c), they are not necessarily Apple devices! In general:
it is wise to not assume that a device advertising a specific company code is necessarily a product of that company.
A Local Name is an ASCII string. The Local Name is often human-readable (ex: "Charge HR") as the formats described above afford more efficient encoding of machine-readable identifiers. The length of this name is limited by the capacity of the BLE payload.
Assignment of Bluetooth Low Energy identifiers for interoperability and interpretability
Interpret raw BLE advertising data, extracting identifiers and other data.
A getting started guide oriented towards developers familiar with the open source software model.
For an exhaustive machine-readable list of common BLE UUIDs see Sniffypedia's index.js
Explore Sniffypedia, check out advlib, or return to the diyActive home page.