2024-05-07 09:12 AM - edited 2024-05-07 10:14 AM
Hello,
We are developing a product based on a STM32WB5MMG. We have configured the SBSFU with OTA (Asymmetric with AES encryption scheme). Everything is working great and I have only one question that came to my mind during the last commit...
The CBC key for decrypting/encrypting the code is stored in the KMS of the CPU2. The SBSFU is supposed to read from there the key to decrypt new updates. So, why is the key also embedded in the binary of the SBSFU itself, in the se_key.s file? Basically, anyone who has access to the repository can have access to the encryption key (and in our case, being a team with more than one developer and with the potential to collaborate with external parties, this is undesirable). (I'm going to remove the se_key.s from the repo in the meantime). But most of all, what is the point of using the KMS if the SBSFU image itself contains the key?
I'm sure I've missed something and would be very grateful if someone could help me understand it.
Thank you and best regards.
Solved! Go to Solution.
2024-05-13 02:48 PM
Hello @thealbertdev ,
Thank you for raising this point. I think this is a mistake!
STM32WB is the only one chip that has this CKS to store symmetric key. And it looks like code used to generate this symmetric key inside SBSFU was not removed in this case.
One simple thing you can do is to remove the part generating SE_ReadKey_1 in the prebuild and you are done.
I will raise the point internally
Best regards
Jocelyn
2024-05-07 10:04 AM
I expect this:
But I see that prebuild.bat edits se_keys.s
(Using X-CUBE-SBSFU 2.6.2 and folder 2_Images from P-NUCLEO-WB55.Nucleo).
2024-05-07 10:10 AM - edited 2024-05-07 10:10 AM
More info from the README of 2_Images folder:
ETC
@par AES key provisioning
Before the first execution of SBSFU example, the symmetric key used for AES cryptographic functions should be
provisioned into the dedicated FUS Flash via STM32CubeProgrammer Command Line Interface (CLI) :
1. Access to Bootloa
ETC ETC
6. Revert Step 1 procedure to put back device in normal mode
For more details refer to the Application Note:
AN5185 - ST firmware upgrade services for STM32WB Series
UM2237 - STM32CubeProgrammer software description
@par IDE prebuild script
In order to ease the development process, a prebuild script ("prebuild.bat") is integrated in each IDE project.
This preliminary processing is in charge of:
- determining the requested cryptographic scheme
- generating the appropriate keys ("se_keys.s" file)
- generating the appropriate script to prepare the firmware image ("postbuild.bat") when building the UserApp project
ETC
2024-05-07 10:32 AM - edited 2024-05-07 10:48 AM
I see that SE_CRYPTO_AES_ReadKey uses SHCI_C2_FUS_LoadUsrKey in P-NUCLEO-WB55.Nucleo/Applications/2_Images/2_Images_SECoreBin/Src/se_crypto_bootloader.c. So, why is se_key.s edited and needed??
I have checked that is needed to access the public key of the asymmetric key. But is mandatory to contain the private key?
2024-05-07 10:55 AM - edited 2024-05-07 11:24 AM
From se_key.h.
/** @addtogroup SE_KEY_Exported_Functions
* @brief Functions SE_CoreBin can use to retrieve the keys.
* These functions are implemented in se_key.s
* @note Depending on the crypto scheme, @ref SE_ReadKey or @ref SE_ReadKey_Pub can be useless.
* Nevertheless, we do not use compiler switches as the linker will remove the unused function(s).
* @{
*/
/**
* @brief Function to retrieve the symmetric key.
* One specific key per FW image.
* @PAram pKey: pointer to an array of uint8_t with the appropriate size
* @retval void
*/
I assume the method to prevent the private encryption key from not appearing in the firmware image is through compiler optimizations...
I am not marking this as a solution pending if any ST employee can confirm.
2024-05-13 02:48 PM
Hello @thealbertdev ,
Thank you for raising this point. I think this is a mistake!
STM32WB is the only one chip that has this CKS to store symmetric key. And it looks like code used to generate this symmetric key inside SBSFU was not removed in this case.
One simple thing you can do is to remove the part generating SE_ReadKey_1 in the prebuild and you are done.
I will raise the point internally
Best regards
Jocelyn