Seems to me there is a whole lot of guessing going on with not one
reproducible example of CRP failing for those versions in which CRP
was implemented.
Philips has stated that CRP functions properly. In my view, that is
sufficient until someone PROVES with a documented, reproducible,
example that it does not. No guesswork, no suppositions, no what
if's, just a documented, reproducible example. No amount of testing
can prove that it does work but it only takes one example to prove it
doesn't.
Richard
Flash Security Clarification
Started by ●December 22, 2005
Reply by ●December 25, 20052005-12-25
Reply by ●December 25, 20052005-12-25
Just because Philips says something doesn't mean that it's true -
they may be
holding information back, for whatever reason. This isn't a bad thing by
itself. But the LPC's have undocumented functionality, and that's what makes
people curious.
That said, I believe possible attacks on their CRP are very limited. Given the
bootloader code is free of bugs there is no way of having the bootloader
and/or sector 0 changed without destroying all the other flash content, too.
The JTAG comes up enabled, when the chip leaves reset, but it is disabled
within a few microseconds. I've fed continous TCK cycles into the device (TMS
high), and about 250us after the external reset was deasserted, the pulses
are returned on RTCK. Another 2 us later, RTCK turns quiet again, until about
30us have passed. This was on a device with CRP disabled, and fits to what is
written in the user manual and the first few instructions of the bootloader
code.
Regards,
Dominic
On Sunday 25 December 2005 19:10, rtstofer wrote:
> Seems to me there is a whole lot of guessing going on with not one
> reproducible example of CRP failing for those versions in which CRP
> was implemented.
>
> Philips has stated that CRP functions properly. In my view, that is
> sufficient until someone PROVES with a documented, reproducible,
> example that it does not. No guesswork, no suppositions, no what
> if's, just a documented, reproducible example. No amount of testing
> can prove that it does work but it only takes one example to prove it
> doesn't.
>
> Richard
holding information back, for whatever reason. This isn't a bad thing by
itself. But the LPC's have undocumented functionality, and that's what makes
people curious.
That said, I believe possible attacks on their CRP are very limited. Given the
bootloader code is free of bugs there is no way of having the bootloader
and/or sector 0 changed without destroying all the other flash content, too.
The JTAG comes up enabled, when the chip leaves reset, but it is disabled
within a few microseconds. I've fed continous TCK cycles into the device (TMS
high), and about 250us after the external reset was deasserted, the pulses
are returned on RTCK. Another 2 us later, RTCK turns quiet again, until about
30us have passed. This was on a device with CRP disabled, and fits to what is
written in the user manual and the first few instructions of the bootloader
code.
Regards,
Dominic
On Sunday 25 December 2005 19:10, rtstofer wrote:
> Seems to me there is a whole lot of guessing going on with not one
> reproducible example of CRP failing for those versions in which CRP
> was implemented.
>
> Philips has stated that CRP functions properly. In my view, that is
> sufficient until someone PROVES with a documented, reproducible,
> example that it does not. No guesswork, no suppositions, no what
> if's, just a documented, reproducible example. No amount of testing
> can prove that it does work but it only takes one example to prove it
> doesn't.
>
> Richard
Reply by ●December 25, 20052005-12-25
--- In lpc2000@lpc2..., Dominic Rath <Dominic.Rath@g...>
wrote:
>
> Just because Philips says something doesn't mean that it's true -
they may be
> holding information back, for whatever reason. This isn't a bad
thing by
> itself. But the LPC's have undocumented functionality, and that's
what makes
> people curious.
>
> That said, I believe possible attacks on their CRP are very
limited. Given the
> bootloader code is free of bugs there is no way of having the
bootloader
> and/or sector 0 changed without destroying all the other flash
content, too.
>
> The JTAG comes up enabled, when the chip leaves reset, but it is
disabled
> within a few microseconds. I've fed continous TCK cycles into the
device (TMS
> high), and about 250us after the external reset was deasserted,
the pulses
> are returned on RTCK. Another 2 us later, RTCK turns quiet again,
until about
> 30us have passed. This was on a device with CRP disabled, and fits
to what is
> written in the user manual and the first few instructions of the
bootloader
> code.
>
> Regards,
>
> Dominic
But you haven't proven that CRP doesn't work. The only important
result is when you successfully grab the code from a protected
device and document the attack so it can be reproduced.
The questions have been asked and answered; CRP works. The
alternative to accepting that assertion is to choose another
device. There are a lot of them around.
But, every device has warts and every device can be attacked with an
SEM if it is worth the effort. Even when the flash is buried
beneath an oxide layer (Microchip). Sure, it's harder (impractical,
even) but not impossible. It just has to be worth the cost of the
attack.
The only exception is an FPGA loaded from a removable boot loader.
Lose power; lose configuration and crypto keys. And even the boot
loader uses encryption during configuration transfer. Reference
Xilinx re: crypto applications.
Richard
wrote:
>
> Just because Philips says something doesn't mean that it's true -
they may be
> holding information back, for whatever reason. This isn't a bad
thing by
> itself. But the LPC's have undocumented functionality, and that's
what makes
> people curious.
>
> That said, I believe possible attacks on their CRP are very
limited. Given the
> bootloader code is free of bugs there is no way of having the
bootloader
> and/or sector 0 changed without destroying all the other flash
content, too.
>
> The JTAG comes up enabled, when the chip leaves reset, but it is
disabled
> within a few microseconds. I've fed continous TCK cycles into the
device (TMS
> high), and about 250us after the external reset was deasserted,
the pulses
> are returned on RTCK. Another 2 us later, RTCK turns quiet again,
until about
> 30us have passed. This was on a device with CRP disabled, and fits
to what is
> written in the user manual and the first few instructions of the
bootloader
> code.
>
> Regards,
>
> Dominic
But you haven't proven that CRP doesn't work. The only important
result is when you successfully grab the code from a protected
device and document the attack so it can be reproduced.
The questions have been asked and answered; CRP works. The
alternative to accepting that assertion is to choose another
device. There are a lot of them around.
But, every device has warts and every device can be attacked with an
SEM if it is worth the effort. Even when the flash is buried
beneath an oxide layer (Microchip). Sure, it's harder (impractical,
even) but not impossible. It just has to be worth the cost of the
attack.
The only exception is an FPGA loaded from a removable boot loader.
Lose power; lose configuration and crypto keys. And even the boot
loader uses encryption during configuration transfer. Reference
Xilinx re: crypto applications.
Richard
Reply by ●December 25, 20052005-12-25
The location FMDEV[9] (at 0x3fff8024) contains the flash lock bits.
Writing 0xffffffff to it locks all sectors from write or erase.
--- In lpc2000@lpc2..., Dominic Rath <Dominic.Rath@g...>
> > 2. There is something, like CRP latch in the chip, the boot loader
> > writes 0xFFFFFFFF there, if CRP is enabled
> Where is that? It is written to the undocumented location 0x3fff8024
no matter
> if CRP is enabled or not.
Writing 0xffffffff to it locks all sectors from write or erase.
--- In lpc2000@lpc2..., Dominic Rath <Dominic.Rath@g...>
> > 2. There is something, like CRP latch in the chip, the boot loader
> > writes 0xFFFFFFFF there, if CRP is enabled
> Where is that? It is written to the undocumented location 0x3fff8024
no matter
> if CRP is enabled or not.
Reply by ●December 25, 20052005-12-25
Dear Richard,
IMHO you are not being security conscious. It would be wise check if
you boot loader has a 'T' command, and what it does.
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
>
> Seems to me there is a whole lot of guessing going on with not one
> reproducible example of CRP failing for those versions in which CRP
> was implemented.
>
> Philips has stated that CRP functions properly. In my view, that is
> sufficient until someone PROVES with a documented, reproducible,
> example that it does not. No guesswork, no suppositions, no what
> if's, just a documented, reproducible example. No amount of testing
> can prove that it does work but it only takes one example to prove it
> doesn't.
>
> Richard
>
IMHO you are not being security conscious. It would be wise check if
you boot loader has a 'T' command, and what it does.
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
>
> Seems to me there is a whole lot of guessing going on with not one
> reproducible example of CRP failing for those versions in which CRP
> was implemented.
>
> Philips has stated that CRP functions properly. In my view, that is
> sufficient until someone PROVES with a documented, reproducible,
> example that it does not. No guesswork, no suppositions, no what
> if's, just a documented, reproducible example. No amount of testing
> can prove that it does work but it only takes one example to prove it
> doesn't.
>
> Richard
>
Reply by ●December 25, 20052005-12-25
Dear Dominic,
How do you know that the supplied boot loader is free of bugs? Have
you inspected the source and/or tested the binaries?
IMHO you cannot say it is free of bugs even in a practical sense. I
would like to see Philips tell us to what level it will certify boot
loader code.
Regards,
Jaya
--- In lpc2000@lpc2..., Dominic Rath <Dominic.Rath@g...>
> That said, I believe possible attacks on their CRP are very limited.
Given the
> bootloader code is free of bugs there is no way of having the
bootloader
> and/or sector 0 changed without destroying all the other flash
content, too.
>
> The JTAG comes up enabled, when the chip leaves reset, but it is
disabled
> within a few microseconds. I've fed continous TCK cycles into the
device (TMS
> high), and about 250us after the external reset was deasserted, the
pulses
> are returned on RTCK. Another 2 us later, RTCK turns quiet again,
until about
> 30us have passed. This was on a device with CRP disabled, and fits
to what is
> written in the user manual and the first few instructions of the
bootloader
> code.
>
> Regards,
>
> Dominic
How do you know that the supplied boot loader is free of bugs? Have
you inspected the source and/or tested the binaries?
IMHO you cannot say it is free of bugs even in a practical sense. I
would like to see Philips tell us to what level it will certify boot
loader code.
Regards,
Jaya
--- In lpc2000@lpc2..., Dominic Rath <Dominic.Rath@g...>
> That said, I believe possible attacks on their CRP are very limited.
Given the
> bootloader code is free of bugs there is no way of having the
bootloader
> and/or sector 0 changed without destroying all the other flash
content, too.
>
> The JTAG comes up enabled, when the chip leaves reset, but it is
disabled
> within a few microseconds. I've fed continous TCK cycles into the
device (TMS
> high), and about 250us after the external reset was deasserted, the
pulses
> are returned on RTCK. Another 2 us later, RTCK turns quiet again,
until about
> 30us have passed. This was on a device with CRP disabled, and fits
to what is
> written in the user manual and the first few instructions of the
bootloader
> code.
>
> Regards,
>
> Dominic
Reply by ●December 25, 20052005-12-25
Reasonable questions. Here are my answers.
a) No. The documentation is quite clear on what you cannot do to
defeat code security for ATMEL AVR. AVR has the notion of "fuses"
while LPC does not seem to.
b) IMHO you have too many provisoes to your "quite" safe critiera.
Lets wait till Philips tells us what the "T" command does.
c) Client will not include Philips (employees, partners, contractors,
cleaners, etc) in its trust domain. If code is available in a form
the client can certify, client will use the loader AS-IS. Otherwise
client will replace it assuming hardware supports security, without
any need for secrecy or obsfucation of code in boot loader code.
d) What "it can be" is a lot of things, including methods to bypass CRP.
e) Not sure what you on about. We need CRP for security. Nothing
said about OS or MMU requirements. (BASIC is secure!?! :))
f) It is a well established theory that you cannot build security
using software alone if the there is no support for it in hardware.
Based on what I have seen so far, Philips had not included CRP goal in
the hardware design, and it is just a software afterthought.
Regards,
Jaya
--- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
>
> Ummm.... So far... I've confidence that Philips CRP is secure and
> hack-proof.
>
> a) Hacking LPC2xxx by JTAG boundary scan.
> - Cannot answer your questions. But would that be same problems for
> all other ARM chips from TI, Atmel and AD??
>
> b) Current Philips Code locking
> "Quite" safe. as long as..
> - No secret alternate way of programming or chip testing. for e.g.
> parallel programming
> - Boot Loader programmer remembers to disable all commands and only
> allows Chip Erasing when CRP enabled
> - Boot Loader programmer remembers to erase the sector containing
> 0x87654321 last (Not first sector to erase)
>
> c) Re-writing bootloader and replacing philips code
> Why want to do that? Problems...
> - Flash programming timing will be different if philips switches
> silicon foundry
> - It seems like all the 64Pin and 144pin devices (2294, 2292, 2214,
> 2114, 2124, 2129, 2194...) are same silicon. May be the boot loader
> initialize chip to different parts. Oops! You might accidentally
> enable a 64KB flash sector with lots of faulty bits, though your
> 128KB part becomes 256KB part free of charge...
> - Philips Bootloader might initialize some unknown hardware or
> memory mapping properly.
>
> d) Undocumented commands in BootLoader.
> - It can be extra commands for flash memory testing, peeping or etc.
> However, not too much for concern as long as the guys writing the
> boot loader remembers to disables all these commands when CRP is
> enabled.
>
> e) Allowing Customer App Program
> - The LPC2xxx is NOT the correct part for a product with build in
> O/S and customer could develop their own application program (and
> where CRP on O/S section is needed). You need an ARM with MMU.
> - OR: Change the design to include an interpreter (e.g. JAVA Run
> time or Basic Interpreter)
> - BTW, anybody has good recommendation for a Open Source Basic
> interpreter to be ported onto LPC2124?? I'm looking for one
> (Thanks in Advance)
>
> f) May be another way to hack the Chip (I don't know..)
> - Find out the exact clock cycles from reset and bootloader reads
> 0x87654321 (This is fixed no of clock cycles from reset as No
> Interrupt, PLL disabled, Mem Accelerator is off)
> - Pulse that few clock cycles to >100Mhz. The ARM CPU Core seems
> could take >100MHz but not the philips flash memory. Hence the CPU
> will read some "garbage bits"... May be 0x97654331 (even after the
> ECC)
> - Slow down the clock cycles to normal speed... as you get what you
> want after that.... Yeah!!
> - Philips could fix this by reading the 0x87654321 multiple times,
> at random intervals.
>
> => To summarize, is it just whether you trust Philips or NOT....
>
> Finally, Merry X'Mas....
> Have fun hacking the chip over the holidays....
> Let me know the outcome... THANKS!!
>
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
> wrote:
> >
> > There is a technique called JTAG boundary scanning. From memory,
> (I
> > did this some years ago) boundary scanning does not require the
> target
> > to come out of reset. In such a system, the "ememy" is all over
> the
> > code long before the processor even wakes up, and thus how quickly
> it
> > takes to secure flash becomes irrelevant.
> >
> > Incidentally, the unavailablity of BSDL files (for LPC devices)
> does
> > not prevent this type of attack. There are methods by which one
> can
> > "discover" boundary architecture by blind scanning.
> >
> > Philips needs to release a lot more information relating to its CRP
> > implementation and be more forthcoming with describing thing as
> they
> > are, not as they like us to believe (referring to "enabling" JTAG
> in
> > the boot loader) before I would consider CRP as anything more than
> > just a marketting gimmic.
> >
> > Having said this, the issue with boot loader is that because
> Philips
> > will not publish its boot loader code, we never know what is
> hidden in
> > there that can be explioted by any would be attacker to void
> security
> > features.
> >
> > The 'T' command that exists in 2104/5/6 boot loader that Philips
> has
> > not documented in any of the user manuals is one example. What
> *is*
> > this command there for and why is Philips not telling us about it?
> >
> > I prefer not to say more about the 'T' command until Philips has
> had
> > an opportunity to respond to my question in the new year.
> >
> > Meanwhile, may your holiday break be happy and safe, and may the
> new
> > year bring you more happiness and even more prosperity.
> >
> > Best wishes to all ...
> >
> > Jaya
> >
> > --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> > > => Is there another way to force load+run code from RAM when both
> > > JTAG and ISP command are disabled??
> > > Thanks, and Regards /MH
> > >
> >
>
a) No. The documentation is quite clear on what you cannot do to
defeat code security for ATMEL AVR. AVR has the notion of "fuses"
while LPC does not seem to.
b) IMHO you have too many provisoes to your "quite" safe critiera.
Lets wait till Philips tells us what the "T" command does.
c) Client will not include Philips (employees, partners, contractors,
cleaners, etc) in its trust domain. If code is available in a form
the client can certify, client will use the loader AS-IS. Otherwise
client will replace it assuming hardware supports security, without
any need for secrecy or obsfucation of code in boot loader code.
d) What "it can be" is a lot of things, including methods to bypass CRP.
e) Not sure what you on about. We need CRP for security. Nothing
said about OS or MMU requirements. (BASIC is secure!?! :))
f) It is a well established theory that you cannot build security
using software alone if the there is no support for it in hardware.
Based on what I have seen so far, Philips had not included CRP goal in
the hardware design, and it is just a software afterthought.
Regards,
Jaya
--- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
>
> Ummm.... So far... I've confidence that Philips CRP is secure and
> hack-proof.
>
> a) Hacking LPC2xxx by JTAG boundary scan.
> - Cannot answer your questions. But would that be same problems for
> all other ARM chips from TI, Atmel and AD??
>
> b) Current Philips Code locking
> "Quite" safe. as long as..
> - No secret alternate way of programming or chip testing. for e.g.
> parallel programming
> - Boot Loader programmer remembers to disable all commands and only
> allows Chip Erasing when CRP enabled
> - Boot Loader programmer remembers to erase the sector containing
> 0x87654321 last (Not first sector to erase)
>
> c) Re-writing bootloader and replacing philips code
> Why want to do that? Problems...
> - Flash programming timing will be different if philips switches
> silicon foundry
> - It seems like all the 64Pin and 144pin devices (2294, 2292, 2214,
> 2114, 2124, 2129, 2194...) are same silicon. May be the boot loader
> initialize chip to different parts. Oops! You might accidentally
> enable a 64KB flash sector with lots of faulty bits, though your
> 128KB part becomes 256KB part free of charge...
> - Philips Bootloader might initialize some unknown hardware or
> memory mapping properly.
>
> d) Undocumented commands in BootLoader.
> - It can be extra commands for flash memory testing, peeping or etc.
> However, not too much for concern as long as the guys writing the
> boot loader remembers to disables all these commands when CRP is
> enabled.
>
> e) Allowing Customer App Program
> - The LPC2xxx is NOT the correct part for a product with build in
> O/S and customer could develop their own application program (and
> where CRP on O/S section is needed). You need an ARM with MMU.
> - OR: Change the design to include an interpreter (e.g. JAVA Run
> time or Basic Interpreter)
> - BTW, anybody has good recommendation for a Open Source Basic
> interpreter to be ported onto LPC2124?? I'm looking for one
> (Thanks in Advance)
>
> f) May be another way to hack the Chip (I don't know..)
> - Find out the exact clock cycles from reset and bootloader reads
> 0x87654321 (This is fixed no of clock cycles from reset as No
> Interrupt, PLL disabled, Mem Accelerator is off)
> - Pulse that few clock cycles to >100Mhz. The ARM CPU Core seems
> could take >100MHz but not the philips flash memory. Hence the CPU
> will read some "garbage bits"... May be 0x97654331 (even after the
> ECC)
> - Slow down the clock cycles to normal speed... as you get what you
> want after that.... Yeah!!
> - Philips could fix this by reading the 0x87654321 multiple times,
> at random intervals.
>
> => To summarize, is it just whether you trust Philips or NOT....
>
> Finally, Merry X'Mas....
> Have fun hacking the chip over the holidays....
> Let me know the outcome... THANKS!!
>
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
> wrote:
> >
> > There is a technique called JTAG boundary scanning. From memory,
> (I
> > did this some years ago) boundary scanning does not require the
> target
> > to come out of reset. In such a system, the "ememy" is all over
> the
> > code long before the processor even wakes up, and thus how quickly
> it
> > takes to secure flash becomes irrelevant.
> >
> > Incidentally, the unavailablity of BSDL files (for LPC devices)
> does
> > not prevent this type of attack. There are methods by which one
> can
> > "discover" boundary architecture by blind scanning.
> >
> > Philips needs to release a lot more information relating to its CRP
> > implementation and be more forthcoming with describing thing as
> they
> > are, not as they like us to believe (referring to "enabling" JTAG
> in
> > the boot loader) before I would consider CRP as anything more than
> > just a marketting gimmic.
> >
> > Having said this, the issue with boot loader is that because
> Philips
> > will not publish its boot loader code, we never know what is
> hidden in
> > there that can be explioted by any would be attacker to void
> security
> > features.
> >
> > The 'T' command that exists in 2104/5/6 boot loader that Philips
> has
> > not documented in any of the user manuals is one example. What
> *is*
> > this command there for and why is Philips not telling us about it?
> >
> > I prefer not to say more about the 'T' command until Philips has
> had
> > an opportunity to respond to my question in the new year.
> >
> > Meanwhile, may your holiday break be happy and safe, and may the
> new
> > year bring you more happiness and even more prosperity.
> >
> > Best wishes to all ...
> >
> > Jaya
> >
> > --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> > > => Is there another way to force load+run code from RAM when both
> > > JTAG and ISP command are disabled??
> > > Thanks, and Regards /MH
> > >
> >
>
Reply by ●December 25, 20052005-12-25
> f) It is a well established theory that you cannot build security
> using software alone if the there is no support for it in hardware.
Stipulated that LPC won't meet your needs. Now are we done?
Richard
Reply by ●December 25, 20052005-12-25
Dear Richard,
The discussion on CRP is for all in this forum who are interested in
this feature
It is not unreasonable to question the veracity of CRP claims.
As there are outstanding issues still unresolved, the answer is no.
Kind regards,
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
>
>
> > f) It is a well established theory that you cannot build security
> > using software alone if the there is no support for it in hardware.
>
> Stipulated that LPC won't meet your needs. Now are we done?
>
> Richard
>
The discussion on CRP is for all in this forum who are interested in
this feature
It is not unreasonable to question the veracity of CRP claims.
As there are outstanding issues still unresolved, the answer is no.
Kind regards,
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
>
>
> > f) It is a well established theory that you cannot build security
> > using software alone if the there is no support for it in hardware.
>
> Stipulated that LPC won't meet your needs. Now are we done?
>
> Richard
>
Reply by ●December 25, 20052005-12-25
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> Dear Richard,
>
> The discussion on CRP is for all in this forum who are interested in
> this feature
This is a lightweight forum, hardly the place to get definitive
answers. Just a bunch of guys, hanging around on Yahoo! sharing
experiences. Some stuff will be right on, some will be completely
wrong. Or perhaps right for the wrong reasons.
Get on an airplane and go see the engineers. If your silicon
requirement is large enough, have them come see you.
Or get your customer representative involved. Hand them a list of
issues and ask for written responses, soonest. If they don't respond,
choose another supplier.
There are formal channels for resolving these kinds of things. But, I
doubt that Yahoo is one of them. In fact, this is one of the only
forums where reps of a major manufacturer even bother to reply. Most
ignore these forums entirely. I would...
Richard
>
> Dear Richard,
>
> The discussion on CRP is for all in this forum who are interested in
> this feature
This is a lightweight forum, hardly the place to get definitive
answers. Just a bunch of guys, hanging around on Yahoo! sharing
experiences. Some stuff will be right on, some will be completely
wrong. Or perhaps right for the wrong reasons.
Get on an airplane and go see the engineers. If your silicon
requirement is large enough, have them come see you.
Or get your customer representative involved. Hand them a list of
issues and ask for written responses, soonest. If they don't respond,
choose another supplier.
There are formal channels for resolving these kinds of things. But, I
doubt that Yahoo is one of them. In fact, this is one of the only
forums where reps of a major manufacturer even bother to reply. Most
ignore these forums entirely. I would...
Richard
