Integrating Encryption Techniques with Off-theshelf Systems*

Transcription

1 Integrating Encryption Techniques with Off-theshelf Systems* Himanshu Khurana NCSA, University of Illinois University of Washington, Seattle, March * Joint work with Jim Basney, Rakesh Bobba, Jin Heo and Meenal Pant

2 Introduction Protecting confidentiality of is important Sensitive and private data Sending an encrypted 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 systems today!

3 Two Encryption Techniques Proxy encryption Convert ciphertext without access to plaintext Application: SELS (Secure 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 Tools and Usable interfaces

4 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

5 Background: Digital Signatures Alice Bob Plaintext Signing key SK A Hash Enc Signed Message Hash Verif. key PK A Dec Match?

6 Pretty Good Privacy (PGP) Security for Two-party 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 address

7 Introduction to Mailing Lists List Moderator (LM) - creates lists - Subscribes users List Server (LS) - creates lists - forwards s - archives User/subscriber - subscribes to lists - sends/receives Mailing Lists (MLs) enable users to easily exchange s 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 List Services solutions for confidentiality, integrity, and authentication

8 Security Requirements X X X Confidentiality: only authorized users (i.e. list subscribers) should be able to read s list server is excluded Integrity: receivers must be sure that has not been modified in transit Authentication: receivers must be able to verify the identity of the sender

9 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

10 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 s 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 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 between sender and receivers without requiring access to plaintext R n

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

12 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

13 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 systems Key Management Easily obtain, trust and manage cryptographic keys Performance Should not overburden existing mail servers

14 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

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

16 Sending s in SELS Keyring: (SK A, PK LK ) Keyring: Members proxy keys K Ui Alice LS Header Encrypt k (m,sig(m)) 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 Header Encrypt k (m,sig(m)) Plaintext m (AES, 3DES) Sig(m) w/ SK A (RSA, DSA) Transform k W/ K B (SELS Proxy Re-encryption)

17 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; s are encrypted Solution: rely on non-crypto authentication, wait for S/MIME ESS tools Triple-wrap: sign-encrypt-sign

18 Testing Compatibility: Windows, Mac, *-nix client with GPG plugins: Outlook, Thunderbird, Mac Mail, Emacs, Mutt Performance: reasonable 45 Size: 100KB 45 Size: 100KB Throutput(messages/sec) Insecure PSELS Throughput (messages/sec) Insecure PSELS List Size List Size Mailman Throughput Combined Mailman and Sendmail Throughput

19 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

20 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

21 Identity-based Encryption Identity based cryptography flourishing Initial work by Cocks, Boneh and Franklin Uses pairing-based cryptography Encrypted is a killer app for IBE (Identity Based Encryption) Primary benefit: eliminate key distribution We analyze IBE for 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

22 Secure 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 )

23 Secure 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 )

24 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

25 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

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

27 RSA-based IBE Can we implement IBE for 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 NIST, X. Ding and G. Tsudik. Simple Identity-Based Cryptography with Mediated RSA. In CT-RSA, Lecture Notes in Computer Science 2612, Springer, pages , 2003.

28 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

29 Secure 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 }

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

31 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

32 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

33 Conclusions Effective solutions for secure 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 signing solutions

34 Questions?

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