On Fri, 2023-03-10 at 14:28 +0000, Jeremy Stanley wrote: > 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. No, this is not about blind modification. There are relevant attacks in this area. https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ > 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. The only thing an attacker can modify in software is the GRUB binary in /boot/efi. The GRUB binary can be more easily verified by Secure Boot and it is where I enter my LUKS passphrase. > 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. Hardware modifications are not a fair comparison. Hardware modifications can always replace anything with anything that looks alike. > Sure, if you're concerned that sensitive information is being put in > /boot sufficient to warrant the additional work of protecting it What additional work? The installer did it automatically without me even noticing for years. Having a separate /boot partition is actually more work. You need to decide on the required size, choose an appropriate filesystem etc. > 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. Any installed program that is not in the essential setup should be considered sensitive information. > 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 > either. There is nothing inconvenient about it. Regards
Attachment:
signature.asc
Description: This is a digitally signed message part