BLE Privacy Features: Address Randomization and IRK

BLE Privacy Features: Address Randomization and IRK

BLE devices broadcast their address in every advertising PDU. Without privacy measures, a passive scanner can track the physical location of any BLE device by following its MAC address — a significant concern for wearables, medical devices, and consumer electronics. Bluetooth 4.2 introduced the LE Privacy feature to address this.

Bluetooth Address Types

Resolvable Private Addresses (RPA) are the key privacy mechanism. The address is generated from an Identity Resolving Key (IRK) and a random prand value:

RPA generation:
  prand = random 3 bytes (with 2 MSBs = 01)
  hash = AES-128(IRK, prand || 0x000000)[0:3]
  RPA = prand || hash (6 bytes total)

RPA resolution by bonded device:
  Extract prand from upper 3 bytes of address
  Compute hash' = AES-128(IRK, prand || 0x000000)[0:3]
  Compare hash' with lower 3 bytes
  Match → this is the known device

The RPA changes every 15 minutes by default (configurable in most stacks). An observer without the IRK sees a new, uncorrelated address each interval.

IRK Distribution During Bonding

The IRK is exchanged during the SMP (Security Manager Protocol) key distribution phase of bonding:

Key distribution flags in pairing request/response:
  KeyDist_EncKey: LTK (Long-Term Key) — for re-encryption
  KeyDist_IdKey:  IRK + Identity Address — for privacy
  KeyDist_Sign:   CSRK (signing key) — for authenticated writes

After bonding, both devices store each other's IRK in non-volatile memory. The central's resolving list (managed via HCI LE_Add_Device_To_Resolving_List) enables the controller to resolve RPAs in hardware without involving the host — critical for scanning 100+ bonded devices simultaneously.

Privacy Mode (Bluetooth 5.0)

Bluetooth 5.0 added two privacy modes that govern how a bonded device responds to peers:

Network Privacy Mode prevents a bonded peer from advertising with its identity address, forcing RPA use. This mode breaks backward compatibility with pre-4.2 devices.

// Nordic nRF Connect SDK: enable privacy
bt_le_oob_set_sc_data_param_t params = {
    .privacy = BT_LE_PRIVACY_OPT_ENABLED,
    .rpa_timeout = 900, // 15 minutes in seconds
};

Tracking Prevention and Regulatory Context

Apple, Google, and the Bluetooth SIG have published guidelines for preventing unwanted tracking (AirTag controversy, 2021–2022):

• Bluetooth SIG Multi-Device Audio: AirTag-style accessories must implement DULT (Detecting Unwanted Location Trackers) spec
• Apple/Google DULT spec (2024): Mandates RPA rotation < 24 hours, user-accessible serial number via NFC, audible alert after separation
• iOS CoreBluetooth: App extensions cannot access CBCentral between advertising intervals — prevents background tracking

Privacy in the Controller vs Host

LE Privacy can be implemented at two layers:

Controller-based RPA is preferred for commercial products — the HCI resolving list enables hardware-accelerated address resolution when scanning 50+ bonded devices (e.g., access control readers). Host-based RPA is common in resource-constrained devices where the controller has a small resolving list.

// Nordic: add peer IRK to controller resolving list
struct bt_le_resolving_list_entry entry = {
    .peer_addr = peer_addr,
    .peer_irk = peer_irk,
    .local_irk = local_irk,
};
bt_le_resolving_list_add(&entry);

For product designs involving LE Audio or hearables, BLE Privacy interacts with hearing aid profiles — see the LE Audio guide for HAP privacy requirements. See also BLE Pairing Methods for how privacy and pairing interact.