I am the author of the STM32F1 FPB security bypass exploit. Seeing this happen again, with another manufacturer, but this time with undocumented silicon, is just appalling. They will never learn. At least NXP replied to the email... I never got a reply from ST.
I'm halfway through your `One Exploit to Rule them All?` paper [1], and my jaw is on the floor. I mean... wow. I knew it was bad, but this really is ridiculous.
It's really unfortunate that hardware vendors are obsessed with shipping closed source firmware and ROM. Fortunately there's been a slow and steady buildup of pressure as open source has started being pushed lower into the stacks. Great to see Oxide Computers pushing on this. The rest of the NXP software stack is pretty open.
Overall the LPC55S69 chips are pretty impressive chips! They have dual cores with plenty of 16 bit ADC's and 16 bit DAC's built in, which is amazing. With good platform support from Arduino, Zephyr, etc it means you can get high quality signals in a single chip, and have two cores to process the data (one for real time data, the other for communications and controls).
If they shipped with open source firmware, you would have a number of companies copying it and using in their products undercutting the original manufacturer.
The US and the West don't have teeth when it comes to IP violations in Asia.
If you can't do anything against IP violations, closed source doesn't exactly protect you from clones (the range of reverse engineering/firmware extraction services available is impressive). It'll slow them down, but also gets in the way of your legit customers.
That is true, but without source code the violators cannot improve "their" products much nor give any meaningful updates, so the original manufacturer can still have an edge.
If sources were available, the violators could even make it better than original, without having to make even remotely the same R&D investment than original manufacturer.
Not sure this applies much for the ROM's on microcontroller. They're pretty small and mostly handle very low level details so there doesn't seem much space for meaningful improvement. Even when the firmware is completely open, the original firm often maintains a competitive edge because they have the know how to work with the code base and rest of the chip. Ideally they have internal simulation tools, a broad range of expertise, etc. The firmware often doesn't contain as much "secret sauce", but does contains lots of possible vulnerabilities or bugs for customers.
The response from NXP is just incredible. Heck of a job their "certified security test labs" are doing, if this has just been sitting out there for years waiting for some curious end-users to find it.
What's the point of those certified labs, then? To think inside the box and tell their client only what they want to hear?
The test lab industry is a grift. They just sell "LGTM" stickers for $30k a pop.
NXP and every other chip company are all just (correctly?) expecting that they will end up needing to do fewer respins by keeping the door to the closet where they keep their skeletons shut.
The problem is that NXP and their direct customers only care about exposure to liability for their products being insecure crap. It's the end users who actually suffer when their security tokens and HSMs are defeatable by anyone with some reversing skills and a few months to spare.
I don't know anyone who genuinely believes that the "secure microcontrollers" available today are even remotely secure. All chip companies act like this. You'd think that one of them would be motivated to release a line of chips with an open boot rom and all of the "oops bits" documented and just let the public have at it. Sure, they'd have to do a few respins, but by the time they were done, they'd completely own the market of products that genuinely need real security and not just rubber stamp security.
Beyond closed ROMs, it's even worse when entire lines of chips are locked behind NDAs.
It's always irked me you could never get programmable smartcards, except via a VM like Java or BASIC. The reason for this AIUI was that smartcard chips tended to consist of an 8051 plus a large customer-specified mask ROM, and very little flash. Except nowadays this is no longer the case, and platforms like ST's ST32 have ARM SC000 cores and, AIUI, are all-flash based. Except they may as well not exist for my purposes since they're entirely NDAware. Non-VM user-programmable smartcards exist, you just can't have them.
I suspect that part of this is antiquated attitudes and/or a refusal to accept Kerchhoff's principle by NXP, and that part of it is a similar attitude held by its customers, the organisations that buy smartcards. NXP's comments here as regards the LPC5S69 almost seem to insinuate something like "We don't rely on security by obscurity ourselves, but some of our customers have outmoded ideas about security and would complain if we opened things."
> I suspect that part of this is antiquated attitudes and/or a refusal to accept Kerchhoff's principle by NXP
That is attributing far too much agency to the players involved.
The real issue is much simpler: "We don't want to be bothered supporting anyone who isn't throwing around enough money that we're willing to actually do the design for them."
Suggestions very much welcome! Unfortunately, this space does not really have any good open options: certainly, there is no ARM MCU that meets our security constraints and also has open firmware. (Indeed, there is no ARM MCU that I am aware of that has a completely open ecosystem; all of them have some proprietary bits, though some less than others.) Longer term, we are bullish on RISC-V, but it's not there yet with the security features that we need (e.g., a PUF) -- and we are not in the position (yet!) to make our own ASIC. (We took a hard look at using a secure FPGA for our root of trust, but the best solution we found in the space made NXP look downright open.)
Again, suggestions welcome -- and we are very optimistic that our options will be much better in the coming decade!
You might be interested in what Anton Blanchard has been up to with the power ISA soft cores, it seems like his work has spanned the bulk of the FPGA toolkits, and I think his latest is taped out for the SKY130 run. His work is also being adapted for an openBMC replacement, which would offer an opportunity to dust off some old Xzibit templates, so thats good.
Unfortunately, going one layer down, most ASIC tooling is extremely opaque about what it does, and it's hard to share chip designs that are open at all levels (you may have open-source verilog, but the GDSII might have to be closed-source due to vendor NDAs). I suspect that if you have problems with FPGA tooling, you will also have problems with ASIC tooling.
However, the cost of an ASIC on an older node (~65-130 nm) is a lot lower than you think. There are (bad) free design tools and even older nodes may have open PDKs from foundries (the old scalable CMOS processes).
I have been considering starting up a company to build hardware root-of-trust chips along the lines of Titan/Cerberus,but I don't know if there's enough of a customer base out there to make it a reality.
I’m working with a lot of IoT and more complex autonomous systems, and would really like to have something that’d perform as a local root of trust. The NXP still seems one of the better options presuming they actually fix the CVE. There’s likely others like me as well. If Oxide made an open chip with an appropriate PUF I’d love to be able to buy it!
Or perhaps the Raspberry Pi folks could be talked to adding one to their Pico boards. ;)
P.S. TI also has trust zone chips, all NDA bound, but various levels of open source firmware.
