Lightweight Encryption for Email Ben Adida Susan Hohenberger Ronald L. Rivest MIT MIT MIT [email protected] [email protected] [email protected] Abstract 1.1 Prior Key Management Strategies Email encryption techniques have been available for Public-key encryption has been around for 25 years. In more than a decade, yet none has been widely de- its basic form, it is well understood: a public key allows ployed. The problems of key generation, certification, for encryption, while an associated private (a.k.a. secret) and distribution have not been pragmatically addressed. key performs decryption. The complication lies in as- We recently proposed a method for implementing a sociating a public key with a user. How does Bob obtain Lightweight Public Key Infrastructure (PKI) for email Alice’s public key? How can Bob be certain that the pub- authentication using recent developments in identity- lic key he has obtained is indeed Alice’s, and not some based cryptography and today’s existing Internet infras- eavesdropper’s? tructure. In classic public-key cryptosystems like RSA [11], El While this solution works well for email authentica- Gamal [7], or Cramer-Shoup [5], each user generates a tion, email encryption exhibits a different threat model keypair. The association between a public key and an that requires special treatment. In this work, we discuss identity is then certified by the digital signature of some how to achieve email encryption and present a realistic authority. With S/MIME [10], these certification author- deployment and adoption process, while respecting the ities form an organizational hierarchy. With PGP [14], current functionality and expectations of email. an individual trusts a peer-to-peer certificate chain. In identity-based public-key cryptosystems, first con- 1 Introduction jectured in 1984 [12] but only fully implemented in 2000 [4], a master authority generates a master keypair Email is a mostly insecure communication medium. (MPK,MSK) and publishes MPK to the world. A Email encryption solutions such as the well-known user’s public key is then the combination of MPK and PGP [14] and S/MIME [10] have existed for more than a the string id string representing the user’s identity. The decade, yet neither has achieved widespread use. This is user’s secret key SK is computable from id string only due, in large part, to the complexity of key management: by a master authority in possession of MSK who deliv- a user must generate a keypair, certify and distribute his ers this key securely to the user. Though identity-based public key, and obtain a validated public key for all in- schemes simplify user-key management, there remains tended recipients. a domain-key management problem: the MPK-domain association must be safely distributed, and the user secret Even identity-based encryption [12], which proposes keys must be securely delivered. to compute public keys directly from users’ email ad- dresses (or other identity-related strings), presents key management complications. No realistic, practical ar- 1.2 The Lightweight PKI chitecture has been proposed for making use of identity- based encryption in an Internet-wide setting. We recently introduced Lightweight PKI, a mechanism Recently, we proposed and implemented a for Internet-wide distribution of identity-based public Lightweight PKI [2, 1] to manage keys for email keys for the purpose of email authentication [2, 1]. Each authentication. We now propose extensions to this email domain becomes a master authority for an identity- architecture for the purpose of email encryption. We call based scheme of its choosing and generates a unique this approach Lightweight Encryption. master keypair (MPK,MSK). Each MPK is dis- 1 USENIX Association SRUTI ’05: Steps to Reducing Unwanted Traffic on the Internet Workshop 93 tributed via the Domain Name System (DNS), as a TXT 1.4 Our (Two-Part) Solution record associated with the hostname of the domain’s Mail Exchange (MX) record. (Interestingly, Lightweight In this paper, we describe how to use the traditional ap- PKI automatically inherits security from any future im- proach of key splitting and distributed key generation [9] provements to DNS [6].) Email users obtain their secret in our identity-based framework. We apply this tech- key SK by email-based identification: the master author- nique in two ways, first to protect honest domains from ity delivers the key directly to the user’s inbox. Key revo- single-attack compromise, then to protect honest users cation is handled by using short-lived keys: the identity from overly curious incoming mail servers. string of a public key includes an expiration date [2]. Thus, Alice can sign each of her messages with her secret key. Upon receiving a signed email Protecting Honest Domains. A domain’s MSK can from [email protected], Bob can look retroactively decrypt all messages encrypted against its up MPKwonderland.com via the DNS record for public counterpart. Thus, we consider MSK so valu- wonderland.com . Then, Bob can compute Al- able that it should never be stored on a single computer. ice’s public key using MPKwonderland.com and the string However, it must remain functional enough to compute [email protected], and verify the signature. keys for new users on demand. Lightweight Signatures strike a practical compromise. We propose that a domain maintain several servers They reasonably assume that Alice’s mail server will not that independently generate master key shares actively attack Alice. Then, using only the established (MPKi,MSKi). The master public key shares infrastructures of DNS and email delivery, they make are combined into a single MPK that is distributed spoofing outgoing email from Alice as difficult as con- via the DNS. Each server with MSKi individually sistently intercepting Alice’s incoming email. sends Alice secret key share SKAlice,i. Alice can then combine all shares into a single secret key SKAlice. As expected, SKAlice correctly decrypts ciphertexts 1.3 Insufficient Security for Encryption computed against MPK and Alice’s identity string . Consider deploying Lightweight PKI for encryption. In id string this case, a passive adversarial incoming mail server could easily decrypt and read a user’s encrypted email. Protecting Honest Users. Even with split Moreover, even if Alice’s mail server is honest, the com- MSK amongst multiple servers, Alice’s secret key shares can promise of the master authority’s would reveal all MSK be intercepted by her passive, incoming mail server. prior encrypted emails for all users of that domain. Effectively, Lightweight PKI is insufficient for encryp- We must take extra precautions to help honest domains tion because it provides a single, imperfect commu- secure their master key and honest users protect their pri- nication channel: email is decrypted using the single vacy. We conclude two necessary principles for encryp- key SKwonderland.com issued by the master domain for tion: Alice wonderland.com, which is known to both Alice and her incoming mail server. 1. a domain’s cannot exist on a single machine. MSK Our solution is thus to set up multiple channels, all 2. only Alice should know her decryption key of which are necessary to perform decryption. Email- . SKAlice based identification can provide lightweight certification as long as it defines one of these channels. To ensure Al- Much like Lightweight Signatures, our practical threat ice’s privacy, only she should have access to all channels model does not defend against active mail server adver- simultaneously. saries nor the total compromise of an end-user’s personal Alice can, in fact, create one of these channels on computer. However, we do provide a reasonable privacy her own. She generates Alice Alice us- guarantee for users, using (primarily) the existing Inter- (MPK ,MSK ) ing parameters compatible with wonderland.com and net infrastructure. MPK publishes MPKAlice via the mechanism of her choice, e.g. her web page. Then, her complete decryption key Good Enough Security? In certain limited cases, the is a combination of wonderland.com and Alice. No- SKAlice SKAlice unmodified deployment of Lightweight Signature keys tice that, although Alice generates one key share on her may be good enough for encryption. It certainly achieves own, she does not need to obtain certification for it, better privacy than the majority of users enjoy today. since an active adversary who spoofs it will not have However, we can do better within the same deployment wonderland.com to read her email. We return to these SKAlice constraints. issues in Section 3.3. 2 94 SRUTI ’05: Steps to Reducing Unwanted Traffic on the Internet Workshop USENIX Association 2 DNS CombineMasterKey foo.com foo.com foo.com MPKfoo.com MPK1 MPK2 5 Lightweight 1 Cert. Server foo.com foo.com ([email protected],MPKBob) foo.com key server #1 key server #2 MPK 3 CombineMasterKey [email protected] (MSKBob,MPKBob) foo.com foo.com SKBob,1 SKBob,2 6 Bob SKBob foo.com incoming mail server GenerateShare 4 Encrypt 7 From: Alice CombineSecretKey To: Bob Subject: Secret SK Bob Bob Alice Figure 1: Lightweight Encryption: (1) The domain sets up two key servers, each in possession of a share of MSK, (2) The domain’s shares of the master public key are combined into a single key MPKfoo.com stored in the DNS, (3) each domain key foo.com server emails Bob a share of his secret key SKBob for that domain, (4) To achieve privacy from his mail server, Bob generates Bob Bob his own master keypair and stores his secret key SKBob , (5) Bob publishes his uncertified master public key MPK via a keyserver or simple web page, (6) To encrypt to Bob, Alice retrieves his two master public keys and combines them, (7) To decrypt, Bob combines his three secret keys.