[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unlock LUKS with login/password

On 2023-03-10 13:48:21 +0000 (+0000), Stephan Verbücheln wrote:
> Encryption per se does not protect against modification, I am aware of
> that. That is even more true for disk encryption where the encrypted
> data block has to fit into the physical disk block, so there is no room
> for a MAC or signature. However, in combination with a filesystem like
> btrfs which checksums everything, it is providing some protection, even
> though it was not designed for that purpose.

Okay, so you're wanting to rely on encrypted /boot as an incomplete
alternative to checking file signatures, because the current
attestation solutions are also imperfect. Keep in mind that
checksumming isn't providing protection from coherent modification
of the decrypted filesystem and checksums, it's just protecting
against someone blindly modifying the encrypted blocks. If they have
physical access to your system sufficient to modify firmware or add
hardware without you noticing, then encrypted /boot is pretty
pointless against such an actor.

> Apart from the fact that UEFI Secure Boot is an overly complex monster
> which is basically broken[1] by design, my understanding of it is also
> that it does not protect configs, initramfs etc. in /boot. It only
> protects the kernel image and loaded modules.
> [1]
> https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/

Well, it's not as if encrypted /boot is protecting you from the
attacks described in that article either. Someone with that level of
access to your system can quite easily record/copy your decryption
keys, or simply wait until you've unlocked your sensitive data.

> In addition, files in /boot like the initrd are generated individually
> and may contain files not limited to what someone puts into /boot
> intentionally. In contrast to /boot/efi, /boot does not only contain
> static files delivered by the distribution.

Sure, if you're concerned that sensitive information is being put in
/boot sufficient to warrant the additional work of protecting it
from disclosure when someone steals the device or gets their hands
on the drive after disposal, then by all means go ahead. It's just
not usually worth that amount of additional complexity.

It comes down to basic cost/benefit analysis, and deciding what
threats you reasonably want to invest in defending against. I'm
certainly not saying there's *never* a reason to encrypt /boot, but
people who feel they need to do so aren't involved in improving
tools and automation sufficiently to make it convenient to set up
Jeremy Stanley

Attachment: signature.asc
Description: PGP signature

Reply to: