Digi International Security Notice
Secure Session SRP ephemeral values are not randomized if BLE is disabled
Digi International Security Notice
March 2, 2020
The purpose of this notice is to inform our customers of a security vulnerability regarding the establishment of Secure Session connections on XBee 3 RF firmware. This notice informs our end users of the vulnerability, which devices are impacted, what steps users can perform to mitigate the risk and to inform you of what Digi is doing to fix this issue.
The random number generator used to generate the one-time ephemeral shared key during Secure Session authentication is only initialized when Bluetooth is enabled on the device. Only XBee 3 Zigbee and XBee 3 802.15.4 are affected and only if Secure Session is being used.
This vulnerability can only be exploited by a node internal to the network and only impacts the security of a Secure Session connection. Secure Session is not critical to the operation of the device but could allow a bad actor to affect device configuration in some circumstances. Thus, Digi has rated the ability to exploit this vulnerability as LOW
The vulnerability is limited to particular versions of firmware for the Digi XBee 3 RF radio modules. The following firmware variants are impacted:
- Digi XBee 3 Zigbee versions 1008 and 1009
- Digi XBee 3 802.15.4 version 2006
Note: if you have questions on any Digi products and services not listed, contact us at +1 (952) 912-3456, or via the web site at www.digi.com/support
This vulnerability is not present in the following RF firmware variants:
Detailed Information on Affected Products
Secure Session is a feature on XBee 3 RF firmware that can restrict remote configuration and/or serial data to devices that have the appropriate credentials. For more information on Secure Session and how it can be used to protect devices on your network from unauthorized remote configuration, please refer to the Secure Access
section of the user guide.
The random number generator used for SRP authentication is only initialized when BLE is enabled (BT
). Thus, if BLE is disabled and a Secure Session established, the shared key that is generated will be identical every time; capturing two successful sessions would be sufficient to glean the private key.
If Secure Session is not being used, then there is no risk to the security of the device due to this vulnerability. In order to glean the private key: BLE must be disabled when the device starts, at least two successful secure sessions must be established, and the RF exchanges captured with a sniffer. If Secure Session is being used in addition to AES encryption (EE
), then the bad actor would also need to have the appropriate encryption keys necessary to decrypt the RF packets. Encryption keys are write-only and cannot be read.
If BLE is enabled when the device boots, then the RNG is properly initialized and the Secure Session authentication will be secure.
In the field, Digi sees the ability to exploit this vulnerability as LOW. The risk, however, needs to be determined by the end-user and how they have chosen to deploy devices within their environment, and who might have access to those devices.
Suggested Steps to Protect Your Network
There are several ways to protect against this vulnerability:
- The initialization routine is corrected in version 100A (Zigbee) and 200A (802.15.4). Using this version or newer will always initialize the RNG upon startup.
- In order to prevent a bad actor from downgrading the firmware to expose the vulnerability, Digi has also added the ability to reject OTA updates unless they originated from a particular 64-bit address using the US command.
- Enable BLE by setting BT to 1 and writing this to configuration with WR.
- If you do not wish to use BLE, you can immediately disable it by setting BT to 0. BLE only needs to be enabled once per boot for the RNG to be initialized. A MicroPython script or configuration change from the host device can be set up to disable BLE after startup.
Mar 05, 2020