Protection, Is my code in Flash really secure?

renon2 · ‎2008-06-09

Posted on June 09, 2008 at 12:43

#stm32

16-32micros · ‎2011-05-17

Posted on May 17, 2011 at 12:29

Quote:

On 28-05-2008 at 08:29, Anonymous wrote:

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?

=> ''Debug Mode'' means when JTAG Tools are connected to the device and controlling it with the ARM Ice-debug module as desrcribed in our RM0008 Section Debug (like Jlink, Ulink, R-Link etc...)

Quote:

''[...] 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)?

=> When Booting from Bootlaoader and RDP is enabled, only Removing RDP protection and Global erase commands are available and reset is done internally automatically, further about removing write protection : this is shown in the (Fig.19, page29 of AN2606) that when RDP is active the write protection cannot be disabled (NACK answer).

Quote:

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.

=> In all cases the Global Erase is done automatically when removing protection and is effective immediately.

Quote:

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.

=> See My previous answer.

=> Anyway, I suggest you to start trying these hypothical scenarios that may happen in theory and let us know the reality on real STM32 silicon ;)

Wish you a nice weekend.

ST1

[ This message was edited by: STOne-32 on 01-06-2008 12:56 ]

lanchon · ‎2011-05-17

Posted on May 17, 2011 at 12:29

hi ST1,

well here's the problem, if you take the text from the document:

''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).''

together with your definition of debug mode:

'''Debug Mode' means when JTAG Tools are connected to the device and controlling it with the ARM Ice-debug module as desrcribed in our RM0008 Section Debug''

then it follows that the security can be circumvented as follows:

-boot into main flash with no JTAG dongle connected to the device

-then connect the dongle, break, and read the flash

my point is not that this works -it probably doesn't-, my point is that one or both of these affirmations are false. so far ST is using vague rhetoric (some of it obviously false, as the example above shows) to convince us that the STM32 is safe instead of disclosing the security model. while others may be, I personally won't ever be convinced of that without a clear in-depth description.

I asked this question:

''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)?''

and you answer a completely different thing: what the bootloader supposedly does and does not. but again, ''does the bootloader have main flash read and/or write access (even though it doesn't use it)?''

if the answer is yes, then the bootloader becomes part of the ''trusted core''. that is, it could be exploited and must be scrutinized as closely as the protection model itself (in fact, it becomes part of the protection model). in that case one must investigate several possibilities, such as:

-can the bootloader code be trusted? to answer that ST must release the full source code.

-is the bootloader guaranteed to be unchanged in the future?

-can the bootloader be patched? can it be erased or overwritten? to answer that ST must fully disclose how the system area of the flash is erased and programmed at factory, and the mechanisms that guarantee that it can't be reprogrammed.

clearly the ''trusted core'' should be as small as possible, and the bootloader should not be part of it. but what's actually implemented in the STM32 is anybody's guess for now.

''Anyway, I suggest you to start trying these hypothical scenarios that may happen in theory and let us know the reality on real STM32 silicon''

actually I've successfully hacked obscure and ''secure'' embedded systems before as a hobby (some of it still floats around the net :) ), but I won't try any attack on the STM32, and here's why:

-it takes a lot of effort and ST is not paying.

-the burden of proof is on ST, not on it's clients. for me the STM32 is not safe until proven so.

-you can prove a system unsafe with a single hack, but you could never prove it safe by failing to hack it. the only way to prove it safe (sort of) is via full disclosure and analysis.

on the other hand, if ST discloses the security model (on time for my project schedule) I might look hard into the problem... :)

cheers!

16-32micros · ‎2011-05-17

Posted on May 17, 2011 at 12:29

Hi all,

Have a look on this paper about STM32 and security :

''The Benefits of Global Security Peripherals in STM32-based Applications''

http://www.iqmagazineonline.com/IQ/IQ22/pdfs/IQ22_pgs36-39.pdf

Here attached as well. Enjoy the lecture.

Cheers,

STOne-32.

asterix · ‎2011-05-17

Posted on May 17, 2011 at 12:29

Hi all,

Being an old LPC2000 (ARM7) from NXP then MSP430 from TI user, I've experienced some issues on both products when enabling Flash Read-out protection,

1) For MSP430 Micros :

On year ago, Once enabled on MSP430 the JTAG fuse is crammed and I can not anymore connect to my chip even for re-programming and I have seen accidentaly while prforming a wrong sequence, my chip is dead for ever and It can not recover anymore :-[ , I saw also a post on this Forum, where someone having the same issues while using LMI Micros and here is the full story :

http://www.luminarymicro.com/component/option,com_joomlaboard/Itemid,92/func,view/id,893/catid,7/

2) For LPC ARM7 Micros :

Code Read protection was breached on LPC2292 with Boot Loader Version 1.64 using the ISP interface. NXP was notified of this on 10 March 2007 of the CRP Security breach. When NXP failed to respond for a week, the breach was announced on Yahoo LPC2000 and NXP MCU discussion forums.

NXP has not responded to date.

Anecdotal evidence from contributors to the LPC2000 forum (claiming to work for NXP) appears to suggest that NXP is not concerned with CRP breaches on parts like LPC2292 which have Boot Loader Version 1 (BLV1).

Although NXP will not publicly acknowledge the existence of this vulnerability on LPC2292 or in its Version 1 Boot Loaders, it appears that NXP is confident that such vulnerabilities do not exist on LPC2138 parts with Boot Loader Version 2 (BLV2).

BLV1 is found in 2114, 2114, 2119, 2124, 2124, 2129, 2194, 2212, 2212, 2214, 2214, 2292, and 2294 parts. The most recent BLV1 release appears to be CRP Security breach was discovered and confirmed on release

BLV2 is found in 2132, 2138, 2141, 2142, 2144, 2146, and 2148 parts, which

comprise the second generation of LPC processors on which the flash controller is different.

BLV2 supports and additional IAP call (57) to enable applications to enter the ISP mode, supposedly to enable software updates in the field. It also has two levels of CRP (CRP2 and CRP3) and this is yet to be documented by NXP.

If CRP3 is the same as what is described in user manual for LPC2468 then its purpose is unclear. Its implementation (at least on LPC2138/2.11) does not seem consistent with this description.

Examination of the code (obtained by disassembly of binaries) for both BLV1 and BLV2 suggests that other than the above differences, these two implementations share the same code base, in particular, for the ISP interface.

In order for CRP to work, the on-chip Boot Loader code must always execute

following a system reset and disable the JTAG TAP controller before this port can be used to control execution of instructions by CPU.

Any method that gains controls of execution of instructions by CPU before the BootLoader disables the JTAG TAP controller can be used to potentially breach CRP security.

Anyone who has access to a device (not just the manufacturer) can patch or replace the on-chip Boot Loader. In such a scenario, the on-chip Boot Loader on each device must be verified and validated by the manufacturer to ensure CRP security has not been defeated, for example, by Trojans or defects. All code that can be possibly be executed by the CPU, including but not limited to, the Boot Loader and user code, must be free of defects that could be used to breach CRP security.

Full Story and scenarios is here :

http://www.cast.com.au/esdk/lpc2/crp-security.html

So Please ST Do not change your security model and also do not disclose your bootloader code, In my opinion It is a very reliable security scheme, However I think that the bootloader code as described in AN2606 version 2.0 is still having some enhancements for future like supporting USB, CAN or even SPI and most important to implement a Timeout mechanism for more safety using your Idependent watchdog.

Best regards, Cordialement ( in french) ;)

Asterix.

http://groups.google.com/groups/img/3nb/groups_bar.gif

Subscribe to STM32 Community

Email:

http://groups.google.com/group/stm32-community

[ This message was edited by: asterix.magigimix on 08-06-2008 17:53 ]

lanchon · ‎2011-05-17

Posted on May 17, 2011 at 12:29

hi asterix,

thanks for posting info on other cases.

I must admit I don't understand your thinking or where you're coming from.

> So Please ST Do not change your security model [...], In my opinion It is a very reliable security scheme

to the best of my knowledge, ST hasn't disclosed the security model at all. the few lines of text that ST has released about the model, that put together would make up a short paragraph at best, don't begin to describe the model, much less permit us to evaluate it's reliability.

I can't imagine how you got the idea that the security scheme is ''very reliable''. if it is based on text published by ST, please post the relevant segments to this thread. I've done that on my previous posts here and the results so far are not encouraging.

> and also do not disclose your bootloader code

what are you talking about? ''security by obscurity'' is not even consider security by today standards. on the field, security ''solutions'' based on obscurity have an abysmal track record. it's the best way to ensure failure.

the model has to be fully disclosed, and if the bootloader is part of the model it has to be disclosed too. the bootloader is part of the model if it is trusted by the model, meaning that the bootloader code has flash read access. in that case bugs could be exploited or maybe the bootloader code itself could be patched somehow.

(on the other hand if the bootloader is not trusted, bugs or malicious code in the bootloader area would be treated the same way as malicious software loaded in RAM via JTAG; the model would ensure that both fail to access the main flash. in this case bootloader disclosure would not be a prerequisite to evaluate security.)

anyway, what is the benefit of obscurity? are you aware that anybody can download the binary from the stm32? how much resources does it take to disassemble 2K of code? $1000? does that mean that if an attacker is willing to spend $1000 they will get to our code?

asterix · ‎2011-05-17

Posted on May 17, 2011 at 12:29

Bonjour lanchon,

This is simply my personal opinion based on old experience on 16-bits and 32-bits micros and looking at the market trends nowadays : I can see that all Open architectures like ARM and others are not actually implementing a high level security as it is the case for Smart-Card ones when a secure core and HW security algorithms are implemented like AES, DES, Elleptic etc.. and even for the internal Bootloader has to check before start-up a special key and differet levels of signatures as implemented on our Mobile phones when locked and others high level security applications.

Here some Upcoming Events for security workshops if you are interested.

Cordialement, :p

Asterix,

dbarto2 · ‎2011-05-17

Posted on May 17, 2011 at 12:29

dbarto2 · ‎2011-05-17

Posted on May 17, 2011 at 12:29

hbliek2 · ‎2011-05-17

Posted on May 17, 2011 at 12:29

According your findings, the ST documentation is not correct on the statement that RAM code cannot access the Flash code. When using external RAM, you're screwed of course, but using the internal SRAM, it doesn't seem a real threat. Because with a protected flash and the boot pins in RAM mode, I still cannot get JTAG access. So in order to be a problem, the malicious code has to be put in place by the protected flash code itself... Am I thinking right here?

Of course it is worryfying that ST makes claims which are not true, especially on this kind of subjects...

Nickname12657_O · ‎2011-05-17

Posted on May 17, 2011 at 12:29

Dear Bliek, Barto,

This is to clarify the point raised below, a small typo ( ''booted'' swapped by ''executed'') was introduced in our PM0042 regarding this sentence about FSMC and external code : It is now updated , please refer to the the last version (Rev8)

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

.

Thus, There is no change on the protection feature of the internal Flash, However a better clarification on what means ''user code'' is updated. If a user code (trusted code) will allow to dump the internal flash; of course it will bypass the hardware protection mechanism even the code is fetched out of the internal flash or in an external memory thru FSMC.

Cheers,

STOne-32.