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
Reading BLK3 from idf while protected
Reading BLK3 from idf while protected
--//--
Ralimtek.com
Ralimtek.com
Re: Reading BLK3 from idf while protected
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
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
Re: Reading BLK3 from idf while protected
Hi Angus,
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
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: 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
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).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
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
--//--
Ralimtek.com
Ralimtek.com
Re: Reading BLK3 from idf while protected
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.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).
See nvs_flash_init_partition and nvs_open_from_partition functions.
Could you point us to the gaps you are seeing in the documentation and tools support? We'll try to improve it.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
Re: Reading BLK3 from idf while protected
That's a very good idea, I'll look into this one further.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.
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 ?
The biggest thing I find missing is absolutely no process examples for implementing this yourself, for when python is not an option.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.
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.
--//--
Ralimtek.com
Ralimtek.com
Re: Reading BLK3 from idf while protected
Yes this has not been explained
Also how to use rom stub to write plaintext into encrypted flash when download_dis_encrypt is not enabled has not been shown.key_status determines whether BLOCK3 is deployed for user purposes
Re: Reading BLK3 from idf while protected
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?The biggest thing I find missing is absolutely no process examples for implementing this yourself, for when python is not an option.
Re: Reading BLK3 from idf while protected
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.
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.com
Ralimtek.com
Re: Reading BLK3 from idf while protected
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.RalimTEk wrote: ↑Wed Nov 21, 2018 6:06 amCould 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 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.
Who is online
Users browsing this forum: MicroController and 167 guests