Comment by nextaccountic

Comment by nextaccountic 5 days ago

6 replies

here is some actual security: encrypted /boot, encrypted everything other than the boot loader (grub in this case)

sign grub with your own keys (some motherboards let you to do so). don't let random things signed by microsoft to boot (it defeats the whole point)

so you have grub in an efi partition, it passes secure boot, loads, and attempts to unlock a luks partition with the user provided passphrase. if it passed secure boot it should increase confidence that you are typing you password into the legit thing

so anyway, after unlocking luks, it locates the kernel and initrd inside it, and boots

https://wiki.archlinux.org/title/GRUB#Encrypted_/boot

the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech

however, this is still better than, at failure, letting anything run

sophisticated attackers will defeat this, but they can also add a variety of attacks at hardware level

gorgoiler 5 days ago

I’d much rather have tamper detection. Encryption is great should the device is stolen but it feels like the wrong tool for defending against evil maids. All I’d want is that any time you open the case or touch the cold external ports (ie unbolted) you have to re-authenticate with a master password. I’m happy to use cabled peripherals to achieve this.

Chaining trust from POST to login feels like trying to make a theoretically perfect diamond and titanium bicycle that never wears down or falls apart when all I need is an automated system to tell me when to replace a part that’s about to fail.

  • nextaccountic 5 days ago

    Encryption is just a baseline. Nobody should have unencrypted personal computers.

    You can have both full disk encryption AND a tamper protection!

    • gorgoiler 5 days ago

      Sorry, I wasn’t clear enough. We’re talking about three things here:

      (1) Encryption: fast and fantastic, and a must-have for at-rest data protection.

      It is vulnerable to password theft though. An attacker might insert evil code between power-on and disk-password-entry. With a locked down BIOS / UEFI, the only way to insert the code is to take the boot drive out of the device, modify it, put it back, and hope no one notices. “Noticing” in this case is done by either:

      (2) Trust chaining: verify the signatures of the entire boot process to detect evil code.

      (3) Tamper detection: verify the physical integrity of the device.

      My point is that (1) is a given, and out of (2) or (3), I’d rather have the latter than deal with the shoddiness of the former

mikkupikku 5 days ago

> the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech

Reminds me of my old Chromebook Pixel I wiped chromeos from. Every time it booted I had to press Ctrl-L (iirc) to continue the boot, any other keypress would reenable secure boot and the only way I knew to recover from that was to reinstall chromeos, which would wipe my linux partition and my files with it. Needless to say, that computer taught me good backup discipline...

ahepp 5 days ago

Doing secure boot properly is kind of difficult. There are a bunch of TPM measurement registers for various bits and bobs (kernel, initramfs, cmdline, lots more). Using UKIs simplifies it a lot, but it’s not trivial to do right at the moment.

  • Nextgrid 5 days ago

    Secure Boot and TPM are separate things. The current Secure Boot policy gets measured by the TPM but that's about it.