unable to read efuse key block after writing

robbawebba
Posts: 4
Joined: Tue Nov 22, 2022 11:38 pm

unable to read efuse key block after writing

Postby robbawebba » Fri Dec 02, 2022 9:42 pm

Hello,

I am currently working on generating and storing a 256-bit key in eFuse key block 0. I am using the ESP32S3. My goal is to store a key in efuse with the upstream purpose (ESP_EFUSE_KEY_PURPOSE_HMAC_UP), use it for HMAC calculation, as well as read the key from eFuses when necessary.

Here is the approach I use to generate and program the key:
  • Fill a 32-byte buffer with random data with esp_fill_random
  • write this 32-byte key to efuse block KEY0 with HMAC UPSTREAM purpose, using esp_efuse_write_key
  • set key write disabled bit to prevent modifications using esp_efuse_set_key_dis_write
  • set key purpose write disabled bit to prevent modifications using esp_efuse_set_keypurpose_dis_write
All of this works well, for generating the key. However, I am unable to read back the key using esp_efuse_read_field_blob despite never setting the read disable bit. Reading from the efuse block returns all 0's, so the efuse block appears to be empty. I used the following code to view the status of this efuse block:

Code: Select all

    bool unused = esp_efuse_key_block_unused(SECRET_KEY_EFUSE_BLOCK);
    bool empty  = esp_efuse_block_is_empty(SECRET_KEY_EFUSE_BLOCK);
    esp_efuse_purpose_t purpose = esp_efuse_get_key_purpose(SECRET_KEY_EFUSE_BLOCK);
    bool wprot = esp_efuse_get_key_dis_write(SECRET_KEY_EFUSE_BLOCK);
    bool rprot = esp_efuse_get_key_dis_read(SECRET_KEY_EFUSE_BLOCK);

    logw("unused:%d empty:%d purpose:%d wprotect:%d rprotect:%d", unused, empty, purpose, wprot, rprot);
Running this code produced this log message:
unused:0 empty:1 purpose:8 wprotect:1 rprotect:1
So somehow the read protection bit is being set. Do you know why the read protection bit is set when writing a key? Is there any way to avoid disabling user read functionality while enabling HMAC upstream mode?

I tested writing keys with these settings using the virtual efuse manager before using hardware efuses, and the virtual efuses behaved as expected. I was able to read keys after burning fuses. I would like to achieve this same result with hardware fuses if possible. Thanks in advance for your help!

ESP_Mahavir
Posts: 188
Joined: Wed Jan 24, 2018 6:51 am

Re: unable to read efuse key block after writing

Postby ESP_Mahavir » Mon Dec 05, 2022 3:09 am

Hello,

EFuse API ensures that appropriate read protection bits are set where it is not desirable for software to have access to the keys, this includes HMAC key too. Please see relevant code at: https://github.com/espressif/esp-idf/bl ... #L293-L294
Keeping the HMAC key (upstream mode) software readable is not recommended, this key should only be accessible to hardware and it can help you get HMAC-SHA256 for a given message entirely in the HMAC peripheral.

May I know what is your use-case here?

robbawebba
Posts: 4
Joined: Tue Nov 22, 2022 11:38 pm

Re: unable to read efuse key block after writing

Postby robbawebba » Tue Dec 06, 2022 9:06 pm

Hi Mahavir,

Thanks for the information and the link to the eFuse API implementation where reading is disabled when key purpose is HMAC_UP.

My use case involves both HMAC-SHA256 and AES-CBC encryption with the same key. Our plan is to have one pre-shared key per device which is generated during manufacturing and stored in a database for future HMAC calculations and encryption when authenticating with our cloud services. Only the device and cloud services will know the pre-shared key, so this key will be used to verify the authenticity of messages and encrypt some other data.

I would like to use the AES accelerator peripheral of the ESP32S3, but this peripheral cannot access keys from efuses directly like the HMAC accelerator. So in order to use AES peripheral, the key must be readable by software. I understand that this is not recommended, and we were planning to use security features such as HW secure boot and other secure software design choices to limit the potential exposure of the pre-shared key.

Please let me know if you have any other design recommendations. I will most likely implement my own version of esp_efuse_write_key that does not disable reading the key from software.

Thank you for your help!

Who is online

Users browsing this forum: Bing [Bot] and 107 guests