CSIS: RSI: General problem with RSI in privacy 1.2

[MariuszSkamra]

Statement Once the RPA changes, the new RSI (Resolvable Set Identifier) shall be generated and AD/SD data shall be updated as well with the new RSI value. This shall be done to avoid the tracking device. There shall not be condition that result in advertising old RSI using new RPA.

Background If controller-based privacy is used, the HCI_LE_Set_Resolvable_Private_Address_Timeout is used to set "the length of time the Controller uses a Resolvable Private Address before a new resolvable private address is generated and starts being used" (Core 5.3 | Vol 4, Part E, 7.8.45).

Core 5.3 | Vol 3, Part C 10.7.1.1 Privacy feature in a Peripheral with Controller-based privacy "If the advertising data or the scan response data change regularly then those changes should be synchronized with any changes in private addresses (both local and remote). For this purpose, the Host should either instruct the Controller to synchronize address changes with those data changes or, if the Controller does not support that feature, generate private addresses as described in Section 10.7.1.2 instead of offloading private address generation to the Controller."

Problem The lack of synchronization in private addresses changes between controller and host. The host does not really know when RPA changed and when to provide new RSI. Is it guaranteed that the RPA_Timeout is reset on HCI_LE_Set_Extended_Advertising_Enable/HCI_LE_Set_Advertising_Enable? Maybe Controller might have a global RPA Timer, so that *_Enable command will cause to generate RPA for this advertising only, but the RPA might not last RPA_Timeout but change earlier. Such behavior makes the host impossible to track RPA changes even if it set and knows RPA_Timeout.

The synchronization would require some HCI vendor event so that the host would know when to change RSI.

Core says, that if there is no such synchronization, then Section 10.7.1.2 should be used (10.7.1.2 Privacy feature in a Peripheral with Host-based privacy).

I see two options here:

1. To stop using Controller-based privacy at all when CSIS is enabled and just fall-back to Host-based.
2. 1 + To have a HCI Zephyr-specific event that provides synchronization in private addresses generation, that could be used with Zephyr controller only.

Moreover, maybe this would require to raise an errata to Core.

[MariuszSkamra]

ping @cvinayak @jhedberg @Thalley @sjanc @rymanluk

[Thalley]

Hi @MariuszSkamra

I remember this being discussed at the GAWG (ping @asbjornsabo @Rasmus-Abildgren-Bose) multiple times, and IIRC it would considered to be an implementation specific challenge.

IMO Coordinated Sets should never have been a GATT profile, as there so many challenges with the data that CSIS requires (LTK, RPA update, etc.).

I had not previously considered the approach of using a VS event to get the RPA; that's a good idea I think.

Perhaps a combination of the two options?

if (controller == Zephyr) {
    use vendor specific event to update RSI
} else { 
    require host-based privacy
}

[Thalley]

Removed the bug label: It's not really a bug, but a missing feature.

[Thalley]

@jhedberg @alwa-nordic

We need to either be able to force Host privacy, or to use a Zephyr specific event to let an application to always know of RPA changes. Does CONFIG_BT_PRIVACY enable host privacy (rpa_expired is guarded by CONFIG_BT_PRIVACY)?

[alwa-nordic]

We need to either be able to force Host privacy, or to use a Zephyr specific event to let an application to always know of RPA changes. Does CONFIG_BT_PRIVACY enable host privacy (rpa_expired is guarded by CONFIG_BT_PRIVACY)?

We do not have an API for forcing Host privacy. CONFIG_BT_PRIVACY enables both host and controller privacy. But my understanding is that the current Host implementation does not use Controller privacy for advertising, except for directed advertising. So the problem does not exist yet. However, the all the points for concern stand. To be safe, we have to explicitly assert somewhere in code that we don't use Controller privacy when an rpa_expired event listener is installed.

The search term for finding the code that enables Controller privacy in the Host is "OWN_ADDR_RPA". For advertising, the following is the relevant bit of code.

https://github.com/zephyrproject-rtos/zephyr/blob/1eb9d36d46b6fcfff2696332ca51fd714eb788dc/subsys/bluetooth/host/id.c#L1595-L1606

For context, the following is the call watershed from Host API to bt_id_set_adv_own_addr.

[Thalley]

@alwa-nordic Is it correctly understood that updating the RPA only happens in the host then?

We do have something like bt_rpa_create which is also called from the controller and called from ull_filter_rpa_update, which would indicate the the controller may also update an RPA for an advertising set.

[alwa-nordic]

@alwa-nordic Is it correctly understood that updating the RPA only happens in the host then?

For non-directed advertising, yes.

We do have something like bt_rpa_create which is also called from the controller and called from ull_filter_rpa_update, which would indicate the the controller may also update an RPA for an advertising set.

This should be controlled by own_addr_type from the HCI command. The current Host implementation will never set own_addr_type to "Please generate an RPA" for non-directed advertising.

[Thalley]

Alright, thanks

@cvinayak Do you agree with Aleksander's comments?

[Thalley]

This is no longer handled by the stack and should be handled by the application. Closing due to this.