Forums

re lpc2100_fan's objection to CRP thread

Started by Jayasooriah February 13, 2006
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 

An Engineer's Guide to the LPC2100 Series

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" target="_blank" rel="nofollow">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&.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&.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&.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&.sig=Malspbd0T4Rq3M4Q0nHrfw>Pic

>microcontrollers
>
>
>----------
>>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@lpc2..., 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@l10@...>
>Reply-To: lpc2000@lpc2...
>To: lpc2000@lpc2...
>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@lpc2..., 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@lpc2..., "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@lpc2...
> >To: lpc2000@lpc2...
> >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@lpc2..., "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@lpc2..., "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@lpc2..., "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@lpc2..., 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