is ACTIVE SLOT Header protected ??

[SPati.7]

From SBSFU examples, with default SECUSER memory setting except reading from OB registers, it is only protecting SBSFU area alone.

Are we need to protect SBSFU + ACT_SLOT HEADER (1024 Bytes for H7) area as well right ??

So what is your recommendation on protection of HEADER ??

[Fred]

It protects also the active slot header:

[Fred]

When this is called:

SFU_MPU_SysCall((uint32_t)SB_SYSCALL_LAUNCH_APP, SlotStartAdd[SlotNumber] + SFU_IMG_IMAGE_OFFSET);

Can you still access the active slot header ?

[SPati.7]

@Fred​  To launch the application, we are giving right address by passing SlotStartAdd[SlotNumber] + SFU_IMG_IMAGE_OFFSET. But question is on configuring the secure user memory protection.

From examples, i didn't see that we are applying secure user memory protection to ACT_SLOT Header part.

So, as you mentioned, we should protect ACT SLOT HEADER as well, while configuring through OB, right ??

[Fred]

Yes, the active slot header is a sensitive piece of information, it must be protected otherwise we cannot trust the authenticity and integrity checks.

So, from a design perspective, it is clear that it must be protected.

Now, when looking at the latest implementation, I think the size we protect is too short.

I'm trying to clarify it with my colleagues.

[Fred]

Reading the code, I have a doubt too...let me check further.

[Fred]

Ok, there is indeed a bug.

A change made for H7 devices with non-contiguous headers has been propagated erroneously to all H7 devices.

Will be better with:

#define SFU_SEC_MEM_AREA_ADDR_END ((uint32_t) (SlotHeaderAdd[SLOT_ACTIVE_1] + SFU_IMG_IMAGE_OFFSET - 1U))

in:

Firmware/Projects/NUCLEO-H753ZI/Applications/2_Images/2_Images_SBSFU/SBSFU/Target/sfu_low_level_security.h

Sorry for any inconvenience.

[SPati.7]

@Fred​  Thanks for your prompt replies.

I want to give appreciation for your help, we are getting, May i know the channel to do the same.

[Fred]

Hi,

sorry for the late reply, I was on holidays.

The crypto scheme is like this:

[SPati.7]

@Fred​  Thank you very much for reply.

By default is this is the signing mechanism we follow or Do we configure to SIGN alone metadata header with SHA256 of Metadata Header.??

Looks to me, we compute SHA256 of Firmware, add this TAG in metadata header and sign Metadata header from example. is this correct ??

[Rejane Durand]

Hello,

This is correct. This is the signing mechanism followed by the software.

Both tags are checked during the update: