https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/ #systemd #tpm #tpm2

@pid_eins any thoughts on this one?

@jarkko I have a list of similar bypasses listed in https://salsa.debian.org/debian/tboot/-/blob/master/debian/README.Debian?ref_type=heads#L80

@jarkko @pid_eins at least for clevis this is a known limitation of the tpm2 pin and documented in https://github.com/latchset/clevis/blob/master/src/pins/tpm2/clevis-encrypt-tpm2.1.adoc#threat-model

@jarkko It's a long text, but the person writing this is basically saying that a TPM2 policy for a disk that only locks to PCR 7 or not even that is not secure? I mean, no shit sherlock, of course it doesn't. If you policy doesn't lock to anything then it doesn't lock to anything...

A full boot chain that gets things right would include at least a UKI with a signed PCR policy + a dynamic systemd-pcrlock policy. The combination should be reasonably secure, I'd claim, but if you have neither…

@jarkko … then you have only a very weak model, probably to the point it's not worth it.

What matters is that distributions actually start deploying UKIs like this, and enable systemd-pcrlock by default. This is not trivial, but some distros are further ahead there then others.

@pid_eins This was circling around social media, I read it 3~ times, and could not catch the dragon tail...

The only thing I also did catch was that "PCR 7 locking is unsafe", which is obviously dead obvious, so I guess this is noise about nothing then :-)

@pid_eins @jarkko I suppose it's warranted in the sense that many distros are "not there yet" and that many resources (still) only talk about locking to PCR7. Your blog post from 4 years ago now is still one of the best resources (IMO) but only mentions PCR7 (because well, 4 years ago things were much worse):

https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html

@ljrk @pid_eins Thanks for all the feedback on this (from everyone who comments, all comments were useful).

I posted this mainly because could not get the gist, and was wondering do I have some blind spot here, that's all.

There's like a drum roll but no drop...

@pid_eins
Is there a kind of (even unofficial) reference distro you could recommend where one might be able to try out this & other recent features that are not yet mainstreamed (homed, etc.)? In particular I am thinking of having reasonable configurations so that the systemd components work well together and are not obviously insecure.

The furthest I have gotten so far was using systemd on Arch, but I sometimes am doubtful that the Arch wiki has the latest best practices for such a setup.

@pid_eins @jarkko It seemed worth pointing out the password fallback path still left the keys accessible.

@pid_eins @jarkko What I understood from that post is that, even if you locked to all PCRs instead of just 7, it's still not secure because of the password fallback, which allows booting from a modified filesystem (the attacker controls the password) with the same PCR state it would use for automatic boot. The fix would be to measure anything into the PCR state used for the lock, even when using password fallback, but for some reason tpm2-measure-pcr= does nothing at all in my testing.

@cesarb @pid_eins For my home desktop I would never lock password into the PCR's, i.e. that really should be a choice. Depends on deployment really.

@cesarb @pid_eins Also even if all those procedure were taken care of (rescue password locked into PCR's), I would never use a computer, which has been physically compromised. A physical compromise is a game over as far as I'm concerned, and TPM's work best against software attacks :-) That has been the driving design goal in the standard.

@cesarb @jarkko tpm2-measure= only does something if you boot a proper UKI.