LPC4370 Any way to protect firmware?

[splin]

As this is a flashless part it the firmware is open to being copied and reverse engineered from the external SPI flash device. The user manual talks about AES encrypted boot mode but this feature is only available on 43Sxx devices - of which the only ones available seem to the 43S20, 43S30 and 43S50.

Is this right? This seems to be such a major shortcoming of the LPC4370 that I feel I must be missing something?

I see that Digikey will no longer be stocking the 100 pin part when stocks are exhausted - is this a worry, a sign that the part wasn't popular and vulnerable to being obsoleted
Splin

Oops didn't realize this was accidentally posted before it was finished. Apologies for the duplicate.

[Jeroen3]

You can encrypt the data in your spiflash.
You'd need your own loader, at the beginning of spifi, copying the encrypted part to sram. But the sram is a bit harder to read.

Because it requires more development and experience to work with flashless, and it has high performance features. It's market is quite small. But it's nephew is inside the iPhone, so not that small.

The AES parts have import restrictions in some countries.

[lapm]

If you worry about firmware, use controller with internal flash and memory protection..

You also need to ensure firmware upgrade method is also secure. Assuming you do release firmware upgrades.

If that firmware is on external memory chip, it will be copied in china or where ever copies will come if your product is popular...

[splin]

You can encrypt the data in your spiflash.
You'd need your own loader, at the beginning of spifi, copying the encrypted part to sram. But the sram is a bit harder to read.

Because it requires more development and experience to work with flashless, and it has high performance features. It's market is quite small. But it's nephew is inside the iPhone, so not that small.

The AES parts have import restrictions in some countries.

But your unencrytped decryption code has to be loaded in from the external Flash so surely that wouldn't help at all - unless there were some way of programming a decryption key into the device that isn't accessible externally.

The device does have a unique ID which is 4x32bit words. Could that be used to encrypt/decrypt the code with decent security? It would be painful to manufacture though with the external Flash having to have specific code for each product. Since every device probably has an incrementing serial number as part of the unique ID I guess it would be vulnerable to brute force attacks.

Splin

EDIT: I had overlooked that the LPC4370 has:

   One-Time Programmable (OTP) memory

   The OTP provides 64-bit + 256 bit of memory for general purpose use.

So that must be the answer to the key problem. It still means that for a large application you face having to write memory handling functionality to page in code and decrypt it to RAM for execution as needed (very slow), or encrypt only important code leaving the rest unencrypted in external Flash - such as library code which is freely available.

[splin]

If you worry about firmware, use controller with internal flash and memory protection..

You also need to ensure firmware upgrade method is also secure. Assuming you do release firmware upgrades.

If that firmware is on external memory chip, it will be copied in china or where ever copies will come if your product is popular...

Well yes I think you're right - but its a shame as the LPC4370 has that 80MSPS 12bit ADC which is as far as I know is unique for a microcontroller - the fastest I have encountered elsewhere are the 5MSPS 12bit ADCs on some STM32F3 devices. The triple core, HS USB and large internal RAM are also attractive features for the price.

Splin

[coppice]

If you worry about firmware, use controller with internal flash and memory protection..

You also need to ensure firmware upgrade method is also secure. Assuming you do release firmware upgrades.

If that firmware is on external memory chip, it will be copied in china or where ever copies will come if your product is popular...

Well yes I think you're right - but its a shame as the LPC4370 has that 80MSPS 12bit ADC which is as far as I know is unique for a microcontroller - the fastest I have encountered elsewhere are the 5MSPS 12bit ADCs on some STM32F3 devices. The triple core, HS USB and large internal RAM are also attractive features for the price.

Splin

Its a very unique device, which means its was made for one customer, and then offered to the open market. If it had been developed for a specific application, rather than a specific customer, they would push its suitability for that application.

[Jeroen3]

But your unencrytped decryption code has to be loaded in from the external Flash so surely that wouldn't help at all - unless there were some way of programming a decryption key into the device that isn't accessible externally.

It still has OTP, however this might not be very well documented.

[splin]

If you worry about firmware, use controller with internal flash and memory protection..

You also need to ensure firmware upgrade method is also secure. Assuming you do release firmware upgrades.

If that firmware is on external memory chip, it will be copied in china or where ever copies will come if your product is popular...

Well yes I think you're right - but its a shame as the LPC4370 has that 80MSPS 12bit ADC which is as far as I know is unique for a microcontroller - the fastest I have encountered elsewhere are the 5MSPS 12bit ADCs on some STM32F3 devices. The triple core, HS USB and large internal RAM are also attractive features for the price.

Splin

Its a very unique device, which means its was made for one customer, and then offered to the open market. If it had been developed for a specific application, rather than a specific customer, they would push its suitability for that application.

That's interesting - not something I've seen mentioned anywhere else; do you have any references or links to more information on this or is it not meant to be in the public domain?

[Jeroen3]

All in the datasheet.

32-bit ARM Cortex-M4 + 2 x M0 MCU

One 6-channel, 12-bit high-speed ADC (ADCHS) with DMA support and a data
conversion rate of 80 MSamples/s.

http://www.nxp.com/documents/data_sheet/LPC4370.pdf
It's predecessor, the 4350 didn't have the super adc and extra core.

[splin]

All in the datasheet.

32-bit ARM Cortex-M4 + 2 x M0 MCU

One 6-channel, 12-bit high-speed ADC (ADCHS) with DMA support and a data
conversion rate of 80 MSamples/s.

http://www.nxp.com/documents/data_sheet/LPC4370.pdf
It's predecessor, the 4350 didn't have the super adc and extra core.

Sorry - I was referring to coppice's statement:

'Its a very unique device, which means its was made for one customer, and then offered to the open market.'

[Jeroen3]

Sorry.
I'm not sharing details about that.

[Howardlong]

How could you protect the OTP area from external reads, or code DFU'd to read it?

I am not sure it is possible to protect your IP in the flashless devices without an external authentication device, but it would be interesting to know thoughts on how that could be achieved. The SPIFI interface is very clever, offering real-time memory mapped FLASH through quad SPI, but it is also an Achiles heal from protecting IP.

Running from RAM is possible, and indeed in a few cases such as low latency interrupts desirable, but there's not a huge amount of it and it's not contiguous.

Its a very unique device, which means its was made for one customer, and then offered to the open market. If it had been developed for a specific application, rather than a specific customer, they would push its suitability for that application.

Do we know that, or is that conjecture?
 

[Jeroen3]

You should run from ram, spifi allows only 70 Mhz equivalent of execution speed.
The OTP assigned to the AES module should still be there, which should not be readable from outside.
Then you just have to set the MPU properly to prevent exploits.

Why don't you ask them for a solution, you're probably not alone.

[Howardlong]

I thought AES was only available in parts with flash?

[splin]

Hardware AES encryption/decryption isn't available on the LPC4370 but you can do it in software - just not very fast. You could trade off security for speed by choosing a simpler encryption scheme.

In either case you'd encrypt the code before programming it, along with the unencrypted boot code containing the decryption code into the external Flash. The decryption key(s) would then be written into the processor's OTP memory. Knowing the decryption algorithm won't help without knowing the key(s).

*BUT* what is to stop the external flash from being replaced with code to read the key(s) from the OTP and make them available to the attacker? Devices with AES protection store the decryption keys in the OTP memory but they aren't readable by the processor - only by the AES hardware. So it doesn't look like its possible to protect the code after all. 

[Howardlong]

Hardware AES encryption/decryption isn't available on the LPC4370 but you can do it in software - just not very fast. You could trade off security for speed by choosing a simpler encryption scheme.

In either case you'd encrypt the code before programming it, along with the unencrypted boot code containing the decryption code into the external Flash. The decryption key(s) would then be written into the processor's OTP memory. Knowing the decryption algorithm won't help without knowing the key(s).

*BUT* what is to stop the external flash from being replaced with code to read the key(s) from the OTP and make them available to the attacker? Devices with AES protection store the decryption keys in the OTP memory but they aren't readable by the processor - only by the AES hardware. So it doesn't look like its possible to protect the code after all. 

That was indeed what I was alluding to!

[mikeselectricstuff]

A quick skim of the datasheet says it has a unique ID, so this could be used as part of a key to prevent easy cloning of devices.

[Mechanical Menace]

A quick skim of the datasheet says it has a unique ID, so this could be used as part of a key to prevent easy cloning of devices.

There's no way to prevent you running your own code to extract that, same problem as with the OTP unfortunately.

[mikeselectricstuff]

A quick skim of the datasheet says it has a unique ID, so this could be used as part of a key to prevent easy cloning of devices.

There's no way to prevent you running your own code to extract that, same problem as with the OTP unfortunately.

Like I said, it protects against simple cloning into another device as a new target device will have a different factory ID. Obviously this could probably be patched around, but makes it a less trivial task.

[Howardlong]

A quick skim of the datasheet says it has a unique ID, so this could be used as part of a key to prevent easy cloning of devices.

There's no way to prevent you running your own code to extract that, same problem as with the OTP unfortunately.

Like I said, it protects against simple cloning into another device as a new target device will have a different factory ID. Obviously this could probably be patched around, but makes it a less trivial task.

The other problem is that the way the device is pimped you are led to using its SPIFI interface for code: this rather cleverly memory maps your QSPI flash. It has pros and cons, it's remarkably fast, due to some proprietary and secret sauce cache recipe, but equally it adds a degree of indeterminism. In addition it precludes direct use of encrypted firmware.

You can disable JTAG access by programming the OTP config bits.

Like you say, anything you do is going to add complexity, and at the end of the day is not going to stop a determined hacker. The method I am aware of uses an external authentication chip that the firmware continually questions. But this would not stop someone hacking the firmware to ignore the authentication results, it just makes it harder, and assuming you can persuade the end users that there is a need to update the firmware sufficiently frequently with different authentication methods it might sufficiently thwart cloning attempts.

[Howardlong]

Regarding product longevity, I had a response from NXP, both packages of the LPC4370 are guaranteed to September 2023.

http://www.nxp.com/techzones/microcontrollers-resources/product-longevity.html

[splin]

The other problem is that the way the device is pimped you are led to using its SPIFI interface for code:

An alternative is to use a 2nd micro to provide the code (into internal RAM) via ISP or usiing the boot loader. The 2nd micro could subsequently act as the external authentication chip you suggest.

The 2nd micro could dynamically encrypt code it provides after the boot code phase using time based keys to make it harder to hack and could even provide plausible, but wrong code if the timing is very slightly out to make it harder to use a debugger to reverse engineer the code. But as you say it won't stop someone who really wants the code. This seems rather reminiscent of the PC dongles used to copy-protect software which had the same problem - I don't know how successful they ultimately were despite the grand claims made by the dongle vendors. I managed to bypass the dongle used by an 8051 compiler with an hour or two's debugging, but the protection in that case was pretty feeble.

this rather cleverly memory maps your QSPI flash. It has pros and cons, it's remarkably fast, due to some proprietary and secret sauce cache recipe, but equally it adds a degree of indeterminism. In addition it precludes direct use of encrypted firmware.

Is it just me that is perplexed that that they don't seem to provide any worthwhile information about the performance when code is executing from Flash - unless I've not been looking properly? Why erect barriers to potential customers who have alternative choices? The device is clearly targeted at users who need performance, but knowing that if they need to execute from Flash they would first have to spend time and money evaluating how it performs. They'd probably still need to go through the evaluation anyway before fully committing, but not before being reasonably confident that it will be acceptable.

With an effective read speed from QSPI Flash of 40Mbytes/s and Thumb2 instructions being at least 16bits, without cache the 204MHz processor's going to run at 20MHz 

And how difficult would it be to determine the important cache characteristics anyway using the usual techniques including timing code with ever larger loop sizes etc? And surely its not as if other manufacturers don't know how to design cache!

Writing and debugging the code is hard enough without the chip manufacturer deliberately witholding important design information. OK if you fit all your time critical code into RAM and don't care if the rest runs at 20MHz then its straightforward, but I wonder how many designs that applies to? That fast ADC and high speed USB and Ethernet interfaces can chew up the RAM really quickly. Trying to squeeze your application into a small RAM footprint just makes the design and coding much harder than it needs to be.

Hmm. This has turned into a bit of a rant. Perhaps I should just ask NXP? 
It would be interesting though to hear any experience/insights into the 43xx QSPI performance.

You can disable JTAG access by programming the OTP config bits.

Like you say, anything you do is going to add complexity, and at the end of the day is not going to stop a determined hacker. The method I am aware of uses an external authentication chip that the firmware continually questions. But this would not stop someone hacking the firmware to ignore the authentication results, it just makes it harder, and assuming you can persuade the end users that there is a need to update the firmware sufficiently frequently with different authentication methods it might sufficiently thwart cloning attempts.

Not sure I understand that last bit, but I don't suppose it matters - I think we agree on the main points!

Regarding product longevity, I had a response from NXP, both packages of the LPC4370 are guaranteed to September 2023.

Thanks - that's very interesting.

[Jeroen3]

It would be interesting though to hear any experience/insights into the 43xx QSPI performance.

I was able to run about 70 MHz from SPIFI in the 4350, on the boot rom config. But that was some time ago, I do not remember if I benchmarked it properly.
You can run from internal ram (there is plenty),  keeping your graphics data in spifi and your rw in external ram.

[Howardlong]

Exactly, you just need to be a bit smart about where you put your code. Typically it'll be a 90/10 scenario anyway, 10% of your code executes 90% of the time, so find that 10% and stick it in RAM.

You can also play around increasing the speed of the SPIFI interface, it's been a few weeks but the last time I fiddles about with that, the SPIFI interface was only running at 50MHz or so by default but it'll support 104MHz, ie 52MB/s.

To be honest, in prototypes I've not yet needed to move anything specifically into RAM.! But I did do a few tests to show it can be done.

If you want to provide your code by booting from an external device, you'll want to hide your SPI or serial lines in a middle layer to hamper snooping and use a BGA source device. At some point, at least some stuff is going to be sent in the clear. It means you lose DFU too, one of the nice features of the device.

You may have already figured this out but nothing is easy on this processor :-(

[splin]

Exactly, you just need to be a bit smart about where you put your code. Typically it'll be a 90/10 scenario anyway, 10% of your code executes 90% of the time, so find that 10% and stick it in RAM.

True, but beyond some obvious functionality such as interrupt routines, some RTOS/library functions etc, not all applications have clear hotspots. Any code that you don't mind running at 26MHz or less can clearly be located in QSPI Flash; for the rest potentially a *lot* more work may be needed to analyse the application - a) to find which code definitely could not be put in Flash because of hard real time requirements - including rarely used but important error/exception handling - and b) that with 'softer' real-time deadlines which might be OK in Flash.

NXP suggest that code executing from Flash runs at approx 70% of full speed but without any supporting evidence or guidelines (that I can find) I'll take that with a pinch of salt - maybe for code with a small memory footprint relative to the unspecified cache size or that which spends a lot of time in small loops.

Profiling may help for (b) but a significant problem is the difficulty of exercising some parts of the code without extensive test support which you are unlikely to have at the start of a project (if at all!). Especially when you are at the stage of choosing which micro(s) to use.

I agree though that for a lot of applications, especially where the demands on the RAM are modest enough to allow plenty to be allocated for code, will be easy to partition. But if the product is the type that suffers 'creeping featuritis' you also have to be able to anticipate future demands - you could end up in the position of having a massively powerful processor - triple core so potentially 612MHz worth of processing (who needs an M7?!!) - with gobs of external Flash for the code, but not enough spare RAM to run it from and you're faced with your new features having to run at 26MHz - less than even an entry level Cortex M0 costing less than $1.

You can also play around increasing the speed of the SPIFI interface, it's been a few weeks but the last time I fiddles about with that, the SPIFI interface was only running at 50MHz or so by default but it'll support 104MHz, ie 52MB/s.

To be honest, in prototypes I've not yet needed to move anything specifically into RAM.! But I did do a few tests to show it can be done.

If you want to provide your code by booting from an external device, you'll want to hide your SPI or serial lines in a middle layer to hamper snooping and use a BGA source device. At some point, at least some stuff is going to be sent in the clear.

Yes I had thought of that, but the BGA Flash device could be lifted and re-connected dead bug style given that only 5 or 6 signal lines need to go to the processor, so not too difficult to intercept.

It means you lose DFU too, one of the nice features of the device.

I had a quick look at the documentation but couldn't get to grips with why this could be exciting - it appears to be a USB Bootloader/programming feature?

You may have already figured this out but nothing is easy on this processor :-(

Yeah. 1420 pages of user manual is testament to that - and I'll bet its still missing important detail! But is it really any harder than say an STM32F4 to get up and running with some basics peripherals such as ADC, timers, UARTs etc. with DMA? It's not as if the peripherals on other M4s are exactly trivial.

Don't get me wrong, I think this is an amazing micro for the price - it's just that the external Flash issues (encryption and performance) especially are major concerns. I'd love to think that NXP are going to update the LPC4370 - even if it were only to fix any silicon errata and add some on-chip bootable Flash. And a non-BGA package version would be very welcome.