TPM–Fail: TPM Meets Timing and Lattice Attacks | Hacker News Reader

TPM–Fail: TPM Meets Timing and Lattice Attacks

tpm.fail

90 pointssohkamyung29 comments

I think Paul Kocher first published about timing attacks in 1996 (https://dl.acm.org/citation.cfm?id=706156). The fact that industry giants not only sold them, but got them certified says a lot about how much assurance CC and FIPS evaluation buys you...

In my view this is some kind of argument as for why you should not (ab)use TPM as general purpose HSM (ie. for something that it is not designed for) and it does not say much about the security when it is used correctly (as a local attacker that has TPM in state where it will sign literally anything I throw at it, what exactly does key recovery attack buy me?)

Not sure why you'd say it's not designed for this. They call out the fact that it was specifically certified for such use and to be resistant to such attacks.

To me this sounds like exactly the same as Minerva [1][2] but in TPM instead of in smart card.

1 - https://minerva.crocs.fi.muni.cz/

2 - https://news.ycombinator.com/item?id=21147865

Does this allow users to install custom OSs on devices with verified boot chains like game consoles and phones?

If I’m reading this correctly, it means the private key of a certificate is leaked during generation. Boot chains rely on the verification of certificates and signed data, not signing. So no.

So this lets you grab the key on your own device which is used to encrypt the storage but not the OEM key used to sign the firmware image?

Almost. s/encrypt the storage/sign the remote attestation document/.

Storage would be encrypted with a symmetric AES key, this only leaks asymmetric ECDSA signing keys

No. There are two different things, Secure Boot (which prevents the device from running unsigned software) and Trusted Boot (where the device can run anything but can prove to a remote party that it's running a specific software).

Because this would only leak private keys inside the device, you can only attack Trusted Boot (where producing trusted signatures is important), not Secure Boot (which only verifies signatures that were produced elsewhere).

The PoC mentioned in the ZDNet article (https://www.zdnet.com/article/tpm-fail-vulnerabilities-impac...) seems to be out...

https://github.com/VernamGroup/TPM-Fail/

That code is nonsense. It's a perl script that messes around with cowsay and does not make a single tpm command.

Yeah, that code is a hoax. The code isn't available yet, but when it is it will be here:

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

Is there a good reason for a security conscious hi value target shop to use VMs or docker when they don't control the whole box?

That depends on what you are protecting, but in general if you are high-value enough that it's worth it for somebody to try to attack you through VM instances sharing the physical machine, you should be managing your own hardware and using physical HSM's to protect keys.

The link to the paper[1] is a 404. Did anyone manage to grab a copy of the paper? I haven't thought about lattices since gradschool crypto classes, and was excited to see if I could comprehend anything after 10 years. :(

[1]: http://tpm.fail/TPM-FAIL.pdf

It appears to be here now: http://tpm.fail/tpmfail.pdf

Thanks!

Are there many uses of signing with a TPM on consumer hardware? I can see the issue with servers, but not much else.

https://docs.microsoft.com/en-us/windows/security/informatio...

It's used to store th private key of user certificates, but those are PIN protected presumably. But a key that isn't supposed to be extractible may well be so.

The TPM can be used to store and protect Bitlocker keys.

I have not read the paper, and I could be wrong. However, these appear to be attacks against the crypto implemented inside a TPM/fTPM.

The reference implementation of TPM 2.0 leaves the choice of the crypto library up to the platform vendor. If my suspicions are correct, it sounds like some of the platform vendors decided to use crypto libraries vulnerable to timing attacks. Hmmm...

If you look at IBM's TPM 2.0 implementation[1], you can see that they don't use any well tested libraries for crypto primitives, but rather uses what looks like home-cooked crypto implementation.

Microsoft, on the other hand, seems to support OpenSSL and wolfSSL in their simulator[2].

[1] - http://ibmswtpm.sourceforge.net/ibmswtpm2.html [2] - https://github.com/microsoft/ms-tpm-20-ref

You're not supposed to use the IBM TPM emulator for anything except developing software that talks to a real TPM without using a real TPM.

Sure, but what exactly do you think real TPM manufacturers are putting inside them? They must run some crypto code, do you think they won’t just reuse IBMs emulator? Or that they will come up with something more secure?

I hope that's what happens, yes.

IBM's implementation is really scary. I read through the codebase and my WTF meter went through the roof. It looks like the codebase of some evil genius that invented a world of coding practices of his own.

You’ll find it interesting then that this codebase is mostly consisting of reference implementation. These WTF practices are straight from TPM 2.0 standard. See https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev...

The researchers used the intel tpm2-tss stack.

tpm2-tss is not an implementation of a TPM, it's a client of the TPM protocol that talks to a server. The server in this protocol can be a real TPM reached by a linux device file or a TPM arbitrator (in kernel on in userspace) or a TPM emulator (the IBM one linked above), etc.

tpm2-tools are CLI utilities that use the tpm2-tss library.

Reply on news.ycombinator.com