Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remotely unlocking an encrypted hard disk

jyn.dev

Post reply on HN
Print view View original

31–40 of 100 posts

Re: Remotely unlocking an encrypted hard disk

#31

Post by Foxboron »

Calzifer wrote: post #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/...

`mkinitcpio` supports both.

The `base` hook installs the shell PID 1, the `systemd` hook installs systemd as PID1. The default hook setup was changed with the latest'ish release to default too the `systemd` hook setup.

Shell `init`; https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio...

Re: Remotely unlocking an encrypted hard disk

#32

Post by SchemaLoad »

epistasis wrote: post #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…

TPM is probably the best solution here. The key can be automatically fetched on reboot unless the boot order is changed or the drive is put in another computer.

Realistically for a home server what you are worried about is someone breaking in and selling your drives on Facebook marketplace rather than the FBI raiding your nextcloud server. So TPM automated unlock is perfectly sufficient.

Re: Remotely unlocking an encrypted hard disk

#34

Post by bogwog »

SchemaLoad wrote: post #32
epistasis wrote: post #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…

TPM is probably the best solution here. The key can be automatically fetched on reboot unless the boot order is changed or the drive is put in another computer. Realistically for a home server what you are worried about is someone breaking in and selling your drives on Facebook marketplace rather than the FBI raiding your nextcloud server. So TPM automated unlock is perfectly sufficient.

> Realistically for a home server what you are worried about is someone breaking in and selling your drives on Facebook marketplace

If someone steals the entire machine, the drives will unlock themselves automatically. I don't think it's worth the risk to assume a hypothetical thief is too lazy to check if there's any valuable data on the disks. At the very least, they'll probably check for crypto wallets.

With something like Clevis and Tang, you can set it up so it only auto unlocks while connected to your home network, or do something more complex as needed

Re: Remotely unlocking an encrypted hard disk

#35

Post by belorn »

akdev1l wrote: post #20
teddyh wrote: 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_...

(I am the other Mandos developer)

I think FOSDEM had a talk a few years ago about that solution and their tang server. It is very similar in concept. They use McCallum-Relyea exchange, and we use PGP encryption, but the basics are the same in that you need information stored at the server and information stored in the unencrypted initramfs in order to be combined and turned into the encryption key. If my understanding of the McCallum-Relyea exchange is correct, they also combine the key creation and perfect forward security of the transaction into a single protocol, while we use TLS and client keys for the perfect forward security aspect and PGP for data at rest.

With tang you need to verify the hash of the tang server in order to prevent a MITM threat from extracting the server side part during the key creation process, while with Mandos you configure it manually with configuration files.

Tang uses REST and JSON. Mandos sends a single protocol number and then sends the data. Both operate primarily through local LAN, through Mandos client also support as an option to use global reachable ip addresses.

Outside of those design differences, there are some packaging aspects. Tang was designed for Redhat/Dracut, while Mandos was designed for Debian and initramfs-tools (Today Mandos also support Dracut, but it is not packaged for Redhat). Redhat packaging has been requested multiple times for Mandos, but neither of us two developer are Redhat users.

To add some historical context, I recall a Debconf BoF by the developers of initramfs-tools about if they were going to continue developing initramfs-tools or giving up and port everything to Dracut, and the silence was fairly deafening. People did not want to give up on initramfs-tools, but everyone recognized the massive duplication that those two project are. Similarly, the reason why Redhat had chosen initially to develop Dracut rather than just port initramfs-tools is also fairly big mystery, and is generally considered a Not Invented Here syndrome. Today there are however some distinct difference in design between the two systems.

Re: Remotely unlocking an encrypted hard disk

#36

Post by teddyh »

akdev1l wrote: post #20
teddyh wrote: 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_...

Despite the “tang/clevis” system being too clever by half (and even more complex), it is essentially very similar. Mandos, though, is much simpler; you can actually understand it, since it uses standard components and protocols like DNS-SD¹, OpenPGP and TLS. (Mandos is documented in man pages, in contrast to page you linked, which is both huge, and – for me at least – keeps reloading itself and replacing the entire page with a 500 server error.)

Mandos is also for Debian (and all Debian-based systems), and not Red Hat (although there is nothing preventing a port, since Mandos now also supports initramfs images created by Dracut).

Finally, Mandos was initially created in in 2007, many years before tang/clevis, and literally by a person in a dorm room, not by whatever academics/scientists who seem to have dreamed up the cryptography/protocol tangle that is tang/clevis. Mandos has changed some since then, from initially using broadcast UDP and X.509 certificates, to using DNS-SD and raw public keys², but has otherwise remained very similar to its initial design.

1. https://www.dns-sd.org/>

2. https://www.rfc-editor.org/rfc/rfc7250>

Re: Remotely unlocking an encrypted hard disk

#37

Post by neocron »

teddyh wrote: 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…

Which server today doesnt have Raid? Just pull one hdd out, extract what you need or change the image.

Then you turn off the server, and just start a vm with the captured init and capture the key.

Now you can decrypt the server offline with all the time in the world.

Re: Remotely unlocking an encrypted hard disk

#38

Post by gruez »

FabCH wrote: post #28
ycombinatrix wrote: post #4

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 en…

>and in doing so they unplug the system.

They have kits that allow them to unplug the server from the wall without interrupting power supply, specifically so they don't lose the decryption keys.

Re: Remotely unlocking an encrypted hard disk

#39

Post by SchemaLoad »

bogwog wrote: post #34
SchemaLoad wrote: post #32

Earlier quoted context omitted.

TPM is probably the best solution here. The key can be automatically fetched on reboot unless the boot order is changed or the drive is put in another computer. Realistically for a home server what you are worried about is someone breaking in and selling your drives on Facebook marketplace rather than the FBI raiding your nextcloud server. So TPM automated unlock is perfectly sufficient.

> Realistically for a home server what you are worried about is someone breaking in and selling your drives on Facebook marketplace If someone steals the entire machine, the drives will unlock themselves automatically. I don't think it's worth the risk to assume a hypothetical thief is too lazy to check if there's any valuable data on the disks. At the very least, they'll probably check for crypto wallets. With somet…

They will unlock in to a password protected system. Unless the junkie who stole your server has an unpatched debian login bug, this won't be much use to them. If they remove the drive or attempt to boot off a USB, the drive is unreadable.

Re: Remotely unlocking an encrypted hard disk

#40

Post by teddyh »

varispeed wrote: post #33

And me was thinking about having a monitor, camera pointed at monitor and robot arm that I could type password in controlling it remotely.

An equivalent, but simpler, solution would be to use a network-based KVM, like PiKVM. You connect a USB connector to the PiKVM so it can simulate a keyboard (and mouse), an HDMI connector so it can show you what’s on the server screen, and you also connect a special cable to the server motherboard power and reset pins, so the PiKVM can “press” those buttons remotely as well.
Post reply on HN