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

81–90 of 100 posts

Re: Remotely unlocking an encrypted hard disk

#81

Post by belorn »

rlpb wrote: post #73
belorn wrote: post #35

Earlier quoted context omitted.

(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 understandin…

clevis and tang do currently work seamlessly on Debian and Ubuntu using initramfs-tools. So while the initramfs-tools/dracut discussion is valid, it seems mostly orthogonal to this topic.

I was unaware that they no longer depended on Dracut and now support initramfs-tools, which also seem to be the earliest clevis version that got packaged in Debian. That makes the initramfs-tools/dracut distinction a historical aspect of the project.

Re: Remotely unlocking an encrypted hard disk

#82

Post by PunchyHamster »

koolba wrote: post #23
teddyh wrote: post #22

Earlier quoted context omitted.

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.

There is plenty of cases of cold boot in datacenter.

Also most distros don't support using kexec for kernel upgrades anyway.

Re: Remotely unlocking an encrypted hard disk

#83

Post by PunchyHamster »

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.

TPM is security theathre for disk encryption. If you steal the device, you have stolen the key

Re: Remotely unlocking an encrypted hard disk

#84

Post by PunchyHamster »

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.

Plenty of TPM bugs happened in the past and plenty of zero days in any code involved will happen.

Having key off-machine mitigates a lot of that.

> Unless the junkie who stole your server has an unpatched debian login bug,

the key for disk decryption is in memory at that point. There are methods to take it out of it

Re: Remotely unlocking an encrypted hard disk

#85

Post by benttoothpaste »

hnarn wrote: post #80
mmh0000 wrote: post #2

This has been a "need" for a long time for home users with FDE. The go-to software solution for Linux has been: https://github.com/gsauthof/dracut-sshd

Sure, if you're using dracut, which is not true for "Linux" in general.

Most Linux distros are not Arch either. It would be nice to have more support for this use case in general - like something one can configure easily during the initial OS setup.

I use OpenSuse so I had to use the guide for Fedora, but there were some differences as far as I remember.

Re: Remotely unlocking an encrypted hard disk

#86

Post by teddyh »

snthpy wrote: post #58
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?

The whole architecure of Mandos is very plugin-based, it will therefore likely not be hard to add. But I am not sure what you are asking for? The Mandos server will, by default, unlock all clients, without asking. There is support for not unlocking immediately and instead wait for external approval for clients explicitly so configured, but what is the scenario? Is the client the one supplying the passkeys/webauthn? Or are you providing that manually on a web page somewhere? The latter is possible; the web page server process would then, when a passkey/webauthn has been verified, send a D-Bus “Approve” message to the Mandos server process, which would then send the client its password.

Re: Remotely unlocking an encrypted hard disk

#87

Post by abound »

hnarn wrote: post #79
abound wrote: post #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 t…

It's not only more complicated, it also does not sound to me like it would scale. What do you do when you have N servers? Do you buy N raspis, or do you keep using one bastion host? How do you automate it when you sooner or later must (re-)deploy? If you set this up once ("this" meaning adding networking, SSH and tailscale inside initramfs), you can just do the same thing for the next server you set up, and you don't…

The approach I've outlined scales fine to N servers, it just doesn't work if they're on different networks.

But scaling also isn't really a parameter I (or the author) are optimizing for: we have a single beefy server we do all our work on, and a thin laptop client we want to access the server from, remotely and booting an encrypted root partition.

I don't necessarily understand the deployment question. If it's about the Raspberry Pi, I just do my updates when I don't need to use it to boot the server.

Re: Remotely unlocking an encrypted hard disk

#88

Post by ycombinatrix »

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

[flagged]

I meant "just use dm-verity" as in "don't do full disk encryption"...

Re: Remotely unlocking an encrypted hard disk

#89

Post by nozzlegear »

mistersquid wrote: post #78
bertman wrote: post #69

Earlier quoted context omitted.

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

The good news: macOS can unlock FDE over SSH. The bad news: `The capability to unlock the data volume over SSH appeared in macOS 26 Tahoe.`

The "bad news" about Tahoe is largely overblown unless you hang out in the control center (or whatever they call that notification area) all day, which is the only place you'll actually notice Liquid Glass on a Mac.

Re: Remotely unlocking an encrypted hard disk

#90

Post by neocron »

teddyh wrote: post #42
neocron wrote: post #37

Earlier quoted context omitted.

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…

Why wouldn't this work with Raid5? One of my raid5 hdds cought fire and the server was still running. Talking about mdadm in this case.

5 minutes is plenty to boot initrd from a vm... what's that gonna take? 10 seconds?

Post reply on HN