SELS: A S ecure E -mail L ist S ervice

1. SELS: A Secure E-mail List Service Himanshu Khurana, Adam Slagell, Rafael Bonilla NCSA, University of Illinois Appeared in the ACM Symposium of Applied Computing, Santa Fe, NM, March 2005

2. Introduction to E-mail List Services • E-mail List Services (ELSs) comprise • ListModerator (LM) – user/process that creates lists and controls list membership • ListServer (LS) – maintains list and membership information, forwards e-mails, and optionally archives them • User/subscribers – subscriber to/ unsubscribe from lists with the help of LM, and send/receive e-mails with the help of LS • 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 but less than 20% of them serve public content • Unlike two-party E-mail exchange, little or no work in providing security solutions for ELSs • We provide solutions for confidentiality, integrity, authentication, and anti-spamming

3. Contribution: SELS; Solutions for • Confidentiality • Extending two-party solution would expose plaintext at LS • We wish to minimize trust liability in LS • Solution using proxy encryption techniques whereby the plaintext is not exposed at LS; instead, LS simply transforms encrypted messages • LS archives e-mails in encrypted form and provides access on-demand • Integrity and authentication • Solution using digital signatures where certificate validation (w.r.t. list membership) is provided by LM • Anti-spamming • Use digital signatures with LM providing certificate validation • Use MACs as a cheaper alternative with LS participating actively

4. Create Group Establish Corresponding List Key KLS LM LS Establish Corresponding Private key K’U1, HMAC Key HU1 LM, LS implicitly agree KLK = KLM + KLS is list key Establish List Key KLM KLK = KU1 + K’U1 Verify HMAC, transform and forward Subscribe Send signed, encrypted, and HMACd email Verify HMAC, decrypt and verify signature Establish Private key KU1 HMAC Key HU1 U3 U2 U1 SELS Overview • Assumptions • LM is an independent entity not controlled by LS • Subscription e-mails between user, LM, and LS can be secured (e.g., PGP, • passwords)

5. Key Store: Members’ corresponding private keys K’Ui and HMAC Keys HUi Key Store: (SKA, PKA),HUA Alice LS Base-64 encoded X Sig(m) w/ SKA (RSA, DSA) Key Store: (SKB, PKB), HUB Bob LS Base-64 encoded Y Encrypt (m,Sig(m)) w/ k (AES, 3DES) Email Plaintext m Sig(m) w/ SKA (RSA, DSA) Sending E-mails Email Header Encrypt (m,Sig(m)) w/ k (AES, 3DES) Encrypt (k) w/ PKA (SELS/El Gamal) H(X) w/ HUA (SHA-1) Email Plaintext m Email Header Transform k W/ K’UA, K’UB (SELS Proxy Re-encryption) H(Y) w/ HUB (SHA-1)

6. Recent Work: Formal Verification and Implementation • Formal Verification with Proverif • Fully automated protocol verification tool based on pi calculus • Verified that SELS provides confidentiality and anti-spamming • Implemented SELS Prototype in Java • Integrated with Eudora E-mail Client via command-line interface • Integrated with GnuPG Toolkit for standard Signature and Encryption operations • Work in Progress • Plugin for Eudora, Thunderbird, GnuPG • Integration with Majordomo/Mailman list server software

7. Paper available at http://www.ncsa.uiuc.edu/people/hkhurana

8. FAQ’s • Why can’t we distribute encryption keys and have users send out emails to everyone? • More computational burden on user • Extremely large encryption headers • Cannot have immediate revocation • Why can’t we just eliminate digital signatures, aren’t HMACs sufficient? • Easier recovery from compromised / misbehaving LS. • We want end-to-end authentication, not transitive trust through the LS.