SBSFU KEY Revoke Mechanism is Possible ??

[SPati.7]

As per current SBSFU Key storage mechanism, we can store One Key per each SLOT wise, as we are going to use single slot, we can configure one Key in SBSFU.

Also, if you want to store more keys, we can use other slot keys as well like ECC_KEY2 and ECC_KEY3. Need some customization at SBSFU to utilise these for SLOT 1 firmware purpose. is my understanding correct ??

Then i have some following questions on KEY Revoke mechanism

• If i want to Revoke KEY1 and make use of another KEY2 in case of KEY1 compromise, is it possible to do this ??
• To achieve this, we need some common secured shared memory between SBSFU and Application, is it exist ??

We are thinking of solution in case of one KEY1 compromised, and we want to switch to alternate KEY2 for further verification of Firmware. So please suggest better solution to this ??

[Fred]

We do not provide examples for this (our keys management is provided by KMS).

But, yes, you can implement this kind of approach.

You need to define:

• who decides to revoke ?
• how do you make sure only a legitimate "user" can revoke a key ?
• then you probably need a secure service to perform this revocation

So, I think it is more than just a shared memory area, you need to define a strategy and privilege management to avoid that anybody can revoke a key.

[SPati.7]

@Fred​ Understood, we define the strategy. But as part of our design approach, we may need to communicate with SBSFU from application context. That's why i am asking any kind of secure storage solution we have, where SBSFU and User application can access. Preferrably no STSAFE. is there any another way exist ?? Please suggest.

[SPati.7]

@Fred​ Any solution for the above ??

[Fred]

It depends on your stm32.

Some series like the L4 have the Firewall IP. Thanks to this, we can offer runtime services at application level. So here you may have a secure service to revoke a key that the user application can call.

Some series like the H7 do not have this, here we do not offer secure runtime services to the user application. You may need to implement a solution where the application sets a flag for the SBSFU to process it at next reset.

Anyway, in both cases, the critical point remains the same : who is entitled to revoke a key ?

If "anybody" can call the secure service (directly or indicrectly), then the secure service is only useful against key leakage.

But, an attacker can still revoke keys, which can lead to a denial of service.

So, I think this point is even more important than the security mechanism to put in place to actually revoke.

Thanks & Regards,

Fred

[SPati.7]

@Fred​  then can we use Image Header to store some flag, as we are using IMAGE STATE HANDLING feature ?? We are storing image state in the header and we are reading the sate, based on this, we are proceeding further.

But i didn't see any read from application to this header ?? is it allowed ?? I assume yes, because this is not protected with help of Secure User Memory ??

Also, i want to see the Firmware validation status performed by SBSFU, while running application. What is the mechanism to read this status in Application ??

is again HEADER ??

[Fred]

I assume you are working with a product with Secure User Memory like the H7 ?

If so, the Active Firmware Header is protected by Secure User Memory.

We cannot let the user application access it, otherwise, we cannot trust the SBSFU checks (authenticity and integrity).

So, there is a RAM exchange area between the SBSFU and the UserApp:

/* Shared RAM for Image State Handling */

define exported symbol __ICFEDIT_SB_FWIMG_STATE_region_RAM_start__ = __ICFEDIT_SB_region_RAM_end__ + 1;

define exported symbol __ICFEDIT_SB_FWIMG_STATE_region_RAM_end__  = 0x2001FFFF;

See also: sfu_fwimg_state.h

The UserApp can update the requested state in this shared area, and a next reset, the SBSFU can apply the requested update in protected FLASH.

The assumption is that, because the user application is verified before being run, we can trust its update of this RAM shared area. SO, SBSFU applies the request, but only SBSFU updates the protected area so only an authorized change can be done (no way to attack the firmware header).

So, the risk is to tag a user application as valid because of an attack and not because of valid self-tests. But this requires that there is a bug in the UserApp self-tests that can be exploited by an attacker (because if self-tests failed, the UserApp is not supposed to go any further).

You may reuse a similar approach for your keys management.

Or you may implement it through a backup registers based communication between UserApp and SBSFU.

In any case, the actual revocation of the keys should be implemented in SBSFU and the UserApp should only be authorized to ask for a revocation. Even this possibility to make this request should be "protected" by privileges so that not any UserApp code can do it.

For instance (but up to you to chose how to do), you may very well decide that this shared area is protected by MPU and that only privileged code can update it.

[SPati.7]

@Fred​ Thank you very much for reply.

From SBSFU application examples for STM32H753, found that user application trying to access SE Callgate APIs to get Firmware state, is this only for example sake ??

In production software, SE Callgate APIs which is part of SBSFU is locked out once Application execution started. Then how this going to works ??

Also, is the existing application examples implemented MPU configuration for Shared RAM for Image status capture ??

[Fred]

With H7, the usage of the secure user memory prevents SBSFU from providing runtime secure services to the user application.

In the example, we demontsrate that such calls should fail:

 printf("If the Secure User Memory is enabled you should not be able to call a SE service and get stuck.\r\n\n");

 printf(" -- Calling FwInfo service.\r\n\n");

 printf("Press the RESET button to restart the device (or wait until IWDG expires if enabled).\r\n\n");

 /* Get FW info */

 se_retCode = SE_APP_GetActiveFwInfo(&se_Status, SlotNumber, &sl_FwInfo);

So, the only way to use SE servies is not to activate the secure user memory, but secure user memory must always be activated when leaving SBSFU.

I do not think we demonstrate the usage of MPU on user application side.

But, you can do the same as what we do in the SBSFU part.

You may even "instantiate" a minimalist Secure Engine in the user application.

Now, if you think this is overkill, you can also assume that the application is checked so should not revoke a key maliciously (but this means you trust your user application software).

As usual, it is a trade-off to find between the level of security you need and the complexity you are ready to implement. So, I recommend doing a security analysis and checking what you decide is needed for this aspect.

[Fred]

Hi,

I only want to draw your attention on 2 points:

1. Delegating the key revocation to SBSFU is not sufficient to consider it is secure : yes the revocation service will be protected by the Secure Engine. But the important question is also: who is entitled to revoke a key ? If anybody can trigger the service, then anybody can revoke a key (no privilege).

To achieve this, I indicate that you may need isolation in the application (but I agree this is not trivial).

2. SBSFU is immutable so you need to decide how you want to actually revoke the key (you cannot update it in FLASH if it is stored with SBSFU assets)

I do not know WolfBoot's implementation so I cannot comment this.

The only thing I can say is that our SBSFU is immutable and must always be the entry point of the system (which is frozen by RDP Level 2), so we cannot update it or relocate it somewhere else "dynamically".

[Fred]

The mechanism is indeed to split the system in 2 parts:

• one where you must be in privileged mode to run the code
• one where you run in unprivileged mode

Secure Engine is "only" a way to put in place this isolation with a unique entry point.

You can implement this without Secure Engine, right.

Please note that this means that you need your applicative code to run in unprivileged mode by default : this can be tricky too.

The principle is this one:

 

[Fred]

Again, this is not trivial.

My main point is really to insist on the complexity that a secure key revocation management might bring.

[SPati.7]

understood the importance of Key Revoke management @Fred​ . Thank you very much for your unconditional support. Thank You Very Much.

Will try this and come back to you if more queries :smiling_face_with_smiling_eyes: