Yahoo Groups archive

Lpc2000

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

Message

Re: [lpc2000] Protection

2004-03-03 by microbit

Hi David, Robert et al,

It is interesting that a thread has been in progress about code security
on MSP430 forum.
I personally found this very interesting reading :
(Thanks to Chris Liechti who posted it on Y! MSP430)
http://www.cl.cam.ac.uk/~sps32/mcu_lock.html

Mininal code security I deem paramount, to turn away (hopefully) most
prospective firmware pirates. For about 7 years now, every client I have
developed for always wanted code security. (or the perception of it)

A product that benefits greatly from a small form factor, low power,
while high CPU thruput like LPC2000, surely to me implies that there's a
good
chance the surrounding HW in product XYZ is fairly minimal, therefore easily
copied.

-- Kris

David Willmore wrote :

> Hello, Robert.
>
> On the topic of protection, I just want to throw this out as
> a cautionary note.  The method of code protection that Philips
> is proposing for the LPC family looks good, but I see at least
> one good attack on it.  Namely, a trojan horse.
>
> Since the programming firmware is not to be touched by the
> normal programmer/developer, we're prone to not even look at
> it.  A clever attacker could take a target system, blank the
> chip, load in new code which overwrites the boot code provided
> by Philips.  Such a design will require reading and understanding
> the Philips code and designing a reasonable substitute.  The
> difference would be that it would only act like it prevented
> readback of code after protection was set.  Via some special
> sequence, the boot code would read out the FLASH.
>
> So, the attack goes:
> 1) but the target device
> 2) blank and reprogram the flash
> 3) return it as broken and ask for it to be reprogrammed (may
>    require some social engineering)
> 4) send it back and let them reprogram it
> 5) receive 'fixed' unit and read out FLASH with special sequence.
>
> So, when repairing failed units, you may want to take an extra
> step to ensure that this kind of attack hasn't occured--load
> in a quick program that does a checksum on the bootblock and
> gives back a thunbs up/down indication of tampering.
>
> Also, this kind of attack could be launched through a supply
> chain.  Be careful who you buy your chips from and where they
> get them from.
>
> This just crossed my mind as I was drifting off to sleep last
> night, so I thought I'd share it so that it doesn't have to
> keep anyone else up.
>
> Cheers,
> David
>
>

Attachments

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.