Hacker News Reader

Comment by detaro | Hacker News Reader

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, ...?

View on HN

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.

I just want to add "low power" to "there appears to be no alternative that is at once robust, mature, secure". Finding a good micro for security applications is a nightmare.

Kind of unrelated here, but wanted to mention Precursor [1]. They just shipped, it's still an early product but... something works.

[1] https://betrusted.io

DO you think that there is actually a significant market for a secure open-source microcontroller? It seems like the BigCos have chosen to do things like Titan (open source but not really), Cerberus (also open source but not really), and T2 (extremely closed source). Traditional microcontroller companies don't seem to be interested. The whole root-of-trust industry is also moving towards extremely-closed-source microcontrollers inside your big SoCs.

In the interest of disclosure, I'm actually in a position to start a secure open-source MCU project/company, but it looks like a terrible dead end.

> DO you think that there is actually a significant market for a secure open-source microcontroller?

I don't think we'll ever know. It is kind of amazing how secretive chip makers are despite the absolutely massive moat they enjoy. Not only is there a fabrication barrier to entry approaching the size of a small nation's GDP, but there is a maze of intellectual property laws backed by supranational leg breakers. And still they operate as if none of that existed and only trade secrets provide them any measure of competitive edge. Now imagine how bad it would be if the US military hadn't put multisource requirements in place...

I am very much looking forward to the day that their BS argument for secrecy might actually make some sense, because that'll be around the time that it becomes practical for businesses operating out of home garages to fabricate their own designs and start eating NXP's lunch.

A lot of the closed source boot Roms look to be SOC vendor code: they'd buy a subsystem ip from someone and have to redistribute the code for that thing but don't have the source licensed.

Unlikely that will ever be cleared up since the IP vendors are very precious about their stuff

Heh, so yes, everything is indeed terrible as feared. Thanks for the comprehensive answer, and especially sad to hear about "ActuallyOpenTitan"... which seems weird, especially since they are involved in the Skywater open ASIC thing.

Why dont you use what Chromebooks use?

We would love to! But they use Titan -- like, entirely closed Titan. (Ditto Apple's T2.) But the Chromebook is very much a model for what we're trying to do; I've said this before, but I feel like the Chromebook is one of the most underappreciated products in computing exactly because of its approach to security.

On ChromeOS, our root of trust is actually the SPI ROM. We allocate a RO section of the SPI ROM that is controlled with the write protect pin. This RO section contains a full copy of the BIOS including vboot and the keys used to verify the RW-A/RW-B sections. We use this to build a chain of trust. RO FW verifies RW FW, RW FW verifies the payload (depthcharge), depthcharge verifies the kernel, the kernel verifies the rootfs using dm-verity.

Here is a great video by Duncan explaining the whole processes in detail: https://youtu.be/HwsTRThChn0

All the components are open source too. You can read more about it here: https://doc.coreboot.org/security/vboot/index.html

As for the security chip, all current Chromebooks ship with a CR50. This is a Google designed chip. The boot rom is closed source unfortunately, but it essentially just verifies and jumps to RW. You can find the RW code here if anyone is curious: https://source.chromium.org/chromiumos/chromiumos/codesearch...

The security chip gives us TPM2 functionality and some ChromeOS specific features like CCD: https://chromium.googlesource.com/chromiumos/platform/ec/+/c...

You should be able to use vboot with a different TPM. Reach out if you want to chat!

What I'm hearing here is "Yes, Google designed their own chip because everything on the market sucks."

And who are you?

Reply on news.ycombinator.com