1 / 20

Usable Secure Mailing Lists with Untrusted Servers

Usable Secure Mailing Lists with Untrusted Servers. Rakesh Bobba , Joe Muggli , Meenal Pant, Jim Basney and Himanshu Khurana. IDtrust , April 14 – 16, 2009. Gaithersburg, MD. Mailing Lists ( MLs ) enable users to easily exchange emails LS bears all the overhead

pooky
Download Presentation

Usable Secure Mailing Lists with Untrusted Servers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Usable Secure Mailing Lists with Untrusted Servers RakeshBobba, Joe Muggli, Meenal Pant, Jim Basney and Himanshu Khurana IDtrust, April 14 – 16, 2009. Gaithersburg, MD

  2. 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 Little or no work in providing security solutions for MLs We provide SELS: Secure Email List Services solutions for confidentiality, integrity, and authentication List Moderator (LM) - creates lists - Subscribes users List Server (LS) - creates lists - forwards emails - archives email • User/subscriber • - subscribes to lists • sends/receives • email Introduction to Mailing Lists

  3. Untrusted Servers • Existing Solutions • Password based encryption (end-to-end confidentiality) • Clunky to exchange and manage passwords out-of-band whenever a subscriber leaves • Encrypt to LS, which decrypted and re-encrypted with subscriber keys • LS takes care of key management • LS had access to plaintext messages. • Desirable to Reduce Trust Liability • Trust LS to manage lists and forward messages correctly • But do not trust LS with content of messages – “untrusted server”

  4. SELS History • Original SELS protocol. • HimanshuKhurana, Adam Slagell, and Rafael Bonilla. SELS: A Secure E-mail List Service. In proceedings of the Security Track of the ACM Symposium on Applied Computing (SAC), March 2005. • Modified, practical version of SELS, with extensive experimentation and integration. • HimanshuKhurana, Jin Heo, and Meenal Pant.From Proxy Encryption Primitives to a Deployable Secure-Mailing-List Solution. In the Eighth International Conference on Information and Communications Security (ICICS '06), Raleigh, North Carolina, December 2006.

  5. Create Group Establish Corresponding LS Key KLS LM LS LM, LS implicitly agree KLK = KLM + KLS is list key Establish Proxy Key K’U1, Establish LM Key KLM Transform and forward KLK = KU1 + K’U1 Subscribe Send signed, encrypted, email Decrypt and verify signature U3 U2 U1 Obtain key pair (KU1,PKU1) Protocol Overview Proxy re-encryption at LS ensures that plaintext is not exposed • Assumption: LM is an independent entity not controlled by LS

  6. Suitable for environments where GPG is/can be used Keyring: Members’ proxy keys K’Ui Keyring: (SKA, PKLK) Alice LS Email Header Encryptk (m,Sig(m)) (AES, 3DES) Encrypt kw/ PKLK (El Gamal) Email Plaintext m Sig(m) w/ SKA (RSA, DSA) Keyring: (PKA, SKB) Bob LS Email Header Encryptk (m,Sig(m)) (AES, 3DES) Transform k W/ K’B (SELS Proxy Re-encryption) Email Plaintext m Sig(m) w/ SKA (RSA, DSA) Sending Emails in SELS

  7. Preliminary Usability Evaluation: Groupware Walkthrough

  8. Potential Usability Issues • Installation of multiple keys • List public-key and user decryption key pair (includes private key) • Installing a private key is not common operation • Place appropriate trust in the keys • Sign them or use PGP trust model • Managing and using multiple keys • Users get a private key for every SELS list • Need to remember passwords for each key or set same password for all keys • Most GPG plug-ins cache only one password • Prior GPG experience • Lack of GPG knowledge/experience might make it unusable

  9. Focused User Study - Setup • Two Studies • Study I – sign keys to place trust • Study II – use PGP trust model • Two user groups in each study • Novice – no prior GPG experience (8 in study I and 5 in study II ) • Experts – prior GPG experience (3 in study I and 3 in study II) • 5 Parts to each study • Background questionnaire • Two Party Secure E-mail (TPSE) key installation and message exchange using GPG • SUS questionnaire • TPSE Vulnerability Evaluation • Tasks involving SELS key installation and message exchange • SUS questionnaire • SELS Vulnerability Evaluation

  10. Focused User Study - Results Observations from Study I Observations from Study II

  11. Focused User Study – Vulnerability Evaluation

  12. Vulnerability Evaluation - Results Observations from Study I Observations from Study II

  13. Useful changes to interfaces • Manage/Cache multiple passwords • Caution users on unsigned messages (Mac Mail already does this) • Alert users when signer and sender do not match

  14. SELS Deployment - Production Environment • Redundancy • Two industrial grade servers • Power backup • RAID storage • Partial list isolation • VM for each list • Manual failover • Monitoring scripts

  15. SELS Deployment • Customers are Computer Security and Incident Response Teams (CSIRTs) of Computational Grids • Experience with 2 lists from one such CSIRT • ~52 members • Previous used password based security with PGP/GPG tools • Considered expert users • 4 out of 52 faced issues • Compatibility • Misunderstanding about usage

  16. SELS Deployment • Security and usability concern of users • Concern about importing “private” key • Removed “signing key” component from SELS user keys • Concern about selecting a wrong key in the interface • Removed “email address” from names of keys for visual distinction • Pushback on placing “Ultimate Trust” in moderator key • Place “complete” or “full” trust in moderator key and sign it locally • Anecdotal evidence to suggest that SELS made it easy to exchange secure messages on these lists

  17. Where do we go from here? • Reach out and promote broader adoption • S/MIME is natively supported in popular clients • Develop SELS for S/MIME using recently added ECC support • Improve features based on feedback • Questions? • Contact: • Rakesh Bobba rbobba@illinois.uiuc.edu • HimanshuKhuranahkhurana@illinois.edu • Jim Basneyjbasney@illinois.edu • Software: www.sels.ncsa.uiuc.edu

  18. Backup Slides

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

  20. System Design • Suitable for environments where GPG is/can be used Server MTA (e.g., Sendmail) List Server (e.g., Mailman) SELS Transformation Agent Process invocation Handlers Key Mgmt (GPG) Crypto Functions (GPG, BC Libs) List Moderator Subscriber Interface (GPG Plugin) MUA Interface (GPG Plugin) MUA Crypto Functions (GPG, BC Libs) List Mgmt Key Mgmt (GPG) Crypto Functions (GPG Lib) Key Mgmt (GPG) Crypto Functions (GPG, BC Libs) Legend: COTS component; Developed component

More Related