ESP32 Forum

Hi guys, I started to venture into these 2 items to apply in one product of the company where I work and although well documented, there are many extremely technical terms that slow down a bit for those who are not in the security area. So I want to leave this post for simple questions (or not) that I will or someone in the future...


I'm testing, for now, only the OTA secure boot without the *hardware* secure boot, I've already done the tests with the .pem key generated by espsecure.py and, although very interesting, it left me some questions :

1. If the key used to create the .bin by the idf needs to be the same as the one in esp32, what would the process be for "updating" this key if I need to change it or even lose the file? Imagine that I lost the .pem of a device and need to update it remotely with a new key, how would the process (if possible) be?


2. I have an FTP server where the main .bin is available, however, there is still the bootloader and partitions binarys. How does an OTA update work if I need to change the partition table?

1. Not possible
2. Not supported

To expand on WiFive's answers (which are correct), I'll answer in reverse order:

2.There's no support for OTA updating the bootloader or the partition table. Technically, you can have your app erase these flash regions and overwrite them, but if there's a power failure or anything goes wrong then you have a brick which needs physical reflashing.

For the record, if hardware Secure Boot is enabled then changing the bootloader would also require changing the bootloader secure boot digest (so you'd need to know the secure boot key in efuse, see "Reflashable" mode in the docs).


1. The public key for verifying app signatures is compiled into the bootloader. Changing the bootloader via OTA is not supported (see #2). So if you use hardware secure boot or enable "Bootloader verifies app signatures" (new in master branch for v3.2), then only one public key can be used.

If you enable "Verify app signature on update" only (also new), then the public key is compiled into the app. So, with a bit of fiddling, if you have "App version 1" which is checking "Key A" and it downloads "App version 2" which was signed with "Key A" but is compiled to check "Key B", then you can transition your devices from an old key to a new key. But each app will still only verify one key, so to update the app you'll need the matching key.

You could theoretically modify the bootloader or ESP-IDF to compile in multiple public keys, so you have a "backup" key that is kept offline somewhere. This isn't supported though, and the recommended practice is to to be careful about not losing or leaking your original signing key.

ESP-IDF build signing has support for signing binaries offline, so you can have a totally separate signing server if this is desirable for security and/or not losing track of keys.

ESP_Angus wrote:To expand on WiFive's answers (which are correct), I'll answer in reverse order:

2.There's no support for OTA updating the bootloader or the partition table. Technically, you can have your app erase these flash regions and overwrite them, but if there's a power failure or anything goes wrong then you have a brick which needs physical reflashing.

For the record, if hardware Secure Boot is enabled then changing the bootloader would also require changing the bootloader secure boot digest (so you'd need to know the secure boot key in efuse, see "Reflashable" mode in the docs).


1. The public key for verifying app signatures is compiled into the bootloader. Changing the bootloader via OTA is not supported (see #2). So if you use hardware secure boot or enable "Bootloader verifies app signatures" (new in master branch for v3.2), then only one public key can be used.

If you enable "Verify app signature on update" only (also new), then the public key is compiled into the app. So, with a bit of fiddling, if you have "App version 1" which is checking "Key A" and it downloads "App version 2" which was signed with "Key A" but is compiled to check "Key B", then you can transition your devices from an old key to a new key. But each app will still only verify one key, so to update the app you'll need the matching key.

You could theoretically modify the bootloader or ESP-IDF to compile in multiple public keys, so you have a "backup" key that is kept offline somewhere. This isn't supported though, and the recommended practice is to to be careful about not losing or leaking your original signing key.

ESP-IDF build signing has support for signing binaries offline, so you can have a totally separate signing server if this is desirable for security and/or not losing track of keys.

The low possibility of changing the partitions makes me very insecure. The project is not yet 100% finished and it may be that we need to increase some LOG or CONFIG partitions. But since this is so, (which might be a future update to allow the partition to change via OTA), I believe I will increase the size of the CONFIG partition for possible adjustments.

Let's go to the next basic question.

1. What MENUCONFIG options change the bootloader.bin? Any of them? Someone? Only "bootloader submenu"? Which are?

For example if I change the CPU clock, only the main.bin needs to be updated or bootloader.bin too?

urbanze wrote:1. What MENUCONFIG options change the bootloader.bin? Any of them? Someone? Only "bootloader submenu"? Which are?

For example if I change the CPU clock, only the main.bin needs to be updated or bootloader.bin too?

"SDK tool configuration", "Bootloader config", "Security features", "Serial flasher config" (the SPI speed/size/mode settings), "Partition Table" (partition table offset), "Compiler options".

(Basically all of the top-level menus.)

The bootloader is designed to be cross-compatible with apps compiled with different settings and forwards compatible to newer versions, so changing settings and building a new app should still work with an older/different bootloader. I think the only thing which will totally break compatibility between the app and the bootloader is changing the partition table offset (and maybe even there are some hacky ways you could make this work to change some partition details, by having the bootloader read one partition table and the then the app reads a different partition table at a different offset, but this is unsupported.)

CPU frequency is entirely set in the app not the bootloader.

Secure boot say: "Secure Boot is a feature for ensuring only your code can run on the chip. Data loaded from flash is verified on each reset."

Flash enc say: "When flash encryption is enabled, physical readout of the SPI flash is not sufficient to recover most flash contents."



With the secure boot, only my codes (or whoever has the key) can update the code in mcu and with the flash enc reading the flash code is difficult. Okay.

I'm adding OTA via server, a simple HTTP GET request, which in theory anyone could do (via browser) it and also download the product binary (and maybe replicate our product). Are there any ways to either of the above 2 options make my code work only on my specific hardware?

So whoever has the binary but it is not a hardware that left us, you will not get much. Or would that be simpler to secure on the server-side? What do you advise to protect binary? Ensuring that only our hardware can download it...

urbanze wrote: I'm adding OTA via server, a simple HTTP GET request, which in theory anyone could do (via browser) it and also download the product binary (and maybe replicate our product). Are there any ways to either of the above 2 options make my code work only on my specific hardware?

So whoever has the binary but it is not a hardware that left us, you will not get much. Or would that be simpler to secure on the server-side? What do you advise to protect binary? Ensuring that only our hardware can download it...

You want to prevent the OTA app from being downloaded by a third party? Yes, the recommended way to do this is to secure it on the server side somehow. If your device already connects to an app server then it must have some way to authenticate itself, suggest reusing this.

(Using Flash Encryption and Secure Boot on the device itself will prevent an attacker from being able to clone whatever secret/key/etc is used to authenticate the device.)

1. Flash enc. prevent someone to read my code, okay. But how can I prevent my code to run in non-auth esp's? Secure boot ensure that only my code run in my hardware, but I would like to prevent my code run in another esp. Ideias?

2. If I can't update bootloader and partitions, what happen if I update idf version? And toolchain?

1. Don't let anybody get unencrypted bin file
2. It will always be backwards compatible (unless release notes say otherwise)

Yes, what WiFive says is correct. You'll need some way to authorize OTA updates from your server.

ESP-IDF apps are currently supported to find on bootloaders back to ESP-IDF v1.0 (although apps need this config item enabled if bootloader is pre-v2.1).