aaron-kelley.net :: E-mail Security / thawte Web of Trust
E-mail Security / thawte Web of Trust
(under construction)
Maybe you're here because you received a signed e-mail from me, that was either correctly identified by your e-mail software, or was confusing because of the "smime.p7f" attachment that seemed to be there for no reason (this actually indicates that your e-mail software does not know how to recognize digital signatures). Or, maybe you're here because you found the link on my web site, or because you were Googling for information on the subject and this page popped up. Read on for more information about digital e-mail signing.
- Introduction
- Public/Private Key Cryptography, Digital Certificates
- Pros / Cons
- thawte Web of Trust
- Implications / Conclusion
(back to top)
For electronic communications, e-mail is one of the most prevalent methods of communication. So many people use it, yet it is astounding how broken the system is.
Perhaps the most obvious problem is spam. Everyone who uses e-mail knows about it. If your e-mail address gets out, you use your e-mail address to sign up for anything, or you just have a common name like "John Smith," chances are you will begin to receive spam at your e-mail account.
There's also the problem that it is difficult to tell where e-mail came from. Sure, you can look in the Internet headers to get an idea, but most people have no idea that means or how to interpret the information found there. And because it says it's from "service@paypal.com," it must be an important message, you should click on the link and type in your credit card information, right? What would your great aunt, who doesn't know much about this computer stuff, do if she got an e-mail like that? It is easy to forge e-mail from any address, anyone can do it with no fancy equipment or anything.
You'd think that in all of our technologicaly advanced-ness, we'd have come up with a way to deal with these problems.
Obviously, we can't just switch to a new, "more secure" system. It would cost a lot of time and money to develop, deploy, and get people to switch, and it would lead to a time where users of the two systems couldn't communicate or some mechanism to allow communication between the old e-mail and the new e-mail (which seems like it would be hard to pull off without flooding the new system with spam). There are ongoing attempts to fight this problem; SPF records for your domain, RBL databases of known spamming IP addresses, research into junk mail recognition which leads to "anti-spam" software and junk mail filtering (that often identifies good mail as junk as often as it identifies junk mail as good), and so on.
Are there any other solutions out there, maybe, something you can do to help fix our e-mail problem?
The purpose of this document is to introduce the idea of using digital certificates to authenticate e-mail (specifically, using X.509). Not that this was my idea, or that I am introducing it for the first time; rather, to introduce the idea to people who perhaps haven't heard of this before, and who aren't nerds who really think about this kind of thing all the time.
For electronic communications, e-mail is one of the most prevalent methods of communication. So many people use it, yet it is astounding how broken the system is.
Perhaps the most obvious problem is spam. Everyone who uses e-mail knows about it. If your e-mail address gets out, you use your e-mail address to sign up for anything, or you just have a common name like "John Smith," chances are you will begin to receive spam at your e-mail account.
There's also the problem that it is difficult to tell where e-mail came from. Sure, you can look in the Internet headers to get an idea, but most people have no idea that means or how to interpret the information found there. And because it says it's from "service@paypal.com," it must be an important message, you should click on the link and type in your credit card information, right? What would your great aunt, who doesn't know much about this computer stuff, do if she got an e-mail like that? It is easy to forge e-mail from any address, anyone can do it with no fancy equipment or anything.
You'd think that in all of our technologicaly advanced-ness, we'd have come up with a way to deal with these problems.
Obviously, we can't just switch to a new, "more secure" system. It would cost a lot of time and money to develop, deploy, and get people to switch, and it would lead to a time where users of the two systems couldn't communicate or some mechanism to allow communication between the old e-mail and the new e-mail (which seems like it would be hard to pull off without flooding the new system with spam). There are ongoing attempts to fight this problem; SPF records for your domain, RBL databases of known spamming IP addresses, research into junk mail recognition which leads to "anti-spam" software and junk mail filtering (that often identifies good mail as junk as often as it identifies junk mail as good), and so on.
Are there any other solutions out there, maybe, something you can do to help fix our e-mail problem?
The purpose of this document is to introduce the idea of using digital certificates to authenticate e-mail (specifically, using X.509). Not that this was my idea, or that I am introducing it for the first time; rather, to introduce the idea to people who perhaps haven't heard of this before, and who aren't nerds who really think about this kind of thing all the time.
(back to top)
I will first give a brief introduction to public/private key cryptography. This is the mechanism by which we authenticate messages; that is, given a message, we can tell whether or not it is really from who it says it is. (This is a little technical, if you don't care to know how it works, you can skip this section.)
I want to send a message. I want whoever to receives it to be able to verify that the message is from me, not from just whoever wanted to send a message and stick my name on this. How do we accomplish this with a computer?
We could say that, in our network of people who want to be able to communicate with each other, everyone has a public key and a private key. A key in this sense is nothing more than a large number. You keep the private key secret, and share the public key with everyone.
These keys can be used to encrypt and decrypt messages. Messages encrypted with someone's private key can only be decrypted with the corresponding public key. Likewise, messages encrypted with someone's public key can only be decrypted with the corresponding private key.
One of the obvious ways to use this is to send a message that only the intended recipient can read. If I want to send a message to Bob, I take my message, encrypt it with Bob's public key (which he gladly shares with me), and send the encrypted message to him. Bob, being the only person who knows his private key, is the only person who can use it to decrypt the message.
However, private communication is nice, but it's not what we're after here. So let's do it a little backwards.
I have a message, and I want whoever receives it to know that it came from me. So, I encrypt the message with my private key. This means that it can only be decrypted with my public key. Since I share my public key with everyone, anyone can decrypt the message; however, because decryption with the public key was successful, it must have been encrypted with my private key, that only I know. Thus, I must have been the one who sent the message.
Instead of encrypting the whole message, generally we take a hash or fingerprint of the message and encrypt that with our private key, because it is computationally cheaper. This encrypted fingerprint is the signature; by including the encrypted fingerprint with the message, we are signing the message. The message can still be authenticated; the receiver simply takes the message, generates the fingerprint using the same method, and checks to see if it matches the fingerprint received with the message, after decrypting it with our public key.
Obviously, I left out all of the math that makes this work; if you want to know more about that, you can read about RSA. It is important that the mathematical methods that we use to pull this off not be suceptable to attack, that is, it is extremely difficult to fake valid messages.
So, here we have a mechanism for authenticating messages. There's still a problem, though. Obviously, we have to have some way to electronically exchange public keys. If I receive Bob's public key, how do I know that it really came from Bob? If we don't have some mechanism for trusting or distrusting keys, then the system has only become more complicated but not added anything else.
We have some trusted authorities. Trusted authorities also have a public and private key for themselves. Everyone knows their public key, and for our purposes we will assume that these are distributed in some secure, out-of-band way.
When someone new joins the messaging system, they need a public and private key for themselves. They request these from a trusted authority. The authority assigns a public and private key to the new person, and also gives them what we call a certificate, which contains their public key signed by the authority (using their private key). The new person may then include the certificate with outgoing messages; it contains their public key and other people can verify that it was assigned by the authority just like they check any other message.
We call these trusted authorities certificate authorities, or CAs.
When using this with e-mail, typically you will request a certificate from a CA. They will send you an e-mail, which contains a number you must enter or a link you must click on to verify that you are actually the person in charge of that e-mail account. After this, you can download the certificate to your computer and use it to sign mail.
(A disclaimer here, for those of you who already know a lot about this; I know that I simplified things in this section a bit, but it should be enough to get the general idea across.)
I will first give a brief introduction to public/private key cryptography. This is the mechanism by which we authenticate messages; that is, given a message, we can tell whether or not it is really from who it says it is. (This is a little technical, if you don't care to know how it works, you can skip this section.)
I want to send a message. I want whoever to receives it to be able to verify that the message is from me, not from just whoever wanted to send a message and stick my name on this. How do we accomplish this with a computer?
We could say that, in our network of people who want to be able to communicate with each other, everyone has a public key and a private key. A key in this sense is nothing more than a large number. You keep the private key secret, and share the public key with everyone.
These keys can be used to encrypt and decrypt messages. Messages encrypted with someone's private key can only be decrypted with the corresponding public key. Likewise, messages encrypted with someone's public key can only be decrypted with the corresponding private key.
One of the obvious ways to use this is to send a message that only the intended recipient can read. If I want to send a message to Bob, I take my message, encrypt it with Bob's public key (which he gladly shares with me), and send the encrypted message to him. Bob, being the only person who knows his private key, is the only person who can use it to decrypt the message.
However, private communication is nice, but it's not what we're after here. So let's do it a little backwards.
I have a message, and I want whoever receives it to know that it came from me. So, I encrypt the message with my private key. This means that it can only be decrypted with my public key. Since I share my public key with everyone, anyone can decrypt the message; however, because decryption with the public key was successful, it must have been encrypted with my private key, that only I know. Thus, I must have been the one who sent the message.
Instead of encrypting the whole message, generally we take a hash or fingerprint of the message and encrypt that with our private key, because it is computationally cheaper. This encrypted fingerprint is the signature; by including the encrypted fingerprint with the message, we are signing the message. The message can still be authenticated; the receiver simply takes the message, generates the fingerprint using the same method, and checks to see if it matches the fingerprint received with the message, after decrypting it with our public key.
Obviously, I left out all of the math that makes this work; if you want to know more about that, you can read about RSA. It is important that the mathematical methods that we use to pull this off not be suceptable to attack, that is, it is extremely difficult to fake valid messages.
So, here we have a mechanism for authenticating messages. There's still a problem, though. Obviously, we have to have some way to electronically exchange public keys. If I receive Bob's public key, how do I know that it really came from Bob? If we don't have some mechanism for trusting or distrusting keys, then the system has only become more complicated but not added anything else.
We have some trusted authorities. Trusted authorities also have a public and private key for themselves. Everyone knows their public key, and for our purposes we will assume that these are distributed in some secure, out-of-band way.
When someone new joins the messaging system, they need a public and private key for themselves. They request these from a trusted authority. The authority assigns a public and private key to the new person, and also gives them what we call a certificate, which contains their public key signed by the authority (using their private key). The new person may then include the certificate with outgoing messages; it contains their public key and other people can verify that it was assigned by the authority just like they check any other message.
We call these trusted authorities certificate authorities, or CAs.
When using this with e-mail, typically you will request a certificate from a CA. They will send you an e-mail, which contains a number you must enter or a link you must click on to verify that you are actually the person in charge of that e-mail account. After this, you can download the certificate to your computer and use it to sign mail.
(A disclaimer here, for those of you who already know a lot about this; I know that I simplified things in this section a bit, but it should be enough to get the general idea across.)
(back to top)
Before I go on, let me outline some of the positives and negatives to jumping in and using digital e-mail signatures.
The positives, I have really already discussed. E-mail that other people receive from you will be authenticated; they will know that it really came from the person to whom the e-mail address it says it is from belongs. Also, if your name is included in the certificate, then they will know that it came from you. For more positives, see the "Implications" section below.
Your certificate will be stored on your computer. You must use an e-mail client to send mail; to my knowledge, no web mail provider supports sending signed mail. (You can send signed mail through Outlook Web Access.) This means that if you are used to using a web browser and going to a web site to check your e-mail (through Hotmail, Yahoo!, Gmail, etc.), you'll either have to stop doing that, or just go ahead and send those messages unsigned. Fortunately, most web mail providers now allow you to use a regular e-mail client to check your mail; Gmail supports both POP and IMAP which allows you to use virtually any mail client, Microsoft offers a free connector to allow you to use your Hotmail account from Microsoft Office Outlook (and will also offer free POP access for everyone in the near future), and Yahoo! allows POP access for paid subscribers.
All that being said, I personally prefer using a regular e-mail client as opposed to web mail; there are many other advantages, and if you are not used to it, I suggest that you consider giving it a try. I use Microsoft Office Outlook, but Mozilla Thunderbird is also a good free choice and Evolution is a fantastic client for Linux.
Because your certificate and keys are stored on your machine, if they are compromised (for example, some malware on your machine steals them), then the compromiser will be able to send e-mail under your identity. Depending on what software you use, there may be some safeguards in place against this; for example, Windows Vista makes you click to confirm every time some software needs access to your private key. However, if you become aware of this, you may contact whoever issued your certificate and have it revoked.
Also, certificates typically expire after a year or two years, so this will require some awareness on your part; when your certificate is near its expiration date, you will need to get a new one from the CA.
Before I go on, let me outline some of the positives and negatives to jumping in and using digital e-mail signatures.
The positives, I have really already discussed. E-mail that other people receive from you will be authenticated; they will know that it really came from the person to whom the e-mail address it says it is from belongs. Also, if your name is included in the certificate, then they will know that it came from you. For more positives, see the "Implications" section below.
Your certificate will be stored on your computer. You must use an e-mail client to send mail; to my knowledge, no web mail provider supports sending signed mail. (You can send signed mail through Outlook Web Access.) This means that if you are used to using a web browser and going to a web site to check your e-mail (through Hotmail, Yahoo!, Gmail, etc.), you'll either have to stop doing that, or just go ahead and send those messages unsigned. Fortunately, most web mail providers now allow you to use a regular e-mail client to check your mail; Gmail supports both POP and IMAP which allows you to use virtually any mail client, Microsoft offers a free connector to allow you to use your Hotmail account from Microsoft Office Outlook (and will also offer free POP access for everyone in the near future), and Yahoo! allows POP access for paid subscribers.
All that being said, I personally prefer using a regular e-mail client as opposed to web mail; there are many other advantages, and if you are not used to it, I suggest that you consider giving it a try. I use Microsoft Office Outlook, but Mozilla Thunderbird is also a good free choice and Evolution is a fantastic client for Linux.
Because your certificate and keys are stored on your machine, if they are compromised (for example, some malware on your machine steals them), then the compromiser will be able to send e-mail under your identity. Depending on what software you use, there may be some safeguards in place against this; for example, Windows Vista makes you click to confirm every time some software needs access to your private key. However, if you become aware of this, you may contact whoever issued your certificate and have it revoked.
Also, certificates typically expire after a year or two years, so this will require some awareness on your part; when your certificate is near its expiration date, you will need to get a new one from the CA.
(back to top)
Alright, so, how do you go about getting a digital certificate that you can use to sign e-mail, that will be trusted by other people? They can be purchased from a number of sources, perhaps most notably Verisign. Would you pay $20 per year for your e-mail, if it meant there would be no spam? I would, I suppose. However, we're not there yet, and fortunately, there's a free alternative.
thawte hands out free certificates through their web of trust program. You can get your certificate for free. The free certificate certifies that mail you send came from the person who is in control of the e-mail address that it is from, but it does not tie the mail to your personal identity. For this, you must participate in the web of trust and get your identity trusted.
Here's how that works. There are thawte web of trust notaries. These are people who can assert that you are who you say you are. You visit a notary, taking with you some pieces of identification (driver's license, passport), the notary verifies that you are who you say you are and you are a real person, and then they credit some points to you thawte web of trust account. After you accumulate 50 points, you can include your name in your e-mail certificates. And after you reach 100 points, you may become a notary and assert trust for other people. The number of points a notary can credit ranges from 10 to 35, and it increases as they notarize more people.
You can obtain certificates for any number of e-mail addresses using only one thawte account (although you must verify each one of them), so you do not have to be notarized multiple times if you have multiple e-mail accounts that you want to send signed mail from.
This somewhat offsets the responsibility of verifying people's identities from the CA to everyone.
I have chosen to participate in the thawte web of trust and encourage other people to do so as well. Carl and I are both trying to get the ball rolling on this at Baylor, and both of us would be glad to notarize you if you live in the area and decide to join.
thawte is not the only place to go to get a certificate, however. There are plenty of other CAs. There are even other "webs of trust," perhaps most notably the PGP web of trust, however, this operates using PGP certificates (instead of X.509 certificates) so it is not as widely supported among e-mail client software.
Alright, so, how do you go about getting a digital certificate that you can use to sign e-mail, that will be trusted by other people? They can be purchased from a number of sources, perhaps most notably Verisign. Would you pay $20 per year for your e-mail, if it meant there would be no spam? I would, I suppose. However, we're not there yet, and fortunately, there's a free alternative.
thawte hands out free certificates through their web of trust program. You can get your certificate for free. The free certificate certifies that mail you send came from the person who is in control of the e-mail address that it is from, but it does not tie the mail to your personal identity. For this, you must participate in the web of trust and get your identity trusted.
Here's how that works. There are thawte web of trust notaries. These are people who can assert that you are who you say you are. You visit a notary, taking with you some pieces of identification (driver's license, passport), the notary verifies that you are who you say you are and you are a real person, and then they credit some points to you thawte web of trust account. After you accumulate 50 points, you can include your name in your e-mail certificates. And after you reach 100 points, you may become a notary and assert trust for other people. The number of points a notary can credit ranges from 10 to 35, and it increases as they notarize more people.
You can obtain certificates for any number of e-mail addresses using only one thawte account (although you must verify each one of them), so you do not have to be notarized multiple times if you have multiple e-mail accounts that you want to send signed mail from.
This somewhat offsets the responsibility of verifying people's identities from the CA to everyone.
I have chosen to participate in the thawte web of trust and encourage other people to do so as well. Carl and I are both trying to get the ball rolling on this at Baylor, and both of us would be glad to notarize you if you live in the area and decide to join.
thawte is not the only place to go to get a certificate, however. There are plenty of other CAs. There are even other "webs of trust," perhaps most notably the PGP web of trust, however, this operates using PGP certificates (instead of X.509 certificates) so it is not as widely supported among e-mail client software.
(back to top)
Imagine a world where most everyone digitally signs their mail. This means that for every piece of signed mail you received, someone jumped through the hoops to get a certificate from the CA. Unsigned mail could be discarded as junk. Every piece of mail can be traced to an individual or a company. If someone abused their certificate by using it to send unsolicited e-mail or for some scam, their certificate could be revoked. They could even be fined or legally charged.
Would this solve the problems we have with e-mail today? It seems like it. However, I cannot let go of the idea that new problems would arise... Scammers would surely resort to trying to compromise other people's private keys, perhaps by tricking them into installing some junk software on their machine, and then use the compromised keys to send e-mail under their identity. It also places a lot of power in the hands of the CAs, which may be worrisome to some.
Thank you for reading this. If you have any suggestions as to how I could improve this document (which is still under construction at this time, but I figured I'd go ahead and post it), or if you have any questions on getting this set up yourself, please don't hesitate to send me an e-mail.
Imagine a world where most everyone digitally signs their mail. This means that for every piece of signed mail you received, someone jumped through the hoops to get a certificate from the CA. Unsigned mail could be discarded as junk. Every piece of mail can be traced to an individual or a company. If someone abused their certificate by using it to send unsolicited e-mail or for some scam, their certificate could be revoked. They could even be fined or legally charged.
Would this solve the problems we have with e-mail today? It seems like it. However, I cannot let go of the idea that new problems would arise... Scammers would surely resort to trying to compromise other people's private keys, perhaps by tricking them into installing some junk software on their machine, and then use the compromised keys to send e-mail under their identity. It also places a lot of power in the hands of the CAs, which may be worrisome to some.
Thank you for reading this. If you have any suggestions as to how I could improve this document (which is still under construction at this time, but I figured I'd go ahead and post it), or if you have any questions on getting this set up yourself, please don't hesitate to send me an e-mail.
Unless another source is given or a different copyright is cited,
contents of this site are © 2004-2008 Aaron Kelley.
contents of this site are © 2004-2008 Aaron Kelley.