On Tue, 2021-12-21 at 13:47 +0100, Thorsten Kukuk wrote:
I'm missing something essential in the TPM2 scenario. It offers (some) protection against tampering. But how does it protect the contents of the storage from being read by 3rd parties? What if someone simply steals the computer and boots it from a USB stick or a DVD?
The USB stick or DVD will create other boot measurements and thus the TPM will not give out the hash to decrypt the harddisk.
In which PCR would these different measurements be?
Another remark: the wiki page calls the encrypted boot partition setup the "most secure", but it doesn't mention that GRUB2's cryptomount is painfully slow even on the fastest modern CPUs. I recently tried this (with LUKS1, no TPM), and soon reverted to unencrypted boot because I just couldn't stand having to wait ~30s just for decryption of one LUKS key slot.
The problem is the initrd: if your boot partition is not encrypted, the initrd is not protected and the weak spot.
There is somewhere a blog by Lennart about this, maybe it explains the problems better.
I understand this, but TBH, as long as the excessive slowness of the decryption in grub isn't fixed, I see no practical value in encrypting /boot. IIUC it can currently be "fixed" only by weakening the encryption (using less KDF iterations or a weaker hash), because crypto hw accelleration isn't (easily) available in the restricted environment grub2 operates in. I once saw a reference where the grub author talked about that, can't find it any more. https://unix.stackexchange.com/questions/369414/grub-takes-too-long-to-unloc... Regards Martin