SMR32 Bootloader and security

dimax · ‎2012-09-28

Posted on September 29, 2012 at 07:26

As far as I understand using of the standard ST bootloader is not secure because in this case FW can not be protected and may be read by anyone. I mean anyone can read my FW and theoretically copy it to its own products or dissasemble it and see how it works Is this correct?

If yes the only way to secure FW is to write own bootloader with some kind of encryption. (I did it with AVRs). In this case my question is what are the minimal HW requirements to get access to system memory and fuses. What is the most simple on-board programmer available? What pins should be routed and how? Is where any reference?

I'm a bit confused about 20 pin connector od the J-Link. Why 20 pins?

And the last question. Is system memory accessible or more exactly writable from regular Flash?

Thanks.

Tesla DeLorean · ‎2012-09-29

Posted on September 29, 2012 at 14:55

The 20-pin connector is an ARM design, and replaces an earlier 14-pin version/standard. I'd imagine it was designed to provide full access to all the JTAG and other signals required, and provide alternating ground guarding on the ribbon cable.

You don't need this many signals to use JTAG/SWD, you could use test points, edge castellations, or interlayer connected break-offs instead.

Unprotected devices can be read out via the boot loader, or JTAG/SWD. The boot loader provides a cheap way of programming blank devices on the PCB rather than prior to manufacturing.

Code running in flash can read all other memory in the memory map, you'll get Hard Faults accessing unimplemented regions.

You should review the details of Readout Protection, this prevents access to your code via the bootloader or JTAG/SWD, but will not prevent a physical attack on the die.

Also you should review the PM00xx programming manuals on the software methods to program.

There is not explicit hardware method, the JTAG/SWD method injects code and data into RAM, and executes that to write your code into flash.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

dimax · ‎2012-09-29

Posted on September 29, 2012 at 15:10

Thanks for your support but this is not clear to me.

If I want to write my own bootloader, instead of the one provided by ST in system memory of chip, how can I reprogram system memory on-board?

Tesla DeLorean · ‎2012-09-29

Posted on September 29, 2012 at 16:06

If I want to write my own bootloader, instead of the one provided by ST in system memory of chip, how can I reprogram system memory on-board?

It's in ROM, you don't get to reprogram it. You can put you own loader at the front of your flash space.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

dimax · ‎2012-09-29

Posted on September 29, 2012 at 17:30

Are you sure !!!?

In this case how can I protect my FW from being copied? In our case we manufacture consumer products and I'm sure our Chinese manufacturers would like to forge it. Today they can not do it as they can not copy FW.

If I pass to STM32 they could simply (assuming they understand how STM32 bootloader works) read our FW via standard bootloader and manufacture the forge. How to prevent it?

I'm talking about a big money and I'm sure if they would have a chance they would do it.

Tesla DeLorean · ‎2012-09-29

Posted on September 29, 2012 at 21:09

You should really review what the Readout Protection modes provide for, because it includes locking down various features of the System Loader.

As I've discussed here before, all these and other IC's are susceptible to industrial attack by those who are better skilled and equipped than your average software developer.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Software Hacking via JTAGSWD possible&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=14

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

dimax · ‎2012-09-29

Posted on September 29, 2012 at 21:57

OK, I'm sorry.

I've missed the point that I can lock FW from being reading out. Protection against hacking via debug hooks is overkill for me.

Next point is remote FW update at customer's side. If I want to send FW update to customer in general case if I take no action I have to send him an image that can be easily burned on another IC. Are there any known technics to protect against it using System Loader?

I can think about following:

1. The most simple thing I can think about is to tier specific FW image to specific IC. As far as I remember each STM32 IC has unique signature.

2. Make secondary BootLoader and work via it's interface with encryption. In this case I can not upgrade secondary BootLoader or use #1 in this case.

I gust do not want to reinvent the wheel so I'd better ask before.

Thanks a lot for your help.

Tesla DeLorean · ‎2012-09-29

Posted on September 29, 2012 at 22:40

Mostly#2

It should be possible to create a bootloader that is sufficiently complete and robust you don't need to update it. You can add stages if you require, and you can call the internal system loader.

Beyond the Unique ID you could also place critical data into the BKP area.

The general rule is never to have the firmware in plain text outside of the device, and to use effective encryption, validation and signing.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

dimax · ‎2012-09-29

Posted on September 30, 2012 at 07:06

Not sure how BKP area may help?

Tesla DeLorean · ‎2012-09-30

Posted on September 30, 2012 at 14:58

Not sure how BKP area may help?

Encryption keys can be nuked via the TAMPER input.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..