This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE advertisement <---> privacy and tracking

Hi!

When using BLE privat random address, we expect the BD-address to change every now and then.

When advertising with the nrf52832, we don't see the BD-address being updated at any point. So our considerations when observing this on other devices like some smartphone brands, makes us think that we need to restart the nRF52832, as it is what triggers the address change in the smartphone.

So, do we really have to disable and re-enable the softdevice or anything else, to make this happen or is this going to happen automatically ??

We have an application where the advertisements can be used for tracking by third parties and we want to avoid that as much as possible to induce privacy.

How can we achieve this?

  • Hi,

    The SoftDevice has support for privacy (resolvable address), but it is not used in any example in the SDK. In order to use it you just need to configure the SoftDevice by a call to sd_ble_gap_privacy_set(). The ble_gap_privacy_params_t instance contain a pointer to the IRK as well as the time between each address change (default is 15 minutes).

    (Note that the SoftDevice does not store any configuration in flash, so the application need to store the IRK and call sd_ble_gap_privacy_set() every time after reset in order to use the same IRK to generate the addresses)

  • Hi!

    Thank you for the quick answer!

    • Do we need to use bonding as part of this feature, cause we have intention to use our own security module, which bypasses gatt? (legacy stuff)
    • Haven't checked these yet:
      • The question is how to get/generate the IRK in the first place?
        • Haven't worked with IRKs yet!
      • When stored on flash, I expect the to need to move all IRKs must the IRK be stored in static RAM before the pointer is set in ble_gap_privacy_params_t::p_device_irk?
        • Haven't worked with the flash or IRK yet.

    Thanks!

  • Hi,

    • The IRK is typically shared with the peer device(s) during bonding. You could probably device a application specific way to share the IRK without bonding, but that would be non-standard and I do not have any particular suggestion on how to do it. Also, it might not work with mobile phones where the Bluetooth API is typically not so flexible.
    • The IRK can be generated randomly, or you can use the default key in the specific nRF device (option when calling sd_ble_gap_privacy_set()).
    • It should not matter whether the IRK you point to with ble_gap_privacy_params_t::p_device_irk is in flash or RAM.
  • Thanks for the help. I find this quite useful!

    It should be possible to generate a random IRK and send it over to the peer using the secure channel, like the one we have.

    But, for this we need first to establish a connection, GATT-service scan and start communicating in order for peers to get this IRK.

    Is this still possible? (I understand it like this:  )

    • The advertised random (private) BD-address is in fact the one the advertiser is listening for and will accept connections on it. But whether a scanner can recognize a peer based on its random_private_address that it is advertising is something it uses the IRK for doing.
      • Correct?
  • I did not follow your reasoning fully. The advertiser uses the IRK to change its address regularly, but there is nothing that prevents it from accepting connection requests from peers that do not have the IRK. Perhaps you are confusing with the whitelist concept, which is a mechanism used to only accept connections from known (whitelisted) peers.

    The scanner can connect to a peripheral that uses resolvable private address even though it does not know it's IRK, but the problem in this case is that it cannot know which device it connects to as it does not know which device has a specific address. The only way to get this mapping is to have the IRK so that the address can be resolved. (You could also put some unique data in the advertisement packet, but that would mean that you can be tracked even if the address changes so it does not seem like a sensible solution.)

Related