Collaborative Security Gene Tsudik Computer Networks Division, - PowerPoint PPT Presentation

Collaborative Security Gene Tsudik Computer Networks Division, USC/ISI gts@ics.uci.edu http://www.ics.uci.edu/~gts and Information and Computer Science Department, UC Irvine gts@isi.edu http://www.isi.edu/~gts 12/ 9/ 99 1

Group Communication G One-to-many I Single-source broadcast: cable/ sat. TV, radio, etc. G Few-to-many I Multi-source broadcast (2-tiered groups): televised debates, GPS, time, etc. G Any-to-any I Collaborative applications: conferencing, mailing lists, visualization, instrument control, simulations, replicated servers, etc. Rich communication semantics, tighter control, more emphasis on security 12/ 9/ 99 2

CLIQUES: Security in Dynamic Peer Groups (DARPA/ITO HCN, 07/97-06/00) Formation Member add Member leave Group merge Group partition 12/ 9/ 99 3

Background Targeted environment • Relatively small groups • Dynamic membership • No hierarchy • Any-to-Any • Collaborative applications Problem: how to obtain security in peer groups with dynamic membership and decentralized control? Complexity > > 2- and 3-party security 12/ 9/ 99 4

Security Services Key adjustment Key agreement Entire group Data Privacy Data Authenticity Within Group Data Privacy Data Authenticity Member Membership Member Authentication Authentication Group pk certification Member certification Data Privacy Data Authenticity Entire group Member With Outsiders Data Privacy Data Authenticity Member Member Authentication strong Authentication weak Group Access Control 12/ 9/ 99 5

Group Diffie-Hellman Important features: I Form al proof of security I Decentralized. I No ordering, no synchronization (sort of) I No topology or network dependencies I Group controller: floating or fixed (chore, not privilege!) I Everyone contributes to the key. I Everyone can prove they took part in the generation of the key. I Two message latency for join of 1 member I One message latency for leave of N members. I N+ 1 message latency for join/ merge of N members Why key agreement? I Centralized (TTP) approach: single-point, too much load I 2-,3-party extensions unscalable: n* n message exchanges 12/ 9/ 99 6

Diffie-Hellman Primer (DH78) − ≥ large prime ( 512 bits) p * = − { 1 ,..., 1 } Z p p − base (generator ) g Alice Bob a mod = A g p * ∈ a Z * ∈ b Z R p b mod = R p B g p b = mod K A p ba = a mod K B p ab Kab= ? Eve 12/ 9/ 99 7

DH Primer (contd) Discrete Log Problem : a = : mod Given A g p : FIND a − Diffie Hellman Problem : a b = = : mod mod Given A g p and B g p ab : mod FIND g p Decision DH Problem : a b = = mod , mod Given : A g p B g p = ab : mod Distinguis h K g p ab from a random number! 12/ 9/ 99 8

GDH Key Agreement L / N N n N ∈ { | [ 1 , ]} 1 g j j n 1 g N { , } g N N N N { , , } g g g 1 2 1 2 L / N N N L N N ∈ { 1 | [ 1 , ]}, g i j j i g 1 i 1 L N N = mod g p n n Key adjustments/ refresh protocols Polynomially indistinguishable easily derived and shown secure from random number! 12/ 9/ 99 9

Another GDH Key Agreement Stage 1 Stage 2 Member i Member n L / N N N g − 1 1 n i L N N N g − 1 n 1 g 1 L / N N n N ∈ { | [ 1 , ]} 1 g j j n L N N L N N g − 1 1 g n 1 i 1 L N N = mod K g p n n • 2 exponentiations per member • lots of communication 12/ 9/ 99 10

Authenticated GDH Key Agreement n L / N N K N ∈ { | [ 1 , ]}, [ ( )] 1 g n j j j n f K n 1 g N { , } g N N N N { , , } g g g 1 2 1 2 L / N N N L N N ∈ { 1 | [ 1 , ]}, g i j j i g 1 i Key Independence Perfect Forward Secrecy Stronger version: KKA Resistance S S mod i K g j p • Membership Integrity = Key Confirmation • Partial entity authentication ij Key Authentication 12/ 9/ 99 11

OFT-based Key Agreement K N K g 1234 5 = 12345 d K K K g 12 34 = 1234 d N N K g 1 2 = N N K g d 3 4 12 = d 34 Very fast merge Best-fit vs wors-fit insert Need to balance on leave Authentication hard 12/ 9/ 99 12

Security Services Provided • Decentralized authenticated group key agreement with provable security based on group Diffie-Helman: each member contributes equally to group key • Membership changes: single member, many members and sub-groups • Membership authentication and non-repudiation: based on knowledge of key-share • Authenticated join/ leave: requires long-term DH credentials Other pieces of the puzzle • Certification infrastructure • Reliable group communication subsystem • Membership Authorization / Access control 12/ 9/ 99 13

STATUS • Protocols • Initial Key Agreement • Auxiliary Key Agreement (membership changes) • Authenticated Key Agreement • Shared-key and signature strains • CLIQUES API, C implementation (rel. 1.7a) • OpenSSL as crypto base • Testing and integration with JHU’s SPREAD and UCSB’s TOTEM • Current performance results: O(n) exponentiations • 12msec on SPARC ULTRA II, 2msec on PENTIUM II 450Mhz !!! • On-going integration with AKENTI Access Control Server 12/ 9/ 99 14

CLIQUES API (contd) Underlying group communication subsystem must provide reliable synchronized event notification for: • group joins • group leaves • partitions • node failures or disconnects hardest • merges (partition heals) Supports primitives for: • leaves • joins • merges • refreshes Centralized and GDH key agreement (others tba) 12/ 9/ 99 15

Generic Architecture 12/ 9/ 99 16

Secure SPREAD Architecture 12/ 9/ 99 17

Secure Spread: join 12/ 9/ 99 18

Secure Spread: leave/partition 12/ 9/ 99 19

Secure Spread: cascaded events 12/ 9/ 99 20

Lessons learned • Paper protocols < > real protocols • Incremental formation of groups • Security, group comm not a simple composition • Comm latency vs computation (group topology!) • Difficulty of handling many merging sub-groups • Group size limits (100?) • other DH-like keys • elliptic curve duals • Provable security matters! 12/ 9/ 99 21

Challenges and directions • Two-tiered groups (few-to-many) • Group membership policy (Auth + AC) • How to specify? • Enforce? • Group certification: group key, membership, etc. • Dynamic membership? • Individual vs. opaque certificates? • How to tolerate Byzantine behavior by member(s)? • Cannot prevent key release or denial-of-service... • Member proves correct protocol execution • Group Barter • Group Signatures 12/ 9/ 99 22

Related Work Strong Group Semantics: Cornell: Birman et al. (ISIS, Horus, Ensemble) G UCSB: Melliar-Smith et al. (Totem) G HUJ: Dolev et al. (Transis) G JHU: Amir et al. (Spread) G IP Multicast: TIS: Balenson et al. (OFT) G UTA: Lam, Gouda G NSA Wallner et al. (LKH) G IBM: Canetti et al. G ETHZ: Carroni, Sun (Versa) G Theory: Ingemarsson, Tang, Wong (ToIT 81) G Burmester/ Desmedt 94 (Eurocrypt 94) G Steer/ Diffie (Crypto’89) G DeSantis/ Vaccaro/ Yung G 12/ 9/ 99 23

Publications • M. Steiner, G. Tsudik and M. Waidner Diffie-Hellman Key Distribution Extended to Groups, ACM CCCS’96 • M. Steiner, G. Tsudik and M. Waidner, CLIQUES: A New Approach to Group Key Agreement, IEEE ICDCS’98 • G. Ateniese, M. Steiner and G. Tsudik Authenticated Group Key Agreement and Friends, ACM CCCS’98 • M. Steiner, G. Tsudik and M. Waidner Key Agreement in Dynamic Peer Groups, IEEE TPDS, submitted. • G. Ateniese, M. Steiner and G. Tsudik Authenticated Group Key Agreement and Friends, IEEE JSAC, April 2000. • Y. Amir, G. Ateniese, D. Hasse, Y. Kim, C. Rotaru, J. Stanton, J. Schultz, and G. Tsudik, Spread/ CLIQUES Integration Experience, IEEE ICDCS’00 • D. Hasse, Y. Kim, O. Chevassut and G. Tsudik, The Design of Group Key Agreement API, DARPA DISCEX’00. 12/ 9/ 99 24

Summary Impact: • IBM • JHU • LBNL • IRTF CLIQUES web page: http: / / www.isi.edu/ div7/ cliques • API documentation • Publications • Presentations API code by request from gts@isi.edu Collaborators: • IBM Research, Johns Hopkins, LBNL, Nortel People: • G. Ateniese, O. Chevassut, D. Hasse, Y. Kim, G. Tsudik 12/ 9/ 99 25

Other current research • Integrated and Reliable Multicast in Ad Hoc Networks (NSF) • Secure IP multicast (Nortel) • Survivability Using Controlled Security Services (DARPA) • Server-Assisted Digital Signatures (NSA) • Access Control in Collaborative Applications (DoE, w/ LBNL) 12/ 9/ 99 26