7

Is there a way to automatically unlock a LUKS drive at boot time with the key-file being stored on a remote machine. The idea is to make sure servers may restart without any user input. Servers are on a public cloud and I can't encrypt the root partition. Leaving the key-file on the machine would simply defeat the purpose of encryption.

Hence the idea to have the key file in a remote machine connecting via a secure channel like ssh.

Mandos seems to do what I'm after but I've got two questions on it.
- All the documentation refers to the root file systems. Can it work with any drive?
- The documentation states that it only works on an intranet, would that work if the local and remote servers connects via a VPN?

Is it the best solution? the only solution?

ludofet
  • 171
  • 1
  • 1
  • 3
  • You may be able to use this with a monitoring solution https://github.com/dracut-crypt-ssh/dracut-crypt-ssh – user9517 Nov 22 '17 at 17:01
  • 1
    If the servers are on a public cloud, it doesn't matter if you encrypt the storage or not, as the cloud provider will always be able to inspect your instance's RAM to find the encryption key. – Michael Hampton Aug 29 '18 at 18:46

5 Answers5

7

tang and clevis can achieve that even with encrypted root partition on CentOS 7 (and I personally use it to automate boot on my home network and at work). Have a look and check if it plugs into your VM.

Tomek
  • 3,390
  • 1
  • 16
  • 10
  • This answers the question, but doesn't solve described security problem - which is unsolvable via this way. As this doesn't protect against someone stealing server (or data from it), because the attacker can access keys from tang in the same way, as the unattended boot can access it. – kravemir Aug 09 '23 at 15:15
3

You have various solutions online (like here) where a small ssh server (busybox+dropbear) is included in initrd to run it at boot time before filesystem mounting and let it be contacted to provide the passphrase as input.

You may be able to do something around that: in initrd, inside of launching a sshd server to wait for remote connection, start an ssh connection to your remote host storing keys, with specific ssh keys, in order to get the key file (doing an scp), then unlocking local filesystem with the LUKS key.

It is however not without drawbacks: you need of course to make sure to delete the downloaded LUKS key as soon as the unlock is done otherwise you gained nothing. Even better if you find a way to have it in RAM only for the time needed and not stored anywhere. Also, "any" attacker being able to read the content of your initrd may find the ssh connection and its ssh key, contact your remote host with them and download the LUKS key. If this happens it means however that your attacker is clearly targeting you and taking the time to study your specific setup, this is clearly outside of script kiddies. You should at least carefully review all connections that downloaded the key, the events should be tied to your other monitoring alerts showing that a given server is indeed rebooting (which again will not protect you against an attacker that was able to modify your initrd).

You also have to take into account cases where network fails at this moment, scp can not connect, etc... So having at the same time the option of the small sshdserver to be able to connect to it and debug things is not a bad idea. Or see what kind of out-of-band solutions your cloud provider can offer.

Patrick Mevzek
  • 9,921
  • 7
  • 32
  • 43
  • 1
    Thanks, You made me realise that the ssh keys have to be readable so "any" attacker with access to the HD would get them. If the remote server only answer request from the IP of the server I should reduce the risk of the keys being accessed from a rogue machine, right? I don't see how an attacker could get access to the initrd and not the unlocked partition (once the server has started) anyway. So I'm not sure I would be more at risk. I am missing something? – ludofet Nov 22 '17 at 17:19
  • Yes you can force the source IP on the remote host for allowing ssh connections, but if you have an attacker already able to read your local ssh keys (that should be only readable by root) it probably means he can read all your (decrypted) disk anyway already. But you could tied the key provided to the source IP so that any machine could get only its decrypting key and no other (if you maintain more than one server with encrypted disks) – Patrick Mevzek Nov 22 '17 at 17:29
2

I have used Mandos to store and retrieve the passphrase to unlock the root file-system, to allow unattended reboots and simply store keys for all other volumes used by that system in a file on that encrypted root volume.

I have used mandos over a WAN connection (by configuring DHCP and the IP-address of the mandos server in the client system rather than relying on Zeroconf which only works in the local LAN) without bothering with a VPN connection.

HBruijn
  • 77,029
  • 24
  • 135
  • 201
1

I wrote a keyscript (and initramfs hook) that allows a key to be retrieved by UUID over HTTPS.

1. Install dependencies:

sudo apt -y install curl initramfs-tools dropbear-initramfs

2. Add a initramfs hook:

sudo nano /usr/share/initramfs-tools/hooks/curl

Paste the following content:

#!/bin/sh -e
PREREQS=""
case $1 in
    prereqs) echo "${PREREQS}"; exit 0;;
esac
. /usr/share/initramfs-tools/hook-functions
# copy curl binary
copy_exec /usr/bin/curl /bin
# fix DNS lib (needed for Debian 11)
cp -a /usr/lib/x86_64-linux-gnu/libnss_dns* $DESTDIR/usr/lib/x86_64-linux-gnu/
# fix DNS resolver (needed for Debian 11 + 12)
echo "nameserver 1.1.1.1\n" > ${DESTDIR}/etc/resolv.conf
# copy ca-certs for curl
mkdir -p $DESTDIR/usr/share
cp -ar /usr/share/ca-certificates $DESTDIR/usr/share/
cp -ar /etc/ssl $DESTDIR/etc/

And ensure that the script is executable:

sudo chmod 755 /usr/share/initramfs-tools/hooks/curl

3. Now create the keyscript:

sudo nano /bin/luksunlockhttps

Paste the following content:

#!/bin/sh -e
# Wait 10 seconds for DHCP (needed for Debian 11+12)
if [ $CRYPTTAB_TRIED -eq "0" ]; then
  sleep 10
fi
if curl -f --retry-connrefused --retry 5 -F "uuid=$CRYPTTAB_KEY" \
  https://www.usbencryptionkey.com/request; then
  exit
fi
/lib/cryptsetup/askpass "Enter password and press ENTER: "

Ensure that the keyscript is executable:

sudo chmod 755 /bin/luksunlockhttps

4. Modify the "crypttab"

Replace "none luks" by "cdbafbaa-21d8-11ee-9186-df2d5ef43f21 luks,keyscript=/bin/luksunlockhttps" using:

sed -i 's/none luks/cdbafbaa-21d8-11ee-9186-df2d5ef43f21 luks,keyscript=\/bin\/luksunlockhttps/g' /etc/crypttab

5. Now regenerate the "initramfs" using:

sudo update-initramfs -u

6. Implementing web endpoint

Writing code that responds with the key on POST requests to https://www.usbencryptionkey.com/request (with 'uuid' as a parameter) is left as an exercise to the reader :-)

source: https://tqdev.com/2023-luks-with-https-unlock

mevdschee
  • 581
  • 5
  • 6
0

Mandos seems to do what I'm after but I've got two questions on it. - All the documentation refers to the root file systems. Can it work with any drive?

Well, the mandos-client package assumes that you want to use it for decrypting the root file system, and all its binaries have defaults which make them most easy to use in the initramfs environment. But it’s certainly possible to run it elsewhere. To run the "mandos-client" binary from the normal system environment, it would need these options: --seckey=/etc/keys/mandos/seckey.txt --pubkey=/etc/keys/mandos/pubkey.txt --network-hook-dir=/etc/mandos/network-hooks.d

  • The documentation states that it only works on an intranet, would that work if the local and remote servers connects via a VPN?

Yes, using the --connect option to mandos-client, and configuring the Mandos server to use a static port number (using the port option in the mandos.conf file). Normally, when wanting to use a non-intranet server, configuring an IP address and route on the client side is also a concern, but since you’re not encrypting the root partition, you don’t have that problem.

teddy
  • 1
  • 1