Imagine Eve taking over the keyserver both Alice and Bob are using.

By replacing Alice and Bob's public keys with her own, she can do a man-in-the-middle attack decrypting messages and relaying them re-encrypted with the original keys.

Even if Alice and Bob sign their messages (by encrypting a hash with their private keys), Eve could just replace the signature with her own, as Alice and Bob only have falsified public keys to verify the signature.

Even if Alice's and Bob's public keys are signed by other users, Eve can also sign her fake key with a lot of other fake users. To verify the key signatures, Alice and Bob again have to rely on the keyserver to supply the public keys to verify these signatures.

The only way to verify that the signed public keys are genuine is to follow the chain of trust back to Alice and Bob themselves, as Eve can't forge their signature. But for one, the chain of trust might not even reach Alice and Bob and, more severe, even to verify their OWN signature, they need to have access to their own untampered public keys, which would make having them around locally just as important as the private key.

This fact is not mentioned in usual PGP manuals, the public key is not protected by a passphrase and it might even be overwritten by an 'update' from the rogue keyserver.

Where am I wrong in my assumptions? What measures are in place to prevent this? Does the 'verify signature' function of GnuPG indeed follow the chain of trust back to the own private key, or does it just check the first level of signatures with public keys from the keyserver?

Update: I've already found "Shouldn't GPG key fetching use a secure connection?" and "Is connection to keyserver encrypted?". Both state, in short, that the complete PGP system is useless UNLESS you can find one (or better more) path(s) from your own (or another ultimately trusted) key to the sender. But still they don't mention that this ultimately boils down to the integrity of your locally copy of your own (or other ultimately trusted) public key. So the question remains: is this enforced and checked by GnuPG?

  • Chaos welcome to Information Security, and thanks for this great question! – AviD Aug 21 '13 at 9:40
  • 1
    Have you read the answer to this question: security.stackexchange.com/questions/40549/… ? – Stephane Aug 21 '13 at 12:39
  • @Stephane I take from the answer linked that "subpackets only get added and are not ordered, thus no conflicts can occur". Thus a local public key is never overwritten, but a false key will be added. Given that 'trust' in a key is only stored locally and not automatically set to added sub-keys, I imagine a signature verification will not come out positive because of a fake public key then. – Chaos_99 Aug 21 '13 at 12:52
  • The answer explains that, basically, the key servers are not there to vouch for anything. They are just a convenient repository of public keys. the authenticity of a specific pubic key must be validated by some other means and then YOU need to sign the known valid key. That's why PGP security is hard to scale: it works if you have a previous secure link between participants only. The only other solution is to use 3rd part authorities to vouch for people's key: that's the public PKI used by S/MIME (which has its own problems) – Stephane Aug 21 '13 at 13:21

Ultimately it is chain of "trust" for a reason. At some point you have to trust, either a web of trust based on individual certificates that you have verified or by trusting some third party to be reliable. If you trust the wrong party, everything breaks down. Trust isn't a magic cure-all, it's just a way to evaluate how much trust you've placed in something based on decisions you've made about who to trust.

Keep in mind that you CAN validate a public key from your private key to ensure it matches. If you encrypt something with your private key, it should decrypt with the public key. If it doesn't, it isn't your public key.

Also keep in mind that it is still possible to contact someone directly to give a thumbprint of the public certificate to ensure it was unaltered and it is also possible to use a key from a local store once it is obtained. This greatly limits what Eve can do as she can only attack the first key exchange and can't easily compromise the secondary verification of a thumbprint between the two parties via another channel without a pretty sophisticated attack. This secondary secure channel verification should be done on any keys that don't already have trust (through signing or other secure mechanisms) to ensure the public keys have not been tampered with.

The real take away should be to understand that giving any key server or individual in a web of trust your trust means that you must actually trust them. If you don't trust your security to them, then either don't trust them or take alternate measures to ensure that what you get from them is valid.

  • Is the validation of your public key as you describe it done automatically by GnuPG at any time? – Chaos_99 Aug 23 '13 at 9:30
  • Reading you answer over and over I realize it's almost all there. You're just missing the last consequence, which is that you are not only able to, but MUST acquire (or verify) any public key you want to put trust on via a secure side channel, as otherwise you can't be sure that you put that trust on the right key (as you can't validate their signatures without having trusted keys first). Add this and I accept your answer as right. – Chaos_99 Aug 23 '13 at 9:55
  • @Chaos_99 - the entire point of a web of trust is that you DON'T have to explicitly obtain and trust every public key (or more accurately every certificate, as the certificate includes the signatures where as the public key is just the key itself). If I get Bob's certificate through a secure channel and I trust Bob to verify people, then Bob can get Charlie's certificate through a secure channel, sign it and now I can trust Charlie's certificate even though I got it through an insecure channel, because I know that Bob verified it already. The same goes for trusting CAs. – AJ Henderson Aug 23 '13 at 13:12
  • As far as the behavior of GnuPG, I do not know if it does this or not, but it wouldn't be hard to do manually. Just sign something and then use the public key to verify the signature. – AJ Henderson Aug 23 '13 at 13:17
  • You are right. But as you have rightly stated, I NEED to get Bob's certificate via a secure channel, or otherwise I couldn't verify that Charlie's certificate was indeed signed by Bob. So to correct myself: I need to obtain every certificate through a secure side channel that I want use as first link in the chain of trust. – Chaos_99 Aug 23 '13 at 13:28

A PGP key server is just a big wall where anybody can glue some piece of paper, to the view of all people who happen to walk along the wall. Nobody actually trusts the wall for providing any kind of assertion about the truthfulness of what is written on the papers; that's just a wall, an archetype of mindlessness.

A PGP public key might be trusted, or not, depending on the signatures by other key bearers that you will find on that key. This is the Web of Trust, the kind of PKI that PGP uses. Signatures are completely independent of how the signed data was stored and transferred, and that's the whole point: nothing in this system relies on the key servers to enforce any security property at any point; and, similarly, signed keys can be sent over emails, phone lines or even avian carriers: it does not matter.

The worst a rogue key server can do is to cease to do its job, e.g. by deleting some of the keys is contains. It won't have much impact, except that it would make it more difficult for people who do not know each other, and yet want to send emails to each other, to build chains of signed keys and gain some trust in their respective public keys.

  • You said "A PGP public key might be trusted, or not, depending on the signatures by other key bearers that you will find on that key." The question was: how can I decide, if the signatures might be all faked? – Chaos_99 Aug 23 '13 at 9:46
  • See the "Web of Trust". You verify a signature on something relatively to a known public key. You have to start with a known public key, i.e. yours. Each verified signature on a public key then gives you some kind of guarantee on the veracity of that key, allowing you to proceed. – Tom Leek Aug 23 '13 at 11:55
  • See my comment on AJs answer. If you need follow the chain of trust back to your key, you would have to have signed at least one other key in the past (or else there would be no chain). For signing this key, you would had to obtain it. But if you can't trust the keyserver to deliver the right key, you MUST have gotten the key to sign via another (secure) channel. – Chaos_99 Aug 23 '13 at 12:02
  • 1
    @Chaos_99 - you don't trust someone named Bob, you trust a public key that you obtained from Bob via a mechanism you trust. You store that key in a place on your system configured as a trusted root. Yes, you have to obtain it securely, but it doesn't have to be traced back to your key, it can be traced back to Bob's key which you hold the public key for. Names on keys are more or less just for human readability and the ability to look up which key to try to verify against (so you don't have to try them all.) – AJ Henderson Aug 23 '13 at 13:47
  • 2
    @Chaos_99: that's the whole point: you do not sign keys which you obtain from key servers. You sign only keys that you could verify to belong to the designated owner through "some other way" (namely, you met the guy in person). Key servers are there just to propagate the results (signed keys), but not to bootstrap the system. – Tom Leek Aug 23 '13 at 14:02

Your Answer

