SELS: A Secure 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

Introduction to List Services 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 s, and optionally archives them User/subscribers – subscriber to/ unsubscribe from lists with the help of LM, and send/receive s 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 exchange, little or no work in providing security solutions for ELSs We provide solutions for confidentiality, integrity, authentication, and anti-spamming

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 s 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

SELS Overview LMLS U1 U2 U3 Send signed, encrypted, and HMACd Verify HMAC, transform and forward Verify HMAC, decrypt and verify signature Assumptions LM is an independent entity not controlled by LS Subscription s 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

Sending s Base-64 encoded Plaintext m Encrypt (m,Sig(m)) w/ k (AES, 3DES) Encrypt (k) w/ PK A (SELS/El Gamal) 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) Header 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

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 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

Paper available at

FAQ’s Why can’t we distribute encryption keys and have users send out s 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.