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

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.
>
>
>----------

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
> >

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
> > >
>
>
>
>

Michael,

I couldn't agree more. Unfortunately, it seems to be common these 
days to forgo the scientific method in favour of the presence of 
conspiracy as an answer for everything. The methodology is simple 
enough:

- make a claim, unsupported by any direct evidence. For 
example, "LPC2000 CRP is insecure", "Apollo was a fraud: man never 
walked on the moon", "the Pyramids were built by Aliens rather than 
an ancient Egyptian culture".

- quote some spurious "facts" (that may or may not be true in 
themselves), that given a particular world view seem to support the 
claim (when in fact there's usually a far more plausible explanation 
for each of the facts quoted)

- wrap up the "facts" in pseudo-scientific language and apparent 
methodology to create a semblance of authority

- explain gaps in evidence for the claim as part of a conspiracy to 
hide the "truth"

- hold the trump card in that you're asking anyone opposed to you to 
prove something that can't be proven (you can never demonstrate that 
CRP is secure; only demonstrate that it is insecure)

Unfortunately, guys, we're on to a loosing battle in trying to use 
facts or evidence to counter this: since the claim doesn't rely on 
them, they'll be ignored or dismissed. Best chill out I think, and 
move onto something else of more relevance to the group as a whole. 

By the way, I'm willing to be proven wrong on this: all we need is 
some evidence.  

One final point, Jaya, you've implied that you work as an academic: 
are you willing to say where? 

Brendan

--- In lpc2000@yahoogroups.com, "Michael Rubitschka" 
<rubitschka@...> wrote:
>
> 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
> >
> >

John, you seem to have some of your facts wrong.

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
 > 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.

Could you explain what your point is in the above paragraph please.  I read 
it a few times but cannot make out what you intend to point out.

 > 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.

Wrong.  JTAG signals are enabled or disabled on reset by pulling specific 
GPIO pins low on boot [see notes on page 120 of 2294 user manual]. The boot 
loader *disables* it, and then at a later time enables it if it thinks that 
CRP is not enabled.

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

The problem is afterthoughts like this are more likely to fail.  In this 
case, where the hardware designers have not included security features, it 
is usually not possible to add this as an afterthought using 
software.  Indeed, if it works for LPC, then it would also work for the 
other ARM cores ... but ... one wonders none of the others are claiming 
they have CRP.

 > 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.

I noticed this too, and this is perhaps the main reason why I have rated 
Philips as not credible.

 > 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.

When you examine evidence, there is the notion of "contemporary" evidence 
for which I give more weight, than further evidence in the process of 
defensive examination that contradicts it.  This is quite common practice 
in industry.

It is quite possible that had I posed the first question in relation to CRP 
issues, I would have got quite a different answer and the availability of 
parallel programming option would not have been raised at all.

 > John Heenan

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

John, you seem to have some of your facts wrong.

[Apologies if this comes up twice -- my email post seems to have failed.]

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
> 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.

Could you explain what your point is in the above paragraph please.  I
read it a few times but cannot make out what you intend to point out.

> 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.

Wrong.  JTAG signals are enabled or disabled on reset by pulling
specific GPIO pins low on boot [see notes on page 120 of 2294 user
manual]. The boot loader *disables* it, and then at a later time
enables it if it thinks that CRP is not enabled.

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

The problem is afterthoughts like this are more likely to fail.  In
this case, where the hardware designers have not included security
features, it is usually not possible to add this as an afterthought
using software.  Indeed, if it works for LPC, then it would also work
for the other ARM cores ... but ... one wonders none of the others are
claiming they have CRP.

> 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.

I noticed this too, and this is perhaps the main reason why I have
rated Philips as not credible.

> 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.

When you examine evidence, there is the notion of "contemporary"
evidence for which I give more weight, than further evidence in the
process of defensive examination that contradicts it.  This is quite
common practice in industry.

It is quite possible that had I posed the first question in relation
to CRP issues, I would have got quite a different answer and the
availability of parallel programming option would not have been raised
at all.

> John Heenan

Good try Brendan, but not good enough.  Look at the arguments, and if
you cannot fault the argument, just accept it rather than faulting the
person who puts forward the argument.

[Apologies if this post comes up twice, my first attempt via email
seems to have failed.]

--- In lpc2000@...m, "brendanmurphy37" <brendan.murphy@...>
wrote:
> One final point, Jaya, you've implied that you work as an academic: 
> are you willing to say where?

jayasooriah wrote:

>>One final point, Jaya, you've implied that you work as an academic: 
>>are you willing to say where? 
>>
Not too hard to find out: http://snipurl.com/mku1

It's a real pity that the signal to noise ratio on this list seems to 
have dropped so low as a result of all this nonsense. The argument still 
seems to concern a non-issue: if IP protection is really *that* 
important to a designer, it would be a bit foolish to depend on 
something implemented in software by a chipmaker in any case. For the 
vast majority of LPC users, I suspect that this is not an issue. The 
others can choose a different chip.

Frankly I'm impressed that Robert from Philips takes the time to watch 
this list at all; if I were in his position, the accusations of deceit 
and incompetence would have made me leave a long time ago.

Thank goodness for killfiles -- there are more interesting/important 
battles to read about than this.


Stuart
Mobile Engineering
Yahoo! Europe

I suppose you think you are very clever Stuart ... like Brendan, if
you cannot fault the argument, go after the person ... good work!

--- In lpc2000@yahoogroups.com, Stuart Wallace <swallace@...> wrote:

> >>One final point, Jaya, you've implied that you work as an academic: 
> >>are you willing to say where? 
> >>
> Not too hard to find out: http://snipurl.com/mku1

jayasooriah wrote:

>I suppose you think you are very clever Stuart ... like Brendan, if
>you cannot fault the argument, go after the person ... good work!
>  
>
 > Could you explain what your point is in the above paragraph please. I
 > read it a few times but cannot make out what you intend to point out.

Jaya, apologies for the implied attack on your personal credibility: as 
has been pointed out, I should have checked beforehand. 

As for the arguments, I really don't see anyhing other than a claim 
("CRP is insecure") with no supporting evidence (as in a mechanism that 
might be used to overcome it). A set of "facts" that may or may not be 
either true or relevant does not an argument make.

I'm well aware that there is no such thing as absolute security. I do 
think though that you do your cause no good at all by labouring points 
that can't really be addressed given the information available. It's 
impossible to do a full review of security threats on the information 
publicly available: making (to my mind invalid) assumptions 
about "hidden" commands etc. builds any such analysis on sand: it just 
won't stand up.

I think Philips are right not to expose details of their IC's internals 
to an open forum, or to comment further. They've made certain 
statements about how and why the parts are as they are which, in the 
absence of any evidence to the contrary, should be taken at face value. 
If required, I'm sure they would share appropriate additional 
information with concenred customers under NDA. 

If you can't get the degree of re-assurance you feel you need, either 
based on publicly available information, or through an NDA with 
Philips, then you can make your own mind up and go elsewhere. There's 
little point though in berating them continuously on this forum when 
they've absolutely no reason to respond further. As I said, I think 
you're doing yourself no good at all in persisting: I for one began to 
assume you were way out there on the crank side of life, rather than an 
academic with a record deserving some serious respect.

Apologies again for the implied questioning of your credentials on my 
last post: it was way out of line.

Regards
Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:

>
> Good try Brendan, but not good enough.  Look at the arguments, and if
> you cannot fault the argument, just accept it rather than faulting the
> person who puts forward the argument.
> 
> [Apologies if this post comes up twice, my first attempt via email
> seems to have failed.]
> 
> --- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@>
> wrote:
> > One final point, Jaya, you've implied that you work as an academic: 
> > are you willing to say where?
>

Please Guys .... if you cant add some technical detail butt out.
This reply to this tortured thread breaks my own request - but NOTHING
statements like
"If you dont like the security use something else - becasue only amateurs
who create no value in their IP use LPC2000 chips"
such as this one from Mr Stuart Wallace is silly in the extreme.
Im sure Philips wont like to read it Stuart.

I for one am trying to load tricky algorithmic stuff to treat spinal trauma
patients - and I dont like the idea that someone can read my implementation
and copy it - nor the implication someone can change it if they can
reprogram the chip. People doing POS work and WIFI stuff must feel the same.

I hope you Understand jaya is a respected academic and I hope his arguments
stimulate Philips to supply a detailed assessment of the present status of
their security.
All the dribble about it not being important is most unprofessional and not
of the quality we want on this forum.

I sincerely hope Philips defeat Jayas detailed argument - and perhaps Jaya
hopes he is wrong also - because we like this chip series and respect
Philips efforts.

But to KNOW is to be secure that one makes the correct decisions.

Thats why Jayas efforts are important for us all.

Rgds
DonW

----- Original Message ----- 

From: "Stuart Wallace" <swallace@...-inc.com>
To: <lpc2000@yahoogroups.com>
Sent: Wednesday, February 15, 2006 11:39 PM
Subject: [lpc2000] Re: lpc2100_fan`s objection to CRP thread


> jayasooriah wrote:
>
> >>One final point, Jaya, you've implied that you work as an academic:
> >>are you willing to say where?
> >>
> Not too hard to find out: http://snipurl.com/mku1
>
> It's a real pity that the signal to noise ratio on this list seems to
> have dropped so low as a result of all this nonsense. The argument still
> seems to concern a non-issue: if IP protection is really *that*
> important to a designer, it would be a bit foolish to depend on
> something implemented in software by a chipmaker in any case. For the
> vast majority of LPC users, I suspect that this is not an issue. The
> others can choose a different chip.
>
> Frankly I'm impressed that Robert from Philips takes the time to watch
> this list at all; if I were in his position, the accusations of deceit
> and incompetence would have made me leave a long time ago.
>
> Thank goodness for killfiles -- there are more interesting/important
> battles to read about than this.
>
>
> Stuart
> Mobile Engineering
> Yahoo! Europe
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

Don Williams wrote:

>Please Guys .... if you cant add some technical detail butt out.
>This reply to this tortured thread breaks my own request - but NOTHING
>statements like
>"If you dont like the security use something else - becasue only amateurs
>who create no value in their IP use LPC2000 chips"
>such as this one from Mr Stuart Wallace is silly in the extreme.
>Im sure Philips wont like to read it Stuart.
>  
>
You're absolutely right, Don. I certainly didn't mean to imply that only 
amateurs use LPC chips because I know this isn't true. My point was that 
the level of effort required to get round the protection seems very 
significant, assuming it can be defeated at all. I definitely don't mean 
to cheapen any of the work done by anyone on this list. I guess I'm just 
rather frustrated with the direction this thread has taken. I therefore 
will indeed butt out!

Again, apologies for a poor choice of words -- I hope this debate gets 
resolved one way or another.


Stuart

John, 

> Thanks Jaya for demonstrating you cannot tell the difference between  
> a break pedal and a break pad. 

I assume this "break pedal" and "break pad" are your own inventions?
Most right-thinking people know what a brake pedal and brake pad is.
:-)  Sorry, couldn't resist.

-- Paul.

I don't believe I have got any facts wrong. The best interpretation 
is that Jaya is very naive and has no idea just how deficient his 
knowledge of electronics and the ARM architecture is and has no real 
experience of how a support system works.

Below is probably a normal commencement to a genuine support issue.

1) Notify a problem
2) Expect to get a stock reply pulled from a support database from an 
excessively polite overworked junior level support person who is not 
very knowledgeable and is desperate to get a good feedback rating.
3) If the stock reply does not answer the issue, try and clearly 
explain the problem again and ensure the problem can be replicated 
with information you give. Keep fingers crossed.
4) Hope the problem will be escalated and that feedback will be 
received.

My guess is that Jaya's supposed problem eventually made its way to 
someone who had real knowledge and insight, saw the correspondence, 
gave correct information to the support person, realised Jaya has no 
idea of what he is talking about and realised the support person  
pulled the wrong information out. If this were the circumstances then 
Philips had no real choice except to apologise.

The point here is that IT IS NORMAL TO EXPECT UNRELIABLE INFORMATION 
in private communications from big companies. 

What is really sad is that there is probably some junior support 
person with a black mark in his file cursing they had the misfortune 
to receive confused ramblings from someone without any real insight.

Thanks Jaya for demonstrating you cannot tell the difference between  
a break pedal and a break pad. My guess is that you won't even 
understand the analogy I have made.

John Heenan

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> John, you seem to have some of your facts wrong.
> 
> --- In lpc2000@yahoogroups.com, "John Heenan" <l10@> wrote:
>  > 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.
> 
> Could you explain what your point is in the above paragraph 
please.  I read 
> it a few times but cannot make out what you intend to point out.
> 
>  > 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.
> 
> Wrong.  JTAG signals are enabled or disabled on reset by pulling 
specific 
> GPIO pins low on boot [see notes on page 120 of 2294 user manual]. 
The boot 
> loader *disables* it, and then at a later time enables it if it 
thinks that 
> CRP is not enabled.
> 
>  > Fact 3. Even if CRP is an afterthought, so what if it works.
> 
> The problem is afterthoughts like this are more likely to fail.  In 
this 
> case, where the hardware designers have not included security 
features, it 
> is usually not possible to add this as an afterthought using 
> software.  Indeed, if it works for LPC, then it would also work for 
the 
> other ARM cores ... but ... one wonders none of the others are 
claiming 
> they have CRP.
> 
>  > 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.
> 
> I noticed this too, and this is perhaps the main reason why I have 
rated 
> Philips as not credible.
> 
>  > 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.
> 
> When you examine evidence, there is the notion of "contemporary" 
evidence 
> for which I give more weight, than further evidence in the process 
of 
> defensive examination that contradicts it.  This is quite common 
practice 
> in industry.
> 
> It is quite possible that had I posed the first question in 
relation to CRP 
> issues, I would have got quite a different answer and the 
availability of 
> parallel programming option would not have been raised at all.
> 
>  > John Heenan
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>

Hello,

On Tuesday 28 February 2006 14:31, John Heenan wrote:
> I don't believe I have got any facts wrong. The best interpretation
> is that Jaya is very naive and has no idea just how deficient his
> knowledge of electronics and the ARM architecture is and has no real
> experience of how a support system works.
>

You've listed a number of facts, and at least the second one (JTAG 
enabled/disabled after reset) was definitely wrong - when Jaya said that "you 
seem to have some of your facts wrong" he's perfectly right. Leaving this out 
of your reply and instead running a personal attack on Jaya seems rather 
unfair.

> ...
>
> John Heenan

Regards,

Dominic

No Dominic. My facts are not wrong. Below is what I stated and what 
Jaya replied. I asserted in Fact 2 that CRP decides if signals from 
JTAG will be allowed to act. This assumes JTAG is enabled and 
attempting to pass signals. Surely this is clear. I did not state 
signals to JTAG (from a debugger for example), I stated signals from 
JTAG, which in the context of Fact 1 clearly means bus signals.

I never stated CRP enables or disables JTAG. JTAG electronics 
operates independently. JTAG can be enabled and spinning uselessly 
because CRP has not enabled Debug.

I will not accept my comments are unfair. If someone posts to a group 
and imply a level of knowledge they do not possess then it is 
appropriate and fair to point this out. If you regard it a personal 
attack, that is not my problem, it still does not mean the comments 
are inappropriate. 

I have no intention of giving lessons in basic electronics. Yes I am 
aware you have put on the web a rather lengthy document concerned 
with JTAG.

I personally am really fed up the damaging effects of the poor level 
of insight of self proclaimed experts.

John Heenan


>  > 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.
> 
> Could you explain what your point is in the above paragraph 
please.  I read 
> it a few times but cannot make out what you intend to point out.
> 
>  > 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.
> 
> Wrong.  JTAG signals are enabled or disabled on reset by pulling 
specific 
> GPIO pins low on boot [see notes on page 120 of 2294 user manual]. 
The boot 
> loader *disables* it, and then at a later time enables it if it 
thinks that 
> CRP is not enabled.


--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@...> wrote:
>
> Hello,
> 
> On Tuesday 28 February 2006 14:31, John Heenan wrote:
> > I don't believe I have got any facts wrong. The best 
interpretation
> > is that Jaya is very naive and has no idea just how deficient his
> > knowledge of electronics and the ARM architecture is and has no 
real
> > experience of how a support system works.
> >
> 
> You've listed a number of facts, and at least the second one (JTAG 
> enabled/disabled after reset) was definitely wrong - when Jaya said 
that "you 
> seem to have some of your facts wrong" he's perfectly right. 
Leaving this out 
> of your reply and instead running a personal attack on Jaya seems 
rather 

> unfair.
> 
> > ...
> >
> > John Heenan
> 
> Regards,
> 
> Dominic
>

Eventually squabbling children and crazy people need to be told to be 
quite or go away.

This is taking up a lot of the newsgroup and those interested 
continueing this bickering should exchange emails or use the 'chat' 
feature.  Perhaps you have been wronged but someones comments, but 
you will never agree so why keep this up? If you have such a low 
opinion of those involved then why engage them in aurgument?? 

Notice that no one is coming to the defence of anyone involved in 
these little spats.  

Also notice that all of the comments of late about this thread 
contain the same simple message - time to stop. 

Ian Scanlon


--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
>
> No Dominic. My facts are not wrong. Below is what I stated and what 
> Jaya replied. I asserted in Fact 2 that CRP decides if signals from 
> JTAG will be allowed to act. This assumes JTAG is enabled and 
> attempting to pass signals. Surely this is clear. I did not state 
> signals to JTAG (from a debugger for example), I stated signals 
from 
> JTAG, which in the context of Fact 1 clearly means bus signals.
> 
> I never stated CRP enables or disables JTAG. JTAG electronics 
> operates independently. JTAG can be enabled and spinning uselessly 
> because CRP has not enabled Debug.
> 
> I will not accept my comments are unfair. If someone posts to a 
group 
> and imply a level of knowledge they do not possess then it is 
> appropriate and fair to point this out. If you regard it a personal 
> attack, that is not my problem, it still does not mean the comments 
> are inappropriate. 
> 
> I have no intention of giving lessons in basic electronics. Yes I 
am 
> aware you have put on the web a rather lengthy document concerned 
> with JTAG.
> 
> I personally am really fed up the damaging effects of the poor 
level 
> of insight of self proclaimed experts.
> 
> John Heenan
> 
> 
> >  > 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.
> > 
> > Could you explain what your point is in the above paragraph 
> please.  I read 
> > it a few times but cannot make out what you intend to point out.
> > 
> >  > 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.
> > 
> > Wrong.  JTAG signals are enabled or disabled on reset by pulling 
> specific 
> > GPIO pins low on boot [see notes on page 120 of 2294 user 
manual]. 
> The boot 
> > loader *disables* it, and then at a later time enables it if it 
> thinks that 
> > CRP is not enabled.
> 
> 
> --- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@> wrote:
> >
> > Hello,
> > 
> > On Tuesday 28 February 2006 14:31, John Heenan wrote:
> > > I don't believe I have got any facts wrong. The best 
> interpretation
> > > is that Jaya is very naive and has no idea just how deficient 
his
> > > knowledge of electronics and the ARM architecture is and has no 
> real
> > > experience of how a support system works.
> > >
> > 
> > You've listed a number of facts, and at least the second one 
(JTAG 
> > enabled/disabled after reset) was definitely wrong - when Jaya 
said 

> that "you 
> > seem to have some of your facts wrong" he's perfectly right. 
> Leaving this out 
> > of your reply and instead running a personal attack on Jaya seems 
> rather 
> > unfair.
> > 
> > > ...
> > >
> > > John Heenan
> > 
> > Regards,
> > 
> > Dominic
> >
>

Again it's time to stop...take your own advice about self proclaimed 
experts!!

[Non-text portions of this message have been removed]

Hello John,

Sorry if I misinterpreted what you wanted to claim with "fact 2", but I'm 
still having trouble understanding what you mean. Actually, both 1 and 2 seem 
a bit confusing, just as the first paragraph of your last posting. I'm not 
sure if you really understood everything as well as you believe.

Enabling/disabling JTAG and debug (these two are the same) is done by way of 
PINSEL2, which decides if the corresponding pins are used as JTAG or GPIO. 
You say you didn't want to state that CRP enables/disables JTAG, but that's 
just what it does.
Not the bus signals are being blocked, but the JTAG signals - the manual says 
that internal multiplexers decide to which peripherals the pins are routed, 
depending on the PINSEL registers.

I didn't reply to this discussion for several weeks, after it became obvious 
to me that CRP works as long as the bootloader is reasonably free of bugs. 
Even if such a bug exists, it can be easily fixed by Philips, so this isn't 
criticial.

It was quite easy for me to ignore these threads, and look for other 
interesting stuff on this list - I don't understand why others just can't do 
the same, but insist on requesting this to be stopped. The recent amount of 
"please stop" postings is just as annoying as the continued discussion of the 
matter itself.

Regards,

Dominic

On Tuesday 28 February 2006 19:01, John Heenan wrote:
> No Dominic. My facts are not wrong. Below is what I stated and what
> Jaya replied. I asserted in Fact 2 that CRP decides if signals from
> JTAG will be allowed to act. This assumes JTAG is enabled and
> attempting to pass signals. Surely this is clear. I did not state
> signals to JTAG (from a debugger for example), I stated signals from
> JTAG, which in the context of Fact 1 clearly means bus signals.
>
> I never stated CRP enables or disables JTAG. JTAG electronics
> operates independently. JTAG can be enabled and spinning uselessly
> because CRP has not enabled Debug.
>
> I will not accept my comments are unfair. If someone posts to a group
> and imply a level of knowledge they do not possess then it is
> appropriate and fair to point this out. If you regard it a personal
> attack, that is not my problem, it still does not mean the comments
> are inappropriate.
>
> I have no intention of giving lessons in basic electronics. Yes I am
> aware you have put on the web a rather lengthy document concerned
> with JTAG.
>
> I personally am really fed up the damaging effects of the poor level
> of insight of self proclaimed experts.
>
> John Heenan

I feel like I am being expected to answer to prima donnas who are 
affronted at the suggestion their beautiful abstract creations might 
be sullied by dirty greasy real things under the bonnet, that it is 
beneath their dignity to be expected to have knowledge of. You can 
just feel the 'hurt', after all I am now expected to explain the 
obvious.

What is very clear is that there is an appalling lack of good sound 
electronic and architectural knowledge from participants in the 
group. If there was sound knowledge then these guys (Jaya and 
Dominic) would never have got away with theie pseudo discussions, 
wrapped up in pseudo educated 'consultancy speak'.

There is a clear need for a document that explains the very basics. I 
wish I had time to do this. I don't. It is not my job. It is not the 
job of Philips, their job is to sell excellent prodcuts. It is the 
job of educators or researchers, in fact those who are doing the very 
undermining.

JTAG and debug are NOT the same. For those who are educated the 
meaning of the word debug is made clear by the context. In the 
context of CRP, debug clearly means enabling the debug bus signal to 
act, which JTAG, if enabled, may be attempting to assert. Lack of 
real educated insight is giving rise to confusion that should not 
exist and I should not be expected to clarify, particularly to those 
who claim or imply expertise. Clearly debug can also mean JTAG, but 
in a different context.

John Heenan

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@...> wrote:
>
> Hello John,
> 
> Sorry if I misinterpreted what you wanted to claim with "fact 2", 
but I'm 
> still having trouble understanding what you mean. Actually, both 1 
and 2 seem 
> a bit confusing, just as the first paragraph of your last posting. 
I'm not 
> sure if you really understood everything as well as you believe.
> 
> Enabling/disabling JTAG and debug (these two are the same) is done 
by way of 
> PINSEL2, which decides if the corresponding pins are used as JTAG 
or GPIO. 
> You say you didn't want to state that CRP enables/disables JTAG, 
but that's 
> just what it does.
> Not the bus signals are being blocked, but the JTAG signals - the 
manual says 
> that internal multiplexers decide to which peripherals the pins are 
routed, 
> depending on the PINSEL registers.
> 
> I didn't reply to this discussion for several weeks, after it 
became obvious 
> to me that CRP works as long as the bootloader is reasonably free 
of bugs. 
> Even if such a bug exists, it can be easily fixed by Philips, so 
this isn't 
> criticial.
> 
> It was quite easy for me to ignore these threads, and look for 
other 
> interesting stuff on this list - I don't understand why others just 
can't do 
> the same, but insist on requesting this to be stopped. The recent 
amount of 
> "please stop" postings is just as annoying as the continued 
discussion of the 
> matter itself.
> 
> Regards,
> 
> Dominic
> 
> On Tuesday 28 February 2006 19:01, John Heenan wrote:
> > No Dominic. My facts are not wrong. Below is what I stated and 
what
> > Jaya replied. I asserted in Fact 2 that CRP decides if signals 
from
> > JTAG will be allowed to act. This assumes JTAG is enabled and
> > attempting to pass signals. Surely this is clear. I did not state
> > signals to JTAG (from a debugger for example), I stated signals 
from
> > JTAG, which in the context of Fact 1 clearly means bus signals.
> >
> > I never stated CRP enables or disables JTAG. JTAG electronics
> > operates independently. JTAG can be enabled and spinning uselessly
> > because CRP has not enabled Debug.
> >
> > I will not accept my comments are unfair. If someone posts to a 
group
> > and imply a level of knowledge they do not possess then it is
> > appropriate and fair to point this out. If you regard it a 
personal
> > attack, that is not my problem, it still does not mean the 
comments
> > are inappropriate.
> >
> > I have no intention of giving lessons in basic electronics. Yes I 
am
> > aware you have put on the web a rather lengthy document concerned
> > with JTAG.
> >
> > I personally am really fed up the damaging effects of the poor 
level

> > of insight of self proclaimed experts.
> >
> > John Heenan
>

From someone who does not know the difference between "break" and "brake", 
I must say you have considerable talent in prefacing you misguided claims 
and false statements with insults and abuses.

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
 >
 > I feel like I am being expected to answer to prima donnas who are
 > affronted at the suggestion their beautiful abstract creations might
 > be sullied by dirty greasy real things under the bonnet, that it is
 > beneath their dignity to be expected to have knowledge of. You can
 > just feel the 'hurt', after all I am now expected to explain the
 > obvious.
 >
 > What is very clear is that there is an appalling lack of good sound
 > electronic and architectural knowledge from participants in the
 > group. If there was sound knowledge then these guys (Jaya and
 > Dominic) would never have got away with theie pseudo discussions,
 > wrapped up in pseudo educated 'consultancy speak'.
 >
 > There is a clear need for a document that explains the very basics. I
 > wish I had time to do this. I don't. It is not my job. It is not the
 > job of Philips, their job is to sell excellent prodcuts. It is the
 > job of educators or researchers, in fact those who are doing the very
 > undermining.
 >
 > JTAG and debug are NOT the same. For those who are educated the
 > meaning of the word debug is made clear by the context. In the
 > context of CRP, debug clearly means enabling the debug bus signal to
 > act, which JTAG, if enabled, may be attempting to assert. Lack of
 > real educated insight is giving rise to confusion that should not
 > exist and I should not be expected to clarify, particularly to those
 > who claim or imply expertise. Clearly debug can also mean JTAG, but
 > in a different context.
 >
 > John Heenan

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

Insulting me because you got something wrong seems a bit cheap, so I snipped 
these parts...

> JTAG and debug are NOT the same. For those who are educated the
> meaning of the word debug is made clear by the context. In the
> context of CRP, debug clearly means enabling the debug bus signal to
> act, which JTAG, if enabled, may be attempting to assert. Lack of
> real educated insight is giving rise to confusion that should not
> exist and I should not be expected to clarify, particularly to those
> who claim or imply expertise. Clearly debug can also mean JTAG, but
> in a different context.
>
As far as Philips LPC2xxx chips are concerned, debug and JTAG _are_ the same. 
There's no boundary scan implemented on the LPCs, only the debug scan chains 
that are part of the ARM7TDMI-S core. When CRP is enabled, JTAG/Debug doesn't 
work.

> John Heenan

Regards,

Dominic

Could you guys please leave my name out of this dead-beaten thread, 
and may even be, let it RIP.

PLEASE, Bob

>> >JTAG and debug are NOT the same. For those who are educated the
 >> meaning of the word debug is made clear by the context. In the
 >> context of CRP, debug clearly means enabling the debug bus signal to
 >> act, which JTAG, if enabled, may be attempting to assert. Lack of
 >> real educated insight is giving rise to confusion that should not
 >> exist and I should not be expected to clarify, particularly to those
 >> who claim or imply expertise. Clearly debug can also mean JTAG, but
 >> in a different context.
 >>

As far as Philips LPC2xxx chips are concerned, debug and JTAG _are_ the 
same.
There's no boundary scan implemented on the LPCs, only the debug scan 
chains
that are part of the ARM7TDMI-S core. When CRP is enabled, JTAG/Debug 
doesn't
work. <<

Actually, for once, I can see John's reasoning. The way I understand it. 
the JTAG is just the interface, which happens to carry the signals from 
the debug unit. It could be called the Philanium Doggle Whack interface 
and have a 1,000 bit wide interface, but still be carrying the same 
debug information. It's possibly like calling TCP/IP Ethernet. Just 
because Ethernet normally carries TCP/IP doesn't mean it always is.

On Thursday 09 March 2006 01:29, Robert Wood wrote:
>  >> >JTAG and debug are NOT the same. For those who are educated the
>  >>
>  >> meaning of the word debug is made clear by the context. In the
>  >> context of CRP, debug clearly means enabling the debug bus signal to
>  >> act, which JTAG, if enabled, may be attempting to assert. Lack of
>  >> real educated insight is giving rise to confusion that should not
>  >> exist and I should not be expected to clarify, particularly to those
>  >> who claim or imply expertise. Clearly debug can also mean JTAG, but
>  >> in a different context.
>
> As far as Philips LPC2xxx chips are concerned, debug and JTAG _are_ the
> same.
> There's no boundary scan implemented on the LPCs, only the debug scan
> chains
> that are part of the ARM7TDMI-S core. When CRP is enabled, JTAG/Debug
> doesn't
> work. <<
>
> Actually, for once, I can see John's reasoning. The way I understand it.
> the JTAG is just the interface, which happens to carry the signals from
> the debug unit. It could be called the Philanium Doggle Whack interface
> and have a 1,000 bit wide interface, but still be carrying the same
> debug information. It's possibly like calling TCP/IP Ethernet. Just
> because Ethernet normally carries TCP/IP doesn't mean it always is.

Yeah, but I don't think that's what he means, when he insists on telling that 
"In the context of CRP, debug clearly means enabling the debug bus signal to 
act", which is simply not the way LPCs work. This whole thread and its 
predecessors are about CRP. I've tried to explain to him that CRP works by 
having the JTAG/Debug pins operate either as a GPIO pins or as JTAG pins, but 
obviously he doesn't care, and is only interested in bashing people.

Actually, Philips themself call the pins "Debug" port. For example in the 
LPC2119, 2129, 2194, 2292 and 2294 user manual on page 120, they describe pin 
P1.26 (RTCK): "LOW on this pin while RESET is LOW enables pins P1.31:26 to 
operate as a Debug port after reset."

Regarding lpc2100_fan's desire to keep his name out of this: Sure, lately this 
is all John Heenan's objections, so lets call it that way.

Kind regards,

Dominic