Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For servers that you need to unlock remotely, you will need to leave /boot unencrypted. But, for things like a laptop, grub has supported encrypted /boot for a while now (and it works well). But, the release versions still only support luks v1 (it was good enough for all those years, probably still fine for most folks mostly just worried about their laptop getting misplaced / stolen).

add to /etc/default/grub to enable encrypted /boot support: GRUB_ENABLE_CRYPTODISK=y

After encrypting /boot, you don't need anything besides ensuring that the less than 2MB of unencrypted grub bootloader that is installed before the first partition on BIOS machines or into /boot/uefi on uefi machines is verified to ensure that 100% of the boot process is trusted (and all your data too since 100% of the disk is encrypted except for < 2MB of boot loader).

A simple way (if your threat model isn't mosad/nsa) is just checking a hash of this tiny bit of data whenever something sketchy has occurred with your laptop e.g., it is left unattended with airport security. Just boot from a thumb drive, and check the hash (it will only change if you e.g., change your filesystem type or grub gets patches). If OK, then boot is still trusted (at least what is on disk; if threat model makes you a possible target for hardware manipulation this nor Pottering's proposal will help you).

Nice if this simple check of less than 2MB could be automated, but not in a complex and fragile way that removes freedom from the nominal owner of the computer as Pottering is suggesting.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: