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 ??

[SPati.7]

@Fred​  Can you please answer the above ??

[Fred]

Ensuring that SBSFU is immutable is ensured by WRP.

Secure User memory is a temporal isolation, to make sure that once the boot process is completed then the user application cannot access it any more.

This is because we consider that a regional isolation with MPU is not sufficient to protect the SBSFU assets from the user application.

The consequence of this, is that there is no secure service at runtime (secure engine is "hidden/un-mapped" when jumping into the user application).

In the example we provide, we do not protect the RAM exchange region when the UserApp is running. Any user code can write in it.

What I wanted to say is that : either you consider that this is acceptable for your revocation handling, or you consider that only some specific user code should be allowed to write the revocation request.

In this latter case, you need a regional isolation between the code authorized to revoke, and the rest of the user code.

On H7, I think you can do this with MPU only.

So, to do this I see 2 options (but again, this is only thinking aloud based on what you shared, a real security analysis must be conducted):

1. You add an isolation in the user application : you can reuse Secure Engine to do so (but compile it in the user application). You would have 2 Secure Engine instantiation : 1 for SBSFU, 1 for the UserApp.
2. You can fine-tune the Secure User memory settings to hide only a part of the SBSFU secure engine. In this case, you do not need a second Secure Engine instance, but you need to segregate the SBSFU Secure Engine in 2 parts:
   1. part reserved to SBSFU, must be hidden by Secure User memory
   2. part available for UserApp (contains the call gate): not hidden when activating the Secure User Memory.

With this approach a small part of Secure Engine can be used by the UserApp but the assets are still protected by Secure User Memory (temporal isolation).

But, here also, this is something I share without any warranty. Up to you to decide if you want to try something like this, assess the impact, do the security analysis and finally decide what to do for your product.

Here, I am only sharing possible ways to investigate further.

[SPati.7]

@Fred​ from above whatever you said, looks like somewhat complex process, i think it is not easy to play with memory protections. Again including secure engine as part of application, and update the RAM shared location ?? this is to provide isolation ??

One more option, from wolfBoot, we see to revoke Keys, solution they are providing is reprogram SBSFU it self with help of RAM CODE only on emergency feature, as while downloading if power lost, device can be bricked.

is this better option to implement Key Revoke ??

from the above proposal, we can avoid storing more than one key along with SBSFU as well.

[SPati.7]

@Fred​  Can you please reply for above query

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

[SPati.7]

@Fred​  Thanks You very much for reply.

Can i try the Option 1 with existing SBSFU examples ??

[Fred]

Hi,

you mean instantiating Secure Engine in the User App ?

You can experiment, but this is not so easy.

You need to study how this has been implemented with SBSFU:

1. See in particular: sfu_mpu_isolation.c in SBSFU project
2. see low_level_security_isolation.c and MpuAreas[]

And you need a separate binary to instantiate Secure Engine (this is more an implementation choice but I think it clarifies the boundaries).

This is definitely not something you can do in a couple of hours unfortunately :(

[SPati.7]

@Fred​  low_level_security_isolation.c this file is not there, but low_level_security.c is available, is this one ??

Also to apply MPU configuration to application, why secure engine is needed ?? from SBSFU it is showing as part of SFU, not secure engine.

May be this too early question from me. if you apply MPU region, do we need to change mode (prvilige or UnPrivilige) of CPU during run time ??

[Fred]

My bad : the proper name is sfu_low_level_security.c

In fact you need three elements:

• one component to configure the MPU to set up the regions so that there is an isolation
• one "transition system" when you need to enter the isolated region running the trusted code
• the "trusted code" running in the enclave

But please note that this separates the "standard code" from "trusted code" and forces the "standard code" to go through a unique entry point to run the trusted code.

So, this brings only isolation, not access control.

I just want to make sure this is clear for you that the main point is to make sure that only authorized users can call the revocation service, so I assume you need to install a check in the entry point.

[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: