Unattended reboots with encrypted disks
34 points by jmmv
34 points by jmmv
Split keys: The ZKeys server only stores half of the passphrase used to unlock a volume. The other half remains on the client machine.
Would Shamir's Secret Sharing be a better fit here, so compromising either half doesn't get you any information?
I don't think you'd need SSS for the case of two parties where both have to release their key-shares. A plain old one-time pad (XOR with random data) would do.
You don't for the k-of-n 2-of-2 special case, sure, but polynomial interpolation gets you everything beyond that trivial base case.
The biggest benefit of using SSS instead of simple XOR is that it allows you to have a bit of redundancy so that you can lose one key without losing everything.
Maybe (I didn't know about it). But for my threat model, this wouldn't gain me anything, I think...
Let's say your passphrase is eight random words (~12 bits of entropy each), and you store four of those words on the remote server. Your passphrase has 96 bits of entropy total, which should be sufficient for an encryption key. But if you already know half of the passphrase, the unknown half only has 48 bits of entropy, and a motivated attacker could brute-force that. (See also: EFF's custom DES cracker brute-forces 56-bit keys.)
One threat model is someone getting their hands on your powered-off home server. If I understand ZKeys correctly, half of your passphrase is stored unencrypted on your home server, and the other half is known by the ZKeys server (but is inaccessible to the attacker). So the attacker reads half of the passphrase from local disk, brute-forces the other 2^48 possibilities for the other half, and decrypts your hard drive.
I think @cyberia's suggestion of an XOR one-time pad is the correct thing to do here. One half tells you no information about the other, so you are protected by the whole undiluted strength of your passphrase.
Dis you look into Clevis that's in the same space? Any particular motivation for not using it?
I don't know if it supports FreeBSD, and having more options is nice!
I couldn't find this project back then (and I did a few searches to see if someone had implemented the same idea...). Maybe because I started with the premise "I need this for FreeBSD" and Clevis doesn't support it. For my use case, Fedora was only an after-thought.
From the looks of it, Clevis is similar to what I need. IIUC, I'd need to use the Shamir Secret Sharing PIN or Tang PIN types. But the former does not allow auto-revocation and the latter assumes same network; correct? And it doesn't support FreeBSD right now. So Clevis wouldn't have solved my problem right away and I'd have had to do extra work on it.
At the end of the day, what I needed was pretty trivial in concept and I had a basic implementation of "serve this key and auto-lock it until keepalives fail" in just a couple of days. I'd have left it at that. The "real work" was in coming up with something I could share, with a web management interface and polishing the client integrations to work across FreeBSD and Fedora ;P I.e. the fun parts!
That's cool. I get by with dracut-sshd for my AlmaLinux hosts with encrypted root partitions, but it's not fully unattended. You still have to log in and type the password yourself. I saw this blog post about getting something similar going with FreeBSD, but I never tried it.
Out of interest, how come the server decrypts the password-half that it keeps using the client-provided key, rather than just sending the encrypted data and letting the client handle the decryption? That way, the server would never touch the key or the raw password-half.
Out of interest, how come the server decrypts the password-half that it keeps using the client-provided key, rather than just sending the encrypted data and letting the client handle the decryption? That way, the server would never touch the key or the raw password-half.
That's a good question. The reason it's this way is because I wanted to protect key retrievals with a password (to prevent arbitrary access, but also to detect malicious retrieval attempts as shown in the dashboard), so the natural thing to do after that password already made it to the server was to reuse it for encryption/decryption of the server-side key. I definitely didn't want to store user keys unencrypted at rest.
As a different option, I could return the encrypted blob to the client, but that'd no better because then the server would still see the password for a moment.
Yet another option would be to have a different password on the client to handle key decryption, but that would adds extra complexity (we'd end up with a password for retrieval, a password for decryption, and a local half) and I'm not seeing much of a gain for that.
Which leads to another completely different option: the "local half" could become the decryption key for the remote blob, instead of gluing together two halves. That would resolve this, but I kinda like the local/remote key separation + recombination that I have now because it's easy to reason about and convince yourself that the local portion was really generated locally and never left the machine.
Right, that makes sense.
I'm writing an end-to-end encrypted app right now (for fun), and I solved a similar problem by having the server keep an HKDF-derived hash of the password, to compare against a client-provided hash for authentication.
My flow goes:
That way you can use the same password for auth and decryption, but HKDF gives you the guarantee that the server can't get the decryption key from the auth key.
Hi! I'm posting this new article of mine here because I have mentioned my work on ZKeys (not by name) in a bunch of the recent "What are you doing this week/weekend" threads and I finally published the project. There was some very light interest in those threads so this announcement seems suitable.
You'll notice that the use-case for this project is extremely niche, but I'm sure we have a bunch of people running their own NAS with FreeBSD and ZFS around here. Oh, but don't let that put you off: I also have support for Fedora out of the box now, and could add other systems if there is interest in the idea.
Note that you need a coupon to register. The service is free but I just want to gate registrations in case something goes rogue. Use LAUNCH50 and you're in.
What do you see as the value to this tool vs a tpm?
You can easily remove the decryption keys if the whole device was stolen.
When storing the decryption keys in TPM, the thieves could still boot the machine.
It helps against the loss of individual storage devices, but not against the loss of the whole machine.
Correct. As I point out in the article and the site, the threat model is "the machine is stolen from my house, plugged elsewhere, and suddenly all my data is exposed". Keeping the key on the machine, even behind a TPM, fails to protect agains this.
Another option would be to encrypt the files instead of the disks. That way the backup server doesn't need to be able to decrypt anything.
I'm not sure where "backup server" comes into play here?
The point of this set up is to allow a server to come back on its own after a reboot, with disks unlocked. For the specific case of a NAS, I want the shared volumes to be available right away. (E.g. if I'm away from home and the NAS reboots for whichever reason, I do not want to have to SSH into it to perform admin tasks.)
I'm not sure where "backup server" comes into play here?
I just assumed that that was what you meant with "a small home server or NAS holding your precious photos and sensitive documents".
But then… can you reboot the machine without manually entering a passphrase before being able to access your files again?
No, but I never reboot. If I had that problem, e.g. due to power outages, I would use a pikvm to restore access.
At least on Linux, you can set up dropbear to run in the initramfs, so you can ssh in to unlock the disks. Debian has a ready-to-use package for this, and the Gentoo Wiki has a guide for setting it up from scratch which seems like it should work on other distros too.
I wonder if there's a way to keep the encryption key in memory while rebooting, so you wouldn't even have to do that (unless you lose power or something). That'd be pretty cool.
Yes! dropbear ssh in initramfs is the answer. You'll wish you had set it up years ago.
I have been considering trying to set up disk encryption key storage in the TPM, but honestly, I'd prefer to be able to ssh in and enter the passphrase. Usually when I'm putting off rebooting, it's because I don't want to go across the room and get down on my hands and knees to plug the little monitor and keyboard into the server. Entering a passphrase from my laptop across the room would be fine.
EDIT: Fedora and RHEL support dracut-sshd.
Thanks, this is some valuable information I did not know. I just realized, I wouldn't even need that. My boot drive is unencrypted, it's only the disk drives that are encrypted. The boot drive holds no data of importance (swap is disabled).
I don't know if you implemented it, but it would be useful to link the key to a physical location as extra security measure. Bringing up a stolen machine should typically cause it to get a new IP address and "location" (different hops along the route) in the network.
Should be easily doable. I already implemented "key access history" and perform geolocation for auditability purposes: in the UI you can see all accesses to a key of yours and which IPs and countries those activities originated from.
The IP only is not sufficient because of dynamic IPs in many cases. More precise geolocation could be done without much difficulty... but I don't particularly like the idea of storing that information. Maybe it'd be an option...
This solves the exact problem I had with my cheap OVH bare metal box that I had parked, thanks! My box doesn't have a TPM and I was considering a similar solution to this but unsure about the direction and the required engineering effort. Great to see validation and the concrete implementation. I may give this a try when I have time to work on it.