Associate III

Solved

Updating the uROT signature remotely in a production device

Forum|Forum|2 years ago
March 13, 2024
4 replies
4387 views

Here is my attempt at background as I understand it...

iROT is a ROM program in the STM32H563. It contains a P256 EC algorithm, and checks some section of FLASH that you define as a program for a signature, then jumps to it. The definition of the program and sig are stored Option Bytes. In my case, I would be asking iROT to check my secondary bootloader for authenticity, in STM32 terms, this becomes the uROT in some cases or OEMuROT in others (terrible naming). Level1 Secure iROT checks my Level2 Secure bootloader, my bootloader checks my Non-secure application. The signature format is confusing, and I think the tools are greatly lacking clarity, but I think I get the idea.

1. What if I change my bootloader in the field? I OTA download a new bootloader. My Non-Secure application stores the update to the secondary bootloader, confirms it's signature with my OTA process, decrypts. Now... My secondary bootloader will update itself on next boot - BUT - If my Level2 secondary bootloader does not ALSO update the Option Bytes iROT-used signature, it will update itself, then on next boot, iROT will refuse to jump to it. Can my application change these option bytes when the product state is TZ-CLOSED? Can I do this from a (Level2?) Secure area?

2. I think no, and this is why STM32H5 iROT has an "INSTALL" method. Where the "uROT" (my bootloader update) and a "DATA" file (the new signature iROT should use) is put somewhere on chip, then somehow iROT sees this, and will update the secondary bootloader / uROT itself in Level1 Secure, then check and jump to it. I am not sure how iROT knows to trigger this install practice. I can not find documentation on this.

Overall, all of the documentation on the root of trust system needs someone to come in and write a non-technical "Here is what we intended" overview.

This topic has been closed for replies.

Best answer by Jocelyn RICARD

Hello @MBC ,

First I'm not answering depending on the number of parts you buy. I just try to help on my spare time.

Secondly, STiROT is supposed to be used with 2 slots, and was certified in this configuration.

What happens if the magic is seen, but the details are wrong like signature? Is the memory left alone or erased? Does iROT continue to boot the next stage?

If you download a firmware with wrong signature it is just erased. Then secure boot checks current firmware in active slot and launches it if verification is OK. Now, as I said, I don't know about all possible cases. I would guess this is most probably erased if magic is seen and no valid firmware is present. This is easy to check.

Regarding your second point, even without knowing the implementation of STiROT, I would bet the HASH is stored in OBKL1. Reason why I say this is that OEMiROT is already doing this. So, you must go through STiROT installation procedure.

About jumping in non secure application from your secure second stage, the point is that with TrustZone you have 2 vector tables. One in secure and another one in secure. The usual way to work with TrustZone is to have your application running in non secure, and secure application implement secure services such as secure storage and crypto for instance. When calling a secure service you execute code in secure and you have specific Cortex-M33 registers for that (VTOR, stack pointer etc).

So, if you jump from your second stage to your non secure application you will keep the secure context of your second stage, and some faults go directly to secure.

The usual way to do is to create a secure application that configures the security and then jumps to non secure application. This secure application can be very small but could help while debugging.

It will allow you to use the RSS jump that closes HDPL2 when jumping in HDPL3 for your application also.

Last point about documentation, I agree this is not always consistent. This naming is very new. I'm sure this will improve!

Best regards

Jocelyn

Jocelyn RICARD

ST Employee

Hello @MBC,

Yes, the STiROT is responsible for updating your secondary loader.

When setting up STiROT you specify the location of a download slot for your secondary loader update file.

Application can write in this slot the received update and triggers a reset.

STiROT will detect the new firmware in this slot and will install it if signature is correct.

The documentation is located in the wiki.

You have some how-to related to STiROT here

Regarding naming:

STiROT means ST immutable Root Of Trust : This is ST code in system flash. A ROM secure boot in fact.

OEMuROT means OEM updatable Root Of Trust: Here OEM is responsible for the associated code. ST provides an example based on mcuboot but it has to be adapted to your needs.

Best regards

Jocelyn

MBCAuthor

Associate III

@Jocelyn RICARD

1. I can't seem to find where that "trigger" mechanism is for iROT to look for an install an update. Magic value at the download location? Is it OK if I co-exist this area with another download area, and put something there that is not uROT update? Would iROT be mad about this, or just assume it wasn't data for it and go along with checking/booting the existing uROT? I don't have the room for a bootloader download area AND an application download area, although if co-existence isn't possible, I could misalign the two by a sector, iROT would never see anything until it had to.

2. I would prefer handle this myself, update the bootloader and update the iROT signature manually. Is this not possible from a TZ-Closed Secure (L2 I think) area? My reason for doing this is my bootloader and application may be linked, that is may need to be programmed together sometimes. I am aware of an option where the uROT update can contain secure (bootloader) and non-secure (application?) code but I would only want the signature to check on the uROT / secure section, not include checking of the non-secure application. My guess is that I would have to do bootloader only if I only want to check the signature of the bootloader only. That is workable.

3. As to the naming... I get iROT naming and function in ROM. My issue is more uROT vs OEMuROT naming. They seem like the same thing to me. They would both be my Secondary Bootloader in this case. All of examples for OEMuROT are MCUBoot, but I would be using WolfBoot. As it were, I don't really get OEMiROT... unless we were talking using OTP or some strict write protect.

Thanks for your prompt reply already today.

Jocelyn RICARD

ST Employee

@MBC wrote:

@Jocelyn RICARD

1. I can't seem to find where that "trigger" mechanism is for iROT to look for an install an update. Magic value at the download location? Is it OK if I co-exist this area with another download area, and put something there that is not uROT update? Would iROT be mad about this, or just assume it wasn't data for it and go along with checking/booting the existing uROT? I don't have the room for a bootloader download area AND an application download area, although if co-existence isn't possible, I could misalign the two by a sector, iROT would never see anything until it had to.

=> The STiROT is based on mcuboot. So same mechanism is used to check presence of a new firmware.

It it checking a magic at first address of the slot. Now, if you need to reuse this slot for other purpose, you should first check that STiROT does not corrupt your data.

STiROT code is not public so I cannot tell 100% what will happen.

2. I would prefer handle this myself, update the bootloader and update the iROT signature manually. Is this not possible from a TZ-Closed Secure (L2 I think) area? My reason for doing this is my bootloader and application may be linked, that is may need to be programmed together sometimes. I am aware of an option where the uROT update can contain secure (bootloader) and non-secure (application?) code but I would only want the signature to check on the uROT / secure section, not include checking of the non-secure application. My guess is that I would have to do bootloader only if I only want to check the signature of the bootloader only. That is workable.

=> The STiROT configuration is static. The location and size of the image checked cannot be changed. If you need something more flexible you can use the OEMiROT but you will lose space in user flash for this.

Otherwise, you can have a setup where your secondary secureboot directly launches a non secure image. But in this case, the second stage becomes the secure application itself and may need to handle secure fault for instance. This could be a concern.

3. As to the naming... I get iROT naming and function in ROM. My issue is more uROT vs OEMuROT naming. They seem like the same thing to me. They would both be my Secondary Bootloader in this case. All of examples for OEMuROT are MCUBoot, but I would be using WolfBoot. As it were, I don't really get OEMiROT... unless we were talking using OTP or some strict write protect.

=> uROT is the principle of updatable loader. OEMuROT is the example we provide for this.

iROT means immutable Root Of Trust. STiROT is located in the ROM (actually system flash) of STM32H573. You also have a code example of OEMiROT also based on mcuboot that can be easily adapted to your need. Only drawback is that it consumes user flash space. Thanks to STM32H5 security mechanisms you can flash this first stage bootloader and make it ROM like, meaning you have no possible way to modify it once protections have been enabled. Protections involved here are:

* WRP: Write protection

* HDP : Hide protect : temporal isolation that hides the bootloader once jumped to application

* Boot lock to ensure first stage bootloader is launched after reset

All these make the first stage bootloader (OEMiROT) immutable and even invisible from the rest of the application.

I hope this answers your questions

Best regards

Jocelyn

MBCAuthor

Associate III

It it checking a magic at first address of the slot. Now, if you need to reuse this slot for other purpose, you should first check that STiROT does not corrupt your data.
STiROT code is not public so I cannot tell 100% what will happen.

@Jocelyn RICARD

Come on. That's not an answer anyone paying $200,000 per order on chips can accept. That's nonsense. I don't care if it's open source, but ST has to be up front about what the side effects will be.

If there is no magic number - that's a pretty clear scenario. Seems like it has to just check and boot user code.

If the magic is seen, and the details are correct, it seems like the install will take place. HideLevel1 Secure iROT will update the next state. The download images are deleted, signature updated, uROT code updated.

What happens if the magic is seen, but the details are wrong like signature? Is the memory left alone or erased? Does iROT continue to boot the next stage?

=> The STiROT configuration is static. The location and size of the image checked cannot be changed. If you need something more flexible you can use the OEMiROT but you will lose space in user flash for this.

Yes. That is what uROT is it seems. iROT is the ROM first stage, uROT is the Flash second stage. The HDPL2 second stage verifies and boots an insecure application also in flash. What I am asking is can the code running in HDPL2 and Secure access and change the SIGNATURE part of the Option Bytes? ST images show the signature is a HDPL2 item. I am aware it can not change the location and size, those would be L1 Secure things set before being TZ-CLOSED. If the SIGNATURE for my secondary bootloader can be changed BY my secondary bootloader, I can self-update from the bootloader, I do not need to involve ST iROT's download/install. If I can not change it, and this can only be done in L1, then I need to use ST's iROT download and install procedure. Which is of course placing FIRMWARE and (meta) DATA PACKAGE with magic values in download waiting for iROT ROM to install on next boot.

Otherwise, you can have a setup where your secondary secureboot directly launches a non secure image. But in this case, the second stage becomes the secure application itself and may need to handle secure fault for instance. This could be a concern.

I agree with the first part. Yes, according to iROT, my secondary bootloader is the "application" and it knows nothing of the real application in non-secure world. This is desirable, we're going for a chain here. Can you elaborate on what this means: second stage becomes the secure application itself and may need to handle secure fault for instance. This could be a concern." I think you are saying a secure violation would jump me from insecure application to a hard fault in the secure realm? I'm not sure about that, wouldn't my insecure application's vector table need an entry for that? I have a vector table for both of course, but VTOR is remapped on the jump (of course). Either way, I don't see this as much of an issue. The uROT/OEMuROT I'm putting in of course would have hooks for secure violation.

you can flash this first stage bootloader and make it ROM like

Got it! STiROT is immutable-actually. OEMiROT is immutable-like. I'll give you it is further on the spectrum of things that are a pain to change, but I stand by why I was confused. As to uROT. I see now that is a general term and OEMuROT examples are just MCUBoot as a second stage. Although it is confusing that sometimes ST diagrams show an arrow to uROT or an arrow to OEMuROT as if those are different things. That is close to what I'm doing. TZ Boot >> iROT >> OEMuROT >> NS Application.

Jocelyn RICARDBest answer