Privacy feature

Introduction

Starting with Bluetooth 4.2, Privacy can be enabled either in the Host or in the Controller:

  • Host Privacy consists of two use cases that are described in detail in the following sections. These are:

    • Random address generation - Periodically regenerating a random address (Resolvable or Non-Resolvable Private Address) inside the Host and then applying it into the Controller.

    • Random address resolution - Trying to resolve incoming RPAs using the IRKs stored in the bonded devices list. The address resolution is performed when a connection is established with a device or for the autoconnect scan. The advertising packets that have an RPA are not resolved automatically due to the high MCU processing that is required.

      The random address resolution is performed by default by the Host whenever the Controller is not able to resolve an RPA. The Host performs random address generation only when Host Privacy is requested to be enabled. During random address generation, the advertising and scan operations, if active, are stopped and restarted. If errors occur during this process and the scan or advertising cannot be started, the application is notified through the corresponding event (gAdvertisingStateChanged_c, gExtAdvertisingStateChanged_c or gScanStateChanged_c)

  • Controller Privacy, introduced by Bluetooth 4.2, consists of writing the local IRK in the Controller, together with all known peer IRKs, and letting the Controller perform hardware, fully automatic RPA generation and resolution. The Controller uses a Resolving List to store these entries. The size of the list is platform dependent and determined by gMaxResolvingListSize_c. For RPA resolution, the entries that do not fit in this list are processed by the Host to be resolved using the IRKs from Bonded Devices list.

Either Host Privacy or Controller Privacy can be enabled at any time. Trying to enable one while the other is in progress generates a gBleInvalidState_c error. The same error is returned when trying to enable the same privacy type twice, or when trying to disable privacy when it is not enabled.

The recommended way of using Privacy is the Controller Privacy. However, enabling Controller Privacy requires at least a pair of local IRK and peer IRK, so this can only be enabled only after a pairing is performed with a peer and the IRKs are exchanged during the Key Distribution phase. When a device starts, if Privacy is required, the workflow is the following:

  1. Enable Host Privacy using the local IRK.

  2. Connect to a peer and perform pairing and bonding to exchange IRKs.

  3. Disable Host Privacy.

  4. Enable Controller Privacy using the local IRK and the peer IRK and peer identity address.

After enabling Host Privacy or Controller Privacy, the application must wait for the gHostPrivacyStateChanged_c or gControllerPrivacyStateChanged_c generic event and verify that privacy has been successfully enabled. Only then it is safe to proceed with setting advertising parameters (via the Gap_SetAdvertisingParameters or Gap_SetExtAdvertisingParameters APIs) or starting scanning (via the Gap_StartScanning API). Failure to do so could result in unwanted behavior, such as the device advertising or scanning with a public address.

Resolvable private addresses

A Resolvable Private Address (RPA) is a random address generated using an Identity Resolving Key (IRK). This address appears completely random to an outside observer, so a device may periodically regenerate its RPA to maintain privacy, as there is no correlation between any two different RPAs generated using the same IRK.

On the other hand, an IRK can also be used to resolve an RPA, in other words, to check if this RPA has been generated with this IRK. This process is called “resolving the identity of a device”. Whoever has the IRK of a device can always try to resolve its identity against an RPA.

For example, assume device A frequently changes its RPA using IRKA. At some point, A bonds with B. A must give B a way to recognize it in a subsequent connection when it (A) has a different address. To achieve this purpose, A distributes the IRKA during the Key Distribution phase of the pairing process. B stores the IRKA it received from A.

Later, B connects to a device X that uses RPAX. This address appears completely random, but B can try to resolve RPAX using IRKA. If the resolving operation is successful, it means that IRKA was used to generate RPAX, and since IRKA belongs to device A, it means that X is A. So B was able to recognize the identity of device X, but nobody else can do that since they do not have IRKA.

Parent topic:Introduction

Non-resolvable private addresses

A Non-Resolvable Private Address (NRPA) is a completely random address that has no generation pattern and therefore cannot be resolved by a peer.

A device that uses an NRPA that is changed frequently is impossible to track because each new address appears to belong to a new device.

Parent topic:Introduction

Multiple identity resolving keys

If a device bonds with multiple peers, all of which are using RPAs, it needs to store the IRK of each in order to be able to recognize them later (see previous section).

This means that whenever the device connects to a peer that uses an unknown RPA, it needs to try and resolve the RPA with each of the stored IRKs. If the number of IRKs is large, then this introduces a lot of computation.

Performing all these resolving operations in the Host can be costly. It is much more efficient to take advantage of hardware acceleration and enable the Controller Privacy.

Parent topic:Introduction

Parent topic:Privacy feature

Host privacy

To enable or disable Host Privacy, the following API may be used:

bleResult_t **Gap\_EnableHostPrivacy**
(
    bool_t              enable,
    const uint8_t *     aIrk
);

When enable is set to TRUE, the aIrkparameter defines which type of Private Address to generate. If aIrk is NULL, then a new NRPA is generated periodically and written into the Controller. Otherwise, an IRK is copied internally from the aIrk address and it is used to periodically generate a new RPA.

The lifetime of the Private Address (NRPA or RPA) is a number of seconds contained by the gGapHostPrivacyTimeoutexternal constant, which is defined in the ble_config.c source file. The default value for this is 900 (15 minutes).

When Host Privacy is enabled, the Host ignores the ownAddressType value for the advertising, scanning or connect parameters. It will always use the random address type in order to use the RPA configured in the Controller in the packets sent over the air.

As mentioned in the Introduction section, call this API for random address generation. For random address resolution there is no need to do so, it is performed by default against the bonded devices list.

Parent topic:Privacy feature

Controller privacy

To enable or disable Controller Privacy, the following API may be used:

bleResult_t **Gap\_EnableControllerPrivacy**
(
    bool_t                               enable,
    const uint8_t *                      aOwnIrk,
    uint8_t                              peerIdCount,
    const gapIdentityInformation_t*      aPeerIdentities
);

When enable is set to TRUE, aOwnIrkparameter shall not be NULL, peerIdCount shall not be zero or greater than gMaxResolvingListSize_c, and aPeerIdentities shall not be NULL.

The IRK defined by aOwnIrk is used by the Controller to periodically generate a new Resolvable Private Address (RPA). The lifetime of the RPA is a number of seconds contained by the gGapControllerPrivacyTimeoutexternal constant, which is defined in the ble_config.c source file. The default value for this is 900 (15 minutes).

The aPeerIdentities is an array of identity information for each bonded device. The identity information contains the device’s identity address (public or random static address) and the device’s IRK. This array can be obtained from the Host with the Gap_GetBondedDevicesIdentityInformationAPI.

Enabling Controller Privacy involves a quick sequence of commands to the Controller. When the sequence is complete, the gControllerPrivacyStateChanged_c generic event is triggered.

Privacy mode

In Bluetooth LE 5.0, the privacy mode has been introduced as an optional feature and is part of the GAP identity structure together with the address and address type. There are two modes: Network Privacy Mode (default) and Device Privacy Mode. These are valid only for Controller Privacy.

A device in network privacy mode only accepts packets from peers using private addresses.

A device in device privacy mode also accepts packets from peers using identity addresses, even if the peer had previously distributed the IRK. Private addresses are also accepted.

The privacy mode of a device is stored in NVM together with the IRK with a default value of Network. If the application wants to change this value it can extract the peer identities, modify the privacy mode from network to device and then enable Controller Privacy with the value.

To change the privacy mode of a device and make the change persistent, the user must call the following API:

bleResult_t **Gap\_SetPrivacyMode **
(
    uint8_t nvmIndex,
    blePrivacyMode_t privacyMode
);

Parent topic:Controller privacy

Scanning and initiating

When a Central device is scanning while Controller Privacy is enabled, the Controller actively tries to resolve any RPA contained in the Advertising Address field of advertising packets. If any match is found against the peer IRK list, then the advertisingAddressResolved parameter from the scanned device structure is set to TRUE.

In this case, the addressType and aAddress fields no longer contain the actual Advertising Address as seen over the air, but instead they contain the identity address of the device whose IRK was able to resolve the Advertising Address. In order to connect to this device, these fields shall be used to complete the peerAddressType and peerAddress fields of the connection request parameter structure, and the usePeerIdentityAddress field shall be set to TRUE.

If advertisingAddressResolved is equal to FALSE, then the advertiser is using a Public or Random Static Address, an NRPA, or a RPA that could not be resolved. Therefore, the connection to this device is initiated as if Controller Privacy was not enabled, by setting usePeerIdentityAddress to FALSE.

Parent topic:Controller privacy

Advertising

When a Peripheral starts advertising while Controller Privacy is enabled, the ownAddressType field of the advertising parameter structure is unused. Instead, the Controller always generates an RPA and advertises with it as Advertising Address.

If directed advertising is used, the Host only allows advertising to a device in the resolving list in order to be able to generate RPAs.

Parent topic:Controller privacy

Connected

When a device connects while Controller Privacy is enabled, the gConnEvtConnected_c connection event parameter structure contains more relevant fields than without Controller Privacy.

The peerRpaResolved field equals TRUE if the peer was using an RPA that was resolved using an IRK from the list. In that case, the peerAddressType and peerAddressfields contain the identity address of the resolved device, and the actual RPA used to create the connection (the RPA that a Central used when initiating the connection, or the RPA that the Peripheral advertised with) is contained by the peerRpa field.

The localRpaUsedfield equals TRUE if the local Controller was automatically generating an RPA when the connection was created, and the actual RPA is contained by the localRpa field.

Parent topic:Controller privacy

Parent topic:Privacy feature

Parent topic:Generic Access Profile (GAP) Layer