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.

  • 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 9: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.

  • +1 for mentioning the hardware security module, the only solution, really, to this conundrum. – MariusMatutiae Oct 27 '17 at 8: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 8:52
  • @StephenKitt Hardware keys are great when the work. When they don't, well... – Satō Katsura Oct 27 '17 at 9: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.) – Stephen Kitt Oct 27 '17 at 9: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

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.

  • Thank you for explaining Tony, you gave a better view on the matter. A hardware security module as mentioned by Stephen will be the main aim. – Zakk Coetzee Oct 27 '17 at 8:49
  • @ZakkCoetzee : As I said in the other answer, what stops the attacker from using the HSM if they are root? – Martin Bonner Oct 27 '17 at 12:08
  • @MartinBonner As said above by Stephen Kitt it stops them from getting the key which is definitely better than getting the key. – Zakk Coetzee Oct 31 '17 at 8:45
  • It is, but not very much better. Ask Diginotar (who had their key in an HSM, but left the HSM connected and with the relevant smart-card in the slot - so that an attacker could sign a number of the attacker's certificates.) – Martin Bonner Oct 31 '17 at 9:17

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.