On Tue, Dec 26, 2017 at 02:24:24PM +0100, Pascal Hambourg wrote: > Le 26/12/2017 à 13:58, Reco a écrit : > > On Tue, Dec 26, 2017 at 11:59:18AM +0100, to...@tuxteam.de wrote: > > > > > > > > > > Is there any inherent advantage to having /boot encrypted? > > > > > The only things which might help against an evil maid attack [1] are: > > > secure boot (tying your bootable to secure firmware) [3], > > > > Restricted Boot (let's call the thing the way it should be called from > > the start) could've solve this problem *if* it would be possible to > > force it to verify the bootloader (or the kernel) signed with *user* > > key. > > I read that some UEFI implementations allow the user to manage secure boot > keys. Carefully choose your hardware.
I'd use term 'elusive' to describe that kind of UEFI implementation. Everything that can be bought here (I'm talking about x86 consumer-grade hardware, of course) respects MSFT signing key only. If you're lucky, your hardware has CSM (aka BIOS emulation mode). > Oh, by the way I forgot twice to mention another situation when an encrypted > /boot would provide an advantage : when the machine has a platform firwmare > which supports LUKS encryption, such as CoreBoot, then the on-disk boot > components could be entirely encrypted. ... and about the only trouble you have then is to locate that ThinkPad x220 (the only relatively modern laptop model that supports CoreBoot without a hassle I know of). Or a Chromebook if they still but SeaBIOS inside those. If you're preferring conventional desktop PC - you're out of luck with CoreBoot. Reco
