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 (◡‿◡✿)

  • Laser@feddit.org
    5·
    5 days ago

    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:

    1. 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)
    2. 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.
    3. You need to authenticate your whole boot chain for actual protection, including initrd, which the linked article also rightfully points out
    4. The only system available to normal users to provide authenticity protection mechanisms is Secure Boot (with implementations not always perfect)
    5. 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
    6. 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)
    7. 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.

    • Scoopta
      1·
      4 days ago

      The last time I tried enabling a UEFI password clearing the CMOS would clear it. I haven’t tried on my latest mobo…but I’m just putting it out there that SOME UEFIs do that

      • Laser@feddit.org
        2·
        4 days ago

        Clearing CMOS clears it, but you will lose the TPM attestation, which indicates tampering

        • Scoopta
          1·
          4 days ago

          By that statement I take it then without TPM you basically can’t have truly secure secure boot? Since the password is your protection from secure boot tampering but the TPM is your protection from password tampering

          • Laser@feddit.org
            1·
            4 days ago

            Realistically, no.

            Theoretically, if you enable Secure Boot and a boot password through UEFI, it might be OK for some purposes, as an attacker clearing your Secure Boot settings would also reset the boot password, which you’d probably notice.

            If you’re concerned about Evil Maid attacks, use Secure Boot with a TPM. If your only concern is getting the device stolen with you losing access, Secure Boot from my point of view is only a convenience feature for stuff like easier unlocking

            EDIT: it should be mentioned that technically, Secure Boot doesn’t require the TPM and just checks the signatures. However, you’d need to check on each boot whether it’s actually enabled with the correct settings and that your device has not been reset. The automation of this is sometimes called Measured Boot, which the TPM is used for. Secure Boot by itself doesn’t protect you against sophisticated physical attackers. But the boot measurement gets thrown into the term because it makes sense.

            At least that’s my understanding.

            • Scoopta
              1·
              4 days ago

              I am aware secure boot doesn’t require a TPM, but I’ve always been confused by its purpose since it’s trivial to disable. Makes sense if you use it in conjunction with TPM measurements. I personally encrypt all my filesystems except my /boot which is also my ESP, I use the efistub and that’s good enough for loss of device. For a physical attacker with actual skills I’m SOL, it’s not that I don’t want to protect against it, I just couldn’t figure out a reliable way to.