[systemd-devel] FDE: UEFI/Secureboot solves main part / missing link is /boot encryption

[Leon Fauster]

On 28.09.21 23:13, Lennart Poettering wrote:
> On Di, 28.09.21 19:44, Leon Fauster (leonfauster at googlemail.com) wrote:
> 
>> Hallo Lennart, corresponding to your last post about FDE:
>>
>> On an EFI system - would an encrypted "/boot" or /boot on
>> an encrypted "/" filesystem eliminate the mentioned main
>> attack vector? The whole chain would be authenticated.
> 
> Encryption is not authentication.
> 
> Not sure why you would encrypt your boot loader though? The boot
> loader code is hardly a secret, is it? It's the same for everyone and
> open source.
> 
> And with which key? a key the user has to type in? how does that help?
> it means the user is queried three times for a pw? once by grub, once
> by cryptsetup and once when logging in? That's not an improvement!



I think was partly misunderstood. Le me rephrase it. My motivation was
just a thought about one step in the implementation (in the context of
UEFI), that has a huge benefit. Speak, protecting the initrd. Thats the
start point.

Shim verifies the boot loader signature which is GRUB 2, right?
The boot loader is on the EFI partition without encryption, right?
Grub verifies the kernel signature, right?

So, having the initrd on one encrypted partition would improve the
current situation. The interactivity of entering the password is
a further detail that needs attention but is left aside here.

Yes, enc != auth - but while speaking about authentication. Dracut
could enroll the signature of the initrd into the allow db (EFI).
So, grub2 could check both, the kernel and the initrd and making the
above encryption completely obsolete, thought.



> My blog story is an attempt to do things cleanly: i.e. authenticate
> what needs authentication, and do so in a way that doesn't require
> interactivity. The ultimate goal is that servers and embedded devices
> can boot up entirely unattanded in safe way, and that desktop machines
> only query the user once, and that the authentication the user does
> unlocks the user's actual data.


Sure, that's the goal!


--
Leon