0

What prevents someone from intercepting most/all of my communication and forge a certificate?
Even if I wish to get certificates from a key server, a man-in-the-middle can intercept my request and send me a forged certificates.
When I wish to download a software image from a mirror and authenticate that software with the keys and signature provided in the software's original website, how can I be sure that I'm downloading the keys and signature that the website provided? Maybe someone intercepted those downloads and sent my a forged signature and keys.
That's problematic for people who live in a dictatorial state, because their government could do that easily.

1

2 Answers 2

2

Man in the middle (MITM) attacks are probably the most viable means of defeating public key cryptosystems. You can thwart a MITM by verifying certificates with information from an independent second channel. Unfortunately, such verification is not always easy, or foolproof.

In the case of systems having no central certifying authorities (like PGP/GnuPG), the second channel should be a telephone conversation or (even better) a face-to-face meeting. During that conversation, the certificate holder proves his/her identity to you, and also proves that you are holding an exact copy of his/her public key certificate. The latter is typically proven by verifying that the fingerprint (a cryptographically strong hash) of the cert you are holding matches the fingerprint of the owner's cert (which he/she would read out to you).

Since such rigorous verification is often burdensome or infeasible, PGP also provides for something called the web of trust. In brief: People sign the keys they strongly believe to be authentic (hopefully after having personally verified them, as previously described), and they distribute those keys far and wide. Then, if I receive a key that was signed by someone I trust (i.e. by someone within my web of trust), I can be confident that the key is genuine.

If, on the other hand, I receive a key cert with no trusted signatures, and it is difficult or impossible for me to personally verify the cert with its owner, then I am in an uncertain position. Should I trust this key or not? The answer will depend on a number of factors, including: where I got the key from, and what I am using the key for. The decision may not be an easy one. For instance, I would view with some suspicion any website that provides both a signature and the cert needed to verify that same signature, since that pair of files could have been put there by anyone. I would have slightly more confidence in a signature and a cert if I obtained them from two separate, independent locations (like from a website and a public keyserver, respectively).

In systems with Certificate Authorities (CA) acting as trusted third parties (like the one used on the web to authenticate SSL/TLS host certs), the independent second channel used for verification is the store of CA public key certs on your local PC. It is presumed that your PC's local CA key store is initialized and updated only by trusted means, so that you have a (hopefully) high level of confidence that the CAs and keys in there are genuine. (Note that you are also trusting that all those CAs in your key store are actually trustworthy. Whether or not that confidence is well founded is a discussion for another day.)

When a web site presents its host cert to your browser during SSL/TLS connection setup, the browser checks whether the cert was signed by a CA in your PC's local CA store. [For simplicity, I am ignoring certificate chaining, which adds nothing to this discusson.] For a MITM to successfully spoof an SSL-authenticated website to your browser, he would have to get his fake host cert signed by one of the CAs in your local CA store. There are a couple of ways that could happen. If some malware has meddled with your local CA store, then your browser could be tricked by a fake cert signed by a fake CA. Alternatively, if a legitimate CA (like Verisign or Thawte) is tricked into signing a fake cert, then your browser will accept it as real, and there is not much you can do about it. You could try removing from your CA store all those CAs that are known to have signed bad certs, but then your browser would begin rejecting all the completely valid certs signed by those CAs. Not good.

In summary, a MITM can succeed only if the key/cert verification process is subverted. Unfortunately, it is often either too difficult to rigorously verify a cert (in the case of PGP/GnuPG), or the process can be poisoned by various means (in the case of trusted third party systems).

2
  • BTW, (browsers related) the local CA store is filled when installing the browser (i.e. in the executable that's downloaded from the website), right? If so, we're back to the interception problem :)
    – Dor
    Nov 29, 2010 at 19:43
  • @Dor: absolutely, unless you managed to verify the original download or buy a cd in a shop etc... It does allow us to chain some of the security though. If you have an OS in place, and download a new browser through https, ignoring the weaknesses in https, in order to corrupt your future CA store, an attacker should also have corrupted your former one.
    – user68729
    Jan 29, 2011 at 21:04
1

This is why web browsers make such a big deal about self-signed SSL certificates. Browsers contain the public keys for (hopefully) trusted certificate authorities, and if the certificate you accept is signed by one of those, you can be reasonably certain it wasn't forged.

For PGP, there is no such centralized system, but there is the web of trust system. There's still the problem of initial exchange, which is why people who are really into PGP get all excited about key-signing sessions. You're right, though, that this is difficult under an authoritarian state.

1
  • +1. Nice for mentioning the key-signing sessions :)
    – Dor
    Nov 29, 2010 at 19:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .