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