Live data from Hacker News

Remotely unlocking an encrypted hard disk

jyn.dev

21–30 of 100 posts

Re: Remotely unlocking an encrypted hard disk

#21
post #12

If you want to be able to reboot remotely, and non-interactively (i.e. while you sleep), I (and one other person) created Mandos for this purpose: https://www.recompile.se/mandos >. It gets the password over the network. If this seems insecure to you, read the FAQ: https://www.recompile.se/mandos/man/intro.8mandos > Mandos works with initramfs images created by both initramfs-tools and Dracut, and is present in Debia…

Why is this needed at all? As the decrypted key is in memory before the reboot, can’t it just be written to a know location in memory and have kexec be instructed to read it early on?

Re: Remotely unlocking an encrypted hard disk

#22
post #21
post #12

If you want to be able to reboot remotely, and non-interactively (i.e. while you sleep), I (and one other person) created Mandos for this purpose: https://www.recompile.se/mandos >. It gets the password over the network. If this seems insecure to you, read the FAQ: https://www.recompile.se/mandos/man/intro.8mandos > Mandos works with initramfs images created by both initramfs-tools and Dracut, and is present in Debia…

Why is this needed at all? As the decrypted key is in memory before the reboot, can’t it just be written to a know location in memory and have kexec be instructed to read it early on?

You’re assuming a controlled reboot. Mandos was initially created to deal with intermittent power failures. It’s also good for kernel panics.

Re: Remotely unlocking an encrypted hard disk

#23
post #22
post #21

Earlier quoted context omitted.

Why is this needed at all? As the decrypted key is in memory before the reboot, can’t it just be written to a know location in memory and have kexec be instructed to read it early on?

You’re assuming a controlled reboot. Mandos was initially created to deal with intermittent power failures. It’s also good for kernel panics.

Oh for sure something is needed for a full start from zero. But the much more common case for a computer with backup power is regular restarts after applying patches that require a reboot. Would be much more pleasant for that to work out of the box with no manual interaction at all.

Re: Remotely unlocking an encrypted hard disk

#24

FYI your decryption key can be MITMed during this process by anyone with physical access to the system, which defeats the purpose of encrypting the disk in the first place. Just use dm-verity for remote servers.

If only everyone shared the same use case :) Maybe I have a server at home, with a locked cabinet and vibration sensors, that houses a server or two and they all use full disk encryption, but I still want to be able to reboot them without having to connect a physical keyboard to them. So no one has physical access, not even me, but I still want to be able to reboot them. Or countless of other scenarios where it could…

That's not a counter-argument. You are protecting the physical access, and your threat model doesn't include someone willing to bypass your locks and sensors. (or it does and you just didn't go into those details.)

The argument was that physical access gives up the FDE key.

Re: Remotely unlocking an encrypted hard disk

#27
post #12

If you want to be able to reboot remotely, and non-interactively (i.e. while you sleep), I (and one other person) created Mandos for this purpose: https://www.recompile.se/mandos >. It gets the password over the network. If this seems insecure to you, read the FAQ: https://www.recompile.se/mandos/man/intro.8mandos > Mandos works with initramfs images created by both initramfs-tools and Dracut, and is present in Debia…

I haven't looked deeply into either, but how does this compare to the combination of Clevis and Tang that e.g. Red Hat/Fedora seems to favor?

Re: Remotely unlocking an encrypted hard disk

#28

FYI your decryption key can be MITMed during this process by anyone with physical access to the system, which defeats the purpose of encrypting the disk in the first place. Just use dm-verity for remote servers.

Police show up and arrest you. Could be with reason, could be by accident. Maybe you did something wrong, maybe you didn’t. They also physically size your servers, and in doing so they unplug the system.

If you have disk encryption, your data now requires the police to force you to produce a password, which may or may not be within their powers, depending on the jurisdiction.

It’s strictly better to have full disk encryption and remote unlocking than no disk encryption at all, because it prevents such „system was switched off by accident“ attacks.

Re: Remotely unlocking an encrypted hard disk

#29
I have a very similar setup to the author, but instead of running Tailscale in my initramfs, I have a Raspberry Pi sitting next to the home server (which is on my Tailscale network) and I use it like a bastion host. Process is something like:

1. SSH into the Pi

2. Issue the Wake-on-LAN packet to boot the server

3. Tunnel that server's SSH port to my laptop

4. SSH into the initramfs SSH server (I use TinySSH), enter the decryption key

5. Wait for server to come up, then access via Tailscale

This is more complicated than the author's setup in that it requires another device (the Pi), but it's simpler in that you don't need to have the initramfs on your Tailnet.

Re: Remotely unlocking an encrypted hard disk

#30
I have something similar set up to unlock the drives on my home server. Just the SSH in initramfs though, tailscale is pretty cool.

I've done stuff with mkinitcpio / initramfs on arch before, can't remember exactly what for. I still run arch on my main laptop. I'm running nixos on my home server though, and adding something like this is so easy by comparison.

Post reply on HN