Who would have thought in this year 2016 (almost 2017) I would be writing a blog post about S/MIME? Having spent my formative computing years at cc:Mail (and later Lotus), I spent a lot of time working with public sector companies and espousing the wisdom of securing your email using this offshoot version of PKI. Later, I would work at Voltage Security (now part of HP) evangelizing a new, easier way to do secure email with a more elegant key sharing/management mechanism. But alas, here I am talking about S/MIME yet again.
What is S/MIME?
For the uninitiated (which should be few of you at this point), S/MIME is a secure email mechanism, facilitated by PKI and is available in just about every modern email client (including mobile clients on iOS, Android & Windows 10). S/MIME got its start from folks wanting to protect the content of their emails but also served as a way to verify the sender (message signing) and, depending on the trust chain, for near non-reputation. I bet we’re all wishing that Yahoo mail had S/MIME built in. If you were industrious enough you could have used an IMAP or POP client to accomplish this, but alas, it does not come built-in.
What Does S/MIME Do for Me?
As you can imagine, with all sorts of nefarious folk out on the inter-web, you might find it useful to protect and encrypt certain conversations. S/MIME is “end to end,” meaning if an e-mail is MITM’led (Man in the Middle) the likelihood of that person being able to open and read it is pretty slim. S/MIME is not necessarily relevant to Aunt Mabel’s cookie recipe, but it might be useful for a private conversation with your boss or business partner. It also allows you to sign the message (the message is hashed to prevent tampering) so that your boss or business partner knows it was really you who sent it.
Why Doesn’t Everyone Use S/MIME?
Good question. The easy answer is that PKI is hard. Setting up the infrastructure to support this simple capability is far from simple, which was one of the reasons why PKI adopting was nearly non-existent outside of the public sector. The good news is that mobile computing architectures have made PKI cool again (if it was ever cool) and have also made it a skosh easier to setup and maintain (still a lot of work by anyone’s estimation,) but the reward is well worth the work.
One of the reasons why MobileIron built security so deeply into the Email+ client (including FIPS 140-2 level crypto -AND- S/MIME) was to support advanced use-cases for certificate based authentication and secure email. Most public sector agencies have long ago adopted PKI and with the emergence of PIV-D (derived credentials) the capability becomes even more important. The S/MIME capability was core to that philosophy. This is also applicable to enterprises in corporate america, who also have a need for securing email communications. These core capabilities and philosophies are why it made perfect sense to add this into the MobileIron family of products, powered by AppConnect, where security is priority one.
So while PKI and S/MIME might seem like a “bridge too far crossing” when it comes to the perceived heavy lifting involved, you have to think about the security benefits afforded (and risk of not doing something) with these kinds of capabilities. And as we wake up every day in a less “technologically secure” world, these kinds of protections should be seriously considered. Right, Yahoo?