Desperately searching for sample secure code for LPC43Sxx

[sylvio5]

I despeately trying to get how to use :

- External RAM execution for a secure encrypted firmware on LPC43S57

- What is needed and how to write an ISP bootloader for secured device. Is a Secure Element needed ? How ?

At the end of UM10946 it's written :

Contact NXP Semiconductors for more information on third party software solutions for the LPC43S67 that utilize the A7001CM device.

How ?? There is no possibility to contact NXP Semiconductors ??

[tyler_drazich]

Hello sylvio5‌,

I too was curious about how the integrated secure booting worked on the "S" MCUs. I am surprised to learn about some of these limitations with internal flash, so I thought I'd share how I have done secure booting with software.

For example, I have a bootloader that accepts a firmware image via USB. The bootloader works with the internal flash. The bootloader supports AES encrypt/decrypt functions using a predetermined hardcoded key. There is no need for the A7 security element as the bootloader isn't generating keys etc (unlike SSL etc). The bootloader then has a write command that only accepts encrypted data, because decrypts as it receives the data. The bootloader then programs the internal flash with the decrypted program data. To keep the flash secure, before shipment, the CRP is set to lockout the JTAG and ISP (keeps IAP) functions.

I then have a .NET tool that I use to encrypt the firmware images. The tool uses the same key (configurable of course) as the bootloader. In the end, only the bootloader and the tool (which you keep internal & private) knows the key. 

I also have the bootloader support a read command, where it encrypts the program data before sending it out USB. I then use the tool again to decrypt the firmware image.

Although I have only done this over USB, this same technique could be applied to any other type of update mechanism, such as via SD card, USB stick etc.

Best Regards,

tyler.drazich‌

[sylvio5]

Hello tyler.drazich‌

Thanks for you experiment feedback. Not sure about one point when you write "the bootloader knows the key" why didn't you use the key in OTP to make it not readable at all ? Do you use the LPC standard and not the "S" series ?

At this point what I undestood - still not sure it's true - the internal flash could not be crypted because there is no need to (CRP is probably enough security level for the conceptor). But what I find very limited is the fact that when we use a secure boot we cannot set the decoded code to be stored in another RAM then the internal RAM at 0x100000. With this it makes quite no sens to have an hardware that supports a secure boot of maximum 90kB of code. with 90kB of code we are able just to run a bootloader and this is quite useless to have an encrypted bootloader...
Then there is more sens to do as you did, a bootloader in internal flash that decodes manually the encrypted image to an external RAM...

Am I right ?

[tyler_drazich]

Hi sylvio5‌,

I use my bootloader in the standard LPC parts, not the 'S'. The bootloader decrypts the firmware image as it receives it, before programming it into internal flash, so the application executes from internal flash. No need to copy to RAM. Thus, you get all of the internal flash space to use for the application, minus the size of the bootloader (about 8-20kB depending on other features) of course.

The advantage the 'S' parts provide is the ability to execute an encrypted image that resides in external flash (e.g. SPIFI). My approach only works if the image is stored in internal flash where I can hide it, since it is stored in the unsecured (decrypted) state. I then have to restrict access to the internal flash, so someone can't read out the unsecured image, but I do that with the code read protection (CRP) settings (basically disable ISP and JTAG/SWD).

Copying to an external RAM could make it possible to dump the unsecured image by attaching to the address/data buses. Maybe that's why the 'S' parts don't support copying to external address spaces?

I have some wrapped up demos of my approach that I'd be happy to share. I develop my own commercial code for these types of things (see https://dzxdesigns.com), but I do have an open source version too that you can use for example/inspiration. If you're interested, let me know which IDE/toolchain you use and I'll attach/email you a copy.

Best Regards,

tyler.drazich‌

[sylvio5]

Thank you for sharing your experiments in this domain. Just may be a question about your choice. It looks like the S series are not really more expensive as the standard one so why to not use S series microcontrollers and use the integrated AES 128 engin with the OTP to store the keys ?

This will probably what we will finally do... except if you tell me a reason to not do this.

[tyler_drazich]

Hi sylvio5‌,

I agree with you. It would be nice to use the S series and take advantage of the built in AES features.

I mentioned non-S parts because it doesn't have to be an S part, and I have used this strategy in the past before the S series parts were available.

Best Regards,

tyler.drazich‌

[sylvio5]

Hello

Thanks for your answer. So let me clarify if I understood well. 
It's not possible to boot a secured code larger than the RAM at bank 0x1000 0000. 

But is there a way to use a larger code at all ?
In example I can figure out that :
1) Image 1 : custom bootloader linked @ 0x1000 0000 ~64kB.

2) Image 2 : the custom application linked @ External RAM address.
Then the Custom bootloader do the job of de-crypting the application image to the External RAM and then set the Program Counter to that address.

Is it a realistic way of doing it ?
Do you have any code example of how to use the AES API for such operation ?

You propose to boot from SPIFI, I think what I wrote just here is kind of the opposite, writing the bootloader in the internal flash and having the application in the SPIFI. Do you see  pros or cons of one solution or the other ?
Are both possible ?

About the remark. I m not sure to get it right. You proposition is to encrypt the BIN twice ? Application -> first encryption OTP Key 1 -> seconde encryption OTP Key 2 -> BIN file on the SD. BIN file decrypted by the Bootloader with OTP Key 2 and flashed to the Internal Flash. Then at boot decrypted from internal flash to the SRAM using OTP key 1 by the boot process. Is it correct ?

Best regards and thanks a lot for your help

[jeremyzhou]

Hi Sylvio Barth,

In example I can figure out that :
1) Image 1 : custom bootloader linked @ 0x1000 0000 ~64kB.

2) Image 2 : the custom application linked @ External RAM address.
Then the Custom bootloader do the job of de-crypting the application image to the External RAM and then set the Program Counter to that address.

Is it a realistic way of doing it ?
Do you have any code example of how to use the AES API for such operation ?

I think it can works, I haven't has the similar kind of code on hand now.

You propose to boot from SPIFI, I think what I wrote just here is kind of the opposite, writing the bootloader in the internal flash and having the application in the SPIFI. Do you see  pros or cons of one solution or the other ?
Are both possible ?

Both is possible, and I think your approach is the more easily to implement, however in the approach, the MCU boot from the internal flash instead of secure boot from an encrypted image, so the security is its disadvantage.

Remark: To add the security, you can encrypt the bin file with the Key 2 from the OTP memory bank2 and decrypted by using the AES API before been programmed in the internal flash.

The SD bin file is the application code, if the bin file is encrypted before, it can add security versus to the plain-test image.

In a word, the Key1 is used by the boot code to decrypt bootloaer code which is stored in the SPIFI flash, however the Key2 is used to decrypt the application code which is read from the SD file.

Hope it helps.
Have a great day,
Ping

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

[sylvio5]

Hello jeremyzhou

I m still not sure about your proposal. Could you please explain me :

1) Is it necessary to have encrypted code in SPIFI ? Isn't it possible to have encrypted code image in internal Flash ?

2) We don't want to let permanently the application image on the SD card. The SD card should be only used as temporary storage used to copy encrypted image file to either the SPIFI or the internal flash (defined by the answer of 1).
Will it be necessary to use an A7 security element to either let run an encrypted booloader code to flash an encrypted image to either SPIFI or internal flash (IAP) or to execute  the Application code in an external RAM ? 
If yes for what task ?

3) Why is it written "secure firmware update" under the column "using A7"  on the table of that document : http://www1.futureelectronics.com/Mailing/etechs/NXP/etechALERT_NXP_LPCSeries/Brochure_LPC18SLPC43S....  ?

Thanks for your help

[jeremyzhou]

Hi Hi Sylvio Barth,

1) Is it necessary to have encrypted code in SPIFI ? Isn't it possible to have encrypted code image in internal Flash ?

    No, the boot flow for encrypted images is not available boot from the on-chip flash.

2) We don't want to let permanently the application image on the SD card. The SD card should be only used as temporary storage used to copy encrypted image file to either the SPIFI or the internal flash (defined by the answer of 1).
Will it be necessary to use an A7 security element to either let run an encrypted booloader code to flash an encrypted image to either SPIFI or internal flash (IAP) or to execute  the Application code in an external RAM ? 
If yes for what task ?

      The A7 secure element is not necessary.

Have a great day,
Ping

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

[sylvio5]

Hello jeremyzhou‌,
So now I m begging the coding of the bootloader. It's finally designed like that :
Same as Tyler did the bootloader will be stored at the begging of the internal flash and the application next to it. Then the code will be protected by the CRP.

Finally the firmware-update image files will be stored on a SD card and those will be encrypted. The idea is to use the hardware decryption engine to decrypt the file and then flash to the internal flash using IAP function.

As I read there is no limitation using IAP function either after programming the OTP keys, is that correct ?

My idea will be to encrypt the firmware image file in the same way than the secured boot image. So it will be possible to use LPScrypt encryption tool to encrypt firmware image files, I except there is no limitation to do encrypt an image that is not linked at bank 0x10 as this is done with a binary file and at all LPScrypt cannot know the linking address. Maybe there is a size limitation with encryption tool or not ?

Do you know where could I find a code example or at least pseudo code example of the decryption algoritm that I need to use if I want to decrypt manually an encoded firmware image file using the AES internal engine and a OTP key ?

This would be really helpful and could save me a lot of time as I m really newbie in this crypto world !

Thanks in advance

[jeremyzhou]

Hi Sylvio Barth ,

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

I'm afraid of I was still confused with the first two questions, so I was wondering if you can clarify.

As I know, if customer want to get A70 security support, they need signed a special NDA with NXP. This need check with A70 product line. Customer can check this with the local A70 team(marketing or CAS team).
Have a great day,
Ping

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

[sylvio5]

Hello.

Sorry if I was not precise enough. 

1) As I understood LPC43Sxx manual and LPCScrypt manual when we use encryption of firmware the code must be linked at bank 0x10 that means it will be automatically decrypted into the RAM at the address. The fact is that at this address we only get 96kB of RAM... and the internal flash is 2x512kB and we - for sure - will need firmware > then 96kB at least > 512kB. So I except we need to add in memory map external RAM memory to run firmware > 96kB. But I wonder to know how to make it in a way that the decryption engine knows where to jump in memorymap when the first 96kB are overpassed ?

I didn't found any answer or information about that neither any project example. That's a pity... and really blocked us in the development of our project. I didn't find any place to get support about that. Could you help ?

2) On this post https://community.nxp.com/message/864381?commentID=864381&et=watches.email.thread#comment-864381  Soledad wrote me that IAP functions are disabled as soon as we program an encryption key. So I wonder how to write a flashing firmware bootloader for encrypted firmware update for my project. Our client wants to be able to let the user update the firmware. On other project (using LPC43xx not encrypted) I used the IAP functions for that. Could you help me as well about this topic ?
If I ask if a A7 secure element is needed to do this; it's because of this file : http://www1.futureelectronics.com/Mailing/etechs/NXP/etechALERT_NXP_LPCSeries/Brochure_LPC18SLPC43S....  shows a diagram where the column "+A7 secure element" mentions "Secure firmware update".
Where to get this information ? Who is the A70 team for customers of Switzerland ? Will them give example program of that ? Support ?

Thanks for helping.

Sylvio

[jeremyzhou]

Hi Sylvio Barth ,

1) As I understood LPC43Sxx manual and LPCScrypt manual when we use encryption of firmware the code must be linked at bank 0x10 that means it will be automatically decrypted into the RAM at the address. The fact is that at this address we only get 96kB of RAM... and the internal flash is 2x512kB and we - for sure - will need firmware > then 96kB at least > 512kB. So I except we need to add in memory map external RAM memory to run firmware > 96kB. But I wonder to know how to make it in a way that the decryption engine knows where to jump in memorymap when the first 96kB are overpassed ?

I didn't found any answer or information about that neither any project example. That's a pity... and really blocked us in the development of our project. I didn't find any place to get support about that. Could you help ?

The image size should be set to no more than the size of the SRAM located at 0x1000 0000 when configure secure booting from an encrypted image, we can't customize or expand the range as the ROM code follows the booting flow permanently.

2) On this post https://community.nxp.com/message/864381?commentID=864381&et=watches.email.thread#comment-864381  Soledad wrote me that IAP functions are disabled as soon as we program an encryption key. So I wonder how to write a flashing firmware bootloader for encrypted firmware update for my project. Our client wants to be able to let the user update the firmware. On other project (using LPC43xx not encrypted) I used the IAP functions for that. Could you help me as well about this topic ?

First, let me clarify it, the IAP also can be used after I contact with the AE team.

And I'd like to suggest the approach to make it.

1. You can encrypt the bootloader, then store the encrypted image in the external SPIFI flash.

2. The MCU booted from the external flash, after the booting process successes, the bootloader code can read the bin file from the SD card and transfer the bin file to the internal flash.

Remark: To add the security, you can encrypt the bin file with the Key 2 from the OTP memory bank2 and decrypted by using the AES API before been programmed in the internal flash.

3.Set program counter to starting address of the application code, then run.

Regarding to get the information about the LPC43S/18Sxx secure application, you can contact with the distributor through the link below:

Distributor Network|NXP 

Hope it helps.
Have a great day,
Ping

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