STM32F407 custom bootloader with encryption support

[razvan_lucaci]

Posted on March 11, 2015 at 17:24

Hello,

    I am trying to develop a product with STM32F407 processor that must be firmware upgradeable in the field. The problem that I am thinking of is that somebody could easily make the same hw design of the board like mine's, copy my code image and put it on his board and have a system identical with mine up and running. So how can I protect myself from this, while still having the option of firmware upgradeable implemented in my product, in order to be able to deliver new features and bug fixes?     The one solution that I am thinking of is the following:         - having a second stage bootloader burned in each STM32F4 that I deliver which:             - when in 'boot mode', receives over serial interface an encrypted application image and writes it into Flash as it is. The image is unique for each product, being encrypted with a key derived from the STM32F4 unique ID             - when in 'app mode', decrypts the application residing on flash using the key based on the processor unique ID and puts the decrypted image in the CCM (core coupled memory). Then it executes the application from the CCM          Pluses of this solution: the application image in clear resides only in CCM which makes the process of copying it a bit more difficult (in my opinion).     Minuses: I have to deliver one image per every product, because the image has to be encrypted with a key derived from each processor's unique ID.          Can you please point me eventually to other solutions to my problem, maybe some that don't need separate images for each system? It would be much easier for me to deliver one single image every time I need to release a new version of software, instead of compiling and delivering one image per every system I have in the field.     Also, can you please let me know if the solution I have in mind would work or maybe I missed something ?          Thank you

[Tesla DeLorean]

Posted on March 11, 2015 at 17:38

You can't run code out of the CCMRAM on the F4 designs. Use it for data/stacks/heap, put the code in SRAM

The trick with piracy/counterfeiting is to price your product so that copying it is uneconomic.

[razvan_lucaci]

Posted on March 12, 2015 at 08:33

Thank you for the answer, clive1

The value of the product I am trying to build stands in the software part, not in the hardware that I use for it. So it is the software that will say how much money my product worth. No matter how less I charge the software, I will never be able to compete with someone that gets it for free, by simply copying it from me. So I need a solution to protect myself from that. I have looked a bit on the application note for the serial bootloader in the system memory of the STM32F4 and I found that the command for reading data can access any valid memory location from Flash or Sram, so even with my above solution, someone could still use this bootloader's commands to copy the application image in clear from Sram. I am sure I'm not the first thinking about protecting my software from counterfeiting, so there should be some solutions already in place. Not sure if these can be achieved with a STM32F4 though. Any thoughts, ideas will be much appreciated. Thank you

[francescatodiego]

Posted on March 12, 2015 at 14:36

mogg what is your purpose? what is the life cycle of your product?

If you need to protect your software for security reasons (metering or handling money) I don't think is a good idea to be able to update the firmware by the user. If you want to protect your software because the market for your products is potentially huge you can be sure that someone will find a way sooner or later to make a similar one. If you want to protect your software because you've worked a lot and you have had some brilliant ideas. Well if it is not something you need to go to Mars I think not worth the effort to find a hard protection in addition to those that are normally used. II believe that your customers will appreciate your work and your service. Who copy the firmware will not be able to upgrade it or  follow the client they can only sell it at a discount .... until there is a problem. If you want to be certain that no one copy your firmware, enables maximum protection on the flash (the manual says that in this case even ST is not able to access the data) You can make a hw where you can easily replace the micro. Use a little separate board with mciro mounted on it. When You need to upgrade th firmware send the new micro as spare part. The old one remains ''a brick'' inaccessible to anyone. Some years ago I collaborated on a terminal to handle money payments To prevent anyone from reading the firmware or access to micro the programming pins were cut before mounting the programmed micro.

[razvan_lucaci]

Posted on March 12, 2015 at 16:01

Thank you very much for the reply, diego.

With regards to the reason I need to protect my software, it is not for security reasons (metering, money handling, etc). You pointed very well 2 aspects: the novelty of the idea I have in mind and the potentially big market for it. The idea with replacing the micro will not work, as the cost of shipping it will be too high compared with the actual value of the product. Plus that I intend to deliver new features quite often and it will be impossible for me to send a new programmed micro to all customers every time a new release is available. You said 'not worth the effort to find a hard protection in addition to those that are normally used.' What did you had in mind ? What are the protections that are normally used ? The one with cutting the programming pins sounds interesting, but I still need to be able to update the hw in the field. So what it crosses my mind right now is: - before soldering on the board, flash the micro with a custom bootloader with encryption support that waits for commands on a serial interface other than the ones used by bootloader in the system memory of STM32F4. While receiving the encrypted image (using a unique key for all products, not one per product), this bootloader decrypts it and puts it into Flash, in clear - cut the pins used by the bootloader in the system memory of STM32F4, because this bootloader allows access for host to read information in Flash or Ram - cut the JTAG pins This way it will be quite hard to read the information from Flash. And this way, I could deliver only one single encrypted image for all devices in the field. What do you think ?

[Tesla DeLorean]

Posted on March 12, 2015 at 17:18

The bootloader won't permit actions against READ/EXEC functions when RDP is enabled, but it's a software level interlock.

The distinction between CCMRAM and SRAM will make little difference in a die level attack of the processor.The more you do to physically protect your part, the more difficult it is for you to test and update it. While a strong front door and good lockset will dissuade some, it won't dissuade those willing to kick in the back door or break a few windows. If someone can leverage several million dollars of equipment against your design, they will have it.The strongest designs are those that use device unique firmware, end-to-end encryption of the firmware/image, a permanent boot loader, and keys in battery sustained RAM with tamper detection.

[lowpowermcu]

Posted on March 12, 2015 at 17:58

Hi mogg,

You can check this application note ''Secure Firmware Upgrade'':http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1743/LN1734/PF257935#doc: http://www.bdtic.com/DownLoad/ST/AN4023.pdfBut you will need to contact your local ST salesrepresentative for more details about the complete solution.

[francescatodiego]

Posted on March 13, 2015 at 07:55

Plus that I intend to deliver new features quite often and it will be impossible for me to send a new programmed micro to all customers every time a new release is available

Uhm mogg ...  you are a Microsoft employee ?

[razvan_lucaci]

Posted on March 13, 2015 at 10:14

Thank you all for the responses.

@diego. No I am not a Microsoft employee :) and yes, maybe I hurried a bit saying that I intend to deliver new features 'quitye often'. For a product lifetime of 5-10 years, I think 1 update per year is not so often.    @lowpowermcu. Thank you for the links, I will take a closer look to them. @clive1. Thank you for point out the RDP feature. The solution that has been shaping after the topic replyies is:     - having a second stage bootloader burned in each STM32F4 that I deliver which:             - when in 'boot mode', receives over serial interface an encrypted application image, decrypts it and writes it into Flash in clear. The image is unique for all products, being encrypted with a unique key and is only me that I know it             - when in 'app mode', jumps in Flash and executes the application from there, if a valid one is found     - having the RDP level set to Level 1     - no microprocessor pin being cut before soldering          Do you see any omission in this solution of my problem ?          Thank you