Secure Group Communication in Asynchronous Networks with Failures: Integration and Experiments By...
-
date post
18-Dec-2015 -
Category
Documents
-
view
216 -
download
3
Transcript of Secure Group Communication in Asynchronous Networks with Failures: Integration and Experiments By...
Secure Group Communication in Asynchronous Networks with
Failures: Integration and Experiments
ByYair Amir, Giuseppe Ateniese, Damian Hasse, Yongdae Kim,
Cristina Nita-Rotaru, Theo Schlossnagle, John Schultz, Jonathan Stanton, Gene Tsudik
Presented ByAnthony 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
Join
Leave
Mass Join
Mass Leave
Fusion
Fission
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: 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
1. Make own contribution Ni
2. Raise each intermediate value to Ni
3. Add received cardinal value to intermediate list
4. Compute new cardinal = old ^ Ni
5. Send intermediates, cardinal to next member
n. Broadcast intermediates to all members
CLIQUES – Example
1
2
3
4
broadcast
cardinalintermediates
Note: Group key =
21
CLIQUES – Example
1
2
3
4
5
…
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
Daemon
Daemon
Clients
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: http://www.sm.luth.se/csee/courses/smd/102/lek3/lek3.html
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
Tim
e (s
ec)
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