How can we achieve a Root of Trust feature for insecure 32-bit ARM microcontrollers?

[DPaul.3]

I'm trying to enable secure boot for general purpose ARM microcontrollers. Based on my research, secure boot starts with a Root of Trust (ROT). Usually this ROT is hardware based, which means that the microcontroller should have a dedicated immutable memory region that stores the very first code that runs after voltage is applied to a microcontroller. This region, also called the BOOT ROM is critical for secure boot as it is the basis on which all later stages of firmware are authenticated.

Now, most microcontrollers that I have implemented in projects earlier do not have this ROT which is why I'm looking to make things secure using a cryptographic module that will act as a secure storage for both the BOOT ROM code and any additional keys for encryption, signing, authentication, etc.

The ST33 TPM seems to be a good fit. The TPM 2.0 specification states that the TPM can be used for CRTM (Core Root of Trust Measurement) by which I assume that I can still keep my bootloader code in whatever microcontroller I have even if it does not have an immutable BOOT ROM and the CRTM will be able to detect if the bootloader has been tampered with. So the question boils down to -

1. The CRTM is code, so is it stored somewhere within the TPM and executed automatically at boot? Or should the CRTM itself be part of the immutable BOOT ROM code which again requires a separate immutable memory (in which case the TPM cannot execute any code, I'd assume)?
2. Is the TPM not a solution for this at all? If no, how can I implement an external module(s) to achieve a hardware ROT feature for existing microcontrollers without messing with its original functionality.

Even though ST Microcontrollers are my main focus, I want this solution to be microcontroller agnostic and would like to implement the same architecture in every past project that I've made. I'm having trouble understanding the CRTM and how the TPM can work as a hardware ROT (as mentioned in many places) because all TPMs are interfaced using some protocol like LPC, I2C or SPI, which would mean that these peripherals must be activated on the microcontroller first (bootloader code) which makes this an inherently confusing chicken and egg situation.

[Jocelyn RICARD · Accepted solution]

Hello Paul,

I explain how root of trust can be ensured in STM32 in this video :

Security Part6 - STM32 security ecosystem - 03 SBSFU presentation

In short, root of trust on general purpose STM32 micro-controllers in ensured in following way

1. Unique boot entry: you have a hardware mechanism that controls the code entry point after a reset. This unique boot entry is basically obtained thanks to RDP Level 2. On recent devices, this unique boot entry can also be obtained with specific option bytes settings.
2. The code executed after reset has to be immutable. In STM32 this immutability is obtained thanks to write protection setting in option bytes AND RDP Level 2 (This RDP Level 2 setting ensures that option bytes cannot be changed, so write protection cannot be removed)

With these 2 settings you get an immutable root of trust.

Then code executed, should be a secure boot able to authenticate the application firmware located in flash.

No secure element can ensure root of trust of STM32

I hope this answers your question

Best regards

Jocelyn

[AScha.3]

>I explain how root of trust can be ensured in STM32

and

>No secure element can ensure root of trust of STM32

makes

>I hope this answers your question

no.

[Pavel A.]

@AScha.3​ ??

The STM32 itself (user firmware) becomes the root of trust, so the "chicken and egg" problem with external secure element disappears.

[Jocelyn RICARD]

Hello @AScha.3​ ,

I'm sorry this does not answer the question.

Maybe this is just misunderstanding, but would need to have more feedback from you to be able to give more details.

From Pavel's answer, I feel I didn't give enough detail why secure element cannot ensure the root of trust. Main reason is that secure element does not have access to STM32's flash. So, it cannot check anything in STM32. Moreover, secure element cannot prevent STM32 from booting.

To have a root of trust through secure element we would need specific mechanisms to check STM32 before it can boot, which is not possible.

So, the only way is that root of trust is ensured by STM32 itself.

Best regards

Jocelyn

[AScha.3]

@Jocelyn RICARD​  Thanks, now i can understand ...

[Pavel A.]

> secure element cannot prevent STM32 from booting.

> So, the only way is that root of trust is ensured by STM32 itself.

Jocelyn, so your conclusion is exactly same as mine [excluding TZ-enabled products] ?

Thank you for detailed explanation.

[DPaul.3]

Thank you for the detailed explanation on how to achieve a root of trust on an STM32. I seemed to be getting fixated on using a secure element for the security of STM32. I feel the approach mentioned by you is foolproof and is the best way to go about it.

[MTS]

hi guys.... sorry to interfere with your smart topic, but I just want to understand what all this secure, trust and other nonsense is about. the only weak point or danger is a programmer who does not know how and does not understand what he is doing 100%. that is, the biggest danger is an incorrectly written code. if it is medical equipment, it can lead to tragedy. they should not be afraid of intruders from the outside, but of programmers who write code without understanding it.  and here is the most important thing! that all these things like ROT and such others only complicate programming, and therefore make the code dangerous. here is such a contradiction that should ensure safety, just gives rise to danger. all these games for the sake of security with address offsets, with random addresses, as in some systems, are useless, but they contain a complication of understanding on the part of the programmer and the possibility of making mistakes due to this nebula and not understanding. it is necessary to make everything easier, everything is simpler and more reliable. the simplest is the most reliable, and therefore the safest, because it is reliable and understandable and there is no room for errors and breakdowns. that's the only way.

[Jocelyn RICARD]

Hello Pavel,

STM32 TZ enabled products (CM33 based) have specific option bytes to get the unique boot entry without having to use RDP level 2.

Also, they implement temporal isolation (HDP) that allow isolation of secure boot from application once application is launched.

So, this is more flexible in term of configuration and testing.

Now, in the field, RDP Level 2 is the way to go to have a closed product.

Moreover, the STM32U5 has a keyed RDP that allows regression from RDP2 thanks to a key provisioned at production time. This provides a way to reopen the device without compromising its content.

Best regards

Jocelyn