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

[Daisuke]

Hello,

Please let me check about the usage of an IRK for the default setting and how to change an IRK each bonding cycle.

We use the resolvable address for our application, and I've met an issue like the following scenario:

1. Connect and bond the nRF device with peer A.
2. Delete the bonding information of peer A on the nRF device.
3. Connect and bond the nRF device with peer B.
4. Connect the nRF device to peer A for re-bonding.
   1. 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.

Questions which I would like to ask you are:

1. I think the soft device does not change the IRK for all time as a default. Is it correct?
2. Is it possible to renew an IRK bonding cycle?
3. Can you see any problems if we implement to change IRK for this solution?  Perhaps, I've just misunderstood privacy features.

If I could get any advice from you, it would be much appreciated.

Thanks,
Daisuke

[Einar Thorsrud]

Hi Daisuke,

1. I think the soft device does not change the IRK for all time as a default. Is it correct?

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.

2. Is it possible to renew an IRK bonding cycle?

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. 

3. Can you see any problems if we implement to change IRK for this solution?  Perhaps, I've just misunderstood privacy features.

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.

Connect the nRF device to peer A for re-bonding.

1. 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

[Daisuke]

Hello Einar,

Thank you very much for your clear answer.

Einar Thorsrud said:

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.

Einar Thorsrud said:

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.

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

[Einar Thorsrud]

Hi,

Daisuke said:

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?

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().

Daisuke said:

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?

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).

[Daisuke]

Hi, Einar,

Thank you so much!

Let us try to implement these.

Best Regards,

Daisuke