Is there a working method to use argon2id with encrypted /boot?
Is there a working method to use argon2id with encrypted /boot?
When you cryptsetup luksFormat, LUKS2 cryptography defaults to argon2id, a competition-winning gpu-resistant multi-core memory-hard algorithm thingy. Only problem is everyone only supports pbkdf2 instead :3
- GRUB had an argon2id support patch in the works. Buuut it stopped because a version-pinned dependency added argon2id support, and GRUB wants to update lib x to update lib y to update lib z to update said dependency (2 years later... I'm here D: )
- systemd-boot is simple and doesn't support argon2id
- efistub, i.e. making the kernel boot itself (i think?), necessitates secure boot and I'm not sure that's the best way to do this (Ventoy can bypass secure boot with MOKMANAGER funkin' anyway, can't it?)
- Raspberry Pi's bootloader might support argon2id? idk
Not to be deterred, I tried manually patching GRUB (tried with aur on a usb, then with portage) but I don't think these are supported with the latest GRUB. (Attempted with whatever the aur package uses, then Gentoo's grub-2.12-r4, then Gentoo's grub-2.12-r5, then git cloning and checking out older versions manually, then picking the earliest 2.12 archive.org tarball to patch lol. All failed with "couldn't find disk"-esque issues)
Does anyone have this working at or after Nov 2024? And better yet, am I missing something obvious ¯\_(ᵕ—ᴗ—)_/¯
Threat model: Avoiding a twopointfouristan prank, but also just screwing around for fun (◡‿◡✿)
-
I'd argue any solution necessitates secure boot, not just the efistub. If someone is determined enough to modify your kernel they'll be determined enough to modify your bootloader
-
I was about to write something similar. You're just pushing the problem down the stack, and argon2 doesn't fix that particular one anyways.
The facts are:
- You always need an unencrypted entry point, so encryption can't be your secure anchor (though it could never be anyways, you're looking for authenticity there, not confidentiality)
- As the original post states, making sure an attacker never has physical access to your boot or EFI partition works against that particular evil maid attack. It won't protect from other threats however and isn't very practical.
- You need to authenticate your whole boot chain for actual protection, including initrd, which the linked article also rightfully points out
- The only system available to normal users to provide authenticity protection mechanisms is Secure Boot (with implementations not always perfect)
- In practice, you need to enroll your own keys to sign your initrd and have a mechanism to actually check it, or use something like a signed UKI
- In your actual system, make sure your boot partition is only available to root - EFI mandates vFAT which doesn't support owner attributes, so put on a restrictive mask (0077)
- Your UEFI needs to be protected by password so that an attacker can't just disable Secure Boot and replace your protected files
With all these in place, you should set up booting from an encrypted partition where they key is loaded from the TPM with sufficient PCRs bound and a PIN or something similar. I'm unaware of current solutions to easily have a kernel check against the registers during boot, so in case your system won't decrypt with the PIN as your input alone, you know that your boot process has been altered (not necessarily malicious, could be a firmware update, but still).
Real security is hard, there is no easy solution if the vendor doesn't control the hardware (which both Apple and Microsoft do), most users don't care that much that distribution would push for it. You rather still have the unhealthy "open source is secure and TPM / secure boot is a Microsoft tool to lock out other operating systems" attitude.
PS. this is not meant as a guide for setting up a secure system, just some considerations when considering the approach.
-
-
The way I do it is I use a UKI. It's an approach similar to efistub, you pack the kernel and initramfs into a single EFI file, then sign it with custom Secure Boot keys generated with sbctl.
-
Can't Ventoy bypass secure boot with the shim thing? i.e. ENROLL_THIS_KEY_IN_MOKMANAGER.cer
Or is secure boot just to ensure that "this kernel uki hasn't been tampered with"?
Furthermore, if it's secure boot autounlocked by TPM, won't I have to password protect my bootloader too to avoid kernel parameter oopsies? (Lol changing kernel parameters right then and there reminds me of the windows utilman trick)
The secure boot route seems fraught but perhaps I'm looking at it wrong
-
The simplified way of how Secure Boot works is you have a bunch of public keys stored in the UEFI, and you can sign .efi executables with the private key. If the signature of an executable is invalid or the file has been tampered with, UEFI refuses to run it.
Now, every computer sold nowadays comes with Microsoft's keys pre-installed, one for Windows and one for stuff that Microsoft deems worthy of signing.
One of those things is shim, it's signed with one of Microsoft keys and it looks for the MOK database to see what it can boot or not.
But you don't have to use Microsoft keys, you can make your own, put it in your UEFI and sign your stuff. That's why UKI is useful, it's a single EFI file you can sign. You can even sign your bootloader, like systemd-boot. The Secure Boot Arch Linux Wiki link contains information of how to do it easily with sbctl.
TPM is completely independent of Secure Boot, it can be used with or without it.
-
-
-
Please let me know if you figure it out. I opted the detached header approach a few years ago because it had most of the same benefits without the headache and poor support. I'm wondering if it might be possible to replicate what Grub is doing as it us relatively trivial but that doesn't mean easy. Basically you'd have a Secure Boot signed bootloader that is able to boot a protected file system (secondary /boot) where your kernel & initramfs, or combined image exists. This secondary boot partition can be a lot more flexible though so it could even read a sparse-baded file that has a file system stored in it, and then from there you'd unlock the second layer of encryption. My guess is it can be done using something besides Grub and you'd have full access to all the algorithms available under cryptsetup.
-
Well thats only slightly terrifying. I thought tpm was the fix to this since it will verify the boot itself but thats doesnt seem to be available for most systems.
-
TPM can be the fix, but it needs to be integrated into the boot process correctly.
https://0pointer.net/blog/brave-new-trusted-boot-world.html mentions some or most of the pitfalls
-