29 ms·

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

by detaro 5y ago

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

bcantrill 5y ago
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.
- sydthrowaway 5y ago
  Why dont you use what Chromebooks use?
  - bcantrill 5y ago
    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.
    - yx827ha 5y ago
      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 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 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/+/main:src/platform/cr50/board/cr50/;bpv=1;bpt=0 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/+/cr50_stab/docs/case_closed_debugging_cr50.md#ccd-open 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!
      - sydthrowaway 5y ago

by detaro 5y ago

bcantrill 5y ago

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.

sydthrowaway 5y ago
Why dont you use what Chromebooks use?
- bcantrill 5y ago
  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.
  - yx827ha 5y ago
    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 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 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/+/main:src/platform/cr50/board/cr50/;bpv=1;bpt=0 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/+/cr50_stab/docs/case_closed_debugging_cr50.md#ccd-open 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!
    - sydthrowaway 5y ago