FDE, TPM, Secure Boot, and Linux

I’m sort of a security junkie, so I wanted to see how locked down I could get the Framework laptop. It supports UEFI, and has a TPM 2.0, so the theory was that it could get pretty far. Following in the footsteps of Matthew Garret and Trammel Hudson’s Safeboot project, I wanted to see how easy it would be to do the following:

  • Full disk encryption (FDE) with the decryption key stored in the TPM
  • Arbitrary secure boot key enrollment
  • Secure boot using a signed unified kernel
  • Additional goodies, like tpm2-totp
  • Systemd-boot for boot management

I’m running Arch Linux, so I mostly followed a combination of the Arch wiki pages for Secure Boot, disk encryption, and systemd-boot.

Disk encryption

I have rolled out FDE+Secure Boot on a pretty wide variety of systems in the past using a wide variety of tools. Typically the trick with FDE is getting the disk to unlock on boot, assuming everything checks out in the firmware (akin to Microsoft BitLocker). Until recently, it had been theoretically possible but I’d never had much luck. Recently, however, systemd has implemented support for early-stage TPM interaction, including storing a LUKS2 key in the TPM and pulling it out at boot if certain PCR values check out. The new features are systemd-cryptenroll, which I happily discovered when setting up LUKS this most recent time.

So, following the standard disk formatting and encrypting guides for LVM and LUKS, setting a password, and enrolling the initcpio hook, I could enter a password at boot time to unlock the disk. Running systemd-cryptenroll, I can cache the key in the TPM, and unlock it if PCRs 0 and 7 match expected values automatically on boot, no password needed! (PCRs are hash chained, so once you have the PCR you want, in this case PCR 7, which stores Secure Boot info, you know what you need to know. Keeping 0 just makes sure that we’re on the machine we think we are). It works like a dream!

Secure Boot

The next step was to actually set up Secure Boot, which along with systemd-boot allows us to verify the system state up to the launch of the kernel. Following the arch wiki, I generated keys using Rod Smith’s script and put them on my efi system partition (/boot by default). Then I opened the Framework firmware interface,set a firmware password, turned on Secure Boot, and enrolled the keys under the Secure Boot option on the Security page. This was by far the easiest time I’ve ever had enrolling keys. Now my system decrypts the disk and boots only if the firmware checks out. By using sbupdate to generate and sign a unified bootloader+kernel image, it’s now much harder carry out Evil Maid attacks and the like on my Framework laptop (though as recent findings have shown, not impossible if you can sniff keys of the TPM bus).

Future work

Ideally I’d like to get TPM2-TOTP implemented, where the system shows me a one-time password on each boot that I can verify with a MFA app on my phone. So far, I can’t seem to get the value to display in Plymouth, though I’m not sure what I’m doing wrong. It’s all very new tech, so it could just be that.

I’d also like to use dm-verity to set my root partition as read-only, which in theory extends Secure Boot guarantees up into the OS (something akin to Safeboot’s SIP clone). That’s what I’m going to work on next.

Despite some initial uncertainty, the TPM and Secure Boot infrastructure on the laptop works exactly as expected, and the firmware has been a dream to work with compared to other vendors (ahem HP). It’s even easier than Lenovo IMO. Hopefully this helps someone else make their Framework more secure! Most of the tools aren’t specific to Arch, if you’re using Debian/Ubuntu you can just use Safeboot to get a lot of what I’ve done above. I’m sure Fedora has similar packages too.

If there’s any interest, I’d be happy to do a step-by-step write-up.


Seriously @nrp, thank whoever designed the firmware interface for me. It’s so nice to just be able to interact with TianoCore as intended :joy:

1 Like

Thank @Kieran_Levin !

1 Like

Many thanks @Kieran_Levin :pray:


@mbernhard thank you so much for the detailed write up and kind words. I am glad you tried this out. FDE with TPM backed keys has gotten a lot easier in the last few years :).


Update: I got TPM2-TOTP working!


Since you offered, it would be great to do a step-by-step write-up. :slight_smile:

Also, any additional care required for dual-booting configs?


@Somebody I’ll try to get to it tomorrow!

Re: dual-booting, tbh I’m not totally sure. If you’re using Windows and Ubuntu/Fedora, you’re probably okay (and you don’t have to replace the keys if you don’t want to, though I would). In principle, as long as your boot manager is signed you can do “Secure Boot”, as it only covers up to the boot process. You can’t do a unified kernel, per se, but you can probably put Windows+Windows BL and linux+linux BL into unified images that you can sign. Tbh I’m not sure how well that would work. Dual booting is kind of against the philosophy of Secure Boot.


Huh, very nice! I’m curious to attempt running a similar setup once I get my laptop (batch 2 edition so should ship some time this month in theory) and the time to set things up.

Yup, batch 2 orders should be shipping shortly, there is a thread with most of the action.

@mbernhard I’d be very interested!

1 Like

@Somebody @Anil_Kulkarni check out Securing an Arch Linux Install


I’m curious what could be done in regards to going another step further and requiring a FIDO2/Physical PGP key to be present.

I’ve got two Yubikey’s laying around I could in theory use as physical key in addition to a password, but I’ve got not much ideas on how to properly implement such a thing.

Curious to see what others think. :slight_smile:

I think there is a way to do key splitting for your disk encryption key using a hardware token, so that you can only decrypt the disk using a password and your HST, but I don’t know much more about it than that. It should definitely be possible to stash the disk encryption key on your HST and add a hook to try to read it from there, but I haven’t done it before.

Slightly off-topic, but Pid Eins has published a very interesting - albeit aspirational - article on common attack vectors, how the common Linux distros are currently vulnerable and a set of recommendations. Great read for those interested in this topic.

1 Like

This bit gives me significant pause. A large part of the reason I and many others use Linux is that we’re not locked into what some vendor provides.

His proposal does not require vendor lock-in – that’s just the easy path. People willing to go through the effort of managing their own chain of trust can augment or even forego vendor certificates. In fact, one of the benefits his suggestion provides is to get away from the current mechanism where Microsoft is the only authorized signer.

I imagine that if distro vendors develop tools to manage the chain-of-trust, it wouldn’t be long before individuals could use those same tools, making the non-easy path less hard for us.

The main point I got from the article is that the current state of secure boot on Linux (as implemented by major distros) provides no meaningful security benefit beyond protecting user data from a casual thief. Any protection against a determined attacker requires significant custom effort – likely beyond many of the folks who need it most.


Did you play with boot / hard drive passwords? Trying to figure out if this has been added to the UEFI beta yet. Getting antsy waiting for my batch 5 unit to ship, and I’ll be following along with your steps above, but I’d like to pursue a couple additional. Namely locking down boot, and stacking on an OPAL2 encrypted drive at boot.

I’ve been running a BIOS password since I got mine, so that definitely works. I haven’t tried an OPAL2 drive, I use block-level encryption and that works well.

@mbernhard I know this is a bit of an old topic, but do you mind explaining in more detail how you got secure boot working?

I generated my keys with that script and put them in /boot/efi-keys, I set sbupdate’s KEY_DIR to that directory and generated the unified kernel image. I went into the firmware interface and enrolled DB.cer, KEK.cer, and PK.cer, and then enabled Enforce Secure Boot, but I reboot to this message:

Default Boot Device Missing or Boot Failed.
Insert Recovery Media and Hit any key.
Then Select ‘Boot Manager’ to choose a new Boot Device or to Boot Recovery Media

Then I have to disable Secure Boot to boot.