| Document Sections |
| Background |
| Apply for a Certificate |
| Install Your Certificate |
| Configure Your Client |
| Backup Your Certificate |
| Renew Your Certificate |
| Technical Details |
| Links |
Chances are good that you are using an email client that supports digital signing of email using the S/MIME standards. We think that anything that adds accountability to email is a good thing, so we spent a little bit of time writing up this document to tell you how to do it using common email client software and cost-free certificates from several vendors. We don't assume that you know anything in particular except how to use a web browser and your own email client.
The network protocols that are used to transport email were designed for a kinder, gentler internet than the one we are using today. In particular, there is no built-in support for proving who sent an email. Email headers tell us who claims to have sent an email, but not necessarily who did send an email, a recognized weakness in email infratructure. And that weakness is routinely exploited to conceal the identity of the punk who sent your pre-teen daughter fifty solicitations a day to visit his porn site. But you knew this already.
Hopefully, it's noon on the day of spam. Some people think that afternoon won't even start until all the did send and claimed to have sent of non-spam email is always the same. For that, we need digital signing of email-- cryptographic techniques and standards (called "S/MIME") that have been around for many years and which are now supported by all modern GUI email clients. The S/MIME standard allows a user to include proof of indentity with each outgoing message, to encrypt their message, or both.
The sooner senders start signing their email, the sooner it will become practical for recipients to just say no to unsigned email. Imagine being able to configure your kids' email clients to reject any email from other than a set of configured senders, and make it stick. Unless Uncle Bernie finally goes off the deep end, that spells an end to unsolicited emailed porn come-ons.
In order to prove your email really came from you, you need a certificate: a chunk of data that contains (1) two really big numbers, (2)some information about who you are-- at a minimum, your email addresses, but possibly also your name and affiliations-- and (3) some information about who vouches for your claim, and for how long they do so (typically, one year from the date it's issued).
There are two main approaches to the (3) vouching-for part: the distributed "web of trust" scheme that relies upon other users vouching for you, and a centralized "certificate authority" scheme that relies upon a faceless corporation vouching for you. I describe the latter of these two approaches. For information on the former scheme, browse Explanation of the web of trust of PGP.
A certificate authority (CA) is an organization-- usually a for-profit corporation-- that issues certificates. This is a very profitable business for outfits like Verisign, Thawte, and InstantSSL, who charge hundreds of dollars to certify individual web sites-- a process that consists of making a few phone calls or reading a few letters to support the claim of some entity (usually an online vendor) wanting to run an SSL-secured web site that they are who they say they are. The key asset that a CA has is an agreement with the people who ship web browsers (e.g. Microsoft, Apple, Mozilla, and Opera Software) to include the "root certificate" of the CA with the web browser. If your web browser has that root certificate, and if the CA used that cerficate to sign the vendor's certificate, then your browser will make an HTTPS connection to the vendor without popping up any scary security alerts. Lucrative business, that.
A few CAs also offer individuals certificates for secure email free of charge. One visits a web site, fills in a form with some personal information, and receives an email containing instructions for retrieving and installing the certificate in your browser or email client. The principle here is that if you can recieve that email, you must be the owner of that email address, and the CA is therefore willing to issue a certificate certifying that. (Think about that next time you walk away from your workstation for just a minute.)
Which you choose to use is not particularly important. Personally, I use certificates from both of the vendors listed below.
Thawte (pronounced "thought") is the wholey-owned "little sister" of Verisign, the 800-pound gorilla of the CA biz (Thawte is their "discount" brand.) Their scheme is a hybrid of the faceless corporation/web of trust schemes in that you can (but need not) work with peer users to increase the amount of information that is contained (and thus vouched for) in your certificate. Information on the Thawte web of trust is available on their web site.
To obtain a no-cost secure email certificate from Thawte, browse here. The process is relatively straightforward-- you establish an account with your email address as the username and a password of your choosing. Be prepared to give them some sort of "national ID number" such as a social security number or driver's license number, along with a set of challenge questions that can be used to retrieve your password if you should forget it. You also need to tell it what sort of certificate format to use, based upon the client software you have. (For Mozilla, choose Netscape.) When you finish the initial steps of providing information, they will email instructions to the email address you gave them in the enrollment process. That email contains the URL you must visit to complete the enrollment and a few numbers you must enter in a form to prove that you receieved the mail.
When you complete the enrollment process, they give you the URL you must visit to check the status of your certificate. In my experience, the certificate is ready for issue by the time you get there. Precise instructions for installing the certificate depend upon your client software, covered in the next section.
InstantSSL (a brand of the Comodo Group) is another discount CA that offers free email certificates. To apply, use Internet Explorer to browse here and click on "Get your Free Email Security Certificate now!" near the bottom of the page.
The enrollment process is very simple: you specify your name and email address and, optionally, a password to be used to revoke your certificate in the unlikely event it is necessary later. Within a few minutes, and email is sent to the address you specified that contains a URL and password that you must use to pick up the certificate.
(Note: you can't even use Mozilla directly with InstantSSL-- instead, you have to use Internet Explorer to install the certificate, then export it to a file that can then be imported and used with Mozilla.)
Precisely how you install your certificate depends upon what software (operating system and email client) and CA you are using. I'll cover a few common combinations below.
The Mozilla web browser, which is an open-source spinoff of the now-defunct Netscape, comes with a kick-ass email client that, like the browser itself, is free of cost and available for a wide variety of operating systems. The email client uses the certificate store of the browser, so by loading the certificate into your web browser it becomes accessible to the email client as well.
Mozilla calls the certificate store a "security device," and uses an optional password to secure it. This is pointless until you have client certificates (like this one) to store, and an excellent idea thereafter. You will be prompted to establish such a password the first time you store something in the security device, and prompted to enter it whenever you make changes thereafter. This is one of those passwords that you really don't want to forget, because your certificate store is a total loss if you do.
Anyway, when you retrieve your certificate from Thawte is one of those times when you are writing to the security device. I always find it a little disconcerting when I store a new certificate because Mozilla doesn't tell you that it's doing it. The only way you know that it's happened is that afterwards you can see it listed when you browse the contents of your certificate store. You do that by selecting "Edit Preferences," "Security," "Certificates," "Manage Certificates," "Your Certificates." Look for one labeled "Thawte Freemail Member" in the "Thawte" section. Select "View" to see the details of your certificate.
To install your InstantSSL certificate, you simply use Internet Explorer to visit the URL and enter the password contained in the email you get from the vendor. You will get a security alert asking for confirmation before the certificate is absorbed by the Internet Explorer certificate store. Afterwards, you can confirm that it worked by opening the "Tools:Internet Options" menu, selecting the "Content" tab, and clicking on the "Certificates" button. Your certificate will appear in the "Personal" tab on that screen. Select the line corresponding to your certificate and click "View" to see the gory details. Click on "Advanced" to see even gorier details. Note: if you have trouble using your certificate to sign email, make sure that the "Secure Email" checkbox is checked in the "Advanced" screen.
Like Outlook, Outlook Express uses the Internet Certificate store to find the certificates it uses to sign (or encrypt) email. See above.
Out of the box, Pine doesn't support S/MIME. There are third-party patches that extend it, but we haven't tried them and don't plan to.
Finally, we are ready to actually use the certificate to start signing email. The details of how you do that depend, of course, upon which client you are using.
I've included a screenshot, below, to show you the screen that's used to tell Mozilla Mailer that to digitally sign all email using the certificate. One way to get to this screen is by selecting "Edit," "Mail & Newsgroups Account Settings...," "Security." As you can see, I've selected the new certificate and specified that it be used to sign but not to encrypt all messages-- by default. I can chose to encrypt or to not sign any particular outgoing message by selecting "Options" while I am composing it.
Start by selecting "Options" from the "Tools" menu in Outlook 2000, then select the "Security" tab. Everything on the next page is greyed out until you configure, which you do by selecting the "Settings" button. In the "Certificates and Algorithms" section, click "Choose" to select your certificate as the "Signing Certificate." After that's done and you click "Okay," you can check the "Add digital signature to outgoing messages" box under the "Secure e-mail" heading, click "Okay" again, and you are done.
Configuring Outlook Express to digitally sign email is similar to so configuring Outlook 2000. Choose "Options" from the "Tools" menu, then select the "Security" tab. Check the "Digitally sign all outgoing messages" checkbox.
Next, configure your email account to use your certificate by right-clicking on the account name in the folders pane and selecting "Properties." Select the "Security" tab, then click on the "Select..." button in the "Signing certificate" section to select your certificate.
Oddly, Outlook Express is pickier about digital signatures than other email clients, including Outlook. It works poorly to share a single certificate between several email accounts, and it complains about incoming mail signed with a certificate that lists multiple email addresses.
You probably want to make a backup of your certificate, for two reasons:
Of course, the details of how you do it depend upon your client.
Select "Edit Preferences," "Security," "Certificates," "Manage Certificates," "Your Certificates." Look for one labeled "Thawte Freemail Member" in the "Thawte" section. Select "Backup" or "Backup All" to save your certificate(s) to a "PKCS12 file."
There are a couple of things that Mozilla does to keep this operation secure:
Please resist the temptation to leave the only copy your backup on the same computer as your browser runs on. Ideally, you would store it somewhere physically remote from your computer.
Restoring or importing your certificates into Mozilla is easy, too. Select "Edit Preferences," "Security," "Certificates," "Manage Certificates," "Your Certificates," and press the "Import" button. Again, you will need to establish or enter a password for the security device, and you will need to enter the password that was used to encrypt the backup.
Select "Options" from the "Tools" menu, then select the "Security" tab. In the section labeled "Digital IDs (Certificates)" click on "Import/Export" and select "Export your digital ID to a file." Click "Select" to browse your certificate store and select your certificate, then click "Browse" to specify a location for the backup file. You need to enter and confirm a password that is then used to encrypt the backup.
Restoring or importing certificates into Outlook is performed from the same dialog boxes.
Typically, email certificates are good for one year from the date of issue. You should note the expiration date and renew or replace your certificate before that date, or your email client may refuse to allow you to send signed email. Even if it does, recipients may get a tedious and scary security alert that the certificate used to sign your mail has expired.
You can also check the expiration date of certificates by viewing the properties in the facility that your client provides for that.
To renew, visit the web site of your vendor and follow the instructions.
I've been simplifying my explanations above for the sake of brevity, but more technically inclined folks may want a little more detail on what's actually happening. Here it is.
This whole scheme is based upon something called public key cryptography-- the same technology that secure web commerce (SSL) is based upon. The idea is that there are two really big numbers that are related to one another: a private key that is known only to a single party, and a public key that is known to everybody else. Data that is encrypted using the private key can only be decrypted it using the corresponding public key. It is virtually impossible to compute the private key from the public key, so it's safe-- necessary, in fact-- to share the public key around.
To grasp how this can be used to add accountability to email messages, you first need to know what it means to digitally sign a block of data-- in this case, the body of an email message (email subjects and other header fields are, according the the S/MIME standard, never signed nor encrypted).
There is something called a hash: a big number that is computed from the email message-- a number that is so big (and computed in such a fashion) that it is impractical to anybody to create another, different block of data that has the same hash value. (See What is a hash? for details).
To sign an email message, the sender computes a hash of the message, then encrypts that hash value using their own private key. Their certificate plus that encrypted hash value form a digital signature that is included with the email.
The recipients know the public key of the user that signed the message because they have the sender's certificate (it's part of the signature), and they can therefore decrypt the hash value. If the decrypted hash value is the same as the hash value they themselves compute for the message, it must have been encrypted with the corresponding private key-- that is, the sender must have signed it.
A certificate consists of the following elements: a public key, information about who the owner of the public key claims to be, and a hash of the whole mess, signed by a certificate authority.
How do recipients know that the public key belongs to the sender? They know it because the certificate containing it is itself signed by some certificate authority that their browser has been configured to trust. That certificate authority certifies the identity of the sender.
The recipients have the certificate-- and thus the public key-- of the certificate authority-- because it came with their browser. If the recipients can use that public key to decrypt the hash value in the certificate, and if the recipients compute the same hash value, the conclusion can be drawn that the sender's certificate was signed by the certificate authority. And that amounts to proof that the message body was signed using the sender's private key.
Earlier, we talked about the need to protect the data in your certificate store. Besides certificates, the certificate store contains copies of your private keys. Note that anybody who recieves an email from you has your certificate, and thus your public key. If they can compromise your certificate store and steal your private key, they have everything they need to create email that is all but provably from you. So don't let it happen.