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.

[SPati.7]

@Fred​ In our case, we should enable Secure User Memory, that's how we are projecting as SBSFU is immutable right ??

I confused with your statement

"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."

This means what, with Secure user memory activation, still we can access Secure Engine ??

Also, i see we didn't consider MPU protection for below region right ??

/* Shared RAM for Image State Handling */

#define SB_FWIMG_STATE_REGION_RAM_START  (SB_REGION_RAM_END + 1)

#define SB_FWIMG_STATE_REGION_RAM_END    0x2001FFFF

Can we activate this in our production build, if we are going to use this region for Key Revoke ??