ESP32 Forum

Hi urbanze,

You don't need a new chip.

Code: Select all

E (112) flash_encrypt: Cannot re-encrypt data (FLASH_CRYPT_CNT 0xff write disabled 0

This is a bug in the IDF bootloader (it thinks FLASH_CRYPT_CNT 0xFF means encryption is disabled not enabled, so it's trying to encrypt again). Will fix ASAP.

The upload of the binary to the server will no longer be the RAW .bin file, but rather the encrypted file with the same key

Since it is safe to play Flash Crypto with pre-generated key, I will continue abusing the code upload and my adventures. Waiting for this bugfix, thanks for the help guys.

One last question at this moment (besides the previous ones that I will copy)

2. To upload new bootloader, I need to upload it crypted or decrypted?
3. To upload new ota_data_initial, I need to upload it crypted or decrypted?
4. To upload new partitions, I need to upload it crypted or decrypted?

5.I said in one post later:

The upload of the binary to the server will no longer be the RAW .bin file, but rather the encrypted file with the same key

but since flash crypto with pre key need to be uploaded with .bin crypted, I can upload this crypted to server or need to recrypt again?!

2. crypted.
3. crypted.
4. crypted.
Sending anyone decrypted will fail and eFuse..._CTN still in past value (good notice hehe)
Sending anyone crypted will work and eFuse..._CTN still in past value (expected)

5. Apparently, no need to crypt again to decrypt in code, just send this .bin crypted by "compiler" to server.

Can anyone tell me how --force-write-always works? Unintentionally I ran make flash before burning the key

Hi urbanze,

2. crypted.
3. crypted.
4. crypted.
Sending anyone decrypted will fail and eFuse..._CTN still in past value (good notice hehe)
Sending anyone crypted will work and eFuse..._CTN still in past value (expected)

That's right, any time FLASH_CRYPT_CNT has an odd number of bits set (or 0xFF) -> all these things have to be encrypted.

Any time FLASH_CRYPT_CNT has an even number of bits set (but not 0xFF) -> all of these things have to be plaintext.

Otherwise, the ESP32 is unable to read the data from flash.

5. Apparently, no need to crypt again to decrypt in code, just send this .bin crypted by "compiler" to server.

Kind of. There are two things to consider here:

1. The OTA app_update framework assumes that the binary data you give it is plaintext, and it uses the esp_partition APIs which will automatically encrypt anything written to a partition with flash encryption enabled. This means it will double-encrypt the OTA if it's already flash encrypted data, and you won't be able to boot. If you write your own routines to write to flash, you can write the flash encrypted data as-is.

2. Distributing pre-encrypted binaries on the server means either (a) you use the same flash key on all devices, or (b) you have to store a different binary for each ESP32, and keep a database of which ESP32 has which key. We don't recommend (a), because a compromise of one flash key will compromise all your devices. If you're not concerned about this then you can do (a), though. Doing (b) is possible but complex, which is why we want to develop an alternative method for encrypting the OTA binary on the server.

Can anyone tell me how --force-write-always works? Unintentionally I ran make flash before burning the key

Normally, "espefuse.py burn_key" will fail in software if it looks like the efuse key (BLK1, BLK2 or BLK3) has already been burned, rather than try to burn it anyhow.

"--force-write-always" will cause espefuse.py to try and burn it anyhow. If the efuse is write protected, this will do nothing as the write will be blocked in hardware. If the efuse is not write protected, the result will be bitwise or: (Old Contents) | (New Contents), because efuse bits can only be burned 0->1 not the other way around.

If you accidentally booted an ESP32 with flash encryption enabled in the bootloader, no "insecure options", and no pre-burned key then it will have generated a random key, written it to efuse, and then read and write protected it. You can't change this key or access it. The only thing you can do to update this ESP32 is to follow the "serial flashing" process where you disable flash encryption and reflash it again. Flash encryption can be re-enalbed this way up to 3 times, total: https://docs.espressif.com/projects/esp ... l-flashing

(Note that if you disable flash encryption and don't re-enable it, you can keep using this ESP32 as normal.)

Hi urbanze,

2. crypted.
3. crypted.
4. crypted.
Sending anyone decrypted will fail and eFuse..._CTN still in past value (good notice hehe)
Sending anyone crypted will work and eFuse..._CTN still in past value (expected)

That's right, any time FLASH_CRYPT_CNT has an odd number of bits set (or 0xFF) -> all these things have to be encrypted.

Any time FLASH_CRYPT_CNT has an even number of bits set (but not 0xFF) -> all of these things have to be plaintext.

Otherwise, the ESP32 is unable to read the data from flash.

5. Apparently, no need to crypt again to decrypt in code, just send this .bin crypted by "compiler" to server.

Kind of. There are two things to consider here:

1. The OTA app_update framework assumes that the binary data you give it is plaintext, and it uses the esp_partition APIs which will automatically encrypt anything written to a partition with flash encryption enabled. This means it will double-encrypt the OTA if it's already flash encrypted data, and you won't be able to boot. If you write your own routines to write to flash, you can write the flash encrypted data as-is.

2. Distributing pre-encrypted binaries on the server means either (a) you use the same flash key on all devices, or (b) you have to store a different binary for each ESP32, and keep a database of which ESP32 has which key. We don't recommend (a), because a compromise of one flash key will compromise all your devices. If you're not concerned about this then you can do (a), though. Doing (b) is possible but complex, which is why we want to develop an alternative method for encrypting the OTA binary on the server.

Can anyone tell me how --force-write-always works? Unintentionally I ran make flash before burning the key

Normally, "espefuse.py burn_key" will fail in software if it looks like the efuse key (BLK1, BLK2 or BLK3) has already been burned, rather than try to burn it anyhow.

"--force-write-always" will cause espefuse.py to try and burn it anyhow. If the efuse is write protected, this will do nothing as the write will be blocked in hardware. If the efuse is not write protected, the result will be bitwise or: (Old Contents) | (New Contents), because efuse bits can only be burned 0->1 not the other way around.

If you accidentally booted an ESP32 with flash encryption enabled in the bootloader, no "insecure options", and no pre-burned key then it will have generated a random key, written it to efuse, and then read and write protected it. You can't change this key or access it. The only thing you can do to update this ESP32 is to follow the "serial flashing" process where you disable flash encryption and reflash it again. Flash encryption can be re-enalbed this way up to 3 times, total: https://docs.espressif.com/projects/esp ... l-flashing

(Note that if you disable flash encryption and don't re-enable it, you can keep using this ESP32 as normal.)

With pre-generated key and protected FLASH_CRYPT_CNT (in odd), esp32 will accept only crypted binaries, then, why Espressif tells to enable secure boot? What is the insecure that option returns? With _CTN protected, secure boot is really necessary?