LESC authentication for just exchanging IRK with enc key set to 0 seems to exchange LTK

[jm_laird]

I am attempting to use an nRF52840 with softdevice 7.2.0 to validate some scenarios and am seeing a difference in operation between legacy pairing and LESC pairings. I have tested against an nRF52840, iPhone (with LESC) and Android phone (without LESC). I set the key distribution to have id = 1 and all other fields = 0 on the device. In legacy mode, I get the authentication complete process and am getting the same values back in the params.auth_status.kdist_own and params.auth_status.kdist_peer parameters in the BLE_GAP_EVT_AUTH_STATUS event, however if the remote device supports LESC then I get id = 1 and enc = 1 in the params.auth_status.kdist_own field in this callback, even though I specified not to exchange the enc key by setting s_sec_params.kdist_own.enc = 0, I am still getting id = 1 and all other fields = 0 for the params.auth_status.kdist_peer parameter.

Is this expected or is something amiss in this?

[jm_laird]

Hi Einar,

It is an odd use case but the use case is just wanting to get the IRK from a device, if both devices support LESC then they will establish an LESC encryption so that they can exchange their IRKs (as an encrypted link is required to exchange the IRK), if one side doesn't then it will still establish encryption to exchange the keys (which is working as intended, own and peer enc is set to 0). So the full details are both devices want to bond by exchanging IRKs but do not want to store encryption keys (they should just be temporary for the duration of the connection) - so the bond flag is required because the IRKs are going to be stored but the problem is in the BLE_GAP_EVT_AUTH_STATUS event, how do you know (if it's an LESC bond) if you should be storing just the IRK in the bond database or if the encryption details should be stored as well? That is the issue I am trying to resolve.

Thanks,
Jamie

[Einar Thorsrud]

Hi Jamie,

I see. Then I do not see any way around bonding as normal, and then removing the bond later, while keeping the IRK (for whitelisting or whatever you are using it for). On the nRF side that should not be a problem, though there are no examples doing that. I don't know if it will be possible on iOS and Android, though.