The post-ultimate guide to better Full Disk Encryption with TPM and Secure Boot (with hibernation support!)

[-]

EnvironmentalCook520@reddit

Interesting. I already use btrfs with encryption but this seems like it goes a step further. I really like btrfs and being able to use snapshots.

[-]

With Debian I've found it way much easier to just compile sbctl version 0.17 with static linking and drop it to /usr/local/sbin, or download the Ubuntu package from openSUSE: https://software.opensuse.org/package/sbctl

Sealing empty PCR 15 is used in conjunction with tpm2-measure-pcr=yes to ensure that after booting, PCR 15 is overwritten by something else by an "extend" operation, so that TPM can no longer give up the key.

With Debian's official kernel, it's also possible to configure dkms to use the sbctl keys to sign kernel modules instead of using MOK, which simplifies the process, so that lockdown mode can remain enabled for security. With Arch's official kernels this is a pain as it's not compiled with the CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT option enabled.

[-]

blastrock0@reddit (OP)

I hope `sbctl` gets packaged by debian soon, I don't like much importing external packages. As for Option ROM digests, I understand that this is a problem if you remove the Microsoft keys from secure boot, which is not one of my goals, and it doesn't help much with the attack surface from my understanding. Thanks for the insight though, I didn't even consider this was an issue haha

I'm not sure I understand your point with keeping lockdown and how it's related to using sbctl or MOK. The only way I have found to enable hibernation is to disable lockdown as it is directly related. I am not disabling lockdown to load custom modules, that can be done just by signing the modules.

[-]

etherealshatter@reddit

If you don't remove the Microsoft keys from secure boot, then an evil maid can easily manipulate your efi partition with a rogue OS (e.g. based on shim-signed or a Debian live CD) to extract the key from TPM.

[-]

blastrock0@reddit (OP)

Ah I see, I'm only defending against laptop theft here. I don't try to defend myself against the evil maid since she could put a hardware keylogger if she wanted to. Also I dual boot windows, so removing MS keys is not an option, but I see your point.

[-]

TheOneTrueTrench@reddit

Note that in some (I believe rare) circumstances, removing them can brick stuff, see warning at https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys

[-]

shroddy@reddit

Wouldn't it me more secure to require the password to decrypt the volume, and instead set the login manager to auto login to avoid the need to enter the password twice?

[-]

TheOneTrueTrench@reddit

This is what I do with ZFS. My UKI doesn't have the password, it has a script to ask for it and then decrypts the zpool. I have my UKI (and a few other things) signed with my key.

[-]

Jealous_Diver_5624@reddit

Sealing the key to enter-initrd will brick systemd-creds (possibly in the future, I don't know how far behind Debian is in this regard). Pinning PCR 15 to an empty hash is no longer best practice either; instead, pin the actual volume: https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Pinning_a_LUKS_volume Additionally, you may want to pin PCR 11, which is the actual UKI (plus embedded commandline). I'm not sure how flexible Debian is in this regard, but you could probably also skip systemd-boot entirely and just boot the UKI directly.

[-]

ElvishJerricco@reddit

Sealing the key to enter-initrd will brick systemd-creds

There's been a lot of discussion about this on github, but no this is not the correct takeaway. As I said in my most recent comment, the enter-initrd phase is actually important. The thing with pinning PCR 15 to zero, or with fixate-volume-key, can be used to get the same effect, but you have to be very careful with it so that the initrd can't be fooled into mounting the wrong disk as the rootfs (e.g. rd.luks.uuid=a-uuid-with-dashes is vulnerable to /dev/mapper/luks-a-uuid-with-dashes being populated by a random LVM disk). So enter-initrd is just a very strong way to make sure decryption cannot happen outside of initrd.

Additionally, you may want to pin PCR 11

That is what --tpm2-public-key does, effectively. It makes it so that PCRs specified with --tpm2-public-key-pcrs (default to just PCR 11) can be anything so long as a signature for those PCRs with the specified public key can be provided. The UKI embeds that signature and makes it available to initrd for this purpose.

[-]

Jealous_Diver_5624@reddit

no this is not the correct takeaway. Why not? I am aware what the point of locking to enter-initrd is, but what it also does is bricking systemd-creds, unless you jump through the hoops of having multiple keys, which I feel is worth mentioning.

[-]

ElvishJerricco@reddit

Well I already explained why it's necessary, both here and on the GitHub thread. It's not the kind of thing where you get to choose whether it makes sense based on if you're willing to put in the effort; it's a solution to a problem that you must solve, or else the whole endeavor of encrypting the disk with the TPM was pointless and you might as well not have encrypted the disk.

[-]

Jealous_Diver_5624@reddit

As per my previous message: I am aware of the "why." The fact that it also bricks an integral part of the system if implemented without awareness of the additional hoops required, as was done in the main article, is still an important takeaway.

[-]

blastrock0@reddit (OP)

Ohh! This explains why that service fails to boot on my setup! I didn't investigate the issue since everything keeps working. I'll read that issue carefully, thank you!

[-]

blastrock0@reddit (OP)

That's good to know! I took the empty PCR15 trick from the arch wiki a few months ago. I'm not sure I understand the consequences of using enter-initrd. Things change too fast 😞

About PCR11 I understood it's redundant, and it will be checked when you use public key binding anyway.

Skipping systemd-boot works, and it was my previous setup. However, having a proper bootloader is convenient. I would love having limine in debian to have the restore from the boot, but we'll see for that in a couple years...

Thanks for the feedback, I'll check that further!

[-]

Jealous_Diver_5624@reddit

Things change too fast

They very much do, I was only made aware of the intricacies of stage binding when libvirtd stopped working because it couldn't decrypt its secrets anymore a couple of months ago.

[-]

ChocolateSpecific263@reddit

the article says:

"On older hardware, TPM chips were independent and visible on the motherboard, which made them vulnerable to key interception if someone tried to plug a few wires on the right tracks. More modern TPMs are called fTPMs, for Firmware Trusted Platform Module. In short, the TPM is itself integrated into the CPU, so the key can’t be intercepted as easily."

fTPM is the "cheaper" variant not the better.

"TPM 2.0 (Introduction of Sessions): The newer TPM 2.0 standard supports so-called Authenticated/Encrypted Sessions. The CPU and TPM dynamically generate keys during every boot process to encrypt the data stream traveling across the bus."

[-]

blastrock0@reddit (OP)

I see, but my point still stands: most consumer laptops nowadays come with an fTPM, which is not vulnerable to a plug-the-wires-and-sniff attack

[-]

FineWolf@reddit

fTPMs also implement the full 2.0 spec, including sessions. What point are you trying to make here?

[-]

ElvishJerricco@reddit

[PCRSignature:initrd]
Phases=enter-initrd
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key.pem

Note the lengthy conversation on github about this. I had to change the section in the arch wiki about this so that people would enroll the default key for all phases and only a separate key for the initrd phase, so that things which have to happen after initrd will still work when they use the default key.

[-]

arjunkc@reddit

I just did this this week, and gave up at the hibernation pitfall and disabled secure boot.

[-]

FineWolf@reddit

fTPMs are 2.0 compliant as well, and thus implement session keys. What's your point?

[-]

Kasoo@reddit

I'm not sure binding PCR 15 to zero is enought to defeat the attack on the oddlama blog you referenced.

The demo in the oddlama blog has PCR 15 measuring as zero before and after booting into the Alpine root image they use to request the encryption key from the TPM.

https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/#verifying-pcrs

[-]

blastrock0@reddit (OP)

Indeed, but PCR15 does change when a partition is decrypted. My guess is that things have changed since that oddlama post was written. The empty PCR15 trick is described here for that exact attack (IIUC) https://wiki.archlinux.org/title/Systemd-cryptenroll#Trusted_Platform_Module

[-]

TheZnert@reddit

Hey really nice writeup! I'm running Fedora with encryption, so I'm not sure I can follow along, but I still appreciate the effort you put in. I'm still dreaming that one day full disk encryption will be as easy as it is for "consumer" OSes, like Windows, Mac OS, Android, iOS - basically anything but Linux 😄

[-]

PrestigiousRadio3733@reddit

With Fedora you can bind to a PCR value using clevis. Clevis can act as the primary or secondary key, so you can still unlock your disk with a passcode, but as long as your device is physically attached to the same untampered system the disk will auto-unlock.

[-]

New_Grand2937@reddit

Does anyone know if the “unlockdown” module works with fedora?

[-]

blastrock0@reddit (OP)

It does, I used it for some time

[-]

New_Grand2937@reddit

Would that also allow for MSR writes for undervolting?

(See this tool https://github.com/kitsunyan/intel-undervolt)