ESP32 Forum

Hi,

Is there any way to use the BLK3 fuse bits to store part of our secret key, and protect these from read out using the espefuse.py tool with the protection bits but maintain the ability to read these from the code running on the esp32?

Looking to lock down using these bits for part of the key generation, but do not want to use nvs due to the risk of it being erased with upgrades etc. But naturally need to be able to read these from the code operating on the device.

Thanks,
Ralim

Hi Ralim,

I'm afraid not. The "read protection" in efuse applies to all reads via the memory bus (ie not using a hardware crypto peripheral), and espefuse.py and software running on the ESP32 read this data in the same way.

The recommended approach for storing this kind of secret is to enable flash encryption (including encrypting the app) and then store it encrypted in flash (or in NVS using the new NVS Encryption support). In the default configuration, flash encryption is disabled while running in the bootloader mode that espefuse.py & esptool.py use.

Angus

Hi Angus,

ESP_Angus wrote: I'm afraid not. The "read protection" in efuse applies to all reads via the memory bus (ie not using a hardware crypto peripheral), and espefuse.py and software running on the ESP32 read this data in the same way.
Angus

Can BLK3 be routed to a hardware crypto module by any chance? Can the other eFuse blocks that hardware crypto currently uses be used on user data rather than flash memory in the meantime?

ESP_Angus wrote: The recommended approach for storing this kind of secret is to enable flash encryption (including encrypting the app) and then store it encrypted in flash (or in NVS using the new NVS Encryption support). In the default configuration, flash encryption is disabled while running in the bootloader mode that espefuse.py & esptool.py use.
Angus

Our main concern with this approach is the chances of the nvs becoming erased during firmware changes, there doesnt seem to be documentation that I have found that specifies that it will not be erased or have issues long term after multiple writes (as its being actively used).

Encrypted flash sounds ideal, but not an option until tools support this and there is better documentation on these features. Would love to be able to use this, but currently not an option

Our main concern with this approach is the chances of the nvs becoming erased during firmware changes, there doesnt seem to be documentation that I have found that specifies that it will not be erased or have issues long term after multiple writes (as its being actively used).

One way to ensure that this data doesn't get erased is to have a one more NVS partition, and open it read only. For all settings which can change, use the main NVS partition. Use the read only one to read factory programmed settings.

See nvs_flash_init_partition and nvs_open_from_partition functions.

Encrypted flash sounds ideal, but not an option until tools support this and there is better documentation on these features. Would love to be able to use this, but currently not an option

Could you point us to the gaps you are seeing in the documentation and tools support? We'll try to improve it.

ESP_igrr wrote: Our main concern with this approach is the chances of the nvs becoming erased during firmware changes, there doesnt seem to be documentation that I have found that specifies that it will not be erased or have issues long term after multiple writes (as its being actively used).


One way to ensure that this data doesn't get erased is to have a one more NVS partition, and open it read only. For all settings which can change, use the main NVS partition. Use the read only one to read factory programmed settings.

See nvs_flash_init_partition and nvs_open_from_partition functions.

That's a very good idea, I'll look into this one further.

Can you confirm if there is any way to use any of the 3 keys to encrypt/decrypt user provided data (Not in flash) and have their security protection set ?

Encrypted flash sounds ideal, but not an option until tools support this and there is better documentation on these features. Would love to be able to use this, but currently not an option

Could you point us to the gaps you are seeing in the documentation and tools support? We'll try to improve it.

The biggest thing I find missing is absolutely no process examples for implementing this yourself, for when python is not an option.
You mention that AES is done backwards, but unlike most vendors there are no app notes / examples / implementation details that I can find? This is by far the biggest shortcoming I find with a large number of the documentation on the Read the Docs pages.
If it doesn't exist in the examples folder of the idf, there are no examples / implementation examples. Not saying that you have to make these, just that its one thing I notice in comparison to other vendors.

Also, your comment about the write protect preventing reads from all memory buses except for hardwired encryption peripherals isnt overly noted anywhere, or how these hardware connections are made ?

Another one is in the TRM, there is very little information on how to use the capture sub module for timing events etc. (Less than one page). This is not the only thing, but just one I came across today.


Still love the part though. Just find it hard with the documentation scattered everywhere.

Yes this has not been explained

key_status determines whether BLOCK3 is deployed for user purposes

Also how to use rom stub to write plaintext into encrypted flash when download_dis_encrypt is not enabled has not been shown.

The biggest thing I find missing is absolutely no process examples for implementing this yourself, for when python is not an option.

I think using python tools is not a requirement for flash encryption flow, you only need to write plaintext firmware into the ESP32, the bootloader will do the rest (generate the key, encrypt the partitions, program the key into efuse). Or does the use case require pre-generated keys?

Could anyone confirm if its possible to route the burned fuses to the encryption hardware and use this on user data ?

Need a method of encrypting data on the ESP and it would be ideal if this could be done independently to flash encryption settings etc.

For flash pre-generated keys are not required, but these are required for the data encryption, so it would be ideal to be able to burn these into BLK3 and then route this to the encryption hardware in the ESP32.

RalimTEk wrote: ↑

Wed Nov 21, 2018 6:06 am

Could anyone confirm if its possible to route the burned fuses to the encryption hardware and use this on user data ?

Need a method of encrypting data on the ESP and it would be ideal if this could be done independently to flash encryption settings etc.

For flash pre-generated keys are not required, but these are required for the data encryption, so it would be ideal to be able to burn these into BLK3 and then route this to the encryption hardware in the ESP32.

If you want the key to be read protected (ie only readable by hardware encryption not via software) then I'm afraid this is only possible when using the flash encryption engine.

If you are happy for the key to be software readable, you can have software read it from the BLK3 registers directly and then use it with the AES hardware accelerator. However in this case the key can be read by an attacker with physical access to the device (ie via espefuse.py).

If flash encryption is enabled then it's possible to store a key in flash using the flash encryption feature, which protects it against unauthorised access. I'm afraid this is the best option for protecting a key against an attacker with physical access, at this point.