Secure bootloading with LPC11U68?

[mattferrari]

Regardless of whether you use CRP0, CRP1 or CRP2, anyone can destroy your product simply by erasing all the memory via the built-in bootloader.  There's no way to stop that.  CRP1 promises to protect Sector-0, but not if ALL the memory is erased.  Not secure.  The only way to be secure is to use CRP3, but then you lose the built-in bootloader.  

The only solution appears to be to (a) lock the part down using CRP3 and (b) code your own USB bootloader so that you have the chance to qualify any downloaded code before it is allowed to run.

I have seen many posts about this very concern, but have yet to see a definitive solution for the LPC11U68.

Via the LPCXpresso IDE, many code examples are offered for many peripherals.  Since this LPC11 security issue is such a concern, wouldn't it make sense for NXP to simply provide a code example for a secondary USB bootloader?  Then users could make simple modifications to it to protect certain sectors as needed.

Right now, LPC11 users need to choose between a completely vulnerable solution or lose their bootloading feature.  Not a great choice to have to make!   And many of us don't have the USB expertise to code our own USB bootloader.

Instead of requiring every user to re-invent the wheel, how about if NXP provides a secondary bootloader code example to address this shortcoming.  If there are already solutions, would someone please refer me to them?  Perhaps there IS already a code example available, or an App Note with code in it?  Or maybe someone has already coded it up and is willing to share?  That would be awesome!  If there is anything available, I would appreciate a reference to it.

Any help will be appreciated!  I was planning on CRP1 & Sector-0 to be my solution and was heartbroken when I realized that Sector-0 is in fact not secure with CRP-1 and can be easily blown away.  Some micros have the ability to apply security on a Sector basis, but sadly the LPC11U68 does not seem to have that capability (am I wrong about that?)

Thanks for any help with this issue - I really appreciate it!

Matt

[jeremyzhou]

Hi Matt Ferrari,

I've requested the LPCXpresso board LPC1347 to do the CRP testing.

Yes, it seems a little confused and CRP1 security feature is not enabled in the USB ISP.

After complete the testing, I will share the explanation with you.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jeremyzhou]

Hi Matt Ferrari ,

Thank you for interest in NXP Semiconductor products and the opportunity to serve you.

I've found that you had created some threads about the question, and I'll reply the in the thread Does USB Bootloading in CRP1 always erase all Flash? .

However other thread will be closed later.

Thanks for your understanding.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mattferrari]

Hi Ping - 

The two threads are actually quite different.  One is asking about the function of CRP1 and Sector-0, the other is asking for a code example of a Secondary USB Bootloader for the LPC11U68.  I'm not sure why you would want to combine these?  I have thoroughly researched the available App Notes and found that there ARE code example projects for a Secondary USB Bootloader for several other micros (like the LPC1768).  Can you please provide an example code project for the LPC11U68?  Considering that Sector-0 cannot be secured, it appears that using CRP3 along with a Seconday USB Bootloader is the only solution. I don't have the USB expertise to code my own USB Bootloader, which is why I designed in the LPC11U68 - because it already had one built in.  But now I've found that it can't be secured.  So what's really important is to get this code example for the LPC11U68.  This truly is a different issue than the CRP question.  I hope you can provide me with this example project soon.

Thanks Ping.

[jeremyzhou]

Hi Matt Ferrari ,

In my opinion, these questions are about the CRP setting and implementation.

For me, it's convenience to provide the support in only one thread.

About the second the question: design a Secondary USB Bootloader, let me summarize it.

According to your statement, the sector 0 seems like to be independent with the application code and the sector 0 is unaffected by the USB updating operation, is it right?

I've have another further question, as you said the sector 0 should be protected , do you mean that the sector 0 can't be read and write by other guys?
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mattferrari]

No - I think you've misunderstood me.  By "protected" I mean that when using CRP1, nothing in Sector-0 will change when other new data is written to the other Sectors.  I think this quotation from NXP App Note 10968 says what is "supposed" to happen perfectly:

CRP Level 1 is designed to prevent read access to the device while enabling
modification of flash memory on a sector by sector basis. Note that sector 0 can only be
erased when fully erasing the device, and cannot be written to when CRP1 is enabled.
This effectively prevents modification to sector 0. CRP1 is required, for example, when a
design dedicates one or more sectors of flash to storing calibration information or serial
numbers, etc. If a full chip erase were to take place during a firmware update, this
calibration information would be lost. CRP1 can also be useful, for example, should a
design implement a custom secured bootloader. This would program sector 0 and only 

allow field updates to modify the “application” sectors while enabling the bootloader to
persist in an unmodified state.

This was what I was counting on when I selected the LCP11U68 for my design.  Sadly, this claim about being able to use Sector-0 for a "secured bootloader" is completely misleading.  You CANNOT implement a secure anything as this paragraph suggests, because any download which fully erases the device (i.e. writes data to all Sectors) will result in the erasure of not only the "application", but also whatever is residing in Sector-0 as well.  That's not secure at all - it's completely vulnerable.

According to this excerpt from App Note 10968, I should be able to set CRP = CRP1, then write to a few Sectors to the chip and (as the App Note claims) "effectively prevent modification to Sector-0".  But, as I have described several times, when I set CRP = CRP1, then via USB Bootloader, delete "firmware.bin" and copy in the code for the new Sectors, Sector-0 winds up getting erased in the process.

It was my intention to use CRP1 and Sector-0 as a secure "gate keeper" to qualify code downloaded via the LPC11U68's built-in USB Bootloader before allowing it to run, but sadly, the statement that "the bootloader will persist in an unmodified state" and the statement that "sector 0 can ... be erased when fully erasing the device" are at odds with each other and do not constitute anything "secure" at all.  

This is why I think the only solution is to secure the part using CRP3 and code a full USB Secondary Bootloader customized to qualify downloaded code before allowing it to run.  And this is why I'm asking if you can provide me with an example LPCXpresso project for such a USB Secondary Bootloader.  Such LPCXpresso projects for USB Secondary Bootloaders already exist for several of your other processors (e.g. LPC1768).  As I have mentioned, I designed in the LPC11U68 - because it had the bootloader built in and claimed that I could use CRP1 to secure Sector-0.  This is just not proving to be true.

If the chip truly is capable of doing this:

"CRP1 can also be useful, for example, should a design implement a custom secured bootloader. This would program sector 0 and only 

allow field updates to modify the “application” sectors while enabling the bootloader to persist in an unmodified state.

then please explain how it can be done, and why this is not working for me - because right now, it's easy to delete Sector-0 any time you delete "firmware.bin" and copy over some new Sector data.  

My guess is that the act of deleting "firmware.bin" via the USB Bootloader interface to the PC is causing the complete flash to be erased.  Maybe the behavior described in the above quote works for other ISP interfaces other than USB, such as UART - I don't know, but it doesn't work via the LPC11U68's built-in USB Bootloader.  Believe me - I wouldn't be spending all this time writing posts if it was working.

So will you please provide me with an example LPCXpresso project for a LPC11U68 USB Secondary Bootloader like you have for some of your other processors?  It's appearing that this will be the only solution.

Matt