Last week we took a look at how public key encryption systems work, and how anyone can send you an encrypted message—which only you can read—if they have access to your public key. It turns out that the process of getting your public key to people who need to use it is a complex task that involves a combination of trust, third parties, and various other factors which together are known as public key infrastructure.
On the face of it, giving people access to your public key shouldn’t be much of a problem. You could make it available for download on your Web site, you could distribute it on a memory stick, or you could simply e-mail it to people.
But in practice there is a big problem with that. Here’s the thing: if someone wants to send a message that only you can read, they need to use your public key to encrypt their message. But if they use a key that they think belongs to you but actually belongs to someone else (call them Mallory) then you won’t be able to read the message, and Mallory will. So if Mallory wants to read confidential messages intended for you, all he has to do is replace your public key with his on your Web site, or on a memory stick you’ve distributed, or in emails that he sends out purporting to come from you, and if he can then intercept any messages bound for your encrypted with this bogus key he will be able to read them.
Of course you would realize something was up when you discovered that using your private key you couldn’t decrypt and read the messages you received (because they have been encrypted with Mallory’s public key, not your public key). But if Mallory were smart he would re-encrypt the messages intended for you after he had read them with your real public key and send them on. In that case you wouldn’t know that anything was amiss. Mallory would have carried out a “man in the middle” attack.
So how can this problem be overcome? How can you distribute your public key to someone in such a way that anyone who receives it can be sure that it really is your key, and not, for example, Mallory’s? And how can you be sure that any public keys you get hold of really do belong to the people that you think that they do? The answer is to get any public key vouched for by a trusted third party, and that’s where PKI comes in.
Imagine that there’s someone in the community—call him Solomon—that everyone trusts as an upstanding and trustworthy citizen. You take your public key in person to Solomon, who checks who you say you are (perhaps by checking your drivers’ license or passport.). He then signs a certificate which he attaches to the key that says that he, Solomon, can personally vouch for the fact that the attached key belongs to you.
In the digital world Solomon would effectively encrypt your public key along with a certificate saying “I certify that this public key belongs to X” using his private key. Anyone receiving this could only decrypt it using Solomon’s public key, and what they would find is your key, plus the message saying that it is indeed your key. Since only Solomon could have created the message, and since the message and the key could not have been altered in any way (because they were both encrypted and thus tamper-proof) then the they could be sure that the key was indeed your key – as long as they trusted Solomon to tell the truth, and as long as they could be sure that the key that they believe to be Solomon’s public key is in fact his. (In practice the procedure is slightly different in that it uses something called a hashing function, but the principal is exactly the same.)
But surely this just pushes the problem back one stage? The person receiving your key can be sure that it is genuinely yours only if they can be sure that the copy of Solomon’s public key that they have is genuine. But how can they know that it is?
One answer in the real world is to have a limited number of trusted third parties (or Solomons), known as certification authorities or “CAs,” who issue certificates, and for the public keys for these CAs, known as root certificates, to be pre-installed in software packages (such as Microsoft’s Internet Explorer.) This means that as long as a public key that you receive is signed by a CA that you have a root certificate for, then you can be sure that the public key belongs to the person it says that it does—if you are sure that the pre-installed root certificate you have is genuine and you deem the CA to be trustworthy.
If the root certificate was included with a software package, then you have to decide whether you trust the maker of the software to have included a genuine root certificate or not. Likewise, you can look at the details of any CA and decide whether you trust them. Microsoft includes root certificates for CAs as diverse as commercial US entities such as Visa and RSA (which you may well know and trust), as well as more obscure overseas ones such as the Uruguayan Administracion National de Correos and the Government of Slovenia’s General Certification Authority (which you may well know nothing about and therefore have no reason to trust beyond the fact that they sound vaguely official—which is a tenuous reason to trust any organization). Ultimately it’s up to you which software makers and CAs you chose to trust and which you don’t.
There’s another way that you can get reassurance that a public key you get hold of is genuine without having to place your trust in certificate authorities and root certificates, and that’s known as a web of trust. In this model, you meet face to face with people you know, and get them to sign your public key with their private key confirming that your public key is really yours. The more people you can get to sign your key the better, so this is often done at a “signing party” where a number of people meet face to face.
The principal then is this: imagine that you get a public key which you think belongs to Carol, but you can’t be sure, because you didn’t get it directly from her. When you get it, you might see that it has been signed as genuine by Bill. If you know Bill and have a copy of his public key that you got from him when you met him face to face, you can easily decide that the key does belong to Carol, because Bill says so and you trust him. Of course the filament of trust could be longer: Carol’s key could have been signed by Ben, who you don’t know, but Ben’s key could have been confirmed by Bill, who you do know. The more people you trust who confirm that the key is genuine, either directly or indirectly, the better. Webs of trust are good for small networks of people who mostly know each other, but aren’t suitable for very large groups with a high proportion of people you don’t know.
The important point to remember in the end is that although public key ciphers are extremely secure —as far as we know—public key infrastructure relies on an element of trust: You can only use a public key belonging to someone you don’t know if you can trust that it belongs to the person that you think it does. This means thinking carefully about the CAs or web of trust members that you deal with, and seeking alternatives if you can’t be sure enough that they are reliable.
Over the next few weeks we’ll be looking at how public key cryptography and public key infrastructures come together in both commercial and open-source products which offer secure email communications.
