9

I have a linux system running at a cloud provider where I created an encrypted container using LUKS to store personal data.

The encrypted container is manually mounted at /srv; the rest of the system is unencrypted so that the server and especially the ssh daemon start automatically on system boot.

At the moment, if the server restarts (because of an update that requires a restart or because the host system where the droplet runs required a restart) I need to manually open the LUKS container and start the services that store data in the encrypted partition (dovecot, mysql etc.). Of course, this is the logical consequence of having an encrypted partition. But I was wondering if I can automate this in a secure manner.

I do not want to store the passphrase on the server for obvious reasons. So I wrote a little script that runs on a Raspberry Pi at home: It ssh-es every 5 minutes into the server and checks if the Loopback Device is mounted. If not it mounts the container (relevant lines of the script, this is only executed if /srv is not mounted):

# Mount Srv Container
ssh root@<ip> "echo -n '*** my passphrase ***' | cryptsetup luksOpen /root/srv_container_file container -"
ssh root@<ip> "mount -t ext4 /dev/mapper/container /srv"

# Start Services that store data on /srv
# ...

The approach works but it feels super hacky. Not sure if the constant connections, aka active checking, are a good idea and I am also not sure if I am opening myself up to vulnerabilities by echoing my passphrase into cryptsetup.

Thus my question:

What is a good/standard way to automatically open the LUKS container without storing my passphrase on the server and without opening up my system to vulnerabilities (compared to manually opening the container)? References to official documentation are very welcome.

What am I trying to protect myself from?

  • I don't know how the cloud provider handles old and/or faulty disks. I don't want anyone to read my data from the physical disks or backups made by my cloud provider.

  • I don't know if my disk image gets moved on the physical storage (according to the docs of my provider it's stored redundantly), so I don't want anybody who has access to those blocks after me to be able to restore the data.

  • I know that once an attacker has shell access to my running system it is game over as the partition is open and not passphrase is needed.

phisch
  • 1,305
  • 10
  • 14
  • Is a MITM attack not part of your threat model? – forest Apr 29 '18 at 10:21
  • Are you talking about the ssh connection? It failes if the hostkeys don't match. – phisch Apr 29 '18 at 10:22
  • Indeed, but a compromised server could steal said keys. If all that matters is data-at-rest security (e.g. for the automated backups you mention), then this makes more sense. However connecting every 5 minutes is a little silly. Why not simply have the server request the passphrase when it boots up? Do you expect the encrypted partition to spontaneously or randomly unmount at runtime? – forest Apr 29 '18 at 10:23
  • If someone has gained unauthorized access to my server they do not need the passphrase, as the partition is already mounted and the data is available. The reason why I have the Passphrase stored at Home and have the Raspi connect to the Server is that it is not reachably from the internet and the server does not know where the password is coming from. – phisch Apr 29 '18 at 10:27
  • Fair enough. So why not supply the password at boot? Why do you need to do it every 5 minutes? Surely you can automate supplying the password whenever you start up the VPS. – forest Apr 29 '18 at 10:28
  • Thats exactly my question. How do I supply the password at boot time or close hereafter without storing the password on the system. – phisch Apr 29 '18 at 10:30
  • Do it the other way around. Rather than your raspi push the password to the server, have the server pull the password from the raspi. That way, only your server (or someone with privileged access to it) would be able to get the password. – forest Apr 29 '18 at 10:31
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/76738/discussion-between-phisch-and-forest). – phisch Apr 29 '18 at 10:32

1 Answers1

2

Rather than having a local machine periodically query the server and push the key to it if necessary, you could do it the other way around and have the server pull the key from your local machine. The server and client can mutually authenticate each other with SSH, making it such that an active attacker who has access to either the local machine's storage or the remote machine's storage would be required to steal the key. If the attacker is passive and can only read the contents of the remote machine's disk, but not act on it (for example, by SSHing to the real server and backdooring it), pulling the password should be safe. The specific implementation is up to you, but it could be:

  1. The server boots up, connects to your local machine, and requests the key.

  2. The server and your local machine authenticate each other over SSH.

  3. Optionally, the two machines can verify that the other is connecting from the correct IP.

  4. After authentication, the server pulls the key from your local machine.

Since you specified that your threat model involves an attacker with complete access to the remote server's storage, be aware that you can only protect from a passive adversary, not one who is able to both read the storage and MITM your connection, or SSH in directly using stolen credentials.

forest
  • 64,616
  • 20
  • 206
  • 257
  • 3
    I don't understand why you recommend pulling. Do you see a security benefit, or is it only to avoid a connection at 5-minute intervals? I see a security benefit to pushing (admittedly in a very specific scenario): if the attacker gains access to a copy of the server (e.g. by duplicating a backup), but cannot compromise the network connection between the watchdog Pi and the legitimate server, then they won't have any way to obtain the encryption key. – Gilles 'SO- stop being evil' Apr 29 '18 at 14:23
  • Thank you @Gilles. That was the reason I went with pushing. I did not want to leave anything on the Server as to where the passphrase is coming from. – phisch Apr 30 '18 at 06:16
  • 1
    @Gilles That issue can be mitigated by checking for the correct IP, as I mentioned in the answer. – forest Apr 30 '18 at 08:36