Hello,
On Wed, Jun 08, 2022 at 04:40:55PM -0400, Ian Kelling wrote:
I skimmed, but agree with your analysis.
I have a systemd service which, on reboot, adds a luks key stored on
the encrypted disk to the unencrypted initrd, and on boot, removes
it.
That's an interesting idea!
So, there is a time window just as your VM is shutting down where
the initrd contains a working LUKS key. If an attacker was able to
prevent your VM from booting they could grab that key out of your
initrd and boot a copy of your block device with their own initrd,
right?
Still it reduces the time span when you are vulnerable…
Perhaps with a remote secrets server it could be improved by storing
a signature of the initrd and kernel command line as well. Then only
an unmodified initrd being booted as expected (no init=/bin/bash)
could request the LUKS key. If something else requested it, the
secrets server would refuse and it would fall back to manual
passphrase input on console (or over ssh-in-initrd).
I suppose the method of updating the signature of the initrd in the
secrets server would itself require a passphrase to be typed as
otherwise the attacker could register their own initrd signature
there.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
"SCSI is usually fixed by remembering that it needs three terminations: One at
each end of the chain. And the goat." — Andrew McDonald