Espressif Security Advisory concerning fault injection and eFuse protections (CVE-2019-17391)
Issue Summary
Please also read the previous important message
An attacker who uses fault injection to physically disrupt the ESP32 CPU immediately after reset can corrupt eFuse bits when they are being read out by the internal hardware. This includes corrupting read protection eFuse bits, which control software read access to other parts of eFuse.
This fault injection attack can allow bypassing of read protection for Flash Encryption and Secure Boot keys stored in eFuse. The keys are often also corrupted by the fault, but by repeating the attack and analyzing the results a full eFuse key value may be recovered.
At time of writing, currently available ESP32 chips (ESP32-D0WD, ESP32-D2WD, ESP32-S0WD, ESP32-PICO-D4, and related modules) are vulnerable to this attack. The ESP32-D0WD-V3 chip has checks in ROM which prevent this attack. This chip and related modules will be available in Q4 2019. More information about ESP32-D0WD-V3 will be released soon.
What is fault injection?
Fault injection is a technique for disrupting the behaviour of a hardware system by injecting faults via physical means, often by carefully timed voltage or clock fluctuations. To deploy fault injection an attacker must have physical access to the hardware to modify it and inject faults.
Following a fault, the system will usually crash. However sometimes a carefully timed fault may cause the CPU or an internal hardware process to skip a particular instruction or corrupt the result of a particular operation. By repeating the fault injection process a large number of times, an attacker may eventually get a result which bypasses a security measure.
All electronic hardware is vulnerable to some types of physical fault injection, although the difficulty of inducing the fault varies.
Impact of the attack
This attack requires physical access to the device, and the time and resources to modify the device to apply fault injection.
Using fault injection to successfully recover the Flash Encryption key from an ESP32 allows an attacker to read the device’s flash contents including firmware and data stored in flash. It also allows updating the encrypted contents of flash.
Using fault injection to successfully recover the Secure Boot key from an ESP32 allows generating a new valid secure boot digest to allow booting a modified bootloader.
The recommended configuration for Flash Encryption and Secure Boot keys is that each devices generates individual and unique keys. If this is the case, then eFuse keys recovered from a single ESP32 chip cannot be reused on other ESP32 chips. The physical fault injection attack must be repeated against each individual chip in order to recover additional keys.
Mitigations in ROM
In May 2019, Espressif worked with security analysts from Riscure in order to review the ESP32 boot ROM code including modifications made to harden it against fault injection.
When making these changes, it was identified that there might be potential for fault injection to corrupt eFuse values when they were read by the hardware after reset. Additional checks were added in ROM code to protect against this possibility, and these checks are included in the ESP32-D0WD-V3 chip.
ESP32-D0WD-V3 also adds support for a new Secure Boot V2 scheme based on asymmetric cryptography. Secure Boot V2 does not require a read-protected Secure Boot key. ESP-IDF software support for Secure Boot V2 will be released in Q4 2019. Secure Boot V1 is also supported on ESP32-D0WD-V3, with checks in ROM to prevent fault injection attacks.
The forthcoming ESP32-S2 SoC has additional hardware and ROM code provisions to protect against fault injection, including against this attack. ESP32-S2 also uses the Secure Boot V2 scheme.
Recommendations for ESP32 Users
If producing devices which require ESP32 Flash Encryption and/or Secure Boot features then it is recommended to use ESP32-D0WD-V3 chips or the related ESP32-WROVER-E modules which include fault injection checks in ROM. Please contact Espressif Sales with your requirements.
For already deployed hardware using other ESP32 silicon revisions, there is no software mitigation for this issue.
Additional general recommendations:
• Remove any unnecessary sensitive data from flash storage, if possible. This includes providing a “factory reset” option which removes customer data from flash before the product is sold or disposed of.
• Use per-device unique keys for Secure Boot and Flash Encryption.
• Generate per-device unique keys stored in flash for application uses, rather than using a single shared key across all devices.
The ESP32-D0WD-V3 chip has checks in ROM which prevent fault injection attack.
This chip and related modules will be available in Q4 2019.
More information about ESP32-D0WD-V3 will be released soon.
More info please have a note
best wishes
rudi
