Secure Group Communication in Asynchronous Networks with Failures: Integration and Experiments By Yair Amir, Giuseppe Ateniese, Damian Hasse, Yongdae Kim, Cristina Nita-Rotaru, Theo Schlossnagle, John Schultz, Jonathan Stanton, Gene Tsudik Presented By Anthony Wood

2 Outline Overview Group Communication CLIQUES Spread Secure Spread Evaluation Conclusion

3 Context Secure Routing Hop-by-hop encryption / authentication SPINS Node to BS protocol, BS broadcast Efficient Distribution… BS broadcast, keychains Random Key Pre-distribution Neighbor key agreement What’s missing? Groups of nodes communicating securely

4 Secure Spread Systems look at secure group communication Internet / WAN context Secure Spread uses: Spread toolkit for communication CLIQUES for group key agreement Blowfish for group confidentiality

5 Contributions Integration of security with group communication semantics With respect to this seminar Group communication issues Security properties of groups Key agreement protocol

6 Groups History: Group communication community Internet community Wireless Sensor Network community In WSNs: Collaboration in neighborhoods Tracking mobile events “Enough”, redundancy, loose membership

7 Group Semantics Messaging facilities and semantics Reliability, ordering, safety Failure handling Fail-stop, fail-and-recover, partitions Membership Supported primitives

8 Group Membership JoinLeaveMass JoinMass LeaveFusionFission

9 Secure Groups Why not just extend 2-party key agreement? Failure of communication channel is not binary anymore Group state fluctuations must be accompanied by security adjustments Naïve pair-wise approach is expensive

10 Secure Group Semantics What do we mean by group “security”? Authentication of group as a whole Authentication of group members Confidentiality of in-group communication Confidentiality of to-group communication Membership non-repudiation Key independence

11 Secure Spread Goals 1. Authentic and private communication within a group 2. Authentic and private communication between secure group and outsiders 3. Authentication and non-repudiation of members within and outside group

12 Why Focus on Keying? Members must share a secret to achieve confidentiality More complex than message formats and mechanisms More costly in communication and computation

13 Group Keying Centralized TTP chooses key Controller / Leader chooses key Distributed Group secret is function of all members’ contributions More complex, more overhead More robust, less trust needed

14 Outline Overview Group Communication CLIQUES Spread Secure Spread Evaluation Conclusion

15 2-Party DH Agree on: An algebraic group G of order p, with generator g Protocol: A (B) chooses random Sa (Sb) < p A -> B: g Sa mod p B -> A: g Sb mod p Shared key is: g SaSb mod p Depends on difficulty of computing discrete logs Participants work: O(log 2 p) Adversaries work: O(p 0.5 )

16 CLIQUES Protocol suite for key agreement in dynamic groups (Steiner, Tsudik, Waidner, ’98 ICDCS) Uses Diffie-Hellman group key agreement Uses a group controller to manage member additions/removals Initial and Auxiliary phases Final group key:

17 CLIQUES – IKA

18 CLIQUES – Join

19 CLIQUES – Leave

20 1.Make own contribution N i 2.Raise each intermediate value to N i 3.Add received cardinal value to intermediate list 4.Compute new cardinal = old ^ N i 5.Send intermediates, cardinal to next member n. Broadcast intermediates to all members CLIQUES – Example broadcast cardinalintermediates Note: Group key =

21 CLIQUES – Example … Node 5 joins and is new controller

22 CLIQUES Attributes Distributed Contributory Computation load is distributed Uses Diffie-Hellman key agreement Fixed or floating controller, based on trust model

23 CLIQUES Requirements Group multicast Member to member unicast FIFO ordering Knowledge of membership All of these are provided by Spread

24 Outline Overview Group Communication CLIQUES Spread Secure Spread Evaluation Conclusion

25 Spread Overlay network for group communication in WANs (Amir, Stanton, ’98) Provides ordering, reliability, membership, stability Aggregates packets for efficiency over WAN Layers atop different topologies and protocols Uses hierarchical daemon-client architecture

26 Spread Architecture Daemon Clients

27 Spread SW Architecture Secure Spread

28 Spread Semantics Reliability Unreliable Reliable Ordering Unordered FIFO Causal Agreed Stability Safe Delivery Membership Extended Virtual Synchrony View Synchrony

29 EVS / VS Virtual Synchrony (ISIS, ’87 SOSP) Processes perceive failures and membership changes at same logical time Extended Virtual Synchrony (’94 ICDCS) Handles network partitions, merging, process failure and recovery View Synchrony (’97 SOPDC) Total order on views, total order on message delivery within views

30 Outline Overview Group Communication CLIQUES Spread Secure Spread Evaluation Conclusion

31 Secure Spread Integrates Spread with CLIQUES Group keying and crypto are modular Runtime binding of modules to groups Layers security services on top of Spread, exposing similar API to application

32 Secure Spread Key agreement Key used for confidentiality Provides VS semantics Can bypass security

33 Key Agreement Module CLIQUES for distributed key agreement CKD for centralized key distribution Controller exchanges keys with each member using 2-party Diffie-Hellman Controller creates group key Controller distributes group key to members one at a time

34 Blowfish 64-bit block cipher Created by Bruce Schneier Fast, compact, simple, variable key length Uses Feistel network Public domain Requires extensive sub-key computation

35 Blowfish Source: 1.Pre-compute sub-keys PKi (521 iterations, 4KB) 2.Operate 16 rounds on each 64-bit block of plaintext Mixing Function:

36 Layering vs. Integration “Client-model” is layered approach Trust Spread to provide group communication Applications (group members) take part in keying Daemon-model is integration Have to trust Spread to do it all Only daemons have to do key agreement

37 Outline Overview Group Communication CLIQUES Spread Secure Spread Evaluation Conclusion

38 Evaluation Metrics Number of messages per event Number of participants per event Serial and overall computation per event Fault tolerance Trust in members of group Load distribution

39 Evaluation – Messages Number of Messages CLIQUES Initialization:n-1 unicast, 1 broadcast Join:1 unicast, 1 broadcast Leave:1 broadcast Centralized Key Distribution (CKD) Initialization:2(n-1) unicast, 1 broadcast Join:2 unicast, 1 broadcast Leave:1 broadcast

40 Evaluation – Participants Number of participants CLIQUE-level Many fewer entities in key agreement if using daemon-model Fully contributory implies all members participate Spread-level Routing scales with daemons Clients at individual sites are reachable by a single message

41 Evaluation – Computations CLIQUES relies on controller less, at the expense of greater computation for joins IKA n (n+3)n/2 – 1 3n - 3

42 Evaluation Fault Tolerance Cascading Failure Handling: not implemented Trust Cliques: Controller can be checked CKD: Controller is trusted completely Spread: Daemons trusted to provide ordering Load Distribution Floating Controller: New member computes

43 Evaluation – Performance One DH exponentiation with 512-bit modulus on SUN: 12 ms Join Group Size Time (sec) CLIQUES uses 3n exponentiations CKD uses n + 6 exponentiations

44 Open Issues Cascading failures Handling membership changes or crashes while key adjustment is in progress Group / member certification Membership non-repudiation Secure communication with non-members Group membership policy Impact on other services

45 Application to WSNs Constraints Modular exponentiation is still expensive Message sizes are linear in group members Spread architecture is heavyweight (except perhaps for hierarchical WSNs) EVS/VS require ACKs, broadcasts, retransmissions Blowfish optimized for 32-bit architectures

46 Application to WSNs WSN Groups Will we know the full membership in a WSN group? What if group members are sleeping when a node is added? Flooding is an expensive multicast method Group Applications Mobicast Envirotrack

47 Conclusion Distributed key agreement is useful and robust—but can be expensive Tradeoffs depend on dynamics of membership, semantics desired END