Andrew McGlashan wrote:
> The biggest weakness with the Dropbear setup is that the initramfs is
> stored on an unencrypted partition (no matter which file system is
> used). That means that someone with physical access can rebuild the
> initramfs and include their own key as well as other stuff to
> compromise the security of the server.
>
Exactly what I was saying
> Aside from the fact that the IME is suspect, it would be great if grub
> can be, somehow, given a method that allows for full disk encryption
> which will include everything in /boot -- especially initramfs.
>
but it would also mean that it should be accessible over the internet,
because I do not see any other way to reach the server and decrypt.
> Even so, then grub might have another attack vector of itself. But it
> would at least allow for encrypted /boot ...
Well but again we shift from the boot partition to grub - hense if
probability that one has physical access to the server can be ignored,
dropbear is still practical solution.
regards
That's why the reverse scenario is better, you include a client SSH key in the initramfs which you use to ssh to a remote server and download the encryption key.
The way I see it an important part of all these remote storage methods, apart from automation, is prevention and remediation. First it can limit the resource access from only specific IP(s) so If someone heads off with your encrypted disk your data will stay protected since the key can not be retrieved from anywhere else but your IP. And second, although it seems that you have just replaced one kind of plain text credentials (the encryption key) with another one (ssh key or AWS IAM user credentials), you can actually still protect yourself by revoking those credentials on the remote server/storage side upon a security incident.