Lpc2000

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
>
>Send instant messages to your online friends 
><http://au.messenger.yahoo.com>http://au.messenger.yahoo.com
>
>
>SPONSORED LINKS
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ>Microcontrollers 
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA>Microprocessor 
><http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw>Intel 
>microprocessors
><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw>Pic 
>microcontrollers
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000" 
> on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    * 
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-unsubscribe@yahoogroups.com 
>
>    *
>    *  Your use of Yahoo! Groups is subject to the 
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------