How Android Generates Random BLE MAC Addresses and the Security Risks Behind It

Introduction

In April 2015 the Bluetooth Special Interest Group published a blog titled “Bluetooth Technology Protecting Your Privacy”, describing the use of random MAC addresses to prevent BLE device tracking and its inclusion in the Bluetooth 4.0 and 4.2 specifications. Android implements MAC address randomization by changing the BLE address roughly every 15 minutes.

BLE MAC Address Types

BLE devices can use two address types: Public Device Address and Random Device Address, both 48 bits long.

Public Device Address

Assigned by IEEE to manufacturers, guaranteeing uniqueness but making devices easy to track.

Random Device Address

Divided into Static Device Address, Non‑resolvable Private Address, and Resolvable Private Address.

Static Device Address

Generated at power‑up, highest two bits are “11”, the remaining 46 bits are random (not all zeros or ones). It remains constant for the power‑up cycle.

Non‑resolvable Private Address

Randomly generated and updated periodically (typically every 15 minutes).

Resolvable Private Address

Generated from a 24‑bit prand (with highest bits “01”) and a 24‑bit hash computed as hash = ah(IRK, prand). The address changes periodically.

Android BLE Random MAC Address Generation and Use

Android primarily uses the Resolvable Private Address. The IRK (Identity Resolving Key) is generated in the function btm_ble_reset_id_impl() (found in btm_ble.cc) by encrypting a random 16‑byte IR with a constant using aes_128(). The IRK is created once when the Bluetooth stack starts and does not change on Bluetooth toggle or device reboot.

During pairing, devices run the Security Manager Protocol (SMP) to exchange keys, including the IRK. The SMP flow consists of three stages: link‑layer connection and exchange of pairing information, generation of encryption keys based on IO capabilities, and distribution of keys (including IRK) for address resolution.

After successful pairing, devices store each other's IRK in bt_config.conf (located at /data/misc/bluedroid). This file contains the local IRK, the random IR used to derive it, and the public device address.

The paired device list also stores the peer’s IRK; for devices using a static public address the IRK is present but not used for address resolution.

Android BLE Security and Privacy CVEs

CVE‑2020‑35473

This high‑severity CVE stems from the allow‑list based side‑channel described in “When Good Becomes Evil”. An attacker can replay a previously captured MAC address of a paired device in a SCAN_RSP packet; the target phone, recognizing the address via its stored IRK, will automatically connect, revealing the phone’s presence.

CVE‑2021‑39673

Discovered by Dr. Wu Jianliang, this high‑severity issue arises because Android’s IRK is static. If an attacker obtains the IRK (e.g., from a compromised paired device), they can resolve any future random MAC addresses of the phone, effectively tracking it even after the MAC changes.

CVE‑2023‑21307

Google disclosed this medium‑severity vulnerability where, during BLE pairing, Android also transmits its public device address (BD_ADDR) alongside the IRK. The public address is globally unique, and if intercepted it can be used for device tracking.

Conclusion

The Bluetooth SIG introduced three random MAC address types to mitigate tracking, with the Resolvable Private Address being the most common in Android. However, static IRK handling and accidental exposure of the public address create privacy risks, as demonstrated by the three CVEs discussed.