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. :(
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.
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.
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.
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).
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].
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?
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.
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.
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.
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...
32 comments
[ 3.2 ms ] story [ 77.2 ms ] thread[1]: http://tpm.fail/TPM-FAIL.pdf
Storage would be encrypted with a symmetric AES key, this only leaks asymmetric ECDSA signing keys
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 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...
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
tpm2-tools are CLI utilities that use the tpm2-tss library.
1 - https://minerva.crocs.fi.muni.cz/
2 - https://news.ycombinator.com/item?id=21147865
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.
https://github.com/VernamGroup/TPM-Fail/
https://github.com/VernamLab/TPM-Fail