AnsweredAssumed Answered

stm32f207 code protection

Question asked by carpenter.adrian on May 5, 2013
Latest reply on May 22, 2013 by carpenter.adrian
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

Outcomes