Impact
We would like to report a privacy issue we recently discovered in the Zephyr Bluetooth stack. It could enable the attacker to track the victim
device’s physical location. Our experiment shows that it affects the version of Zephyr (2.7-rc1). It may also affect other versions.
Issue:
Bluetooth Low Energy (BLE) uses a resolving identity key (IRK) to generate the resolvable private address (RPA). The use of RPA protects the privacy of a BLE device while allowing two paired devices to recognize each other.
Zephyr allows an app using BLE to create new identities (MAC address and IRK pairs) for BLE for better privacy. However, even with the privacy feature enabled (CONFIG_BT_PRIVACY=y and CONFIG_BT_CTRL_PRIVACY=y), we found the following 2 issues that allow the attacker to track the victim device’s physical location.
1 We found that one identity can use only one IRK, and the IRK is still valid after the BLE app unpairs or forgets a paired device, unless the app explicitly deletes or resets the identity.
2 We also found that Zephyr will use a fixed IRK for the default MAC address of BLE, if the controller’s identity root (IR) is fixed.
Each of these two issues allows, separately, a device running Zephyr to be tracked once the attacker obtains the IRK. When the privacy feature is enabled, the IRK is distributed to the peer device when pairing over BLE. As a consequence, the IRK can be obtained by the attacker when the victim device pairs with a malicious BLE device or the paired BLE device is compromised, making the tracking of the user practical.
What is worse is that unpairing the malicious (or compromised) BLE device does not stop the tracking because the same IRK is still used and not changed when unpairing with the malicious device, unless the app explicitly deletes/resets the identity. Moreover, when the default identity is used, completely resetting the Zephyr OS does not prevent the tracking either, if the IR is fixed.
In summary, after an app pairs with a malicious/compromised device, the attacker can track (i.e., understand when the user is physically near) the user, even after the user unpaired with such malicious/compromised device. Additionally, if a BLE app uses the default identity, even completely resetting Zephyr OS may not prevent the tracking.
Detailed explanation:
BLE introduces a new privacy feature (page 278 in the Bluetooth Core Specification 5.2,
https://www.bluetooth.com/specifications/specs/core-specification/) that allows using the RPA as the MAC address of a BLE device. To use an RPA, a device must have an IRK and use the IRK to generate RPAs following the procedures described in the specification (page 2861 in the specification). Correspondingly, to resolve an RPA and identify a device, the same IRK (the one used to generate the RPA) is needed.
It is not clearly stated in the Bluetooth Core Specification how many IRKs a device should use, and we found that Zephyr allows a BLE app to
create new identities for BLE for better privacy. However, even with the privacy feature enabled (CONFIG_BT_PRIVACY=y and
CONFIG_BT_CTRL_PRIVACY=y), we found the two issues stated earlier after experimenting with our development board (nRF52840 DK with Zephyr 2.7-rc1) and reading the following code.
1 One identity has only one IRK, and the IRK is still valid when the BLE app unpairs with a remote device:
|
int bt_id_create(bt_addr_le_t *addr, uint8_t *irk) |
When unpairs with a peer device, the remote IRK is removed but the local IRK is not removed:
If BT_SETTINGS is set, the IRK will be stored, and it will be reused when calling settings_load() function
2 The IRK for the default MAC address may be fixed (depending on the behavior of the used board):
In fact, Zephyr tries to read the IR from the controller:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/host/id.c#L1249
Then it calculates the IRK based on IR:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/host/id.c#L1251
Therefore, if the IR is fixed (as in the nRF52840 DK board we used for testing), the IRK is also fixed.
Each of these two issues may make the device using Zephyr trackable once the victim device pairs with a malicious BLE device or the paired
BLE device is compromised. The victim device is still trackable even if the victim device unpairs with the malicious (or compromised) BLE
device. If the default identity is used by a BLE app (the app does not create new identities explicitly), even completely resetting the Zephyr OS may not prevent the tracking. As a consequence, the following attack scenario, in which the attacker can track the location of a victim device user, is possible.
Attack model:
The victim device uses RPAs and has been paired with a malicious BLE device under the attacker's control. The victim user may pair with a
malicious BLE device by mistake. It is also possible that the paired BLE device is compromised.
The user can potentially unpair with the malicious BLE device after mistakenly pairing with it. The attacker can deploy malicious devices at
different places to sniff the BLE packets (including BLE advertising messages, Scan requests, Scan responses, and connection requests).
Attack steps:
- The victim device is paired with a malicious BLE device under the attacker's control, e.g., the paired BLE device is compromised. During
pairing, the device running Zephyr may distribute its IRK to the malicious BLE device
(
|
smp_send(smp, buf, NULL, NULL); |
).
According to the specification (page 1390 in the specification), a device using an RPA shall always distribute its IRK during pairing (this aligns
with our observation during our experiments). As a result, if the victim device uses an RPA, its IRK will always be distributed to the attacker
when the victim device pairs with the malicious BLE device.
The attacker can also get the victim device’s IRK from a compromised paired BLE device since the victim device always distributes its IRK during pairing.
-
(optional) The user notices she has paired the victim device with a malicious (or compromised) device and unpairs with it.
-
Once the attacker obtains the IRK, the attacker can track the victim user's location when the victim device uses the BLE functionality (e.g.,
advertising messages) with an RPA. The deployed malicious devices sniff BLE packets and extract the RPAs from the packet. Then the malicious
devices try to resolve RPAs and identify the victim device with the procedures described in the specification (page 2862 in the specification). If the RPA is resolved, it means that the victim device is close to the location of the malicious device that receives the BLE packet and resolves the RPA.
Impact:
We have done experiments on an nRF52840 DK development board with Zephyr 2.7-rc1. When enabling the privacy feature in Zephyr BLE, the RPAs are used, and the victim device distributes its IRK during pairing. Accordingly, the attacker can obtain the IRK when the victim device pairs with a malicious BLE device or the paired BLE device is compromised. Once the attacker obtains the IRK, she can track the victim user's location when the victim device uses the BLE functionalities, such as broadcasting advertising messages or connecting to a BLE peripheral.
Unpairing with the malicious BLE device does not help to mitigate the tracking because the victim device will still use the same IRK after unpairing. If the app uses the default identity, even completely resetting the Zephyr OS may not stop the tracking.
Possible Fix:
- Fix for the first issue (the IRK is still valid after a BLE app unpairs with a remote device)
A per-pairing IRK can defend against the attack. The per-pairing IRK design works perfectly for the central role. However, for the peripheral role, the per-pairing IRK design may have performance overhead.
1.1 The Zephyr device acts as a central device.
Assume an app on the Zephyr development board acts as the central role and connects to a BLE peripheral, such as a bulb. When the board
connects to the bulb, the board can generate a new IRK and use this IRK as the local IRK to generate an RPA. During pairing, the board can
distribute this IRK to the bulb and store this IRK as local IRK and the bulb’s IRK as peer IRK in the resolving list (page 279 in the specification).
When the board reconnects to the bulb after pairing, the board always uses the IRKs (local and peer IRKs) stored in the resolving list. So the
board and the bulb can still recognize each other since they share the same set of IRKs. When the board unpairs with the bulb, remove the
corresponding local and peer IRKs.
With the per-pairing IRK design, the board can make sure that the local IRK distributed to the peripheral device is no longer used when it
unpairs with the peripheral. Consequently, the per-pairing IRK can prevent the attack we proposed.
1.2. The Zephyr device acts as a peripheral device.
For example, a sample app (https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/peripheral_identity) running on the
development board acts as the peripheral role. When the board first advertises (the board did not pair with any central device through this
app), the Zephyr should generate a new IRK and use the RPA generated based on this IRK. During pairing, the board distributes this IRK to the central device and stores this IRK as a local IRK and the central device’s IRK as a peer IRK in the resolving list. Meanwhile, Zephyr maintains a paired-device list and also adds the record (local-peer IRK pair) to this list. After pairing, when the board advertises, Zephyr goes through each record on the paired-device list and generates an RPA for each record based on its local IRK. Then the board advertises using the previously generated RPAs. When the sample app unpairs with a central device, Zephyr removes the corresponding record from both the resolving list and the app’s paired-device list.
Even though the per-pairing IRK design can completely mitigate the attack, it has some performance overhead, which may make the central
device require more time to discover the peripheral device. For example, if a board pairs with 3 central devices, there are 3 records on the
paired-device list. When the board advertises, it has to advertise 3 times to make it discoverable for all 3 paired central devices. The RPA in each advertising corresponds to each of the local IRKs of the record on the paired-device list.
- Fix to the second issue (fixed IRK for the default identity):
Even though the specification allows to calculate the IRK from IR, for privacy consideration, it would be better to randomly generate an IRK for the default identity.
Reporter
Jianliang Wu [email protected]
Antonio Bianchi [email protected]
Tian, Jing [email protected]
Xu, Dongyan [email protected]
Patches
For more information
If you have any questions or comments about this advisory:
embargo: 2022-01-12
Impact
We would like to report a privacy issue we recently discovered in the Zephyr Bluetooth stack. It could enable the attacker to track the victim
device’s physical location. Our experiment shows that it affects the version of Zephyr (2.7-rc1). It may also affect other versions.
Issue:
Bluetooth Low Energy (BLE) uses a resolving identity key (IRK) to generate the resolvable private address (RPA). The use of RPA protects the privacy of a BLE device while allowing two paired devices to recognize each other.
Zephyr allows an app using BLE to create new identities (MAC address and IRK pairs) for BLE for better privacy. However, even with the privacy feature enabled (CONFIG_BT_PRIVACY=y and CONFIG_BT_CTRL_PRIVACY=y), we found the following 2 issues that allow the attacker to track the victim device’s physical location.
1 We found that one identity can use only one IRK, and the IRK is still valid after the BLE app unpairs or forgets a paired device, unless the app explicitly deletes or resets the identity.
2 We also found that Zephyr will use a fixed IRK for the default MAC address of BLE, if the controller’s identity root (IR) is fixed.
Each of these two issues allows, separately, a device running Zephyr to be tracked once the attacker obtains the IRK. When the privacy feature is enabled, the IRK is distributed to the peer device when pairing over BLE. As a consequence, the IRK can be obtained by the attacker when the victim device pairs with a malicious BLE device or the paired BLE device is compromised, making the tracking of the user practical.
What is worse is that unpairing the malicious (or compromised) BLE device does not stop the tracking because the same IRK is still used and not changed when unpairing with the malicious device, unless the app explicitly deletes/resets the identity. Moreover, when the default identity is used, completely resetting the Zephyr OS does not prevent the tracking either, if the IR is fixed.
In summary, after an app pairs with a malicious/compromised device, the attacker can track (i.e., understand when the user is physically near) the user, even after the user unpaired with such malicious/compromised device. Additionally, if a BLE app uses the default identity, even completely resetting Zephyr OS may not prevent the tracking.
Detailed explanation:
BLE introduces a new privacy feature (page 278 in the Bluetooth Core Specification 5.2,
https://www.bluetooth.com/specifications/specs/core-specification/) that allows using the RPA as the MAC address of a BLE device. To use an RPA, a device must have an IRK and use the IRK to generate RPAs following the procedures described in the specification (page 2861 in the specification). Correspondingly, to resolve an RPA and identify a device, the same IRK (the one used to generate the RPA) is needed.
It is not clearly stated in the Bluetooth Core Specification how many IRKs a device should use, and we found that Zephyr allows a BLE app to
create new identities for BLE for better privacy. However, even with the privacy feature enabled (CONFIG_BT_PRIVACY=y and
CONFIG_BT_CTRL_PRIVACY=y), we found the two issues stated earlier after experimenting with our development board (nRF52840 DK with Zephyr 2.7-rc1) and reading the following code.
1 One identity has only one IRK, and the IRK is still valid when the BLE app unpairs with a remote device:
zephyr/subsys/bluetooth/host/id.c
Line 1021 in b08e572
When unpairs with a peer device, the remote IRK is removed but the local IRK is not removed:
zephyr/subsys/bluetooth/host/hci_core.c
Line 1657 in e2f85b1
If BT_SETTINGS is set, the IRK will be stored, and it will be reused when calling settings_load() function
zephyr/subsys/bluetooth/host/id.c
Line 1015 in b08e572
2 The IRK for the default MAC address may be fixed (depending on the behavior of the used board):
In fact, Zephyr tries to read the IR from the controller:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/host/id.c#L1249
Then it calculates the IRK based on IR:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/host/id.c#L1251
Therefore, if the IR is fixed (as in the nRF52840 DK board we used for testing), the IRK is also fixed.
Each of these two issues may make the device using Zephyr trackable once the victim device pairs with a malicious BLE device or the paired
BLE device is compromised. The victim device is still trackable even if the victim device unpairs with the malicious (or compromised) BLE
device. If the default identity is used by a BLE app (the app does not create new identities explicitly), even completely resetting the Zephyr OS may not prevent the tracking. As a consequence, the following attack scenario, in which the attacker can track the location of a victim device user, is possible.
Attack model:
The victim device uses RPAs and has been paired with a malicious BLE device under the attacker's control. The victim user may pair with a
malicious BLE device by mistake. It is also possible that the paired BLE device is compromised.
The user can potentially unpair with the malicious BLE device after mistakenly pairing with it. The attacker can deploy malicious devices at
different places to sniff the BLE packets (including BLE advertising messages, Scan requests, Scan responses, and connection requests).
Attack steps:
pairing, the device running Zephyr may distribute its IRK to the malicious BLE device
(
zephyr/subsys/bluetooth/host/smp.c
Line 2193 in e2f85b1
According to the specification (page 1390 in the specification), a device using an RPA shall always distribute its IRK during pairing (this aligns
with our observation during our experiments). As a result, if the victim device uses an RPA, its IRK will always be distributed to the attacker
when the victim device pairs with the malicious BLE device.
The attacker can also get the victim device’s IRK from a compromised paired BLE device since the victim device always distributes its IRK during pairing.
(optional) The user notices she has paired the victim device with a malicious (or compromised) device and unpairs with it.
Once the attacker obtains the IRK, the attacker can track the victim user's location when the victim device uses the BLE functionality (e.g.,
advertising messages) with an RPA. The deployed malicious devices sniff BLE packets and extract the RPAs from the packet. Then the malicious
devices try to resolve RPAs and identify the victim device with the procedures described in the specification (page 2862 in the specification). If the RPA is resolved, it means that the victim device is close to the location of the malicious device that receives the BLE packet and resolves the RPA.
Impact:
We have done experiments on an nRF52840 DK development board with Zephyr 2.7-rc1. When enabling the privacy feature in Zephyr BLE, the RPAs are used, and the victim device distributes its IRK during pairing. Accordingly, the attacker can obtain the IRK when the victim device pairs with a malicious BLE device or the paired BLE device is compromised. Once the attacker obtains the IRK, she can track the victim user's location when the victim device uses the BLE functionalities, such as broadcasting advertising messages or connecting to a BLE peripheral.
Unpairing with the malicious BLE device does not help to mitigate the tracking because the victim device will still use the same IRK after unpairing. If the app uses the default identity, even completely resetting the Zephyr OS may not stop the tracking.
Possible Fix:
A per-pairing IRK can defend against the attack. The per-pairing IRK design works perfectly for the central role. However, for the peripheral role, the per-pairing IRK design may have performance overhead.
1.1 The Zephyr device acts as a central device.
Assume an app on the Zephyr development board acts as the central role and connects to a BLE peripheral, such as a bulb. When the board
connects to the bulb, the board can generate a new IRK and use this IRK as the local IRK to generate an RPA. During pairing, the board can
distribute this IRK to the bulb and store this IRK as local IRK and the bulb’s IRK as peer IRK in the resolving list (page 279 in the specification).
When the board reconnects to the bulb after pairing, the board always uses the IRKs (local and peer IRKs) stored in the resolving list. So the
board and the bulb can still recognize each other since they share the same set of IRKs. When the board unpairs with the bulb, remove the
corresponding local and peer IRKs.
With the per-pairing IRK design, the board can make sure that the local IRK distributed to the peripheral device is no longer used when it
unpairs with the peripheral. Consequently, the per-pairing IRK can prevent the attack we proposed.
1.2. The Zephyr device acts as a peripheral device.
For example, a sample app (https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/peripheral_identity) running on the
development board acts as the peripheral role. When the board first advertises (the board did not pair with any central device through this
app), the Zephyr should generate a new IRK and use the RPA generated based on this IRK. During pairing, the board distributes this IRK to the central device and stores this IRK as a local IRK and the central device’s IRK as a peer IRK in the resolving list. Meanwhile, Zephyr maintains a paired-device list and also adds the record (local-peer IRK pair) to this list. After pairing, when the board advertises, Zephyr goes through each record on the paired-device list and generates an RPA for each record based on its local IRK. Then the board advertises using the previously generated RPAs. When the sample app unpairs with a central device, Zephyr removes the corresponding record from both the resolving list and the app’s paired-device list.
Even though the per-pairing IRK design can completely mitigate the attack, it has some performance overhead, which may make the central
device require more time to discover the peripheral device. For example, if a board pairs with 3 central devices, there are 3 records on the
paired-device list. When the board advertises, it has to advertise 3 times to make it discoverable for all 3 paired central devices. The RPA in each advertising corresponds to each of the local IRKs of the record on the paired-device list.
Even though the specification allows to calculate the IRK from IR, for privacy consideration, it would be better to randomly generate an IRK for the default identity.
Reporter
Jianliang Wu [email protected]
Antonio Bianchi [email protected]
Tian, Jing [email protected]
Xu, Dongyan [email protected]
Patches
For more information
If you have any questions or comments about this advisory:
embargo: 2022-01-12