Remotely Keyed LUKS
27 Jun 2024Securing data against the theft of Linux servers.
The obvious solution to thieves accessing data on stolen Linux servers is LUKS. LUKS lets you encrypt partitions so that they can only be accessed once unlocked with a passphrase.
Problem:
LUKS requires a passphrase to be typed-in to gain access to encrypted data (or even to boot, if the root partition is encrypted). This is problematic in the case of unexpected reboots, regardless of cause.
/etc/crypttab used to allow a script to provide the passphrase, but systemd has a bug/feature which prevents this from working.
/etc/crypttab does allow a passphrase to be read from disk, but that appears pointless as it would need to be on unencrypted storage.
Solution:
Remotely Keyed LUKS would consist of two parts, remkeyfs and remkeyserver.
remkeyfs would be a remotely keyed encrypted filesystem.
Encrypted data (passphrases) would be stored locally, with unencrypted filenames.
The data would be encrypted with a key retrieved from remkeyservers via HTTPS.
/etc/crypttab would then contain references to /remkeyfs-mountpoint/volume-guid.passphrase
Passphrases stored in remkeyfs would be randomly-generated second-slot LUKS passphrases, allowing the original human-memorable passphrases to still be used, if ever needed.
The remkeyservers, which would be located on remote sites, would only serve the key to requests from the expected (probably NAT’ed) IP address.
When thieves power-up stolen servers, remkeyfs would be denied the key by the remkeyservers (due to the unexpected source IP address) and so remkeyfs would not decrypt the needed passphrase(s). The stolen data would remain encrypted.
If the stolen servers had internet access, the failed attempt would be logged, including the source IP.
F.A.Q.
Q. Why store encrypted passphrases locally, rather than store unencrypted passphrases on the remkeyservers?
A. The remkeyservers would be a high value target if they contained all of the LUKS keys. Also, this approach allows the remkeyservers to be run by third parties with whom you would not trust passphrase(s).
Q. What if the thieves go to the remote site and steal the remkeyservers, too?
A. The remkeyservers will use LUKS and will require a password to be enetered at boot. As there can be multiple remkeyservers at multiple sites, it does not matter if remkeyservers have to wait for a human for occassional reboots.
Q. This is just what I need, where can I download the remkeyfs and remkeyserver code?
A. This is just a design for a solution. I haven’t written the code (yet). Email me if you’re interested in this solution.
Q. Is life easier without systemd?
A. Yes, without the systemd crypttab bug, a Devuan server’s crypttab could just curl a key from an IP-restricted remote nginx server. No new software required.