the usage of an IRK for the default setting and how to change an IRK each bonding cycle.

RE: the usage of an IRK for the default setting and how to change an IRK each bonding cycle.

Daisuke — Mon, 03 Jun 2019 11:10:19 GMT

Hello Einar,

Let me ask the additional questions related with sd_ble_gap_privacy_set() function, please.

i. sd_ble_gap_privacy_set() and sd_ble_gap_privacy_get() function does not use the flash memory, does they? (When the nRF device turns off, The IRK is gone.) Is it correct?
ii. Do we need to store the IRK which is generated by nrf_crypto_rng() to the flash memory by our selves? What is the assumed implementation with sd_ble_gap_privacy_set() ?

Thanks,
Daisuke

RE: the usage of an IRK for the default setting and how to change an IRK each bonding cycle.

Daisuke — Tue, 28 May 2019 08:28:07 GMT

Hi, Einar,

Thank you so much!

Let us try to implement these.

Best Regards,

Daisuke

RE: the usage of an IRK for the default setting and how to change an IRK each bonding cycle.

Einar Thorsrud — Tue, 28 May 2019 07:43:25 GMT

Hi,

[quote user="Daisuke"]a. Our accessory uses a static random address before bonding. If my understanding is correct, the static random address is also fixed as a default. So, if we would like to change the address, we can use sd_ble_gap_addr_set() function for this purpose. Is this correct?[/quote]

Yes. The SoftDevice always uses the device-specific random static address from FICR unless you explicitly configure something else. If you want to change it, you have to call sd_ble_gap_addr_set().

[quote user="Daisuke"]b. Do "GAP Address cycle modes" relate with our cases? (for IRK or Static Random Address?) How can we handle this? Is it OK to leave it as default?[/quote]

Yes. If you use a recent SoftDevice, the address cycle mode is configured by setting private_addr_cycle_s field in the ble_gap_opt_privacy_t instance passed to sd_ble_gap_privacy_set(). If you don't set it (i.e., use 0), the default of 15 minutes is used (BLE_GAP_DEFAULT_PRIVATE_ADDR_CYCLE_INTERVAL_S).

RE: the usage of an IRK for the default setting and how to change an IRK each bonding cycle.

Daisuke — Tue, 28 May 2019 03:19:16 GMT

Hello Einar,

Thank you very much for your clear answer.

[quote userid="7377" url="~/f/nordic-q-a/47722/the-usage-of-an-irk-for-the-default-setting-and-how-to-change-an-irk-each-bonding-cycle/189262"]It is not a common approach, probably because it renders all existing bonds invalid. Also, the only benefit is that it prevents previously bonded devices from being able to track the nRF (which is the purpose or using a resolvable address). In most cases this is probably not a practical problem, since you trusted the device you have bonded with. I would leave the IRK as is unless you have a good reason for not doing it.[/quote][quote userid="7377" url="~/f/nordic-q-a/47722/the-usage-of-an-irk-for-the-default-setting-and-how-to-change-an-irk-each-bonding-cycle/189262"]The typical way to handle such issues is just to delete bonding information on the phone before you pair again (if I understood the problem coreclty). Note that if you do re-bonding, any cached GATT (meta)data should anyway be discarded, as it is linked to the bond.[/quote]

Yes, we know the backward by renewing the IRK each bonding cycle. However, our usage policy for pairing is quite simple, which is "Our accessory can pair with only one peer." For this case, the previous peer might act the wrong way if the user does not delete bonding information on the last peer side. (Ordinary users can confuse easily when just one problem causes.)

Here is a related question, could you comment on this too, please?:
a. Our accessory uses a static random address before bonding. If my understanding is correct, the static random address is also fixed as a default. So, if we would like to change the address, we can use sd_ble_gap_addr_set() function for this purpose. Is this correct?
b. Do "GAP Address cycle modes" relate with our cases? (for IRK or Static Random Address?) How can we handle this? Is it OK to leave it as default?

Sorry for my many questions, but if I could get any comments on this, it would be much appreciated.

Thanks,
Daisuke

RE: the usage of an IRK for the default setting and how to change an IRK each bonding cycle.

Einar Thorsrud — Mon, 27 May 2019 10:02:59 GMT

Hi Daisuke,

[quote user=""]1. I think the soft device does not change the IRK for all time as a default. Is it correct?[/quote]

Yes, that is correct. The SoftDevice will always use the IRK which was randomly generated in production and placed in the IR registers by default.

[quote user=""]2. Is it possible to renew an IRK bonding cycle?[/quote]

There is no strict link between the local IRK and bonding, but changing the IRK will effectively render all existing bonds invalid since the peer device(s) will no longer identify the nRF as the same device. Assuming you use the peer manager with a recent SDK version you can call pm_privacy_set(), which essentially just calls sd_ble_gap_privacy_set(). The configuration parameter is pm_privacy_params_t, which is typedefed to ble_gap_privacy_params_t, and this has a p_device_irk field that should point to the IRK you want to use (which you may have generated using for instance nrf_crypto_rng()). Note that the nRF can only have a single device (own) IRK active at a single time, so this will cause problems with previous bonds.

[quote user=""]3. Can you see any problems if we implement to change IRK for this solution? Perhaps, I've just misunderstood privacy features.[/quote]

It is not a common approach, probably because it renders all existing bonds invalid. Also, the only benefit is that it prevents previously bonded devices from being able to track the nRF (which is the purpose or using a resolvable address). In most cases, this is probably not a practical problem since you trusted the device you have bonded with. I would leave the IRK as is unless you have a good reason for not doing it.

[quote user=""]Connect the nRF device to peer A for re-bonding.[/quote]

At this timing, peer A acts as if it has already known the nRF device because nRF's IRK does not change. (the nRF advertises with the resolvable address for peer B, but peer A can also resolve it because IRK is the same as the last session.) So, peer A uses cached handle IDs for GATT protocols, which causes problems on the connection.

The typical way to handle such issues is just to delete bonding information on the phone before you pair again (if I understood the problem correctly). Note that if you do re-bonding, any cached GATT (meta)data should anyway be discarded, as it is linked to the bond.

Br,

Einar