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

41–50 of 100 posts

Re: Remotely unlocking an encrypted hard disk

#41

Post by gruez »

kro wrote: post #17
idorosen wrote: post #10

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

Just use fTPM?

Re: Remotely unlocking an encrypted hard disk

#42

Post by teddyh »

neocron wrote: post #37
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.

> Just pull one hdd out,

That only works with RAID 1. If the server uses RAID 5 or RAID 6, this won’t work.

> extract what you need

Well, yes. This is addressed in the FAQ.

> or change the image.

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

Well, as explained in the FAQ, an attacker will have to do so quickly, before the Mandos server decides that the Mandos client has been offline for too long, and disables that client. The default value is five minutes, but is configurable per client.

Re: Remotely unlocking an encrypted hard disk

#43

Post by danparsonson »

SchemaLoad wrote: post #39
bogwog wrote: post #34

Earlier quoted context omitted.

> 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.

What's the difference when booting off a USB drive? That's been my goto in the past when I forgot my login password; does the TPM only unlock boot devices?

Re: Remotely unlocking an encrypted hard disk

#44

Post by michaelt »

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…

The hope with the TPM is that the system boots to a standard login screen, and the thief doesn't know any user's password. Much like someone snatching a laptop that's in 'suspend' mode.

Of course, a thief could try to bypass the login screen by e.g. booting with a different kernel command line, or a different initramfs. If you want to avoid this vulnerability, TPM unlock can be configured as a very fragile house of cards - the tiniest change and it falls down. The jargon for this is "binding to PCRs"

Re: Remotely unlocking an encrypted hard disk

#45

Post by michaelt »

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

The solution is "don't apply untested upgrades to critical servers at 3am" :)

If you must do such upgrades, solutions include hot standby hardware, IPMI, an on-site tech with a screen and keyboard, or moving everything to the cloud.

Re: Remotely unlocking an encrypted hard disk

#46

Post by NekkoDroid »

neocron wrote: post #37
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.

This doesn't work with secure boot and UKIs, since the entire "pre-rootfs switch" is signed in a single binary. If your threat model is what you have that is the least you should have.

Re: Remotely unlocking an encrypted hard disk

#48

Post by NekkoDroid »

danparsonson wrote: post #43
SchemaLoad wrote: post #39

Earlier quoted context omitted.

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.

What's the difference when booting off a USB drive? That's been my goto in the past when I forgot my login password; does the TPM only unlock boot devices?

Generally you'll have your drive only unlock against certain PCRs and their values. It depends on which PCRs you select and then how exactly they are measured.

E.g. systemd measures basically everything that is part of the boot process (kernel, kernel cli, initrd, ...[1]) into different PCRs, so if any of those are different they result in differen PCR values and won't unlock the boot device (depending on which PCRs you decided to encrypt against). I forgot what excatly it measures, but I remember that some PCRs also get measured during the switch_root operation from initrd -> rootfs which can be used to make something only unlock in the initrd.

[1]: https://systemd.io/TPM2_PCR_MEASUREMENTS/

Re: Remotely unlocking an encrypted hard disk

#49

Post by Scramblejams »

michaelt wrote: post #45
Scramblejams wrote: post #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 rec…

The solution is "don't apply untested upgrades to critical servers at 3am" :) If you must do such upgrades, solutions include hot standby hardware, IPMI, an on-site tech with a screen and keyboard, or moving everything to the cloud.

Of course, but all those things (including upgrading during business hours) require budget. So, back to my original question...

Re: Remotely unlocking an encrypted hard disk

#50

Post by emmelaich »

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.

You don't need a robot arm, just mimic a usb keyboard.

https://pikvm.org/ and similar exist.

This is maybe not as good as the article solution, because it requires you to secure the pi too.

Post reply on HN