Is there end-2-end software encryption middleware for NXP MCUs?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Is there end-2-end software encryption middleware for NXP MCUs?

304 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by OldManVimes on Sun Jul 27 05:51:20 MST 2014
Hello all,

Allow you to make use of your collective knowledge. I want to protect the upgrade-able software inside a MCU from prying eyes.

That translates to the following idea: I am looking for a software stack that implements robust firmware upgrade of encrypted images towards Cortex-M3 NXP MCUs. The aim is to create a device that has fair protection against reverse engineering of the firmware inside the MCU. The system requires firmware upgrade of the MCU at the end-user, so the firmware images and the process of upgrading requires protection in the form of encryption.

I know about the encryption library NXP provides. I've also found an open source boot-loader that implements decryption of firmware images, but it is not complete.
Using these elements I might be able to create the necessary infrastructure, but can spend my time otherwise and am considering (commercial) offerings. Besides, I am no security expert.

What I am looking for is a proven solution that does the following:
- Provides a boot-loader that supports firmware upgrade (via the ISP UART) of encrypted images to the internal device flash
- Robust for power loss during firmware installation (i.e. never 'brick' the device since ISP support will be disabled in the MCU)
- Boot the un-encrypted application from flash via the boot-loader if it is valid. An application is valid only after completion of the firmware upgrade (see power loss requirement).
- Allow restarting the boot-loader in firmware upgrade mode (triggered from inside the running application)
- Capability to change the key over time (this has implications for the boot-loader since the key must be available to it) I'm open to discuss the need for this requirement.
- Host OS tools (at least Windows) for creating encrypted firmware images
- Source code that can be integrated into an existing C/C++ application (win32) that handles the upgrade process towards the MCU. The software should allow me to hook my own UART device (because it's custom).
- Documentation (and possibly support)

I am willing to spend some time on the integration of this, but the middleware should do the heavy lifting and save me quite a bit of time. It is my understanding that this, in combination with a sufficiently limiting CRP value, will make my device firmware fairly robust against reverse engineering efforts. Is there any evidence that this is not true? If anyone wishes to read the flash memory via X-ray (or whatever the method) then they've earned the right to get the code. I'm talking about everything other than physically opening the MCU.

I got my hopes up when I saw the LPC1800S, but it does not even get close since it only provides encrypted 'installation' in case you do not flash the image, but run it from RAM. Should I take that as a hint that there is a fundamental issue with un-encrypted images in internal flash? The user manual does not explain why it does not support the use-case with flash (or I could not find it). So now I'm wondering what attack vectors my requirements expose.

It does not have to be free (as in beer). In fact a commercial offering might be preferable. So is there a software stack available or for sale? I don't believe I'm the first to want this sort of thing (in combination with LPC MCUs), so there must be something out there, right? (Come on NXP, give me a unique selling point ;-)

Thanks in advance,
Vimes
0 Kudos
0 Replies