Unlocking an encrypted rootfs over ssh-server in initramfs
1–9 of 9 posts
Re: Unlocking an encrypted rootfs over ssh-server in initramfs
#2Well, yes - if you are using an encrypted rootfs on a server, the disk is permanently in an unlocked state - so it doesn't completely matter if encrypted or not. But don't forget, in some cases you don't want to have unencrypted data stored on a hard disk or a flash medium either. I guess another solution would be to have only parts of the system/data encrypted, but I think this way is more convenient.
Here is another article, describing a similar setup [0].
And here is a similar question on stackoverflow with plenty of answers [1] and some other tool mentioned.
[0]: http://blog.neutrino.es/2011/unlocking-a-luks-encrypted-root... [1]: https://unix.stackexchange.com/questions/5017/ssh-to-decrypt...
Re: Unlocking an encrypted rootfs over ssh-server in initramfs
#3Well, yes - if you are using an encrypted rootfs on a server, the disk is permanently in an unlocked state - so it doesn't completely matter if encrypted or not. But don't forget, in some cases you don't want to have unencrypted data stored on a hard disk or a flash medium either. I guess another solution would be to have only parts of the system/data encrypted, but I think this way is more convenient. Here is anothe…
>
Well, yes - if you are using an encrypted rootfs on a server, the disk is permanently in an unlocked state - so it doesn't completely matter if encrypted or not.
It is very irresponsible to make statements like that. It is very common to have an attack, where the attacker gains access via social engineering to a server, and manages to restart the server and gain access to a rescue system.
And even then, nowadays renting servers is very common - how do you know you can trust everyone in the hosting company? FDE should be the default thing to do, especially for servers. I don't really understand why they aren't a standard practice already.
Re: Unlocking an encrypted rootfs over ssh-server in initramfs
#4I've been toying with this idea for personal experimentation. My idea for an unattended unlock is to involve some sub-Rasberry Pi sized machine to be somewhere on the LAN that stores the key (or part thereof). That small machine would be on local WiFi and physically hidden, like under a sink.
Re: Unlocking an encrypted rootfs over ssh-server in initramfs
#5Well, yes - if you are using an encrypted rootfs on a server, the disk is permanently in an unlocked state - so it doesn't completely matter if encrypted or not. But don't forget, in some cases you don't want to have unencrypted data stored on a hard disk or a flash medium either. I guess another solution would be to have only parts of the system/data encrypted, but I think this way is more convenient. Here is anothe…
> Well, yes - if you are using an encrypted rootfs on a server, the disk is permanently in an unlocked state - so it doesn't completely matter if encrypted or not. It is very irresponsible to make statements like that. It is very common to have an attack, where the attacker gains access via social engineering to a server, and manages to restart the server and gain access to a rescue system. And even then, nowadays re…
> It is very irresponsible to make statements like that.
I don't think so. It is irresponsible to suggest that you can secure a server you don't physically control. Full disk encryption doesn't protect your disk if someone can take a memory dump of the machine. Using sshd in an initramfs to receive the passphrase for an encrypted rootfs doesn't help if someone can modify the initramfs and wait for a the passphrase.
Encrypting your volumes does provide some security, but having to SSH into an initramfs to unlock the root partition has its own problems.
Re: Unlocking an encrypted rootfs over ssh-server in initramfs
#6I think the author dismisses evil maid style attacks too lightly. It is true that its kinda difficult to protect against such attacks, but Secure Boot should raise the bar slightly.
Re: Unlocking an encrypted rootfs over ssh-server in initramfs
#7I think the author dismisses evil maid style attacks too lightly. It is true that its kinda difficult to protect against such attacks, but Secure Boot should raise the bar slightly.
Slightly? Considerably.
Re: Unlocking an encrypted rootfs over ssh-server in initramfs
#8Well, yes - if you are using an encrypted rootfs on a server, the disk is permanently in an unlocked state - so it doesn't completely matter if encrypted or not. But don't forget, in some cases you don't want to have unencrypted data stored on a hard disk or a flash medium either. I guess another solution would be to have only parts of the system/data encrypted, but I think this way is more convenient. Here is anothe…
You're right, this offers no protection while the server is running.
But: Hard disk die. Usually just a few sectors become unreadable and the remaining part is still accessible. Sometimes you can even read all the data, but S.M.A.R.T. is indicating an impending failure. Of course you want to swap out such a drive as soon as possible. Hopefully the old drive will be disposed of responsibly and securely. But do you want to depend on that? I don't. If I have a failing drive and I can't wipe most of it, I keep it instead of sending it in for warranty replacement.
I have come by several old servers and hard disks that still contained non-empty partitions from the previous owner / user. If that happens, I just wipe the drive before reformatting it. But I always wonder: would they do the same if they got an unwiped drive of mine?
Re: Unlocking an encrypted rootfs over ssh-server in initramfs
#9Earlier quoted context omitted.
> Well, yes - if you are using an encrypted rootfs on a server, the disk is permanently in an unlocked state - so it doesn't completely matter if encrypted or not. It is very irresponsible to make statements like that. It is very common to have an attack, where the attacker gains access via social engineering to a server, and manages to restart the server and gain access to a rescue system. And even then, nowadays re…
> It is very irresponsible to make statements like that. I don't think so. It is irresponsible to suggest that you can secure a server you don't physically control. Full disk encryption doesn't protect your disk if someone can take a memory dump of the machine. Using sshd in an initramfs to receive the passphrase for an encrypted rootfs doesn't help if someone can modify the initramfs and wait for a the passphrase. E…
Nothing is ever 100% safe and everything has its own problems. Initramfs-based full disk encryption is easy and effortless to do, and the value is most definitely greater than the effort required. I know multiple of cases where a simple FDE would have helped to greatly reduce the harm done.
You can host your own servers, but even that is not 100% safe. Someone can break to your hosting space and inspect the servers. And that of course requires quite a deal of effort.