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]

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:

[SPati.7]

@Fred​ We are thinking of some solution on Key Revoke mechanism as mentioned below.

X-CUBE-SBSFU has capability to store up to 3 Keys (Slot1,Slot2 and Slot3 Key).

So here is the check we want to perform in SBSFU itself.

Happy Path

• Verify downloaded firmware with Slot_KEY1 as first check, as we signed with KEY1, verification will be succeeded and install application.

KEY 1 Compromise Case

1. Firmware signed with KEY2 and downloaded.
2. SBSFU start verifying with KEY1, and it is failed. Then we can mark KEY 1 as Revoked, and we can store this information in ACT SLOT Header where it is persistent.
3. Now SBSFU start verifying with KEY 2, and it got succeeded, then install the application.

So, as per the above, we can keep Revoked Key information in ACT SLOT Header or some other location where we can mark that as WRP protected on FLASH.

For you, is this solution looks feasible enough?? or do you see any challenges in doing this at SBSFU level??

From my point of view, as we restricting logic to SBSFU itself, i felt is is better option.

[Fred]

The problem I see with this strategy is "what if" :)

1. I get access to the leaked key (because it has leaked): KEY1
2. I identify the object I want to attack and block its secure update channel (blocking the connections to your update server)
3. I forge a malicious firmware FWx and prepare it with KEY1
4. I install this malicious firmware FWx: it is accepted because the "update" to revoke KEY1 has been blocked so KEY1 is still valid
5. I have now control over your object

So, I think that relying on an update to revoke a key might be too weak ?

This being said, if the REVOKE command is blocked too then it is the same result.

It is just that the REVOKE command may be less easily identified as it can be sent on the "standard channel" instead of the update channel maybe ?

[SPati.7]

@Fred​ what is the object you are referring ??

Also, how can we block connections to update server, as SBSFU Key only compromised, not Secure Communication Key. Still Secure Communication is in place.

To place forge firmware, it has to break Secure Communication as well.

Then, if in case of another solution where Application can initiate Revoke mechanism, still i see same weakness, in case of Forge firmware installed.

[Fred]

I am referring to the IoT device.

If your connected object is communicating over WiFi, probably via a gateway, an attacker might identify your exchanges with the update server (knowing it by the IP @ for instance) and block them with a radio jammer or by controlling the gateway.

I guess it is not trivial but hackers are very imaginative.

Such attacks can be made without breaking your device or the secure communications.

But, you may decide that such attacks are out of scope for your use-case.

Up to you do determine what you need.

[SPati.7]

@Fred​  Thanks for reply.

Anyway our device is not communicating with Gateway. It is local device, and it is communicating on UART with some other device over wired, which has connection to gateway over wired network.

Then, i believe it is not easy to break this.

So, do you see any other weakness, for the solution i proposed above ?? is it feasible enough ??

[SPati.7]

@Fred​  Can you look at above proposal and share your view ??

It's look like, too much complexity coming with enabling secure engine in application.

So, we go by above proposal, where SBSFU it self, can verify the firmware with signatures and detect which one is Valid Key or not.

But only concern here is, where we need to store this information ?? not in SBSFU as immutable.

(OR)

Separate Flash location, with what kind of protection ??

Also, i have one more query on storage of IMAGE_STATE_HANDLING in RAM. AFter status updated by application and go for RESET to execute SBSFU, this RAM area is going to disappear right ?? then how it si possible to read the status ??

[SPati.7]

@Fred​ Can you please try to answer below ??

[Fred]

Hi,

there is a noinit RAM exchange area:

/* Exported types ------------------------------------------------------------*/

#if defined(ENABLE_IMAGE_STATE_HANDLING)

#if  defined(SFU_MPU_PROTECT_ENABLE) || defined(SFU_SECURE_USER_PROTECT_ENABLE)

/**

  * Firmware Image State definitions : information saved in non-initialized RAM shared memory

  * ==> SB_FWIMG_STATE_REGION_RAM_START

  */

#define FWIMG_STATE_TAG_INVALID   0x0035049fU /* image is not valid (typically selftest has failed) and should not boot */

#define FWIMG_STATE_TAG_VALID     0x003574e4U /* image is valid (selftest passed), image OK to boot if signature checks pass */

#define FWIMG_STATE_TAG_VALID_ALL 0x003654aaU /* master image is valid (selftest passed), all other images are automatically validated */

#define FWIMG_STATE_TAG_SELFTEST  0x0036c702U /* self tests to be executed. Image OK to boot one time if signature checks pass */

#define FWIMG_STATE_TAG_NEW       0x00375ff5U /* new image, has never run on the device */

#define FWIMG_STATE          ((uint32_t *)SB_FWIMG_STATE_REGION_RAM_START)

#endif /* SFU_***_PROTECT_ENABLE */

#endif /* ENABLE_IMAGE_STATE_HANDLING */

So the principle is to define a RAM region that you do not initialize at startup.

Hence, as long as there is no power down, the data stored in RAM is available for SBSFU after a reset triggered by the application.

Of course this is only RAM and the content is lost if there is an electrical power down.