OEMiROT for STM32H523 MCU

[hakeila]

Hi,

 

I am working on OEMiROT bootloader for STM32H523. I have copied big parts of the ST OEMiROT example project from H533 example as this is the closest MCU to H523 from the flash memory layout perspectives.

 

However, it is taking ridiculously too long time to refactor the security parts of the project as the H533 does have more hardware security peripherals than H523.

 

I have cloned the STM MCUBoot and the ST Mbedtls repos in my project.

 

I would love to know if there is an OEMiROT project example(s) for H523 and if you have any recommendation on how to process this faster as it has been taking forever to refactor and recompile the H533 example on H523 MCU.

 

Cheers,

Hani

[SirineST]

Hello, 

The STM32CubeH5 firmware package currently does not support the OEMiROT example on the STM32H523 device.

The OEMiROT example for the STM32H533 cannot be compiled on the STM32H523 device because the STM32H523 lacks support for the CRYP and PKA peripherals. For further assistance, please refer to the following wikis:

* OEMiROT OEMuROT for STM32H5:

https://wiki.st.com/stm32mcu/index.php?title=Security:OEMiROT_for_STM32H5&oldid=36098

* How to start with OEMiRoT on STM32H573 and 563–Arm® TrustZone® enabled:

https://wiki.st.com/stm32mcu/wiki/Security:How_to_start_with_OEMiRoT_on_STM32H573_and_563%E2%80%93TrustZone_enabled

 

[hakeila]

Hi @SirineST 

 

Thank you for your quick reply.

I am totally aware that there are differences in terms of peripherals between H533 and H523. And I am totally aware that the OEMiROT example can't be compiled on H523. 

 

What I need a recommendation from ST on how to implement OEMiROT on H523 without having to re-write the whole bootloader code. There must be something that can be done to avoid writing OEMiROT from scratch.

 

For example, Can I refactor the OEMiROT example for H503 to make it compliable on H523? However, the flash layouts on both are very different though but it uses HASH for encrypting/decrypting the OBK.

 

Alternatively, Can I use ST Cryptographic library to refactor the OBK part of the OEMiROT code in H533 to make it compliable with H523?

 

I am reaching out to ST on this matter because you guys should know better. I was hoping that you can help me more on this.

Also, I would like to mention that H523 does support PKA peripheral. There is an error on the STM32H523xx.h that suggested otherwise. I already contacted ST and they have an internal ticket for it.

 

Regards

[Jocelyn RICARD]

Hello @hakeila ,

The OEMiROT example for STM32H533 can be reused for STM32H523.

You only need to disable the usage of crypto HW accelerator by commenting 

#define BL2_HW_ACCEL_ENABLE

STM32Cube_FW_H5_V1.4.0\Projects\NUCLEO-H533RE\Applications\ROT\OEMiROT_Boot\Inc\mcuboot_config\mcuboot_config.h

Best regards

Jocelyn

[hakeila]

Hi @Jocelyn RICARD 

 

Thank you so much for your email and sorry for late response as I was away.

 

I managed to compile the OEMiROT successfully on H523 based on OEMiROT example from H533. 

 

I didn't disabled the CRYPTO accelerator though but rather I extracted the example project and replaced the crypto accelerator part using STM32CRYPTO library and kept the PKA and the HASH accelerators as the Accelerator peripherals are available on H523.

 

Kind Regards,

Hani

 

[Jocelyn RICARD]

Hello @hakeila ,

thank you for your feedback. This is very good idea indeed.

I created an internal ticket to ask for improving OEMiROT implementation to allow per IP selection.

Best regards

Jocelyn

[hakeila]

Hi @Jocelyn RICARD,

 

Thank you so much for your feedback. It would be awesome to have a practical example on H523 as well :).

 

I just have one question regarding OEMiROT on H523. Do I have to enable TrustZone (e.g. TZC = 0xB4) or I can still use OEMiROT with non-secure part? If so, Can I still use the STM32CRYPTO library even with non-secure OEMiRTO bootloader?

 

The reason for asking is that we are interested in using the OEMiROT bootloader strategy for firmware download/installation security as an OEM entity

[Jocelyn RICARD]

Hello @hakeila ,

The OEMiROT is designed to be used with TrustZone enabled.

It is possible to adapt it to run without TrustZone. There is an example for STM32H503. But H503 does not have obkeys feature to store the secure boot keys. So, it uses a flash sector to do it.

I'm sorry I don't understand your last sentence. Could you please explain and also why TrustZone is a problem ?

Best regards

Jocelyn

[hakeila]

Hi @Jocelyn RICARD 

 

Thank you so much for your quick response.

 

Thank you for the clarification on OEMiROT and TrustZone requirement.

 

I meant in my last sentence is that I thought that I won't be able to use TrustZone on H523 when developing OEMiROT as the H523 does have very limited Cryptographic hardware accelerators, and thus I will encounter complexity in decoding using the provisioned keys.

 

My first objective is to use the attached boot path for my OEMiROT especially our application consists of only none secure code.

 

But according to your explanation, it means that OEMiROT bootloader code is supposed to reside in 0x0C000000 where the dedicated secure flash memory resides where the non-secure application code is in 0x08000000. Am I right?

 

Cheers,

Hani

[Jocelyn RICARD]

Hello @hakeila ,

It is possible to have only secure application running. But you need to enable TrustZone anyway.

The addresses 0x08000000 and 0xC0000000 are pointing to the same physical flash address.

This address aliasing allows easier secure configurations.

 

Regarding your point : "I meant in my last sentence is that I thought that I won't be able to use TrustZone on H523 when developing OEMiROT as the H523 does have very limited Cryptographic hardware accelerators, and thus I will encounter complexity in decoding using the provisioned keys."

The STM32H523 had PKA signature verification and hash accelerators. They can be used in secure and non secure context. By default all peripherals are assigned to non secure so can be used either from secure or non secure. Better to assign them to secure though.

So, I don't see any issue here

Best regards

Jocelyn