Using STM32's inbuilt bootloader for secure user-firmware updates - Page 1
Forum section: electronics / general

author: Psi
author_rank: Super Contributor
timestamp: November 22, 2015, 08:49:26 am
content: Hi,I'm trying to figure out how to use the SMT32 uart bootloader so users can update my product in the field.The issue is protecting the firmware transfer, since the bootloader doesn't look to support any encryption.Other than writing my own bootloader, what are the options?I could store a decrypt-and-write function at a specific address and make a point to not erase that area when doing user updates.I could then use the stm bootloader to load encrypted blocks into sram and then execute at that address to make the mcu decrypt and store to flash.Any better ideas?Chip is STM32F042K6STM32 Bootloader ANhttp://www.st.com/web/en/resource/technical/document/application_note/CD00264342.pdf

author: AndyC_772
author_rank: Super Contributor
timestamp: November 22, 2015, 08:55:56 am
content: Not sure about that particular device, but on the STM32 I've been working with recently, the bootloader won't work if you have read protection set in the option bytes.If you don't set read protection, then of course, anyone can read out your firmware through the JTAG or SWD ports.If your device is the same, then I don't see any option but to write your own bootloader - sorry.

author: Psi
author_rank: Super Contributor
timestamp: November 22, 2015, 09:22:24 am
content: Reading the datasheet i think you might be right.Well done TI, a bootloader that is totally useless.

author: dgtl
author_rank: Regular Contributor
timestamp: November 22, 2015, 07:21:16 pm
content: The ST's internal bootloader is only good for factory programming. Applications are so different and it would not make sense to have one generic updater for them all. Depending on the user interfaces and types of device, you shall implement the updater yourself. The best fit is different for every project. As this is needed for every project, you'll start to re-use the code from previous projects and so it will become much easier for every other project.Different approaches for different projects:* Application/bootloader split. Either the application uses some of its communication interfaces to receive an update and store it to another flash region, then bootloader copies it to real location or the bootloader has communication interface too. Sometimes, you can even run from RAM and do in-place update inside the application itself without bootloader at all (with possibility to brick the board).* Communication interface. USB device port (usb DFU, usb-serial etc)? USB host port (update via usb memory stick)? Ethernet (TFTP? Upload update file via web interface? Download from central server?) Can-bus? Native serial port?* Storage. Where to store the update package if it needs to be stored. If the board has external flash, it would be cheaper to have it there instead of doubling the uc internal flash size.* Composition of update package. Sometimes, there has to be additional data besides the uC fw. For example, FPGA bitstream. Graphics/fonts/data stored to external flash. You'll need to handle those as well to have one single update image.* Actions needed on update. Sometimes, configuration data has to be migrated. Sometimes, something else on board needs to be re-programmed, too...* Security. Encryption algorithm. Keys. Checksumming.Different vendors have application notes about bootloader design. Most of that can be easily used on whatever platform, you'll need to implement the flash access of your target system and the communication interface. If your application already has a communication interface, just add the update package upload functionality there. Then you need to implement the bootloader->application launch function and thats it. Change your application linker script to locate it at higher address above bootloader. For Cortex-M0 parts (without VTOR), you'll need to investigate vendor-specific interrupt table relocation possibilities, otherwise redirect VTOR and start the application.

author: gnif
author_rank: Unknown
timestamp: November 23, 2015, 12:05:08 am
content: Take a look at stm32flash, I wrote this many years ago so that UART flashing under linux was possible and reliable, since the project has been taken over by others and now supports most STM32 based devices under both *nix and windows.I would write a little loader that you upload via UART into RAM and execute, that then proceeds to accept your firmware, verify and decrypt, then write to flash.But if you are looking to make it secure, all your attacker has to do is connect to JTAG and dump the sucker out. I don't bother with UART anymore after moving to JTAG on these devices.

author: westfw
author_rank: Super Contributor
timestamp: November 23, 2015, 01:53:29 am
content: Quote1) ST, not TI.2) It's a BOOTLOADER, not a secure software update mechanism!

author: Psi
author_rank: Super Contributor
timestamp: November 23, 2015, 05:37:55 am
content: Quote from: gnif on November 23, 2015, 12:05:08 amCool you wrote that.I've been using it for a while.The problem with that approach is the code copied into ram would include the decrypt keys transfered in unencrypted form. (Or a way to decypt transfered in unencrypted form)STM32F0 doesn't have jtag

author: Psi
author_rank: Super Contributor
timestamp: November 23, 2015, 05:40:38 am
content: Quote from: westfw on November 23, 2015, 01:53:29 amOps sorry yes. STThere is no good reason to exclude some form of protection from the bootloader.It doesn't have to be payment gateway security level. Just needs to protect against someone being able to dump the firmware with a few keystrokes.I think most engineers know there's people in russia/china who will unlock pretty much any general purpose mcu for $1000 (excluding the super secure payment gateway chips)So absolute protection wouldn't be expected.

author: mikerj
author_rank: Super Contributor
timestamp: November 23, 2015, 01:03:50 pm
content: Quote from: Psi on November 23, 2015, 05:40:38 amYou seem to have missed the point that such protection DOES exist. If you set read protection level 2, then the bootloader will not execute irrespective of the Boot pin values. It can still be called from user code if required.The bootloader in the STM32 works perfectly well for the use for which it was designed. If you want a secure bootloader, then write one, it's really not difficult on the STM32.

author: bingo600
author_rank: Super Contributor
timestamp: November 23, 2015, 06:44:13 pm
content: Quote from: Psi on November 23, 2015, 05:37:55 amUse SWD (2-wire Arm "jtag")Chose either the original ST-Link V2 donglehttp://www.ebay.com/itm/251995070583Or the Clone (I have 2 of these)http://www.ebay.com/itm/311466266044I'm using them with OOCD (Open OCD) , for programming and debugging/Bingo