3 ms·

The TPM spec is a monster and I understand the urge to throw it out and create something simpler. It's also true that you're trusting proprietary firmware in th

The TPM spec is a monster and I understand the urge to throw it out and create something simpler. It's also true that you're trusting proprietary firmware in the TPM to be correct. Errors and bugs in the spec are also near impossible to fix. So the idea of "just run whatever code you want" has appeal. And the reference tpm2_tools and software stack is a hot mess of C code that should definitely not be written in C at this point. A device brewed on a RISC-V SOC in an FPGA is probably very hard to secure against hardware attacks. It's fun (in the sense that FPGAs are "fun") and it's definitely a worthy pursuit to have an open hardware + firmware device replace proprietary TPMs. But getting hardware security right is just as important here. A TPM-replacement is not useful if I can solder a JTAG connection to it and read out the memory. Rewrapping keys when there's a firmware/code update is a real weakness here. There's probably a solid solution, like being able to provide a compound/asymmetric CDI to wrap between versions. Like "generate an ECDH key pair for the next hash". It would be a pain if every client application had to implement this themselves. The other hot use case for TPMs is boot chain attestation, where hashes of UEFI firmware, boot loaders, and kernel images are appended to create a verifiable hash. The device attests to the hash being authentic. One major weakness of TPM 2.0 is that it's monolithic for the whole system. If you're running VMs or even just multiple processes in the OS, it's not really easy to use across domains. So lightweight code swapping would be pretty cool. Interesting stuff nonetheless.

loup-vaillant 3y ago
> A device brewed on a RISC-V SOC in an FPGA is probably very hard to secure against hardware attacks. Makes sense. Which is why I didn't insist too much on the FPGA nature of the TKey. For maximum security I would want an ASIC system on a chip (ideally some RISC-V profile), with a real fuse bank, neatly lockable ROM for the bootloader firmware, and all the real hardware security I basically know nothing about. An FPGA is such a sexy prototype, though.
- MrSimontia 3y ago
  Interesting discussion! There are some exciting things that could be done with an ASIC, but at the same time an ASIC would require extensive supply chain security to be in place (which is a big task). There are a lot of hands touching the design and silicon from point of design sign-off, to ASICs in your hand. Supply chain attack is more difficult on a FPGAs, partly by processes implemented by the vendors and partly by the fact how FPGAs work, since there is no functionality in the FPGA, malware injection is more difficult (close to impossible?). Glad to hear your reasoning around this. (Full disclosure: I work at Tillitis)

loup-vaillant 3y ago

> A device brewed on a RISC-V SOC in an FPGA is probably very hard to secure against hardware attacks. Makes sense. Which is why I didn't insist too much on the FPGA nature of the TKey. For maximum security I would want an ASIC system on a chip (ideally some RISC-V profile), with a real fuse bank, neatly lockable ROM for the bootloader firmware, and all the real hardware security I basically know nothing about. An FPGA is such a sexy prototype, though.

MrSimontia 3y ago
Interesting discussion! There are some exciting things that could be done with an ASIC, but at the same time an ASIC would require extensive supply chain security to be in place (which is a big task). There are a lot of hands touching the design and silicon from point of design sign-off, to ASICs in your hand. Supply chain attack is more difficult on a FPGAs, partly by processes implemented by the vendors and partly by the fact how FPGAs work, since there is no functionality in the FPGA, malware injection is more difficult (close to impossible?). Glad to hear your reasoning around this. (Full disclosure: I work at Tillitis)