5 ms·

> you are now secure against petty criminals stealing your data Ordinary disk encryption would protect me too here, wouldn't it?

npteljes 1y ago
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-disk-encryption-legacy-boot-mode-mbr-vs-efi-boot-mode 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 1y ago
  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 1y ago
    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 1y ago
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 1y ago
  https://news.ycombinator.com/item?id=44246281 https://news.ycombinator.com/item?id=44246281
  - JCattheATM 1y ago
    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 1y ago
      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 1y ago
        You could still have that with UEFI though.
        fsflover 1y ago
        But not with Secure Boot AFAIK.
        JCattheATM 1y ago
        Well, yeah, you could, that was the point of my comment. Coreboot supports secure boot, so why isn't that sufficient?
        fsflover 1y ago
        Secure Boot is closed and not auditable.

npteljes 1y ago

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-disk-encryption-legacy-boot-mode-mbr-vs-efi-boot-mode 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 1y ago
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 1y ago
  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 1y ago

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 1y ago
https://news.ycombinator.com/item?id=44246281 https://news.ycombinator.com/item?id=44246281
- JCattheATM 1y ago
  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 1y ago
    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 1y ago
      You could still have that with UEFI though.
      - fsflover 1y ago
        But not with Secure Boot AFAIK.
        JCattheATM 1y ago
        Well, yeah, you could, that was the point of my comment. Coreboot supports secure boot, so why isn't that sufficient?
        fsflover 1y ago
        Secure Boot is closed and not auditable.