ESP32 Forum

Hi Angus,

I also enable flash encryption in menuconfig.


# Security features
#
CONFIG_SECURE_SIGNED_ON_BOOT=y
CONFIG_SECURE_SIGNED_ON_UPDATE=y
CONFIG_SECURE_SIGNED_APPS=y
CONFIG_SECURE_BOOT_ENABLED=y
CONFIG_SECURE_BOOTLOADER_ONE_TIME_FLASH=y
CONFIG_SECURE_BOOTLOADER_REFLASHABLE=
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES=
CONFIG_SECURE_BOOT_VERIFICATION_KEY="signature_verification_key.bin"
CONFIG_SECURE_BOOT_INSECURE=
CONFIG_FLASH_ENCRYPTION_ENABLED=y
CONFIG_FLASH_ENCRYPTION_INSECURE=


It is Flash encryption with secure boot and signing.

Now signing is all working. now I enabled flash encryption. It is not working any more.

Do I need to first encrypt my all bins including bootloader then do sign and generate secure bootloader from encrypted boot loader bin.

To enable flash encryption:
espefuse.py --port COM184 burn_key flash_encryption encryption_key.bin
espefuse.py --port COM184 burn_efuse FLASH_CRYPT_CONFIG 0xF
espefuse.py --port COM184 burn_efuse FLASH_CRYPT_CNT


I do following first generate encrypted bins.

espsecure.py encrypt_flash_data --keyfile encryption_key.bin --address 0x1000 -o ./build/bootloader-encrypted.bin ./build/bootloader/bootloader.bin


espsecure.py encrypt_flash_data --keyfile encryption_key.bin --address 0x20000 -o ./build/app-encrypted.bin ./build/W2K1-BootLoader-Release.bin

espsecure.py encrypt_flash_data --keyfile encryption_key.bin --address 0x8000 -o ./build/partitions-encrypted.bin ./build/partitions.bin

then use these encrypted bins to generate signed bins.

espsecure.py sign_data --keyfile signing_key.pem --output ./build/signed_partitions.bin ./build/partitions-encrypted.bin
espsecure.py sign_data --keyfile signing_key.pem --output ./build/signed_W2K1-BootLoader-Release.bin ./build/app-encrypted.bin
espsecure.py digest_secure_bootloader --keyfile secure_boot_key.bin --output ./build/secure_bootloader.bin ./build/bootloader-encrypted.bin

Finally:

esptool.py --port COM184 --baud 921600 write_flash 0x0000 ./build/secure_bootloader.bin 0x8000 ./build/signed_partitions.bin 0x20000 ./build/signed_W2K1-BootLoader-Release.bin

Error:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371


Is this because I already flash secure boot loader with out encryption. It expect encrypted secure bootloader.

Any steps wrong?

Thanks,
Naeem

Hi Naeem,

The digest has to be encrypted as well, and based on the plaintext bootloader not the ciphertext version.

ie I'm not sure this is the root cause of your current problem though, as the error for a bad digest is "secure boot check fail" not the error you're getting. The "flash read 1000" error indicates the header of the bootloader at offset 0x1000 doesn't look like a valid bootloader image - this would indicate a problem with encryption.

So if the above steps don't solve the problem, could you please post the output of "espsecure.py summary" with any sensitive keys marked out.

If you plan to enable flash encryption using "espefuse burn_efuse FLASH_CRYPT_CNT" for production devices, rather than using the method described in the documentation where the bootloader burns these efuses itself, then please note that there are some other efuses which need to be burned to have a secure system:
https://github.com/espressif/esp-idf/bl ... ypt.c#L117

Hi Angus,

1-
Basically it is working. First we need to signed then encrypt the bins. I was doing other way around.

2-
I do get this warning message from esptool when encrypt signed bins. This happens to all bins.

espsecure.py encrypt_flash_data --keyfile encryption_key.bin --address 0x8000 -o ./build/partitions-encrypted.bin ./build/signed_partitions.bin

espsecure.py v2.6-beta1
Using 256-bit key
WARNING: Padding with 12 bytes of random data (encrypted data must be multiple of 16 bytes long)


Is this issue?

Two different way of doing flash the encrypted signed bin.

3- First method.

Our ideal production process is
We would like to flash only signed bins and not encrypted. As part of our production process we enable encryption on via esptool then we will OTA the signed bins. which will do OTA write and encrypt bins while writing via OTA.

bin via flash is different then OTA bins in term of size and code.

CONFIG_FLASH_ENCRYPTION_ENABLED=n

Not enable flash encryption via menuconfig.

Is this method possible?

4- Second method.

If step # 3 is not possible. This step 4 works for me.



#
# Security features
#
CONFIG_SECURE_SIGNED_ON_BOOT=y
CONFIG_SECURE_SIGNED_ON_UPDATE=y
CONFIG_SECURE_SIGNED_APPS=y
CONFIG_SECURE_BOOT_ENABLED=y
CONFIG_SECURE_BOOTLOADER_ONE_TIME_FLASH=y
CONFIG_SECURE_BOOTLOADER_REFLASHABLE=
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES=
CONFIG_SECURE_BOOT_VERIFICATION_KEY="signature_verification_key.bin"
CONFIG_SECURE_BOOT_INSECURE=
CONFIG_FLASH_ENCRYPTION_ENABLED=y
CONFIG_FLASH_ENCRYPTION_INSECURE=

Enable secure boot and encryption on via esptool

flash signed and encrypted bins then OTA the signed bins. which will do OTA write and encrypt bins while writing via OTA.


Method # 2 is working. I wonder method # 1 is possible.


Thanks,
Naeem

Can some one answer please.

Hi Angus,

1-
Basically it is working. First we need to signed then encrypt the bins. I was doing other way around.

Fantastic!

2-
I do get this warning message from esptool when encrypt signed bins. This happens to all bins.

espsecure.py encrypt_flash_data --keyfile encryption_key.bin --address 0x8000 -o ./build/partitions-encrypted.bin ./build/signed_partitions.bin

espsecure.py v2.6-beta1
Using 256-bit key
WARNING: Padding with 12 bytes of random data (encrypted data must be multiple of 16 bytes long)

Is this issue?

No, this is not an issue.

Starting from IDF v3.2, esptool will pad the .bin file when secure boot is enabled and will not have this warning. However you can ignore it.

3- First method.

Our ideal production process is
We would like to flash only signed bins and not encrypted. As part of our production process we enable encryption on via esptool then we will OTA the signed bins. which will do OTA write and encrypt bins while writing via OTA.

bin via flash is different then OTA bins in term of size and code.

CONFIG_FLASH_ENCRYPTION_ENABLED=n

Not enable flash encryption via menuconfig.

Is this method possible?

Do you want to use known keys, or random keys generated on the device?

If you enable encryption via esptool, you'll need to flash encrypted binaries. Otherwise the device won't be able to boot after encryption is enabled with esptool.

Can I ask why you can't use the recommended process of building with CONFIG_FLASH_ENCRYPTION_ENABLED=y, flashing plaintext, and then having the device encrypt itself on first boot?

4- Second method.

If step # 3 is not possible. This step 4 works for me.

#
# Security features
#
CONFIG_SECURE_SIGNED_ON_BOOT=y
CONFIG_SECURE_SIGNED_ON_UPDATE=y
CONFIG_SECURE_SIGNED_APPS=y
CONFIG_SECURE_BOOT_ENABLED=y
CONFIG_SECURE_BOOTLOADER_ONE_TIME_FLASH=y
CONFIG_SECURE_BOOTLOADER_REFLASHABLE=
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES=
CONFIG_SECURE_BOOT_VERIFICATION_KEY="signature_verification_key.bin"
CONFIG_SECURE_BOOT_INSECURE=
CONFIG_FLASH_ENCRYPTION_ENABLED=y
CONFIG_FLASH_ENCRYPTION_INSECURE=

Enable secure boot and encryption on via esptool

flash signed and encrypted bins then OTA the signed bins. which will do OTA write and encrypt bins while writing via OTA.

Yes, as mentioned this should work.

I am still curious why you don't want to use the recommended workflow, though - the workflow you describe will probably take longer in the factory (more espefuse.py & esptool.py invocations) for the same result, and if you forget to burn one of the security-related efuses manually then you can end up with an insecure system.

Hi Angus,

Thanks for your reply. It is all clear now.


We will use known keys that is pre-generated.

We will enable encryption and signing via esptool and will flash signed encrypted binaries.

In this case CONFIG_FLASH_ENCRYPTION_ENABLED=y is not necessary. but secure boot still need be on by menuconfig as I understood.

#
# Security features
#
CONFIG_SECURE_SIGNED_ON_BOOT=y
CONFIG_SECURE_SIGNED_ON_UPDATE=y
CONFIG_SECURE_SIGNED_APPS=y
CONFIG_SECURE_BOOT_ENABLED=y
CONFIG_SECURE_BOOTLOADER_ONE_TIME_FLASH=y
CONFIG_SECURE_BOOTLOADER_REFLASHABLE=
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES=
CONFIG_SECURE_BOOT_VERIFICATION_KEY="signature_verification_key.bin"
CONFIG_SECURE_BOOT_INSECURE=
CONFIG_FLASH_ENCRYPTION_ENABLED=y
CONFIG_FLASH_ENCRYPTION_INSECURE=

This workflow I describe will take longer in the factory (more espefuse.py & esptool.py invocations) using pre-generated keys.
but more control for us.


Thanks,
Naeem

This workflow I describe will take longer in the factory (more espefuse.py & esptool.py invocations) using pre-generated keys.
but more control for us.

I see. The process you describe will work.

Just to make sure I understand, did you consider burning the pre-generated keys with espefuse burn_key, and then flashing plaintext binaries with esptool after that?

This workflow I describe will take longer in the factory (more espefuse.py & esptool.py invocations) using pre-generated keys.
but more control for us.

I see. The process you describe will work.

Just to make sure I understand, did you consider burning the pre-generated keys with espefuse burn_key, and then flashing plaintext binaries with esptool after that?

My process is make menuconfig with these settings.

1-
#
# Security features
#
CONFIG_SECURE_SIGNED_ON_BOOT=y
CONFIG_SECURE_SIGNED_ON_UPDATE=y
CONFIG_SECURE_SIGNED_APPS=y
CONFIG_SECURE_BOOT_ENABLED=y
CONFIG_SECURE_BOOTLOADER_ONE_TIME_FLASH=y
CONFIG_SECURE_BOOTLOADER_REFLASHABLE=
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES=
CONFIG_SECURE_BOOT_VERIFICATION_KEY="signature_verification_key.bin"
CONFIG_SECURE_BOOT_INSECURE=
CONFIG_FLASH_ENCRYPTION_ENABLED=y
CONFIG_FLASH_ENCRYPTION_INSECURE=
2-
Enable secure boot and encryption with espefuse.
3-

burning the pre-generated keys with espefuse burn_key.
4-
Generate encrypted signed bins via esptool.
5-
Flash signed and encrypted bins via esptool.
6.

Use signed bin for OTA.

I understand. And as I've already said, this process will work and it will be secure provided you also burn all the additional security-related efuses mentioned in the code I linked a few posts back.

We don't recommend this approach, for pregenerated keys we recommend you first do "espefuse.py burn_key ..." for both keys and then do "esptool.py write_flash ..." with plaintext, and then allow the bootloader to do everything else itself on first boot. This is the process best supported by the docs and the build system.

But your approach can still work if you're very careful.

Hi,

Question #1
As secure bootlaoder allow flash only once.
https://docs.espressif.com/projects/esp ... -boot.html


I wonder how it works for me. I use signed secure bootloader bin first which works. then later on I flash again encrypted signed bootloader after enable flash encryption which also works.

Question #2

Also I found It don't need to enable any secure boot and flash encryption via menuconfig.

Now my menuconfig is

#
# Security features
#
CONFIG_SECURE_SIGNED_APPS_NO_SECURE_BOOT=
CONFIG_SECURE_BOOT_ENABLED=
CONFIG_FLASH_ENCRYPTION_ENABLED=

I generated plain bin. we use esptool to generate encrypted singned bins. It all works.

Steps are:
1- signed and encrypted secure boot.
espsecure.py digest_secure_bootloader --keyfile secure_boot_key.bin --output ./build/secure_bootloader.bin ./build/bootloader/bootloader.bin
// ignore WARNING: Padding with 12 bytes of random data (encrypted data must be multiple of 16 bytes long)
espsecure.py encrypt_flash_data --keyfile encryption_key.bin --address 0x0 -o ./build/secure_bootloader-encrypted.bin ./build/secure_bootloader.bin

2-signed and encrypted partitions.bin

espsecure.py sign_data --keyfile signing_key.pem --output ./build/signed_partitions.bin ./build/partitions.bin
// ignore WARNING: Padding with 12 bytes of random data (encrypted data must be multiple of 16 bytes long)
espsecure.py encrypt_flash_data --keyfile flash_encryption_key.bin --address 0x8000 -o ./build/signed_partitions-encrypted.bin ./build/signed_partitions.bin

3-signed and encrypted bootsrap.

espsecure.py sign_data --keyfile signing_key.pem --output ./build/signed_W2K1-BootLoader-Release.bin ./build/W2K1-BootLoader-Release.bin
// ignore WARNING: Padding with 12 bytes of random data (encrypted data must be multiple of 16 bytes long)

espsecure.py encrypt_flash_data --keyfile encryption_key.bin --address 0x20000 -o ./build/signed_encrypted_W2K1-BootLoader.bin ./build/signed_W2K1-BootLoader-Release.bin



4- Enable secure bootloader

espefuse.py --port COM184 burn_key secure_boot secure_boot_key.bin
espefuse.py --port COM184 burn_efuse ABS_DONE_0 1

5- Enable encryption.

esptool/espefuse.py --port COM184 burn_key flash_encryption encryption_key.bin
esptool/espefuse.py --port COM184 burn_efuse FLASH_CRYPT_CONFIG 0xF
esptool/espefuse.py --port COM184 burn_efuse FLASH_CRYPT_CNT


6-

esptool.py --port COM184 --baud 921600 write_flash 0x0000 ./build/secure_bootloader-encrypted.bin

esptool.py --port COM184 --baud 921600 write_flash 0x8000 ./build/signed_partitions-encrypted.bin

esptool.py --port COM184 --baud 921600 write_flash 0x20000 ./build/signed_encrypted_W2K1-BootLoader.bin



This method better for us. for developer keep working with unsigned and not encrypted bin via build system make with board where no secure boot and flash encryption are disabled on efuse. Only our production process needs to do signed and encryption which uses esptool to do job.



Thanks,
Naeem