LPC4370 Any way to protect firmware? - Page 1
Forum section: electronics / general

author: splin
author_rank: Frequent Contributor
timestamp: January 26, 2015, 01:16:19 pm
content: 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 obsoletedSplinOops didn't realize this was accidentally posted before it was finished. Apologies for the duplicate.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 26, 2015, 01:30:15 pm
content: 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.

author: lapm
author_rank: Frequent Contributor
timestamp: January 26, 2015, 01:31:54 pm
content: 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...

author: splin
author_rank: Frequent Contributor
timestamp: January 26, 2015, 01:45:40 pm
content: Quote from: Jeroen3 on January 26, 2015, 01:30:15 pmBut 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.SplinEDIT:I had overlooked that the LPC4370 has:One-Time Programmable (OTP) memoryThe 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.

author: splin
author_rank: Frequent Contributor
timestamp: January 26, 2015, 01:50:56 pm
content: Quote from: lapm on January 26, 2015, 01:31:54 pmWell 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

author: coppice
author_rank: Super Contributor
timestamp: January 26, 2015, 01:53:51 pm
content: Quote from: splin on January 26, 2015, 01:50:56 pmIts 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 26, 2015, 01:59:55 pm
content: Quote from: splin on January 26, 2015, 01:45:40 pmIt still has OTP, however this might not be very well documented.

author: splin
author_rank: Frequent Contributor
timestamp: January 26, 2015, 02:08:39 pm
content: Quote from: coppice on January 26, 2015, 01:53:51 pmThat'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?

author: Jeroen3
author_rank: Super Contributor
timestamp: January 26, 2015, 02:27:49 pm
content: All in the datasheet.QuoteQuotehttp://www.nxp.com/documents/data_sheet/LPC4370.pdfIt's predecessor, the 4350 didn't have the super adc and extra core.

author: splin
author_rank: Frequent Contributor
timestamp: January 26, 2015, 02:32:56 pm
content: Quote from: Jeroen3 on January 26, 2015, 02:27:49 pmSorry - I was referring tocoppice's statement:'Its a very unique device, which means its was made for one customer, and then offered to the open market.'

author: Jeroen3
author_rank: Super Contributor
timestamp: January 26, 2015, 02:42:21 pm
content: Sorry.I'm not sharing details about that.

author: Howardlong
author_rank: Super Contributor
timestamp: January 26, 2015, 03:38:46 pm
content: 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.QuoteDo we know that, or is that conjecture?

author: Jeroen3
author_rank: Super Contributor
timestamp: January 26, 2015, 03:50:15 pm
content: 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.

author: Howardlong
author_rank: Super Contributor
timestamp: January 26, 2015, 04:05:55 pm
content: I thought AES was only available in parts with flash?

author: splin
author_rank: Frequent Contributor
timestamp: January 26, 2015, 05:20:47 pm
content: 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.

author: Howardlong
author_rank: Super Contributor
timestamp: January 26, 2015, 05:56:56 pm
content: Quote from: splin on January 26, 2015, 05:20:47 pmThat was indeed what I was alluding to!

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 26, 2015, 11:00:48 pm
content: 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.

author: Mechanical Menace
author_rank: Super Contributor
timestamp: January 26, 2015, 11:04:54 pm
content: Quote from: mikeselectricstuff on January 26, 2015, 11:00:48 pmThere's no way to prevent you running your own code to extract that, same problem as with the OTP unfortunately.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 26, 2015, 11:23:13 pm
content: Quote from: Mechanical Menace on January 26, 2015, 11:04:54 pmLike 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.

author: Howardlong
author_rank: Super Contributor
timestamp: January 28, 2015, 10:46:07 pm
content: Quote from: mikeselectricstuff on January 26, 2015, 11:23:13 pmThe 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.

author: Howardlong
author_rank: Super Contributor
timestamp: January 29, 2015, 09:29:24 am
content: 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

author: splin
author_rank: Frequent Contributor
timestamp: January 29, 2015, 12:16:34 pm
content: Quote from: Howardlong on January 28, 2015, 10:46:07 pmAn 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.QuoteIs 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 20MHzAnd 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.QuoteNot sure I understand that last bit, but I don't suppose it matters - I think we agree on the main points!QuoteThanks - that's very interesting.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 29, 2015, 07:59:21 pm
content: Quote from: splin on January 29, 2015, 12:16:34 pmI 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.

author: Howardlong
author_rank: Super Contributor
timestamp: January 29, 2015, 08:50:16 pm
content: 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 :-(

author: splin
author_rank: Frequent Contributor
timestamp: January 31, 2015, 05:27:21 pm
content: Quote from: Howardlong on January 29, 2015, 08:50:16 pmTrue, 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.QuoteYes 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.QuoteI 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?QuoteYeah. 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.

author: Howardlong
author_rank: Super Contributor
timestamp: February 01, 2015, 10:33:29 am
content: The ADC is actually a typical example of an over-complicated peripheral, but it does work and perform well.The other one is the SCT - state configurable timer - which must've been designed by a serious propeller head. It's a super configurable state machine with timers.If you've not yet had to deal with the clocking schema then you have some real fun ahead of you, I can tell you!There isn't much missing that I've noticed, but they tend to use lots of tables and lacks diagrams. It is a mature device now, and the errata is delightfully short compared to some devices.I agree it would be nice to see a non-BGA version of the device. Still, I have to congratulate this device as it finally forced me into the 21st century albeit kicking and screaming as a result.

author: Jeroen3
author_rank: Super Contributor
timestamp: February 01, 2015, 01:31:31 pm
content: Their SGPIO is nice too.They do have LQFP versions of the family available. But those are huge.Since the chip is for advanced developers, the target audience would be companies with budget to run a bga prototype.Do not forget that you can run code from external parallel memory, or store variables.

author: Howardlong
author_rank: Super Contributor
timestamp: February 01, 2015, 01:43:07 pm
content: I think the OP, like me, is drawn to the BGA only LPC4370 specifically by its integrated high speed 80Msps 12 bit ADC. I don't believe there's any other MCU out there that comes close in terms of ADC performance, although I'd be delighted to be corrected! Microchip's PIC32MZ was a contender, with 28Msps 12 bits and half a dozen sample and holds, but the latest errata has downgraded it to a crappy 1Msps 8 bit single S&H.I've largely got over my BGA phobia, but could probably use some more practice. I managed to fan out the 100 pin 0.8mm pitch device using standard pool-based PCB specs (5mil track and gap, 2.5mm drill). It can even be done 2 layer, but I wouldn't recommend it, your ADC performance will likely be rubbish due to lack of ground plane.

author: splin
author_rank: Frequent Contributor
timestamp: July 10, 2015, 12:38:56 am
content: It seems the answer is finally in - I've just noticed that the LPC43S70, which includes an AES engine for decrypting the boot image, has been announced. Don't know when it will be available or how much extra it will cost though.Now all they need to do is release it in something other than a BGA package so that you aren't forced to use a costly 6 or 8 layer (or more) PCB.Quote from: Howardlong on February 01, 2015, 01:43:07 pmYes exactly that. I have to say that I'm disappointed that ST didn't take the opportunity to put better ADCs on the new STM32F7 rather than sticking with the old STM32F4 ADCs. The STM32F303 for example have up to 4 x 5MSPS ADCs with a max INL of +/-2LSBs and min ENOB of 11.2bits (@25C, 3.3V) and can be used single-ended or fully differential.Compare that to the STM32F7 which has 3 x single-ended 2MSPS ADCs with max INL of +/-3LSBs and ENOB of 10.6bits. Actually they will run at 2.4MSPS but then the max INL increases to +/-6LSBs!Bizarrely though the STM32F3s have a maximum CPU clock speed of only 72MHz so its very difficult to actually handle up to 20MSPS of 12 bit ADC data, whereas the STM32F7 has bags of processing power but only 6 to 7.2MSPS of ADC data. I guess using the old STM32F4 as a starting point was seen as the quickest way to market for the M7 - hopefully they will give it better ADCs in due course (but I doubt they'll appear any time soon).QuoteAh so perhaps you don't need 6+ layers. Perhaps BGA isn't quite so bad after all.