1 / 47

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

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. Outline. Overview

allegra-pope
Download Presentation

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

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

More Related