TPM seems beyond useless to me. I wanted to protect a certificate and private key for a Java application, so that you can't just copy the pkcs12 file and use it elsewhere, but there is no decent API in Java to use a TPM 2 chip. So the road ends there... The only protection now is a hardcoded passphrase in the application but you don't have to be a genius to figure that out...
Discrete (i.e., chip) TPMs (dTPMs) are slow. They are way too slow to use as HSMs.
Firmware TPMs (fTPMs) are faster, but I doubt they're really fast enough to use as an HSM.
There are TPM APIs for Java, so you can do this, but it's not surprising that the Java keystore providers lack builtin support because of the performance issues.
Ideally fTPMs should come with EKcerts and platform certificates and they would be very fast and as secure as (more so than) dTPMs. Then using fTPMs as HSMs might take off.
its meant for secureboot, but i suppose the rest of the platform, built usually by other ppl than ones who designed the TPM, needs to also implement it correctly. an d as this article shows, this is not an easy feat. (this attack seems silly but it's really clever tbh. good inspired idea likely based in lots of domain expertise). - if you can protect the boot-chain with secureboot, what you can do for your private key, what for example AV vendors do, is have a (efi?)driver that contains the certificate, which is a boot-driver protected by secure-boot. - for windows this might require Microsoft cooperation to assign you a driver level so other stuff can't disable it (otherwise it's still tricky and possible to get around your protections likely). (windows -> process protection light / telam drivers). Optionally you could also have the certificate provided by an EFI applcation somehow that's signed / secured by secureboot. (could drop it on disk somewhere, efi partition is easily accessible...).
If the chain is protected by the tpm, this method if implemented correctly through the whole chain should protect your cert and pkey.
that being said _should_ is the keyword,. i dont think any platform really managed to escape all attacks, though a lot in this area do need hw access (the tweezers previously implemented by the author :)).
Heh I always thought that TPM was there to secure anything. If it's only meant for secure boot then I understand the poor tooling and absence of APIs to use the thing properly inside applications.
It is absolutely used and designed for secure boot. There are now simpler mechanisms to accomplish the same thing, but if you want remote attestation, you need a TPM.
Hi Fox, i'm not aware of any other usages on the platform i'm familiar with sorry, maybe a gap in my understanding.
Afaik, if you want access to a chip like TPM, the OS will need to cooperate as such I/O access or MMIO or however it's accessed, will be privileged instructions likely.
I'd find it somewhat logical an OS or loader component starts verification, and then components upwards in the chain are well, chained together via verification, taking away the need to access the TPM after the initial modules are verified.
- Do you have any examples of how else the TPM is used? I'm very keen to learn more about it's use-cases.
> Hi Fox, i'm not aware of any other usages on the platform i'm familiar with sorry, maybe a gap in my understanding.
The TPM as a device is completely democratized and accessible by the normal user.
You can use it for platform attestation (which is this post is trying to point out might be broken in some cases), but it also works as a "discount" smartcard where you can seal data and shield keys.
Two examples here which I have written:
A file encryption utility for `age` that shields the keys in the TPM.
Conceptually both of these tools can also use PCR policy sealing as a form of platform attestation, but I have not implemented that yet as it's a bit hard to do this in a user friendly way UX wise.
As noted by others, you can also do disk encryption. `systemd-cryptsetup` does this on Linux.
> Afaik, if you want access to a chip like TPM, the OS will need to cooperate as such I/O access or MMIO or however it's accessed, will be privileged instructions likely.
Not really? `/dev/tpmrm0` is a TPM resource manager for Linux that is accessible by being part of the `tss` group.
> I'd find it somewhat logical an OS or loader component starts verification, and then components upwards in the chain are well, chained together via verification, taking away the need to access the TPM after the initial modules are verified.
This is only one of several use-cases of a TPM :)
This is also orthogonal of whether or not Secure Boot is part of the chain, depending on the operating system.
Thanks, that's interesting. as commenter noted i'd say this is part of the boot-process, but you are right, it's not technically secure boot related. booting securely != secure boot that's correct :)
It's used to establish a root of trust. If your operating system is modified, it fails to validate and the TPM doesn't release the secrets. If your BIOS is modified, it fails to validate and the TPM doesn't release the secrets. If your CPU is modified, it can tell the TPM what it wants to hear and get the secrets even if the BIOS or OS is modified.
For some people, this is a useful increase in security. Those people set up their own TPM according to their own rules. For the rest of us, who had one forced on us by Microsoft, it's just more anti-right-to-repair.
Each TPM having an unique certificate, you may use that to trace a specific machine to a specific user. Game developers could use that to ban (toxic) players from an online service, for example.
I believe you can't "reset" a TPM, but you can buy a new one (if your CPU does not support fTPM). Or buy a new PC I guess. Both solutions are costly though, depending on how often the cheat is found.
If you are sharing a computer with a hacker then your account would be banned anyways. All the tpm does is ensure you can't just make another account and use it from that computer.
