Lpc2000

--- In lpc2000@yahoogroups.com, "Danish Ali" <danish@...> wrote:

> IMHO the LPC2xxx* should be regarded as safe until someone
> claims to have _broken_ copy protection, not just come up with
> a theoretical line of attack.

I do not doubt that this is a reasonable assumption in many cases.

> And let's hope they say which line of
> attack was vulnerable.
> *excluding LPC2104/5/6

LPC2104/5/6 do not have CRP.  So there is no "attack" concept.

The vulnerabilities that I found based on looking at implementation of
boot loader version 1.64 on LPC2292:

V1:  JTAG disable window on startup;

V2:  defect in exception handler code;

V3:  defect in CSI implementation; and

V4:  undocumented commands and methods.

The above list supersedes earlier discussion in this forum in bits and
pieces.

Until we know the above issues are addressed by the boot loader
implementors, I would not consider the CRP feature safe for the kind
of requirements I have seen.

> But I think ROM/FLASH might make a difference.

Only as far as accidental erasure which was my first gripe with LPC
family.

> Because Philips must somehow get the bootloader into FLASH.
>  - It might be that the JTAG is enabled at reset and the bootloader
_must_
> turn off protection before a JTAG attack can take place.
> And a blank flash bootloader does not do this.

I think I lost you here :)  Did you mean to say "that the boot loader
must turn off in order prevent JTAG attack"?

>  - It might be that Philips put in an extra probing pad (not bonded out)
> that controls whether the JTAG is enabled or disabled at reset (and it
> is merely a matter of belt-and-braces as to why the bootloader
> explicitly re-disables it).

I do not see any evidence of this in the LPC family.  This concept of
"fuses" used by other manufactures works this way, and I have not seen
any reference to such a feature by Philips.

>   = With a substitute bootloader, one could omit that disabling
> test the state of JTAG at hard reset before the bootloader has
touched it.

Given the assumption above is not likely to be true, I would not
accept this.

> With bootloader in ROM, as unity said, the Philips trap-door (which
> might or might not be exploitable by an attacker) is not necessary.

The "trap-door" issue is one thing, (which I am sure Philips would
have made the decision to delete from its boot loader) but the
stability of the CSI (command string interpreter) is an issue.

One other poster said that it is irrelevant of the CSI can be made to
crash by supplying erroneous input.  I think it matter, because this
vulnerability is a resource that hackers use to exploit.  This is one
of the most commonly used methods if you look at history.

> But I have no way of knowing if Philips would remove such a
> trap-door assuming one exists.

It would be a win-win for both Philips and LPC community if Philips would:

a)  open a channel to acknowledge bugs as and when they are reported;
b)  provide information as to what versions and parts these apply to; and
c)  indicate when they plan to fix them and how users can check this out;

Jaya