Live data from Hacker News

Remotely unlocking an encrypted hard disk

jyn.dev

11–20 of 100 posts

Re: Remotely unlocking an encrypted hard disk

#11
I'd love to see this in the bootloader, along with a selection of binaries useful for recovery. Might sound silly but over the years I have had many a remote system get to the bootloader and then no further after an upgrade. Nowadays we've usually got a nicely sized EFI partition, why not stuff it all in there? Gimme a full Linux userspace from the bootloader, it would feel luxurious when I'm up at 3 am trying to recover a broken system halfway across the country.

Or is there already a solution to this that I've been missing? (Yeah, KVM/IPMI/etc, I know, but not all hosters make it easy to get to that.)

Re: Remotely unlocking an encrypted hard disk

#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 Debian since 2011, so no need to use a third-party package.

Re: Remotely unlocking an encrypted hard disk

#13
> Because initramfs is just a (mostly) normal Linux system, that means it has its own init PID 1. On Arch, that PID is in fact just systemd.

Debian has (or had; at least my Devuan still has) a simple shell script as first init. Was an interesting read and helped me understand were to add my remote rootfs decryption.

https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/...

Re: Remotely unlocking an encrypted hard disk

#14
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…

Good FAQ, clearly stating the weak point of physical access. For a server that threatmodel can work, for a fleet of edge/iot devices in unsecured locations without permanent uptime there is no real solution to be expected without custom silicon logic (like in smartcards) on the soc.

Re: Remotely unlocking an encrypted hard disk

#15
Glad to see another example of this! Remote unlocking of your personal server's encrypted hard drive is PITA.

Other options that I've investigated that involve having a second server:

* A second server with Tang, and Clevis in the initramfs OS

* Keylime

Putting tailscale in the initramfs, and then updating the certs on a frequent enough schedule, seems risky to me. I've already played around with limine enough that I know I don't want to install much in the initramfs...

Re: Remotely unlocking an encrypted hard disk

#17

There is an old but still reasonable solution with mkinitcpio hooks encrypt/sd-encrypt + ssh, which is very easy to set up with EFI or grub2 onward. Tailscale is probably overkill for this use case, given that you're already exposing pre-/early- boot to the network by setting up interfaces that early. This became much more hermetic with secureboot and TPMs, too.

TPM definitely rises the effort by a lot to break it. But by default the communication with it is not encrypted, so especially for modules not built into the cpu wire/bus-tapping is a thing.

https://news.ycombinator.com/item?id=46676919

Re: Remotely unlocking an encrypted hard disk

#18
I currently have dropbear-ssh presenting the LUKS password prompt on my home server, but that has the very annoying quality that there's no way to do it from the console if you set that up too.

It's not a huge problem but it certainly means some recovery scenarios would be painful.

Re: Remotely unlocking an encrypted hard disk

#19

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 be useful to be able to remotely unlock FDE.

Re: Remotely unlocking an encrypted hard disk

#20
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…

How does this compare to: https://docs.redhat.com/en/documentation/red_hat_enterprise_...
Post reply on HN