Where to store BHK key and RHUK key in stm32u585 in order to use SBSFU or a custom secure bootloader?

[Aurelien1]

Hi, we have to use a secure bootloader for STM32U585.

I have reading documentation about SFI and SBSFU and I am confusing.

1)   

Is there

somewhere a porting of SBSFU on this device?

We want to use a custom secure

Bootloader that only check update inside external memory and flash it if security

check is ok.

I have written all the code to do it. But I don’t know where to store my RSA KEY. I want to use both RHUK and BHK.

2)   Where is the correct location to store BHK and RHUK key fir a correct security use?

If I am correct from my SBSFU reading, KEYs are just stored inside Internal Secure Flash (0x0C000000) and RDP is used to limit access to Flash from DEBUG port (SWD/JTAG).

3)   If yes why this key are not accessible to application? Is it because Application should not be executed in secure world?

Thanks to help me

[Jocelyn RICARD]

Hello @Aurelien​ ,

I'm sorry for late answer. I didn't see your post earlier.

1) We didn't port the X-CUBE-SBSFU on the STM32U5. One reason is that another secure bootloader was ported on CM33 platform with the TFM (https://www.trustedfirmware.org/projects/tf-m/)

The secure bootloader in this implementation is based on MCUboot (https://www.mcuboot.com/)

In the STM32Cube U5 you can find this secure boot here:

STM32Cube_FW_U5_V1.1.1\Projects\B-U585I-IOT02A\Applications\SBSFU\

A documentation is available:

AN5447: https://www.st.com/resource/en/application_note/an5447-overview-of-secure-boot-and-secure-firmware-update-solution-on-arm-trustzone-stm32-microcontrollers-stmicroelectronics.pdf

The RSA key you want to store should be a public key, so there is no need to encrypt it. You need to ensure it cannot be changed. Using the U5 HDP mechanism (in case you enable TrustZone) or Write protection + RDP2 is enough to protect it.

2) The RHUK is not accessible. It can be used, after a first derivation generating the DHUK, by the secure AES IP to encrypt your data.

The BHK is located in the first eight registers of the tamper register. This key has to be provisioned.

HUK and BHK can be used as input of SAES, individually or combined (with or operator).

These keys can be used directly to encrypt/decrypt some data, or indirectly to encrypt a random key that will be used to encrypt/decrypt your data. This second approach is called wrapping.

You have an example here;

STM32Cube_FW_U5_V1.1.1\Projects\B-U585I-IOT02A\Examples\CRYP\CRYP_SAES_WrapKey\

3) The public key used to authenticate your firmware is stored in flash near your bootloader and secured using hardware security mechanisms (HDP, WRP, RDP).

The RHUK is provisioned in ST secure factory and stored securely in the chip. Each STM32U5 has a different RHUK.

The BHK is in tamper registers and has to be provisioned by OEM. This key can be automatically erased if a tamper even is detected: the tamper configuration has to be setup.

I hope this clarifies a bit.

Best regards

Jocelyn

[Aurelien1]

Hi,

thanks for your answer.

4) i have also an AES Key to stored => I will write it in HDP are, but is there a better location to store it?

Should I have to encrypt it using RHUK before store it inside this area or does HDP/RDP protection is enought?

5) Does the BHK stored in tamper is still available after PowerOff chip (The Product will be Power-On/Power-Off at each use to preserve battery)?

6) Does it is possible to write a new key after Tamper erased (in maintenance)?

7) Can we use KMS on STM32U585 at OEM level (with new board never programmed) to allow him to write custom Bootloader ( write data in Secure Flash + Configure Flash to limit access) and custom data in HyperFlash (we have written code to read/write/erase in HyperRam using STM32Cube Programmer).

8) If 7) is yes how does it is possible to test it before buying some KMS credit?

Thanks for your return

[Jocelyn RICARD]

Hi @Aurelien​ ,

4) You have the choice.

Using HDP protection (it TZ is activated) is a good way to protect all the content of the bootloader.

So, AES key will also be protected.

For a higher level of protection, you can encrypt it using DHUK. But this requires some code to do it at first boot for instance. This encryption cannot be done when RDP level is still 0 because in this case the SAES will use a constant value instead of DHUK.

So, higher protection but involves more development.

5) The BHK does not survive to a power off. This feature is useful when you have a backup domain always powered (thanks to a battery).

6) Yes

7). 8) I don't understand the question. The KMS I know is a Key Management System provided with X-CUBE-SBSFU that has nothing to do with the STM32U5. Could you explain a bit more ?

Are you refering to SFI ?

Best regards

Jocelyn

[Aurelien1]

Thanks a lot for your return.

I mistake It's not KMS but HMS (smartcard)

Yes i refer to SFI.

I understand that HMS is used to send data to OEM (non secure world) => HMS allow OEM to write crypted data inside MCU

I thought i can use STM32 TrustedPackage to create a "secure" package ( with Flash Security configuration's bytes, Software,Bootloader and external binary (to put in external HyperFlash memory)) and OEM use HMS to write package.

[Jocelyn RICARD]

Hi @Aurelien​,

OK so it is still not HMS but HSM for Hardware Security Module :grinning_face:

The SFI process allows you to provide an encrypted image to the manufacturer.

I made a video some time ago on the principle here

The Key used to encrypt the image is stored inside the HSM. HSM is provided to manufacturer. It will allow the programming tool to send a specific "license" to the chip that will contain the encrypted key.

Key will be decrypted inside the STM32U5, and firmware will be decrypted thanks to this key, also inside STM32U5 and flashed.

You can refer to AN4992 for more details.

In order to test this process, you will need to buy a HSM with limited number of licenses like STM32HSM-V2AE.

A specific X-CUBE-SFI update is currently in preparation. It will provide examples for STM32U5.

Best regards

Jocelyn

[Aurelien1]

Arf, copy/paste is not a good way if first element is wrong ;-(

Thanks for your details and the video .

Just one more thing :

Does my custom Bootlader (executed from Secure Flash) can remove protection (RDP/HDP,...) in order to write in Secure Flash (to updta himsel, or update key or application) and then reactivate protection?

[Jocelyn RICARD]

Hello Aurelien,

You can update your bootloader even if it is located in secure flash, as long it is updating itself.

To be able to do this, if you are in RDP level 2, the bootloader should not be protected with write protection.

If you stay in RDP Level 1, you can remove WRP and add it again at the end of the update.

In any case you should have a very reliable update procedure!

If the bootloader update fails, your chip may not be able to boot anymore.

Best regards

Jocelyn

[Aurelien1]

Thanks for those explaination.

It's clear know.

have a good Day

[EGuar.1]

Good morning, How can i Erase the STM32HSM card? And re-program it with new license by STM32 TrustedPackageCrator?

[Jocelyn RICARD]

Hello @Enrico Guariento​ ,

Please create a dedicated topic when asking a question so that answer can be useful for others.

STM32HSM has 2 possible states: Open and provisioned.

As soon as you have provisioned your HSM with keys, personalization data and max number of license with the STM32TrustedPackageCreator, you cannot go back.

You can use it to generate expected number of licenses for SFI process.

Once all licenses are consumed, you can trash the HSM card. It cannot be used anymore.

Best regards

Jocelyn

[EGuar.1]

I make a simple example: I download 3 licenses in the SmartCard and I use them to download the SFI files into the microcontroller. Once the SmartCard is empty, can I load 3 more different licenses for a different firmware or I have to throw the smartcard and buy a new one? ThankYou very much for the answer

[EGuar.1]

ThankYou very much Jocelyn for Your support. You were very clear in the answer and You provided me a great help. Best Regards.