0

I am interested in setting up my computer with full disk encryption, and as I understand, the /boot partition is the only tricky part of the process. Namely, I can encrypt the /boot partition and instruct GRUB to access it appropriately, but since my computer uses UEFI, I will need an additional, unencrypted /boot/efi partition. That partition, as I understand, is still prone to Evil Maid attack?

Is there any way I can secure that partition as well, namely its integrity? In other words, is there any way I can at least get a warning once I start my computer that my /boot partition has been compromised (checking against checksums, signatures, etc.)?

Today I learned about secure boot, but some Linux distributions I am interested in do not have that support (namely, Debian). So is there anything I can do at least post-login to figure out my /boot (/boot/efi) partition integrity has been compromised?

Thanks!

0

Debian actually does have secure boot support (you can use utilities to sign the kernels yourself - the only tricky part is installing the self-signing keys, which depends on the UEFI implementation).

0

I run Debian 9 with secure boot enabled, with self-signed keys. It can certainly protect against trivial Evil Maid-type attacks like plugging in a bootable USB drive to grab data from your system or to install malware to non-encrypted partitions. But that's hardly the limit of what an Evil Maid could do: if you're serious about this, you should also think about the physical security of the system chassis.

For "retroactive" integrity checks, you would need a TPM chip and a bootloader that will utilize its PCR registers. Those registers cannot just be set to any value: when new data is fed to those registers, the TPM chip itself will calculate a hash of the old value of the register + the data input, and assign that as the new value of the register. The system firmware will populate the first few PCR registers with the hashes of the firmware itself, the current firmware settings, and the first piece of boot code that was actually used. After that point, the control will be transferred to that boot code.

If you used a bootloader that similarly records the hashes of the kernel and initramfs files actually loaded into the PCR registers, you could then verify the PCR values against a set of "known good" values stored in the encrypted part of the disk, and display a warning if the current values won't match the known-good state. The kernel also has the CONFIG_IMA option which, when activated, makes the kernel use one PCR register of the TPM to maintain a hash of hashes of everything it has loaded. (A hash of hashes, because a TPM is not especially fast: sending a full copy of all loaded data to TPM for hashing would massively slow down the boot process.)

Of course, you would then have to update the known-good values each time you update any part of the system that gets hashed into the PCRs, or you'll get a false alarm. When installing a system update (e.g. a kernel with a security patch) it can be hard to predict in advance what the new "good" PCR values will be, so yo may have to install the update, accept that the next boot will trigger the alarm, and then record the new "good" state.

A few years ago, when I experimented with the TPM PCRs, it was with a system with a legacy BIOS firmware. With TrustedGRUB (basically a TPM-enabled version of GRUB Legacy) I was able to implement the kind of checking I outlined in the previous paragraph. I'm not sure if there is a Linux UEFI bootloader with TPM support available yet, so you might not get complete PCR coverage of the early system, unless you boot using only the kernel's built-in UEFI stub loader (so the firmware will end up recording the hash of the actual kernel instead of just the bootloader).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.