Secure firmware update questions (after watching ST videos)

[KDesr.1]

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:

https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/STM32_security_in_practice.html

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.

[Jocelyn RICARD]

Hello @KDesr.1 ,

Please have a look to MOOC part 6 that explains the theory of secure boot especially regarding authentication and encryption.

You don't need to customize the update for each unit. (This is still possible but definitely not the common case)

We provide full secure boot examples for these devices but unfortunately this is not the same implementation.

For STM32G4 you can find an example in X-CUBE-SBSFU available on st.com with specific documentation, but for STM32U0 which is recent we provide so called OEMiROT example in the STM32U0Cube. Documentation is available in the wiki here

Best regards

Jocelyn

[KDesr.1]

Jocelyn,

Thank you for the reply, I will definitely look at part 6.  I've been re-watching part 4 to get my head wrapped around it better.

I'm glad to hear that the key does not need to be customized to each unit.  I've been reading a variety of sources and some are adamant that having the same symmetric key in all devices of a certain part# means it can easily be read by a hacker who had physical access to the device, even in protected flash.  This doesn't make sense to me as if they can read the protected part of the flash with the key, why would they not be able to read all of the protected flash and just reverse engineer the code?

Is it correct that the most common configuration for this kind of device and set-up is to have asymmetric keys for authentication and signature, but a symmetric key and something like AES-CGM to encode the firmware packet itself (as is shown in the block diagram on p.92 of the part 4 slide)?  In that slide the "FW Encryption Key" (AES 128) would be a common symmetric key, correct?

[KDesr.1]

The way I plan to do updates, is to create a binary package like on p.92 that they use can download, and have a very simple PC application in which they can select that file from wherever they downloaded it to and send it to the secure bootloader over USB to process.

[Jocelyn RICARD]

@KDesr.1 ,

If your enable flash protection (here RDP), your content is safe from JTAG attack.

If he manages to extract the symmetric key, then he will be able to decrypt an update binary.

Yes, for simple microcontroller based device, the usual configuration is to have an asymmetric public key (ECC more common or RSA) used to check your firmware's signature, and a symmetric key (AES) to decrypt your update.

The chaining mode of AES in such case is usually CBC or CTR but not GCM. GCM is an authenticated encryption more useful for communication.

Best regards

Jocelyn

[KDesr.1]

Jocelyn,

Thanks again for the reply!

Would using a second asymmetric set of keys for the update contents be a better option? 

[KDesr.1]

Jocelyn,

I watched MOOC part 6.  The first half is very informative.  The second half seems to only focus on the Cortex-M33. which was less useful for what I'm trying to do.  I would love to see more practical/lab content on the 12 security functions in 06 as applied to the other families.  My use case is pretty much exactly customer example 1/6 in that video.

I will read UM2262, but if there are any other applicable videos or material you can suggest, please point me to them.

[KDesr.1]

Ok, I've also read AN5056.  I think I know understand how I can make this work with my application and what I'm trying to do using SBSFU.

My device is battery powered with a single battery.  I only use the USB to do firmware update and to retrieve some user data (fixed size records) for debugging purposes.  The battery must be removed in order to plug in the USB, so detecting USB power tells the device to go into a file transfer mode on start-up (firmware update or record retrieval - host app tells it which to do).  I already have all of the functionality working in a un-secure bootloader that uses USB-CDC with my own file transfer protocol.  I don't think SBSFU allows for sending data from from the user data area back to the host, so my thought is the correct way to do this is to move all of this functionality to the application, use the dual slot update configuration, and have SBSFU just do the swap on the next boot-up.  Functions in the app that I want to protect could be put in a protected area of the flash that is execute only, that the app can access.  I can use the SBSFU tools to create the update package with encryption, authentication and signatures.

Does this make sense?  Is this the correct way to do this?