UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

How to exchange email securely with Johnny who still can’t encrypt Woo, Wing Keong 2006

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2006-0714.pdf [ 3.74MB ]
Metadata
JSON: 831-1.0064951.json
JSON-LD: 831-1.0064951-ld.json
RDF/XML (Pretty): 831-1.0064951-rdf.xml
RDF/JSON: 831-1.0064951-rdf.json
Turtle: 831-1.0064951-turtle.txt
N-Triples: 831-1.0064951-rdf-ntriples.txt
Original Record: 831-1.0064951-source.json
Full Text
831-1.0064951-fulltext.txt
Citation
831-1.0064951.ris

Full Text

HOW TO EXCHANGE EMAIL SECURELY WITH JOHNNY WHO STILL CAN'T ENCRYPT by Wing Keong Woo B.Sc, National University of Singapore, 1993 B.Sc. (Hons), National University of Singapore, 1994 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in The Faculty of Graduate Studies (Electrical and Computer Engineering) UNIVERSITY OF BRITISH COLUMBIA August 2006 © Wing Keong Woo, 2006 ABSTRACT Some of us might have had this experience: because of privacy concerns, we decided to use PGP or S/MEVIE for secure email communications. After making the effort to learn the concept of public key cryptography and generate key-pairs for ourselves, we realized that we could not proceed because most of our correspondents did not have a key to start with. It would be difficult to convince them to similarly adopt PGP or S/MEVIE. Eventually we dropped the idea and reverted to sending emails in the clear. This thesis presents a novel solution to this three decade old problem. All currently known solutions are greatly influenced by the traditional mindset of relying on the trusted distribution of public keys to achieve secure communications. Unfortunately, these solutions are faced with the difficult problems of public key distribution and revocation, and have not been commonly adopted as is evident from the predominance of clear emails we are still receiving today. We deviate from the traditional mindset and propose a new approach of using the concept of secure key exchange to design a secure email solution. We design a protocol called EKEmail to specifically cater for the non-interactive email environment which is complicated by the possibilities that email messages may be lost, not read in the order received, or not replied to at all. We have implemented our solution and demonstrated that it works seamlessly within the existing email infrastructure. To begin secure email communications, the only requirement is for the two communicating parties to agree on a one-time shared password. Users are allowed to choose any password of their choice, even if it is considered poor, without the worry of dictionary attack. In addition, EKEmail supports automatic and transparent key refresh with perfect forward secrecy, hence simplifying the use of short-lived keys. Besides providing privacy, EKEmail also supports the off-the-record property which is desirable for casual email conversations. Our solution allows users to enjoy secure email communications with minimal inconvenience. ii TABLE OF CONTENTS Abstract ii Table of Contents iii List of Tables v List of Figures vi Acknowledgements viii CHAPTER I Introduction 1 1.1 The Grand Challenge 1 1.2 The Different Needs for Usability and Security 2 1.3 Potential Invasion of Privacy with Clear Emails 4 1.4 Original Contributions 5 CHAPTER II A Tale of Johnny 8 2.1 1985: Privacy Enhanced Mail (PEM) .' 8 2.2 1991: Pretty Good Privacy (PGP) 9 2.3 1995: Secure Multipurpose Internet Mail Extension (S/MEVIE) 10 2.4 1999: Johnny Can't Encrypt 11 2.5 2004: Whitten's PhD Thesis - Lime 11 2.6 2005: Garfmkel's PhD Thesis - Stream and CoPilot 12 2.7 2006: Johnny Still Can't Encrypt 14 CHAPTER III Traditional Approach: Using Public Key Distribution 15 3.1 Secure Email based on Public Key Distribution 15 3.2 The Adversarial Model 16 3.3 Trusted Third Party (TTP) 17 3.4 X.509 Public Key Infrastructure (PKI) 17 3.5 PGP Web-of-Trust 20 3.6 The Concept of Key Continuity (KC) 22 3.7 Identity-Based Cryptography (IBC) 23 3.8 The Limits of Traditional Approach 24 CHAPTER TV Proposed New Approach: Using Secure Key Exchange 26 4.1 Proposing Secure Email based on Secure Key Exchange 26 4.2 The Problem with Diffie-Hellman Key Exchange (DH-KE) 27 4.3 The Authenticated Key Exchange (AKE) 29 4.4 The Concept of Password Authenticated Key Exchange (PAKE) 30 4.5 The Diffie-Hellman Encrypted Key Exchange (DH-EKE) 31 CHAPTER V The Design of EKEmail Protocol 35 5.1 Designing EKEmail Protocol 35 5.2 Phase 1: EKEmail Request 36 5.3 Phase 2: EKEmail Grant 37 5.4 Phase 3: EKEmail Secure 38 5.5 Analyzing EKEmail Protocol 38 5.6 Key Refresh with Perfect Forward Secrecy 40 • 5.7 The Off-The-Record Property 43 5.8 Modeling EKEMail Protocol with Statechart 43 5.9 Handling Exceptions and Race Conditions 44 5.10 Optional: Using Separate Key for Secure Email Storage 46 CHAPTER VI The Implementation of EKEmail Protocol 47 6.1 Designing New EKEmail MIME Type 47 6.2 The Phase 1 EKEmail MIME Message 48 6.3 The Phase 2 EKEmail MIME Message 49 6.4 The Phase 3 EKEmail MIME Message 50 6.5 Choosing Cryptographic Algorithms 51 CHAPTER VII An Implementation of EKEmail Client 54 7.1 The Architecture of EKEmail 54 7.2 The Security of EKEmail for Alice 55 7.3 The Usability of EKEmail for Johnny 58 7.4 The Transparency of Key Refresh 59 CHAPTER VIII Conclusions and Recommendations for Future Work 62 8.1 Conclusions 62 8.2 Recommendations for Future Work 63 Bibliography 64 iv L I S T O F T A B L E S Table 6.1 Cryptographic suite used in EKEmail protocol version 0.1 53 V L I S T O F F I G U R E S Figure 1.1 Types of emails exchanged between secure-email and clear-email users : 3 Figure 1.2 Grand challenge to enable secure-email users to communicate securely with clear-email users 4 Figure 2.1 Enigmail's key management module simplifies key generation, and uploading/downloading of PGP public keys from PGP key server 9 Figure 2.2 Mozilla Thunderbird's certificate management module facilitates the import of public certificates 11 Figure 3.1 The search results for PGP keys of Philip Zimmermann, the creator of PGP 21 Figure 4.1 Exchange of messages between Alice and Bob executing DH-KE protocol 28 Figure 4.2 An attacker Mallory conducting MITM attack against Alice and Bob executing DH-KE protocol 29 Figure 4.3 Exchange of messages between Alice and Bob executing partial DH-EKE protocol 32 Figure 4.4 Exchange of messages between Alice and Bob executing complete DH-EKE protocol to prevent replay attack 34 Figure 5.1 Components of Phase 1 EKEmail Request message 36 Figure 5.2 Components of Phase 2 EKEmail Grant message 37 Figure 5.3 Components of Phase 3 EKEmail Secure message 38 Figure 5.4 Mallory's unsuccessful MITM attack against Alice and Johnny executing EKEmail protocol 39 Figure 5.5 Components of EKEmail Refresh Request message 40 Figure 5.6 Components of EKEmail Refresh Grant message 41 Figure 5.7 Statechart model describing the behavior of EKEmail protocol in an ideal situation 44 Figure 5.8 Statechart model describing the behavior of EKEmail protocol with exceptions handling 45 Figure 6.1 Components of Phase 1 EKEmail MEVIE message 49 Figure 6.2 Components of Phase 2 EKEmail MEVIE message 50 Figure 6.3 Components of Phase 3 EKEmail MEVIE message 51 Figure 7.1 The architecture of EKEmail 54 Figure 7.2 The GUI of our EKEmail client 55 Figure 7.3 Alice enters her agreed password with Johnny to initiate an EKEmail request message 56 Figure 7.4 The statechart associated with Johnny after Alice sends an EKEmail Request message 57 Figure 7.5 The statechart associated with Johnny after Alice receives his EKEmail Grant message 57 Figure 7.6 Johnny enters his agreed password with Alice to receive her EKEmail request message 58 vi Figure 7.7 The statechart associated with Alice after Johnny receives her EKEmail Request message 59 Figure 7.8 The statechart associated with Johnny in Alice's EKEmail client after it automatically initiates a Refresh Request message 60 Figure 7.9 The statechart associated with Alice in Johnny's EKEmail client after her Refresh Request message is read 60 Figure 7.10 The statechart associated with Johnny in Alice's EKEmail client after his Refresh Grant message is read 61 vii A C K N O W L E D G E M E N T S Foremost, I would like to thank my supervisor Prof. Cyril Leung for his advises during the course of this research. I really appreciate him for spending his precious time, especially during his vacation, in reading and providing me with valuable comments on earlier versions of this thesis. In addition, I would like to thank my colleagues A/Prof. Francis Lee and A/Prof. C T . Lau in Nanyang Technological University, Singapore, who are always there ready to offer their support and help. viii C H A P T E R I I n t r o d u c t i o n 1.1 The Grand Challenge In 1976, Diffie and Hellman introduced the concept of public key cryptography [DH76] which offered the possibility that any user, e.g. Alice, could send secure messages to any other user, e.g. Bob, by enciphering her messages using his public key retrieved from a public directory. Thereafter, international efforts were spent developing standardized secure email solutions such as PEM [RFC 1421], S/MBVIE [RFC3851] and OpenPGP [RFC2440] to facilitate the use of secure messaging. However, 30 years later, most email messages are still being sent in the clear. The difficult problem of secure key distribution required by classical secret key cryptography has now been replaced by another difficult problem, namely that of trusted key distribution required by public key cryptography. How can we guarantee that a public key really belongs to the claimed user? To address this problem of trusted key distribution, two prominent solutions which have been developed are the X.509 Public Key Infrastructure (PKI) [RFC3280] and the concept of web-of-trust introduced by Pretty Good Privacy (PGP) [Zim95]. However, neither has been commonly accepted in practice. In 1999, Whitten and Tygar conducted a study [WT99] to understand why secure email solutions such as PGP are rarely used. They concluded that usability was the problem. In 2003, the Computing Research Association (CRA) organized a conference on "Grand Research Challenges in Information Security and Assurance". At the end of the conference, one of the four grand challenges identified was to "give end-users security control they can understand and privacy they can control." [CRA03] In this thesis, we study the problem of designing and implementing an email solution that is as secure as that offered by PGP [Zim95] or S/MEVIE [RFC3851], and yet is as easily usable as current clear email systems. 1 1.2 The Different Needs for Usability and Security Some of us might have had this experience: because of privacy concerns, we decided to use PGP or S/MEVIE for secure email communications. After making the effort to learn and generate key-pairs for ourselves, we realized that we could not proceed because most of our correspondents did not have a key to start with. It would be difficult to convince them to similarly adopt PGP or S/MIME. Eventually we dropped the idea and reverted to sending emails in the clear. The above scenario highlights a special challenge of secure email solutions. To be acceptable, any proposed solution must simultaneously satisfy the needs of both communicating parties, which may differ widely. Broadly, we may classify users into two groups: secure-email and clear-email users. Users who send a mixture of secure and clear emails may be classified into the secure-email group since they are able to enjoy secure emails if they wish to. Secure-email users tend to have a high tolerance for poor usability but a low tolerance for poor security. For their privacy needs, this group of users is willing to use PGP or S/MEVIE. On the other hand, clear-email users tend to have a high tolerance for poor security but a low tolerance for poor usability. When secure-email and clear-email users communicate with one another, the following four scenarios are possible: 1. When a secure-email user communicates with another secure-email user, they are able to email securely using PGP or S/MEVIE. Their needs are met and there is no requirement for another email solution. 2. When a clear-email user communicates with another clear-email user, they are able to email in the clear, maybe sometimes even exchanging private information like personal credit card numbers. Nevertheless, their needs are met and there is no requirement for another email solution. 2 3. When a clear-email user sends email to a secure-email user, he will likely not know or bother to look for the public key of the secure-email user, but will likely send email in the clear. In this case, the need of the clear-email user is met, but that of the secure-email user is not. There is a need for an easily usable, yet secure email solution. 4. When a secure-email user sends email to a clear-email user, he will have no choice but to email in the clear since the clear-email user does not even have a public key. Again, there is a need for an easily usable, yet secure email solution. Figure 1.1 summarizes the four scenarios, which clearly shows that secure emails are exchanged only among secure-email users. It is pointless to design a solution which does not meet the needs of users. Only the last two scenarios require a new solution to solve the problem of mismatch in the different needs for security and usability between the secure-email and the clear-email users. If such a solution is available, then secure-email users will be able to communicate securely with clear-email users as shown in Figure 1.2. This is the problem to be addressed in this thesis. Figure 1.1: Types of emails exchanged between secure-email and clear-email users 3 S e c u r e G U e a f e m a i l s S e c u r e C l e a r e m a i l s Figure 1.2: Grand challenge to enable secure-email users to communicate securely with clear-email users 1.3 Potential Invasion of Privacy with Clear Emails Although some people may consider secure-email users to be paranoid, the potential for invasion of personal privacy in clear emails can be real and scary. For example, the Federal Bureau of Investigation (FBI) in the United States once installed Carnivore [SobOl] at the Internet Service Providers (ISPs); this effort is reported to have been abandoned in 2005 in favor of better commercially available software. Basically, Carnivore is a surveillance tool allowing law-enforcement agencies to intercept emails and other electronic communications. It has generated some controversies due to the ease with which it can be used to collect private communications not authorized by any court order, thereby violating the U.S. Fourth Amendment. Following the collapse of Enron Corporation in 2001, hundreds of thousands of emails from Enron executives and employees were made public during the legal investigation. Many of these emails are personal messages, and their releases are potential violation of personal privacy. Presently, these emails have proven valuable for research into email classifications [KY04]. In addition, these emails are also available to anyone for any purpose at http://www.enronemail.com. In 2004, Google launched an experimental email service called Gmail. The service entices users with seemingly unlimited free storage space to store all their emails. However, in exchange, Google has the right to scan their emails for targeted advertisements. In fact, Google may keep all their emails even if users explicitly delete them or terminate their accounts. It can be scary to know that now our emails are becoming 4 eternal. There is nothing preventing Google from building a profile of their users. The privacy of non-users of Gmail can also be violated if they correspond with users of Gmail. The launch of Gmail has generated much controversy. The California state Senate has even rushed to pass a bill to restrict what Gmail is allowed to do. In response, Google, highlighted the true problem with clear emails: "Let's face it, there are issues with email privacy, and these issues are common to all email providers ... There exists a real opportunity for misuse of your information by governments, as well as your email provider ... The only alternative is to avoid new technology altogether, and forego the benefits it provides." [Goo04] It seems irresponsible to advise users to forego their privacy in order to benefit from new technology, or to forego the benefits of new technology because of privacy concerns. Rather, we should design an email solution that is as secure as that offered by PGP or S/MEVIE, and yet is as easily usable as current clear email systems. 1.4 Original Contributions This thesis has identified the problem that presently, secure-email users have to forego privacy in order to communicate with clear-email users as shown in Figure 1.1. There is a need for a solution that is as secure as PGP or S/MEVIE to meet the needs of secure-email users, and yet is as easily usable as the current email systems so that clear-email users will readily use it. Secure-email users will then be able to communicate securely with clear-email users as shown in Figure 1.2 This thesis presents a novel solution to the problem, hence enabling users to embrace the benefits of new technology without foregoing their privacy. The main contributions of this thesis are as follows: 5 1. A new approach using the concept of key exchange to design a novel email solution. • In their seminal paper [DH76], Diffie and Hellman presented the concept of achieving secure messaging by enciphering using the public key of the recipient retrieved from the public directory. It seems difficult to break away from this influential approach, as all the known secure email solutions till today rely on it (Chapter 2). Unfortunately, this approach requires the trusted distribution of public keys, which is a difficult problem, and has introduced usability problems in all current secure email solutions (Chapter 3). After 30 years, most email messages are still being sent in the clear. • In the same paper [DH76], Diffie and Hellman also presented the first protocol for key exchange, which does not require the distribution of public keys, but does require the two communicating parties to interact in order to establish the shared secret key (Chapter 4). However, this requirement conflicts with the normal usage of email, whereby the recipient is most likely not available to interact when the sender wishes to send the email. This may be the reason why not a single known email solution is based on key exchange. • In this thesis, we argue that there is a way to use the concept of key exchange to design a novel solution which overcomes the problem of secure email communications. 2. A design and implementation of EKEmail protocol to demonstrate the feasibility of our new approach. • The concept of key exchange, specifically, the password authenticated key exchange, allows two communicating parties to interact in a secure way to establish a shared secret key with just a simple password. The first such protocol called Encrypted Key Exchange (EKE) [BM92] was proposed by Bellovin and Merritt in 1992. We are able to base our design on this concept, and hence we name our protocol "EKEmail" (Chapter 5). • We design EKEmail protocol to specifically cater for the non-interactive environment of email, which is further complicated by the possibility of emails 6 being lost, not being read in the order received, or not being replied at all while the sender keeps sending them. • To meet security requirements, EKEmail protocol uses the concept of password authenticated key exchange to establish shared secret key securely. In addition, it supports transparent key refresh with perfect forward secrecy, and the off-the-record [BGB04] property which are desirable but difficult to achieve in the current secure email solutions. • To be easily usable, EKEmail protocol only requires that the two communicating parties agree on a one-time password to start-off secure email communications. Users are allowed to choose any password of their choice, even if it is considered poor, without the worry of dictionary attack. The use of passwords is easier than the exchange and verification of public keys in the current secure email solutions. • To achieve widespread acceptance, EKEmail protocol is implemented as a new EKEmail MEVIE type (Chapter 6) which allows it to function seamlessly within the existing email infrastructure. Only email clients need to be upgraded. • Finally, we implement a functioning EKEmail client (Chapter 7) using our EKEmail protocol to demonstrate the feasibility of our novel solution. 7 CHAPTER II A Tale of Johnny 2.1 1985: Privacy Enhanced Mail (PEM) With the invention of public key cryptography, it seemed that the day when everyone would be able to securely exchange emails had arrived. In 1985, the Internet Engineering Task Force (IETF) began an effort to standardize the use of secure emails. The result was the Privacy Enhanced Mail (PEM) standard, first published in 1987 [RFC989], with the final revision published in 1993 [RFC 1421][RFC 1422] [RFC 1423]. PEM was developed before the standardization of X.509 PKI [RFC3280] (Section 3.4). Nevertheless, its concept for the trusted distribution of public keys is similar. Essentially, PEM [RFC 1422] specifies the establishment of a single trusted root, called the Internet Policy Registration Authority (IPRA). The IPRA certifies the Policy Certification Authorities (PCAs), which in turn certifies the Certification Authorities (CAs) under them. Finally, the CAs issue trusted X.509 certificates [X509] to users for their use in PEM. However, the idea of having a single IPRA never materialized. In addition, PEM was developed before the widespread adoption of the Multipurpose Internet Mail Extension (MIME) [RFC2045] standard. As a result, PEM [RFC 1421] only specifies the provision of encryption and signatures for the basic ASCII email messages [RFC822]. This restricted specification is not sufficient to handle emails with different MEME types. PEM has largely been superseded by the S/MEvlE standard described in Section 2.3. 2.2 1991: Pretty Good Privacy (PGP) Pretty Good Privacy (PGP) [Zim95] is an email encryption program first written by P. Zimmerman and was released as open-source in 1991. PGP quickly became quite popular among expert users, likely due to its concept of web-of-trust (Section 3.5) for the trusted distribution of public keys. This enabled users to generate their own key-pairs and experiment with PGP immediately within the existing email infrastructure, without the need to wait for the setup of additional infrastructure support as required by PEM and S/MEME. To ensure interoperability across different email implementations, PGP is standardized as OpenPGP [RFC2440], and implemented as an OpenPGP MIME type [RFC3156] according to the MEVIE security multiparts [RFC 1847] specification. The Free Software Foundation has released an open-source version of OpenPGP called GNU Privacy Guard (GPG). A plug-in called Enigmail has also been developed to integrate GPG into the popular Mozilla Thunderbird email client. To start using PGP/GPG, there is a built-in key management module as shown in Figure 2.1 to assist users with key-pair generation. Thereafter, users may easily upload their public keys to the PGP key server (Section 3.5) for distribution, or search and download their friends' public keys from the server. Alternatively, users may also obtain the public keys directly from their friends and import them explicitly. :..:..v'£>:~-:. .....L. File Edit -View > Key|e?v_erj .^ Genef ate Filter for user' ID's or Refresh Selected Public Keys Search:for; Keys _Account / Usej Alice _<alice@vir;> Refresh Ail Public Keys til.. „„.,—»_•, Philip R. 2immermann,<prz@.... 67A966DD .'p.ubv O Philip R. Zimmermanrv<prz@...• B2D7795E; pob Phiiip-R; Zimmermann ,<prz@.... FAEBD5FC pub f £le it | Iv.Calcuiat,',. 'Owner , , , I Expiry 1 S Figure 2.1: Enigmail's key management module simplifies key generation, and uploading/downloading of PGP public keys from PGP key server 9 Once the necessary public keys are available, automatic encryption and decryption of email messages using PGP/GPG may be configured. PGP Corporation is also actively marketing its PGP email client which is claimed to be easily usable. 2.3 1995: Secure Multipurpose Internet Mail Extension (S/MIME) With the extension of email messages to support the MIME standard [RFC2045], in 1995, RSA Data Security began work on Secure Multipurpose Internet Mail Extension (S/MIME) to provide security over the MIME email. Eventually, this work was migrated to IETF, with the publication of the initial S/MIME version 2 [RFC2311] in 1998, followed by the publication of S/MIME version 3.1 [RFC3850][RFC3851] in 2004. S/MEVIE uses X.509 PKI [RFC3280] (Section 3.4) to support the trusted distribution of public keys. The protection of MIME email is achieved according to the standard Cryptographic Message Syntax (CMS) [RFC3852] specification. Presently, many popular email clients, e.g. Microsoft Outlook and Mozilla Thunderbird, have built-in support for the S/MEvIE standard. To start using S/MEVIE, users first need to apply for their personal trusted certificates from recognized CAs such as VeriSign or Thawte, and import them into their email clients. Figure 2.2 shows the built-in certificate management module in Mozilla Thunderbird to assist users with importing the public certificates. Next, users need to obtain the public certificates from their correspondents directly and import them as well since many CAs do not maintain any server for the distribution of public certificates they issue. Alternatively, as specified in the S/MEVIE standard [RFC3850], the public certificate of a signer is sent together in a signed S/MIME message. Hence, Alice may obtain Bob's public certificate by asking him to send her an S/MEVIE message digitally signed by him. When the email client receives the signed S/MEvIE message, the accompanied public certificate will automatically be imported. 10 . — --• • ••!!•'••":— Your Certificates] other Peppje'sfweb Sites ([Authorities MM -You;have,certificatesfrorn these;orgamzationsthat.identify you:: 6uukup Backup A'l .| 'import Delete Figure 2.2: Mozilla Thunderbird's certificate management module facilitates the import of public certificates Similar to PGP, once the necessary certificates are available, automatic encryption and decryption of email messages using S/MJJV1E may be configured. 2.4 1999: Johnny Can't Encrypt Despite all the efforts to develop and standardize secure email solutions as discussed above, Whitten and Tygar reported in 1999 that Johnny couldn't encrypt [WT99]. They concluded that usability of the software, specifically the user interface, was the main problem. They argued that standard user interface design techniques could not be applied to the design of security software, since users are having difficult using the PGP 5.0 software which was considered to have a good user interface. So, there is a need to create special user interface design techniques for security software. 2.5 2004: Whitten's PhD Thesis - Lime In 2004, Whitten proposed two specialized user interface design techniques called safe staging and metaphor tailoring [Whi04], and used them to develop a prototype secure email client called Lime. 11 The idea of safe staging is to allow users to safely and consciously postpone learning and using a particular security mechanism until they are ready to do so. Lime implemented this idea for the trading of public keys, which basically gives the users the options to start trading public keys now or later. If users are ready to trade their public keys, Lime will proceed to guide the users with various help screens. The idea of metaphor tailoring is to assist users to learn and visualize security mechanisms by presenting them with appropriate visual cues. In Lime, a key-pair is displayed as two keys related together in a typical Chinese Ying-Yang symbol. It was hoped that the use of this Ying-Yang visual cue will help users understand the concept of public key cryptography. Whitten conducted user testing on Lime and concluded that the two techniques of safe staging and metaphor tailoring are effective in making security software more usable, and improves Johnny's ability to encrypt. 2.6 2005: Garfinkel's PhD Thesis - Stream and CoPilot Garfinkel did not agree that user interface was the problem. Instead, he argued that if public key generation and distribution were to be automated without involving users, then most likely the problems identified by Whitten would not exist at all. To support his claim, Garfinkel adopted the concept of Key Continuity (KC) [Gut04] (Section 3.6) to develop two easily usable and secure email systems called Stream and CoPilot [Gar05][GM05][Gar03a]. To automate key generation, these systems simply generate new key-pairs for users who do not have one. To automate public key distribution, all secure emails sent out will automatically be accompanied by the appropriate public keys. The main difference between Stream and CoPilot is in the way public keys are distributed. Stream supports PGP [Zim95] and it distributes the public key hidden in the header of the email. CoPilot adopts the S/MIME [RPC3850] standard and it distributes the public key as an S/MIME attachment. Following the concept of KC, both Stream and CoPilot maintain their own local 12 databases of trusted public keys. When a received email is signed by a public key already in the local database, the email will be trusted without any more user involvement. When a received email is signed by a new public key not in the local database, the user will be alerted, and will be required to make an explicit decision whether to accept the new public key or not. However, passing the problem of accepting new public keys entirely to the users without any assistance leaves them vulnerable to spoofing attacks. To address this critical problem of spoofing, Garfinkel proposed to color-code the display of emails to the users as follows: • Yellow - the email is signed by a new sender with a new public key • Green - the email is signed by an existing sender using the same trusted public key in the local database • Red - the email is signed by an existing sender but using a new public key different from the trusted public key in the local database • Gray - the email is not signed but the sender has an existing trusted public key in the local database Although the color-coded display of emails may serve as a good warning, it still does not address the fundamental problem of how users may decide to trust a new public key. Users may be coerced to accept a new public key or run the risk of being unable to exchange email. To summarize, Stream and CoPilot may be easier to use than Lime because the perceived difficult tasks of public key generation and distribution are removed from the users. Unfortunately, the difficult problem of how to trust a new public key is left entirely to users. Through user testing, Garfinkel conceded [GM05] that CoPilot can be vulnerable to phishing attack, which is of increasing concern nowadays. 1 3 2.7 2006: Johnny Still Can't Encrypt In 2006, Sheng et al. [SBK06] studied the usability of PGP version 9, which has been upgraded to support semi-automatic key generation and distribution, opportunistic encryption if the recipients' public keys are available, and automatic email decryption. They concluded that Johnny still can't encrypt! 14 CHAPTER III Traditional Approach: Using Public Key Distribution 3.1 Secure Email based on Public Key Distribution In 1976, Diffie and Hellman introduced the concept of public key cryptography [DH76], which suggested the possibility of using two distinct but related keys with the desired property that the public enciphering keys might be publicly disclosed without compromising the corresponding private deciphering keys. In this way, the public keys may be placed in a trusted public directory so that others may retrieve them for secure communications. In the following year, Rivest, Shamir and Adleman invented the famous RSA algorithm [RSA78] meeting the desired property of the public key cryptography, where the RSA public keys could literally be placed in a trusted public directory for secure communications. However, the need for a trusted public directory might not be practical, and hence in the same year, Kohnfelder proposed the concept of a certificate [Koh78], which was basically a secure message binding the public key with the claimed owner, and digitally signed by a trusted third-party (TTP). Thereafter, it seems obvious and without doubt that the trusted distribution of public keys is the answer for secure communications. As a result, all known solutions till today are relying on the trusted distribution of public keys to achieve secure communications. For example, the secure email solution PEM [RFC 1421] [RFC 1422] is proposing the setup of a single trust root called Internet Policy Registry Authority (IPRA), the S/MIME [RFC3850][RFC3851] is relying on the setup of X.509 PKI [RFC3280], and the PGP [Zim95] is proposing its own concept of web-of-trust for the trusted distribution of public keys. Even in recent years when researchers are starting to search for secure and yet easily usable email solutions, there is still no doubt that the trusted distribution of public 15 keys is essential for secure communications. For example, in 2004, Whitten proposed a secure email client called Lime in her PhD thesis [Whi04][WT03] which aimed to teach users on key-pair generation and public key distribution so that they might eventually understand and perceive secure emails as usable. In 2005, Garfinkel proposed two systems called Stream and CoPilot in his PhD thesis [Gar05][GM05][Gar03a] which aimed to automate the process of key-pair generation and public key distribution so that secure emails might eventually be easily usable. In this chapter, we survey the various schemes being proposed for the trusted distribution of public keys to support secure email communications. We then conclude with a discussion on the limitations of the traditional approach. 3.2 The Adversarial Model Before proceeding further, it may be beneficial to discuss an adversarial model so that we may use it to measure the effectiveness of the various solutions proposed. To be general to cover all eventualities, it is customary to consider the most powerful adversary, who is in control of all the communication networks, and hence, is able to monitor, insert, delete, or tamper with all transmitted messages. In addition, the adversary is assumed to know all the cryptographic protocols and algorithms used if cryptography is being employed to protect the transmitted messages. However, to be realistic, it is also assumed that without knowing the keys, it will be computationally infeasible for the adversary to recover the transmitted messages, or to tamper with the transmitted messages without being detected. In the area of public key distribution, one potential powerful attack to be conducted by the adversary is the Man-in-the-Middle (MITM) attack. This attack can be realistic, and has frequently been used in the analysis of cryptographic protocols. It is sometimes called with fanciful names such as the Grand Chessmaster problem [Sch96], or as the Mafia fraud [DGB87] in the discussion of flaws of Fiat-Shamir identification scheme [FS86]. Basically, in the MITM attack, the adversary, say Mallory, sits in the middle between the two communicating parties, say Alice and Bob. Although a public key does not 16 require any protection, its association with the claimed owner does. Otherwise, Mallory may easily generate and publish two fake public keys claiming to be associated with Alice and Bob. Then, if Alice is not careful, she may unknowingly use Bob's fake public key to communicate 'securely' with him. To avoid being detected, Mallory may then forward it to Bob re-encrypted using his real public key after reading it. The same argument applies to Bob. Hence, all proposed solutions to the trusted distribution of public key for secure emails will need to address this basic problem of MITM attack. 3.3 Trusted Third-Party (TTP) To prevent the potential of a MITM attack, one easy solution in theory is to have a trusted third-party (TTP). By definition, a TTP is an entity that is fair and unbiased, and can be fully trusted by everyone. So, if the TTP has already vouched that the public key really belongs to the claimed owner with its digital signature, then the problem of MITM attack will not exist, and the public key can definitely be safely use without further question. However, in practice, it is very difficult or nearly impossible to have such a TTP. As a result, Szabo has even considered TTP to be a potential security hole [Sza05]. We will now proceed to the next section to discuss the practical problems of relying on a TTP for the trusted distribution of public keys. 3.4 X.509 Public Key Infrastructure (PKI) The idea of using certificates [Koh78] for the trusted distribution of public keys was first proposed by Kohnfelder in 1978. Basically, a certificate is a secure message digitally signed by a TTP to bind the public key with the name of the claimed owner. To ensure the uniqueness of a name, the working group of ITU-T enhances it further with the use of a world-wide unique name called the Distinguished Name, which compromises the fields of Country (C), Organization (O), Organization (OU) and Common Name (CN). The 17 result is the X.509 certificate [X509]. Eventually, the working group of IETF establishes a framework called the Internet X.509 Public Key Infrastructure (PKI) [RFC3280] which specifies how a TTP may be setup to issue unique X.509 certificates for the trusted distribution of public keys. The TTP is now called the Certification Authority (CA). The idea of a single trusted root called IPRA as proposed by PEM (Section 2.1) seems impractical. Without such a single trusted international CA, many commercial companies, e.g. VeriSign and Thawte, have since considered it a business opportunity and setup themselves as CAs, issuing their own 'trusted' certificates. This resultant trust model offered by PKI has been called the Obligarchy Model [Per99]. It is considered to be less secure since a compromise of any of the CAs may subvert the entire PKI, as illustrated below. Before trusting the public keys on the user certificates issued by any of these CAs, we will need to verify their signatures, which will require us to obtain the certificates of these CAs, known as root certificates. Similarly, we will need to verify the signatures on these root certificates before trusting them. However, since there is no more certificate to refer to, a root certificate is always self-signed, so that its signature can be verified using the same certificate. This brings us to the first fundamental problem of CA. How can we trust a root certificate, since it is so easy to generate a fake self-signed certificate? There is no good solution to this problem. Presently, to be usable and meet the needs of different users using certificates issued by different CAs, most of the root certificates of these CAs are simply bundled inside the software, e.g. you will find many root certificates inside your email clients with integrated support for S/MIME. When any of the certificates from these CAs is encountered by the software, it is simply trusted without distinguishing between the well-known CAs and the unknown CAs. Most users are unlikely to remove the unknown CAs themselves since it can involve as many as 700 mouse clicks [Gut04]. Hence, this practice has been criticized for lowering the trust offered by the PKI to be only as good as the trust offered by the weakest CA. When applying for a certificate, some CAs may charge a fee and go through thorough verification processes which may take up to a month before issuing a certificate [Gut03]. To be efficient, some CAs may also support instant online issuing of certificate 18 without much verification! For example, Thawte, a well-known CA, issues free certificates for secure email instantly via web application. Although a user is required to go through 26 steps and fill in pages of personal information [Gar05], the only verification that Thawte does is to ensure that the user is able to receive instructions sent to his email account. This mode of verification has been known as email-based authentication [Gar03b]. However, based on our adversary model described in Section 3.2, it is clear that email-based authentication is susceptible to MITM attack. For example, since an email server administrator can access anyone's email account, he can easily request a fake user certificate, but this certificate is still a valid certificate and will definitely be accepted by any email client that trust Thawte. Presently, PKI has also been widely used for identifying trusted websites, and is seen to be getting more important with the rise of phishing attacks [DOK04]. However, it has been reported that one phishing website does have a valid certificate from a 'trusted' CA[Net04]. Mazieres had also reported that he was able to obtain a VeriSign (which may be considered as the most well-known CA) certificate for $440 for a business that did not exist [MazOO]. Besides the need to verify the signature on a certificate, there is in fact also a need to verify the validity of a certificate before trusting it. Every certificate has a validity period beyond which it should not be trusted. In addition, to cater for circumstances, e.g. when the corresponding private key is compromised, a certificate can be invalidated even before its expiry. To support this requirement, CAs are implementing the certificate revocation mechanisms either via the Certificate Revocation List (CRL) [RFC3280], or the Online Certificate Status Protocol (OCSP) [RFC2560]. However, the idea of key revocation turns out to be complicated in practice, and researchers are now re-thinking of the possibility to eliminate it [Riv98]. A famous incident elaborated below highlighted the practical problem of PKI and certificate revocation. In January 2001, VeriSign erroneously issued two code-signing certificates to someone falsely claiming to represent Microsoft [GueOl]. This was a serious mistake as anyone trusting the CA would have trusted any potentially harmful codes signed by these certificates impersonating Microsoft. Unfortunately, both VeriSign and Microsoft 19 implemented different interpretations of the optional feature of the CRL [RFC3280]. As a result, there was no easy way to revoke these certificates except for Microsoft to issue a patch in March 2001, which was in fact a hard-coded solution to not recognize the erroneous certificates [MicOl]. So, in practice, can we really trust the CAs? We do not want to argue against PKI, but just to illustrate that designating a TTP to ensure trusted distribution of public keys may not be as simple as it was first thought in theory. It may be interesting to read the 10 risks of PKI listed by Ellison and Schneier [ES00]. In terms of usability, PKI does not fare well too. The need to separately apply for a certificate, and fill in pages of personal information [Gar05][Gut03] will turn away many potential users of S/MIME. The need to pay a fee as required by many commercial CAs will turn away even more. After obtaining the certificate, the need to explicitly import the certificate will leave almost none to use the S/MIME, especially the non-technical users. 3.5 PGP Web-of-Trust In contrast to S/MEVIE which relies on PKI, PGP does not rely on a TTP at all. Instead, it introduces its own trust model called the web-of-trust to support the trusted distribution of public keys. Basically, the idea is to let anyone contribute to vouch for the authenticity of the public key. For example, if Alice obtains Bob's public key through some secure means, say during a personal meeting, then Alice can trust Bob's public key fully. If she wishes, she may sign over it vouching for the authenticity of Bob's key. Next, if Carol obtains Bob's public key, say from a key server (discussed below), then if she trusts Alice and is able to verify her signature, she may now trust Bob's public key without getting it personally from him. Again, if Carol wishes, she may sign over Bob's public key to vouch for its authenticity. In short, users are left to decide on themselves whether to trust a public key or not based on its attached signatures. This is in resemblance with our social interactions with people where we ourselves decide whether to trust a person. There is no TTP to tell us whether a person can be trusted or not. 20 To facilitate the signing of PGP public keys, it is still common to have key-signing parties [Bre04] where people gather together to sign one another's keys. However, to prevent the possibility of virus attack if people swap disks, or key-logging attacks if using a common computer, it is usual for people attending these parties to only manually exchange the fingerprints, expressed in 40 hexadecimal digits, of their PGP public keys. After the parties, these people may then search the appropriate keys from the key servers and sign them at their leisure. The global PGP key server (PKS) [Hor96] was developed by Horowitz in 1996 to facilitate the distribution of PGP public keys. Since then, other volunteers have also joined in to run duplicate servers synchronizing one another to achieve better availability and redundancy. Anyone may upload his PGP public key to anyone of these servers for distribution, or search and download others' public keys. Unfortunately, these key servers do not verify the public keys being uploaded since users are supposed to verify the signatures attached to the public keys before trusting them. As a result, spoofing of keys, either due to mischief or intentional, seems to be a problem. For example, a search for the PGP keys of Philip Zimmermann, the creator of PGP, returns many public keys as shown in Figure 3.1. r Found Keys - Select to Import -r-y-i Account / User ID . . . " . J • _ „ . . 1: Created, _. J Key ID , LBJl • Phil Zimmermann FAKE <prz@>acm.org> , 1997-06-09 F50EFA51 • S Philip R. Zimmermann <prz@acm.org> 1992-07-22 FF67F70B • B Philip R. Zimmermann <prz@acm.org> 1993-05-20 C7A966DD • S Philip R. Zimmermann <prz@>acm.org> 2001-01-04 B2D7795E • Philip R, Zimmermann <prz@pgp.com> 2000-04-19 D08D6B1F I; • Philip R. Zimmermann <prz@pgp.com> 2001-02-07 76ECD3B0 ! • Philip R, Zimmermann <prz@>pgp.com> 2000-10-22 6CADD6FB I • Philip R.Zimmermann <prz@pgp> . 2001-02-02 7A0F3504 Figure 3.1: The search results for PGP keys of Philip Zimmermann, the creator of PGP For expert users who are careful in verifying the PGP public keys before trusting them, PGP can be a very secure email solution. However, for non-technical users, the presence of so many keys, possibly spoofed, will definitely confuse and turn most of them away from using PGP. 21 3.6 The Concept of Key Continuity (KC) In 1996, Ylonen developed the SSH [Ylo96] as a secure solution to replace the existing remote login protocols like telnet, rlogin, etc. Without the availability of a feasible solution for the trusted distribution of public keys, he simply designed SSH to maintain its own local database of trusted host public keys. If the client connects to a host with a public key not in the local database, it will pop up a warning so that user may make an explicit decision. If the user chooses to trust it, the secure session will be established and the new public key automatically stored into the local database for future use. Otherwise, the new public key will be discarded and the session terminated. If the client connects to a host with a public key already in the local database, the connection will proceed successfully without interruption. Essentially, SSH does not attempt to solve the difficult problem of trusted distribution of public keys at all, but leaves the decision plainly to the users when a new public key is first encountered. Nevertheless, it does greatly simplify the distribution and use of public keys. This may be the reason why SSH is widely adopted within a short timeframe. Observing the success of SSH, Gutmann coined the term Key Continuity (KC) [Gut04] to represent this paradigm of public key distribution where the trust of a public key depends on the same key being used after it is first trusted. However, leaving the problem of trusting a new public key totally to the user without any assistance will definitely leave KC very susceptible to the MITM attack. Most likely users will simply trust the new public key, or risk not being able to communicate at all. Nevertheless, Garfinkel argued that since all the secure email solutions presented so many barriers to their adoption, it would be better to have just good-enough security [San03] that is usable. Hence, as elaborated in Section 2.6, he proceeded to design two usable and secure email systems called Stream and Co-pilot based on this concept of KC. Although Stream and Co-pilot are reported [Gar05] to be more usable with the automation 22 on key generation and distribution, Garfinkel concedes that work is required to alert users about phishing attack [GM05], which is a form of MITM attack as expected. 3.7 The Identity-Based Cryptography (IBC) Instead of solving the difficult problem of trusted distribution of public keys, in 1984, Shamir introduced a new concept of public key cryptography called Identity-Based Cryptography (IBC) [Sha84], where the identity itself, e.g. email address, is used directly as the public key. This seems to be very attractive as it totally removes the difficult problem of the need to securely bind a public key with the claimed owner. However, it requires a TTP called Key Generation Center (KGC). The KGC has a key-pair, where the private key will be used to generate the corresponding private keys of its users based on their identities. When Alice wishes to send secure messages to Bob, she can simply encrypt it using the identity ofBob and the public key of KGC as the public key. Upon receiving the messages, Bob will be able to decrypt them using his private key obtained from the KGC. In 2001, Boneh and Franklin found a solution using Weil pairing on elliptic curves to solve the problem of encryption using identity-based cryptography [BF01]. This has allowed a practical implementation of a secure email system based on IBC. Unfortunately, there is one serious concern which is hindering the acceptance of IBC-based secure email solution. It is the inherent key escrow [Abe97] feature due to the fact that the KGC generates, and will hence know all the private keys of its users. In addition, the need to have a TTP may create practical problems as encountered by PKI described in earlier Section 3.4. As a result, although IBC-based email system may be a potential usable solution, it definitely will not be considered as secure. 23 3.8 The Limits of Traditional Approach The vision of Diffie and Hellman stated in their seminal paper [DH76] that public key cryptography allows the public disclosure of enciphering keys without worrying about the compromise of the corresponding private deciphering keys seems to have a great influence in everyone's mindset. Presently, everyone seems to have the idea that the trusted distribution of public keys is the pre-requisite for secure email solutions. As a result, all research and development on secure email solutions, with the only exception of IBC-based secure email, are closely-linked to the trusted distribution of public keys as surveyed in the literature, with the notable few presented in this chapter. With this traditional approach, the solution for secure and easily usable email will only be achievable if the trusted distribution of public keys is also secure and easily usable. After three decades of research, it seems that there are not many possibilities available in the design of the solutions for the trusted distribution of public keys. With the use of a TTP, the failure of PKI has shown that the promising theoretical idea of using a TTP is in practice, not really secure and easily usable. Without using a TTP, the current limited use of PGP only within the expert users has shown that the PGP web-of-trust model is confusing and certainly not easily usable by the average users. The use of K C is simple and easily usable. However it is very vulnerable to MITM attack, which can be a concern as the phishing attack [DOK04] is reported to be on the rise. It seems like the only feasible secure and easily usable solution left is to adopt KC, but to require users to verify the fingerprints of the new public keys before trusting them. However, the fingerprint of a public key is normally derived from a hash function [Dam89]. Presently, SHA1 [FIPS180-1] has been popular and is used in PGP, but it generates a fingerprint of 160 bits, or 40 hexadecimal characters. To be easily usable, Perrin [Per03] proposes to reduce the size of the fingerprint to 100 bits by discarding the remaining bits, and to use a technique called hash extension [Aur03] to increase the cost of brute-force attacks. In addition, he proposes to use Base32 format [RFC3548] so that the reduced-fingerprint can be presented in 20 characters, e.g. f3v4g.ifcen.r3rj5.cmbx8. This will enable it to be portable and be distributed in the manner similar to the way we distribute our email addresses and phone numbers. 24 However, reducing the size of fingerprint is a security compromise. The MD5 hash function [RFC 1321] generating a fingerprint of 128 bits has already been broken [WY05]. The effort to break SHA1 has also been reduced [WYY05]. In fact, the current recommendation is to use SHA-256 [FIPS180-2] which will generate a fingerprint of 256 bits, or 64 hexadecimal digits! So, is it possible to design a secure and easily usable solution for the trusted distribution of public keys in order to support the ultimate need for a secure and easily usable email solution? The invention of IBC-based secure email solution has shown a notable deviation from the traditional approach to design a secure and easily usable email solution. However, its inherent key escrow feature makes it rather unattractive. So we should now look for other new approaches to design a secure and easily usable email solution. 25 CHAPTER IV Proposed New Approach: Using Secure Key Exchange 4.1 Proposing Secure Email based on Secure Key Exchange It is known that if n users are to email securely using the classical secret key n(n — 1) cryptography, then the total number of secret keys required will be - A — — , i.e. it increases squarely. In addition, it requires the existence of a secure channel to transmit the secret keys, which is considered impractical. Hence, the invention of public key cryptography [DH76] is often seen as the solution to the above problem, since only n key-pairs are required for n users, and there is no requirement for a secure channel to transmit the public keys. However, after 30 years since its invention, most of our email correspondences are still in clear, despite much effort expended by many (Chapter 2) in developing usable and secure email solutions based on the idea of public key cryptography. In fact, as discussed in Chapter 3, public key cryptography has introduced an equally difficult problem of trust: how can we trust that a public key really belongs to the claimed user? To affirm the authenticity of a public key, it seems like the only way is to verify it with the user, maybe during personal meeting or via a telephone call (if it is considered secure enough). Conceptually, this similarly translates to the requirement of a secure channel to verify at least the fingerprint of the public key. However, this approach may be considered unusable since we human are known to be error prone at dealing with big numbers. There seems no possible solution in sight for a secure email solution that is easily usable. Nevertheless, on very careful thoughts, we realize that it is the shared secret key between the two communicating parties that is essential for secure email communications. As the use of public key cryptography is known to be computationally more expensive than 26 the secret key cryptography, when Alice sends Bob a secure email, it is common for her system to generate a secret key to encrypt the email message, and to use Bob's public key to encrypt the secret key. Both the encrypted email message and the encrypted secret key are then sent together so that only Bob is able to read it. In addition, we notice that for each user communicating with n other users, he either needs to maintain n public keys if using public key cryptography, or n secret keys if using secret key cryptography. It seems immaterial to the user whether public key or secret key cryptography is being used. The only requirement is that the verification of the public keys, or the establishing of the secret keys, must be usable and secure. Hence, we propose a new approach to study the potential of using secure key exchange as a basis to design a secure and easily usable email solution. 4.2 The Problem with Diffie-Hellman Key Exchange (DH-KE) In the same paper [DH76] introducing the concept of public key cryptography in 1976, Diffie and Hellman also proposed the first key exchange protocol to establish a secret key between two users in an insecure channel, which was later known as Diffie-Hellman key exchange (DH-KE). The security of DH-KE is based on the difficulty of solving the problem of discrete logarithm over finite field GF(q) , where q is usually taken to be a large prime to achieve higher security with lesser bits [MW99][Odl84][PH78]. Figure 4.1 summarizes the interaction between two users, Alice and Bob, using the DH-KE protocol to establish a shared secret key for secure communications. 27 q, g,g" mod q g mod q Figure 4.1: Exchange of messages between Alice and Bob executing DH-KE protocol Without loss of generality, let us assume Alice initiates the protocol. First, Alice chooses a large prime q , and a primitive element g of GF(q) . Next, Alice generates a random value a such that 1 < a < q -1 . This value a may be considered as the private key of Alice and must be kept secret. Finally, Alice computes ga modq . The three values q , g and ga modq are then sent through the insecure channel to Bob as shown in Figure 4.1. Upon receiving the request from Alice, Bob also generates a random value b such that \<b < q - \ . Now, Bob is able to compute the secret value gab modq . The shared secret key k with Alice can then be established as a function of this secret value. To enable Alice to establish the same secret key&, Bob computes gb modg and sends it through the insecure channel to Alice. Now, Alice is also able to compute the same secret value gab modg since she knows her own private key a . Thus the same secret key k is established between Alice and Bob, and they may proceed to communicate securely. Presuming an attacker Eve is listening over the insecure channel. Even though she may be able to capture the four values p , g, ga mod q and gb mod q, she is not capable to compute the secret value gab mo&q since solving the problem of discrete logarithm is known to be hard. It is indeed brilliant for Diffie and Hellman to propose the DH-KE protocol. However, using the same adversarial model as discussed in Section 3.2, an attacker 28 Mallory who is able to intercept and insert messages into the insecure channel is definitely able to conduct MITM attack. As shown in Figure 4.2, Mallory now generates her own random value m , and replaces the messages between Alice and Bob with hers. Now, Mallory establishes secure channels separately between Alice and Bob to eavesdrop their 'secure' communications without being detected by them. Mallory q,g,ga modq q,g,gm ™dq Alice gm mod ^  gb mod 9 Bob Figure 4.2: An attacker Mallory conducting MITM attack against Alice and Bob executing DH-KE protocol 4.3 The Authenticated Key Exchange (AKE) Naturally, the solution to prevent potential MITM attack is for the two users to mutually authenticate each other during the execution of the key exchange protocol to establish a secret key. The resultant protocol is then called the authenticated key exchange (AKE) protocol. Presently, there are two feasible groups of A K E protocols being proposed. The first group is based on the use of public key cryptography, which enables a concept called digital signature [RSA78]. It is hence called the signature-based AKE. Authentication is achieved simply by mutually verifying the digital signatures of each other. The Station-to-Station (STS) protocol [DOW92] proposed by Diffie, van Oorschot and Wiener is the first example of such protocol. Another example is the SIGMA protocol [Kra03] which is being adopted as the signature-based mode of the standardized IKE protocol [RFC4306] in IPsec [RFC4301]. However, the use of signature-based A K E will bring us back to the original difficult problem discussed in Chapter 3: how can we trust that the public key really belongs to the claimed user? 29 The second group is based on the traditional use of password as an authenticator, and is hence called the password-based AKE. However, due to the limitation of human memory, it is known that users tend to choose poor passwords which are susceptible to password-guessing attack, known as dictionary-attack [NS05]. As a result, some researchers had proposed adopting the soft approach to educate users [YBA04], while others had adopted the hard approach by developing the proactive password checker [Spa92][Kle90] so as to force users to choose good passwords. Nevertheless, the fact that passwords are still being used today despite other proposed alternatives for authentication shows that passwords are the most usable and convenient. It is definitely more usable than exchanging and verifying fingerprints. In fact, passwords will be even more usable if users are allowed to choose any of their choices without worrying about dictionary attack. Is it possible to establish a secret key between two communicating users by just using a simple password and yet not susceptible to dictionary attack? The answer is surprising, yes! 4.4 The Concept of Password Authenticated Key Exchange (PAKE) Indeed, password authenticated key exchange (PAKE) has been striving to meet the requirement to allow users to choose any passwords of their choice even if they are poor, and yet the protocol itself is not susceptible to dictionary attack. At first glance, this requirement may seem contradictory. So, it may be beneficial to take a closer look on how dictionary attack works. One condition contributing to the success of dictionary attack is the capturing of an encrypted message generated from the password. This encrypted message may be the encrypted form of the password itself using a known algorithm, or the encryption of a message using the password as the key. Anyway, upon the capturing of this encrypted message, an attacker will be able to perform extensive off-line password guessing without the knowledge of the victim. Thus, the obvious way to thwart dictionary attack is to prevent the capturing of the encrypted message [Hau92], or to use one-time password [Lam81] so that the encrypted message is useless even if it is captured. To prevent the 30 potential of an on-line password guessing attack, it is also common for systems to limit the number of unsuccessful login attempts [BS03]. Another condition contributing to the success of dictionary attack is the redundancy present in the unencrypted message. Most of the time, the results of attempting to decipher the encrypted message using the wrong passwords will produce garbage bits. So, as long as a particular password guess is able to produce some recognizable bit patterns, it is likely to be the correct password. Hence, another way to thwart dictionary attack is to ensure that the unencrypted message is random. In this way, there is no recognizable bit pattern for the attacker to verify even if he happens to guess the password correctly. This is exactly the concept adopted in PAKE. In 1992, Bellovin and Merritt proposed the first PAKE called Encrypted Key Exchange (EKE) [BM92]. In the paper, a specific variation of EKE based on DH-KE, and hence called DH-EKE, is simple and practical. Thereafter, Steiner, Tsudik and Waidner [STW95], and Patel [Pat97] highlighted some advises to prevent potential dictionary attack. In 2000, Bellare, Pointcheval and Rogaway [BPR00] attempted a theoretical proof to show the correctness of EKE. There are many other PAKE protocols being proposed after that. Some are variations [Jab96] to the original EKE, some are catering for the potential compromise of the servers storing the passwords [Wu98][Jab97][BM93], some are provably secure [BMP00], and some are already broken [MPS00][Luc97]. We shall not elaborate them here. 4.5 The Diffie-Hellman Encrypted Key Exchange (DH-EKE) Let Alice and Bob be the two users who have previously agreed on a shared secret password p of their choice, maybe during their personal meeting, or via a telephone call (if they consider it to be secure enough). Now, they wish to establish a secure channel for further communications, but the password itself cannot be used directly to protect their communications since they have chosen an easily remembered password, and is hence highly likely to be susceptible to dictionary attack. 31 However, they have learned the availability of DH-EKE protocol, and decide to give it a try. Their interactions are summarized in Figure 4.3. ,Ep[gamodq) A l i c e Bob Ep[gbmodq) Figure 4.3: Exchange of messages between Alice and Bob executing partial DH-EKE protocol Similar to the execution of DH-KE protocol discussed in Section 4.2, Alice first chooses a large prime q , and a primitive element g ofGF(q). Next, Alice generates a random value a such that l<a<q-l . Then, Alice computes ga mod q . However, instead of sending it out directly as in DH-KE protocol, Alice performs a further step to encrypt it with their shared secret passwordp , obtainingE p[ga modgj. The three values q , g and Ep[ga mod*?) are then sent through the insecure channel to Bob as shown in Figure 4.3. Upon receiving the request from Alice, Bob also generates a random value b such that 1 < b < q -1 . With their shared secret password p , Bob is able to decrypt Ep{ga modi?) to obtain back ga mo&q . Now, Bob is again able to compute the secret value gab mod q . His shared secret key k with Alice can then be established as a function of this secret value. Similarly, to enable Alice to establish the same secret key k , Bob computes gb modq , encrypts it with their shared password p , and sends Ep [gb modq) out through the insecure channel to Alice. With their shared secret passwordp , Alice can similarly decrypt Ep\g modqj and then compute the same secret value gab modq . Thus the same secret key k is 32 established between Alice and Bob, and they may proceed to communicate securely. Now, presuming the same attacker Mallory is listening in the insecure channel, and is preparing to intercept and inject fake messages between Alice and Bob in the hope of performing MITM attack. However, after intercepting the first message from Alice containing values q , g and £ ^ ( g f l m o d ^ | , she is not able to recover ga modq regardless of how simple the password is, and how powerful her dictionary attack is. There is simply no redundancy for her to verify her guess since ga modq is random. Not being able to recover ga mod q , she can never establish a secure channel with Alice pretending to be Bob. At best she can randomly generate a value and sends it back, but this will only result in a garbled channel and alert Alice of the possibility of an attack. The same argument applies to her interactions with Bob. Hence, the threat of MITM attack is prevented with just an addition of a simple password! Since the DH-EKE protocol is designed to be a solution for establishing secure channel after successful authentication, it is necessary to safeguard against potential replay attack. Otherwise, the attacker Mallory can simply capture the first message and replay it later to initiate a session with Bob, pretending to be Alice. Hence, the full DH-EKE protocol has additional nonces included, which is a common challenge-response technique [AN94] to ensure freshness. Figure 4.4 shows all the messages exchanged in a full DH-EKE protocol. na and nb are the nonces generated by Alice and Bob respectively, and £ ^ ( « a ) , E^in^) and Efr {na, rift) represent the encryption of the nonces by the newly established secret key k. 33 Alice q,g,Ep[gamodq) . Bob Ep[gb modq]Ek(nb) Ek{na,nh) _W EkM _^  ^ Figure 4.4: Exchange of messages between Alice and Bob executing complete DH-EKE protocol to prevent replay attack 34 CHAPTER V The Design of EKEmail Protocol 5.1 Designing EKEmail Protocol Like all the key exchange protocols, D H - E K E assumes an interactive environment where the two communicating parties are available to interact so as to establish the shared secret key k . It cannot be applied directly to the non-interactive environment of email which is further complicated by the possibilities of emails being lost, not being read in the order received, or not being replied at all while the sender keeps sending them. Nevertheless, the key idea of D H - E K E enables us to design a protocol for use in our proposed novel solution. Hence, we name our protocol "EKEmail" . To be practical in the non-interactive environment of email, we cannot afford to have too many email exchanges between the two communicating parties before the establishment of a secret key. The original D H - E K E protocol [BM92] as shown in Figure 4.4 has 4 rounds to guard against replay attacks. Nevertheless, as seen in Figure 4.1, the minimum required for the D H - K E protocol [DH76] is 2 rounds. Hence, we shall design 2 rounds in the EKEmai l protocol. There is no concern of replay attacks since the password wi l l only be used once for the establishment of the secret key. This has the added benefit that users may safely forget the password after its first use. We shall refer to these 2 rounds as phases. After Phase 1, the recipient has computed the secret key k, and is able to commence secure email communications in the reply in Phase 2. We introduce a Phase 3 to represent all subsequent secure email communications between the users. The details of the 3 phases are now described. 35 5.2 Phase 1: EKEmail Request Alice likes privacy, but has been exchanging emails in the clear with Johnny since he can't encrypt. When Alice hears about EKEmail, she is eager to give it a try. She arranges to meet Johnny, or maybe she calls him (if she considers this to be secure enough). Luckily, a one-time password of their choice is manageable for Johnny. Frankly, being security conscious, Alice has many passwords to remember. So, she is happy that once she starts her EKEmail client to send Johnny the usual email Ma, enters the one-time password p when prompted, she can safely forget the password forever. In the background, her EKEmail client automatically generates a large prime q , and a primitive root g of GF(q) . It also generates a random value a such that 1 < a < q -1 , and stores it securely for later retrieval. Then it computes ga mod q , and uses the password p to encrypt it, resulting mEp[ga mod#). Clearly at this phase, it is impossible to have any secret key to protect the message Ma, so it is sent in the clear. Figure 5.1 shows the components of the EKEmail Request message from Alice to Johnny. Figure 5.1: Components of Phase 1 EKEmail Request message When Johnny receives Alice's email, he only needs to enter their one-time password p when prompted. Bingo, his EKEmail client automatically recovers q and g from the email, and generates a random value j such that 1 < j < q -1 . Next, it computes gJ modq , and uses the password p to encrypt it, resulting in Ep (gj modg). This value is stored until Johnny is ready to reply back to Alice. In addition, his EKEmail client uses the same password p to decrypt Ep[ga modg) sent by ^ 4//ce, obtaining backga mo&q. 36 This enables the computation of the secret value gaj modq . The secret key k to be shared between Alice and Johnny can now be established as a function of this value. 5.3 Phase 2: EKEmai l Grant When Johnny sends his reply email My- to Alice, his EKEmail client automatically retrieves their secret key k to encrypt it, resulting in [Mj). In addition, it retrieves the previously stored value Ep (gy mod <?) and sends it together with E^ [Mj) . Figure 5.2 shows the components of the EKEmail Grant message from Johnny back to Alice. Johnny is very happy now as he is able to send secure email with minimum intervention. He only needs to enter the secret password p once during Phase 1. Subsequently, the encryption process is completely transparent to him. Alice Ep[gJmodq\Ek(Mj) Johnny Figure 5.2: Components of Phase 2 EKEmail Grant message When Alice receives Johnny's reply, her EKEmail client automatically retrieves the password p previously entered by her, and uses it to decryptEp (g y mod<?|, obtaining back g J mod q. Now, with the previously stored private value a , it can also compute the same secret value gaj modq , and establish the same secret key k . Next, her EKEmail client automatically decrypts Johnny's secure e m a i l [ M J j , recovers Mj and displays it. 37 5.4 Phase 3: EKEmail Secure Henceforth, all emails exchanges between Alice and Johnny will automatically be sent securely. The system simply retrieves the secret key k to encrypt the email M toE k(M), and sends it out as Phase 3 EKEmail Secure message as shown in Figure 5.3. Alice Ek{M) Johnny • » Figure 5.3: Components of Phase 3 EKEmail Secure message 5.5 Analyzing EKEmail Protocol Mallory has been monitoring clear email exchanges between Alice and Johnny. Now, to continue reading such exchanges, she has to cryptanalyse EKEmail messages. She cannot decipher the secure message E^{M) directly since this is computationally infeasible without knowledge of the secret key k . She learns that EKEmail is using password authenticated key exchange protocol without the need for a good password. She has already intercepted Ep[ga mode?) andEp{g^ modg). However, no matter how long she tries, her password-guessing system simply cannot determine the password since ga modq and gJ modq are purely random. There is basically no redundancy to verify the guesses. Even if she happens to guess p correctly and recover ga modq andg-^  modq , these two values will not enable her to compute secret key k since the problem of determining discrete logarithms is known to be hard. So, a possible way that Mallory can try is to simply guess a password p' and conduct a man-in-the-middle (MITM) attack as shown in Figure 5.4. However, the probability of her guess to be correct in just 1 try is negligible. Otherwise, many existing 38 password authentication systems which allow 3 login tries before account logout would have reported a lot of break-ins. Brostoff and Sasse have even argued for the purpose of usability to allow 10 tries before account logout [BS03]. Mallory Alice _! Ep.(gmmodq\EkJ{Mj) 1,g,Ep{gm™dq\Ma Ep[gJ modq]Ekj(Mj) Johnny Figure 5.4: Mallory's unsuccessful MITM attack against Alice and Johnny executing EKEmail protocol In Figure 5.4, the value m is Mallory's private value randomly generated similar to private values a and j generated by Alice and Johnny respectively. Since Johnny Ep<{gm modg] , he will compute his version of the secret key receives kJ = Dp{Ep<{gm modi?))'' modq, where Dp{) represents the decrypting function using password p . Mallory will attempt to compute her secret key with Johnny as k • - Dp<{Ep[gJ mod^J modq . With very high probability, kj *kmj since the probability of getting p = p' in just 1 guess is almost negligible. Similarly, Alice will compute her version of secret key Dp\Ep\gm mod modq, and Mallory will attempt to compute her secret key with Alice as kr Dp(Ep(ga modq\ modq . With similar reasoning, ka * kma with high probability. Mallory's MITM attempt has resulted in garbled channels between Alice, Johnny and Mallory since all of them have computed different secret keys ka * kma, kj ^ kmj and&a ^ kj. Alice, being more knowledgeable in security, knows that they must be under 39 attack. So, she calls Johnny to remove the wrong key, agree on another secret password, and restart the EKEmail protocol again. 5.6 Key Refresh with Perfect Forward Secrecy It is always desirable to use short-lived keys [SH97]. Otherwise, if the key happens to be compromised, then all the email correspondences - past, present, and even future if it is not being detected - will be readable by the attacker. . Hence, we will improve the EKEmail protocol designed so far to support key refresh. To be easily usable, we will design it to be executed transparently, with the refresh frequency set by the user in the system setting, e.g. monthly. (This is in contrast to all the present secure email solutions where key refresh is seldom done due to the problem of public key distribution.) To refresh the secret key, 2 rounds referred to as EKEmail Refresh Request and EKEmail Refresh Grant phases are designed. To prevent the possibility of an attack, key refresh is performed within the protection of Phase 3 EKEmail Secure message. Since the probability for the current secret key k to be compromised is rather low, the key refresh request may be considered as valid as long as the correct key k is used. Nevertheless, to add another layer of safeguard just in case the secret key k has really been broken, we shall design the system to store and re-use the old password p previously entered by the users, although by now it may have been safely forgotten by them. Hence, the EKEmail Refresh Request is designed as the nesting of the Phase 1 EKEmail Request message inside the Phase 3 EKEmail Secure message as shown in Figure 5.5. Figure 5.5: Components of EKEmail Refresh Request message 40 Alice, being more privacy-conscious, sets her EKEmail client to refresh the secret key k more frequently, say weekly, instead of monthly which is being set in Johnny's EKEmail client. Nevertheless, when Alice sends Johnny an email Ma a week later, her EKEmail client will automatically retrieve the stored values k and p , generate new values q , g and a , perform the necessary computations, and send out an EKEmail Refresh Request message as shown in Figure 5.5. When Johnny receives this message, his EKEmail client will first interpret it as the standard Phase 3 EKEmail Secure message. Upon decrypting it using the current secret key k, it obtains Phase 1 EKEmail Request message, and will now know that it is a key refresh request. Similar to Phase 1 described in Section 5.2, his EKEmail client will automatically establish a new secret key k' without involving him. Only the decrypted email Ma is displayed to him as usual. The EKEmail Refresh Grant phase can similarly be designed as the nesting of the Phase 2 EKEmail Grant message inside Phase 3 EKEmail Secure message as shown in Figure 5.6. Alice Ek(Ep(gJmodq\Ek{Mj)) Johnny * Figure 5.6: Components of EKEmail Refresh Grant message When Johnny replies email Mj to Alice, his EKEmail client will encrypt it using the new secret key k' . Then, it will construct a Phase 2 EKEmail Grant message, encrypt it with the old secret key k to form a Phase3 EKEmail Secure message, and send it out. When Alice receives this EKEmail Refresh Grant message, her EKEmail client will decrypt it using the current secret key k to obtain the Phase 2 EKEmail Grant message. Then, similar to the Phase 2 described in Section 5.3, it will automatically establish the same new secret key k' , and use it to decrypt Johnny's email for Alice to read. Now, the old secret key k has been successfully refreshed to the new secret key k' 41 after the exchange o f E K E m a i l Refresh Request and E K E m a i l Refresh Grant messages. This new secret key k' w i l l be used for al l subsequent Phase 3 E K E m a i l Secure messages between Alice and Johnny. As seen from above, the E K E m a i l Refresh Request phase is initiated automatically based on the system setting, and the E K E m a i l Refresh Grant phase is executed automatically based on the reception o f the E K E m a i l Refresh Request message. To both Alice and Johnny, these 2 phases appear as normal emai l exchanges. Not having succeeded previously, Mallory now hopes to attack during the key refresh phases. However, without knowing the current secret key k , she is not able to initiate a E K E m a i l Refresh Request, or a E K E m a i l Refresh Grant message. In fact, she does not even know when Alice and Johnny are refreshing their key. Let us assume that she is really lucky and have somehow recovered the secret key k . However, s imi lar to the argument presented in Section 5.5, she may not be lucky to guess and use the correct password p in just another 1 try. A n y attempt by her to refresh the key may again result in garbled channels and alert both Alice and Bob. O f course in theory, there is always a possibi l i ty for Mallory to attack successfully. However, since it may not be possible to bu i ld a totally secure system in practice, we deem that the use o f the current secret key k, coupled wi th the use o f the password p provide adequate security without burdening the users. Since Mallory may not be able to initiate an attack on key refresh, i f she is really lucky to have learn the current secret key k , her best action w i l l be to eavesdrop quietly on the emai l exchanges between Alice and Johnny. The use o f D i f f i e He l lman key exchange in the E K E m a i l protocol achieves a property cal led Perfect Forward Secrecy (PFS), i.e. a compromise o f the current secret key k w i l l not compromise the new secret key k' to be established in future. Hence, i f Alice and Johnny refresh their keys regularly, then the consequence for their secret key k to be compromised w i l l be min imal . 42 5.7 The Off-The-Record Property Borisov, Goldberg and Brewer argued that casual conversations like emails should have the off-the-record property [BGB04], i.e. the recipient cannot prove that a sender sent certain email message since he himself is able to fabricate it. Presently, to achieve authenticity, PGP and S/MIME use digital signatures, which have resulted in the undesirable non-repudiation property that the senders are held liable for their casual email messages. To alleviate this problem, they propose the use of a ring signature [RST01] scheme, which makes it possible to specify a set of signers without revealing who actually signed it. However, the use of ring signature in secure email communications requires the knowledge of the public keys of both the sender and the recipient, which may not be available since Johnny can't encrypt. EKEmail protocol achieves this off-the-record property naturally with the use of classical secret key cryptography using the shared secret key k . 5.8 Modeling EKEmail Protocol with Statechart To be more precise in describing the behavior of EKEmail protocol, we model it with the commonly used statechart [Har87] adopted in the Unified Modeling Language (UML). In an EKEmail system, every pair of communicating parties will maintain states associated with them, similar to the maintenance of states in every pair of TCP connection. For example, when^//ce communicates with Johnny, there will be a state associated with Johnny in Alice's EKEmail client, and there will be a corresponding state associated with Alice in Johnny's EKEmail client. For ease of understanding, we shall present two statecharts as shown in Figure 5.7 to illustrate the corresponding state transitions that occur in Alice and Johnny's systems in accordance with the different phases described in the earlier Sections 5.2, 5.3, 5.4 and 5.6. In practice, these two statecharts are combined into one single statechart. These statecharts are self-explanatory and provide a better understanding of how EKEmail protocol 43 operates . Clear Receive/Send Clear ove key Send EKEmail Request Request Secure Receive EKEmail Grant Receive/Send EKEmail Secure Send Refresh Request Refresh-Request Receive Refresh Grant Receive/Send, Clear a Clear Receive EKEmail Request Grant Send EKEmail Grant Receive/Send EKEmail Secure1 a Secure Receive Refresh Request Refresh Grant Send Refresh Grant Remove Ke\) State transition associated with Johnny in Alice's EKEmail client State transition associated with Alice in Johnny's EKEmail client Figure 5.7: Statechart model describing the behavior of EKEmail protocol in an ideal situation 5.9 Handling Exceptions and Race Conditions H o w do w e h a n d l e the non- in te rac t i ve e n v i r o n m e n t o f e m a i l , w h i c h is fur ther c o m p l i c a t e d b y the p o s s i b i l i t y that e m a i l messages m a y be los t , no t r ead i n the o rde r r e c e i v e d , o r no t r e p l i e d to at a l l w h i l e the sender keeps s e n d i n g t h e m ? In a d d i t i o n , w h a t i f b o t h Alice a n d Johnny in i t i a te E K E m a i l Reques t , o r E K E m a i l R e f r e s h R e q u e s t messages at the same t i m e ? W e refer to these s i tua t ions as race c o n d i t i o n s . T o answe r these ques t i ons , w e s h o w the c o m p l e t e d e s i g n o f the E K E m a i l p r o t o c o l state t rans i t ions i n F i g u r e 5.8. T h e m e a n i n g o f ' r e c e i v e ' is to be in te rp re ted as ' read ' , i.e. the use r has e x p l i c i t l y se l ec ted the e m a i l to read . 44 Send 1" EKEmail Request Send EKEmai l^ .—^ Request C Receive 1 s t EKEmail Grant Send 1" Refresh Request Send Refresh ~ — ^ Request C Clear , Receive/Send Clear Request Receive 1 s t EKEmail Grant Request s Send EKEmail Grant Receive 1" EKEmail Grant or Secure Receive 1" Refresh Request Refresh-Grant Send Refresh Grant Receive 1 Refresh Grant Receive 1 s t Refresh Grant or EKEmail Secure Figure 5.8: Statechart model describing the behavior of EKEmail protocol with exceptions handling The state of the EKEmail protocol is important in determining the type of EKEmail messages to be sent out. To cater for the possibility of emails being lost, not read in the order received, or not replied to at all, the EKEmail protocol always remains in the current state when sending out the appropriate EKEmail messages, except when sending out the first EKEmail Request message or the first Refresh Request message as shown in Figure 5.8. This is to allow the sender to keep sending email messages which will remain readable by the recipient. To cater for the situation where the emails are not read in the order received, and the need to re-read old EKEmail messages received earlier, the EKEmail client always attempts to decrypt and display any selected EKEmail message as long as the appropriate secret key is available regardless of the state. To avoid cluttering the statechart, this ability to read any selected EKEmail message in any state without state transition is not shown. If the selected email is the first expected EKEmail message type received (read), then the appropriate state transition will occur as shown in Figure 5.8. 45 To handle the race condition which occurs when both users initiate the EKEmail Request message and transit from state Clear to Request, we add the ability to transit from state Request to Grant as shown in Figure 5.8. During this transition, the appropriate secret key k is also established similar to the transition from state Clear to Grant as discussed in Section 5.2. The same reasoning applies to the transition from state Refresh-Request to Refresh-Grant to handle the race condition which occurs when both users initiate the Refresh Request and transit from state Secure to Refresh Request. 5.10 Optional: Using Separate Key for Secure Email Storage Similar to the problem encountered by all secure email solutions, if an email message remains encrypted with an old key, then it will not be readable anymore after the key is refreshed. This may be a good feature if the old email messages are not needed anymore. For EKEmail protocol, both the old secret key k and the newly established secret key k' will be maintained during key refresh as shown in Figure 5.6. This will have the benefit which allows the old emails encrypted with key k to remain readable. However, if users wish to keep even older emails for reference, then there is a need for an alternative solution. In 2001, Brown, Back and Laurie authored an internet draft [BBL01] proposing to enhance PGP with the use of a separate key for long-term email storage. EKEmail client may implement this optional feature if desired. 46 CHAPTER VI The Implementation of EKEmail Protocol 6.1 Designing New EKEmai l M I M E Type Clearly, EKEmail must work within the existing email infrastructure in order to be acceptable as a practical solution. Fortunately, the message body of an email has been extended from the original basic ASCII text to the standard Multipurpose Internet Mail Extensions (MIME) [RFC2045] to support any data type. In addition, MIME security multiparts [RFC 1847] to support encrypted data have also been standardized. Hence, EKEmail can be implemented as a new protocol type of the MIME security multipart, similar to the implementation of OpenPGP [RFC3156]. Following the specification in [RFC 1847], EKEmail message will be implemented as a MIME multipart identified by the content type of multipart/encrypted. It will have exactly two body parts: a control part containing the parameters, and a data part containing the encrypted data. The control part will have its content type identified by the new EKEmail protocol type of application/ekemail. The data part will be identified by the content type of application/octet-stream as specified. We will implement 3 different variations of the EKEmail MIME message to correspond to the 3 phases designed in Chapter 5. The first line of the control part shall contain "Phase: 1", "Phase: 2", or "Phase: 3" to indicate these 3 variations. For phase 1 and phase 2, appropriate parameters will be appended in the control part as well. For phase 3, no parameter is necessary. The parameters in the control part will be encoded using the ASCII armor format similar to OpenPGP. Basically, it is a Base64 [RFC3548] encoding of the data with the addition of headers. The ASCII armor format shall contain the following: • A header line • A version number 47 • A blank line • Base64 encoding of data • A tail line The user email will be sent as encrypted data in the data part. As specified in [RFC1847], the user email will first be transformed into a MEME body part in canonical MEME format, i.e. including appropriate mail headers such as content-type, before being sent for encryption. After encryption, it will be similarly encoded using the ASCII armor format. Implementation based on the description in this thesis will have the version number 0.1. 6.2 The Phase 1 EKEmail MIME Message In the Phase 1 EKEmail Request message as described in Section 5.2, there are three parameters q , g andEp {ga modg] to be sent. However, for performance reasons as discussed in later Section 6.5, we shall use pre-defined values for q and g similar to the practice in EKE [RFC4306]. Hence, the corresponding Phase 1 EKEmail MEME message will only have 1 parameterEp{ga modq^j in the control part; and the clear email Ma in the data part. These are identified by the words "PARAMPBE" and "MESSAGE" in the header and tail lines respectively. An example of Phase 1 EKEmail MEME message sent from Alice to Johnny is shown in Figure 6.1. 48 F r o m : a l i c e B v i r t u a l . t e s t T o : j o h h n y @ v i r t u . a l . t e s t M e s s a g e - I D : < 2 3 3 8 7 0 9 3 . 5 1 1 5 2 6 9 0 5 8 5 4 7 7 . J a v a M a i l . r o o t B l o c a l h o s t . l o c a l d o m a i n > S u b j e c t : L e t ' s t r y E K E m a i l M I M E - V e r s i o n : 1 . 0 C o n t e n t - T y p e : m u l t i p a r t / e n c r y p t e d ; p r o t o c o l = " a p p l i c a t i o n / e k e m a i l " ; b o u n d a r y = e k e m a i l — e k e m a i l C o n t e n t - T y p e : a p p l i c a t i o n / e k e m a i l C o n t e n t - T r a n s f e r - E n c o d i n g : 7 b i t P h a s e : 1 B E G I N E K E M A I L PARAM PBE • V e r s i o n : 0 . 1 c 0 e 9 3 v l G C a h X F O T 7 2 b l v 8 O B / d H L / h l 7 g w t 7 G s l H f + c a C 8 p n V Z B e F a 3 c s e 6 + t P e 8 c 9 H T Z z b s m I 8 b 0 3 y 5 k g y J 6 5 O E e f S 4 1 u e u R Q / I O B n z 0 b 6 P f Y e e a J J V 0 6 K G 9 9 r v h A R x q P r x l 2 Y p v 5 p E z m P I Q T N e 9 W K s 2 G w M 0 h S + Y 2 T + c r ^ N y d v P u o r S x V e Y 9 Z C A = = END E K E M A I L PARAM PBE — e k e m a i l C o n t e n t - T y p e : a p p l i c a t i o n / o c t e t - s t r e a m C o n t e n t - T r a n s f e r - E n c o d i n g : 7 b i t B E G I N E K E M A I L MESSAGE V e r s i o n : 0 . 1 S G k s I E p v a G 5 u e S w K C k V L R W l h a W t j g a X M g Y S B u Z X c g d X N h Y m x l I G F u Z C B z Z T J N l c m U g Z D1haWwgc 2 9 s dXRpb 2 4 uC k x 1 d C d z I G d p d m U g a X Q g Y S B0 c n k h C gp DaGV1c nMhCkF s a U N l C g = = END E K E M A I L MESSAGE — e k e m a i l — Figure 6.1: Components of Phase 1 EKEmail MIME Message 6.3 The Phase 2 EKEmail MIME Message In the Phase 2 EKEmail Request message as described in Section 5.3, the corresponding Phase 2 EKEmail MIME message has 1 parameter Ep[g-i modg] in the control part, and the encrypted email E^Mj) in the data part. Figure 6.2 shows an example of Phase 2 EKEmail MIME message reply from Johnny to Alice. 49 F r o m : 3 o h n n y S v i r t u a l . t e s t T o : a l i c e S v i r t u a l . t e s t H e s s a g e - I D : < 2 7 3 3 4 3 4 5 . 3 1 1 5 2 6 9 1 0 8 7 9 5 5 . J a v a H a i l . r o o t @ l o c a l h o s t . l o c a l d o m a i n > S u b j e c t : R e : L e t ' s t r y E K E m a i l H I H E - V e r s i o n : 1 .0 C o n t e n t - T y p e : m u l t i p a r t / e n c r y p t e d ; p r o t o c o l = " a p p l i c a t i o n / e k e m a i l " ; b o u n d a r y = e k e m a i l — e k e m a i l C o n t e n t - T y p e : a p p l i c a t i o n / e k e m a i l C o n t e n t - T r a n s f e r - E n c o d i n g : 7 b i t P h a s e : 2 B E G I N E K E M A I L PARAH PBE V e r s i o n : 0 . 1 h d G B a Q 3 G j f Y d Z 4 t q Q T k J B A H 6 S i j T 7 / 9 n n C G y F l + U U B 4 U R 4 s x R S d 5 U U T R Y 7 F r a n 2 C + P F x Z h J k V / h e 6 P K b B v x J J d L 1 8 5 O V 4 0 4 0 4 z v F E H v L t p d U c / A u 4 c j L 9 i O f r g K t B 8 R a h X x 9 i l E E 6 i U v 7 0 X D I i d I X r j s u 4 T c j u A k P 3 M q / Q 0 2 u g A 2 a f z h k W w t 9 x N c = END E K E M A I L PARAM P B E — e k e m a i l C o n t e n t - T y p e : a p p l i c a t i o n / o c t e t - s t r e a m C o n t e n t - T r a n s f e r - E n c o d i n g : 7 b i t _: B E G I N E K E M A I L MESSAGE V e r s i o n : 0 . 1 i y s 6 n k / o O R n / 5 8 e / K 3 K f H X 7 A s 8 A b t a A L f q N 8 u 7 N s x h g V F w c c 9 T K H j l 9 p i T 7 o J 7 C m G n N U f + x 9 y M j d 0 2 o d u V w V v u w Z T I k Z F w I f A y J o 8 n q T X z p 0 u S C s r z a / y O f H f + a u T 7 T q l 1 7 d 4 C K x i Y i ¥ q 0 4 h 4 d b r l g v + S P l z C q S R 6 B V J B A u d S d R N q B B f 9 g Q o B A 3 z 2 T u p ¥ o M h F u b u 4 o i R 8 q G Z I Q e C 2 j S j n K X 5 F F V G + a 2 1 H b P 6 5 r b A q e O B s U w q T L I m N y Z X F Q u / Z R L T END E K E M A I L M E S S A G E — - — — e k e m a i l — Figure 6.2: Components of Phase 2 EKEmail MIME Message 6.4 The Phase 3 EKEmail MIME Message In the Phase 3 EKEmail Secure message as described in Section 5.4, the corresponding Phase 3 EKEmail MIME message simply has "Phase: 3" in the control part without any parameter appended, and the encrypted email in the data part. Figure 6.3 shows an example of Phase3 EKEmail MEME message reply from Alice to Johnny. 50 F r o m : a l i c e Q v i r t u a l . t e s t . T o : j o h n n y B v i r t u a l . t e s t M e s s a g e - I D : <2 6 4 3 5 8 1 0 . 5 1 1 5 2 6 9 1 3 2 0 4 9 0 . J a v a M a i l . r o o t @ l o c a l h o s t . l o c a l d o m a i n > S u b j e c t : R e : L e t ' s t r y E K E m a i l M I M E - V e r s i o n : 1 . 0 C o n t e n t - T y p e : m u l t i p a r t / e n c r y p t e d ; p r o t o c o l = " a p p l i c a t i o n / e k e m a i l " ; b o u n d a r y = e k e m a i l — e k e m a i l C o n t e n t - T y p e : a p p l i c a t i o n / e k e m a i l C o n t e n t - T r a n s f e r - E n c o d i n g : 7 b i t P h a s e : 3 — e k e m a i l C o n t e n t - T y p e : a p p l i c a t i o n / o c t e t - s t r e a m C o n t e n t - T r a n s f e r - E n c o d i n g : 7 b i t B E G I N E K E M A I L MESSAGE V e r s i o n : 0 . 1 I I c G U X h G H O E D 7 1 2 G V z 6 x a 5 c M v W v z d 4 m Q n Y I J y 7 h D 4 h Z N U d X F v t 5 z S E E Y B u w g 3 f g J X s O H A A d D v U T r L V s L A n L f Q 5 X F 7 r . 4 h u K a I X h 3 6 x O Q Z U Q 5 I q r T Y s G h E i U 5 z I U m h K 7 8 f s C z w B t s A t + o 3 y 7 s 2 z G G B U X B x z l M o e P X 2 m J P u g n s K Y Z X b b j d c 7 i v l P S j K h O I x l n E v 6 F X l S F g j u m e t e 8 b N q M R q A c Z r T / h X R v C V c Y m s l X K T J + q 8 G A 0 9 U X g A i w d l i f U f g 8 P b R9qS qyH8 QMhayh i YG2 TwcmmTD aQY05 TNQKuE Rx IvgHTNy / y d s f i 31 u P N t Gc Y i kV4 o e H j k k h D A x G b f S v F 8 d C I 3 V l p Z g t V P a i + b U Y q 0 y m K l W 9 V o j t 6 S e I E B m j 8 S q J W 2 R E G r r i t X R E j g W v U 7 R W l f ZI3dFxro== END E K E M A I L MESSAGE — e k e m a i l — Figure 6.3: Components of Phase 3 EKEmail MIME Message 6.5 Choosing Cryptographic Algorithms The most important consideration in choosing cryptographic algorithms to be adopted in the EKEmail protocol is the password-based encryption of Diffie-Hellman public terms ga modq mdgJ modq. Utmost care must be taken to avoid leakage of information unknowingly being introduced during the encryption. For example, the standard password-based encryption (PBE) techniques described in [RFC2898] are not applicable due to the addition of padding [RFC1423] to the end of the message before it is being encrypted. The presence of these pads of the form (expressed in hexadecimal) 0x01, 0x0202, 0x030303, 0x04040404, 0x0505050505, 0x060606060606, 0x07070707070707, or 0x0808080808080808 introduce redundancy which will allow attackers to verify their guesses. The use of random pads may still introduce redundancy due to the presence of the length field to indicate the number of pad bytes. An unreasonable 51 value indicated in the length field after decryption will give a hint to the attacker that the guess is likely wrong. Hence, the use of block ciphers is ruled out. This leaves us with only stream ciphers to consider. Alleged RC4, or Arcfour (to avoid trademark problem with RC4) [KT99][Sch96] is a very fast and widely-used stream cipher. Although the use of Arcfour in the Wired-Equivalent Privacy (WEP) protocol has been criticized and broken [SIR02][BGW01], it is mainly due to its careless use [FMS01], and not its inherent vulnerability. The use of Arcfour to only encrypt the two Diffie-Hellman public terms which may be considered as random values should spare us from all known attacks. Nevertheless, to be cautious, we use the standard password key derivation function, specifically PBKDF2 specified in [RFC2898], with HmacSHAl [RFC2104], a randomly generated 8-byte initializing vector (IV), and an iteration count of 1000 as recommended, to derive an Arcfour key from the given password p provided by the user. Although the use of short Arcfour keys is vulnerable to attacks [FMS01], the use of very long keys is also vulnerable to another form of attack called related-key attack [GW00]. Hence, we adopt the current practice of using 128-bit Arcfour key to generate the key stream. Following the recommendation in [Mir02][GW00], we discard the first 512 bytes of the key stream before using it for encryption. With the use of a randomly generated IV in PBKDF2, different key streams will be generated to encrypt the two Diffie-Hellman public terms ga modq andgJ modq, hence avoiding the potential of XOR attack [DN96]. The IV will be appended as the first 8 bytes of the encoded data in PARAM-PBE sent to the recipient. The choices for the other cryptographic algorithms are more straightforward. Since the purpose of EKEmail is for privacy protection, a secret key size of around 90 bits is sufficient as recommended in [RFC3766]. Nevertheless, we shall adopt the new standard AES [FIPS197] for the encryption of emails, which uses a minimum key size of 128 bits. To match the security strength offered by 90-bit secret key, [RFC3766] advises the use of around 1500 bits for the public parameter q in the Diffie-Hellman protocol. Fortunately, the parameters q and g may be fixed without affecting its security [BM92]. Hence, for performance reasons, we shall use the fixed parameters q and g designed for 52 IKE [RFC4306], specifically the Group 2 1024-bit MODP. This also has the advantage of eliminating the need to verify these parameters to prevent the number-theoretic attack described in [Pat97]. As for the private parameters, i.e. a and j , to withstand the Pollard's rho attack [Pol78], they should have at least twice the number of bits used in AES [FIPS197], i.e. at least 256 bits in our case. For security reasons, the secret value gaj modq computed after the Diffie-Hellman protocol needs to be hashed before it can be used to derive the secret key [GKR04]. As recommended in [RFC3 766], we shall hash it using SHA-1 [FIPS180-1 ], and then extract the first 128 bits as the secret key for use in AES [FIPS 197]. Table 6.1 summarizes the cryptographic algorithms adopted in EKEmail protocol version 0.1. Cryptographic algorithms/ protocols Parameters Details Remarks DH key exchange DH public parameters q ,g = pre-defined; private exponents a, j = at least 256 bits randomly generated RFC 4306 Group 2 1024-bit MODP DH-EKE Use password p to encrypt DH public terms Ep[gamodq), Ep(gJ modq) p = any of users' choice -HmacSHAl arcfourkey = PBKDF2( p , IV, c, dkLen) IV = 8 bytes randomly generated by sender and sent to recipient, c= 1000, dkLen = 16 bytes RFC 2898, RFC 2104 Arcfour key stream = generated using 128-bit arcfourkey, discard first 512 bytes Internet draft SHA1 Derive 128-bit secret key k from computed DH secret value gaj modq RFC 2631, FIPS PUBS 180-1 AES Use 128-bit A: to encrypt emails (M) FIPS PUBS 197 Table 6.1: Cryptographic suite used in EKEmail protocol version 0.1 53 CHAPTER VII An Implementation of EKEmail Client 7.1 The Architecture of EKEmail To incorporate EKEmail within the existing email infrastructure, we merely need an email client that can recognize the new EKEmail MIME type, and the ability to maintain states according to the statechart in Figure 5.8. For re-usability and ease of integration with existing email clients, the EKEmail protocol is developed as two main modules - the EKEmail Protocol module and the EKEmail KeyStore module as shown in Figure 7.1. EKEmail Protocol module •send' 'receive' •4 • •> SMTP - POP3 — IMAP Any email client EKEmail KeyStore module Figure 7.1: The architecture of EKEmail To send an EKEmail, the email client only needs to pass the clear email message to the EKEmail Protocol module to 'send'. The EKEmail Protocol module will transform the clear email into the appropriate EKEmail MIME message according to the state of the recipient maintained in the EKEmail KeyStore module. The resulting EKEmail is then returned to the email client for sending out using any email transport protocol it supports, e.g. SMTP. 54 To read an EKEmail, the email client only needs to pass the EKEmail to the EKEmail Protocol module to 'receive'. The EKEmail Protocol module will attempt to transform the EKEmail back to the original clear message using the corresponding secret keys of the sender stored in the EKEmail KeyStore module. The state of the sender will be updated automatically according to the statechart shown in Figure 5.8 if necessary. A typical screen of our EKEmail client is shown in Figure 7.2. The look and operation are similarly to other email clients currently available. P ' E K E m a i l : T o w a ' r d i , U s j a i e , a r i d ; S e c i i i e E m a i l ? , £ ^ i 'I" \*,/^V * W E l S y s t e m S e t t i n g s M a i l B o x e s Key C a b i n e t He lp • | p Inbox] -dB T rash Enc t yp fp . Status - |l ' jilohnnv@virtual.test Subject lRe:.Let;s t i y EKEma i l , |Date:Fri, 28 Jul 2 0 0 6 15:27:56 +0800: (SCT) jFrom: 'johnny@;virtual:test ITo: alice@virtual.test [Mi, Al ice, can't.bel ieve it/1 can enct\pt now!' JHappy, Johnny > Hi, Johnny, > EKEmail. is a new u s a b l e a n d secure email solution. > Let's'.give'.it'a'.tryt >• Cheers! > Alice Date , J j u l 28 2 0 0 6 , Figure 7.2: The GUI of our EKEmail Client 7.2 The Security of EKEmail for Alice Since Alice is concerned with her privacy, she sets her EKEmail client to send all her emails as EKEmail, which will initiate EKEmail request if keys have not been established yet. When Alice sends Johnny her first EKEmail as described in Section 5.2, 55 she enters her email in the usual way. Only when she clicks the 'Send' button does her EKEmail client pop up the additional password dialog box for her to enter the password as shown in Figure 7.3. Q EKEmail: Write mail r _ I s ! m L(J ha i From :alice@virtual.test . T o : ljohnny@virtual.test Cc: I Subject: [let's tr Hi, Johnny. EKErnail is a new Let's give it a try! Cheers! Alice EKEmaikSending mails :R Please enter your shared pais sword with johnny@virtual.test: Please enter your password again for confirmation : Send EKEmail Send clear Don't send Figure 7.3: Alice enters her agreed password with Johnny to initiate an EKEmail request message Thereafter, everything proceeds as with a normal email client. Alice may verify the status by looking at the statechart associated with Johnny in her EKEmail client as shown in Figure 7.4. When Alice receives an EKEmail Grant reply from Johnny as described in Section 5.3, her EKEmail client will transparently establish the secret key k and the statechart associated with Johnny will be updated accordingly as shown in Figure 7.5. There is no manual involvement required from Alice. From this point, Alice can enjoy secure email communications with Johnny. 56 Q EKEman:Kev CabineV . [f My Secret Keys with. Friends :| H o h h n y g v i r t u a l . t e s L alice^irtual.test : Our shared secret key for securing email Key type: Key size: New key value: New key date: Old key value: Old key date : i-Oui key exchange for refreshing secret key-Protocol type : Key size: Request date: Status lEKEmail Protocol • 1024 Fri Jul 2815:10:55SGT 2006* Current state: |Request If for any reason, this key is different with your correspondent, you may remove it and retry again. U Ren F i g u r e 7.4: T h e statechart assoc iated wi th J o h n n y after A l i c e sends an E K E m a i l Request message P Sly'Secret keys with Friends , Q'EKEmail: Key Cabinet aliceSvirtual.test ohriny@virtual.test Our shared secret key for securing email 128 9201 1513.5C12 FEE7; A38E 7228 BC8C-5B Key type : [AES Key size : New key value : New key date : Old key value: Old key date : (Our key exchange for refreshing secret key Frl Jul 28 15:28-37 SOT 2006 Protocol type: Key size: Request date:• rStatus-Cunent state : |Secure '•. :,. ...ijJ^Z.s. " . If for any reason, this key is different with your correspondent, you may remove it and retry again. | Remove I F i g u r e 7.5: T h e statechart assoc iated wi th J o h n n y after A l i c e rece ives his E K E m a i l G r a n t message 7.3 The Usability of EKEmail for Johnny For Johnny who can't encrypt, he simply uses EKEmail client in the default setting, which is to send EKEmail if keys are available, and to send clear emails if not. Hence, no password dialog box will pop up when Johnny sends emails. When Johnny selects to read Alice's email which is an EKEmail request message, his EKEmail client will automatically pop up the password dialog box for him to enter the password as shown in Figure 7.6. p] EKEmail: Towards Usable and Secure Email •://•// System Sellings Mail Boxes Key Cabinet Help SJ/lnJ2°*J 53/Sent a3f T rash E n c r y p t s / S t a t u s . ll f*^ ta l i ceSV inuaHest . . -Subject' •ajLet's-trv EKEmail.-HH<Eni..il " : Please^ejuer y™ir share_d_ password. wiilValir.e.iI>virtual.tesi: Please emei your pisswbTdWairi^oflc'o^ j' Ok „ ,,Enter.|ater:-. .Date J I JuL28, .20 ,0 .6„_ Figure 7.6: Johnny enters his agreed password with Alice to receive her EKEmail request message Thereafter, his EKEmail client transparently establishes the secret key k as described in Section 5.2. Figure 7.7 shows the statechart associated with Alice in his EKEmail client. With just a simple password, Johnny can encrypt now! 58 Q I.M.in.111: K.-» CaDui. i l . n ' l|f My Secret Keys with'Friends', alice@virtual.test' , • pohnny@virtual. test Our shared secret key for securing email 128, Key type : (AES Key s i z e : New key v a l u e : New key date : Old key v a l u e : Old key date : 9201 1513 5C12FEE7 A3 8E 7228 BC8C r.r-J8 [Fri, i l 23 15:25:19 SGT 2006 Our key exchange for refreshing secret k e y -Protocol type : Key s i z e : Request da te : rS ta tus -Current s ta te : |Grant _ _„-.,. _ ,• If for any reason, this key is different with your correspondent, y o u may remove it and retry aga in . . -5^  Remove Figure 7.7: The statechart associated with Alice after Johnny receives her EKEmail Request message 7.4 The Transparency of Key Refresh As described in Section 5.6, Alice sets her EKEmail client to refresh.the secret key weekly, whereas Johnny uses the default- setting which is to refresh the secret key monthly. When Alice sends Johnny an email message a week later, her EKEmail client will automatically detect the need to refresh the secret key and wrap her email into an EKEmail Refresh Request message before sending it out. The whole process is totally transparent without any involvement from Alice. Figure 7.8 shows the statechart associated with Johnny after the email is being sent out. When Johnny selects to read Alice's email, his EKEmail client displays it as normal. Transparently in the background, a new secret key k' is established, which will be used to secure future emails between Alice and Johnny. Figure 7.9 shows the statechart associated with Alice in Johnny's EKEmail client after her email message is being read. 59 Figure 7.8: The statechart associated with Johnny in Alice's EKEmail client after it automatically initiates a Refresh Request message u' : :mu' :n s™r™K»i™aKasimi Q-EKEmail: Key Cabin My Secret Keys with .Friends' Wm£m r W , - > j ^ * j ir ahce@virt.ual.lest ljohnny@virtual.test rOur shared secret key for securing email 128 Key type: |AES Key size: New key value: New key date: Old key value: Old key date I93E0 2982 2015 462C CA41 2A15 F7E2 9F95 !Fri Aug 04 21:55:37 SGT.2006 9201 1513 5C12 FEE7A38E 7228 BC8C 5G98-Fri Jul 28 15:25:19'SGT 2006 -Our key exchange for refreshing secret key-Protocol type Key size Request dale Status 'i Current state : [Refresh C r a m : If for any reason, this key is different with your correspondent, you may remove it and retry again. Remove.-. UIJ Figure 7.9: The statechart associated with Alice in Johnny's EKEmail client after her Refresh Request message is read When Alice receives the Refresh Grant message from Johnny, her EKEmail client also transparently establishes the new secret key k' . Figure 7.10 shows the statechart associated with Johnny in Alice's EKEmail client after his email message is read. Key refresh takes place without any manual involvement from Alice and Johnny. The new secret key k' will now be used for secure email communications between them. P.. r K r , , ,:"!:!:M- , l , M!^ \ _ . . I J M y S e c r e t K e y s w i t h F r i e n d s a l i c e @ v i n u a l . t e s t j o h n n y t i g v i r t u a l . t e s t r O u r s h a r e d s e c r e t k e y f o r s e c u r i n g e m a i l K e y t y p e : |AES K e y s i z e : N e w k e y v a l u e : N e w k e y d a t e : O l d k e y v a l u e : O l d k e y d a t e : 93E0 2982 2015 4S2C CA41 2A15 F7E2 9F95 jFri Aug 04 21:57:52 SGT,.200S 9201 1513 5C12 FEE7 A38E 7228 FJC8C 5B9S Frijul 2815:28:37 SCT_2006 O u r k e y e x c h a n g e f o r r e f r e s h i n g s e c r e t k e y -P r o t o c o l t y p e : K e y s i z e : R e q u e s t d a t e : S t a t u s -C u r r e n t s t a t e : JSecure. If f o r any r e a s o n , t h i s k e y i s d i f f e r e n t w i t h y o u r c o r r e s p o n d e n t y o u m a y r e m o v e i t a n d r e t t y a g a i n . , R e m o v e Figure 7.10: The statechart associated with Johnny in Alice's EKEmail client after his Refresh Grant message is read 61 CHAPTER VIII Conclusions and Recommendations for Future Work 8.1 Conclusions W e have presented E K E m a i l , a novel email solution w h i c h is based on the new approach o f using secure key exchange to a l low secure emai l exchanges in a largely transparent way. A s elaborated upon i n Chapter 1 , secure-email users have had to forego their pr ivacy i n order to exchange email w i t h clear-email users. W i t h E K E m a i l , they are able to enjoy the benefits o f email without foregoing their privacy. W i t h E K E m a i l , we can easily begin secure email communications by s imply contacting our correspondents, maybe v i a personal meeting or just a phone cal l ( i f it is considered secure enough), to agree on a simple one-time password. There is no requirement to learn and generate our key-pairs, and there is no requirement to convince our correspondents to generate their key-pairs. W i t h E K E m a i l , key refresh is done automatically and transparently wi th perfect forward secrecy, and w i t h the additional feature that the frequency o f key refresh is determined by the party w i t h the higher refresh rate. This is i n contrast to the present P G P and S / M I M E solutions where key refresh is hardly ever done due to the difficult problems o f publ ic key distribution and revocation. F i n a l l y , w i t h E K E m a i l , the off-the-record property desirable for casual email conversations is naturally achieved. This is not possible wi th P G P or S / M E M E , where users may be held liable due to their digital signatures on their emails. 62 8.2 Recommendations for Future Works We believe that EKEmail will be of interest to many users who wish to have email privacy but are unable to use the current secure email solutions such as PGP and S/MIME. To benefit more users, the following future works are being planned: • Implement EKEmail in C/C++ for compilation into native codes. Presently, EKEmail is implemented using Java J2SE 5.0. Although it has the benefit of being machine-independent, it does. require users to have Java Runtime Environment (JRE) in their machines, which may not be available. In addition, users need to explicitly download the Unlimited Strength Jurisdiction Policy Files in order to use the Java Cryptography Extension (JCE) with unlimited strength. Furthermore, EKEmail uses the optional JavaMail 1.4 package, which will also need to be separately installed. Obviously, all these extra installation steps required by Java will drive average users away. Hence, our plan is to implement EKEmail in C/C++ and compile it into the native codes so that users may easily install and run it by simply double-clicking on its icon. • Integrate EKEmail Protocol into existing popular email clients. Users may prefer to continue using their favorite email clients instead of switching to the new EKEmail client. The EKEmail protocol is developed as a library for re-usability and ease of integration into existing email clients. Hence, to benefit more users, our next step is to integrate EKEmail protocol into existing popular email clients, possibly starting with the open-source Mozilla Thunderbird. 63 BIBLIOGRAPHY [Abe97] H. Abelson, et al., "The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption," ' World Wide Web Journal, no. 3, 1997. [AN94] M. Abadi, and R. Needham, "Prudent Engineering Practice for Cryptographic Protocols," Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1994. [Aur03] T. Aura, "Cryptographically Generated Addresses (CGA)," Proceedings of 6th International Conference on Information Security (ISC 2003), LNCS 2851, 2003. [BBL01] I. Brown, A. Back, and B. Laurie, "Forward Secrecy Extensions for OpenPGP," Internet Draft, Oct 2001 (expired). [BF01] D. Boneh, and M. Franklin, "Identity-Based Encryption from the Weil Pairing", Advances in Cryptology - CRYPTO 2001, LNCS vol. 2139, 2001. [BGB04] N. Borisov, I. Goldberg, and E. Brewer, "Off-the-Record Communication, or, Why Not To Use PGP," Workshop on Privacy in the Electronic Society (WPES), Oct 2004. [BGW01] N. Borisov, I. Goldberg, and D. Wagner, "Intercepting Mobile Communications: The Insecurity of 802.11," Proceedings of the 7th Annual International Conference on Mobile Computing and Networking (MOBICOM), Jul 2001. [BM92] S. Bellovin, and M. Merritt, "Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks," Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1992. [BM93] S. Bellovin, and M. Merritt, "Augmented Encrypted Key Exchange: a Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise," Proceedings of the 1st A C M Conference on Computer and Communications Security, Dec 1993. [BMP00] V. Boyko, P. MacKenzie, and S. Patel, "Provably Secure Password-Authenticated Key Exchange Using Diffie-Hellman," Advances in Cryptology - EUROCRYPT 2000, LNCS 1807, 2000. [BPR00] M. Bellare, D. Pointcheval, and P. Rogaway, "Authenticated Key Exchange Secure against Dictionary Attacks," Advances in Cryptology - EUROCRYPT 2000, LNCS 1807, 2000. [Bre04] V. Brennen, "GnuPG Keysigning Party HOWTO." Available: http://www.cryptnet.net/fdp/crypto/ gpg-party.html [BS03] S. Brostoff, and M. Sasse, "Ten Strikes and You're Out: Increasing the Number of Login Attempts Can Improve Password Usability," Proceedings of CHI2003 Workshop on Human-Computer Interaction and Security Systems, Apr 2003. [CRA03] Computing Research Association, "Four Grand Challenges in Trustworthy Computing," Conference on Grand Research Challenges in Information Security and Assurance, Nov 2003. [Dam89] I. Damgard, "A Design Principle for Hash Functions," Advances in Cryptology - CRYPTO '89, LNCS vol. 435, 1990. [DGB87] Y. Desmedt, C. Goutier, and S. Bengio, "Special Uses and Abuses of the Fiat-Shamir Passport Protocol," Advances in Cryptology - CRYPTO '87, LNCS 293, 1988. 64 [DH76] W. Diffie, and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, vol. 22, no. 6, Nov 1976. [DN96] E. Dawson, and L. Nielsen, "Automated Cryptanalysis of XOR Plaintext String," Cryptologia, vol. 20, no. 2, Apr 1996. [DOK04] C. Drake, J. Oliver, and E. Koontz, "Anatomy of a Phishing Attack," Proceedings of the Conference on Email and Anti-Spam (CEAS), Jul 2004. [DOW92] W. Diffie, P. Oorschot, and M. Wiener, "Authentication and Authenticated Key Exchanges," Designs, Codes and Cryptography, vol. 2, no. 2, Springer, Jun 1992. [FIPS180-1] NIST, "Secure Hash Standard," FIPS PUB 180-1, May 1993. [FIPS180-2] NIST, "Secure Hash Standard," FIPS PUB 180-2, Aug 2002. [FIPS197] NIST, "Advanced Encryption Standard (AES)," FIPS PUB 197, Nov 2001. [ES00] C. Ellison, and B. Schneier, "Ten risks of PKI: What you're not being told about public key infrastructure," Computer Security Journal, vol. 16, no. 1, 2000. [FMS01] S. Fluhrer, I. Mantin, and A. Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4," Proceedings of the 8th Annual International Workshop on Selected Areas in Cryptography, LNCS 2259, 2001. [FS86] A. Fiat, and A. Shamir, "How to Prove Yourself: Practical Solutions to Identification and Signature Problems", Advances in Cryptology - CRYPTO '86, LNCS 263, 1987. [Gar03a] S. Garfinkel, "Enabling Email Confidentiality through the use of Opportunistic Encryption," National Conference on Digital Government Research, 2003. [Gar03b] S. Garfinkel, "Email-Based Identification and Authentication: An Alternative to PKI?" IEEE Security & Privacy Magazine, vol. 1, no. 6, Nov-Dec 2003. [Gar05] S. Garfinkel, "Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable," PhD Thesis, MIT, May 2005. [GKR04] R. Gennaro, H. Krawczyk, and T. Rabin, "Secure Hashed Diffie-Hellman overNon-DDH Groups," Advances in Cryptology - EUROCRYPT 2004, LNCS 3027, 2004. [GM05] S. Garfinkel, and R. Miller, "Johnny 2: a user test of key continuity management with S/MIME and Outlook Express," Proceedings of the 1st Symposium on Usable Privacy and Security (SOUPS), July 2005. [Goo04] Google, "More on Gmail and Privacy," Jun 2004. Available: http://gmail.google.com/mail/help/ more.html [GueOl] G. Guerin, "Microsoft, VeriSign, and Certificate Revocation," Apr 2001. Available: http: //amug. org/~glguerin/opini on/revo cation. html [Gut03] P. Gutmann, "Plug-and-Play PKI: A PKI your Mother can Use," Proceedings of the 12th USENIX Security Symposium, Aug 2003. [Gut04] P. Gutmann, "Simplifying Public Key Management," IEEE Computer, vol. 37, no. 2, Feb 2004. 65 [GWOO] A. Grosul, and D. Wallach, "A Related-Key Cryptanalysis of RC4," Technical Report TR00-358, Rice University, Jun 2000. [Har87] D. Harel, "Statecharts: A Visual Formalism for Complex System," Science of Computer Programming, vol. 8, no. 3, North Holland, Jul 1987. [Hau92] J. Haugh, "Shadow Password Suite," Proceedings of the 3rd USENIX UNIX Security Symposium, Sep 1992. [Hor96] M. Horowitz, "A PGP Public Key Server," Bachelor Thesis, MIT, 1996. [Jab96] D. Jablon, "Strong password-only authenticated key exchange," A C M SIGCOMM Computer Communication Review, vol. 26, no. 5, Oct 1996. [Jab97] D. Jablon, "Extended Password Key Exchange Protocols Immune to Dictionary Attacks," • Proceedings of the Sixth Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET-ICE), Jun 1997. [Kle90] D. Klein, "Foiling the Cracker: A Survey of, and Improvements to, Password Security," Proceedings of the UNIX Security Workshop II, Aug 1990. [Koh78] L. Kohnfelder, "Towards a Practical Public-Key Cryptosystem," Bachelor Thesis, MIT, May 1978. [Kra03] H. Krawczyk, "SIGMA: The 'SIGn-and'MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols," Advances in Cryptology - CRYPTO 2003, LNCS 2729, 2003. [KT99] K. Kaukonen, and R. Thayer, "A Stream Cipher Encryption Algorithm Arcfour," Internet Draft, Jul 1999 (expired). [KY04] B. Klimt, and Y. Yang, "The Enron Corpus: A New Dataset for Email Classification Research," Proceedings of the 15th European Conference on Machine Learning (ECML 2004), LNCS 3201, 2004. [Lam81] L. Lamport, "Password authentication with Insecure Communication," Communications of the A C M , vol.24, no. 11, Nov 1981. [Luc97] S. Lucks, "Open Key Exchange: How to Defeat Dictionary Attacks Without Encrypting Public Keys," Proceedings of the 5th International Workshop on Security Protocols, Apr 1997, LNCS 1361, 1998. [MazOO] D. Mazieres, "Self-certifying File System," PhD Thesis, MIT, Jun 2000. [MicOl] Microsoft Security Bulletin MS01-017, "Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard," Mar 2001. [Mir02] I. Mironov, "(Not So) Random Shuffles of RC4," Advances in Cryptology - CRYPTO 2002, LNCS 2442, 2002. [MPS00] P. MacKenzie, S. Patel, and R. Swaminathan, "Password-Authenticated Key Exchange Based on RSA," Advances in Cryptology - ASIACRYPT 2000, LNCS 1976, 2000. [MW99] U. Maurer, and S. Wolf, "The Relationship Between Breaking The Diffie-Hellman Protocol and Computing Discrete Logarithms," SIAM Journal of Computing, vol. 28, no. 5, 1999. [Net04] Netcraft, "SSL's Credibility as Phishing Defense Is Tested." Available: http://news.netcraft.com/ archives/2004/03/08/ssls_credibility_as_phishing_defense_is_tested.html 66 [NS05] A. Narayanan, and V. Shmatikov, "Fast Dictionary Attacks on Passwords Using Time-Space Tradeoff," Proceedings of the 12th A C M Conference on Computer and Communications Security (CCS), Nov 2005. [Odl84] A. Odlyzko, "Discrete Logarithms in Finite Fields and Their Cryptographic Significance," Advances in Cryptology - EUROCRYPT '84, LNCS 209, 1985. [Pat97] S. Patel, "Number Theoretic Attacks On Secure Password Schemes," IEEE Symposium on Security and Privacy, May 1997. [Per99] R. Perlman, "An Overview of PKI Trust Models," IEEE Network, vol. 13, no. 6, Nov-Dec 1999. [Per03] T. Perrin, "Public Key Distribution through cryptoIDs," Proceedings of the Workshop on New Security Paradigms, Aug 2003. [PH78] S. Pohlig, and M. Hellman, "An Improved Algorithm for Computing Logarithms over GF(p) and Its Cryptographic Significance," IEEE Transactions on Information Theory, vol. 24, no. 1, Jan 1978. [Pol78] J. Pollard, "Monte Carol Methods for Index Computation (mod p)," Mathematics of Computation, vol. 32, no. 143, Jul 1978. [RFC822] D. Crocker, "Standard for the Format of ARP A Internet Text Messages," RFC 822, Aug 1982. [RFC989] J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encipherment and Authentication Procedures," RFC 989, Feb 1987. [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm," RFC 1321, Apr 1992. [RFC1421] J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures," RFC 1421, Feb 1993. [RFC1422] S. Kent, "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management," RFC 1422, Feb 1993. [RFC 1423] D. Balenson, "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers," RFC 1423, Feb 1993. [RFC1847] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct 1995. [RFC2045] N. Freed, andN. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies," RFC 2045, Nov 1996. [RFC2104] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Key-Hashing for Message Authentication," RFC 2104, Feb 1997. [RFC2311] S. Dusse, et al., "S/MIME Version 2 Message Specification," RFC 2311, Mar 1998. [RFC2440] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [RFC2560] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP," RFC 2560, Jun 1999. [RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method," RFC 2631, Jun 1999. 67 [RFC2898] B. Kaliski, "PKCS #5: Password-Based Cryptography Specification Version 2.0," RFC 2898, Sep 2000. [RFC3156] M. Elkins, D. Torto, R. Levien, and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [RFC3280] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile," RFC 3280, Apr 2002. [RFC3548] S. Josefsson, Ed., "The Basel6, Base32, and Base64 Data Encodings," RFC 3548, Jul 2003. [RFC3766] H. Orman, and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys," RFC 3766, Apr 2004. [RFC3850] B. Ramsdell, Ed., "S/MIME Version 3.1 Certificate Handling," RFC 3850, Jul 2004. [RFC3851] B. Ramsdell, Ed., "S/MIME Version 3.1 Message Specification," RFC 3851, Jul 2004. [RFC3852] R. Housley, "Cryptographic Message Syntax," RFC 3852, Jul 2004. [RFC4301] S. Kent, and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, Dec 2005. [RFC4306] C. Kaufman, Ed., "Internet Key Exchange (IKEv2) Protocol," RFC 4306, Dec 2005. [Riv98] R. Rivest, "Can we eliminate Certificate Revocation Lists?" Proceedings of the 2nd International Conference on Financial Cryptography (FC '98), LNCS 1465, 1998. [RSA78] R. Rivest, A. Shamir, and L. Aldeman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the A C M , vol. 21, no. 2, February 1978. [RST01] R. Rivest, A. Shamir, and Y. Tauman, "How to leak a secret," Advances in Cryptology -ASIACRYPT 2001, LNCS 2248, 2001. [San03] R. Sandhu, "Good-Enough Security: Toward a Pragmatic Business-Driven Discipline," IEEE Internet Computing, vol. 7, no. 1, Jan-Feb 2003. [SBK06] S. Sheng, L. Broderick, C. Koranda, and J. Hyland, "Why Johnny Still Can't Encrypt: Evaluating the Usability of Email Encryption Software," Symposium on Usable Privacy and Security (SOUPS), Jul 2006. [Sch96] B. Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C," 2nd Edition, John Wiley & Sons, 1996. [SH97] B. Schneier, and C. Hall, "An Improved E-Mail Security Protocol," 13th Annual Computer Security Applications Conference (ACSAC), Dec 1997. [Sha84] A. Shamir, "Identity-Based Cryptosystems and Signature Schemes," Advances in Cryptology -CRYPTO '84, LNCS 196,1985. [SIR02] A. Stubblefield, J. Ioannidis, and A. Rubin, "Using the Fluhrer, Mantin, and Shamir Attack to Break WEP," Proceedings of the Symposium on Network and Distributed System Security, 2002. [SobOl] D. Sobel, "Will Carnivore Devour Online Privacy?" IEEE Computer, vol. 34, no. 5, May 2001. 68 [Spa92] E. Spafford, "OPUS: Preventing Weak Password Choices," Computers and Security, vol. 11, no. 3, 1992. [STW95] M. Steiner, G. Tsudik, and M. Waidner, "Refinement and Extension of Encrypted Key Exchange," A C M SIGOPS Operating Systems Review, vol. 29, no. 3, Jul 1995. [Sza05] N. Szabo, "Trusted Third Parties are Security Holes," 2005. Available: http://szabo.best.vwh.net/ ttps.html [Whi04] A. Whitten, "Making Security Usable," PhD Thesis, Carnegie Mellon University, May 2004. [WT99] A. Whitten, and J. Tygar, "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0," Proceedings of the 8th USENIX Security Symposium, 1999. [WT03] A. Whitten, and J. Tygar, "Safe Staging for Computer Security," Proceedings of the Workshop on Human-Computer Interaction and Security Systems (CHI 2003), Apr 2003. [Wu98] T. Wu, "The Secure Remote Password Protocol," Proceedings of the ISOC Symposium on Network and Distributed Systems Security (NDSS), Mar 1998. [WY05] X. Wang, and H. Yu, "How to Break MD5 and Other Hash Functions," Advances in Cryptology -EUROCRYPT 2005, LNCS 3494, 2005. [WYY05] X. Wang, Y. Yin, and H. Yu, "Finding Collisions in the Full -SHAl," Advances in Cryptology -CRYPTO 2005, LNCS 3621, 2005. [X509] ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework," June 1997. [YBA04] J. Yan, A. Blackwell, R. Anderson, and A. Grant, "Password Memorability and Security," IEEE Security & Privacy Magazine, vol. 2, no. 5, Sep-Oct 2004. [Ylo96] T. Ylonen, "SSH: Secure Login Connections over the Internet," Proceedings of the 6th USENIX Security Symposium, Jul 1996. [Zim95] P. Zimmermann, "The Official PGP User's Guide," MIT Press, 1995. 69 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0064951/manifest

Comment

Related Items