SBSFU - Changing the default AES_CBC and ECDSA keys always fails...STM32F407

[Zaher]

Hello everyone,

I've spent a considerable amount of time trying to change the default AES and ECDSA (ECCKEY1) keys, but I can't figure out why it always results in a 'Fw header authentication error' during the firmware image update process.

The project is built with STM32CubeIDE under Windows, all paths and necessary modifications needed for the scripts to work from the new project location (prebuild, postbuild, and the encryption scripts) are done and I can confirm 'se_key.s' is updated with the same data as in 'OEM_KEY_COMPANY1'. SeCoreBin compiles without any issues, the same also applies to SBSFU and the UserApp project.

I followed the instructions found here:
\Middlewares\ST\STM32_Secure_Engine\Utilities\KeysAndImages\readme
and looks like the prepareimage.exe works and generates the 'ECCKEY1', which also when used instead of the one that comes delivered with the package causes the firmware to be rejected immediately. 

Changing the AES key either manually using a Hex Editor or by using 'prepareimage.exe keygen -k OEM_KEY_COMPANY1_key_AES_CBC.bin -t aes-cbc' didn't work either. Just like if the AES and ECCKEY values are already hard-coded somehow into the binary so any change to any of these keys would result in the failure to authenticate the firmware. And by the way, what is the purpose of the 'iv.bin' file and is there any connection between this file and a new value in 'OEM_KEY_COMPANY1_key_AES_CBC.bin' or 'ECCKEY1'?

The cryptographic scheme used is: 'SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256'
SBSFU version: 2.6.2

Thanks

[Zaher]

*** UPDATE ***
I believe I have found a solution, or more likely a workaround for this. I will try to share details later in case someone is facing the same issue in firmware authentication after changing the default keys. It all had to do with the script/s.

[Bubbles]

Hello @Zaher ,

please share your workaround. There are other community members porting SBSFU to the STM32F4.

BR,

J

[starmour]

I have started working on sbsfu and came across this post. 

What I found out is that you must CLEAN and build all 3 projects after you make any major changes like changing the keys. Hope that will help others that come against same issue.

[Zaher]

Hello @Bubbles ,

First of all, I'm so sorry, it took me a while to get back, but I just noticed the notification about new posts here.
Well, like I said earlier in the OP, the whole issue had to do with scripts and the paths. I noticed that the issue is more likely found in the OSC variant. The quick workaround to this is to generate a secure engine binary (SEBin) inside the original demo package (no change for project locations/paths, etc). The pre-build scripts are invoked from IDE during the compilation of the SEBin and SBSFU, also the updated post-build must be manually copied to your new project's location, along with the keys. Of course, given that you already configured all paths for the scripts for your new project.

I've been working on a modified and improved version of the SBSFU for my own products since it's been released and now I almost can't trace back changes done over the years, but as far as keys are concerned, generating them within the original location is one solution.

Another possible solution is to move the entire project (SECoreBin, SBSFU, and UserApp) to Linux and modify all scripts. This step has a lot of advantages, at least for me, but it's a work in progress at the moment!

Zaher