May 22, 2015

avatar

Why King George III Can Encrypt

[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.

Comments

  1. avatar dr2chase says:

    Can you please help King George configure a VPN next? It’s a confusing pain in the royal posterior.

  2. “That’s right, you verify my signature using the same object that you use to encrypt messages you send to me.”

    No, no, no! You most certainly do not! You sign messages using your signing key and you verify signatures using the signer’s verification key. You never, ever, EVER sign messages using your private decryption, nor do you verify signatures using the signer’s public encryption key.

    The only instance I can think of where it would even be possible to make this mistake is with vanilla RSA, in which case it would be a very serious blunder, indeed!

  3. I remember talking to Wenley and Sebastian about this! I did a similar project in the fall. I think this is a cool story, but I think the major problem is that these metaphors don’t make it any easier to convey important concepts about the security properties of PGP. How do you explain to a user that anyone could make a ‘lock’ and a ‘seal’ in your name? How do you explain the web of trust or other methods for actually verifying the identity of the key holder? It actually doesn’t seem too hard to explain how public key encryption can work, the problem is in explaining all of the other functions and intricacies that go into a PGP client. If only we could make THAT simpler.

    • avatar Seth Schoen says:

      Another source of stress on the metaphor might be to ask how King George got ahold of the padlocks of his generals, and how he can get more of them if he needs to send subsequent messages.

      Indeed, the king might worry that colonial agents are trying to send him a whole bunch of counterfeit padlocks—engraved with the generals’ names, but not actually belonging to the generals. When he sends a box locked with such a padlock, colonial agents will unlock it, read the orders, and then re-lock it with a genuine padlock belonging to the receipient.

      We could call this the Minuteman-in-the-middle attack.

      (The metaphor does actually seem to be useful in this case, on reflection, because you can at least have the conversation about it and talk about the problem of finding a trustworthy channel through which the king can get authentic padlocks. A weird thing is that he only needs one authentic padlock per general, because they’re actually digital padlocks and he can copy them at no cost.)

      • avatar Zooko Wilcox-O'Hearn says:

        Yes! This isn’t an example of the metaphor failing to convey the issues to the layman, this is an example of the metaphor succeeding at conveying the issues to the expert!

        (Seth being an expert.)

        Regards,

        Zooko

    • avatar Jonathan says:

      I think Seth’s parenthetical has precisely the right idea. It isn’t necessarily that the metaphors themselves solve any problems, but that they supply a language that is far more conducive to discussion of these ideas. The chosen metaphors are clearly not perfect and fail to take into account a number of important scenarios that can take place in metaphor-world but not in actual encrypted email (running out of locks, losing a key but not a seal, etc.). The key take-away, though, is that they serve as a framework through which we can far more easily explain and intuit about the security properties and attack scenarios of PGP. Given enough time and energy, we could certainly improve on the suggested metaphors – the interesting piece of this project, though, is exploring what we gain by doing so.

  4. avatar Zooko Wilcox-O'Hearn says:

    The object-capability community uses an abstraction of “Sealers and Unsealers” to represent public key cryptography to the programmer:

    erights.org/elib/capability/ode/ode-capabilities.html#rights-amp

  5. avatar Andy Feit says:

    Couldn’t agree more that it is almost entirely about usability. And the idea of a new metaphor for how this all works is quite interesting. As less technical users attempt to use tools like PGP (think about the busy doctor emailing a user with AOL or Yahoo! mail), it would be great if we could provide a framework for discussing how these things work, that does not require reading a white paper first.

    One thing we are trying to do at Enlocked is to simplify (or even hide, when possible) the whole process of creating keys, moving them to various devices, and authenticating the user. Never mind the whole step of getting compatible software on your work laptop, smartphone, tablet and that old home machine. Really, in order for encryption to achieve broad-based adoption, users should not even have to know there is a key at all, and sending or reading a secure message needs to be as friction-free as with a message in the clear.

    We think we’ve made good progress on this front, although there is still room for improvement…. check it out at http://www.enlocked.com

  6. avatar PopeRatzo says:

    Very good ideas. Easy to use encryption is this decade’s killer app.

    While you’re at it, can you make it so that I don’t have to trust the maker of the encryption in order to successfully use it? Make it open source, of course.

  7. First of all, I totally agree there is a usability issue with crypto, and the metaphore described here is an interesting approach.

    Over the past year or so, I’ve been considering a very different aproach to this issue: simplifying the *goals* so there is less to learn up front. Specifically, I’ve been toying with the idea of writing a firefox extension that used GPG’s *signing* capability only. Sign your posts anywhere, and other people can veirfy you were the author pinning their copy of the public key.

    In my (unfortunately limited) tests with trying to explain this concetp to peole new to crypto, this one-way process has a huge advantage over trying to explain public-key-crypto as it is usually used: you don’t have to confuse the issue by explaining how the key pairs work in both directions. Only the bit about the king’s imprint and the resulting well-known seal has to be explained.

    If that king of tool became widely used, it would be a LOT easier to explain the additional “reverse” use of the keys to for protecting against eavesropping. Being able to utilize an already-exisitng network of public keys would probably make that half of the explanation even easier, too.