OpenPGP and S/MIME are competing standards for e-mail encryption, and I argue that Alice and Bob should go for OpenPGP if they are in doubt what standard to prefer. Essentially, the “trust” model of S/MIME is fundamentally flawed.
I’m using both, OpenPGP and S/MIME, and I wrote a GNU Emacs library for automatic encryption of e-mail when public keys or certificates for all recipients are available. As I use S/MIME and as I even programmed something to simplify S/MIME use, I felt compelled to write this article to clarify that I do not recommend S/MIME—and why.
In this document, I place the word “trust” in quotation marks to indicate a misguiding use of the word. Without quotation marks, I refer to the usual meaning of trust: a personal believe that cannot be enforced. (This excellent video explains trust in 3.5 minutes, although in a different context.)
Common Background of OpenPGP and S/MIME
OpenPGP and S/MIME are both readily available for daily use, e.g., the GnuPG project, which you can currently support via their crowdfunding campaign, provides free software for both of them. Lots of tutorials have been written for that software, and I won’t add another one here. I also won’t argue here why Alice and Bob perceive e-mail encryption as necessity. (I did that previously in German.) Actually, why would you choose not to encrypt your e-mail?
OpenPGP and S/MIME are based on asymmetric or public-key cryptography, a branch of mathematics which does some powerful magic. For asymmetric cryptography everyone needs a so-called key pair consisting of a private and a public key. Intuitively, the public key of Alice can be understood as open safe, which she offers for others to receive private messages. Once Bob has put a message into that safe, he closes the door, and nobody but Alice is able to open the door and read the message. Alice needs her private key, the safe’s opening combination, to access the message. This relationship of open safe and public key on the one hand and opening combination and private key on the other is the essence of asymmetric cryptography.
Now, the fundamental challenge of asymmetric cryptography is the identification of trusted or authentic open safes (i.e., public keys). Assume that Mallory wants to intercept Bob’s messages to Alice. To trick Bob, he creates an open safe (in fact, a key pair) and attaches the name tag “Alice” to that open safe. If Bob sees that safe, he might believe that it belongs to Alice and deposit messages. Of course, Mallory can access those messages, read or modify them, and forward them to Alice’ real safe. Neither Alice nor Bob will notice the difference, and Alice never learns about that fake safe created in her name by Mallory.
Public key infrastructures (PKIs) aim to distribute public keys in such a way that Mallory will be unable to use keys in somebody else’s name. Essentially, PKIs make use of so-called certificates, which are documents containing a public key and a digitally signed statement that the key belongs to a certain person (or organization or machine). In the analogy of open safes, a certificate would be a safe whose name tag is attached via an unforgeable seal. Even without going into details on digital signatures, it should be clear that a PKI shifts the problem of identifying correct public keys into the problem of verifying signatures: Who is able to create unforgeable seals, and how does one verify their authenticity?
The companies, organizations, and individuals creating unforgeable seals are called certificate authorities (CAs), and every CA has its own key pair (or several of them) to create seals. Technically, CAs use their private keys to create seals, while others use the CAs’ public keys to verify the seals’ authenticity. Thus, Alice could ask a CA, say Carol, to attach the name tag “Alice” to Alice’s open safe with Carol’s unforgeable seal. Carol would then check whether Alice really is who she claims to be, before she attaches her seal. If Bob has obtained Carol’s public key, he can verify the authenticity of her seal. If that verification is successful, Bob knows that Carol claims that the safe belongs to Alice. Nothing more, nothing less. Should Bob trust Carol? Maybe Mallory paid, tricked, or forced Carol to claim that his own safe belongs to Alice?
Trust Models
PKIs in the real world follow one of two fundamental trust models, namely anarchy and oligarchy. Maybe neither “anarchy” nor “oligarchy” sound too trustworthy, so let’s start with a hypothetical alternative, democracy. Under democracy, voting is used to determine authorities. Everyone has an equal vote, and those parties receiving most votes are elected as new authorities. It turns out that trust works differently, largely unaffected by majority voting. Even if Carol is unknown to almost everyone, Bob may know her so well that he trusts her to act in certain ways in certain situations, independently of any majority voting. Vice versa, Bob is free not to trust Carol even if everybody around him praises her. Consequently, democracy is not an option for trust.
In an oligarchy, several authorities exist, and you must do as any of them says. This is the “trust” model adopted to secure communication on the Web via SSL/TLS (whenever a Web address begins with https://). There are lots of CAs, whose public keys are embedded as “trust” anchors in every Web browser. The browser “trusts” every of those CAs to sign certificates for every Web address. If you didn’t do so, please take the time to check whom your browser “trusts.” With Firefox, take just six clicks in the menu: Edit / Preferences / Advanced / Certificates / View Certificates / Authorities
For something as fundamental as “trust” anchors, that does not appear to be displayed as prominently as it could be. Whom among that impressive list of authorities do you know, let alone trust? Maybe it helps to check out this lucid visualization of about 650 CAs and their “trust” relationships (a legend is provided by the SSL Observatory).
Nope. That didn’t help, I’m afraid. It gets worse, though.
The bad news is that the “trust” model oligarchy is only as strong as its weakest link. Mallory only needs to pay, bribe, trick, compel, force, or operate a single CA to have his open safe with name tag Alice universally “trusted.” As every CA is “trusted” by every browser to vouch for every name (independently of any prior relationship between certifying and certified parties), the oligarchy fails to provide trust. Pay, bribe, trick, compel, force, or operate. Probably more. That provides a lot of economic, social, legal, and criminal opportunities to choose from.
In fact, you may want to recall some major CA failures demonstrating that different types of Mallory succeed to pay, trick, and compel CAs:
To patch up that broken situation on the Web, several Firefox extensions exist, e.g., HTTPS Everywhere, Certificate Patrol, and Perspectives.
Now for some good news. In an anarchy, you are free to trust. You are free to trust in the natural meaning of the word, as you see reason. Alice does not need to contact or “trust” some Carol if she wants to communicate with Bob in private. She just creates her open safe. Every open safe carries a temper-resistant serial number (a mathematical property, called fingerprint, of the public key), so that Mallory is unable to create a second safe sharing the same serial number. Alice communicates that number to Bob (not via e-mail, of course, which could be intercepted and forged by Mallory, but in person or on the phone). Before Bob places any message in a safe with name tag “Alice”, he verifies whether the safe carries the correct serial number, thus avoiding Mallory’s safe.
Once Bob verified the number, he can even attach his own seal to the name tag “Alice” to demonstrate his trust that the safe really belongs to Alice. Now, if Dave knows Bob and if Dave trusts Bob to attach seals only to the correct safes, he can immediately use Alice’s safe, which is how over time the so-called web of trust emerges.
Monkeysphere is a project to bring anarchy to the Web.
E-Mail with OpenPGP and S/MIME
S/MIME is generally used under the “trust” model oligarchy. If you want to start using S/MIME, you first need a certificate signed by some CA. There are lots of companies selling certificates, some issue them even without payment. Which company do you know? Which one do you trust? Suppose you choose one, for whatever good reasons. Now you want to send an e-mail to me. What makes you think that I place any trust in the CA chosen by you?
In general, I believe the oligarchy to be useful only in the special case of a dictatorship or monopoly. We may be able to trust the same CA. For example, if we work at the same company, we may be reasonably sure about certificates issued by our company’s CA.
Otherwise, we are on our own as far as trust is concerned. Thus, the natural option is to start out in anarchy, and I recommend GnuPG as free software that implements OpenPGP and allows you to build your own web of trust.
Trust me.
Some Pitfalls
At work I’m using GnuPG to encrypt e-mails under both standards, OpenPGP and S/MIME (depending on the recipient). In addition, I use my S/MIME certificate for X.509 authentication with Firefox.
If you need to generate an S/MIME certificate, spend some thought how to do that. Maybe your CA provides a Web form where you generate the certificate in the browser. Clearly, a browser on a networked machine is a pretty unsafe environment to generate keys. If you plan to store your key on a smartcard or e-token, then you may want to generate the key offline via gpgsm or openssl. Without smartcard or e-token, your private key may need to be accessible on a networked machine anyways. In that case, you should make sure that the key is protected by a passphrase. While gpgsm and openssl ask for a passphrase by default, Firefox does not. With Firefox (and Thunderbird), you must set a master password. Otherwise, everyone with access to your profile folder (local admins as well as admins for backups in remote places) can immediately use and steal your private key.
Also, I’d like to point out that some expertise is necessary to use S/MIME based on openssl. As the man pages of openssl’s smime and cms commands document among their BUGS sections, SMIMECapabilities are ignored when encrypting data. Moreover, openssl advertises and defaults to broken encryption algorithms such as RC2, which appears scary to me.
To check out what your S/MIME implementation advertises to others, analyze your own signature. If you sign an e-mail, the signature is contained in an attachment. With Gnus, you can invoke X m (gnus-summary-save-parts) and save the appropriate MIME part (application/pkcs7-signature). Otherwise, save the e-mail and extract its attachments into separate files:
$ munpack <email-file>
One of the extracted files is the signature. Decode that:
$ dumpasn1 <signature-file>
The output contains something like:
...
SEQUENCE {
1640 9: OBJECT IDENTIFIER
: sMIMECapabilities
...
Immediately afterwards, those encryption algorithms are displayed that should be used by others when sending e-mails to you. I don’t think that you can change that list with openssl, and on Ubuntu 10.04 no AES variant is included. In contrast, S/MIME 3.2 (January 2010) specifies AES-128 as MUST. Not good.
If you use Gnus with S/MIME for e-mails in GNU Emacs, chances are high that you also use openssl. In fact, the subsection on S/MIME in the Message manual only discusses openssl (although gpgsm is supported via EasyPG as well). If, after all that you’ve read here, you are interested in S/MIME with Gnus and gpgsm, I suggest my library ExtendSMIME.