Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

LPC22xx Flash Copy Protection

LPC22xx Flash Copy Protection

2005-06-01 by mirax_ua

Hello ppl,
Those processors don't have any flash copy protection, do they? As 
long as there is some executable code in external memory and that is 
what external flash is meant for. You can hook up some of you code 
into external flash that will read the contents of internal flash and 
give it away via say serial interface. What protection are we talking 
about here?
Acctually, I couldn't find any 32-bit processor that has both external 
memory bus and internal flash with read protection.

Re: LPC22xx Flash Copy Protection

2005-06-01 by tom_laffey

Hi,

My guess is that you are looking for a CPU for a secure (financial?) 
application.  I worked on a platform a few years ago that stored off-
chip programs and data in an encrypted form and then decrypted pages 
into internal RAM as needed.  Quite a bit of "infrastructure" is 
required to do this sort of thing.  And you might want an ARM9 instead 
of an ARM7.  

To do this now, I'd be looking for an implemenation using 
ARM's "TrustZone" and "SecureCore" technology.  I haven't yet seen this 
in generally available silicon.

Regards,

Tom

--- In lpc2000@yahoogroups.com, "mirax_ua" <mirax_ua@y...> wrote:
> Hello ppl,
> Those processors don't have any flash copy protection, do they? As 
> long as there is some executable code in external memory and that is 
> what external flash is meant for. You can hook up some of you code 
> into external flash that will read the contents of internal flash and 
> give it away via say serial interface. What protection are we talking 
> about here?
> Acctually, I couldn't find any 32-bit processor that has both 
external 
> memory bus and internal flash with read protection.

Re: LPC22xx Flash Copy Protection

2005-06-01 by lpc2100_fan

Hi,

your observation is correct that any external CODE will destroy your
efforts to secure the internal Flash because there is no READ
protection. The available protection disables all debug channels and
if your code does not branch outside the chip, protection is
available. Even external data is possible but no external code. As Tom
already pointed out, an option is to encrypt/decrypt the code you are
fetching from external memory. Besides the fact that this will use up
a significant part of your internal Flash, it will also slow down
execution a lot. Nevertheless, if you can put the part of the code
that needs performance into the flash, together with the en/decryption
code this might be an option. 

Better would be if you can fit your program (not necessarily your
data) into the internal flash. In this case the available protection
would work. 

One other option to protect yourself against tampering with external
memory are sanity checks such as checksums of a code segment before
you execute it, which would prevent you from execute code not
compliant with checksum rules you would set up. However, this can be
cracked rather easily, just requires somebody with a little experience
rather than somebody who is just curious ;-)

In a nutshell, of the shelf microcontrollers will probably not fit
your requirements unless you can fit your whole program into internal
flash. 

Cheers, Bob

--- In lpc2000@yahoogroups.com, "mirax_ua" <mirax_ua@y...> wrote:
Show quoted textHide quoted text
> Hello ppl,
> Those processors don't have any flash copy protection, do they? As 
> long as there is some executable code in external memory and that is 
> what external flash is meant for. You can hook up some of you code 
> into external flash that will read the contents of internal flash and 
> give it away via say serial interface. What protection are we talking 
> about here?
> Acctually, I couldn't find any 32-bit processor that has both external 
> memory bus and internal flash with read protection.

Re: LPC22xx Flash Copy Protection

2005-06-02 by mirax_ua

Hi Bob,
You are right about "...unless you can fit your whole program into 
internal flash" and that is what I eventually decided to do (have 
chosen AT91SAM7S512 though, 'cos of 512k of flash and 64k of RAM). 
And about "Besides the fact that this will use up a significant part 
of your internal Flash..." I can say that I have earlyer implemented 
DES (56-bit key) decrypting downloader in PIC16Fxxx and the whole 
thing took about 1k of flash and 256 bytes of EEPROM for tables 
(matrices).


--- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@y...> 
wrote:
> Hi,
> 
> your observation is correct that any external CODE will destroy 
your
> efforts to secure the internal Flash because there is no READ
> protection. The available protection disables all debug channels 
and
> if your code does not branch outside the chip, protection is
> available. Even external data is possible but no external code. As 
Tom
> already pointed out, an option is to encrypt/decrypt the code you 
are
> fetching from external memory. Besides the fact that this will use 
up
> a significant part of your internal Flash, it will also slow down
> execution a lot. Nevertheless, if you can put the part of the code
> that needs performance into the flash, together with the 
en/decryption
> code this might be an option. 
> 
> Better would be if you can fit your program (not necessarily your
> data) into the internal flash. In this case the available 
protection
> would work. 
> 
> One other option to protect yourself against tampering with 
external
> memory are sanity checks such as checksums of a code segment before
> you execute it, which would prevent you from execute code not
> compliant with checksum rules you would set up. However, this can 
be
> cracked rather easily, just requires somebody with a little 
experience
> rather than somebody who is just curious ;-)
> 
> In a nutshell, of the shelf microcontrollers will probably not fit
> your requirements unless you can fit your whole program into 
internal
Show quoted textHide quoted text
> flash. 
> 
> Cheers, Bob

Re: LPC22xx Flash Copy Protection

2005-06-02 by mirax_ua

Hi Tom,
This is quite good solution, btw, what processor did you use for 
this RAM Decrypted Code Execution? And do you know any ARM9 
processor with internal flash to keep decrypting code and key? I 
guess this internal flash _must_ be read protected and LPC22xx suits 
it but these processors have a bit limited RAM (you can find 
processors with bigger internal RAM of course).

--- In lpc2000@yahoogroups.com, "tom_laffey" <tom_laffey@y...> wrote:
> Hi,
> 
> My guess is that you are looking for a CPU for a secure 
(financial?) 
> application.  I worked on a platform a few years ago that stored 
off-
> chip programs and data in an encrypted form and then decrypted 
pages 
> into internal RAM as needed.  Quite a bit of "infrastructure" is 
> required to do this sort of thing.  And you might want an ARM9 
instead 
> of an ARM7.  
> 
> To do this now, I'd be looking for an implemenation using 
> ARM's "TrustZone" and "SecureCore" technology.  I haven't yet seen 
this 
> in generally available silicon.
> 
> Regards,
> 
> Tom
> 
> --- In lpc2000@yahoogroups.com, "mirax_ua" <mirax_ua@y...> wrote:
> > Hello ppl,
> > Those processors don't have any flash copy protection, do they? 
As 
> > long as there is some executable code in external memory and 
that is 
> > what external flash is meant for. You can hook up some of you 
code 
> > into external flash that will read the contents of internal 
flash and 
> > give it away via say serial interface. What protection are we 
talking 
Show quoted textHide quoted text
> > about here?
> > Acctually, I couldn't find any 32-bit processor that has both 
> external 
> > memory bus and internal flash with read protection.

Re: LPC22xx Flash Copy Protection

2005-06-02 by tom_laffey

Hi,

I was working for a well-known financial terminal provider and we 
were contracting with a well-known chip supplier to develop a custom 
design.  I can't provide details on the design due to NDA.

What I can say is that the ARM "TrustZone" and "SecureCore" IP, when 
combined, provide a high percentage of what we were doing.  Offhand, 
I can't think of a current ARM9 implemenation that I'd consider for 
this.  We were using an ARM7 in our custom implemenation for cost 
(die area) reasons.

Regards,

Tom


-- In lpc2000@yahoogroups.com, "mirax_ua" <mirax_ua@y...> wrote:
> Hi Tom,
> This is quite good solution, btw, what processor did you use for 
> this RAM Decrypted Code Execution? And do you know any ARM9 
> processor with internal flash to keep decrypting code and key? I 
> guess this internal flash _must_ be read protected and LPC22xx 
suits 
> it but these processors have a bit limited RAM (you can find 
> processors with bigger internal RAM of course).
> 
> --- In lpc2000@yahoogroups.com, "tom_laffey" <tom_laffey@y...> 
wrote:
> > Hi,
> > 
> > My guess is that you are looking for a CPU for a secure 
> (financial?) 
> > application.  I worked on a platform a few years ago that stored 
> off-
> > chip programs and data in an encrypted form and then decrypted 
> pages 
> > into internal RAM as needed.  Quite a bit of "infrastructure" is 
> > required to do this sort of thing.  And you might want an ARM9 
> instead 
> > of an ARM7.  
> > 
> > To do this now, I'd be looking for an implemenation using 
> > ARM's "TrustZone" and "SecureCore" technology.  I haven't yet 
seen 
Show quoted textHide quoted text
> this 
> > in generally available silicon.
> > 
> > Regards,
> > 
> > Tom
> > 
> > --- In lpc2000@yahoogroups.com, "mirax_ua" <mirax_ua@y...> wrote:
> > > Hello ppl,
> > > Those processors don't have any flash copy protection, do they? 
> As 
> > > long as there is some executable code in external memory and 
> that is 
> > > what external flash is meant for. You can hook up some of you 
> code 
> > > into external flash that will read the contents of internal 
> flash and 
> > > give it away via say serial interface. What protection are we 
> talking 
> > > about here?
> > > Acctually, I couldn't find any 32-bit processor that has both 
> > external 
> > > memory bus and internal flash with read protection.

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.