Easy PGP

1. Easy PGP Rick Carback, Emily Fetchko, Bryan Pass University of Maryland, Baltimore County 11-30-2005

2. Easy PGP • More users were: • Able to complete given tasks correctly • Willing to use our extension in the future • Inability to make dangerous errors

3. Overview • Motivation • New and Significant • Related Work • Making Easy PGP • Survey • Survey Results • Issues • Tradeoffs and Limitations • Easy PGP Vision/Future Work • Conclusions

4. Motivation • Keys are hard to create and manage • Average user • Unlikely to understand purpose of keys • May not make appropriate decisions • People do not like following directions • “Blinking 12:00” • “Terms and Conditions” • Rebates & Product Registration

5. E-mail Encryption is a pain to get working!

10. Should it really be this hard? • Put yourself in a User’s shoes… • What is a Digital ID? • Shouldn’t I have one through hotmail or msn already? • Why does my recipient need one? • Software was current (all patches applied) • Shouldn’t they have fixed this if people actually used it? • How many people regularly use E-mail encryption? • Only 3 (of 20), ever, in our study • 1 continues to use it • Clearly it is too much hassle for its benefits!

11. New and Significant • “E-mail Encryption your grandma can use!” • Idea of e-mail encryption as a web service • “Will people use this?” Vs. “How well can people use this?” • Secure, seamless key generation and management system • Completely transparent to user

12. Related Work - Lessons Learned • Private Keys Aren’t • User’s typically copy them whenever and wherever needed • Especially if paid for • Options for insecurity • Left as an exercise for the user • Random Data?

13. Tested PGP 5.0 Considered the best UI out there 1 of 12 used it correctly Most would not use it on their own. Definition: Usable Security Software Required tasks are known Tasks can be done No dangerous errors Continued use Related Work - Why Johnny Can’t Encrypt

14. Related Work - Johnny 2 • Key management • BIG problem in usability • Simulated Key Continuity Management running a test similar to Johnny • Better task comprehension • Uncovered trust issues • Did Not: • Say if users would use it • Have a working prototype

15. Related Work - Verisign • Provides Keys • Need to follow directions • Key server • Requires user to point to it • Local key management still a pain to set up and use • What about keys that are not from Verisign? • User is still unlikely to understand the purpose of keys • We do not think they need to know

16. Related Work - STU III • “Push Button Security” for Phone • Exactly what we want for E-mail • We envision extending Easy PGP • Interoperability with existing key servers • Web service so users can set their options and send from anywhere

17. Related Work - Enigmail • PGP Extension for Thunderbird (aka Sunbird/Firebird, based off of Mozilla/Netscape Communicator) • Front-end for GPG • Used as base for and tested against Easy PGP

18. Problems with Enigmail • Encourages bad decisions • Too many options • Why can’t • We use our e-mail password by default? • A key be generated in the background? • With most secure options chosen by default

19. Making Easy PGP • Extension Communicates with PHP script • Script is an interface to GPG (OpenPGP) • Just like Enigmail • Keys stored at server • Encryption happens at server

20. Building the Extension • Extension built in XUL - a scripting language for mozilla • Not as robust as advertised • Combines XML, javascript, and CSS • Has a large learning curve associated with it • Two interfaces • Message Composing • Message Displaying

21. Message Composer

22. Message Display

23. Code to send message • var cmdStr = "https://130.85.179.253/~bryan/ez_pgp.php?action=" + action + "&"; • cmdStr += "sender=" + gCurrentIdentity.email + "&"; • cmdStr += "receiver="; • cmdStr += getBasicRecipientEmails(gMsgCompose.compFields.to); • cmdStr += "&message="; • var editor = GetCurrentEditor(); • gEzPgpPageReq = new XMLHttpRequest(); • cmdStr += ezPgpSendableMessage(editor.rootElement.innerHTML); • gEzPgpPageReq.open("GET", cmdStr, false); • editor.rootElement.innerHTML = ""; • gEzPgpPageReq.send(null); • editor.insertText(gEzPgpPageReq.responseText);

24. Header Element Example • <?xml version="1.0"?> • <?xml-stylesheet href="chrome://ezpgp/content/messageSafety.css" type="text/css"?> • <overlay xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" • xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> • <vbox id="messagepanebox"> • <hbox id="msgSafetyView" insertafter="msgHeaderView" keywordrelated="true" originalclass="none" persist="state"> • <vbox flex="1"> • <!-- Collapsed Pane Details, shows the "short" safety message --> • <!-- Expanded Pane Details, shows the "long" safety message --> • </vbox> • </hbox> • </vbox> • <script type="application/x-javascript" src="chrome://ezpgp/content/msgSfeViewOverlay.js"/> • </overlay>

25. Button CSS Example • toolbarbutton#easypgpencrypt-button • { • list-style-image: url("chrome://messenger/skin/messengercompose/compose-toolbar.png"); • -moz-image-region: rect(0px 120px 24px 96px); • } • toolbarbutton#easypgpsign-button • { • list-style-image: url("chrome://messenger/skin/icons/mail-toolbar.png"); • -moz-image-region: rect(0px 48px 24px 24px); • }

26. PHP Script • case 'encrypt': • exec( "gpg --homedir $GPG_HOME --no-tty --encrypt -a -r $receiver -o $outfile $infile 2>&1",$output,$ret ); • break; • case 'decrypt': • exec( "echo \"defaultpassword\" | gpg --homedir $GPG_HOME --no-tty --passphrase-fd 0 --decrypt -u $receiver -o $outfile $infile 2>&1",$output,$ret ); • break;

27. Survey • Four Parts • Pre-Questionnaire • E-mail Disclaimer • Directions • Post-Questionnaire • Notes were taken during every trial • Approx. completion time for each step • Things users had trouble with • Other Comments

33. Survey Results • Correct Identification • Enigmail: 90% • EasyPGP: 97% • Ease of Use:

34. Survey Results (cont.) • Avg Time to Complete (minutes): • Enigmail: 11.9,  = 4.969 • EasyPGP: 3.5,  = .806 • Continued Use: • Enigmail: 2.7,  = .781 • EasyPGP: 3.6,  = .663

35. Issues • Is https secure enough? • Keys are no longer private if http server compromised • Only message contents in transit affected if SSL is vulnerable • Will it scale? • Inter-server communication • Trust issues are more prevalent here • No user verification, yet

36. Tradeoffs and Limitations • Must unconditionally trust server • User choice is limited to what we choose • Service depends on network connectivity • DoS • Centralization makes encryption server a target • Security and Integrity of system must be maintained • Account hijacking

37. Easy PGP Vision/Future Work • Web Service • Spread by users • “Want to read this message? Click here!” • “Invite a friend!” • Funded by Advertisement (Google, Yahoo, Hotmail, etc). • More options for advanced users • Preferred algorithm, multiple key levels, etc. • Trust levels • Identity Verification • User as untrusted until identity can be verified in some way • Post card to listed address • Public Records Lookup • Could be a “premium service”

38. Conclusions • All e-mail encryption can be made easier • Not just PGP • Interface is not the issue • Setup and maintenance are! • Security as a Web Service

39. References • Lessons Learned in Implementing and Deploying Crypto Software, Peter Gutmann, USENIX Security ‘02 • Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0, A. Whitten and J. D. Tygar • Johnny 2: A User Test of Key Continuity Management with S/MIME and Outlook Express, S. Garfinkel and R. Miller