OpenTitan: An open-source silicon root of trust from lowRISC(opentitan.org)
opentitan.org
OpenTitan: An open-source silicon root of trust from lowRISC
https://opentitan.org
4 comments
I see no mention of the ability to use it in one's own designs, which seems like an oversight to me ("source available" vs "free software/hardware"). However, the repository's license seems to be Apache 2.0.
What application does a hardware-backed root of trust have for more consumer/non-server products like laptops/phones?
Dos this differ substantially from a TPM? Could it be used to verify integrity of a system from power-on to finishing booting say a Linux distro?
Dos this differ substantially from a TPM? Could it be used to verify integrity of a system from power-on to finishing booting say a Linux distro?
Apparently Google phones and some Chromebooks have a Titan-C chip [1], although it's not clear how it's more secure than the Intel secure boot architecture.
[1] Google managed to build a chip with an un-Google-able name
[1] Google managed to build a chip with an un-Google-able name
The chip in Chromebooks is called cr50 or h1. It has open source firmware (https://github.com/coreboot/chrome-ec/tree/master/board/cr50) and a few public mentions, e.g. https://2018.osfc.io/talks/google-secure-microcontroller-and...
In addition to secure boot, it could be the basis for hardware security modules like yubikeys.
The page draws parallels to Google’s Titan security chip, so I’d assume it can verify the boot chain.
To clarify this is just open source fpga code. It's not an open chip. Yet. It does however get us one step towards open silicon. An open source root of trust would be the most useful application for open silicon initiatives. I'd argue anything that touches key material should be auditable.
Put another way, you wouldn't trust a proprietary cryptographic algorithm, why would you trust a black box chip?
Current chips (including OpenTitan) still need to be fabricated at third party foundries using that foundry's proprietary process design kits ('PDKs') and signing two layers of NDA's. As multiple talks at CHES showcase every year there are a number of shenanigans that can be pulled off between a company like Google releasing verilog code for tapeout and the foundry handing back a 'compiled' chip.
The state of open silicon is somewhat analogous to GNU's efforts to create an open source operating system prior to Linux coming along and implementing an open kernel. We still lack open pdk's though it looks like there have been some recent breakthroughs with two foundries in the US and one in Hong Kong.
Recent advances in open FPGA toolchain environments at least let us simulate open solutions here like OpenTitan even if we can't yet tape them out transparently.
Put another way, you wouldn't trust a proprietary cryptographic algorithm, why would you trust a black box chip?
Current chips (including OpenTitan) still need to be fabricated at third party foundries using that foundry's proprietary process design kits ('PDKs') and signing two layers of NDA's. As multiple talks at CHES showcase every year there are a number of shenanigans that can be pulled off between a company like Google releasing verilog code for tapeout and the foundry handing back a 'compiled' chip.
The state of open silicon is somewhat analogous to GNU's efforts to create an open source operating system prior to Linux coming along and implementing an open kernel. We still lack open pdk's though it looks like there have been some recent breakthroughs with two foundries in the US and one in Hong Kong.
Recent advances in open FPGA toolchain environments at least let us simulate open solutions here like OpenTitan even if we can't yet tape them out transparently.
What's the gate count? It should be a good fit for libresilicon, a 1um open source process.
https://libresilicon.com/
https://libresilicon.com/
The question would be: how expensive is it to pay off the NDA-schenannigans for a mostly-obsolete node at a small, practically defunct fab? It should be a competitive advantage at that point.
When I last quoted, about $200k for the Hong Kong guys and 4-5 million for the Minnesota/Florida folks. Hong Kong was a much bigger process node.
4-5 million seems worth to try a kickstarter or so for.
If it succeeds, it'll open all this needed info. Kickstarter pledges convert at some ratio into credits that can be used to pay the fab.
If it succeeds, it'll open all this needed info. Kickstarter pledges convert at some ratio into credits that can be used to pay the fab.
There is Verilator (https://github.com/verilator/verilator).
While it, frankly, doesn't hold a candle to the proprietary tools like Synopsys, it's a starting point and serves as a wonderful way to do research and actually learn about hardware.
While it, frankly, doesn't hold a candle to the proprietary tools like Synopsys, it's a starting point and serves as a wonderful way to do research and actually learn about hardware.
Can someone explain what this is or what it is competing against?
> Silicon RoT can help ensure that the hardware infrastructure and the software that runs on it remain in their intended, trustworthy state by verifying that the critical system components boot securely using authorized and verifiable code.
The idea is that the firmware can't be modified without causing errors to propagate, errors that may not be able to be bypassed.
It can do some good things like protecting encryption keys, but mostly it allows someone to verify their server is exactly as they intended. Preventing a few high impact hijacking techniques that are incredibly difficult to pull off.
However, similar things have crept into consumer-grade hardware, where it's used to prevent someone from using a device for how _the owner_ intends, which is not so good.
---
This thing isn't really competing with many. It's an open-sourcing of Google's Titan [0], in an area which is fairly new. It's an attempt to own the niche.
[0] https://security.googleblog.com/2019/11/opentitan-open-sourc...
The idea is that the firmware can't be modified without causing errors to propagate, errors that may not be able to be bypassed.
It can do some good things like protecting encryption keys, but mostly it allows someone to verify their server is exactly as they intended. Preventing a few high impact hijacking techniques that are incredibly difficult to pull off.
However, similar things have crept into consumer-grade hardware, where it's used to prevent someone from using a device for how _the owner_ intends, which is not so good.
---
This thing isn't really competing with many. It's an open-sourcing of Google's Titan [0], in an area which is fairly new. It's an attempt to own the niche.
[0] https://security.googleblog.com/2019/11/opentitan-open-sourc...
It's way for big software and/or hardware companies to block you from running your own Linux distribution of choice.
(I'm exaggerating, but only very slightly, by a nanometer.)
(I'm exaggerating, but only very slightly, by a nanometer.)
Exactly. The bottom line is hardware that will only run trusted software. The problem then becomes determining who gets to sign software.
Better would be to just have a physical switch to disable firmware writes.
Better would be to just have a physical switch to disable firmware writes.
OpenTitan seems to be mainly oriented towards servers, though the announcement post [1] does mention that it could also be used for client devices.
[1] https://security.googleblog.com/2019/11/opentitan-open-sourc...
[1] https://security.googleblog.com/2019/11/opentitan-open-sourc...