Shouldn't GPG key fetching use a secure connection?

Question

If I run this for example:

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451

then does the importing occur in a secure way? I mean does it go over only secured connections? (HKP?) Could it be compromised because the key fetching doesn't use end-to-end encryption+proper authentication (MITM attack)?

UPDATE: So I'm asking exactly this: when I want to grab someone's public GPG, then could it be attacked with MITM? (So that the attacker hijacks the "connection" and it spoofes the keyserver.ubuntu.com to an ip that he ownes, and gives a false public key, and when I check it with GPG then I will contact the bad GPG keyserver, and it could look like that the GPG key is valid!)

Answer 1

It depends on your definition of "compromise". The main concern is privacy, for which parcimonie and tor are solutions, as noted below.

But first lets look at data integrity.

The notion of "end-to-end" security is most helpful when it covers the actual application you have in mind for the data. Since the objects moved around by the OpenPGP HTTP Keyserver Protocol (HKP) are covered by signatures based on public-key technology, they can be checked by your application (e.g. gpg) itself. It will establish whether the signatures are valid, whether they apply to other keys and people you trust, etc. (Update: So gpg only (optionally) gets the certificates from the keyserver, it does not rely on any keyserver to establish the validity of the keys.)

For example suppose you're using gpg to check signatures on email. If gpg tells you a given key is not known, you fetch it from a keyserver. Perhaps your mail then tells you the key is known but not trusted, since there isn't a trusted path (e.g. leveraging wotsap) from your ultimately trusted keys to the one that signed the email (like this one). So you look at the signatures, and find the key of someone who is trusted by someone you know, and who trusts the given key and download that too. If you end up with a path you trust, everything is great. If someone mucks with the keys while you're downloading them, you either won't get a trusted path (due to broken or unhelpful keys), or (and this would be pretty unusual) you'll get another path that might or might not work for you. The point is, though, that you still have to use gpg to check the paths, and evaluate the "intangibles" of the trust path yourself (how much you trust people and their understanding of signatures, etc). But you always have to do that with PGP. It is thus "end-to-end" in the sense that it is secured all the way from the person who made the signature, to your software which checks the signature, and your configured trust roots, and is thus pretty much ideal.

The security of the transport is not particularly important, and using TLS and the associated PKI and certificates would add extra complexity, cost and brittleness to the PGP keyserver infrastructure, without improving data integrity. If someone messed with the transport, they could deny you service, or do something like a phishing attack, but you nearly always have to deal with those sorts of issues anyway.

See e.g. the "Security Considerations" section of the (expired, but presumably still useful) Internet Draft on the subject: draft-shaw-openpgp-hkp-00 - The OpenPGP HTTP Keyserver Protocol (HKP)

A much more significant data integrity concern would be the risk of being fed a carefully crafted "malware certificate" that can exploit a buffer overflow vulnerability in your gpg client, or something like that. I haven't heard of any such exploits in gpg, but they have happened for SSL: yaSSL Certificate Processing Buffer Overflow Vulnerability - CNET. This is explored more at What risks are inherent with connecting to an untrusted public key server?

Update: A more problematic concern is privacy. If you don't want people to be able to see what keys you are searching for, or to mess with your key transfers, using TLS would be an alternative. But it doesn't protect you from the server knowing what you're interested in.

@teris-riel expands on the privacy concern: Imagine someone sends you a signed then encrypted email. Your mail client happily retrieves the key for the signature. Evan is watching the traffic and sees the key fly by. Now he knows 1) that you can read messages encrypted with the key he sent to, 2) that you did read that particular message, and 3) the approximate time you read it. If this kind of confirmation attack worries you, use hkps and Tor to get keys, and don't do it automatically. parcimonie is a tool that works to solve this problem.

And as a parcimonie implementation in bash notes: gpg --refresh-keys discloses your entire list of PGP keys to the keyserver you are using, as well as whoever is wiretapping your connection if you are using an unencrypted protocol such as HKP (which is the default for most setups). That is a bad thing.

So use something like parcimonie.

---

There are some alternative protocols, but finding servers for them which contain the keys you want seems hard:

• Symantec's PGP Global Directory uses https.
• LDAP, or LDAPS (over TLS) - And see PGP LDAP Keyserver Comparison. But see also PGP: Public Key Servers by David E. Ross
• RFC 4387 which provides an https option. But I'm not sure how many servers for it there are out there.

See also

• How should I distribute my public key?
• Key Server (Wikipedia)

Answer 2

There is no point in using a secure connection to the key server, because you should not trust the key server either.

In OpenPGP (the protocol that GnuPG implements), you gain trust in a public key by virtue of that key being signed by someone whose public key you trust. This is recursive, so the idea is to get a chain of keys, each signing the next, from a key you know absolutely (basically, your key, or the key of someone you physically met and who gave you his public key at that occasion) to the key you want to use. This is a kind of Public Key Infrastructure known as Web of Trust. The "public keys signed by other people" are actually "certificates". How you obtain certificates has no influence on their security, since you will use only certificates for which you could verify the signature. Thus, they can be stored on a public server which is not assumed to be especially trustworthy, and transmitted in cleartext without protection.

Actual security in a WoT is achieved by find several (many) validating paths; a single path is not enough. This is because getting sure that key K belongs to Bob does not necessarily imply that whatever key K' signed by Bob really belongs to whoever Bob believes it does. In X.509 terminology (another PKI standard), a WoT is like "everybody is a Certification Authority". This does not work well because Bob could be gullible, or maybe prone to recklessly sign other keys after his third pint. This is mitigated by requiring an overdefined set of certificate paths, i.e. the key you want to use is signed by many different Bobs, on the assumption that making a fake key (i.e. a key with the wrong identity, but nonetheless signed by other people) would require too much effort (or too much beer) from the attacker.

On the whole, the PGP worldwide WoT does not work well. What works well is exchanging keys through any insecure medium (a key server, simple emails...) and then phoning the key holder and exchanging the "fingerprint" (which is a hash of the key). Some people include their public key fingerprint on their business card. Basically, a direct certification without going through a Bob. This is how OpenPGP gets used most of the time, and that's fine.

Answer 3

Most people seem to talk about PGP keys when they actually talk about PGP certificates. (Chapter 1 of the document Introduction to Cryptography in the PGP 6.5.1 documentation doesn't use the expression "PGP key" but "PGP certificate".)

Just like X.509 certificates, the security value of the PGP certificate is in its signature(s) and the ability of its consumer to bind the signer to an entity it knows and trusts. The main difference between X.509 and PGP certificates is that an X.509 certificate can only have one signature and issuer (hence it's part of a hierarchy), whereas PGP certificates can be regularly updated with additional signatures, asserting the binding between the public key and the identity. (As far as I know PGP certificates are always at least self-signed, which doesn't guarantee much. EDIT, thanks to @nealmcb)

Getting the certificate over a secure transport mechanism wouldn't add much (as @nealmcb said). What matters is to be able to be able to chain it back, using its signatures, possibly via intermediates, to a signer you know and trust. Of course, just like with X.509, there needs to be a "leap of faith" (or "dictated" corporate trust) when you get to the top.

If keyserver.ubuntu.com was serving its keys over TLS (assuming with an X.509 certificate), you would certainly know that the PGP certificate you were looking for hasn't been compromised between the server and you (provided you trust the issuing CA for its certificate). However, if you trust the key because of this, you would end up mixing two models: it's not because a key server hosts a PGP certificate that it makes any assertion regarding how you should trust its content. Key servers are just repositories of certificates.

Answer 4

Your danger here comes in the form of spoofing of the remote location, and this is most likely to happen via DNS which isn't helped by switching to HTTPS.

I would say that your best option here is to download regularly but manually confirm with the recipient that the key is correct.

Answer 5

Those are some long answers, so I'll try to be brief: a secure connection provides two advantages:

• Data is hidden from a 3rd party
• Data is authenticated so it cannot be changed by a 3rd party

Rarely (though possibly in some cases) is retrieval of a public cryptography key considered sensitive if exposed. It may be an issue if Eve is going to know way too much just by finding out that Alice and Bob have swapped keys, but for all basic intents we don't need to hide anything from a 3rd party so we don't need to encrypt it.

The public key you're downloading is verified by its cryptographic fingerprint which would already be exchanged in order to be secure. As authentication is built into the keys (so much as you already know the fingerprint), the an extra layer of authentication beyond that would be superfluous.

Thus, when transmitted by plaintext, GPG keys are still secure. Whether transported by SSL, private courier, or spray-pained on the side of a wall, the authentication is integral to the key and its public exposure almost never presents a risk.

Answer 6

In short: I could be tricked because it's not using HTTPS.

because: HTTP could be "rewritten" on-the-fly (MITM) and from there, the attacker could give a false GPG server to me.