Hope this answers all the questions raised on Flash security. Many
thanks to the group users. We appreciate your feedback. Please keep it
coming. Most of us are out till Jan 2 due to year end shutdown.
Happy Holidays and a Happy New Year
- Philips Microcontroller Team
1) Am I right in assuming LPC2000 CRP is a software fence implemented
in the supplied boot loader code?
Partially. It is a combination of Hardware and Software supplied in
the bootloader code. Application running in micro has full access to
the entire memory space.
2) I am going to replace the Philips bootloader. I have figured out
how to do it.
Replacing the Philips bootloader is not recommended. It hides the
underlying hardware and allows Philips to use new flash technologies
without impacting the end user. Philips Bootloader may reside in ROM
or write/erase protected flash making replacement impossible. In
LPC2101/2/3 the bootloader resides in on-chip ROM.
3) How is Bootloader programmed for the first time?
Via JTAG on a tester. JTAG is accessible in virgin devices. Once
bootloader is programmed and CRP is enabled the tester can't access
the JTAG.
4) CRP in devices with internal flash and external bus.
The bootloader prevents external boot if CRP is enabled. User
Application residing in on-chip flash which needs to be protected
should not execute code from external memory.
5) Can bootloader write/erase itself?
No.
6) Can bootloader get corrupted?
Very unlikely if IAP/ISP calls are used for flash programming.
Very likely if Flash programming interface registers are directly
accessed for flash programming.
7) Can Philips comment if Quick-Pulse parallel programming can void CRP?
First of all there is no Quick-Pulse parallel programming option for
ARM based micros. 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. It does not matter how a part is programmed. If CRP is enabled
it will remain enabled once the part is programmed. If CRP is enabled
a parallel programmer can't access the flash unless it erases the
whole flash. Same applies to the ISP utility and JTAG based debuggers.
8) Is CRP option available for 2104/05/06?
Not yet.
9) Devices with external memory bus can be forced to boot from
external memory?
ONLY if CRP is NOT enabled or NO internal flash present. Also see (4).
10) Can I tell client Philips has confirmed CRP is not voided by PP?
Yes. Also see (7).
11) How do I reprogram a CRP enabled part?
Erase all user sectors in one go via ISP. You can reprogram it after a
power cycle.
Please note that the protected code vanished and was not visible to a
"spy" or "preying eyes".
Flash Security Clarification
Started by ●December 22, 2005
Reply by ●December 23, 20052005-12-23
Thank you for confirming JTAG is enabled upon reset before any code is
executed in a "virgin" device. This confirms what my client has been
telling me all along.
This means that unless boot loader code is executed after power on
reset, *and* CEP byte is enabled by writing the magic word in the
specific location in user flash, the code in on-chip flash can be
compromised by JTAG debugging.
To know how this can be done, you need to look what the boot loader
does on starting up. For 2148 part (see code snippet below with my
annotation, thanks to Joel for providing me the memory dump), the
first thing bootloader does is to "hastily" disable JTAG debug port.
I say "hastily" because as quickly as possible, it clears PINSEL2
register which disables JTAG debug port. Then after clearing what
appears to be a SPECIAL undocumented register 40 bytes away from
PINSEL2, it restores PINSEL2 with what was originally there, but with
the bits 0-3 cleared.
Bits 0 and 1 of PINSEL2 are not documented in the user manual. But
setting Bit 2 to a 1 will enable the JTAG debug port.
According to Table 62 on page 80 of 214X user manual, upon reset, Bit
2 is 0. If this is the case, why is it necessary for the boot loader
to clear this bit?
Jaya > @ r0 = PINSEL2
> @ PINSEL2 = 0
> ldr r2, =0xe002c014 @d004
> mov r3, #0x0 @d004
> swp r0, r3, [r2] @d008
>
> @ r1 = SPECIAL
> @ SPECIAL = 0
> add r2, r2, #40 @d00c
> swp r1, r3, [r2] @d010
>
> @ PINSEL2 = r0 & ~7
> bic r3, r0, #7 @d014
> str r3, [r2, #-40] @d018
>
> @ continue with reset
> ldr pc, 0x7fffd020 @d01c
--- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...>
> 3) How is Bootloader programmed for the first time?
>
> Via JTAG on a tester. JTAG is accessible in virgin devices. Once
> bootloader is programmed and CRP is enabled the tester can't access
> the JTAG.
executed in a "virgin" device. This confirms what my client has been
telling me all along.
This means that unless boot loader code is executed after power on
reset, *and* CEP byte is enabled by writing the magic word in the
specific location in user flash, the code in on-chip flash can be
compromised by JTAG debugging.
To know how this can be done, you need to look what the boot loader
does on starting up. For 2148 part (see code snippet below with my
annotation, thanks to Joel for providing me the memory dump), the
first thing bootloader does is to "hastily" disable JTAG debug port.
I say "hastily" because as quickly as possible, it clears PINSEL2
register which disables JTAG debug port. Then after clearing what
appears to be a SPECIAL undocumented register 40 bytes away from
PINSEL2, it restores PINSEL2 with what was originally there, but with
the bits 0-3 cleared.
Bits 0 and 1 of PINSEL2 are not documented in the user manual. But
setting Bit 2 to a 1 will enable the JTAG debug port.
According to Table 62 on page 80 of 214X user manual, upon reset, Bit
2 is 0. If this is the case, why is it necessary for the boot loader
to clear this bit?
Jaya > @ r0 = PINSEL2
> @ PINSEL2 = 0
> ldr r2, =0xe002c014 @d004
> mov r3, #0x0 @d004
> swp r0, r3, [r2] @d008
>
> @ r1 = SPECIAL
> @ SPECIAL = 0
> add r2, r2, #40 @d00c
> swp r1, r3, [r2] @d010
>
> @ PINSEL2 = r0 & ~7
> bic r3, r0, #7 @d014
> str r3, [r2, #-40] @d018
>
> @ continue with reset
> ldr pc, 0x7fffd020 @d01c
--- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...>
> 3) How is Bootloader programmed for the first time?
>
> Via JTAG on a tester. JTAG is accessible in virgin devices. Once
> bootloader is programmed and CRP is enabled the tester can't access
> the JTAG.
Reply by ●December 23, 20052005-12-23
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> Thank you for confirming JTAG is enabled upon reset before any code is
> executed in a "virgin" device. This confirms what my client has been
> telling me all along.
>
i think you're mixing 2 things --- JTAG after reset and JTAG on
"virgin" device.
1) according to user manual '0x00000000' is written into every
pinselect register when reset is low, thus switching JTAG/GPIO pins
into GPIO mode Inputs.
2) i assume that "virgin" device behaves different with GPIO, this can
be done using simpliest 32 AND gate circuit.
3) How ever -- Philips did not comment on my previous statement ---
IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
all sectors? (by using boot update procedure with patched boot)
If there is such possibility -- then i consider this CRP unsecure,
and not effective enough.
Dixi.
>
> Thank you for confirming JTAG is enabled upon reset before any code is
> executed in a "virgin" device. This confirms what my client has been
> telling me all along.
>
i think you're mixing 2 things --- JTAG after reset and JTAG on
"virgin" device.
1) according to user manual '0x00000000' is written into every
pinselect register when reset is low, thus switching JTAG/GPIO pins
into GPIO mode Inputs.
2) i assume that "virgin" device behaves different with GPIO, this can
be done using simpliest 32 AND gate circuit.
3) How ever -- Philips did not comment on my previous statement ---
IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
all sectors? (by using boot update procedure with patched boot)
If there is such possibility -- then i consider this CRP unsecure,
and not effective enough.
Dixi.
Reply by ●December 23, 20052005-12-23
Hello,
On Friday 23 December 2005 15:43, Felix wrote:
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
> > Thank you for confirming JTAG is enabled upon reset before any code is
> > executed in a "virgin" device. This confirms what my client has been
> > telling me all along.
>
> i think you're mixing 2 things --- JTAG after reset and JTAG on
> "virgin" device.
>
> 1) according to user manual '0x00000000' is written into every
> pinselect register when reset is low, thus switching JTAG/GPIO pins
> into GPIO mode Inputs.
The reset state of pinsel2 (the one responsible for jtag) is detailed in table
62. Bit 2 is determined by the state of pin1.26/rtck on the rising edge of
reset. If this pin is driven low when the device comes out of reset, the jtag
port will start enabled. That's why they're setting it to zero as early as
possible. The JTAG statemachine is held in reset while the system reset is
driven low, which is why the lpcs can't be debugged out of reset. Depending
on when the debug logic is released from reset, a criticial timing issue
could enable an attacker to force the device into debug mode before the
bootloader had a chance to disable JTAG. Programming the debug control
register to force the target into debug state takes 71 TCK cycles, or 24us at
3MHz JTAG frequency. Of course, this is pure speculation, as the user manual
is a bit unclear about the state of the test logic during reset. It is likely
that because of the restrictions of -S arm cores (synchronize TCK with MCLK)
this attack isn't possible.
> 2) i assume that "virgin" device behaves different with GPIO, this can
> be done using simpliest 32 AND gate circuit.
The virgin device has no bootloader which could disable the JTAG port, so JTAG
comes up enabled, if RTCK is driven low.
>
> 3) How ever -- Philips did not comment on my previous statement ---
> IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> all sectors? (by using boot update procedure with patched boot)
> If there is such possibility -- then i consider this CRP unsecure,
> and not effective enough.
I haven't checked the bootloader updating mechanism yet - maybe the updates
are digitally signed, and the IAP calls only accept updates with a valid
signature?
> Dixi.
>
Regards,
Dominic
On Friday 23 December 2005 15:43, Felix wrote:
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
> > Thank you for confirming JTAG is enabled upon reset before any code is
> > executed in a "virgin" device. This confirms what my client has been
> > telling me all along.
>
> i think you're mixing 2 things --- JTAG after reset and JTAG on
> "virgin" device.
>
> 1) according to user manual '0x00000000' is written into every
> pinselect register when reset is low, thus switching JTAG/GPIO pins
> into GPIO mode Inputs.
The reset state of pinsel2 (the one responsible for jtag) is detailed in table
62. Bit 2 is determined by the state of pin1.26/rtck on the rising edge of
reset. If this pin is driven low when the device comes out of reset, the jtag
port will start enabled. That's why they're setting it to zero as early as
possible. The JTAG statemachine is held in reset while the system reset is
driven low, which is why the lpcs can't be debugged out of reset. Depending
on when the debug logic is released from reset, a criticial timing issue
could enable an attacker to force the device into debug mode before the
bootloader had a chance to disable JTAG. Programming the debug control
register to force the target into debug state takes 71 TCK cycles, or 24us at
3MHz JTAG frequency. Of course, this is pure speculation, as the user manual
is a bit unclear about the state of the test logic during reset. It is likely
that because of the restrictions of -S arm cores (synchronize TCK with MCLK)
this attack isn't possible.
> 2) i assume that "virgin" device behaves different with GPIO, this can
> be done using simpliest 32 AND gate circuit.
The virgin device has no bootloader which could disable the JTAG port, so JTAG
comes up enabled, if RTCK is driven low.
>
> 3) How ever -- Philips did not comment on my previous statement ---
> IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> all sectors? (by using boot update procedure with patched boot)
> If there is such possibility -- then i consider this CRP unsecure,
> and not effective enough.
I haven't checked the bootloader updating mechanism yet - maybe the updates
are digitally signed, and the IAP calls only accept updates with a valid
signature?
> Dixi.
>
Regards,
Dominic
Reply by ●December 23, 20052005-12-23
If I remember correctly the manual also says the pins are sampled a bit
after the reset, which suggest that this is done by the bootloader code.
If I would have to implement this myself in hardware, I would enable the
jtag if the bootcode did not write to PINSEL register within the first
few instructions executed. This way the JTAG is enabled if the device is
virgin (no bootcode in the flash) and the device is protected if the
right bootcode is present. The fact that the bootloader writes to the
PINSEL register in the first instructions, may suggest that this is also
what philips implemented. The other possibility is that they blow a fuse
after programming the bootloader into the virgin device. I don't think
they would leave a backdoor when they go to all the trouble of
implementing the CRP.
Erasing the bootsector is also impossible because all ways to execute
code other than the bootloader or the flashed program are disabled when
CRP is enabled.
According a past thread, nobody succeeded in starting debugging directly
after reset. The answer from philips_apps was that this was to implement
the CRP. I have seen enough evidence to trust philips when they say
there are no backdoors.
Richard. Dominic Rath wrote:
> Hello,
>
> On Friday 23 December 2005 15:43, Felix wrote:
> > --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
> > > Thank you for confirming JTAG is enabled upon reset before any code is
> > > executed in a "virgin" device. This confirms what my client has been
> > > telling me all along.
> >
> > i think you're mixing 2 things --- JTAG after reset and JTAG on
> > "virgin" device.
> >
> > 1) according to user manual '0x00000000' is written into every
> > pinselect register when reset is low, thus switching JTAG/GPIO pins
> > into GPIO mode Inputs.
> The reset state of pinsel2 (the one responsible for jtag) is detailed
> in table
> 62. Bit 2 is determined by the state of pin1.26/rtck on the rising
> edge of
> reset. If this pin is driven low when the device comes out of reset,
> the jtag
> port will start enabled. That's why they're setting it to zero as
> early as
> possible. The JTAG statemachine is held in reset while the system
> reset is
> driven low, which is why the lpcs can't be debugged out of reset.
> Depending
> on when the debug logic is released from reset, a criticial timing issue
> could enable an attacker to force the device into debug mode before the
> bootloader had a chance to disable JTAG. Programming the debug control
> register to force the target into debug state takes 71 TCK cycles, or
> 24us at
> 3MHz JTAG frequency. Of course, this is pure speculation, as the user
> manual
> is a bit unclear about the state of the test logic during reset. It is
> likely
> that because of the restrictions of -S arm cores (synchronize TCK with
> MCLK)
> this attack isn't possible.
>
> > 2) i assume that "virgin" device behaves different with GPIO, this can
> > be done using simpliest 32 AND gate circuit.
> The virgin device has no bootloader which could disable the JTAG port,
> so JTAG
> comes up enabled, if RTCK is driven low.
>
> >
> > 3) How ever -- Philips did not comment on my previous statement ---
> > IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> > all sectors? (by using boot update procedure with patched boot)
> > If there is such possibility -- then i consider this CRP unsecure,
> > and not effective enough.
> I haven't checked the bootloader updating mechanism yet - maybe the
> updates
> are digitally signed, and the IAP calls only accept updates with a valid
> signature?
>
> > Dixi.
> >
>
> Regards,
>
> Dominic > SPONSORED LINKS
> Microprocessor
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
after the reset, which suggest that this is done by the bootloader code.
If I would have to implement this myself in hardware, I would enable the
jtag if the bootcode did not write to PINSEL register within the first
few instructions executed. This way the JTAG is enabled if the device is
virgin (no bootcode in the flash) and the device is protected if the
right bootcode is present. The fact that the bootloader writes to the
PINSEL register in the first instructions, may suggest that this is also
what philips implemented. The other possibility is that they blow a fuse
after programming the bootloader into the virgin device. I don't think
they would leave a backdoor when they go to all the trouble of
implementing the CRP.
Erasing the bootsector is also impossible because all ways to execute
code other than the bootloader or the flashed program are disabled when
CRP is enabled.
According a past thread, nobody succeeded in starting debugging directly
after reset. The answer from philips_apps was that this was to implement
the CRP. I have seen enough evidence to trust philips when they say
there are no backdoors.
Richard. Dominic Rath wrote:
> Hello,
>
> On Friday 23 December 2005 15:43, Felix wrote:
> > --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
> > > Thank you for confirming JTAG is enabled upon reset before any code is
> > > executed in a "virgin" device. This confirms what my client has been
> > > telling me all along.
> >
> > i think you're mixing 2 things --- JTAG after reset and JTAG on
> > "virgin" device.
> >
> > 1) according to user manual '0x00000000' is written into every
> > pinselect register when reset is low, thus switching JTAG/GPIO pins
> > into GPIO mode Inputs.
> The reset state of pinsel2 (the one responsible for jtag) is detailed
> in table
> 62. Bit 2 is determined by the state of pin1.26/rtck on the rising
> edge of
> reset. If this pin is driven low when the device comes out of reset,
> the jtag
> port will start enabled. That's why they're setting it to zero as
> early as
> possible. The JTAG statemachine is held in reset while the system
> reset is
> driven low, which is why the lpcs can't be debugged out of reset.
> Depending
> on when the debug logic is released from reset, a criticial timing issue
> could enable an attacker to force the device into debug mode before the
> bootloader had a chance to disable JTAG. Programming the debug control
> register to force the target into debug state takes 71 TCK cycles, or
> 24us at
> 3MHz JTAG frequency. Of course, this is pure speculation, as the user
> manual
> is a bit unclear about the state of the test logic during reset. It is
> likely
> that because of the restrictions of -S arm cores (synchronize TCK with
> MCLK)
> this attack isn't possible.
>
> > 2) i assume that "virgin" device behaves different with GPIO, this can
> > be done using simpliest 32 AND gate circuit.
> The virgin device has no bootloader which could disable the JTAG port,
> so JTAG
> comes up enabled, if RTCK is driven low.
>
> >
> > 3) How ever -- Philips did not comment on my previous statement ---
> > IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> > all sectors? (by using boot update procedure with patched boot)
> > If there is such possibility -- then i consider this CRP unsecure,
> > and not effective enough.
> I haven't checked the bootloader updating mechanism yet - maybe the
> updates
> are digitally signed, and the IAP calls only accept updates with a valid
> signature?
>
> > Dixi.
> >
>
> Regards,
>
> Dominic > SPONSORED LINKS
> Microprocessor
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
Reply by ●December 23, 20052005-12-23
On Friday 23 December 2005 15:43, Felix wrote:
> 3) How ever -- Philips did not comment on my previous statement ---
> IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> all sectors? (by using boot update procedure with patched boot)
> If there is such possibility -- then i consider this CRP unsecure,
> and not effective enough.
> Dixi.
>
Bootloader update works by using ISP to load the supplied .hex file into RAM
and executing it there. Because 'Write to RAM' is disabled when CRP is
enabled, the bootloader can't be updated until the flash has been erased.
When CRP is enabled, only all user sectors can be erased, so it isn't
possible to erase sector 0 while preserving the content of the other sectors.
The LPCs are save in that regard.
Dominic
> 3) How ever -- Philips did not comment on my previous statement ---
> IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> all sectors? (by using boot update procedure with patched boot)
> If there is such possibility -- then i consider this CRP unsecure,
> and not effective enough.
> Dixi.
>
Bootloader update works by using ISP to load the supplied .hex file into RAM
and executing it there. Because 'Write to RAM' is disabled when CRP is
enabled, the bootloader can't be updated until the flash has been erased.
When CRP is enabled, only all user sectors can be erased, so it isn't
possible to erase sector 0 while preserving the content of the other sectors.
The LPCs are save in that regard.
Dominic
Reply by ●December 23, 20052005-12-23
Hi Felix,
It is my guess (based on understanding of information on LPC devices
and history) that the two are the same. In other words LPC comes out
of RESET with JTAG enabled (so you can recover when the on-chip flash
is NBG). The only way to stop JTAG debugging is to actively disable
it on reset, and this is exactly what the boot loader is doing.
If this is true (and I say "if" becuase I have not got into further
disasesembling the rest of the boot loader on for the 2148 part) the
Boot Process Flow Chart on page 295 of the 214x user manual is flawed.
It would be untrue to claim that the Boot loader enables JTAG if CRP
is not enabled. The boot loader disables JTAG first, and then enables
it if CRP is not enabled.
Dominic in later poster has explained how this can compromise CRP.
As to your last question, yes I have been told this is possible. I
nave not done it, so I do not wish to comment on whether the method works.
Having got Philips to address the issue thus far was good, and I am
just hoping we can get more issues relating to CRP out in the open for
the benefit of all parties, including Philips.
I can see the LPC would fit well for use in security devices. IMO, as
it stands using this in security context means Philips software team
is now in the trust domain. This is an unecessary risk to take and
increases "attack surface area".
This is why I am looked at replacing the boot loader, but Philips will
not guarantee the part if this was done. (You would expect Philips to
say this of course.)
One could work around this limitation by reloading the part with the
original boot loader should problems be found in any batch.
Jaya
--- In lpc2000@lpc2..., "Felix" <felix_lazarev@y...> wrote:
>
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
> >
> > Thank you for confirming JTAG is enabled upon reset before any code is
> > executed in a "virgin" device. This confirms what my client has been
> > telling me all along.
> >
>
> i think you're mixing 2 things --- JTAG after reset and JTAG on
> "virgin" device.
>
> 1) according to user manual '0x00000000' is written into every
> pinselect register when reset is low, thus switching JTAG/GPIO pins
> into GPIO mode Inputs.
> 2) i assume that "virgin" device behaves different with GPIO, this can
> be done using simpliest 32 AND gate circuit.
>
> 3) How ever -- Philips did not comment on my previous statement ---
> IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> all sectors? (by using boot update procedure with patched boot)
> If there is such possibility -- then i consider this CRP unsecure,
> and not effective enough.
> Dixi.
>
It is my guess (based on understanding of information on LPC devices
and history) that the two are the same. In other words LPC comes out
of RESET with JTAG enabled (so you can recover when the on-chip flash
is NBG). The only way to stop JTAG debugging is to actively disable
it on reset, and this is exactly what the boot loader is doing.
If this is true (and I say "if" becuase I have not got into further
disasesembling the rest of the boot loader on for the 2148 part) the
Boot Process Flow Chart on page 295 of the 214x user manual is flawed.
It would be untrue to claim that the Boot loader enables JTAG if CRP
is not enabled. The boot loader disables JTAG first, and then enables
it if CRP is not enabled.
Dominic in later poster has explained how this can compromise CRP.
As to your last question, yes I have been told this is possible. I
nave not done it, so I do not wish to comment on whether the method works.
Having got Philips to address the issue thus far was good, and I am
just hoping we can get more issues relating to CRP out in the open for
the benefit of all parties, including Philips.
I can see the LPC would fit well for use in security devices. IMO, as
it stands using this in security context means Philips software team
is now in the trust domain. This is an unecessary risk to take and
increases "attack surface area".
This is why I am looked at replacing the boot loader, but Philips will
not guarantee the part if this was done. (You would expect Philips to
say this of course.)
One could work around this limitation by reloading the part with the
original boot loader should problems be found in any batch.
Jaya
--- In lpc2000@lpc2..., "Felix" <felix_lazarev@y...> wrote:
>
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
> >
> > Thank you for confirming JTAG is enabled upon reset before any code is
> > executed in a "virgin" device. This confirms what my client has been
> > telling me all along.
> >
>
> i think you're mixing 2 things --- JTAG after reset and JTAG on
> "virgin" device.
>
> 1) according to user manual '0x00000000' is written into every
> pinselect register when reset is low, thus switching JTAG/GPIO pins
> into GPIO mode Inputs.
> 2) i assume that "virgin" device behaves different with GPIO, this can
> be done using simpliest 32 AND gate circuit.
>
> 3) How ever -- Philips did not comment on my previous statement ---
> IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> all sectors? (by using boot update procedure with patched boot)
> If there is such possibility -- then i consider this CRP unsecure,
> and not effective enough.
> Dixi.
>
Reply by ●December 23, 20052005-12-23
Hi Richard,
My understanding is that like in other such devices, the GPIO pins are
sampled and copied on to relevant enable/disable bits during the reset
cycle before any code gets executed.
This is the method by which you can configure "virgin" devices to boot
for external memory, or enable JTAG even if the default behaviour is
that out of reset, external memory interface and JTAG are disabled.
This suggest the code to force these bits low is there to try and
mitigate security risks under these circumstances. So unless have
information about these techniques (which Philips no doubt has) it
would not be easy for just anyone to do this.
If Philips had the fuse concept (like in ATMEL AVRs), this would have
been stated in the manuals (like ATMEL did) and that would make the
LPC part a candidate for security devices.
I do not mean to cast doubts on the ability of this audience. However
the fact that nobody has defeated the security features says nothing
at all in the security context if methods are kept secret.
In other words, to trust LPC for security needs, one also has to trust
not only Philips but the many employes (and contractors) engaged by
Philips, past and present, who have access to this secret. This is
the core argument against security by obscurity.
Jaya
--- In lpc2000@lpc2..., Richard Duits <yahoo@r...> wrote:
> The other possibility is that they blow a fuse
> after programming the bootloader into the virgin device.
> I don't think they would leave a backdoor when they go
> to all the trouble of implementing the CRP.
> According a past thread, nobody succeeded in starting
> debugging directly after reset. The answer from
> philips_apps was that this was to implement the CRP.
> I have seen enough evidence to trust philips when
> they say there are no backdoors.
>
My understanding is that like in other such devices, the GPIO pins are
sampled and copied on to relevant enable/disable bits during the reset
cycle before any code gets executed.
This is the method by which you can configure "virgin" devices to boot
for external memory, or enable JTAG even if the default behaviour is
that out of reset, external memory interface and JTAG are disabled.
This suggest the code to force these bits low is there to try and
mitigate security risks under these circumstances. So unless have
information about these techniques (which Philips no doubt has) it
would not be easy for just anyone to do this.
If Philips had the fuse concept (like in ATMEL AVRs), this would have
been stated in the manuals (like ATMEL did) and that would make the
LPC part a candidate for security devices.
I do not mean to cast doubts on the ability of this audience. However
the fact that nobody has defeated the security features says nothing
at all in the security context if methods are kept secret.
In other words, to trust LPC for security needs, one also has to trust
not only Philips but the many employes (and contractors) engaged by
Philips, past and present, who have access to this secret. This is
the core argument against security by obscurity.
Jaya
--- In lpc2000@lpc2..., Richard Duits <yahoo@r...> wrote:
> The other possibility is that they blow a fuse
> after programming the bootloader into the virgin device.
> I don't think they would leave a backdoor when they go
> to all the trouble of implementing the CRP.
> According a past thread, nobody succeeded in starting
> debugging directly after reset. The answer from
> philips_apps was that this was to implement the CRP.
> I have seen enough evidence to trust philips when
> they say there are no backdoors.
>
Reply by ●December 23, 20052005-12-23
At 01:19 AM 12/23/05 +0000, philips_apps wrote:
>Hope this answers all the questions raised on Flash security. Many
>thanks to the group users. We appreciate your feedback. Please keep it
>coming. Most of us are out till Jan 2 due to year end shutdown.
>
>Happy Holidays and a Happy New Year
>
>- Philips Microcontroller Team
Nice summary. With your permission I'll copy this to the FAQ (with
appropriate credit of course).
Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
>Hope this answers all the questions raised on Flash security. Many
>thanks to the group users. We appreciate your feedback. Please keep it
>coming. Most of us are out till Jan 2 due to year end shutdown.
>
>Happy Holidays and a Happy New Year
>
>- Philips Microcontroller Team
Nice summary. With your permission I'll copy this to the FAQ (with
appropriate credit of course).
Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
Reply by ●December 23, 20052005-12-23
At 01:19 AM 12/23/05 +0000, philips_apps wrote:
>11) How do I reprogram a CRP enabled part?
>
>Erase all user sectors in one go via ISP. You can reprogram it after a
>power cycle.
>Please note that the protected code vanished and was not visible to a
>"spy" or "preying eyes".
Or even prying eyes :) Although the phrase preying eyes does have a
certain appeal.
Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
>11) How do I reprogram a CRP enabled part?
>
>Erase all user sectors in one go via ISP. You can reprogram it after a
>power cycle.
>Please note that the protected code vanished and was not visible to a
>"spy" or "preying eyes".
Or even prying eyes :) Although the phrase preying eyes does have a
certain appeal.
Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
