Indeed, since it is only the physically accessible products that can be targeted by a fault injection attack, ESP32’s security design remains effectively safe for the vast majority of our products.

For the affected products, Espressif does have a migration path available through an updated SoC revision (ESP32 ECO V3). However, before making a decision to move to this revision, customers are advised to understand the impact of the attack and evaluate if their product is likely to be affected. The details below are intended to help in this regard.

Understanding the Attack

Fault injection attacks are techniques for disrupting the behavior of an electronic system by injecting faults via physical means. An attacker introduces a small error into the externally controlled components of the chip to disturb its normal operation. When specifically targeted to the security subsystem, it can result in the attacker obtaining the cryptographic key that is used internally, or skipping a required security check. The obtained cryptographic key, then, can be further used to read and modify information such as firmware and data stored in the device’s flash memory. There are various physical methods for a fault injection, such as carefully timed voltage or clock fluctuations, external temperature variation, laser irradiation or using strong magnetic fields.

We believe that this type of attack is not unique to ESP32 SoC. Other commercial chips are also known to be susceptible to this type of attack.

The attack on ESP32, described in this disclosure by LimitedResults, specifically resulted in:

1. Revealing the secure boot key and, thereby, bypassing the secure boot check and booting untrusted firmware;
2. Revealing the flash encryption key that was  used to encrypt the application firmware and flash contents.

It is important to note the following points about the attack:

1. The attack requires physical access to the ESP32 SoC, so that parts can be removed from the circuit board or module. Circuit board traces may also need to be cut or modified before it is connected to the attacker's equipment.
2. The attacker's voltage glitching equipment must be connected to particular power supply pins of the SoC, so that repeated attempts can be made to introduce a correctly timed voltage fluctuation.

Understanding Secure Boot and Flash Encryption in ESP32

In order to understand the impact of the above-mentioned attack, it is useful to summarize how these two features work on ESP32.

Secure Boot

When the secure boot is enabled, at the first boot the software bootloader generates and programs a “per-device unique” secure boot key in the eFUSE memory. This is the AES-256 key and  is used to compute digest for the software bootloader and to program the digest in the flash. Then, upon the subsequent bootup, the bootROM verifies the digest against the actual software bootloader image, using the AES-256 key.

Verification of the application from the software bootloader is done using the Elliptic Curve Digital Signature   Algorithm (ECDSA). The software bootloader contains ONLY the public key, whereas the private key remains with developers. Even when the software bootloader is decrypted with a fault injection attack, only the public ECDSA key is obtained. It is not possible to use this public key to sign the firmware or to obtain the private key. Hence, the device cannot be programmed with any other firmware.

Flash Encryption

When the flash encryption feature is enabled, at the first boot the software bootloader generates  and programs a “per-device unique” flash encryption key and then encrypts the specified sections of the flash data with this key.

Impact of the Attack on ESP32

With the above information about the function of the secure boot and flash encryption schemes, it is easy to analyze the impact of losing the flash encryption key or bypassing the secure boot check.

Even if the flash encryption key is obtained by the malicious user, the flash encryption key corresponds only to the  unit that the attacker used. This is because each ESP32 chip has a uniquely generated flash encryption key. So, the flash contents and sensitive data that are  specific only to that product unit can be obtained by the attacker.

Just like the flash encryption key, the secure boot key is also unique to each ESP32 chip. Hence, the possible bypassing of the secure boot check is also specific to that particular ESP32 chip. This can’t be used to execute an untrusted application on a remote ESP32.

The bottom line is that due to the per-device unique flash encryption and secure boot crypto-keys, the attack surface of such an  attack is limited  only to the specific device that the attacker holds. This attack does not scale up to a larger number of devices in the same product-line, which are not in the attacker’s physical possession.

For more details, please review the security advisory posted on 1 November 2019.

What is the Impact on Your Product?

In order to evaluate if your product can potentially be affected by such an attack, you should consider whether any of the following conditions are true for your product:

1. Your product is deployed outdoors or in a public place where physical tampering and subsequently connecting  glitching equipment pose  a possible threat.
2. Your product contains a shared secret across all product units and this secret is stored in the flash memory connected to ESP32.

In the cases above, we advise you to use the new revision of the SoC, ESP32 ECO V3, in your product design.

If your product does not fall in any of the above-mentioned categories, the impact from this attack is low when using the current ESP32 SoC.

How ESP32 ECO V3 Addresses This Threat

ESP32 ECO V3 has the following enhancements that protect the product against physical fault injection attacks:

1. ESP32 ECO V3 supports a PKI-based (RSA) secure boot scheme where the eFuse contains only the public key (in fact a cryptographic hash of the public key) and the private key always remains with you. This ensures that it is not possible for an attacker to create a signed bootloader which can be persisted in the flash and incorrectly trusted by Secure Boot.
2. ESP32 ECO V3 is hardened against fault injection attacks in hardware and software, so that it prevents any unintended key disclosure through voltage glitching.

If you are developing a new product, you can consider ESP32 ECO V3-based modules or chips in your product design. For more information about ESP32 ECO V3, please check out the relevant document.

ESP32 ECO V3 Availability

Engineering samples of ESP32 ECO V3-based modules (ESP32-WROVER-E and ESP32-WROOM-32E) are already available in limited quantity. These modules will be available for mass production in March 2020. Please get in touch with sales@espressif.com for any further enquiries regarding these parts.