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)

▲

whiatp 3 hours ago | parent | next [-]

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

▲

bubblethink 4 hours ago | parent | prev [-]

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

▲

lakeviewterrace 4 hours ago | parent | next [-]

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.

	▲	bri3d 4 hours ago \| parent \| next [-]
		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.
	▲	bubblethink 4 hours ago \| parent \| prev [-]
		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).

▲

phoronixrly 4 hours ago | parent | prev [-]

Precisely, exfiltrate the pin, unlock the real one.

▲

phoronixrly 4 hours ago | parent | prev [-]

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.