On 28.09.21 23:13, Lennart Poettering wrote:
On Di, 28.09.21 19:44, Leon Fauster (leonfaus...@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
