Hi Sean,

The discussion is not quite "academic" as it contains operational
security 
assessment those in the "industry" use.

JTAG implementation is hardware, can be enabled or disabled by software.

[See notes on page 120 of 2294 user manual which states: "Important: LOW on

P1.20 while nRESET is LOW enables pins P1.25:16 to opreate as Trace prot 
after reset" and "Important: LOW on pin P1.26 while nRESET is LOW
enables 
P1.32:26 to operate as Debug port after reset". ]

Yes, my boot loader works with JTAG like and any boot loader that does not 
disable JTAG would.

Jaya

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

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

Hello,

Yes, this is what I thought, so why then would a trashed (Philips) boot 
loader cause JTAG to be nonfunctional?  I'd think if the boot loader was 
completely trashed then there would be no effect on JTAG.

The reason that I called the discussion academic is because it seems fairly 
clear now that the CRP isn't something you should rely on if you really 
don't want people to look at what you load into the device.

-- Sean

At 20:32 2/13/2006, you wrote:
>Hi Sean,
>
>The discussion is not quite "academic" as it contains operational
security
>assessment those in the "industry" use.
>
>JTAG implementation is hardware, can be enabled or disabled by software.
>
>[See notes on page 120 of 2294 user manual which states: "Important:
LOW on
>P1.20 while nRESET is LOW enables pins P1.25:16 to opreate as Trace prot
>after reset" and "Important: LOW on pin P1.26 while nRESET is LOW
enables
>P1.32:26 to operate as Debug port after reset". ]
>
>Yes, my boot loader works with JTAG like and any boot loader that does not
>disable JTAG would.
>
>Jaya
>
>--- 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
>
>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.
>
>
>----------
	

--- In lpc2000@lpc2..., Sean <embeddedrelated@...> wrote:
 > Yes, this is what I thought, so why then would a trashed (Philips) boot
 > loader cause JTAG to be nonfunctional?  I'd think if the boot loader
was
 > completely trashed then there would be no effect on JTAG.

Philips said a trashed boot loader can cause JTAG to be nonfunctional.  I 
do not know what they had in mind, but my guess is that given there is code 
in their boot loader to disable JTAG, it is possible these get executed and 
stop tractional JTAG procedures from working.

 > The reason that I called the discussion academic is because it seems
fairly
 > clear now that the CRP isn't something you should rely on if you
really
 > don't want people to look at what you load into the device.

Other than your "academic" qualification, I could not agree with you
more.

I know at least one client who pulled LPC out based on security 
assessment.  Likewise, I suspect that for those here who claim they trust 
CRP works until an exploit is posted, I think CRP security assessment is 
more an operational requirement than just an academic exercise.

Anyway, like many, I like to see this discussion cool to the back burner 
until, perhaps,  Philips comes back with some answers.  As far as I can 
tell, CRP is now back to the drawing board until the next hardware iteration.

Jaya 

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