Lpc2000

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