Lpc2000

The attacks on the integrity of the CRP are really, really tiresome.

Still nothing concrete, except now using (probably private) 
statements as credible from Philips that they themselves have 
acknowledged are incorrect and have apologised for.

If I was a member of Jaya's academic Department I would be in mortal 
fear of the Department receiving letters from the lawyers of Philips.

I wonder if Jaya would care to reveal where his research grants are 
coming from.

Fact 1. JTAG hardware operates independently. Nothing JTAG does, 
including reset signals, will make the slightest bit of difference 
unless the signals JTAG passes are not blocked and so are allowed to 
act. Simple invertor and OR logic gates are perfectly adequate to 
block signals.

Fact 2. The boot loader decides if CRP (Code Read Protection) is 
enabled and so decides if it will allow signals from JTAG to act.

Fact 3. Even if CRP is an afterthought, so what if it works.

Fact 4. A lot of contradictory statements from Philips have been 
quoted including an apology and clarification (P3) that parallel 
programming uses either JTAG and/or ISP.

Fact 5. Use of an incomplete statement (C1); admitted to be in 
a 'different context' that contradicts directly Philips apparently 
later clarification in Fact 3. Reuse of C1 as C5.


John Heenan


--- In lpc2000@yahoogroups.com, Sean <embeddedrelated@...> wrote:
>
> 
> Although I am enjoying this academic discussion, I am a little 
confused 
> here...  Pardon my ignorance in the matter.
> 
> Is the JTAG implementation hardware or software?
> 
>  From what I understand it's hardware, but then why then can a 
toasted boot 
> loader prevent JTAG from functioning?  Based on this statement it 
appears 
> that the boot loader is required to make JTAG function.  You (Jaya) 
said 
> that you have written and use your own boot loader.  Does JTAG work 
with 
> your boot loader?
> 
> If the boot loader is required to make JTAG function (and thus JTAG 
is 
> non-functional at power on) then it should be trivial to implement 
CRP in 
> the boot loader in a secure fashion.  The boot loader simply 
doesn't enable 
> the JTAG functionality unless CRP is disabled.
> 
> However all this discussion about how the boot loader will disable 
JTAG if 
> CRP is enabled (and thus leaves a window open to attack) implies 
that JTAG 
> is actually functional at power on, so why would a toasted boot 
loader 
> cause it to stop working if it is enabled before the boot loader 
even starts?
> 
> It seems to me that if Philips really wanted to make this secure 
JTAG would 
> simply be nonfunctional until the boot loader has kicked in and 
verified 
> that CRP is disabled.  Ergo I agree that CRP seems like some 
afterthought: 
> a hack around JTAG to pretend that they actually have some form of 
security 
> on the chip.
> 
> -- Sean
> 
> At 17:49 2/13/2006, you wrote:
> >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
> >