Lpc2000

Dear John

You dont even need to be a fan to find these discussions without a proof 
tiresome.
Ploticans and sometimes lawers behave this way, by simle repetition a 
accusation without
proof becomes truth.This worked even in the ancient Rome, f.e. Cicero 
against Catelina.
Fortunatly engineers are not infected by this strange virus ;-)

Cheers
Michael


>From: "John Heenan" <l10@...>
>Reply-To: lpc2000@yahoogroups.com
>To: lpc2000@yahoogroups.com
>Subject: [lpc2000] Re: re lpc2100_fan's objection to CRP thread
>Date: Tue, 14 Feb 2006 14:53:30 -0000
>
>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
> > >
>
>
>
>