ESP32 Forum

Hello!

I activated secure boot with Reflashable mode on my device and I was wondering whether I can change it to One-Time Flash or at least emulate it by making the digest and bootloader write-protected on the flash. If I understand correctly, this is the main difference between the two methods: whether the digest and bootloader can be rewritten.
As I was looking around in my eFuse with command I found that my ABS_DONE_0 is 1 but my ABS_DONE_1 is 0. Is it the thing that shows me that I am in reflashable mode so I can reflash digest? I don't understand 'abstract' word here and didn't really find the meaning of this flag.

So my questions are, can I change somehow from reflashable method to OTF and what does ABS_DONE_1 mean?

Thanks in advance,
András

Hi Andras,

Unfortunately this is not really possible, although it may not be necessary depending on what you need:

As you are probably aware, in Secure Boot V1 the bootloader has a digest stored at offset 0x0 in the flash. The digest is calculated from the bootloader contents and the secret key stored in eFuse (read & write protected). Then the bootloader uses a different mechanism to verify the ECDSA signature on the app.

In "one time flash" mode, the Secure Boot key in eFuse is randomly generated by the device on the first boot. So there is no workflow to generate a new digest to flash a new bootloader.

In "reflashable" mode, the Secure Boot key in eFuse is the SHA-256 hash of the ECDSA private key used to sign the apps. If you have the private key you use to sign the apps, then you can also generate a new bootloader digest and reflash the new bootloader and digest together.

The reason "reflashable" mode is not recommended for production is that the key in eFuse will be identical for every device that uses the same signing key. This means that it's possible to swap the bootloader and digest from one device to another. However if Flash Encryption is used (always should be the case when using Secure Boot) and each device has a different flash encryption key then each bootloader and digest ciphertext is still different, so swapping bootloader and digest is not viable without also bypassing Flash Encryption.

eFuse bit ABS_DONE_1 is not used by Secure Boot V1. In ESP32 V3 this eFuse is used to enable Secure Boot V2, on earlier ESP32 revisions it is unused.

Hi ESP_Angus,

wow, thank you for the fast and detailed explanation, that makes a lot of things clear. However, there are two things I don't understand.

In "reflashable method" you can also generate a new bootloader digest and reflash the new bootloader and digest together.

Is there any other usage of "reflashable method", then swapping the bootloader and digest from one device to another? Why should one flash a new bootloader to a device that has already secure boot available? Shouldn't it be the goal that the secure bootloader is permanent?

The other thing is, that you mentioned SHA-256. So if I understand correctly, in "OTF" mode, there's an AES256 key, in "reflashable mode", there's an SHA-256 hash in eFuse?

Thanks,
András

Hi Andras,

I'm glad the explanation was helpful, I appreciate some of these concepts are a bit unusual.

wow, thank you for the fast and detailed explanation, that makes a lot of things clear. However, there are two things I don't understand.

In "reflashable method" you can also generate a new bootloader digest and reflash the new bootloader and digest together.

Is there any other usage of "reflashable method", then swapping the bootloader and digest from one device to another? Why should one flash a new bootloader to a device that has already secure boot available? Shouldn't it be the goal that the secure bootloader is permanent?

That's right. There is generally no reason to pick "reflashable" mode once in production, as the bootloader is intended to be permanent once flashed. However reflashable mode provides a way to re-flash the bootloader in development, without disabling Secure Boot or having to store a second "Secure Boot eFuse key" for just this purpose.

The other thing is, that you mentioned SHA-256. So if I understand correctly, in "OTF" mode, there's an AES256 key, in "reflashable mode", there's an SHA-256 hash in eFuse?

The ESP32 hardware uses the same eFuse block for the Secure Boot AES key (digest calculation key) in both modes. The only difference is how this key is generated:

In One Time Flash mode, it's a random 256 bit sequence generated by the RNG on first boot. It's expected that noone has a copy of this key.

In Reflashable mode, it's the SHA-256 hash of the private key used to sign the app (because this is a 256-bit value that can only be generated by someone who has the private signing key, but is otherwise not predictable.)

There is nothing stopping someone from generating a 256-bit random key and burning this to the Secure Boot eFuse key block on the ESP32 manually before first boot. They could also have a "reflashable" bootloader this way instead (i.e. the same hardware configuration as the documented configurations, and because they know the key stored in the eFuse they can generate new digests). The only reason we don't document this as the preferred way to make the bootloader "reflashable" is that it requires storing two secret keys - the private key used to sign apps, and this eFuse key. The "Reflashable" mode removes the need to keep a separate eFuse key, because the eFuse key is derived from the signing key instead.

Let met know if you have more questions about this.