Could you also confirm you have no options to read a CRP enabled
device on your tester?
The gripe here is that client requirements are quite clear. The
client will not use a part unless the manufactur guarantees there are
no (known) hidden or undisclosed methods tha the manufacture has
chosen not to disclose that the "enemy" can use to read locked down
code.
The client did not say this explicitly, but it my guess that this
client thinks that if Philips chose not to disclose LPC flash
programming algorithm, it may well likewise chose not to disclose
methods or open holes in in the implementation that defeat CRP.
I know the client is happy with protection oferred in AVR device, and
is looking to LPC for other requirements, but the trust component is
not there yet in relation to Philips.
For this reason, I would suggest Philips put effort on this front in
relation to CRP feature if it wants LPC parts to be used in the same
league as AVR parts.
Regards,
Jaya
--- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...>
wrote: >
> Mauricio,
>
> with IAP calls you can not erase the bootloader, it protects itself
> as it knows where it is located.
>
> I can assure you we have an options to program the virgin device on
> a tester.
>
> Regards, Robert
Reply by Richard Duits●December 22, 20052005-12-22
The bootloader is updated by a program that is uploaded to the internal
ram. I guess this program contains the flash programming code itself and
it does not use the iap calls at any time.
--- In lpc2000@lpc2..., Mauricio Scaff <scaffm@g...> wrote: >
>
> > I can assure you we have an options to program the virgin device on
> > a tester.
> >
> Let's say that your answer is a little bit obscure. So my code is
> protected as far as no one knows what happens in that "tester" ?
It
> doesn't look like something very safe.
>
How can you catagorize it as not "very safe" without even knowing
what
a "tester" is?? A tester, like the HP3000, is often used to test
devices while they are still on the wafer prior to packaging. Devices
at that stage are far more accesible than they are after they are
packaged, and all you can get at are the pins or balls. It could also
program the device via access methods that become completely
unavailable after packaging. For instance, if the device is a "stacked
die" part, then it could be programed before the dice are even bonded
out. This is not to say that is what is actually happening, but just
to point out that making a judgement from a position of no knowledge
is not likely to be very profitable to anyone.
BTW, if you are assuming that what is happening is just hidden access
mechanisms on completed parts, then I would agree that you are
justified in worrying about security. "Security by obscurity"
always
fails eventually.
-- Dave
Reply by Steve Franks●December 22, 20052005-12-22
> Message: 10 > Date: Thu, 22 Dec 2005 20:58:17 +0100
> From: "Marko Pavlin (home)" <mp@mp@....>
> Subject: I Gotta Know
>
> I am not Elvis, but "I Gotta Know".
>
> Is here anyone dealing with wireless 802.15.4 on LPC21xx or
> even using
> Chipcon CC2420 with LPC21xx, or "I'll be one and only till
> the end of time"?
>
> Thank you!
> Marko
Marko,
I've been using the CC2420 for quite awhile on the AVR's, actually,
the
availability of GCC on the LPC and the existence of some template libs for
the CC2420 was the primary reason I started investigating the LPC's.
Steve
Reply by Joel Winarske●December 22, 20052005-12-22
> with IAP calls you can not erase the bootloader, it protects itself > as it knows where it is located.
How is a bootloader 'update' handled if IAP calls cannot erase the
bootloader?
> I can assure you we have an options to program the
virgin device on
> a tester.
Can any of these 'options' read a device?
Is CRP solely implemented in the software based bootloader?
Joel
Reply by Mauricio Scaff●December 22, 20052005-12-22
philips_apps wrote: > Mauricio,
>
> with IAP calls you can not erase the bootloader, it protects itself
> as it knows where it is located.
> Ok. It sounds good.
> I can assure you we have an options to program the
virgin device on
> a tester.
> Let's say that your answer is a little bit obscure. So my code is
protected as far as no one knows what happens in that "tester" ? It
doesn't look like something very safe.
Client : - Is my code secure in this device ?
Me : - Yes, of course. Noboby can read your code. Well, Philips can,
but they told me that they will never tell how to do that.... By the
way, may you give me your bank account and password please ?
> Regards, Robert
Mauricio
Reply by Marko Pavlin home●December 22, 20052005-12-22
I am not Elvis, but "I Gotta Know".
Is here anyone dealing with wireless 802.15.4 on LPC21xx or even using
Chipcon CC2420 with LPC21xx, or "I'll be one and only till the end of
time"?
Thank you!
Marko
Reply by philips_apps●December 22, 20052005-12-22
Mauricio,
with IAP calls you can not erase the bootloader, it protects itself
as it knows where it is located.
I can assure you we have an options to program the virgin device on
a tester.
Regards, Robert
--- In lpc2000@lpc2..., Mauricio Scaff <scaffm@g...> wrote: >
> If the parallell programming is done by the bootloader, and the serial > programming is done by the bootloader, and the
JTAG is controlled by the > bootloader, How the bootloader is programmed for
the first time (in > factory ) ????
>
> Another question:
> Is it possible to erase the bootloader using the provided IAP calls ? If > so, is there anyway to recover it ?
>
> Mauricio
>
> > Robert,
> >
> > fyi, parallel programming is possible but the only thing parallel is > > the databus, in the end the parallel
programmer again uses the
> > bootloader for programming.
> >
> > The other Robert
> >
> > --- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...> > > wrote:
> > >
> > > At 01:39 AM 12/22/05 +0000, jayasooriah wrote:
> > > >Was Philips misleading us about Code Read Protection?
> > > >
> > > >The preliminary user manual for LPC2119/2129/2194/2292/2294
dated > > 2004
> > > >May 03 in the section on CRP states:
> > > >
> > > > > When the code read protection is enabled the JTAG
debug
> > > > > port, external memory boot and the following ISP
commands
> > > > > are disabled:
> > > > >
> > > > > . Read Memory
> > > > > . Write to RAM
> > > > > . Go
> > > > > . Copy RAM to Flash
> > > > >
> > > > > The ISP commands mentioned above terminate with
return
> > > > > code CODE_READ_PROTECTION_ENABLED.
> > > > >
> > > > > The ISP erase command only allows erasure of all
user
> > > > > sectors when the code read protection is enabled.
> > > >
> > > >Philips stated (by way of poster dated Sat Dec 17, 2005 11:52 AM) > > > >that the purpose of CRP as:
> > > >
> > > > > Code Read Protection (CRP) was implemented with
intention
> > > > > to protect on-chip Flash content from preying eyes.
> > > >
> > > >It appears that Philips made these claims while it knew that
CRP > > can
> > > >be defeated by other methods, including parallel programming
or > > > >booting from external memory.
> > > >
> > > >1/ LPC parts without external memory interface support parallel > > > >programming. This method can be used
to read and write on- chip > > flash.
> > >
> > > I've seen the hints you provided on this but no real
evidence
> > yet. Since
> > > this appears to directly contradict what is on Philips Website
I > > remain to
> > > be convinced. You need to be able to show that the parts can be > > parallel
> > > programmed and that method of programming bypasses the CRP
> > > features. Certainly if parallel programming is possible it raises > > that as
> > > a possibility since presumably the boot loader would not be
> > involved.
> > >
> > > There is another possibility though and that is that you have been > > the
> > > victim of marketing manipulation of terms. It is quite possible > > that the
> > > references you have seen to parallel programming are just
> > indicators that
> > > the devices can be programmed off board with an appropriate
> > programmer and
> > > that programmer uses either the serial or JTAG ports to do the
> > programming.
> > >
> > >
> > > >2/ On LPC parts with external memory, it is possible to force the > > > >part to boot on external memory.
Code in external memory can
> > read and
> > > >write on-chip flash.
> > >
> > > Well they do claim that turning on CRP disables the ability to
> > boot from
> > > external memory. Do you have any evidence to the contrary? This > > does have
> > > the advantage of being easily tested. Have you tested it and if > > so what
> > > did you use for a test case? If not, why not? With a test case > > this would
> > > be easy to duplicate and verify.
> > >
> > > >If the above claims are not true, it would be a simple matter
for > > > >Philips to say so. The fact that
Philips has chosen to go quiet > > on
> > > >this issue seems to suggest the claims are indeed true.
> > >
> > > Hey give them a bit of a chance. They do, I think, need to
> > respond. If
> > > this is coming out of the blue they may need some time to figure > > out
> > > exactly what it is they are responding to. Also at this season
> > the people
> > > most able to respond may well be on vacation.
> > >
> > > Robert
> > >
> > > " 'Freedom' has no meaning of itself. There are
always
> > restrictions, be
> > > they legal, genetic, or physical. If you don't believe me,
try to > > chew a
> > > radio signal. " -- Kelvin Throop, III
> > > http://www.aeolusdevelopment.com/
> > >
> >
> >
> >
> >
> >
> >
> > SPONSORED LINKS
> > Microprocessor
> > <http://groups.yahoo.com/gads? t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+mi
crocontrollers&w451+microprocessor&c=4&s&.sig=tsVC-
J9hJ5qyXg0WPR0l6g> > > Microcontrollers
> > <http://groups.yahoo.com/gads? t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+
microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8X
q01nxwg> > > Pic microcontrollers
> > <http://groups.yahoo.com/gads? t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=
Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ
7c6LyBvUqVQ> > >
> > 8051 microprocessor
> > <http://groups.yahoo.com/gads? t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=P
ic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_H
VIlekkDP-A> > >
> >
> >
> > ----------------------------- ------- > > >.
> >
> >
> > ----------------------------- ------- >
Reply by Mauricio Scaff●December 22, 20052005-12-22
If the parallell programming is done by the bootloader, and the serial
programming is done by the bootloader, and the JTAG is controlled by the
bootloader, How the bootloader is programmed for the first time (in
factory ) ????
Another question:
Is it possible to erase the bootloader using the provided IAP calls ? If
so, is there anyway to recover it ?
Mauricio
> Robert,
>
> fyi, parallel programming is possible but the only thing parallel is
> the databus, in the end the parallel programmer again uses the
> bootloader for programming.
>
> The other Robert
>
> --- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...>
> wrote:
> >
> > At 01:39 AM 12/22/05 +0000, jayasooriah wrote:
> > >Was Philips misleading us about Code Read Protection?
> > >
> > >The preliminary user manual for LPC2119/2129/2194/2292/2294
dated
> 2004
> > >May 03 in the section on CRP states:
> > >
> > > > When the code read protection is enabled the JTAG debug
> > > > port, external memory boot and the following ISP commands
> > > > are disabled:
> > > >
> > > > . Read Memory
> > > > . Write to RAM
> > > > . Go
> > > > . Copy RAM to Flash
> > > >
> > > > The ISP commands mentioned above terminate with return
> > > > code CODE_READ_PROTECTION_ENABLED.
> > > >
> > > > The ISP erase command only allows erasure of all user
> > > > sectors when the code read protection is enabled.
> > >
> > >Philips stated (by way of poster dated Sat Dec 17, 2005 11:52
AM)
> > >that the purpose of CRP as:
> > >
> > > > Code Read Protection (CRP) was implemented with intention
> > > > to protect on-chip Flash content from preying eyes.
> > >
> > >It appears that Philips made these claims while it knew that
CRP
> can
> > >be defeated by other methods, including parallel programming or
> > >booting from external memory.
> > >
> > >1/ LPC parts without external memory interface support parallel
> > >programming. This method can be used to read and write on-chip
> flash.
> >
> > I've seen the hints you provided on this but no real evidence
> yet. Since
> > this appears to directly contradict what is on Philips Website I
> remain to
> > be convinced. You need to be able to show that the parts can be
> parallel
> > programmed and that method of programming bypasses the CRP
> > features. Certainly if parallel programming is possible it raises
> that as
> > a possibility since presumably the boot loader would not be
> involved.
> >
> > There is another possibility though and that is that you have been
> the
> > victim of marketing manipulation of terms. It is quite possible
> that the
> > references you have seen to parallel programming are just
> indicators that
> > the devices can be programmed off board with an appropriate
> programmer and
> > that programmer uses either the serial or JTAG ports to do the
> programming.
> >
> >
> > >2/ On LPC parts with external memory, it is possible to force
the
> > >part to boot on external memory. Code in external memory can
> read and
> > >write on-chip flash.
> >
> > Well they do claim that turning on CRP disables the ability to
> boot from
> > external memory. Do you have any evidence to the contrary? This
> does have
> > the advantage of being easily tested. Have you tested it and if
> so what
> > did you use for a test case? If not, why not? With a test case
> this would
> > be easy to duplicate and verify.
> >
> > >If the above claims are not true, it would be a simple matter
for
> > >Philips to say so. The fact that Philips has chosen to go quiet
> on
> > >this issue seems to suggest the claims are indeed true.
> >
> > Hey give them a bit of a chance. They do, I think, need to
> respond. If
> > this is coming out of the blue they may need some time to figure
> out
> > exactly what it is they are responding to. Also at this season
> the people
> > most able to respond may well be on vacation.
> >
> > Robert
> >
> > " 'Freedom' has no meaning of itself. There are
always
> restrictions, be
> > they legal, genetic, or physical. If you don't believe me, try
to
> chew a
> > radio signal. " -- Kelvin Throop, III
> > http://www.aeolusdevelopment.com/
>
>
> SPONSORED LINKS
> Microprocessor
>
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
>
<http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A
>
>
> >.
>
>
Reply by Tom Walsh●December 22, 20052005-12-22
jayasooriah wrote:
>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.
>
Good grief! The last time I had a "secure" part with an external bus,
I
proved that I could defeat the "security" by enabling the external ROM
and then reading the internal ROM. There was a problem with that part.
Have you done nothing but 'read'? Come on now, try it out, see if you
can break it. Spend some money, get a parallel programming setup, can
you break it??
Sheesh
TomW
>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@lpc2..., "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
>>
>
>Yahoo! Groups Links
