Secure Boot V2 and Certificate Update (IDFGH-12866)

[diplfranzhoepfinger]

Answers checklist.

• [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Hello,

ESP32-S3, https://docs.espressif.com/projects/esp-idf/en/v5.2.1/esp32s3/security/secure-boot-v2.html

if the Customer wants Time-Limited Root Certificates, how can this be combined with Secure Boot V2 ?

so after 12 years, if the Root Certificate is no more Valid, is there a secure way to update the Certificate and also accept then the newly signed OTA Updates ?

Thanks, Franz

[SolidStateLEDLighting]

The way that I understand it -- secure boot is independent from OTA.

Secure boot is a relationship between a secret burned into a fuses, and signature that is attached to the end of an application where the hardware verifies that the application matches that encoded information burned into the fuses.

An OTA has other credentials which are stored in NVS. Those credentials provide the mechanism where the system can call into a IOT service, authenticate, and get what it needs. Commonly, a software package will have a mechanism to fleet provision its credentials. If something expires, its fleet provisioning process should be able to restart and re-authenticate automatically.

Secure boot (to my knowledge) just never changes. AND you have the option if applying 3 signatures so that the developer can rotate through those 3 signatures should an attacker find a way to copy one of those signatures and build software that runs on your hardware. Once those 3 signatures have been rotated through, that hardware exhausts its ability to boot software. The secure boot process will not look externally for any authentication information.

[mahavirj]

@diplfranzhoepfinger

Need more information to better comment on your requirements here.

FWIW, Please take a look at this documentation section https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/security/security.html#managing-root-certificates for managing the root certificates on the device side. Please note that, this does not have any direct co-relation with secure boot scheme.

[metala]

What if the requirements impose that the SW signing keys needs to be rotated every X years? The limited number of secure boot digests and revocation bits in the eFuses are not enough.

The best solution to the requirement would be to have a PKI and X.509 certificates for the application signing.

What would be the solution for such requirements, where the application signing key (and certificate) needs to be updated that often? Secure Boot V2 and it's limited key slots doesn't seem to fit the requirement.

PS. It's not related to TLS.

Kind regards, Marin

[kayzen9]

What would be the solution for such requirements, where the application signing key (and certificate) needs to be updated that often? Secure Boot V2 and it's limited key slots doesn't seem to fit the requirement.

trust boot involves verified chain. Chip code verifying bootloader, bootloader verifying app. if the app signing key is leaked then all executable on device shud be updated. how you plan manage early boot software update? best option is to keep bootloader signed with multiple keys and use revocation. it is not practical to manage multiple signing keys, at-least to not my experience... ..for our product we found HSM are best option to take care of signing key.

[diplfranzhoepfinger]

HSM you mean an external one or what we have in ESP32-S3 ?

[metala]

@kayzen9 Of course, there should always be a verified chain from the trust anchor to the app. The simplest solution might be to have a hardcoded HSM key that can sign the SSBL and the Root CA certificate (and if present, the CRL). Then the SSBL would verify the X.509 chain and at the end the application image signature.

Regarding the early boot software update, since SSBL does not support OTA update, it should hardly ever happen. If it does, then the HSM key would be used to sign a new version of SSB. The verification of the SSBL is done through the standard Secure Boot V2. The revocation capability of the eFuses is concerning. I'd try to avoid it if possible, since it's irreversible.

[mahavirj]

@diplfranzhoepfinger @metala

Sorry for slow turnaround on this topic.

Storing signing key on the device is not a recommended approach. Probably @kayzen9 meant using external HSM (either physical or cloud) for storing the signing key. Please see few technical posts on this topic [1], [2].

What if the requirements impose that the SW signing keys needs to be rotated every X years? The limited number of secure boot digests and revocation bits in the eFuses are not enough.

I have not come across such a requirement. Could you please elaborate if its any certification specific requirement?

Our recommendation is to store the private keys in secure manner (e.g., FIPS 140-2 level3 compliant storage) and worst case there is a provision for fallback using revocation scheme on the device side. So-far in our experience, the 3 digest slots have been sufficient for most of the customers. We can consider any improvements based on your feedback.

Hope this helps!

[metala]

@mahavirj

This is also what I mean. An external HSM accessed through PCKS11/Cryptoki and used for signing the SSBL and a X.509 Root CA that is part of the Application Image. The SSBL is verified using the Secure Boot V2 scheme and the PKI chain for the application is verified using the HSM public key from the SSBL signature block or hardcoded as part of the SSBL.

The Secure Boot V2 mechanism should guarantee the authenticity of the HSM public key.

[diplfranzhoepfinger]

OK, an external HSM, like:

• Infineon: OPTIGA™ Trust X, there ist a devkit with ESP32 and SW Samples
• ATECC608A like used in the Modules ESP32-WROOM-32SE

but not the HMAC or so which comes with the ESP32-S3 ?

right ?

[diplfranzhoepfinger]

https://blog.espressif.com/secure-signing-using-external-hsm-ebe855a2f2ef

[diplfranzhoepfinger]

https://blog.espressif.com/esp32-s2-security-improvements-5e5453f98590

[mahavirj]

The SSBL is verified using the Secure Boot V2 scheme and the PKI chain for the application is verified using the HSM public key from the SSBL signature block or hardcoded as part of the SSBL.

This should be possible by modifying the way 2nd stage bootloader verifies the application. It is possible to customize the 2nd stage bootloader, just that there is maximum size cap with secure boot enabled case.

OK, an external HSM

Yes, ideally it should be FIPS 140-2 level3 (reference) compliant.

but not the HMAC or so which comes with the ESP32-S3 ?

It is strongly recommended to store the signing key outside of the device.

Hope this helps!