[systemd-devel] Is tpm2-measure-pcr really an additional security?

[lacsaP Patatetom]

Le mar. 11 mars 2025 à 13:27, Lennart Poettering <lennart at poettering.net> a
écrit :

> On Mo, 10.03.25 19:25, Diorcet Yann (diorcet.yann at gmail.com) wrote:
>
> > Is PCR15 checked against a pre-calculated value saved in the signed
> initrd
> > before leaving initrd? If it's not the case, then when executing the init
> > from the chrooted malicious partition, the original /dev/sda1 LUKS will
> be
> > opened and mounted as var.
>
> I think you are misunderstanding what PCR15 is supposed to be. it's
> not really supposed to be consumed for FDE, but simply populated by
> FDE. It's usecase was to later have PCR that identifies the local
> system, that we can lock encrypted credentials or systemd-confext
> images to.
>
> To protect the order of things use the "phase" logic, i.e. in PCR 15.
>
> And to say this very clearly: the model this is designed for assumes
> you have one encrypted fs not many. i.e. if everything checks out then
> you get access to it, and if it doesn't you don't. I am not sure I
> understand your scenario, but you appear to work with two encrypted
> disks, one for the rootfs and one for /var/? Yes, there is no
> protection for using them for the wrong purpose (ie. the root fs for
> /var/ or vice versa), because that was never in the picture of being
> an issue.
>
> If you want multiple encrypted partitions like that, then things are a
> lot more complicated, but let me ask you: why even? It makes sense to
> split up things so that you have various sets of data with different
> protections (i.e. some unprotected, some verity protected, some
> encrypted + tpm). But if you have multiple partitions protected the
> same way, why split them up, and why create such a headache then.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>

hi,

I hope I'm not being (totally) off-topic with this :
https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/ .

regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250311/cc048fe8/attachment-0001.htm>