ESP2 efuse and the hardware module

[Seungwhan]

Hi,
Got some questions on ESP32 efuse and the hardware module.
Since my thoughts are not quite organized yet, my questions may not make sense at all.

1. What we are trying to do is,
- write our own key to Block3
(our own key : can be our own private key or public key or both.)
- read protect Block3
- later, read key from Block3 and use it to verify the signed app or sign any data.
=> I guess this is normally not possible, because we read protected Block3, and once read protected it can only accessed by the hardware module.

So my question is
- what actually is the hardware module? Is it some MCU with ROM code? or something more like ASIC or FPGA?
- motivation of asking this question is to check the possibility of having the hardware module to have our own taste so that we can use Block3 for our own purpose.

2. One of your online document says,
"Verification on update: When enabled, the signature is automatically checked whenever the esp_ota_ops.h APIs are used for OTA updates."

Can you please explain in more detail on this?
Which key is used for this? Maybe the public-key compiled together with the boot loader?
Can we use key from Block2 or Block3?
Can we modify the behavior of this "Verification on update"?

I'll probably have more follow up questions but this is what I have at the moment.
Oh and we are using ESP-IDF v3.2.

Thanks for reading and appreciate your reply.

[WiFive]

1. Hardware block like asic. Only used for flash encryption and bootloader signature check. At most you could use it to do those functions with a block 3 key but this is not documented or supported. If you use block 3 it has to be readable. Otherwise use encrypted flash partitions to store secrets.

2. Yes the key compiled into the bootloader. No this verification is done in software not by the hardware block. You can change it but then you have to make sure you don't break the bootloader check.

[Seungwhan]

Hi,
Thanks so much for the quick reply.
I have one quick follow up question.

Your document say, when secure boot is enabled,
whenever after the first boot, bootloader will recalculate the digest and will compare it with the pre-saved digest.
I went through most of the bootloader and bootloader_support source codes but wasn't able to find where that happens.
Can you please point me where this happens?

Thank you!

[WiFive]

https://github.com/espressif/esp-idf/bl ... mat.c#L198

[Seungwhan]

WiFive,

Thanks for quick reply.
But I am not quite sure if verify_secure_boot_signature() is what I wanted.

Maybe my question was not clear enough.
I am trying to locate where it checks the genuineness of the bootloader image.
To achieve this goal, if I understood correctly,
it will first read key from Efuse Block 2 and (re)calculate the digest,
and compare this digest with the one pre-written at 0x0.
But verify_secure_boot_signature() doesn't seem to do this?
Or is it actually doing it?

I guess ets_secure_boot_check() could be the one doing that but it is never used in esp-idf.

If will be great if you could clarify this.
Thanks.

[ESP_Angus]

Hi Seungwhan,

You're right. The ESP32 boot process is a two stage process, and therefore the Secure Boot system is also a two stage process. The first stage is the ROM loader verifying the integrity of the ESP-IDF bootloader. This is done using the key stored in efuse block 2, and the digest stored in flash. This verification happens in the mask ROM of the ESP32 before any IDF code is running. Then the IDF bootloader verifies the signature of the app, before booting that (chain of trust concept). The app verification stage use asymmetric encryption and ECDSA signatures.

OTA updates also use the ECDSA signature to verify the app image, as only the app is updated via OTA not the bootloader. The ECDSA public key is compiled into both the bootloader and the app (and the hardware digest verifies that the bootloader binary is valid, so the ECDSA public key should be valid).

For full details see the Secure Boot docs here:
https://docs.espressif.com/projects/esp ... -boot.html

Because keys stored in efuse are only usable by hardware modules (for both flash encryption and secure boot), they are not accessible by software. If you want to protect a key in hardware that is used for software purposes, recommend using flash encryption for this. The easiest option is to use NVS and the NVS Encryption feature:
https://docs.espressif.com/projects/esp ... encryption

[Seungwhan]

Great!
I may come up with a follow up question in the future,
but this solves all my questions for now.
Thanks so much!

*Oh and that's true.
I thought I have read that document several times but I missed(or didn't pay much attention to) that phrase everytime, "5. On subsequent boots the ROM bootloader sees".

[Seungwhan]

Hi,
We are finalizing our scenario and I have one follow up question.

In a simple word,
is it possible to use flash encryption without boot loader encrypted?
(Also we are not planning to use secure boot.)

When we enable flash encryption,
or let me just say we make parity of FLASH_CRYPT_CNT efuse to odd,
does the ROM loader check this register and try to decrypt the data(software bootloader in this case) as it fetches data from Flash?

Our motivation is just to encrypt very small partition of the flash where we will keep our secret.

Thanks again!

[WiFive]

No, if you enable the efuse for flash encryption the bootloader and app have to be encrypted. You may be able to use the spi_flash_read_encrypted function without enabling it but overall this isn't a secure solution because someone could flash a malicious app to dump the encrypted secret.

[ESP_Angus]

Sorry for delayed reply, WiFive is right. Actually it's not possible to decrypt at all unless flash encryption is on, and when it's on then it's on for all cache accesses (which includes code execution and any read from SPI flash which does not explicitly disable using flash encryption).

We recommend using secure boot and flash encryption together, and flash encryption must be applied to bootloader and all app partitions.

If using only flash encryption, make sure to write-disable the FLASH_CRYPT_CNT efuse to prevent an attacker from disabling flash encryption and then writing their own bootloader that re-enables encryption and then dumps the contents of the flash.