[This is a guest post by Wenley Tong, Sebastian Gold, Samuel Gichohi, Mihai Roman, and Jonathan Frankle, undergraduates in the Privacy Technologies seminar that I offered for the second time in Spring 2014. They did an excellent class project on the usability of email encryption.]
PGP and similar email encryption standards have existed since the early 1990s, yet even in the age of NSA surveillance and ubiquitous data-privacy concerns, we continue to send email in plain text. Researchers have attributed this apparent gaping hole in our security infrastructure to a deceivingly simple source: usability. Email encryption, although cryptographically straightforward, appears too complicated for laypeople to understand. In our project, we aimed to understand why this problem has eluded researchers for well over a decade and expand the design space of possible solutions to this and similar challenges at the intersection of security and usability.
Most notably, in 1999, Alma Whitten and J. D. Tygar challenged 12 people to properly send and receive secure email using then-standard software. The resulting, now-classic paper, Why Johnny Can’t Encrypt, details the hilarious yet horrifying struggles of these participants. Whitten and Tygar concluded that the terminology of PGP, couched in metaphors coined decades earlier by cryptography researchers, was poorly integrated into the visual language of the encryption programs themselves. Users who managed to understand these metaphors still struggled to translate their knowledge into actions. In her PhD dissertation, Whitten designed her own email client with these concepts in mind, wrapping existing metaphors in a better user-interface.
We hypothesized that the flaw might lie deeper, with the metaphors themselves. In PGP’s metaphors, each user posses two items, a private key and a public key. Have you inferred how the protocol works yet? Unless you have previous exposure to cryptography, likely not. Why do I have two keys? What do these keys open? Aren’t all keys private? When you want to send a message to someone, you encrypt it with his public key, which is known to everyone. The recipient can decrypt it with his private key, which only he possesses. But can’t anyone use the public key to decrypt the message again? Nope. A public key can only encrypt, not decrypt. Just trust us on that one. You’re probably starting to understand why secure email is so hard to use. Bear with us for one paragraph longer.
Now that we’ve taken care of encryption, we want to ensure one more security property: authenticity. Did the message come from me or someone pretending to be me? To prove I am who I claim to be, I sign all messages I send with my private key. Wait a minute – how do you possibly sign something with a key? Finally, you can make sure my signature is valid by checking it with my public key. That’s right, you verify my signature using the same object that you use to encrypt messages you send to me. Mathematically, this makes perfect sense. Metaphor-wise, it’s a nightmare, and we haven’t even discussed key distribution or revocation.
We decided to test whether better metaphors might be able to close this gap between security and usability. Specifically, we wanted metaphors that represented the cryptographic actions a user performs to send secure email and were evocative enough that users could reason about the security properties of PGP without needing to read a lengthy, technical introduction. We settled on four objects: a key, lock, seal and imprint. To send someone a message, secure it with that person’s lock. Only this recipient has the corresponding key, so only they can open it. To prove your identity, stamp the message with your seal. Since everyone knows what your seal’s imprint looks, it’s easy to verify that the message came from you.
As we prepared to test our ideas on users, we discovered another advantage of our metaphor choices: the actions that they evoke make as much sense in the physical world as they do when sending secure email. We realized that these metaphors released us from having to explain PGP using the same dry, technical style of documentation that we needed to demystify public and private keys. We therefore decided to explore, not just the design space of new metaphors, but also of documentation. We captured our metaphors in the form of a fictionalized historical narrative about King George III and his colonial empire, where his system of keys, locks, seals, and imprints ensured that his letters remained safe from enemy hands:
King George III set aside his quill, having completed secret orders to put down the rebellion. It was imperative that they remain secure, visible only to Generals Gage and Howe. The King opened a cabinet in the wall behind him, revealing hundreds of locks each labelled with the name of a British General. Selecting one with “Gage” engraved on the side, the King placed his orders for General Gage in an impregnable metal box and secured it shut with the lock. Since only General Gage possessed the corresponding key, the King knew that the orders were secure from prying eyes. After doing the same for General Howe, King George marked the boxes with his royal seal, whose imprint was known throughout the world. Anyone who received the message could now be sure it came from the King. Several weeks later, two metal boxes arrived on the King’s desk, one bearing the unforgeable imprint of General Gage’s seal and the other of General Howe’s. Both boxes were bound shut with locks engraved with “His Majesty King George III” on their sides. The King unlocked the boxes with his personal key, revealing two identical documents: “It is done.”
This style of introduction is engaging, concise, and implicitly demonstrates the process for sending secure email by example. More interestingly, it places our metaphors in an internally-consistent fictional universe, giving users the ability to reason about the security properties of PGP beyond scenarios specifically addressed in our documentation. The natural extension of this idea might be to describe secure email in a comic strip, simultaneously introducing visual motifs from an accompanying user-interface.
We put these ideas to the test by developing a quiz that measured a subject’s ability to understand and reason about secure email. We gave different groups of users various forms of documentation, stretching from a technical introduction of traditional PGP metaphors to a narrative that did little more than show our new objects in use. Our results indicated that the new metaphors themselves were no more effective than public and private keys, but that far less documentation was necessary to achieve an equivalent level of understanding (196 words in the shortest narrative in comparison to 718 for a complete introduction to PGP). Since public and private keys have no analogs in the physical world, it is impossible to apply these methods without new metaphors. Intuition suggests that shorter and more engaging instructions are more likely to be read, improving the odds that user understanding is such that PGP becomes usable. Better metaphors themselves do not directly achieve this goal, but they enable new approaches to teaching that bring usable secure email into the realm of possibility.
We would like to acknowledge the many people who generously contributed their time, energy, and resources to assist in this study. Professor Lorrie Cranor shared her tremendous expertise in conducting user studies, providing advice that formed the basis of our experimentation. Professor Arvind Narayanan, in addition to teaching the class that facilitated this project and advising us at key junctures, furnished the funding that made our testing possible. Finally, our families kindly spent countless hours reviewing and copy-editing drafts of our paper in the days prior to submission.