feat(esp_encrypted_img): adds support for ECIES HMAC seeds generation within the device @ boot sequence (IEC-309)

[g-380]

Is your feature request related to a problem?

Hello,

The current design assume that the device hmac key must be securely provisioned onto the device by burning it into an eFuse key block, before it is later used by compute_ecc_key_with_hmac(..) to get the private key ready for use.

To resolve the best secure path for the HMAC key not being exposed during injection, you may consider having the device generating the hmac key itself when bootstraping, after application has been verified (as an example)
Could be using IDF random librairies by enabling an entropy source for RNG, if RF subsystem is disabled ?

Thanks for your support

Describe the solution you'd like.

No response

Describe alternatives you've considered.

No response

Additional context.

No response

[Ashish285]

Hi @g-380,

Thank you for your thoughtful suggestion regarding generating the HMAC key on-device during bootstrapping.

While generating the HMAC key using on-device entropy sources (e.g., esp_random()) after firmware verification is technically feasible — especially with Secure Boot enabled to ensure code authenticity — it introduces a key architectural challenge for the OTA system.

The current pre-encrypted OTA design assumes that all devices share a common decryption key (or derive it in a deterministic and consistent way). This allows the OTA server to host a single encrypted firmware image that can be safely downloaded and decrypted by any device in the field.

If each device were to generate its own unique HMAC key (and thereby its own ECC private key), this would result in:

• A unique decryption key per device, requiring the OTA server to individually encrypt firmware for each device.
• A mechanism to register or transmit each device's public key back to the OTA infrastructure.
• Significantly increased complexity in OTA server operations, image generation, and device-key association.

Since Espressif typically does not manage the OTA servers in customer deployments, we have no reliable way to ensure such a per-device key management pipeline exists or can scale. Therefore, the pre-encrypted OTA design intentionally opts for a shared HMAC key, securely provisioned to the device (e.g., via eFuse) during manufacturing.

That said, we do recommend that:

• This shared key be stored in a non-readable eFuse block, and
• If needed, partition devices into security groups or batches, each with its own shared key, to improve isolation without sacrificing OTA scalability.

Your proposal is certainly valid in environments where per-device provisioning and OTA customization are feasible (e.g., enterprise deployments or secure provisioning factories). But for general-purpose and scalable OTA updates, a shared or group-shared key model remains the most practical balance between security and deployment efficiency.

Please let us know if you have any specific requirements or use case.

Thanks

[g-380]

Hi @Ashish285 , thanks a lot for all you comments which I agree with.

In my case, we are in valid environments where per-device provisioning and OTA customization are feasible , that's why I was asking about best practice to have TRNG running fine for HMAC seed generation to be burned in efuse by the device.

Then, I will do what is neccessary to get the public key and make DeviceId / Public Key relationship stable .

thanks

[Ashish285]

Hi @g-380,

In order to use TRNG for HMAC seed generation when the RF subsystem is disabled, you can use SAR ADC based entropy source.

 bootloader_random_enable();
 esp_fill_random(<key_buf>, sizeof(<key_buf>));
 bootloader_random_disable();

For reference this is used by nvs and LWIP.

Let me know if you have any other questions.

Thanks

[g-380]

Hi @Ashish285 , thanks for your confirmation, this is exactly what I am currently using .
With best regards

[Ashish285]

Hi @g-380,

We will add the TRNG with SAR ADC based entropy source to the official documentation and also provide an API to extract the public key.

Let me know if you would like anything else to help support your use case.

Thanks

[Ashish285]

Hi @g-380 ,

We have introduced API to extract public key along with the documentation update with v2.5.0. I believe this will be enough for the per device unique key use case.

I am closing this issue, please feel free to try it out and create another issue if you encounter any problems.
Thanks

[g-380]

hi @Ashish285 .
I am wondering about piece of code to have the HMAC_KEY ready for ECC private key.
Wether entropy comes from HOST (esp_enc_img_gen.py / generate_hmac_key ) or from within CPU (compute_ecc_key_with_hmac) , it is the max we can expect (TRNG from ESP32, in case of device )
=> Then, calling esp_encrypted_img_pbkdf2_hmac_sha256 is overkill, isn't it ?
Thanks for your feedback.