Flash encryption - flashing pre-encrypted app.bin

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: Flash encryption - flashing pre-encrypted app.bin

Postby ESP_Angus » Thu Aug 29, 2019 12:50 am

GerryTitan wrote:
Wed Aug 28, 2019 5:54 pm
By "config", do you mean by modifying sdkconfig? Are you referring to functions like "esp_partition_write" and "esp_spi_flash_write"? What about reading encrypted? (Not from the cache).
Sorry for not being clear, that's correct I mean the project config in the sdkconfig file.

Yes, the write functions need to follow a different code path to write encrypted data and this isn't compiled in if support is disabled.

Some different code is also compiled in for encrypted partition reads - in order to be transparently decrypted, the data needs to be mapped via the MMU flash cache feature (spi_flash_mmap). Whereas the plain "spi_flash_read" will read the exact contents of flash, which in this case would be the ciphertext.

GerryTitan
Posts: 30
Joined: Mon Oct 15, 2018 2:10 am

Re: Flash encryption - flashing pre-encrypted app.bin

Postby GerryTitan » Thu Aug 29, 2019 1:37 am

Great. Thanks again for the response.

dovoto
Posts: 27
Joined: Tue Apr 20, 2021 3:51 pm

Re: Flash encryption - flashing pre-encrypted app.bin

Postby dovoto » Fri Aug 19, 2022 7:51 pm

ESP_Angus wrote:
Tue Aug 27, 2019 11:36 pm
GerryTitan wrote:
Tue Aug 27, 2019 1:52 pm
Hi, I actually have a question related to this point. Regarding the first boot for flash encryption, are there any disadvantages to the following workflow? For the record, I am using ESP-IDF v3.2.
  • Generate flash encryption key, write to eFuse
  • Set FLASH_CRYPT_CNT to 1, FLASH_CRYPT_CONFIG to 15, set other relevant eFuses (DISABLE_DL_*, JTAG)
  • Pre-encrypt bootloader, app, and partition table, then flash everything to the chip
Hi Gerry,

The only disadvantage is that it's time consuming to burn all these efuses and easy to get this sequence wrong. If you miss one of the other relevant efuses then the device may not end up configured as you expect.

If you have some use cases for it being easier for doing it like this then we could add additional host-side support as well (for example a one-step espefuse.py command which sets everything correct). For now to keep things simple there's one supported method, and it's the "first boot" method.
GerryTitan wrote:
Tue Aug 27, 2019 1:52 pm
(Also related: Is it still necessary to enable flash encryption for the bootloader if the above steps are followed?)
It's not supported/tested but I think the bootloader will work even without this config. The app needs to built with encryption enabled in the config, otherwise some of the SPI flash code to write encrypted is not compiled in.
The use case for this is simple: Pre encrypting the binary saves about 1.5 minutes of programming time on the factory floor which means I can spend about $200k less on programming fixtures.

I didnt find the documentation for preencrypting binaries very clear (it took me about two hours to figure out the right sauce)

Generate the key using the espsecure tool
Encrypt all binaries using espsecure (the bootloader, the application, the initial ota data, any binaries you are loading into pre encrypted memory)
Burn the key using espefuse
Set the rest of the fuses according to the way the firmware would have done it: https://docs.espressif.com/projects/esp ... on-process
Set the fuses to disable all the things you dont want your user to be able to do (jtag etc..)
Burn your encrypted binaries

Who is online

Users browsing this forum: aapee-jcv and 444 guests