Hacker News Reader

Comment by mjg59 | Hacker News Reader

What would that get you? The input devices are almost certainly going to be internal and PS/2 or I2C, and if you're the sort of person doing this you'd be using encrypted storage.

View on HN

I mean tapping the external SPI connection at that point. You can't encrypt the first stage that gets loaded into the CPU, so you would simply replace that with your rootkit and then continue as normal until the user types the decryption key into the now-compromised device.

The CPU measures the first block of the firmware into the TPM. This is already a solved problem.

I'm fascinated by the idea of having a TPM without any on-board storage for it to use. How do you propose that would work?

If you're willing to accept stateful storage for the TPM then I agree this is straightforward, but then I don't think the "stateless device" has been achieved. If you're willing to trust the TPM's storage then you could have just used that to establish trust for everything (which is the status quo on chromebooks).

As described in the article, PTT includes a TPM running on the ME. The CPU loads the ME firmware (which is validated against a key on the ME), then starts executing the rest of the firmware (including copying measurements to the TPM).

So it just boils down to TPM-protected encrypted storage? That obviously works (because it's how a bunch of devices work today), but it's a lot less exciting... if you can set up a full TPM stack for sealed storage (which we don't have on consumer linux today :( ) then I don't see what attacks this "stateless laptop" defends you against that the TPM doesn't already handle.

Reply on news.ycombinator.com