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
- 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
- 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.
- 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.
- 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.