16

I am tasked with automating a gpg decryption using cron (or any Ubuntu Server compatible job scheduling tool). Since it has to be automated I used --passphrase but it ends up in the shell history so it is visible in the process list.

How can I go about automating decryption while maintaining good (preferably great) security standards?

An example will be highly appreciated.

muru
  • 69,900
  • 13
  • 192
  • 292
Zakk Coetzee
  • 163
  • 1
  • 1
  • 6
  • Arguments like this are visible in `ps` etc unless you have `hidepid` on `/proc`, but a shell running a script (from cron or otherwise) is noninteractive and should not write history unless misconfigured. – dave_thompson_085 Oct 27 '17 at 09:25

2 Answers2

25

Store the passphrase in a file which is only readable by the cron job’s user, and use the --passphrase-file option to tell gpg to read the passphrase there.

This will ensure that the passphrase isn’t visible in process information in memory. The level of security will be determined by the level of access to the file storing the passphrase (as well as the level of access to the file containing the key), including anywhere its contents end up copied to (so take care with backups), and off-line accessibility (pulling the disk out of the server). Whether this level of security is sufficient will depend on your access controls to the server holding the file, physically and in software, and on the scenarios you’re trying to mitigate.

If you want great security standards, you need to use a hardware security module instead of storing your key (and passphrase) locally. This won’t prevent the key from being used in situ, but it will prevent it from being copied and used elsewhere.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • +1 for mentioning the hardware security module, the only solution, really, to this conundrum. – MariusMatutiae Oct 27 '17 at 08:40
  • Stephen thanks for the hardware security module mention, I'll do some research. Thanks for pointing me in the right direction. – Zakk Coetzee Oct 27 '17 at 08:52
  • @StephenKitt Hardware keys are great when the work. When they don't, [well](http://karl.kornel.us/2017/10/welp-there-go-my-git-signatures/)... – Satō Katsura Oct 27 '17 at 09:13
  • @SatōKatsura true, although I would point out that the Yubikey isn’t an HSM. (Which doesn’t mean HSMs [aren’t vulnerable of course](https://cryptosense.com/the-untold-story-of-pkcs11-hsm-vulnerabilities/).) – Stephen Kitt Oct 27 '17 at 09:29
  • "If you want great security standards," then you cannot have an automated job decrypt or sign anything. – JimmyB Oct 27 '17 at 10:04
  • @StephenKitt True. Sadly there are still many problems related to the use of hardware keys. Despite the many efforts to get them ready for general use, I don't think we're quite there yet. – Satō Katsura Oct 27 '17 at 10:26
  • An HSM doesn't actually help all that much. If the cron job can use the HSM, then what stops an attacker from using it too? The answer is "operating system security" - and if that can stop an attacker using the HSM, it can stop an attacker reading the password file. (There are some advantages to an HSM. It won't stop the attacker using the key, but it will stop them *copying* the key - and depending on the setup, using it may create logs which at least allows the attack to be uncovered.) – Martin Bonner supports Monica Oct 27 '17 at 11:58
  • @Martin granted; the advantages you quote are what constitutes in my mind the different between my first paragraph and my second one — preventing attackers from copying the key is a big advantage as far as I’m concerned. I should really have started by saying that any security-related question needs to be based on specific attack scenarios and levels of mitigation. – Stephen Kitt Oct 27 '17 at 12:13
  • Callout - with this solution, your file could end up in backups which has the potential to be seen by the storage / backup team etc. – jacksonecac Oct 27 '17 at 13:00
5

Automating decryption means you have to store the passphrase somewhere, or not use a passphrase (unless you use additional options as pointed out in the other answer submitted by Stephen while I was typing mine)! Neither of those match your requirement for good or great security standards.

i.e. your requirement is not compatible with it being secure.

You can rely on things like - you have to be root, I've given the file in which my passphrase is stored a really confusing name, I've encrypted the underlying file systems, etc., etc. but they're all layers which are trivial to circumvent once you are root in the first place.

The option which prevents the passphrase showing up in the process list is --passphrase-file <file-name>.

However, that's no more secure than just removing the passphrase in the first place.

EightBitTony
  • 20,963
  • 4
  • 61
  • 62