STM32H7 SBSFU Firmware Validation

[SebastianAdams]

Hi all,

I'm new to using the STM secure boot/secure firmware update and I'm trying to understand how the verification works when sending a new firmware image to the board. I got SBSFU running on an STM32H750B-DK dev board and successfully loaded the example UserApp program from the SBSFU extension package. I then tried to corrupt the firmware image file by flipping a single bit in a copy of the firmware file created with python script utilizing the shutil.copyfile() method, which from its documentation does not copy file metadata. From what I understand, when I try to load the corrupted image onto the board using Tera Term and selecting the "Download a new Fw image" option, after verifying the keys the SBSFU should verify the integrity of the new firmware image by checking both the header and the rest of the file compared to the current image. Is my understanding correct? Or does the SBSFU only verify the image signature?

This brings me to my issue. In some cases, the new corrupted image loads and runs without issues, even without the same metadata as the previous image and with a flipped bit, though in other cases the SBSFU properly rejects the corrupted image. This seems to have to do with the position of the flipped bit - if the bit is earlier in the file it is not rejected. I'd like to understand why it's not being rejected in certain cases. Is it because the SBSFU is able to handle such a small "corruption" in some cases? Are there areas of the firmware image that don't need to be validated and so there could be a flipped bit? Any help would be greatly appreciated.

[Jocelyn RICARD]

Hello @SebastianAdams ,

You provide both a header and signed encrypted binary for update.

The binary is aligned on interrupt vector constraint. So, you have some space between the end of the useful information inside header and the beginning of actual code.

Principle is to check first the header signature done on the hash of the header.

Then, inside header you have the hash of the binary that is is compared to the computed hash.

Best regards

Jocelyn

[SebastianAdams]

Hi @Jocelyn RICARD,

Interesting, that's about what I assumed since the check failed when I flipped bits at or past byte 1024. However, the corrupted firmware loads without issue even if I flip bits in byte 1, which I assume is part of the header. I tested a lot of other bytes less than 1024 and those loaded onto the board without issue as well.

I feel like I'm not quite understanding the structure of the header. Does the header contain more than just the hash of the header and the hash of the binary? And if I were to flip bits in those hashes within the header, then the SBSFU would reject it?

Thanks for your response,

Sebastian

[SebastianAdams]

Ok, we looked into it a bit more, and reading through UM2262 we expect that corrupting either the header tag or the firmware tag in the .sfb firmware image file by flipping a bit would result in the SBSFU rejecting that firmware, but that does not seem to be happening. Is our understanding correct?

[Jocelyn RICARD]

Hello @SebastianAdams ,

at this point you have to be a bit more specific otherwise I cannot answer.

Please provide which example you are using, which bit is corrupted, how do you check secure boot behaviour, and any information that would help reproducing a  possible issue. As you are just starting with it I would first suspect something not understood but an issue is always possible.

Regarding bit flipping, I would advise using a binary editor such as HxD to know exactly what your are doing.

You will also see immediately the structure of the header.

Best regards

Jocelyn

[SebastianAdams]

Hi @Jocelyn RICARD,

I'm using the example under Projects -> STM32H750B-DK -> Applications -> 2_Images_ExtFlash from the  stm32cube-expansion-sbsfu-v2.6.2 software archive available from your site. I'm also using Tera Term to connect to the STM32H750B-DK dev board and check the secure boot behavior by the outputs from the board there.

Taking another look at the output, I now think the board is properly rejecting the image with the corrupted header, but an error message specific to that case isn't being displayed. When I load a valid FW image, I get this message saying the new FW needs to be installed, and then it is swapped into the active slot:

However, when I try to load the image with the corrupted header (any single bit flipped before byte 1024), I get this message that does not contain any lines indicating the image is being installed or swapped:

It seems that in this second case, the SBSFU detects the corrupted header and rejects it, but does not output a message about the header being invalid. It then goes on to execute the existing valid FW in the active slot. Is my interpretation correct? And would you expect there to be a message about the header or no?

I expected there to be an error message about the header because when I corrupt the firmware image past the header (byte 1024) and try to load it I get a "Fw signature check error" message, and then the already loaded and valid program is executed:

[Jocelyn RICARD · Accepted solution]

Hello @SebastianAdams ,

Thank you for the details. Fortunately no big issue !

The best way to make sure your firmware is well updated is to change something visible and possibly firmware version.

As I described earlier, the first step is to check the signature of the header. Then if OK, check the hash of the firmware comparing with the hash provided in the header content.

Also, a version check is done. Lower versions are rejected.

It looks like a message is missing relative to the header signature checking failure. I will raise this point.

Now you understand how things work, a good exercise is to add this message :)

Best regards

Jocelyn