Lpc2000

Thank you Brendan for raising the question.  When one asks, one must be 
prepared to listen ...

>have you even considered ths remotest
>possibility that the reason Philips aren't replying to your
>outstanding question is not becuase they have something to hide

I did but in the final analysis my assessment is that it is quite (very) 
likely that Philips has lots to hide.  Read on if you want to know why.

This not a tutorial on risk assessment, or for that matter free advice, but 
an attempt to put some of the issues to be considered in proper perspective.

Facts relating to LPC
---------------------

F1:  LPC incorporate JTAG module for debugging purposes.

F2:  Interface to JTAG can be enabled or disabled by software.

Note: These apply just about every other ARM core there is in the market 
that does not have any security features whatsoever.  The LPC appears no 
different in this regard.

Philips came up with (quite clearly as an afterthought) the illusion called 
"Code Read Protection" (CRP) which it claims "was implemented with 
intention to protect on-chip flash content from preying eyes."  (I am using 
the term "illusion" here as it is used in operating systems.)

It appears CRP is a software abstraction based on F1 and F2 alone.  If this 
is the case, it must apply to just about every other arm core there is in 
the market.  As none of this have any such security features, more 
specifically any form of protection at all, one has to look at what 
features of LPC that the others do not have enables Phlips to claim CRP.

Note: The boot loader source is proprietary, and so Philips does not have 
to release what is it that they are claiming is different in LPC that 
enables their software "protect on-chip flash from preying eyes" and which 
similar software in the other ARM cores cannot do.

Facts relating to JTAG
----------------------

F3:  JTAG interface allows one to do just about anything (and more) from 
the outside that one can do by software inside the chip.  It is reasonable 
thus to question if JTAG can be used to break the software fence.

F4:  The JTAG public instruction set indicates what one can do through the 
interface.  It does not in however say (or give any hints as to) what one 
cannot do.  Indeed, there more things one can using designer's (reserved) 
private instruction set.

F5:  JTAG implementations are typically designed minimally so that they do 
what they are expected to do when fed with the correct input sequence.  It 
is most often the case that when an incorrect sequence is presented, what 
happens is undefined.

Note: Private instructions are private and hence Philips does not have to 
release what these are and what they do.

The boot loader is hence an intrinsic component of CRP.  To protect one's 
IP in on-chip flash based based on the CRP claim one has to include 
Philips, its contractors and/or partners, and anyone else involved in the 
design and development of the boot loader into the trust domain.

Some threats to CRP and how one could assess them:

T1: Parallel programming
------------------------

Cons:

C1: Claim by Philips (in response to query in a different context) (words 
to the effect used here): "if the boot loader is corrupt is possible even 
JTAG will not work ... thus the only way to reload the boot loader is by 
using a parallel programmer".

C2: Claim by Client(s): At least one other party has been advised by 
Philips that parallel programming can be used for production-loading code 
into on-chip flash using commercial off-the-shelf programmers.

C3: Philips Production Selection Guide indicates parallel programming (the 
type that is available for the other families) is also available for LPC.

C4: Claim by Philips: "I can assure you we have an options to program the 
virgin device on a tester."

C5: Claim by Philips: "Parallel programming for ARM based micros just means 
that the device can be mass programmed in a commercial programmer." [cf P3]

Pros:

P1: Philips chose to alert (in a queer way though) that its initial advice 
relating to parallel programming in another context was a "mistake").

P2: Claim by Philips: "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".

P3: Claim by Philips: "We are sorry for not making clear what is meant by 
'Parallel Programming' for ARM based micros. Parallel programming for ARM 
based micros just means that the device can be mass programmed in a 
commercial programmer. Parallel programmers still use JTAG and/or ISP and 
go through the bootloader IAP routines to program the on-chip flash."

Risk: high

T2: JTAG - Embedded ICE Logic
-----------------------------

Cons:

C1: Defensive code in boot loader at the expense of makng boot loader less 
secure suggests it is possible to break this within fourth instructions.

C2: Non authoritative posts in this forum point to no conclusion on JTAG 
clocking rates (is it at TCK or less than TCK; is it synchronised or do we 
need external synchronisation;).

C3: Non authoritative posts in this forum point to number of cycles 
required to be well above that it takes four instructions to execute.

Pros:

P1: Non authoritative posts in this forum suggests number of TCKs required 
to seize control compared is much larger than the three instruction cycles 
as it stands in the latest versions of boot loader.

P2: Claim by Philips (on slow clocking): "No, the clock for JTAG and the 
CPU are syncronized on these devices."

P3: Claim by Philips (on cycles needed): "There are not enough JTAG clocks 
to control the CPU before the JTAG gets disabled by the bootloader software."

Risk: low to medium

JTAG is "enabled" by the software only when CRP is disabled, but the 
software that does this is being loaded by JTAG.  How is JTAG enabled if 
there is no software to enable it in the first place?

If it is indeed true that the LPC design is such that it must discarded if 
for some reason its boot loader is corrupt, this does not reflect well on 
the design.


T3: Boot loader Exploits
------------------------

Cons:

C1:  Explanation of the "T" and "G" test features that made their way to 
the field does point to absence (or failure) of processes and/or measures 
that ensure quality of boot loader that one is required to trust if one is 
to accept that CRP works.

C2:  There are no assurances whatsoever that a) the boot loader does what 
it is supposed to do; b) the boot loader does not do anything it is not 
supposed to do.

[The above is a rudimentary requirement for any security assessment.]

C3:  The refusal to acknowledge CSI bug does not point to any bug 
management process in place to mitigate threats to security.

C4:  False claim by Philips: "Bottom line: ... Even if a code is 
successfully loaded into the on-chip RAM using this ("T") command, a "G" 
command has to be issued."

Pros:

[I am not able to come up with anything I would list here based on what I 
have been able to examine: the reverse engineered source code.]

Risk: high

As I said, this is not a forma threat assessment which would include a full 
list of threats and their assessment.

Summary: CRP is not what it is claimed to be, and the costs for relying on 
CRP to protect ones IP can be high if one does not make a proper threat 
assessment.

Jaya  

Send instant messages to your online friends http://au.messenger.yahoo.com