Robert, what I am doing is exactly that -- sharing experiences. Not
sure why you seem to want to quench the discussion on CRP and security.
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> 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.
Flash Security Clarification
Started by ●December 22, 2005
Reply by ●December 25, 20052005-12-25
Reply by ●December 25, 20052005-12-25
Exactly, that's my point. If you accept that the bootloader is free of
bugs,
you can be reasonably sure that there are no holes left. At least there are
no conceptual holes.
If you take possible bugs into account, there is no safe CRP. But that's a
choice that is up to you.
Regards,
Dominic
On Sunday 25 December 2005 23:21, jayasooriah wrote:
> 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
you can be reasonably sure that there are no holes left. At least there are
no conceptual holes.
If you take possible bugs into account, there is no safe CRP. But that's a
choice that is up to you.
Regards,
Dominic
On Sunday 25 December 2005 23:21, jayasooriah wrote:
> 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
Reply by ●December 25, 20052005-12-25
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> Robert, what I am doing is exactly that -- sharing experiences. Not
> sure why you seem to want to quench the discussion on CRP and
security.
I guess I am just bored of the month long harangue of Philips. This
isn't a discussion, it is a prolonged attack without one shred of
proof that Philips is either incorrect or hiding something.
I just read through the section in the LPC2292 datasheet (3d paragraph
of section 6.2) - it seems pretty clear to me.
JTAG doesn't talk to the hardware for programming, it uses IAP which
is implemented in the boot code. This from Errata IPA1, 14 NOV 2005.
One can suppose that the boot code knows what to do about JTAG access
to flash given that the boot code does that actual programming as well
as implementing CRP. If Philips says JTAG is disabled if CRP is
enabled, where is the proof that they are wrong?
Go to the source, get the answers in writing, share the results, if
they aren't covered by an NDA. Again, there are formal channels for
this.
Richard
>
> Robert, what I am doing is exactly that -- sharing experiences. Not
> sure why you seem to want to quench the discussion on CRP and
security.
I guess I am just bored of the month long harangue of Philips. This
isn't a discussion, it is a prolonged attack without one shred of
proof that Philips is either incorrect or hiding something.
I just read through the section in the LPC2292 datasheet (3d paragraph
of section 6.2) - it seems pretty clear to me.
JTAG doesn't talk to the hardware for programming, it uses IAP which
is implemented in the boot code. This from Errata IPA1, 14 NOV 2005.
One can suppose that the boot code knows what to do about JTAG access
to flash given that the boot code does that actual programming as well
as implementing CRP. If Philips says JTAG is disabled if CRP is
enabled, where is the proof that they are wrong?
Go to the source, get the answers in writing, share the results, if
they aren't covered by an NDA. Again, there are formal channels for
this.
Richard
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.
> 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
Current CRP implementated by Philips should be secure enough.
Please look at the CHIP from TOP-DOWN, the bigger picture:
If only programming method is through Serial Port, why using
software CRP is not safe??
- Assuming JTAG port is locked down properly, and the is no
undocumented parallel port programming.
What is the problem of using software CRP??
The other Atmel/Pic chip are having parallel, Serial-SPI
and etc types of programming, hence they need extra CRP locking
hardware. All these are hardware flash programming state machines.
Regards /MH
> 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
Current CRP implementated by Philips should be secure enough.
Please look at the CHIP from TOP-DOWN, the bigger picture:
If only programming method is through Serial Port, why using
software CRP is not safe??
- Assuming JTAG port is locked down properly, and the is no
undocumented parallel port programming.
What is the problem of using software CRP??
The other Atmel/Pic chip are having parallel, Serial-SPI
and etc types of programming, hence they need extra CRP locking
hardware. All these are hardware flash programming state machines.
Regards /MH
Reply by ●December 25, 20052005-12-25
On Monday 26 December 2005 02:37, rtstofer wrote:
> I guess I am just bored of the month long harangue of Philips. This
> isn't a discussion, it is a prolonged attack without one shred of
> proof that Philips is either incorrect or hiding something.
Sorry, but please ignore the remainder of this thread. Seems there are more
people interested in this discussion than those that want to see it stopped.
> I just read through the section in the LPC2292 datasheet (3d paragraph
> of section 6.2) - it seems pretty clear to me.
>
> JTAG doesn't talk to the hardware for programming, it uses IAP which
> is implemented in the boot code. This from Errata IPA1, 14 NOV 2005.
> One can suppose that the boot code knows what to do about JTAG access
> to flash given that the boot code does that actual programming as well
> as implementing CRP. If Philips says JTAG is disabled if CRP is
> enabled, where is the proof that they are wrong?
If you're able to access JTAG on the device, you're done. This isn't Philips'
fault, nor is there anything (reasonable) they could do against it. I doubt
ARM lets them modify the ARM7TDMI-S macrocell to that extent. JTAG allows you
to control the core, and is only bound by the limits that apply to any code
that runs on the device. The manual is unclear regarding when JTAG is enabled
and disabled - that's why I've tested it myself. I believe the LPCs are safe
in that regard.
> Go to the source, get the answers in writing, share the results, if
> they aren't covered by an NDA. Again, there are formal channels for
> this.
If any information regarding CPR was available only under an NDA that would
make me even more suspicious. Guess we're from two different worlds.
>
> Richard
Regards,
Dominic
> I guess I am just bored of the month long harangue of Philips. This
> isn't a discussion, it is a prolonged attack without one shred of
> proof that Philips is either incorrect or hiding something.
Sorry, but please ignore the remainder of this thread. Seems there are more
people interested in this discussion than those that want to see it stopped.
> I just read through the section in the LPC2292 datasheet (3d paragraph
> of section 6.2) - it seems pretty clear to me.
>
> JTAG doesn't talk to the hardware for programming, it uses IAP which
> is implemented in the boot code. This from Errata IPA1, 14 NOV 2005.
> One can suppose that the boot code knows what to do about JTAG access
> to flash given that the boot code does that actual programming as well
> as implementing CRP. If Philips says JTAG is disabled if CRP is
> enabled, where is the proof that they are wrong?
If you're able to access JTAG on the device, you're done. This isn't Philips'
fault, nor is there anything (reasonable) they could do against it. I doubt
ARM lets them modify the ARM7TDMI-S macrocell to that extent. JTAG allows you
to control the core, and is only bound by the limits that apply to any code
that runs on the device. The manual is unclear regarding when JTAG is enabled
and disabled - that's why I've tested it myself. I believe the LPCs are safe
in that regard.
> Go to the source, get the answers in writing, share the results, if
> they aren't covered by an NDA. Again, there are formal channels for
> this.
If any information regarding CPR was available only under an NDA that would
make me even more suspicious. Guess we're from two different worlds.
>
> Richard
Regards,
Dominic
Reply by ●December 25, 20052005-12-25
> > 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
>
Agreed, when you place the purchase order, ask for a guarantee that
the boot loader will provide adequate protection as you define it.
If they won't provide such a guarantee, pick another supplier.
But, you might as well start new vendor selection now. Nobody is
going to guarantee that anything is 'perfect'.
Look at the disclaimers for medical or nuclear use. Nobody wants
their commercial product in life support or hazardous applications.
There are enough chips to sell without having to provide custom
guarantees.
Richard
Reply by ●December 26, 20052005-12-26
Richard,
Perhaps if I give you a hint of what is in the T command does, I hope
you will change your mind as to what this CRP and security discussion
is really about.
If we are to trust the boot loader, and that all we need to know about
it has been disclosed by Philips, then what is this 'T' command that
is exists in boot loader 1.52 for LPC 21/4/5/6?
The T command accepts arguments like the other commands. It prints
things and for the casual user, exits and does notthing more.
However, if you twiddled GPIO pins 0-7 when the T command is invoked,
something a different piece of code is called. This only happens if
GPIO pins are non-zero when the T command is invoked.
Would you not be interested to know what this undocumented 'T' command
in the boot loader version 1.52 for LPC2104/5/6 does, that has hidden
functions?
Does it also exist on the boot loader for parts which support CRP? Is
the T command disabled when CRP is enabled? If not, can it be used to
read memory that is otherwise protected?
I am not suggesting there is a conspiracy theory. I do not see any
point in tring to double guess its functionality until Philips comes
back to work and tells us about this.
However, the existence of the T command (irrespective of whatever it
does) it is enough reason point out that boot loader holds more than
what we think it holds.
Therefore, CRP enabled or not, it would not be a good idea to include
LPC in your trust domain if you do not want your code to be exposed to
preying eyes.
I am sure you would agree many in this forum would like to know what
this T command does, even if does not do anything harmful.
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> Protecting information is not the same as concealing a defect.
Perhaps if I give you a hint of what is in the T command does, I hope
you will change your mind as to what this CRP and security discussion
is really about.
If we are to trust the boot loader, and that all we need to know about
it has been disclosed by Philips, then what is this 'T' command that
is exists in boot loader 1.52 for LPC 21/4/5/6?
The T command accepts arguments like the other commands. It prints
things and for the casual user, exits and does notthing more.
However, if you twiddled GPIO pins 0-7 when the T command is invoked,
something a different piece of code is called. This only happens if
GPIO pins are non-zero when the T command is invoked.
Would you not be interested to know what this undocumented 'T' command
in the boot loader version 1.52 for LPC2104/5/6 does, that has hidden
functions?
Does it also exist on the boot loader for parts which support CRP? Is
the T command disabled when CRP is enabled? If not, can it be used to
read memory that is otherwise protected?
I am not suggesting there is a conspiracy theory. I do not see any
point in tring to double guess its functionality until Philips comes
back to work and tells us about this.
However, the existence of the T command (irrespective of whatever it
does) it is enough reason point out that boot loader holds more than
what we think it holds.
Therefore, CRP enabled or not, it would not be a good idea to include
LPC in your trust domain if you do not want your code to be exposed to
preying eyes.
I am sure you would agree many in this forum would like to know what
this T command does, even if does not do anything harmful.
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> Protecting information is not the same as concealing a defect.
Reply by ●December 26, 20052005-12-26
Richard,
Perhaps if I give you a hint of what is in the T command does, I hope
you will change your mind as to what this CRP and security discussion
is really about.
If we are to trust the boot loader, and that all we need to know about
it has been disclosed by Philips, then what is this 'T' command that
is exists in boot loader 1.52 for LPC 21/4/5/6?
The T command accepts arguments like the other commands. It prints
things and for the casual user, exits and does notthing more.
However, if you twiddled GPIO pins 0-7 when the T command is invoked,
something a different piece of code is called. This only happens if
GPIO pins are non-zero when the T command is invoked.
Would you not be interested to know what this undocumented 'T' command
in the boot loader version 1.52 for LPC2104/5/6 does, that has hidden
functions?
Does it also exist on the boot loader for parts which support CRP? Is
the T command disabled when CRP is enabled? If not, can it be used to
read memory that is otherwise protected?
I am not suggesting there is a conspiracy theory. I do not see any
point in tring to double guess its functionality until Philips comes
back to work and tells us about this.
However, the existence of the T command (irrespective of whatever it
does) it is enough reason point out that boot loader holds more than
what we think it holds.
Therefore, CRP enabled or not, it would not be a good idea to include
LPC in your trust domain if you do not want your code to be exposed to
preying eyes.
I am sure you would agree many in this forum would like to know what
this T command does, even if does not do anything harmful.
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> Protecting information is not the same as concealing a defect.
Perhaps if I give you a hint of what is in the T command does, I hope
you will change your mind as to what this CRP and security discussion
is really about.
If we are to trust the boot loader, and that all we need to know about
it has been disclosed by Philips, then what is this 'T' command that
is exists in boot loader 1.52 for LPC 21/4/5/6?
The T command accepts arguments like the other commands. It prints
things and for the casual user, exits and does notthing more.
However, if you twiddled GPIO pins 0-7 when the T command is invoked,
something a different piece of code is called. This only happens if
GPIO pins are non-zero when the T command is invoked.
Would you not be interested to know what this undocumented 'T' command
in the boot loader version 1.52 for LPC2104/5/6 does, that has hidden
functions?
Does it also exist on the boot loader for parts which support CRP? Is
the T command disabled when CRP is enabled? If not, can it be used to
read memory that is otherwise protected?
I am not suggesting there is a conspiracy theory. I do not see any
point in tring to double guess its functionality until Philips comes
back to work and tells us about this.
However, the existence of the T command (irrespective of whatever it
does) it is enough reason point out that boot loader holds more than
what we think it holds.
Therefore, CRP enabled or not, it would not be a good idea to include
LPC in your trust domain if you do not want your code to be exposed to
preying eyes.
I am sure you would agree many in this forum would like to know what
this T command does, even if does not do anything harmful.
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> Protecting information is not the same as concealing a defect.
Reply by ●December 26, 20052005-12-26
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> Richard,
>
> Perhaps if I give you a hint of what is in the T command does, I
hope
> you will change your mind as to what this CRP and security
discussion
> is really about.
I would be more interested if the question was related to CRP or
Flash Security as the subject reads. Your issue is with a version
of the boot code that runs on a device that doesn't support CRP. By
the way, it is the version in my 2106, as well. I can't say I much
care how the boot code works, as long as I can load the flash with
the factory provided utility. I know I don't have CRP and don't
care.
For the 2294, the current boot code is at least ver 1.63 and CRP
wasn't implemented until ver 1.60. Is there a T command in the
latest version of the boot code for the 2294? If not, the question
above is irrelevant. And that is the issue - there is not one shred
of evidence that the boot code, as implemented, doesn't work as
described in the datasheet and errata.
You have stated that a software approach to security was not
acceptable for your application. If this is your position, you will
never be satisfied with Philips. Why pursue it?
Richard
wrote:
>
> Richard,
>
> Perhaps if I give you a hint of what is in the T command does, I
hope
> you will change your mind as to what this CRP and security
discussion
> is really about.
I would be more interested if the question was related to CRP or
Flash Security as the subject reads. Your issue is with a version
of the boot code that runs on a device that doesn't support CRP. By
the way, it is the version in my 2106, as well. I can't say I much
care how the boot code works, as long as I can load the flash with
the factory provided utility. I know I don't have CRP and don't
care.
For the 2294, the current boot code is at least ver 1.63 and CRP
wasn't implemented until ver 1.60. Is there a T command in the
latest version of the boot code for the 2294? If not, the question
above is irrelevant. And that is the issue - there is not one shred
of evidence that the boot code, as implemented, doesn't work as
described in the datasheet and errata.
You have stated that a software approach to security was not
acceptable for your application. If this is your position, you will
never be satisfied with Philips. Why pursue it?
Richard
Reply by ●December 26, 20052005-12-26
Hi All,
If somebody with 2294 and version 1.63 of the boot loader can confirm
the T command exists, please do tell me and I am happy to RE the code
and to find out if T commmand does anything like that in version 1.52
boot loader for 2104/5/6.
Richard,
As to your "shred of evidence" comment, the document clearly states
that on RESET, JTAG is DISABLED, and that it is only enabled BY
SOFTWARE when CRP is not enabled.
The very first three instructions of the start up code code on a CRP
supported device demonstrates otherwise. I am puzzled why you still
believe there is not a shred of evidence that the hardware does not do
what Philips would want us to believe it does.
As another poster pointed out, CEP appears to be something Philips
came up as an afterthought well after hardware implentation in
silicon. So I am interested in how well such a CRP regime will work
as I am sure many others would.
I am curioius why you sound so rattled when I question if CRP really
does what it was intended to do, and why you are so keen on quenching
this discussion.
I promise ... wont engage in bilateral discussion with you through
this forum any more. We really should wait untill Philips is back
from hols. I am happy to take it off this forum onto direct email.
You know how to reach me :)
Regards,
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> I would be more interested if the question was related to CRP or
> For the 2294, the current boot code is at least ver 1.63 and CRP
> wasn't implemented until ver 1.60. Is there a T command in the
> latest version of the boot code for the 2294?
> If not, the question
> above is irrelevant. And that is the issue - there is not one shred
> of evidence that the boot code, as implemented, doesn't work as
> described in the datasheet and errata.
>
> You have stated that a software approach to security was not
> acceptable for your application. If this is your position, you will
> never be satisfied with Philips. Why pursue it?
>
> Richard
If somebody with 2294 and version 1.63 of the boot loader can confirm
the T command exists, please do tell me and I am happy to RE the code
and to find out if T commmand does anything like that in version 1.52
boot loader for 2104/5/6.
Richard,
As to your "shred of evidence" comment, the document clearly states
that on RESET, JTAG is DISABLED, and that it is only enabled BY
SOFTWARE when CRP is not enabled.
The very first three instructions of the start up code code on a CRP
supported device demonstrates otherwise. I am puzzled why you still
believe there is not a shred of evidence that the hardware does not do
what Philips would want us to believe it does.
As another poster pointed out, CEP appears to be something Philips
came up as an afterthought well after hardware implentation in
silicon. So I am interested in how well such a CRP regime will work
as I am sure many others would.
I am curioius why you sound so rattled when I question if CRP really
does what it was intended to do, and why you are so keen on quenching
this discussion.
I promise ... wont engage in bilateral discussion with you through
this forum any more. We really should wait untill Philips is back
from hols. I am happy to take it off this forum onto direct email.
You know how to reach me :)
Regards,
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> I would be more interested if the question was related to CRP or
> For the 2294, the current boot code is at least ver 1.63 and CRP
> wasn't implemented until ver 1.60. Is there a T command in the
> latest version of the boot code for the 2294?
> If not, the question
> above is irrelevant. And that is the issue - there is not one shred
> of evidence that the boot code, as implemented, doesn't work as
> described in the datasheet and errata.
>
> You have stated that a software approach to security was not
> acceptable for your application. If this is your position, you will
> never be satisfied with Philips. Why pursue it?
>
> Richard
