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 List Moderator (LM) – user/process that creates lists and controls list membership List Server (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. SELS Overview LMLS U1 U2 U3 Send signed, encrypted, and HMACd email Verify HMAC, transform and forward Verify HMAC, decrypt and verify signature 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) Create Group Establish List Key K LM Establish Corresponding List Key K LS LM, LS implicitly agree K LK = K LM + K LS is list key Subscribe Establish Private key K U1 HMAC Key H U1 Establish Corresponding Private key K’ U1, HMAC Key H U1 K LK = K U1 + K’ U1

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

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.