Easy PGP
Rick Carback, Emily Fetchko, Bryan Pass
University of Maryland, Baltimore County
11-30-2005
Easy PGP

More users were:



Able to complete given tasks correctly
Willing to use our extension in the future
Inability to make dangerous errors
Overview










Motivation
New and Significant
Related Work
Making Easy PGP
Survey
Survey Results
Issues
Tradeoffs and Limitations
Easy PGP Vision/Future Work
Conclusions
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
E-mail Encryption is a pain to
get working!
Should it really be this hard?

Put yourself in a User’s shoes…




Software was current (all patches applied)


What is a Digital ID?
Shouldn’t I have one through hotmail or msn already?
Why does my recipient need one?
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!
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
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?
Related Work - Why Johnny
Can’t Encrypt

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 - Johnny 2

Key management


Simulated Key Continuity Management
running a test similar to Johnny



BIG problem in usability
Better task comprehension
Uncovered trust issues
Did Not:


Say if users would use it
Have a working prototype
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
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
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
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
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
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
Message Composer
Message Display
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);
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>
Button CSS Example










toolbarbutton#easypgpencrypt-button
{
list-style-image:
url("chrome://messenger/skin/messengercompose/composetoolbar.png");
-moz-image-region: rect(0px 120px 24px 96px);
}
toolbarbutton#easypgpsign-button
{
list-style-image: url("chrome://messenger/skin/icons/mailtoolbar.png");
-moz-image-region: rect(0px 48px 24px 24px);
}
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;
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
Survey Results

Correct Identification



Enigmail: 90%
EasyPGP: 97%
Ease of Use:
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
Issues

Is https secure enough?



Will it scale?



Keys are no longer private if http server
compromised
Only message contents in transit affected if SSL is
vulnerable
Inter-server communication
Trust issues are more prevalent here
No user verification, yet
Tradeoffs and Limitations

Must unconditionally trust server


Service depends on network connectivity


User choice is limited to what we choose
DoS
Centralization makes encryption server a
target


Security and Integrity of system must be
maintained
Account hijacking
Easy PGP Vision/Future Work

Web Service

Spread by users




Funded by Advertisement (Google, Yahoo, Hotmail, etc).
More options for advanced users



“Want to read this message? Click here!”
“Invite a friend!”
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”
Conclusions

All e-mail encryption can be made
easier


Interface is not the issue


Not just PGP
Setup and maintenance are!
Security as a Web Service
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
Descargar

Easy Pgp - University of Maryland, Baltimore County