Hi Andras,
I'm glad the explanation was helpful, I appreciate some of these concepts are a bit unusual.
linuxman wrote: ↑Tue Nov 17, 2020 6:25 pm
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.
linuxman wrote: ↑Tue Nov 17, 2020 6:25 pm
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.