Yahoo Groups archive

Lpc2000

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

Message

Re: LPC FLASH security (CRP) broken?

2005-12-22 by jayasooriah

Pleae let me clarify.  I am seeking affirmative answers to the two
questions below so as to assure client that code in the LPC parts
(with CRP enabled) is secure.

According to the Product Overview Edition 08 2005 provide by Philips,
all of the LPC2100 series parts less 2194 is marked "Y" for Parallel
Programming (PP) feature column.

Client was told PP can read and program on-chip flash.  Philips (Jim
E) by email has advised me that I could use PP to re-load the on-chip
flash for LPC2105 parts that my students manage to kill just by bad
coding.

Client wants Philips to confirm that if the device is secured using
CRP, then PP cannot be used to access the on-chip flash.

Your say:
> A parallel programmer will not be able to read
> or program a secured device.

Q1: Can I tell client Philips has confirmed CRP is not voided by PP?

I am curious, what happens to a part when is CRP enabled, and if there
is no way to recover the part at all.

In the same Product Overview document referred to above, all of the
LPC2200 series parts that have external memory interface have a "-"
against the PP feature column.  If it was a "N", I would tell client
this means these devices do not support parallel programming.  I am
not sure what the "-" means.

If these devices cannot be parallel programming, how does the on-chip
flash gets loaded the first time, or after it has been corrupted?

Client was told that these parts are loaded (first time) by forcing
them to boot from external memory by pull downs on specific pins
during reset.

Q2: Would Philips confirm such methods cannot be used to defeat CRP?

I am curious how Philips loads the flash first time for these parts.

You make the statement:

> Oh yes, you, the user is always able to "undo" your
> security while running IAP but how would a "spy" be 
> ever able to run IAP (In application programming)

If the user can "undo" CRP, you must assume the "spy" can.

Security by obscurity (which attempts to use secrecy of design,
implementation, etc) to ensure security is not acceptable to the client.

As an example, Philips "secured" boot loader sector by keeping the
programing algorithms a secret.  My students killed two of my 2105
boards by accident.  I could not tell them what they should not do
because I did not know the programming algorithm.

I am sure there are many who have worked out the algorithm as I now
have.  How long do you think it takes for one of these persons to
publish the algorithm on the net, assuming this has yet to happen?

Jaya

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:
>
> Jaya,
> 
> I am truely sorry but I do not understand your point. A parallel 
> programmer will not be able to read or program a secured device. A 
> microcontroller that executes an external program can not be secured 
> because the external code can always be compromised. Booting from 
> external is not possible once the device is secured and programmed 
> to boot internally.
> 
> Did I miss something?  Oh yes, you, the user is always able 
> to "undo" your security while running IAP but how would a "spy" be 
> ever able to run IAP (In application programming). The devices you 
> mentioned also leave the option to reenable JTAG in your program, 
> again, chicken and egg, as the spy will not be able to alter your 
> program how can he enable JTAG. 
> 
> Philips Apps

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.