Although often overlooked, many standard email clients (not web-based) provide the ability to send S/MIME secure email. S/MIME has been around for quite some time, but you typically only see it used by perhaps government employees or maybe security-minded folks.

What is S/MIME anyway? It stands for Secure/Multipurpose Internet Mail Extensions.

Using client certificates, similar in concept to server certificates, a user sending an email can do two major things:

1) Digitally Sign an email – this marks the email as having come from the actual sender and will show the receiver if the mail has been altered after the sender signed and sent the email. Nifty!

2) Encrypt an email – once two users both have S/MIME configured and have exchanged messages (thus exchanging public keys), they can exchange encrypted messages back and forth. Note that this is different in concept than TLS level transport encryption between SMTP servers. Transport level encryption ensures that while in transit the message is not sent in the clear. S/MIME level message encryption ensures that the only one who can read the message is the intended recipient – who of course has the private key.

What’s really nice is that a user on an email system or client that doesn’t support S/MIME will still be able to read the signed (but not encrypted) messages. They simply see a smime.p7s file attachment with the message.

A number of Certificate Authorities provide third party S/MIME certificates – Comodo even offers a free one for personal use, good for one year. When you do have to pay for a certificate it’s typically very affordable at $20 a year or less per email address you want to secure. If you’re just using this internally for messages in your organization’s Exchange email system you could even just use your own PKI and configure auto-enrollment with AD storage of the certificates for your users.

Because of the relatively low cost some providers such as DigiCert only offer this type of certificates to businesses using their managed PKI (MPKI) product. Perhaps their rational is that the low cost and high support costs of these certificates doesn’t provide a good enough profit.

So why hasn’t S/MIME really caught on? DigiCert may be on to something. A certificate must be created. Every email client a user has must then be configured to use the certificate with S/MIME. This means exporting the private key to every device and then installing it. Given that most people have a desktop or laptop (or perhaps both), a phone, maybe a tablet, this can quickly turn into quite the configuration effort. You also need a secure location to store the private key – once you start sending encrypted messages, you will need to hang on to the private key for AS LONG as you have messages that were encrypted with that private key. Get a new laptop? Now we have to install the private key there so you can get your mail. Certificate expire? No problem, just get a new one, but remember you have to keep the old one installed indefinitely (or at least until you don’t need the messages that used the old certificate anymore).

So certainly there is some overhead and steps involved with using S/MIME. For those that are comfortable with that and have a plan or process in place to manage the use of S/MIME, the benefits can certainly be welcome. Imagine being able to tell if that message from your bank really did come from them. Need to send an important tax document to your accountant? If you’re both on S/MIME it’s a matter of checking the “Encrypted Message” box.

It’s great to see some vendors start coming on board. Outlook 2010 & Outlook 2013 support S/MIME, as does Office 365. Microsoft Exchange 2013 supports S/MIME on Outlook but not on the iOS Outlook app. Apple iOS and OS X both support S/MIME. For Android devices at the moment you’ll have to use a third party mail application. Of course it should also be noted that any web-based email client (such as gmail, hotmail, etc.) does not support S/MIME through their web pages. It is possible however to use a POP3 or IMAP client to send S/MIME email through these services, and for at least gmail there are a couple of Chrome add-ons that will allow S/MIME support.

Have you implemented S/MIME in your organization or for personal use? What issues have you experienced with deploying or maintaining the setup.