Protection, Is my code in Flash really secure?

[renon2]

Posted on June 09, 2008 at 12:43

Protection, Is my code in Flash really secure?

#stm32

[angelos]

Posted on May 17, 2011 at 12:29

Unfortunately most micros that are not designed specifically for security/encryption applications can be hacked by companies in China for less than an engineer's monthly salary and that includes the STM32.

[Shang.Dawei]

Posted on May 17, 2011 at 12:29

[german]

Posted on May 17, 2011 at 12:29

And can you tell us how it can be possible to load code in Ram in a programmed and protected device?

Thanks!

[Tesla DeLorean]

Posted on May 17, 2011 at 12:29

And can you tell us how it can be possible to load code in Ram in a programmed and protected device?

Via JTAG, for instance. A ROP'd device can also copy data to RAM, and that can come from the FLASH, or just as easily via a serial port. Presumably you'll also have variables and buffers in RAM.

[Gawie]

Posted on May 17, 2011 at 12:29

Via JTAG, for instance.

Are you sure it will be possible to read the Main Flash with code that was downloaded to RAM via JTAG/SWD on a Read-out protected device? The reason I asked is that the Flash Programming manual 

PM0075

 says the following (and we assume it is correct ;) :(

Once the protection byte has been programmed:

â—� 

Main Flash memory read access is not allowed except for the user code (when booting 

from main Flash memory itself with the 

debug mode not active

).

I am not concerned about my code running in RAM (copied from my code in flash) and reading from flash. I am concerned about malicious code copied to my end product's RAM via JTAG (or any other method) and reading out my code in flash. As far as I understand it, it will be possible to copy code to RAM, but it will not have read access to flash. This can be used to clear Read-out protection and once this is done, a mass erase of the flash will occur. Again, I assume the spec's are correctly implemented ;-).

Say it is possible as you suggested - Can JTAG be totally disabled? I know one could configure the I/O pins to be used as GPIO pins by setting the SWJ_CFG bits in the AFIO_MAPR register. But it seems that JTAG is always enabled on startup and only disabled once my code disabled it. So there will be a time during startup that JTAG will be enabled. Is there any other way to totally disable JTAG?

Cheers,

Gawie

[Tesla DeLorean]

Posted on May 17, 2011 at 12:29

Are you sure it will be possible to read the Main Flash with code that was downloaded to RAM via JTAG/SWD on a Read-out protected device?

You are inferring something I didn't say, and the question was not asked in that fashion or with that specificity. The question asked if it was possible to get code/data in to RAM on a ROP'd device. I described several methods that do work to do that. If you are booting to RAM or using JTAG, you are indeed going to have difficultly reading the FLASH and ROM. I do not believe the protection is robust against a competent and equipped attacker. The fact that code running in RAM can read FLASH and ROM on a ROP'd device in the right conditions suggests there is a very large hole there.

[Gawie]

Posted on May 17, 2011 at 12:29

Thanks for putting it in perspective clive1.

Sorry, it was not my intention to infer something that you didn't say - it's more due to me not understanding... ;) 

I still want to ask the question: 

Can JTAG be totally disabled?

[Tesla DeLorean]

Posted on May 17, 2011 at 12:29

I still want to ask the question: 

Can JTAG be totally disabled?

You can remap the JTAG pins early in your startup.s code, from a physical stand-point you can bury the contacts with a BGA package. Instead of exporting a JTAG connection use the USART1 loader to get your original code on-board. Such designs will clearly make debugging difficult, but wouldn't preclude someone removing the part, and tearing it down for there. I'm not aware of a fuse or option to render the JTAG non-functional. There will be a small window until you remap, and the device could be booted into ROM or RAM avoiding your code completely.

[damh]

Posted on May 17, 2011 at 12:29

With JTAG connected, there is no code, that would be executed. Even if JTAG-disabling is your first assembler command, you can intrude per JTAG.

Someone said (I have never proofed or disproofed), that the pins for JTAG can be destroyed per ''wrong usage'' without destroying the rest of the mcu. That operation removes warranty and you cannot be sure, that the next charge of mcu will behave the same way. It's like an undocumented feature. Clive's way with BGA an direct connect to ground- or vcc-pin (We use TCK on GND, TMS,TDO,TDI on VCC. It works, but test for yourself.) should work best for allmost all attackers. All others would prefer to intrude your company ;) It is faster and cheaper ;)

[danieldimov]

Posted on March 12, 2014 at 10:18

It seems that all the potential problems are in the bootloader... So my question is: what is so special in this ''standard'' bootloader?! Can I make my own bootloader or can I write my code without such thing as bootloader?