Hacker News Reader

Comment by londons_explore | Hacker News Reader

Is it possible to make your own TPM 2.0 chip? Or at least hardware that emulates the chip?

Or are there root secret keys or something that requires certification and very expensive membership to a professional body and NDA agreements to access?

View on HN

Software emulation https://github.com/stefanberger/swtpm

with bugs https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tpm

https://tpm.fail/ https://github.com/VernamLab/TPM-Fail

The Bob Rudis bit explains TPM shouldnt be relied on. https://www.forbes.com/sites/daveywinder/2021/10/16/critical...

fTPMs can be relied on. dTPMs can't be, but mainly because of bootstrapping issues that keep the BMC/BIOS from using encrypted and audit sessions to protect against passive and active on-bus attacks.

EDIT: Regarding side-channel attacks, presumably fTPMs that have such vulnerabilities can be fixed. dTPMs can also get firmware updates, but I'm not sure that every dTPM side-channel vulnerability is fixable -- it might depend on the chip's hardware capabilities, though the STM one in the TPM-FAIL attack was fixed.

> fTPMs can be relied on. dTPMs can't be, but mainly because of bootstrapping issues that keep the BMC/BIOS from using encrypted and audit sessions to protect against passive and active on-bus attacks.

Microsoft seems to disagree with you.

https://docs.microsoft.com/en-us/windows/iot-core/secure-you...

Firmware TPM (fTPM) requires special Processor/SoC support that is not currently implemented on Raspberry Pi 2 or 3. MinnowBoard Max needs firmware version 0.80 or higher. DragonBoard410c provides fTPM capabilities out of the box enabled by default.

Discrete TPM (dTPM) is considered the utmost trustworthy solution by all means

Software TPM (sTPM) is also referred to as TPM Simulator. It is platform-independent, supported on Windows IoT Core. sTPM is intended for development purposes only and does not provide any real security benefits.

Chips are just as vulnerable, but its currently harder and not impossible to hack them.

Well, they're wrong. The problem is that unless the BMC and BIOS doing all the TPM2_PCR_Extend() calls are securely (like, on some bit of memory or register that apps can't get to until much later when the secure boot sequence has completed) recording the TPM's resetCount or an audit digest of their commands, then an attacker can reset the TPM at a later point and extend the PCRs with values that are approved, and none will be the wiser.

Another problem is that reading out a bitlocker key from the TPM after satisfying a policy is nice, but if it is not read over an encrypted session, then it can be read by any physical attacker than can watch the bus.

The fundamental problem, ultimately, is that in order to defeat the bus attacks, the BMC and BIOS and early OS boot stages need secure volatile storage for storing the TPM's resetCount, and long-term non-volatile storage for storing the public key of some primary on the TPM for keying encrypted sessions. An fTPM has no external bus to worry about. Ergo fTPMs are fine.

Half these problems would go away if we went back to a single core cpu.

It depends on how the TPM is being used by the OS and its apps. If it’s purely being used for the crypto key storage and crypto operations, then you can probably use something like the MS reference implementation [0]. If the OS requires attestation and endorsement, there is a manufacturer key pair that is embedded into the chip that you can use to attest and verify that the TPM you are interacting with is indeed from a particular manufacturer. That aspect would not be doable for an emulated DIY TPM.

[0] https://github.com/microsoft/ms-tpm-20-ref

https://docs.microsoft.com/en-us/windows-server/identity/ad-...

This link has some useful details on attestation.

For a lot of software you should be able to still use a custom TPM since you could use the EKPub based attestation which is per-device. This would allow you to bake your custom key into the device prior to installation and then whitelist it.

I'm by no means an expert but since this is mostly handled at the OS level, provided you control the infra you should be able to roll your own custom TPM and still support attestation & endorsement. So if you are dealing with this on your own personal hardware or in your company (and you have IT's blessing), you should be able to do it but it won't work out of the box.

Only if you want someone special to trust your hardware, then it requires effort. Otherwise not.

I don't believe so - QEMU and proprietary hypervisors can emulate TPMs just fine.

That's the whole point of a TPM/Pluton/etc, remote attestation and corporate control over people.

Reply on news.ycombinator.com