ESP32 Forum

Hi,

I think the whole flash encryption topic is describe very detailly in the docs, but there are so much steps to follow to do it right, that it gets quite confusing... After studying the docs for days, I anyway bricked a chip yesterday
Maybe you guys could review my procedure first, before trying it with the next chip?

1. Enabled Flash encryption
(For beginning: No secure boot. I want to enable this in a later step. First get flash-encryption running.) 2. Erase entire flash 3. Clean and build with new config 4. Generate key on local machine 5. Fuse key to device 6. Pre-encryt app.bin with previously generated key.
Please note, that I use a custom partition-table with no factory app and 2 OTA partitions: ota1 @ 0x10000 and ota2 @ 0x110000 7. Flash pre-encrypted app At that stage, I have my key on device and have ota1 flashed with my pre-encrypted binary.
Is this right?
Is the device now ready to run or is something missing?

Big thanks!

doglike wrote: ↑

Mon Aug 26, 2019 1:49 pm

I think the whole flash encryption topic is describe very detailly in the docs, ..

it does not make much sense to copy the setup, config , steps from the esp idf here again,
Just read that RTFM from begin the theme, it is describe very detailly in the docs.

Hi rudi,
great! Lets shut down this forum - the answer to questions is always RTFM

So... is my understanding right or did I miss anything in the steps above?
Thanks

rudi, I know that your goal is always to be helpful but when posting on the forums please be polite and don't tell people to "RTFM", especially when their post says that they've read the available docs.

doglike wrote: ↑

Mon Aug 26, 2019 1:49 pm

At that stage, I have my key on device and have ota1 flashed with my pre-encrypted binary.
Is this right?
Is the device now ready to run or is something missing?

If the only steps you followed are the exact ones shown here, then the device won't work as flash encryption is not actually enabled (FLASH_CRYPT_CNT efuse is still zero), and no bootloader or partition table has been flashed. But it's also not bricked.

For the *first boot* you should flash absolutely everything in plaintext (bootloader, partition table, app) and let the bootloader (compiled with flash encryption enabled in the config) encrypt the device itself and set all the relevant efuses.

If you want to use a pre-generated key then you still follow the same basic process, the only difference is that *before* you flash anything you need to do the "espefuse.py --port *COMport" burn_key flash_encryption MY_KEY.bin" step. Then on first boot the bootloader will see there is already a flash encryption key set and won't generate a new one.

After the first boot the flash will be encrypted and you can do "espsecure.py encrypt_flash_data" and re-flash with updated pre-encrypted binaries, as needed.

Specifically, the set of steps to follow starts from here (IDF v3.2):
https://docs.espressif.com/projects/esp ... yption-key

If you're using ESP-IDF v4.x (master branch) then we added a new "development mode" flash encryption config so it's no longer necessary to save a pre-generated key in order to re-flash the app many times during development. Those steps are here:
https://docs.espressif.com/projects/esp ... pment-mode

doglike wrote: ↑

Mon Aug 26, 2019 1:49 pm

I anyway bricked a chip yesterday

The good news is, if flash encryption wasn't enabled permanently (and secure boot is disabled) then the chip is probably not bricked. Specifically, if the FLASH_CRYPT_CNT efuse is still writeable and not at the maximum value. You can check with "espefuse.py summary".

The steps to disable flash encryption are here:
https://docs.espressif.com/projects/esp ... encryption

If you know the flash encryption key that was burned to this chip, you can re-enable flash encryption as if it was a new chip and burn pre-encrypted updates from then on.

If the flash encryption key was randomly generated on first boot then you can only re-enable a few more times, or you can keep this unit as an unencrypted ESP32 from now on.

ESP_Angus wrote: ↑

Mon Aug 26, 2019 11:51 pm

rudi, I know that your goal is always to be helpful but when posting on the forums please be polite and don't tell people to "RTFM", especially when their post says that they've read the available docs.

sry angus

edit

Was I rude?
Was that rude "Read the fine manual"
and to refer to the IDF DOC to the chapter?
If this was considered unhealthy by you,
then you have misunderstood something.

what are you doing now?
you quote now in your answers the whole manual
quote from it,
and mix versions 3.2 last and others,
is that better now?
is it clearer? is it easier?
does anyone understand it better now?

/edit

the RTFM is well desribed.
i do not know, which doc the TO has read, so
i link to my well knowed RTFM and there is all really nice desribed.

I think I'm old enough
and do not need a guardian anymore
who tells me what I have to do or not.

if there are rules rules and I have violated it
then please show me, otherwise please refrain
now and here the command tone.

No, I'm not offended!
everything is clean in the docu.
One can save oneself such troll questions.
there are other unanswered ones
which certainly need more attention
my opinion.

edit

/edit

incredible!


@doglike

RTFM

doglike wrote: ↑

Mon Aug 26, 2019 6:50 pm

Hi rudi,
great! Lets shut down this forum - the answer to questions is always RTFM

so perhabs we can delete all docu then cause there is nobody who read the docu?
or link in the docu then each answere from forum to each question?
i like foren and Q and A
but the docu is really well described.
you did not say which version you read
i linked to the last, what @angus did also too.

greetings
'catlike'

Hi ESP_Angus,

thanks for your reply!
I will check "espefuse.py summary" asap and post it here. But it is not so bad, if one chip is bricked. It's more important to learn from mistakes.

Meanwhile I found another post with lots of good information: https://esp32.com/viewtopic.php?t=7348

ESP_Angus wrote: ↑

Mon Aug 26, 2019 11:51 pm

If the only steps you followed are the exact ones shown here, then the device won't work as flash encryption is not actually enabled (FLASH_CRYPT_CNT efuse is still zero), and no bootloader or partition table has been flashed. But it's also not bricked.

For the *first boot* you should flash absolutely everything in plaintext (bootloader, partition table, app) and let the bootloader (compiled with flash encryption enabled in the config) encrypt the device itself and set all the relevant efuses.

If you want to use a pre-generated key then you still follow the same basic process, the only difference is that *before* you flash anything you need to do the "espefuse.py --port *COMport" burn_key flash_encryption MY_KEY.bin" step. Then on first boot the bootloader will see there is already a flash encryption key set and won't generate a new one.

After the first boot the flash will be encrypted and you can do "espsecure.py encrypt_flash_data" and re-flash with updated pre-encrypted binaries, as needed.

Specifically, the set of steps to follow starts from here (IDF v3.2):
https://docs.espressif.com/projects/esp ... yption-key

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

(Also related: Is it still necessary to enable flash encryption for the bootloader if the above steps are followed?)

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.

ESP_Angus wrote: ↑

Tue Aug 27, 2019 11:36 pm

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.

Okay, thank you for the answer. I do not have any particular use case for it. I am just trying to better understand how the process works.

GerryTitan wrote: ↑

Tue Aug 27, 2019 1:52 pm

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.

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).