Automate encryption with GPG

Privacy
Privacy

This blogpost requires some familiarity with GPG.

Today I want to share the scripts for running GPG in the batch (unattended) mode. You can have a password on the keys if you want, but since this is the automated mode, you may want to use keys without a password. Irrespective of whether or not you use a password – use a separate set of keys that you will not use for anything that not batch processed. The scripts are primarily for Linux. If you need them for Windows, please read this and post any problems you face in comments section, and I will help.

The script for encryption is here:

#! /bin/sh
GNUPGHOME='/apps/gpg/'
export GNUPGHOME
gpg --batch -r <reciepient> --output $2 --passphrase-fd 3 --sign --encrypt $1 3</apps/gpg/passph

The first line shows the location of the shell – please change it according to where the shell is on your system. The second line has the location of the folder where the keys are located – the pubring.gpg and secring.gpg. In the last line, replace <reciepient> with the name on the reciepient key. The /apps/gpg/passph points to the location of the file containing the passphrase. The script will both sign and encrypt the file – change this to suit your needs. The script expects the name of the input file and the name of the output files as parameters in that order.

The script for decryption is here:

#! /bin/sh
GNUPGHOME='/apps/gpg/'
export GNUPGHOME
gpg --batch --passphrase-fd 3 --status-fd 1 --decrypt $1 3</apps/gpg/passph | grep '\[GNUPG:\] GOODSIG'
if [ $? -eq 0 ]; then
  gpg --batch --passphrase-fd 3 --output $2 --decrypt $1 3</apps/gpg/passph
fi

The first three lines are similar. Line 4 just checks if the file has a valid signature. If you want to skip this step remove lines 4, 5 and 7. No effort is made to see who signed the file. In my scenario, I could control the people who could sign by having only those public keys in the repository, and the repository could only be written to by ‘root’.

Please post comments in case of questions, concerns.

Share

SFTP>FTP+GPG

Shows that FTP+GPG combination cannot be used in place of SFTP – SFTP is still more secure. Also includes a howto document on setting up passwordless SFTP based automated file transfers.


Recently, we needed to setup secure file transfer with a third party that did not support SFTP. Hence we decided to use FTP+GPG – which includes transfer of GPG encrypted files with FTP. For more details on GPG, visit the homepage http://www.gnupg.org/. It can also operate in ‘portable’ mode – from a USB key.

We did not realise that this combination is still significantly less secure that SFTP based transfer. The threats it does not cater to, which SFTP can combat are:

  • Someone can come to know about the username, password used in the connection since this is still being transferred un-encrypted
  • Using this, someone can load their own files into the server which can be designed to either infect the system, or upload malicious information

Even if GPG signatures are used (as we did after coming to know about these shortcomings), there is still the risk of someone replaying the same files that we received. Even this can cause problems in certain situations. Hence, we had to resort to fixing the source IP to combat the problems. Due to using signatures and IP fixing, it all turned out to be more cumbersome, and still less secure.

The best way currently to establish automated file transfers is to do a password-less SFTP. It does not require any password transfer over the network at all, keeps everything encrypted, and: a disgruntled employee who happens to remember a password (in case of password based SFTP) cannot disrupt your services.

This document contains instructions on how to set this up: Password SFTP – How to setup. There is also an online version of the same document. If you have any questions, please post as comments.

Share