Zephyr does not store a new IRK when another device re-bonds with a Zephyr device #46798
Comments
|
The controller is behaving correctly according to Core 5.3 Vol 4 Part E 7.8.38. Quote follows.
The fix should be done on the host side. |
|
I suggest the fix to be performing an |
|
If I understand this correctly, we have |
Yes, that is correct. |
|
It is a new behavior in Android 12 and 13 phones, which is implemented to prevent tracking. A security issue. |
I tried that as a quick fix by deleting the old key and adding the new if hci_id_add returns an error. This seemed to work. Needs to be investigated further though. Something like this. err = hci_id_add(&keys->addr, keys->irk.val);
if (err) {
BT_ERR("Failed to add IRK to controller");
/* Quick fix for overwriting the duplicate entry with the new since the IRK could have been changed. */
bt_id_del(keys);
err = hci_id_add(&keys->addr, keys->irk.val);
/* What to do if it still returns an error? */
goto done;
} |
|
@jilu-ot You mentioned that this issue exist for Zephyr 2.2.1 (which is fairly old at this point). I assume the issue also exists for Zephyr 3.1? |
|
I heard that @ibaz-nordic has already worked on a an issue (issue 45827) that sounds like this one. Is this right? |
Yes, it looks that way, since nothing seems to be done in bt_id_add if hci_id_add returns an error. err = hci_id_add(keys->id, &keys->addr, keys->irk.val);
if (err) {
BT_ERR("Failed to add IRK to controller");
goto done;
} |
The issues are quite similar. Mine has the same IRK. The fix was reverted because it breaks PTS. So it's still an open issue. |
|
@ibaz-nordic Any work going on right now to fix it (again)? |
I don't have time to look into it (for the next ~1 mo). Should I re-open the issue in case someone has the capacity to look into it sooner? What's the procedure? |
|
Reopened the issue #45827 |
|
Regarding issue #45827. This is not the same problem as I see it. Issue #45827 is about preventing the same identity from being added to the controller's resolve list, and it seems like the IRK is not being considered in that issue. This issue is about a new IRK from the same device (device 1 in the example) that is NOT stored in the controller's resolve list because the the controller is only looking at bit 0 of the address type and the address bytes. This makes the controller unable to resolve random addresses from the device that changed its IRK. |
|
Agreed, it seems to be a separate issue (although somewhat related). In any case, the other issue is still present after the revert of the PR :) As @alwa-nordic also pointed out, it seems like this probably needs to be fixed in the host |
|
Yes. This issue should also be fixed in the host as the controller is allowed by the spec. to return invalid parameter, even if the IRKs are not a match. I have the opportunity to work on this, so I would like to make PR for this. |
|
Could one of you assign me to this issue? I don't think I can assign myself. Maybe you can @alwa-nordic ? |
|
I ran into some problems with MIC errors when deleting the key before adding it to make sure the new IRK is stored. I am currently working on finding out why that is happening. I have so far discovered that it (in my system) is because it ends up using the LTK from the previous bonding. Do any of you have an idea as to why this is happening? |
Without seeing the changes you've made, it'll be difficult to provide input :) I guess it's easier to get input if you create a draft PR |
|
@jilu-ot is |
So you are implementing the solution proposed by @alwa-nordic in here? |
|
|
The IRK issue should be in main as well. I will make a draft PR, with the IRK fix. |
|
I'll copy my post on Discord here for reference: Relevant issues: Two bonds conflict if either (or both)
HCI_LE_Add_Device_To_Resolving_List will fail with Invalid HCI Command Parameters (0x12) when there is a conflicting bond already on the list. I have ideas for two solutions. We might want to implement both in separate PRs.
|
Fixes zephyrproject-rtos#46798 Delete the new key in the controller's resolve list, if it exists, and then save the key. This will ensure that a a potentially new IRK is save upon rebonding. The IRK fix will cause a problem in smp_ident_addr_info because it will copy the identity address into the key pool entry with the re-bonding device's random address and thereby creating a second entry with the same identity address in the key pool. This will make bt_smp_request_ltk use bt_keys_find to get the LTK for the re-bonding device, but it will return the LTK for the previous bonding which is still in the key pool and is stored before the new entry. This is fixed by creating a new function in keys.c that will clear all keys with the re-bonding device's identity address, except for the keys entry referred to in the parameter req in smp_ident_addr_info. Signed-off-by: Jim Benjamin Luther <[email protected]>
|
@jilu-ot You closed your PR with comment #47043 (comment), saying the problem is already solved by #33266. Can this issue be closed? Or are we missing a back port to a still-supported Zephyr version? |
|
Oh, I am not sure if there are missing backports. I can see on PR #33266 's page that some older versions also have this fix. Zephyr 1.14, 2.4 and 2.5. But I don't know if there are other versions that should have this fix. |
|
According to https://github.com/zephyrproject-rtos/zephyr/blob/ae0297e8de1f94b050de0afecc9e2150006e3ec6/.github/SECURITY.md, only Zephyr v2.7 and v3.0 are currently supported. Those tags contain the fix. |
Describe the bug
This issue has been observed when pairing an Android 13 device with a Zephyr 2.2.1 device using privacy and secure connections. The problem is probably also present in Android 12 devices with a security patch from June 2022.
The Zephyr function ull_filter_rl_find in ull_filter.c searches the controller's resolve list for an identity address and returns the resolve list index for it if it is found. It determines that an identity already exists if only bit 0 of the address type and the address itself is a match.
It is used by ll_rl_add to see if an entry for a specified identity address is already present in the controller's resolve list or to give the index for the next available index.
ll_rl_add returns BT_HCI_ERR_INVALID_PARAM if the identity address is already found in the controller's resolve list. This return value is passed up to hci_id_add which is called from bt_id_add.
bt_id_add does nothing if hci_id_add returns BT_HCI_ERR_INVALID_PARAM, probably because the key bt_id_add was called to store was determined by ull_filter_rl_find to already exist in the controller's resolve list.
This creates a problem if a device that re-bonds with a Zephyr device is using a new IRK.
This new IRK will not be stored in the controller's resolve list because ull_filter_rl_find says it is already there based only on a comparison of bit 0 of the address type and the address itself. The IRK is not compared.
Re-bonding with a Zephyr device using an IRK, that is different from the last bonding, will therefore result in the new IRK not being stored in the controller's resolve list.
The device bonding with the Zephyr device using a new IRK will therefore not be able to re-connect to the zephyr device after it lost the BLE connection to it, since the Zephyr device's controller will not be able to resolve the device's random address because the Zephyr device's controller's resolve list still contains the previous IRK.
A potential work around would be to reboot the Zephyr device in order to make it repopulate the Zephyr device's controller's resolve list with identities from the persisted bonding list obtained through Zephyr's settings system (setting load).
To Reproduce
You need the following two devices.
Device 1: A device that changes its IRK when its bonding list is empty with a Zephyr device. This could perhaps be an Android 13 based device with the right beta version or an Android 12 device with a sufficiently new security patch. See this issue's description.
Device 2: A Zephyr based device.
Steps to reproduce the behavior:
Expected behavior
Device 1 should be able to re-connect successfully in step 5. in the steps to reproduce.
Impact
This creates confusion for users with little or no technical skills, such as elderly hearing aid users, since they would likely not understand why their phone cannot re-connect to their hearing aids after, for instance, having brought their phone out of BLE range with their hearing aid.
Potentially even worse if rebooting the Zephyr device does not make reconnection possible again.
Logs and console output
None.
Environment (please complete the following information):
Additional context
None.
The text was updated successfully, but these errors were encountered: