Rutgers, The State University of New Jersey

Privacy Enhanced Mail

[Note on terminology: The term "privacy enhanced mail" is the name for an early Internet standard. I'm using it in a more generic sense to refer to all approaches for increasing the security of email. I'm reluctant to use terms such as "secure email", because this may imply levels of security that are not realistic.]

There is increasing interest at Rutgers in using email to transmit private information, and to be able to verify that validity of email. This document will describe use of the Internet standards for Privacy Enhanced Mail. The facilities described here

Note that this document refers to "privacy-enhanced" mail, rather than "secure email". There is no such thing as complete security. The approach used here will significantly increase the level of privacy of your email. However like all techniques there are limitations, some of which will be noted here. Privacy-enhanced mail is certainly more secure than the non-computer methods of communication it replaces.

This document has three primary sections

Technical note: there are two commonly-used types of privacy-enhanced mail. This document describes a standard called S/MIME. There is a separate approach called PGP. It works similarly, but using it requires you to install additional software. Also, collecting certificates isn't as easy. Thus I recommend using S/MIME.

Creating and loading a certificate

Privacy-enhanced mail uses "certificates" to verify the identity of correspondents, and to specify the information needed to encrypt email. In order to use privacy-enhanced mail

Fortunately, the mail systems will automatically collect certificates from people who send you privacy-enhanced mail (except for Outlook, where you will need to add people to your contacts address book). Thus the main thing you need to worry about is getting a certificate for yourself.

There are a number of places where you can purchase certificates for email. However many of our staff use personal email certificates from Thawte, a division of Verisign.

The first time you get a certicate from Thawte, you will need to join. They will ask for information about you, including identity information such as an SSN. Because digital certificates can be used for legally binding purposes, they need to be able to trace them back to an identifiable person.

Note that certificates are good for only a year, so you'll need to request a new certificate and load it into all of your mail programs once a year.

NOTE: Make sure you use the right browser.

Once you have joined, you'll get to a page that lets you manage your account and certificates. Web pages change, but at as of this date, in the left margin, you'll see "certificates". Click on that.

On the resulting Personal E-mail Certificates page, click "request a certificate". You want an X.509 Format certificate (which is the only option other than a special option for developers).

It will ask for format. Choose "Mozilla..., Netscape" for Mozilla products such as Thunderbird, and for Macintosh Mail. Choose "Microsoft.." for Microsoft Outlook and Outlook Express.

Unless you have made special arrangements, you will have no options on the "Certificate Bearers Name" page.

You will now be in a page "Configure Email addresses for Certificate". You should choose the email address this certificate will be used with (if you have registered more than one). If you need to register or change email addresses, look at the main "Personal E-mail Certificates" page. In the left margin you'll see "my emails". On the resulting page you can add and delete email addresses.

There will be several pages where I recommend taking the default. For Windows you will get a popup box warning that you are generating a certificate and asking you to choose a security level. The default of medium seems OK.

The certificate takes several minutes to be issued. On the main "Personal E-mail Certificates" page, choose "certificates" and then "view certificate status." It will start out as "pending" and then change to "issued".

Once your certificate shows "issued", click on "MSIE" or "Navigator". You'll get a page with information about the certificate, and a "fetch" button. Click on "fetch".

Using Privacy-Enhanced Mail

All three of the mail systems described here provide ways to verify that email is signed, and to send email that is signed, encrypted or both.


When sending email, you set the security options using the "Options" button at the top of the message composition window. In Message Options, click "Security Settings". You can click "Encrypt message", "Add digital signature to this message", or both.

When you add a digital signature, I recommend you make sure that "Send this message as clear text signed" is checked. That means that people will be able to read the message even if their software doesn't support digital signatures.

Note that the certificates aren't checked until you try to send the message. At that point Outlook will warn you if you haven't set up your certificate properly. If you have asked for the message to be encrypted, it will also warn if you do not have certificates for all of the addressees.

To send an encrypted message, your addresses must come from your contacts list. Note that global address books such as LDAP do not qualify. You must find a message they have sent that is signed, right click on the From address, and choose "add to contacts". When you want to send a message to them, you must make sure to get their address from your contacts, not type it manually. Replying to a signed message from them works fine.

I recommend that you sign all of your messages. To set things so that your mail is signed automatically, choose Tools, Options, Security, and make sure that "Add digital signature to outgoing messages" and "Send clear text signed message when sending signed messages" are both clicked.


When sending a message, you set the security options by clicking the pulldown to the right of the Security icon (looks like a lock). You can choose to sign, encrypt, or both.

Note that the certificates aren't checked until you try to send the message. If you have asked for the message to be encrypted, it will warn if you do not have certificates for all of the addressees.

Thunderbird will capture certificates automatically when you get a signed message, so if you want to send encrypted email and you don't have a certificate for your correspondent, ask them to send you signed email.

I recommend that you sign all of your messages. To set things so that your mail is signed automatically, choose Preferences, go to "Security" under your mail server, and set "Digitially sign messages by default." Verify that there's a certificate listed above that. You should also verify that there is a certificate under Encryption, so that you can send encrypted messages if you need to.

Macintosh Mail

When sending a message, you set the security options by clicking an icon that appears right below the headers, on the right side. For signature, the icon looks like an X or a check. The X means digital sigature is off; the check means it's on.

Note that Mail remembers the setting, so once you've sent a signed message, future messages will also be signed unless you turn it off. I recommend leaving signing on for all messages.

Once you've typed an address, you will probably have a second icon, which looks like a padlock. Whether it shows up or not may depend upon whether you have a certificate for one of the addressees, but I've seen inconsistent behavior. The padlock is closed to send the message encrypted. It is open to send it without encryption.

Mac mail will capture certificates automatically when you get a signed message, so if you want to send encrypted email and you don't have a certificate for your correspondent, ask them to send you signed email.

How Secure is Privacy-Enhanced Mail?

Note that I'm not a security expert. This section is based on my own observations. There may well be other weaknesses that I haven't noticed.

This section is intended to give you information on how much you can trust privacy-enhanced mail.

There are two aspects, the signature and encryption. In both cases, the technology is fairly good. While the NSA can do doubt forge messages and break the encryption, it's unlikely that others will be able to do so. The weak points aren't in the technology, but in how it is used, as we'll see below.

First, signatures. If you get email from telling you to send a million dollars in unmarked bills to an address, can you believe that the President actually requested it?

Here are the major issues: First, as noted above, the only thing that is verified is the email address. Whoever sends a message can set whatever they want in the From line. They can claim to be George Bush <>. You have no guarantees about the George Bush part. But if the message is properly signed, you can be reasonably sure it actually came from

I say "reasonably". What do I mean? What you actually know is that the sender has a certificate for How good that is depends upon the policies of the company that issued the certificate. If you analyse Thawte's process, it turns out that it depends primarily on the fact that the person setting up the account can read email sent to That means that they know the password for the netid or other account where the email comes. Some authorities may have tighter processes, but without doing further investigation, this is about the security level you can assume.

In addition to the policies used in issuing the certificate, you have to be concerned about the security of the system used to send the email. The software described on this page attempts to protect certificates. Depending upon the software and its setting, the certificates may be protected by the normal user's password or by a special password for the certificate database. But in either case someone can get hold of a user's certificates by guessing their password (if it isn't carefully chosen) or by breaking into their system and doing a bit of work. It's unlikely that the typical virus or worm will be able to do this, but a determined attacker will probably be able to compromise the certificates on a system if they can break into it. So you're depending upon the user who sent the email to do a good job of security on their system.

How about encryption? This has the same two issues. First, you are concerned with the policies of the group that issued the certificate. If someone has faked a certificate, you may be sending your sensitive data to the wrong person.

Second, you're depending upon the security of the system. If a determined attacker is able to break into the user's system, they will probably be able to compromise the certificates on it and read the email.

However encrypted email is fairly good protection against attackers watching the network, and against the mail servers involved in sending and storing the message being compromised. In the end you're dependent primarily upon the user's security practices. But that would be the case even if you send the file on a floppy delivered by an armed guard.

Note that you can sometimes get a higher degree of assurance if you look at the certificate. Thunderbird and Outlook both let you click on the icon and see the details of the certificate. That lets you see what authority issued the certificate and then investigate their practices. You can also adjust the list of certificate issuers that you will accept. So if you had specific security needs, you could accept only certificates issued by particular groups whose policies you trust.

The default Thawte Freemail certificates are relatively weak because they need to use a process that doesn't require any personal contact. Thawte has a process with higher assurance, called the "Web of Trust". This requires you to get a trusted person to check ID physically. If a Thawte certificate has an actual name, rather than "Thawte Freemail Member" in the "Issued to" field, then you know this process was used.

Some governments and institutions also identify people carefully before issuing certificates. But to be sure you need to look at the certificate and know the policies of the issuer.

Another approach is more pragmatic: if you are in regular correspondence with someone, you can probably be fairly sure who they are. If you get a new email message from them, it is probably them. But to be really sure, except in Outlook, you have to check the certificate, and make sure it's the same certificate as the one you're used to. In principle an attacker could have gotten their own certificate for the same email address. (OK, I'm paranoid.)

In summary: without further investigation, privacy-enhanced mail is about as good as the user's password and their ability to keep their computer secure.

Sets of users with needs for higher levels of assurance can issue certificates more carefully, but except with Outlook, they will then need to set their computers to only accept those certificates, or they will need to check the certificate manually before doing anything security-sensitive.

In some ways Outlook's approach has an advantage. Outlook differs from Mozilla and Mac Mail in that it does not capture certificates automatically. It requires you to add the user to your Contacts list. If you have high security needs, you can check out a user's certificate carefully before adding it to your Contacts. Or you can only add it after you've been conversing with them and you're fairly sure it's them. By default, Thunderbird and Mac mail both capture certificates automatically. They don't alert you when they're doing so. That means that even if you check out a certificate carefully, an attacker who can get a certificate for the same email address can preempt the real certificate. You can protect against this, but it would require you to edit the list of certificate issuers that you accept. [It appears that on the Mac you could put certificates in a separate keychain which you would have to unlock to change. However this requires special setup.]


For more information, contact
Last updated: Friday, 07-Jul-2006 15:50:09 EDT
© 2006 Rutgers, The State University of New Jersey. All rights reserved.