2024-11-22 05:48 PM - edited 2024-11-22 05:51 PM
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
2024-11-24 03:48 PM
*** 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.