[heavyset_go]

Stick a BIOS password on your machine and turn on Secure Boot.

Unless there's an exploit in your firmware, you are now secure against petty criminals stealing your data to even somewhat sophisticated attacks from non-state actors via data exfiltration, software keyloggers, etc.

You can go another step further and use Secure Boot in a chain of trust up to the kernel with Linux, ensuring everything up to the kernel from boot isn't tampered.

Secure Boot isn't about protecting yourself from the OS or software, it's about establishing a chain of trust from the boot process up so you are running the system you intend to run.

This comment assumes you're using disk encryption on top of Secure Boot. When doing FDE, unless your firmware supports it, part of the boot process must be unencrypted to spin up encrypted disk access, and to protect that process, you can sign the unencrypted software to ensure its authenticity despite lack of encryption.

[fsflover]

> you are now secure against petty criminals stealing your data

Ordinary disk encryption would protect me too here, wouldn't it?

[npteljes]

I believe not. Even with full disk encryption, you need an unencrypted bootloader after uefi to decrypt the disk.

https://security.stackexchange.com/questions/267222/full-dis...

So, there are two scenarios here.

First, PC with FDE + normal boot gets stolen. The attacker cannot get the data without the password, so it's safe.

Second, unattended FDE + normal boot PC gets tampered with. Attacker manipulates the bootloader. Unsuspecting user later boots the tampered PC, unlocks the FDE, gets owned.

[fsflover]

The second case requires a professional, dedicated attacker. I use TPM with Heads and a hardware key to protect myself against it. It will notify me if the boot partition or BIOS are tampered with.

As an advantage, all relevant code running on my computer is FLOSS and auditable, unlike the Secure Boot and UEFI.

[npteljes]

That's a cool setup! I didn't know about Heads.

And yes, getting back to the original topic, I believe that against petty criminals, even a full disk encryption is plenty defense. They won't go about installing anything to the EFI partition just to get to the data.

This Coreboot + Heads setup I'd trust to protect against even the more involved.

[heavyset_go]

Unless your BIOS/UEFI supports full disk encryption unlocking of hardware-encrypted Opal drives, you will always have an unencrypted bootstrap process at early boot from the disk.

That unencrypted bootstrap process can be modified by anyone with access to the disk, physical or remote. Theoretically, someone can inject a keylogger into the process and exfiltrate your encryption key's password, or a process that waits until you're decrypted and exfiltrates your data. It's also a potential vector for ransomware, root/boot kits, etc.

[fsflover]

https://news.ycombinator.com/item?id=44246281

[JCattheATM]

What you've described in that comment is just kind of reinventing the wheel. You're solving the same problem a different way, in a way that has slightly more complexity than just using UEFI and secureboot.

[fsflover]

The main difference is that the user owns the root of trust and doesn't have to blindly trust a (buggy) proprietary software from a commercial company. Also, the community review.

[JCattheATM]

You could still have that with UEFI though.

[heavyset_go]

Ah, I thought you were replying to the full quote