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

[lanchon]

Posted on May 17, 2011 at 12:29

hi STOne,

thanks for your concern. > Is the PM0042 not enought clear on this protection point ? not at all. PM0042 just says: ''Once the protection byte is programmed to a value, Flash memory read accesses are not allowed when the device is in debug mode.'' I can think of a thousand ways to circumvent various imagined protection implementations that would all fit within that description. the description must be enhanced to the point that *every* imagined protection implementation fitting the description would appear to be robust. in fact, for evaluation I'll always assume that the *worse* imagined protection implementation fitting the description is the one actually implemented. the alternative is for ST to say ''trust us, we are a good at this''. or even the much better option ''trust us, we've evaluate the system and we officially say that we know of no workable exploit at this time'', which AFAIA you haven't said for now. the latter option would convince a certain audience, since at least you're putting your money where your mouth is. but you can be certain that some of us won't be willing to trust our IP to unverifiable claims (for us), and we'll have to look for alternatives. it all boils down to what customers you want to have. also, PM0042 continues with: ''All features linked to loading and executing code in RAM are still active (for example, JTAG/SWD, boot in RAM, etc.)'' this is very troubling. besides the possible exploits routes it might open, it's particularly troubling that the contents of RAM appear to be out in the open. this would mean that the STM32 can't do cryptography, say to support protected firmware upgrades, since the keys could be easily recovered from the RAM contents when the cryptography algorithms are executing. the same would happen to the backup registers and the whole anti-tamper protection for keys goes down the toilet. I believe the sooner ST publishes a serious security document the better for it. in particular, if the doc can be reviewed by the public soon, concerns could be addressed in time to reach production for the upcoming families. at least some secure families is *immensely* better than none at all.

[gdp123a]

Posted on May 17, 2011 at 12:29

If possible, it would be great if there was a command in the bootloader to disable the JTAG/SWD and enable read protection at the same time.

Then the only way to enable the JTAG again would be to do a mass erase via the bootloader. Failing that, perhaps ST can let us know how to destroy the JTAG interface without destroying the whole chip. A JTAG fuse as used in the MSP430 would be good. Greg.

[jj]

Posted on May 17, 2011 at 12:29

Hi STOne-

lanchon's post re: protection mechanisms/attacks stands on its own! (thank you lanchon) As a Tech-marketing guy I wish to ''strengthen the case'' for WHY IP/Code Security is SO important to your STM32 client base. Often - if protection is ''too easy to defeat'' our CLIENTS BECOME our competitors! And they have suffered NONE of our development costs, time and agony. Loyalty is NOT what it once was - this HAS happened to my firm. If not our client - FOR SURE - our client's COMPETITORS! They have EVERY REASON to ''acquire'' our client's product - and ''steal'' everything that they can. Now our clients KNOW this - and ALWAYS ask, ''HOW SECURE is your design???'' We've removed part markings as a pathetic, past attempt to add difficulty. We've since SEEN the chip identity markings after the ''top'' was popped! This Security issue is a really BIG DEAL - and will have a STRONG IMPACT upon the Sales success of your otherwise wonderful, new micro family. Lanchon's post - and perhaps this one - should be directed to the highest levels. Thanks much for your past, current and future support.

[lanchon]

Posted on May 17, 2011 at 12:29

hi jj,

thanks, you sound very convincing too. what do you mean by this? > We've since SEEN the chip identity markings after the ''top'' was popped!

[jj]

Posted on May 17, 2011 at 12:29

hi back lanchon,

First - great thanks for your time/efforts with this forum - know that you've helped many. We all owe you great thanks for your generous, thoughtful contributions. I have a photo showing an attack on a QFP - in which the plastic ''housing'' was ''lifted'' - and critical IC markings were revealed. This is NOT any weakness by STMicro - ALL makers seem to scribe ID markings onto their wafers. If you wish - I will try to post a hi-res photo here. (I had no idea this could be done) The real ISSUE remains that IP and Code Security are crucial to any serious user - and otherwise wonderful devices may be rendered UNATTRACTIVE by unclear or ineffective Security Measures. I hope others will ''second'' our requests and that STMicro will raise the priority of this VITAL issue.

[paulsmitton9]

Posted on May 17, 2011 at 12:29

jj: I'll second that.

I'm migrating from the MSP430 (which has a jtag-fuse to blow), as i think quite a few people are, certainly it was hinted at an st seminar, and could do with code protection equivalent to the blown fuse.

[lanchon]

Posted on May 17, 2011 at 12:29

hi jj,

thanks for your generous comments. > I had no idea this could be done yes, it's easy and cheap to expose a die, but there's much more you could do. you can sniff information going through interconnects on the chip to obtain cryptographic keys, you can selectively reprogram flash cells to remove protections, and you can even patch the chip here and there to coerce it to expose the flash contents. tools to do this are very expensive, but I've read they can be rented at reasonable prices. there's no perfect protection, all you can aim for is that stealing your design be more expensive than the cost of an independent redesign. and of course attack costs will continue to go down. there are countermeasures to complicate these attacks that sensitive dies implement. I strongly expect that the stm32 implements hardened flash cells for the read protection bits (it very probably does), and I expect no other countermeasures on the stm32. > The real ISSUE remains that IP and Code Security are crucial but it's not very probable that discussions in these technical forums will reach the ones that make the political decisions. maybe some interested party should contact ST at another level, sales at a minimum. note that these are not easy decisions: imagine that the current batch of STM32s is vulnerable by design, and that a description of the security model would immediately expose the vulnerability, then what should ST do about the current clients and their IP? imagine that the security model is only documented for a second generation of devices. wouldn't that be the same as asserting that the first generation is vulnerable? wouldn't that encourage attackers to go after the first? our solution is simple: developers and attackers alike should consider a device not proven to be safe as certainly vulnerable.

[16-32micros]

Posted on May 17, 2011 at 12:29

Dear members,

Quote:

On 16-04-2008 at 19:20, Anonymous wrote: Hi Lanchon,hholms,greg_stm,obtronix, renon, Is the PM0042 not enought clear on this protection point ? Cheers, STOne-32. [ This message was edited by: STOne-32 on 01-05-2008 19:21 ] Following your valuable feedbacks, I would like to inform you that the STM32 programling manual has been updated accordingly and here is the new version :

http://www.st.com/stonline/products/literature/pm/13259.pdf

that clarifies the protection and flash procedures related to security for your applications IPs. Cheers, STOne-32.

[lanchon]

Posted on May 17, 2011 at 12:29

hi ST1,

thanks. I see the protection section has been rewritten. however I believe only two phrases are really relevant to this discussion; it says: ''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).'' where is the term ''debug mode'' defined, how and at what times can it be activated, and what does it mean to boot with the debug mode not active? ''[...] the memory can be programmed by the code executed from the main Flash memory (for IAP, constant storage, etc.), but it is protected against write/erase (but not against mass erase) in debug mode or when booting from the embedded SRAM.'' what about booting into the bootloader with RDP enabled? does the bootloader have main flash read and/or write access (even though it doesn't use it)? this is an improvement, but the security model is still not clear. it seems that coming out of reset a decision is made weather to permit or deny access to the main flash for both read and write, that won't be reviewed until next reset. if this is true ST should clearly say so, and explain in exact non-ambiguous terms when and how the decision is taken, what the direct consequences of the decision are and how they are implemented. (also how the whole system works to protect code if this corollary is not completely obvious.) and ST could even take the opportunity to *sell the stm32* by explaining extras such as how the reset-time decision is cleverly protected from malicious reset and power glitches, how the protection cells are hardened to withstand certain physical attacks, etc. as it stands, I'm afraid the unspecified security model continues to be a show-stopper for the STM32 in my application.

[jj]

Posted on May 17, 2011 at 12:29

Hi STOne-

Thanks much for spearheading your forum users requests for more detail and ''openness'' in describing/invoking STM32 security. Much appreciated. I too agree with lanchon's points - while the new document provides added detail it appears unduly constrained by ''maintaining format consistency'' with its original/model. As a result - many of the key issues raised directly in this forum topic - have ''not'' been adequately addressed. And sadly - some have remained ''silent!'' Having worked for a ''giant'' I can appreciate the rules/protocols ST must navigate. This security topic has huge forum interest - WILL greatly effect STM32 ''design-in'' - and believe that many will remain ''unconvinced'' by the new document. Perhaps ST's ''expert comment'' - in a ''Point by Point'' response to each security issue raised herein - free's ST from ''document consistency'' and better ENABLES the detailed, thoughtful, specific answers we NEED! While we forum posters may not YET be ''market leaders'' - in aggregate we are HUGE - and our expanding purchases generate great profit for ST...