Limitations of secure email

S/MIME is a good standard for securing email, but other factors makes it less secure and less useful than it could be.

Security is like a chain: it is only as strong as its weakest link. With S/MIME there are many links in the chain, so there are many places where weaknesses can occur.

Implementation

Email client program

Not all email programs support S/MIME. All Web browser based email readers (e.g. Gmail, HotMail and Yahoo mail) don't support it. Some mobile mail clients don't support it. And even some desktop email programs don't support it (e.g. Opera Mail).

If you send a signed email, these email clients will see the signature as a smime.p7s attachment. This will probably confuse your average user, so you probably want to avoid signing messages if you suspect they are using a mail client that does not support S/MIME.

Also, you are relying on your email client program to be implemented correctly and is bug free. Of course, a bug free program is virtually impossible.

An example of a bug that I've seen is that the email program indicates that the message is signed when that wasn't fully signed. A signed message was forwarded, along with additional unsigned text. The email program displayed the entire message as if it was all signed, even though some of the text could have been tampered with.

Email servers

The email servers must treat S/MIME messages properly.

It must not modify the message, because that will make signature verification fail. Mailing list programs often append extra text to messages. This could cause the reader to see a warning that the message has been tampered with. Smarter mailing list programs might strip out the signature when they modify the message. This is not as alarming to the receiver, but now there is no security.

Some organisations might have policies that forbid encryption. They might reject or strip out encrypted messages that have been encrypted.

Certificates

The are many problems that can go wrong with the certificates.

It is relatively easy to get a certificate with a false name in it, and email clients usually just display the signer's name. Unless the receiver carefully examines each certificate in detail, there is no guarantee that the message was not signed by a certificate issued to a different person.

Trust

Even if all the technical pieces of S/MIME work, there is still the more difficult issue of trust. Can you trust an email message with a digital signature?

Secure email is based on cryptographic algorithms which are unbreakable, but there are a lot of processes around them which could go wrong.

Do you trust the issuer?

Do you trust the certificate authority to not issue bogus certificates? As we have seen, anyone with an email address can easily get a valid certificate. Those certificates are marked as "Class 1" and might not have the person's real name in it, but unless you manually check all that detail on every email you will not know that.

Even high security "Class 3" certificates (which are supposed to have greater assurances) have been issued in error. For example, Verisign has been tricked to issuing certificates for Microsoft to someone who was not Microsoft. And now there are reports of some governments pressuring certificate issuers to give them false certificates.

Which issuer do you trust?

Mail programs come with a large set of root certificates, but can you trust them all? If you don't manually check the certificate for each signed email you receive, you will not know who issued it.

One solution is to manually delete all the root certificates and only add the ones you trust, or add the individual certificates you trust. This is not a normal thing to do, so most users will not take this action.

When things go wrong?

In theory, if a certificate has been compromised then it is revoked by the certificate authority. In practice, some programs don't do revocation checking and even the large players (like Microsoft and Verisign) don't fully support revocation checking which leaves you vulnerable.

A lot of these limitations come from the limitations of PKI. If you want to find out more, Bruce Schneier has written about the ten risks of PKI.

Uptake

Finally, very few people know anything about secure email, let alone use it. If you are emailing a small group of like-minded people who use it, then that is fine. The difficulty comes when sending emails to people who don't use secure email.

If they don't use secure email, obviously you can't encrypt emails to them and they won't know how to encrypt emails to you.

You can always sign your emails. The signature is there if they want to use it, or they can ignore it. Though they might get confused by the signature if they don't know what it is.

So why use secure email?

If you have read this far, then you are probably interested in secure email--which is a good enough reason to try it out.

If you have some sensitive information to send to someone, and you both agree to make the effort to use secure email, then you can use it.

If you don't have an identified need for security, you still might want to use it. Firstly, it is a reminder that ordinary email is inherently insecure. Secondly, you will understand how to secure your emails if the need ever arises (and be aware of the limitations). Thirdly, to protect your right to use security and privacy: so that it does not become accepted that only people with something to hide will use security and everyone else must remain at risk.