4 ms·
> but those have a downside of the TPM needing to be updated with every new kernel. This depends on the configuration. If you don't bind the key to PCRs at key
by wiktor-k 3y ago
> but those have a downside of the TPM needing to be updated with every new kernel.
This depends on the configuration. If you don't bind the key to PCRs at key creation time kernel updates don't affect the workflow and you still will take advantage of other TPM features such as locking the key after several unsuccessful attempts.
Take a look at the systemd configuration:
https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html https://www.freedesktop.org/software/systemd/man/systemd-cry...
I'm using it on my laptop and it works well.
- jandrese 3y agoIMHO the PCRs are way too much trouble and defend against attacks that are rare outside of extremely spooky circles. They were the biggest problem with Bitlocker too.
- alexeldeib 3y agoYeah, I recently went down this path. It’s all doable but frankly I’m not a nation state target and getting locked out after a kernel update or similar would be far more annoying. Instead I’m leaning toward separate boot and root disks, with a root/data disk encrypted with LUKS with a detached header. dm verity on a read only root with a separate data partition also seems simple/appealing. Of course, these all allow attacks full secure boot/tpm/etc avoid, but it’s a balance.
- wiktor-k 3y agoPCRs being problematic was actually one of the issues policy mechanism in TPM 2.0 was meant to resolve (see "Non-Brittle PCRs (New in 2.0)" in [0]). Tldr version is that you'd authorize OS manufacturer's kernel signing key to use the TPM key so that each time your OS vendor signs the kernel it's OK for the TPM. Sadly I don't think I've seen this deployed in the wild. [0]: https://ebrary.net/24725/computer_science/quick_loading https://ebrary.net/24725/computer_science/quick_loading