ESP32 Forum

Hello,

We're working on a ESP32 based product that will hit large production numbers later this year. After carefully reading the documentation and checking the forum, I'm having some questions about the usage of the Secure Boot and Flash Encryption mechanism, which will be important to plan the actual mass production.
Since this product will be probably assembled and programmed in an external company, it is important that

1. it should be impossible for an external party with wrong intentions to readback the whole SPI flash contents and making another unflashed ESP32 device work by flashing that content into it
2. As a countermeasure of not supplying the full firmware to the external party, the product should be able to be individually ''activated' with the full firmware. HTTPS OTA is a possible way for this. As a result, it should also be possible to 'de-activate' a device.

My questions regarding the above requirements are:

1. I understand direct SPI readback can't be avoided and that Flash Encryption mitigates this issue. I furthermore understand that we can leverage Secure Boot to make sure only our code runs on the board. However, it seems that both techniques automatically initialise themselves and burn the respective eFuses upon noticing the device isn't secured yet. So if an external party with wrong intentions is to directly flash previously read back flash SPI contents (even encrypted) to an empty chip, will this device work or not? I would suppose not, since the flash encryption key is necessary to actually decrypt and run the firmware in the first place. But just want to be sure.
2. Does Secure Boot also guarantee that only that device runs the code, or is 'activated'? In other words, does the Secure Boot hashing algorithm also take in account a unique identifier that is specific for the chip that's being enabled for Secure Boot? The doc specifies:

   Hardware secure boot support generates a device secure bootloader key (generated via hardware RNG, then stored read/write protected in efuse), and a secure digest. The digest is derived from the key, an IV, and the bootloader image contents.

   It seems that the used key is app binary specific, not device specific. The IV seems random, and I'm not sure whether the bootloader image contents contain something device specific.
   Furthermore, am I correct in understanding that read-only eFuses can only be read by hardware? As a consequence, does this mean in only applies to the 'hardware part' of the SecureBoot mechanism, because I don't see hardware eFuse access mentioned somewhere else? If we would devise an activation mechanism trough setting bits in the eFuses (for example using the MAC address), We can't read protect this from external readout because then the software itself can't read it. We also can't write-protect since then we're not able to 'de-activate' that device later on, or to for example change it's license. NVS storage doesn't seem to be encrypted so I can't store a custom activation key there.
   What would be the best way to achieve this?

Thanks for any replies.

Yes if you copy the flash contents to another device it won't boot because the encryption key is different. Secure boot also uses a unique signing key per device for the bootloader. However the app signing key is not unique per device. Read-protected efuses can only be read by hardware. Nvs does support software encryption with a hardware encrypted keystore.

But let's say you have a determined insider attacker who can obtain your factory image and clone one of your unactivated devices. They can then attempt to activate the clone with encryption disabled and obtain the full ota image. Depending on how smart your activation server is you may be able to detect this.

vjacobs wrote: ↑

Mon May 20, 2019 9:31 am

[*] I understand direct SPI readback can't be avoided and that Flash Encryption mitigates this issue. I furthermore understand that we can leverage Secure Boot to make sure only our code runs on the board. However, it seems that both techniques automatically initialise themselves and burn the respective eFuses upon noticing the device isn't secured yet. So if an external party with wrong intentions is to directly flash previously read back flash SPI contents (even encrypted) to an empty chip, will this device work or not? I would suppose not, since the flash encryption key is necessary to actually decrypt and run the firmware in the first place. But just want to be sure.

The default flash encryption workflow does assume that the device is unencrypted at the beginning, and is flashed with plaintext firmware before the first boot. If the factory doing assembly & initial bringup is an untrusted environment then this method won't work exactly as-is, because the factory has access to a plaintext copy of the firmware.

One method for working with an untrusted factory is discussed here: https://www.esp32.com/viewtopic.php?t=9994

We're also working on an official method for doing something similar, but nothing ready to announce right now.

It seems that the used key is app binary specific, not device specific. The IV seems random, and I'm not sure whether the bootloader image contents contain something device specific.

The bootloader secure boot digest is based on the secure boot key (generated by hardware RNG) and the IV. So it's device specific, as only the device's secure boot engine can access the key that was generated on the device (stored read-protected in efuse).

The bootloader is the only part of the firmware protected by the secure boot digest. The main app is verified using an ECDSA signature, which is generated from an Ellipitic Curve private key and verified with the matching Elliptic Curve public key that is burned into the bootloader. (This is a "chain of trust" where the boot ROM verifies the bootloader and then the bootloader verifies the app.) The key pair for app signing is app-specific, generally you would use the same private key to sign a firmware binary for all devices, and then deploy the same public key in the bootloader across all devices.

Furthermore, am I correct in understanding that read-only eFuses can only be read by hardware? As a consequence, does this mean in only applies to the 'hardware part' of the SecureBoot mechanism, because I don't see hardware eFuse access mentioned somewhere else? If we would devise an activation mechanism trough setting bits in the eFuses (for example using the MAC address), We can't read protect this from external readout because then the software itself can't read it. We also can't write-protect since then we're not able to 'de-activate' that device later on, or to for example change it's license. NVS storage doesn't seem to be encrypted so I can't store a custom activation key there.

That's more or less correct, once "read protected" (or read disabled), software reads of an efuse block will see all zeroes but the hardware peripheral (Secure Boot peripheral or Flash Encryption peripheral) is still able to access the key values. If efuses are left readable by software, they can also be read out by an attacker with physical access to the ESP32.

For software-based secure storage you can use NVS with flash encryption since ESP-IDF V3.2: https://docs.espressif.com/projects/esp ... encryption

Thanks WiFive and ESP_Angus for the replies!

That cleared up quite some things. It seems that a combination of 'Option 2' in the link you posted (using HTTPS OTA to also flash the full firmware with a new bootloader that has flash encryption enabled) with using Encrypted NVS to store custom activation keys could meet our requirements.

Am I correct in understanding that the initial limited factory firmware next to not having flash encryption on, also can't have Secure Boot on? Because this last would render rewriting the bootloader impossible.

Thanks.