Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TPM–Fail: TPM Meets Timing and Lattice Attacks

tpm.fail

Post reply on HN
Print view View original

11–20 of 33 posts

Re: TPM–Fail: TPM Meets Timing and Lattice Attacks

#11

Post by tedunangst »

dfox wrote: post #6

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.

Re: TPM–Fail: TPM Meets Timing and Lattice Attacks

#12

Post by munchbunny »

jgalt212 wrote: post #7

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.

Re: TPM–Fail: TPM Meets Timing and Lattice Attacks

#13

Post by vermilingua »

baroffoos wrote: post #9

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.

Re: TPM–Fail: TPM Meets Timing and Lattice Attacks

#14

Post by baroffoos »

vermilingua wrote: post #13
baroffoos wrote: post #9

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?

Re: TPM–Fail: TPM Meets Timing and Lattice Attacks

#15

Post by xyzzyz »

locacorten wrote: post #10

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

Re: TPM–Fail: TPM Meets Timing and Lattice Attacks

#16

Post by wolf550e »

xyzzyz wrote: post #15
locacorten wrote: post #10

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.

Re: TPM–Fail: TPM Meets Timing and Lattice Attacks

#17

Post by matthewaveryusa »

xyzzyz wrote: post #15
locacorten wrote: post #10

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

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.

Re: TPM–Fail: TPM Meets Timing and Lattice Attacks

#19

Post by dlgeek »

baroffoos wrote: post #9

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

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).

Re: TPM–Fail: TPM Meets Timing and Lattice Attacks

#20

Post by dlgeek »

baroffoos wrote: post #14
vermilingua wrote: post #13

Earlier quoted context omitted.

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

Post reply on HN