Lpc2000

Hi Brian..

> [Brian Lane wrote:]
> One of the big failings of the LPC series is its lack 
> of protection for the code programmed into it. MSP430 
> has the jtag fuse that can be blown. I've seen rumors 
> that there is something in the works for later this 
> year, but that's doesn't help us now.
 
While code protection is "nice", you shouldn't count on it 100% and bet
your future on it. Licensing contracts, patents, etc. also have their
roles.

A few years ago, in a past life doing reverse engineering, I managed to
dump data from variety of 'secure' CPU ROMs, including oddball Japanese
parts. Remember when some 8051 flavors didn't latch /EA on powerup/
reset? And when some CPUs offered "encrypted" verify? Or your CPU had
ability to shift in instructions via test port?  Or your part requires
a multicycle reset but you boot 'instantly' and clean up system
execution behavior w/some preamble code, then begin dumping? Also, some
UV EPROM parts had the UV-erasable security bits located away from the
regular code ROM array, so covering the ROM area alone on a die and
erasing w/UV light allowed subsequent dumping.  Chips are pretty robust
and some will run awhile even when glass passivation layer has been
reduced/removed!

Depending on layout issues, pads, etc. a determined attacker might peel
the chip, and poss. use services of a "die surgery" company (FIB) to
reenable having the ROM viewed by the outside world.  Or use some pads
not brought out of the package.  (BTW: I have no idea what measures the
LPC21xx series may use in future to protect code. But there's nothing
that)

Much like protecting against cryptographic attacks, you need to figure
out the value of what you're trying to secure against the cost of the
level of security you desire.  And the attacker has to figure out the
same thing in reverse: how much effort is this task worth?

Bill Wiese
San Jose, CA







__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Bill Wiese wrote:

> Hi Brian..
> 
> 
>>[Brian Lane wrote:]
>>One of the big failings of the LPC series is its lack 
>>of protection for the code programmed into it. MSP430 
>>has the jtag fuse that can be blown. I've seen rumors 
>>that there is something in the works for later this 
>>year, but that's doesn't help us now.
> 
>  
> While code protection is "nice", you shouldn't count on it 100% and bet
> your future on it. Licensing contracts, patents, etc. also have their
> roles.
> 

That is true, but doesn't help you at all when some anonymous chinese 
company clones your new widget. It also doesn't help much if you don't 
have 100k budgeted for lawyers to enforce your patents.

I have no faith in protection offered by patents or contracts. I need to 
keep my code as secure as possible, given the application and 
distribution of the device.

> A few years ago, in a past life doing reverse engineering, I managed to
> dump data from variety of 'secure' CPU ROMs, including oddball Japanese
> parts. Remember when some 8051 flavors didn't latch /EA on powerup/
> reset? And when some CPUs offered "encrypted" verify? Or your CPU had
> ability to shift in instructions via test port?  Or your part requires
> a multicycle reset but you boot 'instantly' and clean up system
> execution behavior w/some preamble code, then begin dumping? Also, some
> UV EPROM parts had the UV-erasable security bits located away from the
> regular code ROM array, so covering the ROM area alone on a die and
> erasing w/UV light allowed subsequent dumping.  Chips are pretty robust
> and some will run awhile even when glass passivation layer has been
> reduced/removed!

I've never done any of that, but it sure sounds like an interesting 
challenge. I have been surprised at the abuse I can sometimes expose a 
chip to and have it survive :)

> 
> Depending on layout issues, pads, etc. a determined attacker might peel
> the chip, and poss. use services of a "die surgery" company (FIB) to
> reenable having the ROM viewed by the outside world.  Or use some pads
> not brought out of the package.  (BTW: I have no idea what measures the
> LPC21xx series may use in future to protect code. But there's nothing
> that)
> 
> Much like protecting against cryptographic attacks, you need to figure
> out the value of what you're trying to secure against the cost of the
> level of security you desire.  And the attacker has to figure out the
> same thing in reverse: how much effort is this task worth?

That's the bottom line. And the LPC doesn't provide anything that would 
prevent someone from cloning the chip using the JTAG interface. You can 
cut the pins, but that introduces extra assembly cost, and how hard is 
it to scrape off some of the chip's plastic and re-attach to them?

Plans for future code protection in the LPC don't help us now. And they 
are likely to be an after-thought when it ought to have been included 
from the start.


Brian

-- 
-----------------------------------------------------
Brian C. Lane (W7BCL)                      Programmer
www.shinemicro.com   RF, DSP & Microcontroller Design

Hi Brian, Bill,

> That is true, but doesn't help you at all when some anonymous chinese
> company clones your new widget. It also doesn't help much if you don't
> have 100k budgeted for lawyers to enforce your patents.

In countries like that patents aren't even valid anyway.

> I have no faith in protection offered by patents or contracts. I need to
> keep my code as secure as possible, given the application and
> distribution of the device.

Same viewpoint here.
I think that in the 8 bit arena, the first real level of protection was
offered
by AVR. Being an ASIC like that, things were scattered around too much,
and the charge in a Flash cell is too weak to microprobe it, or so I've
been told by Atmel.

> That's the bottom line. And the LPC doesn't provide anything that would
> prevent someone from cloning the chip using the JTAG interface. You can
> cut the pins, but that introduces extra assembly cost, and how hard is
> it to scrape off some of the chip's plastic and re-attach to them?

Exactly, as per my previous post.

> Plans for future code protection in the LPC don't help us now. And they
> are likely to be an after-thought when it ought to have been included
> from the start.

EXACTLY.
Some companies here in Oz really have been brought to their knees with
that crap.
The only protection really I guess is to flood the market fast so there's
not
much left for parasites, or at least, it wouldn't be worth their while
anymore.

-- Kris