10

I have a backup server, that creates xz compressed tar archives of directory trees to be backed up. These tar archives can get huge (multiple TBs), are split into pieces (2.5TB), and each piece is written to a LTO-6 tape, and the tapes go offsite.

Now I want to add encryption. I can GPG encrypt the tar archive before splitting, using public-private key encryption, and with one or more recipients (admin public keys).

However, in case of recovery, at least one admin needs to put his private key onto the backup server, since the files are too huge to be unpacked anywhere else.

GPG uses a hybrid encryption scheme under the hood, with a symmetric cipher like AES with a session key, and only that session key gets public-private key encrypted for the recipients.

Is there a way to let an admin provide the session key for decrypting file to be recovered without putting the private key onto the backup server?


I could reinvent the wheel of course:

  • create a random session key on the backup server per each file to be backed up
  • use GPG symmetric encryption to encrypt the file
  • use GPG asymmetric encryption to encrypt the session key for each recipient

But is there a "standard" or builtin or best-practice way of achieving above?

17
+100

This is definitely possible with the --show-session-key and --override-session-key options.

First you need the beginning of your encrypted file. This is where the encrypted session key is stored.

root@qwerty:~/gpg# head -c 1024k bigfile.gpg > head.gpg

Then copy it to your workstation and retrieve the session key

PS C:\Users\redacted\Downloads> gpg --show-session-key .\head.gpg
gpg: encrypted with 2048-bit RSA key, ID DC21D645, created 2016-02-01
  "admin <admin@domain.tld>"
gpg: session key: '9:926EC16DF1248A1C4401F5AD5D86C63C1BD4BF351ECEFB121C57EC209DE3933D'

Now you can decrypt the file using your session key

root@qwerty:~/gpg# gpg -d -o bigfile --override-session-key 9:926EC16DF1248A1C4401F5AD5D86C63C1BD4BF351ECEFB121C57EC209DE3933D bigfile.gpg
gpg: encrypted with 2048-bit RSA key, ID DC21D645, created 2016-02-01
  "admin <admin@domain.tld>"
  • that's a really cool solution for the problem – Lars Feb 2 '16 at 11:28
  • Thanks!! Nice trick with head and such. The approach solves my original itch. – oberstet Feb 5 '16 at 17:01
3

It looks as though most of your question has been answered, however, if you're administrator team is wary of private keys ending up out of their local control ya might consider sshfs to mount the remote backups over a ssh session.

Install via apt on each remote administrator's system

sudo apt-get install sshfs

Assuming admins' ssh configuration looks something like below

# configuration for ssh login to remote server
Host Remote
    Hostname Remote.web.domain
    User admin
    IdentityFile ~/.ssh/private.key

Then your admins can use something like below for mounting

# make a mount point
mkdir -p /mnt/remote
# mount remote directory to local file system
sshfs Remote:/path/to/encrypted/dir /mnt/remote

To unmount after inspection the remote administrator can use the following

fusermount -u /mnt/remote

The sweet bit about using sshfs is that only public keys for GnuPG and ssh are needed on the remote server, the related private keys stay on the systems that own'em. Second nice bit is that until read or accessed most of the file info stays on its related file system.

If you're still looking for tools to facilitate auto encryption of logs or directories ya might want to check the prof of concept tool I've pushed to GitHub (specifically Scenario Four written for sshsf usage) which with a little customization will happily encrypt almost any data via GnuPG. But be warned that it is experimental and some of it's features may cause corruption of data if misused. Source code is less then ~1600~ lines so it's very possible to audit in less then a weekend.

Additional security can be had by setting up the remote server's ssh configuration to chroot users to only allow access to the encrypted directory and disable interactive shell for admins keys that are used in this fashion.

1

If you want the secret key kept off the hard disks, you could create a ramdisk (remember those?) and load the secret keys there from your secure not-on-server location as needed. Use it for decrypting and when done overwrite it with /dev/random. The secret has to go into RAM to be used by GPG anyhow, so why not twice?

If you can't let a secret key ever be on the server, even in RAM, then you have a technical impossibility. GPG must have the secret key somewhere in order to decrypt anything.

Ramdisk info: https://unix.stackexchange.com/questions/66329/creating-a-ram-disk-on-linux

  • 2
    GPG uses a per-message symmetric secret ("session key") that is different for each message encrypted. It is this symmetric key that technically needs to be on the machine that decrypt the respective message. I want to keep the GPG (asymmetric) private key offline. The latter is used by GPG to encrypt the symmetric session key. So I am after a scheme that makes use of these aspects ... – oberstet Feb 1 '16 at 7:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.