Hacker News Reader

Comment by phoronixrly | Hacker News Reader

This is still vulnerable to evil maid. You need to be able to attest the system before you enter the PIN.

Sealing to a reasonable subset of PCRs (ie, not just 7 like the article) is reasonably strong against point-in-time evil maid, no?

Like, in Evil Maid Scenario 1, where the Evil Maid only has one-time access, if you've sealed to say 0,2,4,7,9 , or 7 and 15 with a reasonable setup for what gets extended into 15, the Evil Maid's Fake PIN Entry Software would _not_ validate in the secured boot configuration and couldn't actually unseal the TPM, only coerce you into entering your PIN. Then the Evil Maid would have to physically return to your "correct" boot state with the PIN to unseal the disk, no?

(this is all modulo firmware and early boot exploits, of course, since in that case the attestation could also be forged also)

The maid can just swap out the laptop for a diff one.

Precisely, exfiltrate the pin, unlock the real one.

A different one ... that you would notice immediately because the PIN would not unlock your disk?

You're in here shitting on TPM but don't seem to understand the threat model at all.

What does it matter if it doesn't unlock the disk? It's a different device with a logger. The purpose of the maid is to be evil and steal your pin. The maid has your real device. The only way to prevent this is by you authenticating the device before you enter anything. Look at the heads project (https://github.com/linuxboot/heads).

No, I think this is a valid threat model and a good rebuttal. The evil maid steals the original laptop, replaces it with a second laptop with a look-alike PIN entry screen without an attestation. You enter your PIN, it is transmitted to the evil maid with the first laptop, and your data is unlocked. You would notice, but your data would be exposed.

Now, to be clear, I don't think this negates TPM-sealed disk encryption or TPM-and-PIN sealed disk encryption; they're still meaningfully better than the alternatives (with a passphrase alone, your data is already compromised regardless in this invented scenario, and all scenarios are equally variable to the swiss-cheesiness of UEFI firmware unless it is replaced). But it is a valid model.

I would call out if it is a solder on TPM (or worse a removable module) MITM attacks work against the TPM. (I don't know why, but apparently new dell servers are still shipping with solder on TPMs and having the BIOS/UEFI firmware measure into that instead of just using the AMD EYPYC CPU's fTPM.) TPM isn't actually going and measuring anything on its own, it just gets PCR extend commands containing hashes sent over from the CPU that it has to trust are meaningful. If you can watch the bus (usually just SPI) it would be trivial to monitor the traffic to the TPM during a reboot and watch the hashes it is expecting to see, at least for the boot artifacts, which could be replayed into the TPM after it is disconnected, and then the TPM would happily unseal the secrets for the attacker's microcontroller, even for sealed secrets they weren't able to watch go past while monitoring. So, IMO against physical access the PCRs aren't doing a whole lot, and the whole thing is resting on a PIN. (Obviously this is a huge problem for servers, where a PIN is probably not in use.)

For what it's worth, TPM supports session encryption, but the compatibility is poor due to bad TPM implementations (which is a whole extra can of worms), so it isn't enabled by default in most configurations. If this threat model is meaningful to you (which it probably is if you're using TPM-backed FDE), it's worth looking into what it would take to set up (and switch to fTPM if possible).

Although, if anyone wants an RE project, I've always been interested in reversing the ME <-> CPU bus on Intel to see if the ME-embedded TPM is still vulnerable to snooping. And of course all of this is still highly vulnerable to any early-boot / root of trust exploit (ie against Boot Guard / PSB or horrible UEFI firmwares).

tpm2totp used to do this, and it also eliminated the need to divulge the secret used to unlock the TPM, I now see that it has not seen a commit in 2 years.

I also hear mjg59 is looking into encrypted swap hibernation support, so there's a slim chance there will be some development on the system-attestation front.

Reply on news.ycombinator.com