Secure Group Communication in Asynchronous Networks with Failures: Integration and Experiments

1. 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. Join Leave Mass Join Mass Leave Fusion Fission Group Membership

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 • Authentic and private communication within a group • Authentic and private communication between secure group and outsiders • 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: gSa mod p • B -> A: gSb mod p • Shared key is: gSaSb mod p • Depends on difficulty of computing discrete logs • Participants work: O(log2 p) • Adversaries work: O(p0.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. broadcast Note: Group key = CLIQUES – Example 3 intermediates cardinal 2 4 • Make own contribution Ni • Raise each intermediate value to Ni • Add received cardinal value to intermediate list • Compute new cardinal = old ^ Ni • Send intermediates, cardinal to next member • n. Broadcast intermediates to all members 1

21. … CLIQUES – Example 3 2 4 5 1 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 Daemon Clients Daemon Daemon Clients

27. Spread SW Architecture Secure Spread

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

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. Key agreement Can bypass security Key used for confidentiality Provides VS semantics Secure Spread

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. Mixing Function: Blowfish • Pre-compute sub-keys PKi (521 iterations, 4KB) • Operate 16 rounds on each 64-bit block of plaintext Source: http://www.sm.luth.se/csee/courses/smd/102/lek3/lek3.html

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 IKA n (n+3)n/2 – 1 3n - 3 • CLIQUES relies on controller less, at the expense of greater computation for joins

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. CLIQUES uses 3n exponentiations CKD uses n + 6 exponentiations Evaluation – Performance Join One DH exponentiation with 512-bit modulus on SUN: 12 ms Time (sec) Group Size

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