Since Oxide folks are reading: I'm curious about the details behind the choice of this specific chip - you found a problem last year during evaluation, it's now "chosen part for our product's Root of Trust implementation" and you found another problem. No reason to assume anything else would be any better? Nothing else really on the market that does some specific thing you need? Some of the BigCo's have opened their solutions to this problem - not viable for you to make/obtain, also broken, not actually as open as they claim, ...?
Yeah, big sigh here. So, a bunch of things. First (and to be fair to NXP), a secure microcontroller is a hard problem, with tricky bits in both hardware and software. And it remains to be true that the LPC55 is pretty good at a bunch of things that we need (e.g., a PUF).
Second, while it's true that we're (obviously?) not entirely satisfied with the LPC55, we have worked around the vulnerabilities we have found -- and the alternatives that we have found aren't better. In particular: there appears to be no alternative that is at once robust, mature, secure, and entirely open. And even in the RISC-V ecosystem, there is a disconcerting trend towards proprietary boot ROMs (!!). We definitely welcome alternatives though, so please prove us wrong on that front! (That said: any alternative will be too late for our first product; we will have the LPC55 in our system for at least the foreseeable future.)
In terms of the BigCo's having "opened" their solutions, they haven't really (sadly). OpenTitan -- which we were really bullish about! -- only existed as an FPGA during the time we were trying to build on it. We actually wanted to make a go of making a secure FPGA -- but the problem is harder and the ecosystem is more proprietary than with secure microcontrollers. There are (or were) "plans" to make an ASIC, but we were asked to pony up $500K to join the lowRISC Foundation to find out what those plans were. (!!) To be blunt: that's not open -- it's open-washing. (I hope OpenTitan has seen or will see the error of its ways and opened up an ASIC roadmap -- it's an important effort and we would like to see it succeed.)
As for the other BigCo's, of the ones that I know about, they are either not using an RoT (!) or are using one that's strictly proprietary (i.e., no idea) or they are using the (wait for it...) LPC55.
So, yeah. Big sigh. tl;dr: We would welcome something better; we need to live with the LPC55; we would love RISC-V to not repeat a bunch of proprietary mistakes; we would love OpenTitan to be ActuallyOpenTitan.
Shameless plug: If you want to hear a bit more history about the previous vulnerability on the LPC55S69, we talked to Laura about it in our podcast: https://unnamedre.com/episode/55
Credit to Oxide, the fact that they're finding this stuff implies they really know their way around their hardware/firmware. This finding actually gives me confidence in what Oxide are doing.
After hearing some stories from friends who work with microcontrollers IMO the most impressive thing about this is that Oxide were allowed to publish the vulnerability at all
NXP knew enough to not ask. To their credit, we got much less runaround on this vulnerability than with the vulnerability that Laura and Rick found a year ago.[0] (It should also be said that what Laura originally sent to them left little room for negotiation about the seriousness.) At some level, NXP seems to appreciate that we're helping them improve their products -- or perhaps they're just afraid of what we'll find next? Either way they were at least marginally better.
So all of that is an improvement, certainly, but it's still not what we need: the source code to the ROMs. We believe emphatically that we need transparency throughout the stack, down to its lowest levels. We need open ROMs, open FPGAs, open ISAs, open firmware -- not just because it's the right thing to do, but because it will result in more secure and more reliable infrastructure!
Lots of issues with microcontrollers, even secure ones, can be found around the ISP routines. I remember issues with NXP Micros (also LPCs, but of another generation) where, if you glitch the power at just the right time, you can get it to ignore code readback protection.
I'm not sure that getting the manufacturers to open source the ROM code is the right solution, per se, as even if it was known beforehand that there was an issue here, you would still be left with the same solution space: disable the affected code paths, and prevent access to them with additional (external) integrity checking.
Voltage glitching is a serious but broadly orthogonal issue (and one that has a very different threat model than, say, a compromised software supply chain). We actually do believe that opening this ROM would have prevented the problem because it is in fact glaring -- and the demographic for these parts really cares about this! So it seems highly likely that this problem would have been found many times over, and certainly would have been found in an early rev of the part that would have allowed them to fix it in a subsequent mask.
We need open source ROMs (and open source firmware!), and we collectively need to stop finding excuses for vendors to not provide it.
While it’s true that it being open wouldn’t have changed the solutions, nor strictly speaking prevented the bug, it would make audits by third parties (like us) easier. And that’s really important.
Can anyone explain Oxide's product beyond the (fairly terrible IMHO) site? Seems like some kind of prepackaged VMware-alike including rack + hardware + networking fused into a single uncustomizable product?
If it's anything like the patching in some common bluetooth controllers, the patching area was filled up a long time ago with new features and they don't want to respin the base silicon.
I find it very hard to believe NXP will open source their design, given that many of the logic blocks are probably used across their whole company. At best maybe they'll share code with Oxide under a hefty NDA.
Well, we just want them to open the ROM, but yes. For whatever it's worth, they won't even let us look at the code, let alone share it: not that it's our preferred model (at all!), but we offered to review the code offsite in a disconnected room, etc. They were... not amenable.
I would think that the bootloader code wouldn't use any funky IP blocks - it's not some sort of driver code into which applications call, it's just a special application that runs before anything else. It has to be able to talk UART (or some other interface), check signatures, and write flash. All of these the user code can do as well.
There are many "user-space" bootloaders as well for various chips. The factory bootloader is only different in that it sits in ROM. For example, RP2040 ROM bootloader is here https://github.com/raspberrypi/pico-bootrom
It gets even worse. MS can't open source Windows because there's licensed third party components. A lot of silicon vendors can't open source their design for the same reason.
I am currently trying to find their Common Criteria certificate for that product, but it seems like there is none for the LPC55S69 according to their forums [1].
About a month ago, I took notice of LPC processors in general as "unbrickable" to the extent they all (AFAIK) have a serial bootloader, etc.
At some hazy and facetious level, does a vulnerability such as that described here connote a deeper level of being "unbrickable" -- say if a vendor lost its own key?
[+] [-] detaro|4 years ago|reply
[+] [-] bcantrill|4 years ago|reply
Second, while it's true that we're (obviously?) not entirely satisfied with the LPC55, we have worked around the vulnerabilities we have found -- and the alternatives that we have found aren't better. In particular: there appears to be no alternative that is at once robust, mature, secure, and entirely open. And even in the RISC-V ecosystem, there is a disconcerting trend towards proprietary boot ROMs (!!). We definitely welcome alternatives though, so please prove us wrong on that front! (That said: any alternative will be too late for our first product; we will have the LPC55 in our system for at least the foreseeable future.)
In terms of the BigCo's having "opened" their solutions, they haven't really (sadly). OpenTitan -- which we were really bullish about! -- only existed as an FPGA during the time we were trying to build on it. We actually wanted to make a go of making a secure FPGA -- but the problem is harder and the ecosystem is more proprietary than with secure microcontrollers. There are (or were) "plans" to make an ASIC, but we were asked to pony up $500K to join the lowRISC Foundation to find out what those plans were. (!!) To be blunt: that's not open -- it's open-washing. (I hope OpenTitan has seen or will see the error of its ways and opened up an ASIC roadmap -- it's an important effort and we would like to see it succeed.)
As for the other BigCo's, of the ones that I know about, they are either not using an RoT (!) or are using one that's strictly proprietary (i.e., no idea) or they are using the (wait for it...) LPC55.
So, yeah. Big sigh. tl;dr: We would welcome something better; we need to live with the LPC55; we would love RISC-V to not repeat a bunch of proprietary mistakes; we would love OpenTitan to be ActuallyOpenTitan.
[+] [-] alvarop|4 years ago|reply
[+] [-] bcantrill|4 years ago|reply
[+] [-] veltas|4 years ago|reply
[+] [-] Grollicus|4 years ago|reply
[+] [-] bcantrill|4 years ago|reply
So all of that is an improvement, certainly, but it's still not what we need: the source code to the ROMs. We believe emphatically that we need transparency throughout the stack, down to its lowest levels. We need open ROMs, open FPGAs, open ISAs, open firmware -- not just because it's the right thing to do, but because it will result in more secure and more reliable infrastructure!
[0] https://oxide.computer/blog/lpc55
[+] [-] yc-kraln|4 years ago|reply
I'm not sure that getting the manufacturers to open source the ROM code is the right solution, per se, as even if it was known beforehand that there was an issue here, you would still be left with the same solution space: disable the affected code paths, and prevent access to them with additional (external) integrity checking.
[+] [-] bcantrill|4 years ago|reply
We need open source ROMs (and open source firmware!), and we collectively need to stop finding excuses for vendors to not provide it.
[+] [-] steveklabnik|4 years ago|reply
[+] [-] outsb|4 years ago|reply
What is the intended application?
[+] [-] steveklabnik|4 years ago|reply
[+] [-] wmf|4 years ago|reply
[+] [-] k0ngo|4 years ago|reply
[+] [-] RL_Quine|4 years ago|reply
[+] [-] veltas|4 years ago|reply
[+] [-] bcantrill|4 years ago|reply
[+] [-] mmoskal|4 years ago|reply
There are many "user-space" bootloaders as well for various chips. The factory bootloader is only different in that it sits in ROM. For example, RP2040 ROM bootloader is here https://github.com/raspberrypi/pico-bootrom
[+] [-] R0b0t1|4 years ago|reply
[+] [-] sigttou|4 years ago|reply
[1] https://community.nxp.com/t5/LPC-Microcontrollers/Does-the-L...
[+] [-] rpaddock|4 years ago|reply
NXP has already moved Kentits delivery times out multiple times. Companies are on the verge of bankruptcy because NXP is not delivering.
Queries go unanswered or get a stock "52 weeks", after being told "52 weeks" 53 weeks ago.
[+] [-] a9h74j|4 years ago|reply
At some hazy and facetious level, does a vulnerability such as that described here connote a deeper level of being "unbrickable" -- say if a vendor lost its own key?