stm32f207 code protection

adrian · ‎2013-05-04

Posted on May 05, 2013 at 00:45

Hi again.

I have made great strides in our system this past week (our first use of the stm32) and we have had great interest in this latest (stm32 based) product from potential customers and therefore we would like to sample early pre-production hardware to a few of these companies.

Now, I'm just about to create a bootloader so that we can at least update the firmware on these pre-production units, we have a lot of IP in our software and we need to ensure that it remains as safe as possible.

I've read the threads on here about how the code protection works and possible weaknesses in it.

Now, Level 1 prohibits access to flash via the debug interface which sounds fine in principle, but as pointed out there are potential problems here, the main failing that I can see (the documentation seems to imply that this is allowed) is that ram can be written to and read, possible injection vectors here could be locating RAM relocated functions and injecting code or just scanning the memory during a firmware update to read out the decrypted blocks of firmware...etc.

Level 2 effectively permanently bricks the device, it disables the debug interface with no way of ever being able to mass erase (no special jtag sequence or erase pin). We are using the 176 pin BGA so it's not an easy task to replace a processor on a board if we need to debug a specific board at a later stage.

So, that leaves us with having to secure Level 1 somehow.

My initial thought is to remap the debug interface pins early in the boot process (i.e straight away) - this should still permit the a debug connection over the debug interface under reset and presumably allow a mass ease to be done and restore the device to virgin state.

I suppose there are still other attack vectors by careful manipulation of the program counter, but this would be non-trivial.

I'd also ensure that when decrypting the firmware into RAM that the debug interface pins had definately been remapped and not continue decrypting if they are not in the correct state.

I feel somewhat nervous about the code protection on the STM32, it doesn't really seem that it's been that well thought out and although level 2 does provide a secure answer, it is terminal if you subsequently need to return a board to a virgin state. I've worked with Atmel and Luminary ARM devices which have all had a mechanism for erasing a device when debug is disabled.

Anybody got any other thoughts or advice on how you're protecting your products?

Thanks.

Adrian

picguy2 · ‎2013-05-16

Posted on May 17, 2013 at 01:08

>Now, Level 1 prohibits access to flash via the debug interface which sounds fine in principle, but as pointed out there are potential problems here, the main failing that I can see (the documentation seems to imply that this is allowed) is that ram can be written to and read, possible injection vectors here could be locating RAM relocated functions and injecting code or just scanning the memory during a firmware update to read out the decrypted blocks of firmware...etc.

When I looked at this for much the same reason as you did I came away believing that level 1 protection was ok. It appeared to me that with level 1 protection the only thing one could with the debugger was erase the entire part. And possibly all of RAM as well.

With the debugger locked out injection vectors become impossible to inject.

I needed assurance that the private part of a (Public, Private) Elliptic Curve key pair might be compromised. I was able to generate the key pair saving it to flash ROM. The charm of doing it this way is that the private key never leaves the microcontroller. As part of a external configuration process the recently generated public key is sent to the external configuration process.

My concern: could I write ROM changing 1’s to 0’s? Level 1 (and level 2 which I never want to use) does not prevent code changing flash ROM.

One hole can still exist. If you read or execute code using FSMC that memory could contain code that resets level 1 protection. You may need validate what you read before you execute it.

Note: what I said is for F4 parts. Hopefully the same is true for F2 parts as well.

adrian · ‎2013-05-22

Posted on May 22, 2013 at 09:31

Thanks for the response!

Sounds like you've had many of the same thoughts as me!

Level 2 is just pointless, unless you're 100% confident that you've made no code errors or that you're happy with just being able to flash new code on via boot loader. We often need to analyse units that have failed in the field and the only real way to find out exactly what is going on is to hook up the debugger, Level 2 means that isn't going to happen.

So making Level 1 as secure as possible is the only useful way.

Having worked with Luminary parts (which when you disable JTAG the part can still be returned to blank with a special clocking sequence on the debug pins) and Atmel SAM parts where there was an erase pin (which again took the part back to a blank state) I find it bizarre that ST haven't provided a mechanism to return a part to ''factory'' given that Level 2 is terminal.

Adrian