A Case (Study) for Usability in Secure Email Communication

Secure Systems Editor: S.W. Smith, [email protected]

A Case (Study) For Usability in Secure Email Communication

s a network security researcher, I find it very dis- hold Alice to her original contract by proving that the signature he pos- appointing that most users can’t, or simply don’t, sesses was created before Alice published her key—perhaps by using a secure their everyday Internet communications. time-stamping service2 or an online notary—Alice can still claim that she For good reason, usability in security has received didn’t know her key was stolen. A More sophisticated protocols for a fair deal of attention in the past few years (see the September nonrepudiation are needed, but as it now stands with standard S/MIME, APU KAPADIA 2004 special issue on this topic1). To realized that, currently, everyday nonrepudiation for casual email users Dartmouth push the issue further, I decided to users seldom need to do so, as we doesn’t work in practice. College initiate my own informal case study will see if we examine email signa- on the usability and practical rele- tures more closely. Integrity vance of standard security mecha- For any message, Alice can use Forging email messages on today’s In- nisms for email communication. her private key to generate a crypto- ternet is surprisingly easy, and forg- I focused my attention on avail- graphic package that a recipient can eries such as phishing emails are a able public-key cryptography tech- verify only by using her public key direct threat to everyday users. In the- niques for digitally signing and and the original message. This pack- ory, if messages are digitally signed, encrypting email. My first step was age is called a digital signature and recipients can reject those with to establish a public–private key pair provides two basic properties: non- spoofed “From” addresses because to use with email. I chose to use Se- repudiation and integrity. their signatures won’t be valid—that cure/Multipurpose Internet Mail is, only Paypal can sign messages that Extensions (S/MIME), a standard for Nonrepudiation appear to come from paypal.com. signing and encrypting email, be- Nonrepudiation is the idea that, in Digital signatures also provide protec- cause it’s already supported by popu- theory, a signer such as Alice can’t tion against adversaries who modify lar email clients such as Apple Mail, later deny that she signed the mes- parts of the message in transit, Outlook Express, and Mozilla’s sage. For example, occasionally I although I would argue that such Thunderbird. Unlike S/MIME, I submit reviews for conference papers email modifications present very lit- found that Pretty Good Privacy over email. I could digitally sign my tle threat to everyday users—for them, (PGP) and the GNU Privacy Guard messages to claim responsibility for digital signatures’ main utility is in (GPG) were unusable with nontech- my words. But as any security re- countering forged sender addresses. nical correspondents because it researcher would be quick to point In practice, however, digital signa- quired them to install additional out, digital signatures’ nonrepudia- tures are a weak line of defense. Phish- software. S/MIME, it seemed, was bility is just an illusion. Alice can al- ers can use cleverly crafted email the better solution for these “every- ways claim that someone stole her addresses such as customer-service@ day users,” for whom the concepts of private key and that the signature is a paypal-help.com to trick users into public-key infrastructure (PKI), PGP, forgery. And if that’s not enough, believing that they’re corresponding certificates, keys, and so on remain Alice can publish her key in The New with Paypal. Because phishers can le- elusive. Additionally, I decided to get York Times, letting potentially any- gitimately own a domain such as pay- my public key certified by Thawte body sign a message using it. In such pal-help.com, a phisher can obtain a (www.thawte.com), an online cer- situations, Alice can be penalized for certificate and generate emails from tificate authority (CA). negligence or irresponsible behavior, that domain that have valid signatures but she can’t be held responsible for (this is just a hypothetical example, but Digital signatures the contents of messages signed with at the time of writing, paypal- After months of signing email, I’ve her private key. Even if Bob tries to help.com was registered under a for-

eign mailing address). Any mecha- tion, although anecdotal, has made a “examine certificate,” and a stray nism that combats phishing must look lasting impact on my use of signatures click later, my certificate was pre- beyond the integrity protection that and highlights the need for more re- sented for examination. The email digital signatures provide. Given that search on usability in security. client automatically obtained this most email that users receive is un- By default, some email clients at- certificate from earlier messages I signed, users routinely verify a mes- tempt to digitally sign replies to signed had signed. From my correspon- sage’s integrity based on its contents messages. While responding to my dent’s viewpoint, however, the and context. In fact, I find myself ver- signed email, a correspondent who problem with connecting to an un- ifying messages’ integrity based on works for the military was told to “in- trusted email server was somehow their overall content, even when they sert cryptocard.” Because the corre- linked to my name. Again, I found are digitally signed. For the lack of a spondent was not familiar with digital myself obliged to explain that I better term, I call this form of in- signatures, I received a reply with a wasn’t trying to do anything sneaky tegrity “semantic integrity,” in con- suspicious tone (whether intended or with my correspondent’s email trast to the standard notion of not, this is how I interpreted it). With client. These incidents have taught (syntactic) integrity that digital signa- the prospect of a potentially peeved me an important lesson: sign your tures provide. When corresponding military official, I found myself messages only to people who under- with familiar people, verifying the se- obliged to explain that I was not trying stand the concept. Until more usable mantic integrity of email messages is to do anything sneaky with govern- mechanisms are integrated into pop- surprisingly easy—digitally signed or ment computers, and that the email ular email clients, signatures using not, strange text from a friend that client was the culprit with its auto- S/MIME should remain in the do- contains an attached virus looks suspi- mated behavior. A couple of test main of “power users.” cious. I routinely ignore signatures emails, with and without signatures, from family, friends, and acquain- convinced the correspondent of my Encryption and the key tances simply because I’m confident theory—that the email client was in- distribution problem that I can sniff out forgeries. deed trying to automatically sign Now, more than ever, the privacy of At this point I will re-emphasize replies to my signed messages. our communications is at risk. The my focus on everyday users. Certainly, In a separate incident, another government is increasingly inter- defense contractors, network admin- correspondent, also unfamiliar with ested in our conversations, and in an istrators, and so on are well advised to PKI, was facing problems after en- open system such as the Internet, we digitally sign messages to correspon- countering a certificate signed by an must take added measures to ensure dents who expect them. You can in- untrusted CA. After clicking on our privacy rights. With the confi- struct employees to reject any message from the security officer without a valid signature—certain job functions rely on baseline security mechanisms for which you can provide training. For everyday users, however, using digital signatures to verify messages’ integrity is both overkill and prone to error, the former because using signatures for detecting alterations doesn’t address a tangible threat, and the latter because telling everyday users to “ensure that the signature is valid” to de- tect forgeries is a misguided heuristic. Focusing on tools that will help them verify semantic integrity, instead, is more promising.

Incrimination Given that the two most important properties of digital signatures don’t seem useful in practice, why might everyday users continue to sign email? The property of incrimina-

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 81 Secure Systems

dentiality of my electronic conversa- tally signed) by a CA that Bob trusts, deed create a bogus certificate for my tions in mind, I convinced some of then Bob will accept Alice’s certifi- identity, certified by a malicious CA my research colleagues to encrypt cate as being authentic. If Alice’s key that I don’t trust, but that is on the list their email conversations with me. is certified by a CA that’s not on of installed third-party CAs. Because the S/MIME email client would trust the certificate, were my col- By pre-installing third-party CA certificates leagues accepting a fake certificate signed by another CA or were they into email clients without rigorous auditing accepting my Thawte certificate? Clearly, users must first trust the procedures, vendors are breaking the trust CAs installed in their email clients. Second, if Alice and Bob are ex- model required for PKI to be successful. changing keys, they should use a CA that they both trust. Absent a com- While exchanging public keys, the Bob’s trusted list, Bob can try to find mon trusted CA, the just-men- most important step is to verify that a a trusted path to Alice’s certificate by tioned man-in-the-middle attack is man-in-the-middle isn’t subverting starting at a CA that he does trust. still possible, with or without certifi- your exchange. If we assume that an Let’s say that Bob trusts only CA1 and cate chains. PKI has been plagued by adversary can control our conversa- encounters Alice’s certificate signed its end-points—by pre-installing tions, we must verify the exchanged by CA3. Bob can try to find a chain third-party CA certificates into public keys’ authenticity. of trust in which CA1 certifies CA2, email clients without rigorous audit- Charlie, a man-in-the-middle, who in turn certifies CA3 (certificate ing procedures, vendors are breaking can pretend to be Bob with respect chains can be much longer in prac- the trust model required for PKI to to Alice and Alice with respect to tice). This certificate chain lets Bob be successful. Bob. Alice and Bob communicate establish a path of trust to Alice’s cer- Now, consider enterprise sys- “securely,” except that they’re both tificate, even though he doesn’t ex- tems, in which organizations can communicating through Charlie plicitly trust CA3. PKI proposes make rigorous policy decisions without realizing that he’s decrypt- meshes of CAs established by certifi- about a CA’s certification proce- ing and re-encrypting their mes- cation relationships. Meshes can also dures and thereby outsource the sages. The most secure way for Alice include hierarchies of higher-level key management functions to a and Bob to verify their keys’ authen- CAs certifying lower-level CAs and trusted CA. They can also make ticity is to do so in person; this, how- cross-certification authorities which rigorous policy decisions regarding ever, is impractical, giving rise to the can bridge trust hierarchies into a valid trust paths to other CAs. For key-distribution problem—how can mesh to aid in building trust paths. example, the Higher Education users distribute their public keys to Although this approach can pro- Bridge Certification Authority other parties reliably? The PKI vide a high level of assurance in en- (HEBCA) has a stringent process of world has developed two solutions: terprise-level communications, it has assigning levels of assurance (LOA) to either rely on a trusted third party (or a few limitations when applied to CAs that are part of the bridge. a more elaborate network of trusted email exchanges between everyday Higher education organizations third parties) such as Thawte or users. Mainly at fault is the list of can then trust HEBCA, and the or- VeriSign (www.verisign.com) to “trusted” CAs that the email client’s ganizations that are part of HEBCA certify that your correspondent’s software vendor has pre-installed. A can trust each other’s certificates. In public key is bound to his or her colleague of mine, Scott Rea, calls other words, HEBCA “bridges” identity, or verify the authenticity this a list of “third parties” as opposed trust between different organiza- yourself by checking the public key’s to a list of “trusted third parties” be- tions operating under their own fingerprints through an out-of-band cause this list doesn’t correspond to PKIs by certifying their CAs’ prac- (OOB) channel—that is, by a sepa- the set of CAs that the email client’s tices. Training employees within an rate means of communication. users trust. After all, I chose not to organization to recognize valid cer- get my public key certified from an tificates is feasible because the orga- Third-party “trust” authority that I had never heard of nization has a financial incentive to Verifying the authenticity of keys (and hence didn’t trust), but rather do so. Everyday users, however, with my correspondents was surpris- had it certified by Thawte. My cor- don’t have the time or motivation ingly error-prone. Let’s analyze the respondents, however, don’t know for rigorous bookkeeping about PKI solution that relies on CAs first. my trusted CA a priori. A powerful various CAs’ certification proce- If Alice’s public key is certified (digi- man-in-the-middle attack could in- dures. CA-certified keys and

82 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007 Secure Systems

trusted paths are less meaningful if ter which key continuity gives the over-IP (VoIP) services such as users don’t understand the certify- user a sense of security. This ap- Philip Zimmermann’s Zfone (www. ing CA’s procedures and are willing proach has limitations, however: philzimmermann.com/EN/zfone/), to accept any certificate that their what can Alice do if her key is com- given that it’s very difficult for a email client trusts. (Note, however, promised? In a CA-based approach, man-in-the-middle to subvert a that PKI can be quite successful as a before using Alice’s key to secure voice conversation in real time. means for an enterprise-level or- communications, Bob can check the Additionally, humans can easily ganzation to authenticate everyday CA’s revocation list or use the Online verify the semantic integrity of a users—the organization can have Certificate Status Protocol (OCSP) voice conversation with a known rigorous policies about which CA’s to ensure that it hasn’t been compro- correspondent because a man-in- certificates it should accept, with- mised. KCM, however, relies on the-middle would have trouble im- out including everyday users in Alice informing all her correspon- personating your correspondent’s these trust decisions.) dents that her key has been compro- voice. (Caveat: humans are poor at As I’ve argued, exchanging keys mised. KCM proponents argue that verifying the semantic integrity of using current implementations of the added benefit of an infrastruc- conversations with unknown cor- S/MIME is risky for everyday users tureless approach outweighs the re- respondents, a weakness that is ex- because their trust in their email duction in security from potentially ploited in social engineering attacks.) clients is misplaced. We must take a compromised keys. If users verify It would be prudent, however, to long-term approach toward building fingerprints often enough, they can expect computers in the not-too- usable key-management methods and limit the amount of damage a com- distant future to be able to synthesize educating everyday users about trust- promised key causes. voice in real time. A dedicated man- ing CAs and establishing a common This brings us to one final ques- in-the-middle could possibly re- root of trust with their correspon- tion: how can users verify a key’s fin- place the part of your conversation dents. An independent organization gerprints reliably? One option is to related to fingerprint verification. such as HEBCA can audit CAs care- verify fingerprints for email over IM Soon, we will need more sophisti- fully and help establish a common and fingerprints for IM over email. cated methods for verifying a remote root of trust. Users and email client However, this approach still won’t correspondent’s fingerprints, but vendors can then be instructed to trust protect us against motivated adver- until then, relying on real-time voice only CAs with the auditing organiza- saries (or our employers!) who can verification seems to be the best option’s approval. In the short-term, intercept both communication lines tion. In my personal experience, my however, because most everyday users and subvert our attempted OOB correspondents seemed rather un- don’t have mutually trusted CAs, they fingerprint verification. comfortable with the “geekiness” of should use the second solution, fin- Exchanging SMS messages is a reading random numbers over the gerprint verification, to foil man-in- viable option5 because the mobile phone. However, with VoIP soft- the-middle attacks. phone network is clearly separated ware becoming more popular from our organizations’ networks among everyday users, a mechanism Fingerprint verification (or are they?). After hearing about to use the same verified keys for A fingerprint is a secure hash of the the purported collaboration be- email communications will be a public key and is a smaller, digested tween the NSA and AT&T, how- great solution to the problem of form. Verifying that the exchanged ever, relying on phone companies OOB fingerprint verification. key’s fingerprint matches the origi- to deliver electronic fingerprints Although neither the trusted nal key’s fingerprint is a much faster also seems risky against capable ad- third-party nor fingerprint solutions way to verify the key’s authenticity. versaries. In the end, if you can’t in their current forms seem suffi- The recently proposed concept of key continuity management (KCM)3,4 is an emerging alternative to the CA- In the end, if you can’t verify fingerprints based approach. KCM posits that once Bob has verified a key’s finger- in person, it seems safest to verify them over prints, he can be sure that the key he uses for encryption is the same one the phone. he’s verified in the past. Users needn’t rely on an elaborate network of CAs verify fingerprints in person, it ciently secure for everyday users, to certify keys. As with SSH, users of seems safest to verify them over the perhaps a hybrid approach is needed email clients are assumed to verify a phone. This is the standard method in the short term. As I suggested newly observed key’s fingerprint, af- of fingerprint verification in voice- with CA-based PKI, everyday users

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 83 Secure Systems

should verify a key’s fingerprints. tribute-based annotations to help 4. S.L. Garfinkel and R.C. Miller, Mechanisms developed for KCM users make better trust decisions “Johnny 2: A User Test of Key Con- can bolster trust in CA-certified keys about their email communication.6 tinuity Management with S/MIME and ensure that users verify finger- Until such usable mechanisms are and Outlook Express,” Proc. Symp. prints to secure communication. introduced into popular email Usable Privacy and Security (SOUPS clients, however, proceed with cau- 05), ACM Press, 2005, pp 13–24. tion and verify those fingerprints. 5. A.J. Nicholson et al.,“LoKey: here are several barriers for every- Leveraging the SMS Network in T day users who wish to secure their Acknowledgments Decentralized, End-to-End Trust communications. S/MIME is sup- The author thanks Scott Rea for his insightful Establishment, Proc. 4th Int’l Conf. ported by popular email clients, but comments and willingness to read multiple Pervasive Computing (Pervasive 06), casual users are lulled into a false drafts of this article. He also thanks Sean LNCS 3968, Springer-Verlag, pp. sense of security; accepting “valid” Smith, Patrick Tsang, and Phoebe Wolfskill 202–219. signatures without comprehending for their helpful comments. 6. C. Masone and S.W. Smith, the underlying trust assumptions or “Towards Usefully Secure Email,” being content with encrypted email References IEEE Technology and Society Maga- without being diligent about finger- 1. IEEE Security & Privacy, special issue zine, to be published, Mar. 2007. print verification highlights the on usable security, vol. 2, no. 5, 2004. mismatch between the user’s expec- 2. S. Haber and W.S. Stornetta, “How Apu Kapadia is a post-doctoral research tations and their communication’s to Time-Stamp a Digital Docu- fellow at the Institute for Security Tech- underlying security. ment,” J. Cryptology, vol. 3, no. 2, nology Studies, Dartmouth College. His On the optimistic front, PKI 1991, pp. 99–111. research interests include systems security and privacy, and he is particularly awareness is increasing—here at 3. P. Gutmann, “Why Isn’t the Inter- interested in anonymizing networks and Dartmouth College, all first-year net Secure Yet, Dammit,” Proc. usable mechanisms for enhancing pri- students are issued PKI tokens, and AusCERT Asia Pacific Information vacy. Kapadia has a PhD in computer sci- research on usability for secure com- Technology Security Conf., AusCERT, ence from the University of Illinois at Urbana-Champaign. He is a member of munication is gaining momentum. May 2004; http://conference.aus the IEEE and the ACM. Contact him at One promising approach uses at- cert.org.au/conf 2004/. [email protected].

Advertising Sales Will Hamilton Email: steve@didierand Representatives Phone: +1 269 381 2156 broderick.com Advertiser | Product Index Fax: +1 269 381 2556 Mid Atlantic Email: wh.ieeemedia@ Northwest (product) March | April 2007 (product/recruitment) ieee.org Peter D. Scott Dawn Becker Phone: +1 415 421-7950 Phone: +1 732 772 0160 Joe DiNardo Fax: +1 415 398-4156 Advertiser Page number Fax: +1 732 772 0164 Phone: +1 440 248 2456 Email: peterd@ Carnegie Mellon University 5 Email: db.ieeemedia@ Fax: +1 440 248 2594 pscottassoc.com ieee.org Email: jd.ieeemedia@ CSINetSec 2007 Cover 4 Southern CA (product) ieee.org John Wiley & Sons, Inc. Cover 2 New England (product) Marshall Rubin Jody Estabrook Southeast (recruitment) Phone: +1 818 888 2407 Nato 3 Phone: +1 978 244 0192 Thomas M. Flynn Fax: +1 818 888 4907 Fax: +1 978 244 0103 Phone: +1 770 645 2944 Email: mr.ieeemedia@ ieee.org *Boldface denotes advertisements in this issue Email: [email protected] Fax: +1 770 993 4423 Email: Northwest/Southern CA New England (recruitment) ﬂ[email protected] (recruitment) John Restchack Tim Matteson Phone: +1 212 419 7578 Southeast (product) Phone: +1 310 836 4064 Fax: +1 212 419 7589 Bill Holland Advertising Personnel Fax: +1 310 836 4067 Email: [email protected] Phone: +1 770 435 6549 Marion Delaney | IEEE Media, Advertising Director Fax: +1 770 435 0243 Email: tm.ieeemedia@ Connecticut (product) Email: ieee.org Phone: +1 415 863 4717 | Email: [email protected] Stan Greenﬁeld [email protected] Japan Phone: +1 203 938 2418 Tim Matteson Fax: +1 203 938 3211 Midwest/Southwest Marian Anderson | Advertising Coordinator Phone: +1 310 836 4064 Email: (recruitment) Phone: +1 714 821 8380 | Fax: +1 714 821 4010 Fax: +1 310 836 4067 [email protected] Darcy Giovingo Email: [email protected] Phone: +1 847 498-4520 Email: tm.ieeemedia@ Midwest (product) Fax: +1 847 498-5911 ieee.org Dave Jones Email: [email protected] Europe (product) Sandy Brown Phone: +1 708 442 5633 Hilary Turnbull IEEE Computer Society | Business Development Manager Fax: +1 708 442 7620 Southwest (product) Phone: +44 1875 825700 Email: dj.ieeemedia@ Steve Loerch Phone: +1 714 821 8380 | Fax: +1 714 821 4010 Fax: +44 1875 825701 ieee.org Phone: +1 847 498 4520 Email: [email protected] Fax: +1 847 498 5911 Email: impress@impress media.com

84 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007