Skip to main content
BEnge.1
Associate III
January 11, 2022
Solved

Firmware authenticity verification with ECDSA

  • January 11, 2022
  • 3 replies
  • 5935 views

Hello,

I am using the X-CUBE-SBSFU package with the KMS to perform firmware update on my ST MCU.

To verify the authenticity of the firmware I use ECDSA. However, I don't understand why I only need to provide a private key but not the public key. If I understood correctly the ECDSA should be used to sign the firmware update and this is done by the postbuild script but to verify the signature, the bootloader should be using a public key associated to the private key. However, the KMS only contains the private ECDSA key. Why do we verify the firmware with the private key and not with a public key ?

Kind regards,

Benjamin

Best answer by Jocelyn RICARD

Hello Benjamin,

you are right, the bootloader is using the public key associated to ECC private key provided as input.

The computation of the public key is done by the prebuild using prepareimage tool.

All the key setup process is somewhat hidden behind the usage of prebuild and postbuild.

Private key is used to sign the header of the firmware and public key is provided to SBSFU in se_key.x to check the signature at startup.

The public key is not in clear in se_key.s, but if you extract public key from your ECC key using openssl for instance you will find it out encoded in this file in SE_ReadKey_Pub section.

We made a video last year to support a security workshop that give many details about this.

Please refer to

https://www.youtube.com/playlist?list=PLnMKNibPkDnGd7J7fV7tr-4xIBwkNfD--

especially video number 3 about SBSFU presentation.

I hope this answers your question

Best regards

Jocelyn

3 replies

Jocelyn RICARD
Jocelyn RICARDBest answer
ST Employee
January 11, 2022

Hello Benjamin,

you are right, the bootloader is using the public key associated to ECC private key provided as input.

The computation of the public key is done by the prebuild using prepareimage tool.

All the key setup process is somewhat hidden behind the usage of prebuild and postbuild.

Private key is used to sign the header of the firmware and public key is provided to SBSFU in se_key.x to check the signature at startup.

The public key is not in clear in se_key.s, but if you extract public key from your ECC key using openssl for instance you will find it out encoded in this file in SE_ReadKey_Pub section.

We made a video last year to support a security workshop that give many details about this.

Please refer to

https://www.youtube.com/playlist?list=PLnMKNibPkDnGd7J7fV7tr-4xIBwkNfD--

especially video number 3 about SBSFU presentation.

I hope this answers your question

Best regards

Jocelyn

Rajan Soma
Graduate
May 24, 2024

Hi Joyce,

Any similar document for stm32h573 secure maanger? Highly appreciated for the same.

BEnge.1
BEnge.1Author
Associate III
January 13, 2022

Hello @Jocelyn RICARD​, thank you for your answer.

As I use the variant of the SBSFU with the Key Management System, the keys are not stored in the se_key.s but in the kms_platf_objects_config.h, right ? Indeed I can see SBSFU_ECDSA_1_Verify has the class CKO_PUBLIC_KEY so it is indeed the public key as you told me.

I have another question. If I want to store a private ECC key in the kms for my user application (this is out of the scope of sbsfu). How would you advice me to proceed (from key creation to signing something with the key in my user app), I don't find documentation explaining how to use the KMS from the user application.

Thanks in advance,

Benjamin

Jocelyn RICARD
ST Employee
January 13, 2022

Hello Benjamin,

Ok, so in the KMS example, we use a different way.to authenticate the firmware. We use a certificate chain.

The SBSFU will contain the ROOT_CA certificate as well as the OEM_CA : you can find them in the kms_platf_objects_config.h,file generated.

Then, the firmware header will contain the diversified OEM_CA and the firmware signing cert.

The verification will then consist in verifying the certificate chain.

For your second question, you have the KMS blob project that allows you to generate a blob containing your secret data encrypted and signed. You can then securely install it on your target using Ymodem transfer. This is actually using same mechanism as a firmware update except data is stored inside KMS.

Best regards

Jocelyn