Since you offered, it would be great to do a step-by-step write-up. 
Also, any additional care required for dual-booting configs?
3 Likes
@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.
3 Likes
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.
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.
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.
3 Likes
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.
Hi @Cassidy_Wilson, there are a couple of things this could be. Have you verified that your unified kernel image is really being signed? You should see some warnings about “PE/COFF” section sizes if it is. Alternatively, did you enroll the PK after you enrolled KEK and db? You can check that your keys are there by using mokutil --pk (or looking in the firmware interface).
Another possible issue could be that the firmware doesn’t know about your image. I think sbupdate should take care of that, but you can check bootctl or efibootmgr to see if something is pointing there.
1 Like
Thanks for the response! I figured out soon after I typed that comment that my boot loader hadn’t been signed, so I had to do that.
Now that is really interesting!
Seconded. Definitely seconded!
If somebody is interested, I developed a tool to sign EFI files (linux + initramfs), which mount a dm-verify verified squashfs at boot, which also provides A/B-style updates/rollback.
Using the TPM2.0 for disk encryption is possible with systemd-cryptenroll and tpm2-totp also works in the initramfs.
Since I am probably the only user, this is not considered production ready. At the moment it also only works on Arch Linux, but I will add at least debian in the future.
5 Likes
Since I don’t know a lot about Secure Boot, I’d really love a step-by-step. I want to use Linux and be as secure as possible. I currently use Arch Linux and a LUKS / partition, but would be interested in your setup.
Thanks for the post and I’ll be interested in anything further you document.