2026-01-07 11:33 AM
I would like to implement a secure firmware update solution that will work in both an STM32G4A1 and an STM32U0 83. Different applications, but I would like to use the same basic bootloader and PC update application. Both would updated over USB. They have basically the same security features and both have the AES-GCM accelerators.
I've been watching the MOOC - Security series to learn how to do this. I got to the end of "Security Part4 - STM32 security in practice - 15 Secure firmware update" and had some questions since there isn't any lab video for this module like there are for the modules that came before it.
I've also looked at the Silicon Labs AN0060: Bootloader with AES Encryption app note, which is similar in implementation to what I am thinking of doing.
The link for the slides for the MOOK module is at the bottom of this page:
I'm trying to understand the scheme for the keys.
P.87
" Another option is to have the firmware encrypted with predefined symmetric key before uploading for update service
• Firmware will always be stored on the updating server in encrypted format and stays encrypted during downloading regardless of the communication channel encryption state
• The symmetric key to decrypt the firmware need to be provisioned in the device beforehand • The symmetric key need to be protected for its confidentiality and integrity "
Ok, in this scenario, I assume all devices/unit of the same product/part# would have the same symmetric key in a protected part of the flash and kept secret on the development side, correct? It would have to be the same key for all units if the update package is already sitting there waiting to be downloaded, yes? The diagrams in the "Secure FW update" section seem to use asymmetric keys, but that isn't what I want to do. I don't have have the resources to have a server that customizes an update package to each individual unit. I'm also wondering it the integrity and authentication aspects can also be done with symmetric keys?
The devices in question are relatively simple, but the firmware is a bit unique (some clever tricks in it) and that's what I'm trying to protect. I'm only trying to protect it to a level that someone in a home or small business electronics lab couldn't crack to get the firmware. There is no user data, financial information or anything like that being stored.