Hello,
I just noticed NXP has released boot loader updates here:
http://www.standardics.nxp.com/support/documents/microcontrollers/?scope=LPC2000&type=software
For what it is worth, I looked into this latest Boot Loader 1.66
release for LPC2292. This update seems to be for three level CRP
support compared to just one in the earlier versions.
Firstly, CRP1 does not make appear to make sense. Here is its
description:
Access to chip via the JTAG pins is disabled. This mode allows partial
Flash update using the following ISP commands and restrictions:
Write to RAM command can not access RAM below 0x40000200
Copy RAM to Flash command can not write to Sector 0
Erase command can erase Sector 0 only when all sectors are selected
for erase
Compare command is disabled
This mode is useful when CRP is required and Flash field updates are
needed but all sectors can not be erased. Since compare command is
disabled in case of partial updates the secondary loader should
implement checksum mechanism to verify the integrity of the Flash.
Can anybody explain the rationale for CRP1, given the R command is not
disabled?
Secondly, on updating my LPC2292, I discovered that the CRP breach I
found in 1.64 still exists on this "latest" 1.66 version. When I get
the time I will upload the boot image for verification purposes -- the
"File" link somehow does not seem to work at the moment.
The argument by my critics here that the findings in relation to CRP
flaws were based on a "very old" version of the Boot Loader is clearly
defunct.
Regards,
Jaya
Re: NXP's Boot Loader Update does not address CRP breach notification
Started by ●April 28, 2007
Reply by ●April 28, 20072007-04-28
I was checking out that link and was reading the .PDF file
about security for LPC213x, LPC214x and saw the pasted portion below.
In particular, they mention the internal programming voltages
are not applied when it looks like the part is writing to sectors.
Maybe they wrote this in response to some of your postings, Jaya ?? {:-)
boB
WRITE/ERASE SECURITY
In the NXP ARM based microcontroller, each flash sector can be secured
against write/erase operation. This feature allows the application to
secure the sensitive code/data against tempering. If the Code Read
Protection feature is enabled then the sensitive code/data is also
protected against unauthorized reads. Please refer to the appropriate
user manual for a description of the Code Read Protection feature.
Altering the contents of a secured sector is not possible. The write
or erase operation (via ISP or IAP) on a secured sector will succeed
but the internal erase/programming voltages to alter the flash sector
contents are not generated. The write/erase security feature is
irreversible. It should only be activated in the final design phase to
avoid unusable parts/application boards. If the Code Read Protection
is enabled along with the write/erase security on sector 0 then the
Code Read Protection feature is also irreversible. However an
application executing from the internal memory will still be able to
communicate with the external world, if implemented by the system
designer. The flash sectors which are not secured against write/erase
can be erased/reprogrammed by such application. A write/erase
operation spanning across a secured and an unsecured sectors will not
alter the contents of either secured or unsecured sectors.
The write/erase security is enabled by calling the
write_erase_secure_user_sector() function. This function is available
in the library file. A 'C' header file (write_erase_secure.h) is also
provided. While sectors are being secured the flash memory is not
available for code execution hence it is very important to relocate
functions in RAM during run time. Please refer to the linker
documentation for details. The following section describes the
functions available in the library. The function return codes are
described in Table 4.
--- In l..., "jayasooriah" wrote:
>
> Hello,
>
> I just noticed NXP has released boot loader updates here:
http://www.standardics.nxp.com/support/documents/microcontrollers/?scope=LPC2000&type=software
>
> For what it is worth, I looked into this latest Boot Loader 1.66
> release for LPC2292. This update seems to be for three level CRP
> support compared to just one in the earlier versions.
>
> Firstly, CRP1 does not make appear to make sense. Here is its
> description:
>
> Access to chip via the JTAG pins is disabled. This mode allows partial
> Flash update using the following ISP commands and restrictions:
>
> Write to RAM command can not access RAM below 0x40000200
> Copy RAM to Flash command can not write to Sector 0
> Erase command can erase Sector 0 only when all sectors are selected
> for erase
> Compare command is disabled
>
> This mode is useful when CRP is required and Flash field updates are
> needed but all sectors can not be erased. Since compare command is
> disabled in case of partial updates the secondary loader should
> implement checksum mechanism to verify the integrity of the Flash.
>
> Can anybody explain the rationale for CRP1, given the R command is not
> disabled?
>
> Secondly, on updating my LPC2292, I discovered that the CRP breach I
> found in 1.64 still exists on this "latest" 1.66 version. When I get
> the time I will upload the boot image for verification purposes -- the
> "File" link somehow does not seem to work at the moment.
>
> The argument by my critics here that the findings in relation to CRP
> flaws were based on a "very old" version of the Boot Loader is clearly
> defunct.
>
> Regards,
>
> Jaya
>
about security for LPC213x, LPC214x and saw the pasted portion below.
In particular, they mention the internal programming voltages
are not applied when it looks like the part is writing to sectors.
Maybe they wrote this in response to some of your postings, Jaya ?? {:-)
boB
WRITE/ERASE SECURITY
In the NXP ARM based microcontroller, each flash sector can be secured
against write/erase operation. This feature allows the application to
secure the sensitive code/data against tempering. If the Code Read
Protection feature is enabled then the sensitive code/data is also
protected against unauthorized reads. Please refer to the appropriate
user manual for a description of the Code Read Protection feature.
Altering the contents of a secured sector is not possible. The write
or erase operation (via ISP or IAP) on a secured sector will succeed
but the internal erase/programming voltages to alter the flash sector
contents are not generated. The write/erase security feature is
irreversible. It should only be activated in the final design phase to
avoid unusable parts/application boards. If the Code Read Protection
is enabled along with the write/erase security on sector 0 then the
Code Read Protection feature is also irreversible. However an
application executing from the internal memory will still be able to
communicate with the external world, if implemented by the system
designer. The flash sectors which are not secured against write/erase
can be erased/reprogrammed by such application. A write/erase
operation spanning across a secured and an unsecured sectors will not
alter the contents of either secured or unsecured sectors.
The write/erase security is enabled by calling the
write_erase_secure_user_sector() function. This function is available
in the library file. A 'C' header file (write_erase_secure.h) is also
provided. While sectors are being secured the flash memory is not
available for code execution hence it is very important to relocate
functions in RAM during run time. Please refer to the linker
documentation for details. The following section describes the
functions available in the library. The function return codes are
described in Table 4.
--- In l..., "jayasooriah" wrote:
>
> Hello,
>
> I just noticed NXP has released boot loader updates here:
http://www.standardics.nxp.com/support/documents/microcontrollers/?scope=LPC2000&type=software
>
> For what it is worth, I looked into this latest Boot Loader 1.66
> release for LPC2292. This update seems to be for three level CRP
> support compared to just one in the earlier versions.
>
> Firstly, CRP1 does not make appear to make sense. Here is its
> description:
>
> Access to chip via the JTAG pins is disabled. This mode allows partial
> Flash update using the following ISP commands and restrictions:
>
> Write to RAM command can not access RAM below 0x40000200
> Copy RAM to Flash command can not write to Sector 0
> Erase command can erase Sector 0 only when all sectors are selected
> for erase
> Compare command is disabled
>
> This mode is useful when CRP is required and Flash field updates are
> needed but all sectors can not be erased. Since compare command is
> disabled in case of partial updates the secondary loader should
> implement checksum mechanism to verify the integrity of the Flash.
>
> Can anybody explain the rationale for CRP1, given the R command is not
> disabled?
>
> Secondly, on updating my LPC2292, I discovered that the CRP breach I
> found in 1.64 still exists on this "latest" 1.66 version. When I get
> the time I will upload the boot image for verification purposes -- the
> "File" link somehow does not seem to work at the moment.
>
> The argument by my critics here that the findings in relation to CRP
> flaws were based on a "very old" version of the Boot Loader is clearly
> defunct.
>
> Regards,
>
> Jaya
>
Reply by ●April 28, 20072007-04-28
--- In l..., "bobtransformer" wrote:
>
> I was checking out that link and was reading the .PDF file
> about security for LPC213x, LPC214x and saw the pasted portion below.
> In particular, they mention the internal programming voltages
> are not applied when it looks like the part is writing to sectors.
> Maybe they wrote this in response to some of your postings, Jaya ?? {:-)
>
> boB
>
> WRITE/ERASE SECURITY
> In the NXP ARM based microcontroller, each flash sector can be secured
> against write/erase operation. This feature allows the application to
> secure the sensitive code/data against tempering. If the Code Read
> Protection feature is enabled then the sensitive code/data is also
> protected against unauthorized reads. Please refer to the appropriate
> user manual for a description of the Code Read Protection feature.
> Altering the contents of a secured sector is not possible. The write
> or erase operation (via ISP or IAP) on a secured sector will succeed
> but the internal erase/programming voltages to alter the flash sector
> contents are not generated. The write/erase security feature is
> irreversible. It should only be activated in the final design phase to
> avoid unusable parts/application boards. If the Code Read Protection
> is enabled along with the write/erase security on sector 0 then the
> Code Read Protection feature is also irreversible. However an
> application executing from the internal memory will still be able to
> communicate with the external world, if implemented by the system
> designer. The flash sectors which are not secured against write/erase
> can be erased/reprogrammed by such application. A write/erase
> operation spanning across a secured and an unsecured sectors will not
> alter the contents of either secured or unsecured sectors.
> The write/erase security is enabled by calling the
> write_erase_secure_user_sector() function. This function is available
> in the library file. A 'C' header file (write_erase_secure.h) is also
> provided. While sectors are being secured the flash memory is not
> available for code execution hence it is very important to relocate
> functions in RAM during run time. Please refer to the linker
> documentation for details. The following section describes the
> functions available in the library. The function return codes are
> described in Table 4.
>
Hi Bob,
If we believe everything said above, it should not have been possible
for me to expose the contents of "secured sectors" -- without even trying.
Incidentally, I am often asked what I mean by "without even trying".
It is not meant to say I was doing anything clever. I was not trying
to break CRP at all. I was doing things (for a completely different
purpose and which I rather not discuss) and it so happens these
operations resulted in exposing "secured sectors".
I would not have known about this had I not been told by others that
certain sectors appear not to get erased as they thought it should
when they used SILL to "recover" CRP enabled parts. I suspect there
are other out there breaking CRP every day but they just dont know
about it.
I am told NXP can legally continue to make such claims so long as it
is not aware of the CRP breaches, and that it will continue to be
unaware of these CRP breaches if it ignores notifications to the contrary.
What is interesting to me personally is that NXP seems to have dropped
their MAM and CRP, opened up the flash controller architecture, and no
longer supply "IAP" interface code on LPC288x -- the very components
in the LPC2000 family that I had been critical off.
Jaya
PS: If this was in response to my posts, then I am afraid I am not
used to sparring in two different boxing rings :)
>
> I was checking out that link and was reading the .PDF file
> about security for LPC213x, LPC214x and saw the pasted portion below.
> In particular, they mention the internal programming voltages
> are not applied when it looks like the part is writing to sectors.
> Maybe they wrote this in response to some of your postings, Jaya ?? {:-)
>
> boB
>
> WRITE/ERASE SECURITY
> In the NXP ARM based microcontroller, each flash sector can be secured
> against write/erase operation. This feature allows the application to
> secure the sensitive code/data against tempering. If the Code Read
> Protection feature is enabled then the sensitive code/data is also
> protected against unauthorized reads. Please refer to the appropriate
> user manual for a description of the Code Read Protection feature.
> Altering the contents of a secured sector is not possible. The write
> or erase operation (via ISP or IAP) on a secured sector will succeed
> but the internal erase/programming voltages to alter the flash sector
> contents are not generated. The write/erase security feature is
> irreversible. It should only be activated in the final design phase to
> avoid unusable parts/application boards. If the Code Read Protection
> is enabled along with the write/erase security on sector 0 then the
> Code Read Protection feature is also irreversible. However an
> application executing from the internal memory will still be able to
> communicate with the external world, if implemented by the system
> designer. The flash sectors which are not secured against write/erase
> can be erased/reprogrammed by such application. A write/erase
> operation spanning across a secured and an unsecured sectors will not
> alter the contents of either secured or unsecured sectors.
> The write/erase security is enabled by calling the
> write_erase_secure_user_sector() function. This function is available
> in the library file. A 'C' header file (write_erase_secure.h) is also
> provided. While sectors are being secured the flash memory is not
> available for code execution hence it is very important to relocate
> functions in RAM during run time. Please refer to the linker
> documentation for details. The following section describes the
> functions available in the library. The function return codes are
> described in Table 4.
>
Hi Bob,
If we believe everything said above, it should not have been possible
for me to expose the contents of "secured sectors" -- without even trying.
Incidentally, I am often asked what I mean by "without even trying".
It is not meant to say I was doing anything clever. I was not trying
to break CRP at all. I was doing things (for a completely different
purpose and which I rather not discuss) and it so happens these
operations resulted in exposing "secured sectors".
I would not have known about this had I not been told by others that
certain sectors appear not to get erased as they thought it should
when they used SILL to "recover" CRP enabled parts. I suspect there
are other out there breaking CRP every day but they just dont know
about it.
I am told NXP can legally continue to make such claims so long as it
is not aware of the CRP breaches, and that it will continue to be
unaware of these CRP breaches if it ignores notifications to the contrary.
What is interesting to me personally is that NXP seems to have dropped
their MAM and CRP, opened up the flash controller architecture, and no
longer supply "IAP" interface code on LPC288x -- the very components
in the LPC2000 family that I had been critical off.
Jaya
PS: If this was in response to my posts, then I am afraid I am not
used to sparring in two different boxing rings :)
