Remotely unlocking an encrypted hard disk • Hacker News Board

Re: Remotely unlocking an encrypted hard disk

#51

Post by SchemaLoad » Fri, Mar 06, 2026, 1:34 AM UTC

michaelt wrote: post #44

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…

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

The fallback is you have to manually unlock the drive, the same as you did without a TPM. But the benefit is while things remain unchanged, the system can reboot itself.

Re: Remotely unlocking an encrypted hard disk

#52

Post by SchemaLoad » Fri, Mar 06, 2026, 1:36 AM UTC

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?

The TPM holds the decryption keys and will unlock as long as all checks pass. Booting off the previously registered drive/kernel being one of them.

If this fails you can always manually input the decryption key and reregister with the TPM. The whole point of this setup is you can't just use a bootable USB to reset the devices password.

Re: Remotely unlocking an encrypted hard disk

#53

Post by nembal » Fri, Mar 06, 2026, 2:06 AM UTC

is it just me, or feels scary that it is happening

Re: Remotely unlocking an encrypted hard disk

#54

Post by vel0city » Fri, Mar 06, 2026, 2:48 AM UTC

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?

If properly configured and the TPM implementation is good, no it shouldn't unlock the drive. Changing boot devices, and depending on how configured even changing boot options, can prevent the TPM from releasing the key and require a recovery key.

Re: Remotely unlocking an encrypted hard disk

#55

Post by sillystuff » Fri, Mar 06, 2026, 2:49 AM UTC

koolba wrote: post #21

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…

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?

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

I set up what you are suggesting (sort of anyway[1]) on a personal VPS to reboot after updates, that require one. I just generate an initrd in tmpfs that contains a keyfile[2] and kexec with that ephemeral initrd; The newest kernel can be found by looking at what the /boot/vmlinuz symlink points to. Been running this for years. It is 100% reliable, and simple. And, for the purposes of this box, secure enough.

For remote unlocks from initial power on, Debian has had that since forever using keyscripts and dropbear in the initrd.

[1] You could pull the key from memory, and use that to unlock the disk from within the generated initrd, but it would be more work than just setting up a keyfile in advance. It was my first thought as well.

[2] Easiest way was to use a mount namespace to use a diff crypttab file that points to the keyfile, since cannot specify crypttab location when creating the initrd. E.g.,

  unshare --mount sh -c "mount --bind $CRYPTTAB_KEXEC $CRYPTTAB; mkinitramfs -o $kexec_initramfs  $kernel"

(mkinitramfs is usually wrapped by update-initramfs, but calling it directly allows specifying a location)

Re: Remotely unlocking an encrypted hard disk

#56

Post by fc417fc802 » Fri, Mar 06, 2026, 3:46 AM UTC

SchemaLoad wrote: post #51

michaelt wrote: post #44

Earlier quoted context omitted.

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

The fallback is you have to manually unlock the drive, the same as you did without a TPM. But the benefit is while things remain unchanged, the system can reboot itself.

You can reduce the frequency with which things change by adding an additional layer before the "real" kernel is loaded. A minimal image that does nothing but unlock any relevant secrets, verify the signature of the next image, and then hands off control.

Re: Remotely unlocking an encrypted hard disk

#57

Post by fc417fc802 » Fri, Mar 06, 2026, 4:38 AM UTC

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

Seems like you should be able to launch the LUKS password prompt multiple times on different interfaces.

Re: Remotely unlocking an encrypted hard disk

#58

Post by snthpy » Fri, Mar 06, 2026, 5:17 AM UTC

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…

Sounds great, I'm going to give this a try. Is there a plug-in for passkeys/webauthn for the mandos-server unlock?

Re: Remotely unlocking an encrypted hard disk

#59

Post by gib444 » Fri, Mar 06, 2026, 5:30 AM UTC

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…

Except they are more sophisticated than this in the real world. They have kits to clone drives and keep power running without interrupting it

Re: Remotely unlocking an encrypted hard disk

#60

Post by kro » Fri, Mar 06, 2026, 5:52 AM UTC

michaelt wrote: post #44

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…

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

TPM is good when combined with secureboot and these hashes being part of the attestation, that eliminates initramfs swapping. Still with Physical access being a factor bustapping can happen, ftpm - if available - is much harder to crack then than a discrete module.

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