In my last post on Cryptography, I referred to the Web of Trust concept which is vital to most Public Key Cryptosystems. One point I made was employers were in a unique position to assign trust, as they already have to do verification of identity before they hire their employees. This verification of identity is core to the Web of Trust.

However, what is trust? When dealing with Public Key Cryptography, we have to change our definition slightly from what we normally expect. In the Cryptographic Web of Trust, we aren't indicating that we trust a person with anything of ours personal. Signing a users key is nothing more than an indication that they are who they say they are. So, using the old Cryptography pals Alice and Bob as a demonstration, allows me to explain how this works. Alice and Bob need to communicate securely, and they both have Public/Private Key Pairs. Somehow, they will have given their public keys to one another (this will be discussed later), once Alice has verified that Bob's key is really Bob's key, and Bob's done the same for Alice, they can sign the other's public key with their personal private key, to demonstrate that they have faith that the key is valid and belongs to the person they say it belongs to.

Sounds simple enough, right? And really, this is the goal of the key-signing parties I mentioned last time. However, what if you need to send an encrypted message to someone who you've never met before? Let's take Carl, a friend of Bob. Carl needs to send a secure message to Alice for some reason, but he's never met Alice, and it's important enough that he doesn't have time to verify Alice's key himself. But he's signed Bob's key before, and Carl knows Bob well enough that he feels Bob will be a responsible key-signer, so Carl feels that Bob's signature on a key is good enough to make him feel comfortable trusting any key Bob has signed. This take us to the next stage of the Web of Trust, assigning trust values to signatures. With this, Carl can tell his key management software that he has full faith in Bob's ability (and tendency) to properly verify an identity before signing a key, and thus any key signed by Bob is just as good as if Carl himself had signed it.

This idea of key validation is the greatest challenge to the growth of a healty Public Key Crytosystem. Most people are really bad at properly verifying crypto information before they sign it, and not verifying trust on a key before they use it. Social Networking sites have shown just how problematic this would likely be. People will mark one another as 'friends' on the slightest pretext. While this tendency may not extend to signing of Public Keys, it is still a troubling trend. If people sign keys too imprudently, the value of that persons signature goes down considerably. Let's say that Alice is a person who will sign keys because she's recieved e-mail from a person claiming to be Bob. Now, it might really be Bob, it might not, but Alice signs the key after sending a few e-mails back and forth without really verifying that Bob was the real owner of the key. If Eve was claiming to be Bob, Carl might get an e-mail from Eve, see Alice's signature, and think that the Eve might actually be Bob based solely on the merit of Alice's signature.

With the challenges and education necessary to build a strong Public Key Cryptosystem, it isn't surprising that the technology hasn't really caught on. A few years ago, this was attributed to the fact that using the encryption software was too difficult. I don't believe this is true any longer, as most systems which support PGP or GPG (the most popular Public Key Cryptosystems out there, which are compatible with each other) will integrate into software that requires it (e-mail and file management mostly) in a fairly trivial manner, certainly easily enough that most users would easily be able to adapt. The problem, is in teaching users the value of signatures, and what it means in the grand scheme of the Web of Trust to sign a key. This is the great challenge, and as with most things, the challenge is not really technical one.

Thawte has taken an interesting approach to this problem. With the Thawte Web of Trust, they have built a system which uses S/MIME to sign and encrypt e-mails. Thawte's Web is built around the idea of Notaries and Trust Points. In order for a user to even be considered 'Trusted' in the Web, which allows them to assign a name to their e-mail certificate, they must acquire 50 Trust Points. This is done by meeting a Notary, in person, and getting them verify your identity. As a Notary can only give out a maximum of 35 Points, you need to meet with several notaries before you can be considered 'trusted'. In order to become a Notary, you must have recieved at least 100 Trust Points, and even then are limited in the number of trust points you can assign. This trust model is interesting, in that it takes the context of trust out of hands of individual users. You don't know who has given the key trust points, only that it has recieved the points.

Thawte's web, and S/MIME has some drawbacks that I view as pretty serious. They only work with e-mail. A PGP or GPG key can be used to sign/encrypt e-mails, or any individual file. The certificates are assigned to e-mail addresses, not people, so they aren't really applicable for Cryptographic Signatures on contracts. Again, with GPG or PGP keys with a high-degree of trust, a digital signature against the file containing the contract serves as a reasonable proof of identity of the signer, and can be used to verify the version of the file which was signed. Encryption tends to have other problems in general. E-mail clients that don't support encryption will behave strangely when presented with encrypted or signed e-mails. Web-based e-mail clients don't support encryption, as there are too many questions on how it should be supported. Malware can be hidden from scanners if wrapped up in an encrypted file.

In my opinion, the webmail issue is the greatest one. When I was the sysadmin at CB Apparel, I made an effort to move the company to IMAP from POP3, including support for web-mail. We would use transport layer encryption to protect the data during transit, but we had no public-key encryption infrastructure (nor no immediate need for it). Unfortunately, there was no existing method to implement encryption into the web mail. For that to work, the Private Key would need to be stored on the server. This actually isn't the end of the world, since any private key should be protected by a symmetric key with a good, and more importantly long, passphrase. But then the Passphrase needs to be sent across the wire to the webmail server, and the user is left to trust that their passphrase is being disposed of in a secure fashion. A very, very difficult problem, one that is still being worked through. Ideally, the encryption of the message would be done on the user's local machine, but that raises it's own issues when dealing with Web-based E-mail. Javascript is notoriously slow, and there is no way to load the encryption key from the hard disk (thankfully). As for the other issues, non-supporting e-mail clients are getting increasingly rare, and there is never a good reason why a user shouldn't have some form of local malware detection. Yes, even you Linux and Mac users. Install it now, before you get infected by a virus rushing to be the first to infect your platform.

Overall, I believe the main reason these technologies haven't been taught to the majority of users is that there isn't a percieved need in our society for high-grade encryption for the masses. I once had a professor who felt that citizen should be issued encryption keys, which would be verified and signed by the government. An interesting ideal, and it could lead to the large scale adoption of encryption technology, if the government hadn't attempted to force the integration of technologies that would limit the effectiveness of cryptopgraphy. I fully believe the need for high-grade encryption is out there, and is more and more important in our increasingly digital world. Until that need is percieved by masses, it won't happen. Next time, I'll be posting about the Key Distribution problem. The issues we've encountered with it, and how we're working to solve them.