Does a GPG pass-phrase provide a real benefit to the majority of users?
It seems that there will be the following categories of attack which result in stealing the secret-key data:
- User-space compromise of account (EG exploiting a bug in a web browser or IRC client).
- System compromise (EG compromising a local account and exploiting a kernel vulnerability to get root access).
- Theft of the computer system while powered down when the system was configured to not use swap or to encrypt the swap space with a random key at boot time.
- Theft of a computer system while running or that did not have encrypted swap.
- Theft of unencrypted backup media.
Category 1 will permit an attacker to monitor user processes and intercept one that asks for a GPG pass-phrase as well as to copy the secret key. Category 2 will do the same but for all users on the system.
Category 3 will give the potential for stealing the private key (if it’s not encrypted) but no direct potential for getting the pass-phrase.
Category 4 has the potential for copying a pass-phrase from memory or swap. I am inclined to trust Werner Koch (and anyone else who submitted code to the GPG project) to have written code to correctly lock memory and scrub pass-phrase data and decrypted private key data from memory after use. But I really doubt the ability of most people who write code to interface with GPG to do the same. So every time that a GUI program prompts for a GPG pass-phrase I think that there is the potential for it to be stored in swap or to remain indefinitely in RAM. Therefore stealing a machine that does not have it’s swap-space encrypted with a random key (which is the most practical way of encrypting swap) or stealing a running machine (as mentioned in a previous post [1]) can potentially grant a hostile party access to the pass-phrase.
So it seems to me that out of all the possible ways of getting access to a GPG private key, the only ones where a pass-phrase ones is going to really do some good are categories 3 and 5. While it’s good to protect against those situations, it seems to me that the greatest risk to a GPG key is from category 1, with category 2 following close behind.
I previously wrote about the slow progress towards using SE Linux and GPG code changes to make it more difficult to steal the secret key [2] – something that I’ve been occasionally working on over the last 6 years.
Now it seems to me that the same benefits can and should be made available to people who don’t use SE Linux. If a system directory such as /var/spool/gpg was mode 1770 then gpg could be setgid to group “gpg” so that it could create and access secret keys for users under /var/spool/gpg while the users in question could not directly access them. Then the sys-admin would be responsible for backing up GPG keys. Of course it would probably be ideal to have an option as to whether a new secret key would be created in the system spool or in the user home directory, and migrating the key from the user home directory to the system spool would be supported (but not migrating it back).
This would mean that an attacker who compromised a local user account (maybe through a vulnerability in a web browser or MUA) would not be able to get the GPG secret key. They could probably get the pass-phrase by ptracing the MUA (or some other GUI process that calls GPG) but without the secret key itself that would not do as much good – of course once they had the pass-phrase and local access they could use the machine so sign and decrypt data which would still be a bad thing. But it would not have the same scope as stealing the secret key and the pass-phrase.
I look forward to reading comments on this post.
This is an issue on which I’ve also pondered. I currently use Enigmail in Thunderbird for signing my email so I can do it through GMail and am somewhat miffed that I’m presented with a GTK form which is part of a very large and complicated application to enter my very very secret pass-phrase. (By telling everyone this, my security just slipped another notch too I suppose.)
What I’ve read about GPG on the net would suggest more or less that it’s not so bad if they steal your private key, because they still don’t have your pass-phrase. I think it’s getting to the point where it’s easier to protect the private key itself.
The pass-phrase is important nonetheless. If a solution like the one you described was used without a pass-phrase, if you unwittingly run a user-space application with malignant code it can decrypt anything without the need to even attempt to sniff a password from somewhere. The pass-phrase should also be necessary for important tasks like signings and generating revocations.
Keeping keys in a central protected location is an appealing idea. With SELinux enabled, the difficulty for a remote attacker trying to work out how to access them would be even greater (I won’t say impossible, though that’s the theory of course). Add encryption and even someone who steals the box would have to be very dedicated indeed to get anything out of it.
As for my email, I reckon I’ll set up a server with mutt or something, as a console with only a couple of user-space applications running should be inherently more secure due to less possible code to crack than a full X session.
Why would you ever enter your GnuPG passphrase into any application that isn’t GnuPG? That’s what gnupg-agent is for.
They might compromise a backup host or steal backup media — a pass-phrase would not be entered in this situations. The PP is only useful if the key is encrypted.
For each of the cases you mention, a passphrase at the very least reduces the window of opportunity. If I don’t use my key at the moment an attacker gains control, it remains protected. If someone steals my machine the passphrase /may/ be in swap from some application, but it also may have already been overwritten many times before that. Perhaps an attacker can only fetch files from my account but doesn’t control memory.
A passphrase doesn’t bring you many hard guarantees but it vastly reduces the chances of an attack being actually successful.
Thomas: Thanks for the example of a big application that uses a GPG key. It’s one example of many which breaks the suggestions to use gpg-agent etc that other people are saying (NB they wrote their posts before I approved yours).
I don’t believe that MUTT is necessarily more secure merely for not using X. If you ran MUTT on a system which did not use X then you would get a significant security benefit (EG run Lynx and Mutt in different virtual consoles and with different UIDs). When we get the X access controls for SE Linux in production there will be some significant benefits there too.
http://np237.livejournal.com/18721.html
At the above URL Josselin Mouette comments on this and suggests that once a PAM bug is resolved it will be possible to use the GNOME GPG agent. In addition to the issue that not all applications will use the GNOME GPG agent (although I guess you could just avoid potentially insecure applications).
Finally we have to keep in mind the fact that the most pessimal possibilities need to be considered when discussing security. So if a machine is stolen it might be most likely that no pass-phrases were in RAM and there was no unencrypted data on disk which allows recovery and the encryption was all of adequate strength. But you still need to consider the less likely possibility that the attacker got lucky.
Also in regard to compromise of applications and systems, you can never really be sure that your system has not been cracked.
One of us is confused about how gnupg-agent works. I’m not sure if it’s you or me.
In my experience, applications don’t have to use it or even be aware of its existence at all. If GnuPG is configured to use the agent, invocations of GnuPG spawn gnupg-pinentry without ever telling the calling application that a password is needed. Once you configure GnuPG to always use the agent, applications are no longer aware that you even have passphrases.
A quick Google search apparently reveals (I don’t use it myself) that Enigmail does indeed work with gnupg-agent and doesn’t appear to do anything strange that breaks it. (Unless you’re on Windows, where in general getting the agent working is harder.)
@Russ
Thanks very much for pointing out that gnupg-agent works fine with Enigmail. I set that up using Debian gnupg-agent instructions (http://www.debian-administration.org/articles/452) and it works fine. I think that taking key responsibility from Thunderbird and giving it to pinentry-qt is an improvement.
@etbe
Yes I didn’t spell it out very clearly; I did mean a system which does not run X for reading email.
The main advantage of gnupg-agent as pointed out by Russ if of course that it’s completely application-agnostic (if you’ll let me throw that term in there). Now for me it doesn’t matter whether I’m using GNOME or KDE, or Thunderbird or something else; I still use the same mechanism for entering my pass-phrase. That’s a win, and I think it’s the best that you can hope for in a graphical environment.
I’ve experience (5) but not (1)-(4) (at least not on systems with my GPG secret key on – I’ve seen a few compromised GNU/Linux servers).
That’ll teach me to refuse to encrypt back-ups (because I want the maximum chance of recovering them later – lots later), and then carrying them around away from the computer that was backed-up.
So yes, the pass phrase was useful for me – although the key still got revoked.
It also raises the barrier in 1 and 2 and 4. Not only do you have to compromise the system, you then have to capture the pass phrase. Easy perhaps, but not if the owner notices something is up before re-entering their pass phrase.
Russ and Thomas: gpg-agent seems convenient, but given that ptrace is permitted on it there doesn’t seem to be any security benefit to using it. In fact instead of having to use ptrace on multiple applications that might prompt for a pass-phrase, it is only necessary to ptrace gpg-agent.
Of course I can write SE Linux policy to protect gpg-agent but that takes me back to the “same benefits can and should be made available to people who don’t use SE Linux” point.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490545
I’ve filed a bug report at the above URL.