Issue with SFBU and EEPROM Firmware Update

[NAndreadakis]

Hello,

I'm currently working on a project that involves using the SFBU (Secure Firmware Bootloader Update) due to the limited flash size of the MCU. I've set up an external EEPROM to store the entire firmware before the update process.

I've made necessary modifications to the linker files to accommodate the use of EEPROM. The complete .bin file, containing all the data, successfully boots at SFBU, and after the checks, the main code runs seamlessly.

However, I'm facing an issue when attempting to update from the EEPROM. I encounter a "Fw signature check error" during this process. Upon debugging the BFU (Bootloader Firmware Update) application, I noticed that the C_DigestFinal function returns the wrong pOutputBuffer specifically when updating with a .sfb file. Interestingly, the same function returns the correct tag when we flash both the bootloaded and firmware as one image but still can't make upadate with .sfb file.

Below we see that the fw_tag_output is correct and the installed image pass the check

Now we see that the same application when i send the .sfb file over y-modem for update the kms returns the wrong number.

Both of the images tag are the same and in correct place. All the partitions have been checked and are the correct ones. The same application with the internal flash works ok.

Best regards,

Nikos

[kyf]

Hello there !

I am facing the same issue as @NAndreadakis  mentionσ above. I've stuck at the verification of the new FW file.

[Jocelyn RICARD]

Hello,

as said in other thread, to be able to understand what happens, you shoud

1) Check if encrypted files is well downloaded to the target

2) Check during decryption of the .sfb file first and last decrypted bytes to see if they match the original binary file.

Best regards

Jocelyn

[NAndreadakis]

Hello @Jocelyn RICARD ,

Thanks for the reply!

I have already check the full firmware that is download in the external memory. And is the correct without missing parts.

Also i check the decryption when is done by mcu and is the correct one also.

The authentication tag on both firmwares (full firmware .bin & Generated .sfb) is the same on the beginning section 0x200. 

The C_DigestFinal when is called shouldn't be always check with the same tag? What i mean is that the Authentication tag key with size 32 bytes on the first section of the flash is always the same? 

Below is the image from both header binary files. The tag values are the same.

Do i messing something about how the C_DigestFinal works?

The result using the full image BFU + Firmware:

The same during update from the y-modem:

Best regards,

Nikos

[Jocelyn RICARD]

Hello @NAndreadakis ,

Ok here the hash of the firmware is computed and compared to the hash provided in the header.

I assume you are in a dual slot setup where the sfb image was decrypted in the download slot.

Could you please check that decrypted image in download slot is correct?

Also, what did you change in the BFU project compared to the one provided in the CubeFW ?

Thank you

Best regards

Jocelyn

[NAndreadakis]

Hello, @Jocelyn RICARD 

I assume you are in a dual slot setup where the sfb image was decrypted in the download slot.

Yes i use the dual slot setup as the provided example, but modified to work with external eeprom.

The external eeprom is only used for the download slot.

Could you please check that decrypted image in download slot is correct?

Yes i have checked already that, and the decrypted firmware is the same.

Also, what did you change in the BFU project compared to the one provided in the CubeFW ?

What i have change:

1. Add all necessary functions of the external eeprom for reading and writing on file sfu_low_level_flash_ext.c.
2. Change the Memory Addresses on all files on linker_common to support the external eeprom.

When i revert the above modifications and the download slot is in internal flash the firmware .sfb is flashed normally.

Best regards,

Nikos 

[Jocelyn RICARD]

Hi Nikos,

Before checking the hash of the new firmware, SBSFU decrypts it in place.

This has different consequences:

First, in term of security, your code is rewritten in clear in external flash. This means an attacker could read the actual content of your firmware.

Secondly, this decryption in place, uses the SWAP sector that should a multiple of external flash erase size.

You talk about EEPROM though. If this is real EEPROM without need for erase you should adapt the code of SBSFU.

Other solution is to avoid swaping the download SLOT and active SLOT. This would make the solution more secure but with no way to rollback.

One first thing I would do, is add some code in SBSFU to really compare the content of the decrypted SLOT and the active SLOT (I assume you are using exact same binary for both).

Best regards

Jocelyn

[jmmunoz]

Hi @NAndreadakis , thanks for posting this issue!

I'm currently entering into the same project, I want to use an external Flash memory using SPI to download and update firmware to my stm32wle5 device. 

Would you be willing to share your modifications to the sfu_low_level_flash_ext and linker files? 

Thanks!

[NAndreadakis]

Hi @jmmunoz ,

Is not that simple sharing the modification on sfu_low_level_flash_ext and linked files. That is not going to help you. 

I ended up changing from the ground up the BFU boot sequence according to the project needs. 

What i did is:

• Modified the BFU_1_Slot example
• Extend the flash size of the BFU to fit the eeprom drivers 
• Add drivers to support the external SPI EEPROM.
• Add necessary functions to sfu_low_level_flash_ext  and handle the EEPROM read write process.
• Modified the the sfu_boot.c file to start checking the the external eeprom during boot for download new firmware.
• Modified system state machine on function SFU_BOOT_SM_CheckUserFwStatus, Add new state in file sfu_fsm_states.h, use that new state at function SFU_BOOT_SM_Run.
• Used the function SFU_IMG_DetectFW for detection of the download firmware in external eerom after the button (y-modem) check.
• Add swap space in flash 2KB in order to decrypt the firmware of the eeprom inside the chip for better protection.
• Add new functions on sfu_loader.c file to support the external eeprom
• After a successful boot, i erase the EEPROM with the encrypted image for safety.

The device can't have rollback system. If you need rollback you have to encrypt the internal firmware and hold the image to EEPROM before flash the new one firmware.

Now the device have about 192KB of space to work. The download firmware from the eeprom over SPI is fast and fair enough.

The overall process is very tedious and time consuming. I modified to many files and i completely renovate the firmware build process to work. Always double check if flash memory is written with correct offsets. Use a HEX editor to help you out with bin files encrypted and decrypted.

Hope that information is help you find your way. I took me about 2 weeks to understand and modify the BFU but the fist thing you have to focus is the function SFU_BOOT_SM_CheckUserFwStatus on sfu_boot.c. After that check the way the y-modem is flashing the firmware. This will guide you to understand what path to follow. 

Good luck.