ESP32 Forum

Hello,

I have gone glimpsed through the Docs on the Flash Encryption. I just wanted to get some clarification:

1. If pre-generated flash encryption key is used, I can flash the ESP32 any number of times. Can this be done using USB in Release mode ? Or will I be reduced to using SPI flashers ?

2. Using built in random key encryption, is there anyway I can enable USB flashing but not reverse downloading? What I mean is I should be able to flash the device any number of times but the App/Contents itself should not be read out to a hacker ?

3. In production scenario, is there any way I can pre-encrypt a .bin file and it flashes the key also to the ESP32 ? eg. instead of using the Flash tool and specifying every sector (i.e bootloader, app, etc.), I can Just encrypt the Build file with key and flash that to ESP using command-line tool ?
Any way I can use the above for the first flash ?

4. What happens if I flash an ESP32 (brand new - no previous flashes before) with an encrypted .bin ? will it brick it? will it just throw error so that i can re-flash with plain text ?

5. UART refers to USB ?

Thanks so much!

Regards,

Hi gb.123,

gb.123 wrote: 1. If pre-generated flash encryption key is used, I can flash the ESP32 any number of times. Can this be done using USB in Release mode ? Or will I be reduced to using SPI flashers ?

If the key has been generated on the host, you can flash the ESP32 any number of times, unless UART Download Mode has been disabled. UART Download mode can be disabled on ESP32 revision 3 (a.k.a. ECO3) and later chips. To prevent UART Download Mode from being disabled, enable "CONFIG_SECURE_DISABLE_ROM_DL_MODE" under "Potentially insecure options" menu in menuconfig. If UART download mode is disabled, no flashing over UART is possible.

(Note, if you also enable Secure Boot v1, additional restrictions apply regarding re-flashing the 2nd stage bootloader; check Secure Boot docs)

gb.123 wrote: 2. Using built in random key encryption, is there anyway I can enable USB flashing but not reverse downloading? What I mean is I should be able to flash the device any number of times but the App/Contents itself should not be read out to a hacker ?

This is what Development mode of flash encryption does. It allows flash encryption module to be used in UART Download Mode, so you can write plaintext firmware into the chip using esptool (or "idf.py encrypted-flash"). However, this configuration is insecure, because the attacker can simply upload a very small application into Flash in place of the 2nd stage bootloader, and that application can read out the contents of the rest of the flash and dump it over UART.

gb.123 wrote: 3. In production scenario, is there any way I can pre-encrypt a .bin file and it flashes the key also to the ESP32 ? eg. instead of using the Flash tool and specifying every sector (i.e bootloader, app, etc.), I can Just encrypt the Build file with key and flash that to ESP using command-line tool ?
Any way I can use the above for the first flash ?

You can do this using the provided tools:
1. "esptool.py merge_bin" can be used to combine multiple binaries (bootloader, partition table, application) into a single binary
2. "espsecure.py" tool command can be used to encrypt the binary with a pre-generated key
3. "esptool.py write_flash" can be used to flash the encrypted binary to the chip
4. "espefuse.py" can be used to write the encryption key into the chip's eFuses.

Take note that aside from writing the encryption key into eFuses you also need to burn additional eFuses to make the chip secure — for example, disable encryption and decryption in download mode, disable JTAG, read- and write- protect relevant eFuse blocks, and so on.

Currently we have a tool in development which will automate these aspects.

gb.123 wrote: 4. What happens if I flash an ESP32 (brand new - no previous flashes before) with an encrypted .bin ? will it brick it? will it just throw error so that i can re-flash with plain text ?

If the related encryption key hasn't been burned into eFuses, and flash encryption is not enabled (again, by burning related eFuse) then the ROM bootloader will attempt to load the 2nd stage bootloader from flash and will fail, because it will see what looks like garbage instead of the correct 2nd stage bootloader binary image. The chip will not be bricked, only the ROM bootloader will keep trying to boot the application, and then getting reset by the watchdog timer and starting from scratch. At this point you can put the chip into download mode and flash it again with some other binary, or burn flash encryption keys using espefuse.py.

gb.123 wrote: 5. UART refers to USB ?

ESP32 chip doesn't have a USB peripheral, communication with the host happens over UART. Most development boards come with a UART-USB bridge, which allows you to connect the development board over USB to the computer. From the ESP32 chip's perspective, communication still happens over UART. Most products don't include the UART-USB bridge, and production flashing happens either over UART (e.g. using a connector or test points), or by flashing the SPI Flash chips themselves.


Hope this helps!

Hi ESP_igrr,

First of all Thanks so much for your early reply !
Still some questions left..

If the key has been generated on the host, you can flash the ESP32 any number of times, unless UART Download Mode has been disabled. UART Download mode can be disabled on ESP32 revision 3 (a.k.a. ECO3) and later chips. To prevent UART Download Mode from being disabled, enable "CONFIG_SECURE_DISABLE_ROM_DL_MODE" under "Potentially insecure options" menu in menuconfig. If UART download mode is disabled, no flashing over UART is possible.

=> But SPI Flash would still be possible ?

gb.123 wrote:
2. Using built in random key encryption, is there anyway I can enable USB flashing but not reverse downloading? What I mean is I should be able to flash the device any number of times but the App/Contents itself should not be read out to a hacker ?

This is what Development mode of flash encryption does. It allows flash encryption module to be used in UART Download Mode, so you can write plaintext firmware into the chip using esptool (or "idf.py encrypted-flash"). However, this configuration is insecure, because the attacker can simply upload a very small application into Flash in place of the 2nd stage bootloader, and that application can read out the contents of the rest of the flash and dump it over UART.

=>Forgot to mention I would be using Secure Boot v2 (ESP DevKit V3/4). If I use Secure Boot with Signed Boot in addition to Flash Encryption, then would it be secure enough to leave UART Download Mode enabled ?

Take note that aside from writing the encryption key into eFuses you also need to burn additional eFuses to make the chip secure — for example, disable encryption and decryption in download mode, disable JTAG, read- and write- protect relevant eFuse blocks, and so on.

Any specific eFuses which are important ?

DISABLE_DL_ENCRYPT (If set, disables flash encryption operation while running in Firmware Download mode)
=> Means I cannot upload new plaintext firmware ?

DISABLE_DL_DECRYPT(If set, disables flash decryption while running in UART Firmware Download mode.)
=> Means firmware cannot be dumped back ? (Flash Contents cannot be read)

(I noticed I cannot turn of "Leave UART Bootloader Encryption Enabled" under potentially insecure options.)
(This is when development mode is selected)
And I can see CONFIG_SECURE_FLASH_UART_BOOTLOADER_ALLOW_ENC in sdkconfig.dev. Is this the same as : CONFIG_SECURE_DISABLE_ROM_DL_MODE ?

Currently we have a tool in development which will automate these aspects.

Hate to ask ... but any ETA ? ( I know this shouldn't be asked but am very eager to use ESP32 for my production!)

Just my suggestion for the tool... There should be a way to securely store pre-generated key in the tool so that it gets burned with .bin but the key once input cannot be recovered...(maybe use another encryption and ask for password every x number of flashes (configurable) ) ?
Also... How about an option that other encrypted bins can be pre-flashed from Espressif (in case of large order) and only the key gets burned at the client's end using this tool ? (maybe create ability to mass burn keys at client end)

gb.123 wrote:=> But SPI Flash would still be possible ?

Yes, if you have direct access to SPI flash pins and if you know the encryption key you can still reflash.

gb.123 wrote: =>Forgot to mention I would be using Secure Boot v2 (ESP DevKit V3/4). If I use Secure Boot with Signed Boot in addition to Flash Encryption, then would it be secure enough to leave UART Download Mode enabled ?

Theoretically, yes. However some attacks on ESP32 revision 1 have been facilitated using the ROM bootloader, so we recommend the ROM bootloader to be be disabled (for ESP32 revision 3) or limited to "Secure download mode" (for later chips). Note that this isn't that keeping download mode enabled opens ESP32 for a known attack vector, it is just that disabling it is an additional layer of security ("defense in depth" approach). Please see this post as well: viewtopic.php?f=13&t=16783&p=63509.

gb.123 wrote:Any specific eFuses which are important ?

For ESP32, only DISABLE_JTAG and FLASH_CRYPT_CONFIG seem to be missing from your list. Please see this post as well: viewtopic.php?f=13&t=9977&p=41213.

gb.123 wrote: Hate to ask ... but any ETA ? ( I know this shouldn't be asked but am very eager to use ESP32 for my production!)

I'm sorry, it's not close enough to a release for me to give you a reasonable estimate. I think we will try to publish the first version in Q1 next year.

I think the current version of the tool doesn't handle secrets storage (it is supposed to be handled by the environment the tool is running it), but this is a nice suggestion, I'll pass it along to the author.

"Currently we have a tool in development which will automate these aspects."

Is the tool finished? I am in production now and need to start flash encryption. The target is ESP32C3, and the code is uploaded by UART (it cannot be OTA uploaded since the application is 3.6 MB out of 4MB of flash)