Integrating Encryption Techniques with Off-theshelf Email Systems* Himanshu Khurana NCSA, University of Illinois University of Washington, Seattle, March 9 2007 * Joint work with Jim Basney, Rakesh Bobba, Jin Heo and Meenal Pant
Introduction Protecting confidentiality of email is important Sensitive and private data Sending an encrypted email is hard Complex concepts; e.g., public key crypto Lack of tools/systems; e.g., key management Usability issues; e.g., interfaces Sending to a group of users even harder Promising encryption techniques, security tools, interface metaphors exist and emerging Need to be developed and integrated with email systems today!
Two Encryption Techniques Proxy encryption Convert ciphertext without access to plaintext Application: SELS (Secure Email List Services) Encryption for mailing lists Tools and Usable interfaces Identity-based encryption Eliminate (almost) distribution of public keys Application: RSA-based scheme Encryption for email Tools and Usable interfaces
Background: Encryption/Decryption for Confidentiality Alice Bob Plaintext key k Ciphertext key k Plaintext Enc Symmetric Key Encryption (AES) Dec Plaintext Pub. key PK B Ciphertext Priv. key SK B Plaintext Enc Asymmetric Key Encryption (RSA) Dec Plaintext key k, PK B Ciphertext key SK B, k Plaintext Enc Hybrid Encryption Dec
Background: Digital Signatures Alice Bob Plaintext Signing key SK A Hash Enc Signed Message Hash Verif. key PK A Dec Match?
Pretty Good Privacy (PGP) Security for Two-party Email Exchange PGP: Bob s encryption key PK B Alice Header in Plaintext Base-64 encoded message Plaintext m Encrypt k (m, Sig(m)) AES, 3DES Sign h(m) with SK A (RSA, DSA) PGP: Alice s signature verification key PK A Encrypt (k) w/ PK B RSA, El Gamal Bob Other approaches for achieving confidentiality, integrity, and authentication Privacy Enhanced Mail (PEM), Secure MIME (S/MIME) Challenge: certificate distribution and validation Identity-based encryption Public key (for encryption) generated from email address
Introduction to Mailing Lists List Moderator (LM) - creates lists - Subscribes users List Server (LS) - creates lists - forwards emails - archives email User/subscriber - subscribes to lists - sends/receives email Mailing Lists (MLs) enable users to easily exchange emails LS bears all the overhead Increasingly popular for exchange of both public and private content security is an important concern E.g., there are over 300,000 registered lists on LISTSERV while only 20% of them serve public content Little or no work in providing security solutions for MLs We provide SELS: Secure Email List Services solutions for confidentiality, integrity, and authentication http://sels.ncsa.uiuc.edu
Security Requirements X X X Confidentiality: only authorized users (i.e. list subscribers) should be able to read emails list server is excluded Integrity: receivers must be sure that email has not been modified in transit Authentication: receivers must be able to verify the identity of the sender
Need for Strong Confidentiality Maintain confidentiality of sensitive information; e.g., Security lists concerning infrastructure protection Subscribers: system/security administrators * (our initial customers) Executives lists concerning corporate strategies Subscribers: managers, executives Enforce privacy laws regarding user data in collaborative research E.g., multi-institution R&D on health care needs to enforce HIPAA laws Enable trustworthy groupware applications built on MLs; e.g., Document annotation and storage Distributed software development Mobile Teamwork * Use clunky password based encryption today
Providing Confidentiality in MLs Confidentiality Enc PK LS (m) Dec, Enc PK Ri (m) S LS R 2 R 1 DecSKRi (c) Problem: confidentiality requirement not met; adversary can compromise LS to obtain e-mails Possible Solutions Users exchange symmetric key out-of-band for encryption Difficult to provide secure key distribution Users use PGP web-of-trust to exchange secure email High key management overhead for each user Use cryptographic hardware to do decryption/encryption Expensive, one box differs from another Our solution Use software-based proxy re-encryption at LS to transform encrypted e-mail between sender and receivers without requiring access to plaintext R n
Background: Proxy Encryption * Basic idea Convert ciphertext for one key into ciphertext for another key without revealing secrets keys or cleartext messages Example construction based on El Gamal Keys for A, B: (SK A, PK A ), (SK B, PK B ) Proxy key for transformation agent T: π = (SK B SK A ) Encryption of m for Alice: g r, m(pk A ) r Transformation of mesg for Bob by T: g r, m.(pk A ) r.(g r ) π = g r, m.g r(sk A+SKB SKA) = g r, m(pk B ) r Applications Key escrow, Smartcard key management, File sharing, Group key management [KBSAHB05], Publish/Subscribe event confidentiality [K05], Certified Mailing Lists [KH06] * Initially developed by [MO97, BGM98]; later studied by [ID03, AKGH05]
Steps and Challenges Requirements Geared towards deployability System Design Maximize use of COTS components Protocol Design and Implementation Use available cryptographic libraries Analysis Tradeoffs between security and deployability Integration, Testing, Packaging and Release
Requirements Security properties Strong confidentiality, integrity, authentication LS deemed to be a semi-trusted third party Infrastructure Compatibility Compliance with existing mail standards and deployed email systems Key Management Easily obtain, trust and manage cryptographic keys Performance Should not overburden existing mail servers
System Design Server MTA (e.g., Sendmail) List Server Process (e.g., Mailman) invocation Handlers SELS Transformation Agent Key Mgmt (GPG) Crypto Functions (GPG, BC Libs) List Moderator Subscriber Interface (GPG Plugin) Crypto Functions (GPG, BC Libs) Crypto Functions (GPG, BC Libs) List Mgmt MUA Key Mgmt (GPG) Interface (GPG Plugin) Crypto Functions (GPG Lib) MUA Key Mgmt (GPG) Legend: COTS component; Developed component
Protocol Overview Establish LM Key K LM LM Create Group Establish Proxy Key K U1, Subscribe LS Transform * and forward Establish Corresponding LS Key K LS LM, LS implicitly agree K LK = K LM + K LS is list key K LK = K U1 + K U1 Send signed, encrypted, email Decrypt and verify signature Obtain key pair (K U1,PK U1 ) U1 U2 U3 * Γ (K U2) (X) = g r, m(g K LK ) r.(g rk U2 ) -1 = g r, (g K LK K U2) r m = g r, (g K U2) r m Assumption: LM is an independent entity not controlled by LS
Sending Emails in SELS Keyring: (SK A, PK LK ) Keyring: Members proxy keys K Ui Alice LS Email Header Encrypt k (m,sig(m)) Email Plaintext m (AES, 3DES) Sig(m) w/ SK A (RSA, DSA) Encrypt k w/ PK LK (El Gamal) Keyring: (PK A, SK B ) Bob LS Email Header Encrypt k (m,sig(m)) Email Plaintext m (AES, 3DES) Sig(m) w/ SK A (RSA, DSA) Transform k W/ K B (SELS Proxy Re-encryption)
Security Analysis List Key Compromise Collusion : adversary can get K LK from LS and any one user Current solution: update keys regularly Advanced solution: use threshold cryptography and additional servers LM Generated Decryption Keys Ideally users should generate their own keys Requires software at List Subscriber Consequences deemed acceptable as LM already has decryption capabilities Denial of Service against LS LS executes crypto operations without authentication; emails are encrypted Solution: rely on non-crypto authentication, wait for S/MIME ESS tools Triple-wrap: sign-encrypt-sign
Testing Compatibility: Windows, Mac, *-nix Email client with GPG plugins: Outlook, Thunderbird, Mac Mail, Emacs, Mutt Performance: reasonable 45 E-mail Size: 100KB 45 E-mail Size: 100KB 40 40 Throutput(messages/sec) 35 30 25 20 15 10 5 Insecure PSELS Throughput (messages/sec) 35 30 25 20 15 10 5 Insecure PSELS 0 10 25 50 75 100 200 List Size 0 10 25 50 75 100 200 List Size Mailman Throughput Combined Mailman and Sendmail Throughput
Packaging and Release Beta software available at sels.ncsa.uiuc.edu Test List Server being run at NCSA List Server code still to be packaged Usability studies ongoing Next steps Community testing, feature enhancements
Usability Usability challenges Installing and trusting keys Managing keys and passwords Need for GnuPG experience Approach based on groupware walkthrough Use key signing and key trusting models Assign the same password to all private keys Focused user study with high expert:novice ratio Usability Study Results Key trust assignment works better GnuPG expertise not needed
Identity-based Encryption Identity based cryptography flourishing Initial work by Cocks, Boneh and Franklin Uses pairing-based cryptography Encrypted email is a killer app for IBE (Identity Based Encryption) Primary benefit: eliminate key distribution We analyze IBE for Email and develop RSA alternative Alternative has same trust assumptions and benefits Simplicity and standards-compliance may allow for easier deployment Integration with emerging tools may ease usability
Secure Email with RSA (SMIME) Domain A Domain B CA A (SK A, PK A ) CA B (SK B, PK B ) PK R {PK R } SKB Sender (ID S ) SMIME: {m} PK R Receiver (ID R )
Secure Email with IBE Domain A Domain B PKG A (SK A, PK A ) PKG B (SK B, PK B ) PK PKG B SK R Sender (ID S ) PK R = f(pk PKG B, ID R, policy) IBE: {m} PK R Receiver (ID R )
Benefits of IBE Eliminate User Key Distribution One key fetch per domain (PKG) Sender generates public keys of domain users Policy-based encryption E.g., open after Monday Implicit user mobility Recipient can get private key from any location onto any device
Trust Assumptions IBE vs. RSA Fully trusted PKG Generates private keys Online PKG Revocation via shortlived keys Weaker end-to-end encryption PKG can decrypt messages Partially trusted CA Users generate keys Offline CA Revocation via CRLs, OCSP Strong end-to-end encryption Only recipient can decrypt messages
IBE Revocation Goal: Minimize extent of compromise IBE time-based sender policy [Boneh03] How does sender determine appropriate policy? Requires policy standardization Update domain parameters [Smetters03] Revoke the identity?
RSA-based IBE Can we implement IBE for email using RSA? Prior work: J. Callas. Identity-Based Encryption with Conventional Public-Key Infrastructure. In 4th Annual PKI R&D Workshop, number 7224 in Interagency Reports, pages 102 115. NIST, 2005. X. Ding and G. Tsudik. Simple Identity-Based Cryptography with Mediated RSA. In CT-RSA, Lecture Notes in Computer Science 2612, Springer, pages 193 210, 2003.
IB-mRSA (Ding and Tsudik, 2003) Recipient Domain CA SK R,SEM SEM Cert Org {m} PK R SK R,U Sender (ID S ) PK R = f(cert Org,ID R ) {m} PK R Receiver (ID R ) -1 {{m} PK R }SK R,SEM
Secure Email with IB-MKD (Identity Based - Message Key Distribution) KDC = Key Distribution Center {m} k denotes symmetric encryption {x} PK denotes asymmetric encryption Recipient Domain KDC (SK, PK) PK KDC {k ID R policy} PKKDC k Sender (ID S ) E(m) Receiver (ID R ) E(m) = {{m} k,{k ID R policy} PKKDC }
Object-Based Key Distribution (Ford and Wiener, 1994) Recipient Domain Key Release Agent (SK, PK) PK KRA {k} PKKRA k Sender (ID S ) E(m) = {{m} k,{k} PKKRA } E(m) Receiver (ID R )
Analysis IB-MKD achieves IBE benefits, same trust assumptions Using widely-accepted RSA cryptosystem Previous RSA-based IBE work fails to do so Protocol differences in IB-MKD User encrypts with domain public key Highlights weaker notion of end-to-end encryption Does not change security properties Policy itself is encrypted Additional feature not provided in IBE Recipient must contact KDC for every message More overhead than IBE but comparable to POP over SSL Provides timely policy evaluation and immediate revocation
Deployability and Usability Deployment challenges Distribution of KDC public keys Standards-compliant, interoperable client-side software for encryption/decryption IBMKD advantages Use DNS/DNSSEC with domainkeys Leverage existing standards, but need implementation Usability challenges Installing and managing keys Security decisions per message IBMKD approach Use client proxy Development underway with tigerprivacy, bouncycastle, Java
Conclusions Effective solutions for secure email are needed today Practical challenges Deployment on existing SMTP systems Adoption and usability We develop two solution Encrypted mailing lists with proxy encryption Other applications include attribute-based encryption [NDSS07] Challenges include resolving collusion problem in proxy encryption Simplified encryption with identity-based encryption using RSA Challenges include integration with email signing solutions
Questions? hkhurana@ncsa.uiuc.edu
System Comparison S/MIME IBE IB-mRSA Callas IB-MKD Trusted Entities CA is partially trusted for public key distribution. PKG is fully trusted. CA and SEM are fully trusted. PKG is fully trusted. KDC is fully trusted. End-to-end Encryption CA can t decrypt messages. PKG can decrypt messages. CA can decrypt messages but SEM cannot. PKG can decrypt messages. KDC can decrypt messages. Encryption Key Fetch One key fetch per recipient. One key fetch per domain. One key fetch per domain. One key fetch per recipient. One key fetch per domain. Decryption Key Fetch Offline. Recipient generates the private key. One key fetch per policy. Contact SEM for partial decryption of each message. One key fetch per policy. Obtain symmetric key from KDC for each message. Revocation OCSP/CRLs. Short-lived keys. Immediate revocation via SEM. Could support short-lived keys. Immediate revocation via KDC. Policy-based Encryption No direct support. Policy included in key generation. No direct support. Could be extended to support. Policy associated with message key. Recipient Mobility Requires smartcard or key repository. Implicit. Recipient fetches key from PKG. Requires smartcard or key repository. Implicit. Recipient fetches key from PKG. Implicit. Recipient fetches key from KDC. Encryption Key/Target Recipient key. Recipient key. Recipient key. Recipient key. KDC public key.