Group Key Agreement

1
Group Key Agreement

• Gene Tsudik
• SCONCE Lab, UC Irvine

2
OUTLINE

• Group Communication
• Security Services
• Group Key Management Overview
• Zooming in
• DH-based Protocols
• Authentication
• Consistency
• Measurements
• Robustness / Integration with GCS
• Other models

3
General SettingSecurity in Group Communication
?
4
Group Communication Settings

• One-to-Many (or Few-to-Many)
• Single-source broadcast Cable/sat. TV, radio
• Multi-source broadcast Televised debates, GPS
• Any-to-Any
• Collaborative applications
• Video/Audio conferencing, collaborative
  workspaces, interactive chat, network games,
  replication
• Richer communication semantics, tighter control,
  more emphasis on reliability and security
• Anycast

5
Dynamic Peer Groups (DPGs)

• No hierarchy
• Anyone can send and receive
• Membership changes

6
DPG Security Layers
Video / audio conferencing, distributed web
servers, collaborative work space, multi-player
games, replication Secure Applications
Authorization, Access control, Non-repudiation
Encryption, Authentication
Key Management
Membership Control
Cert-n PKI, Revocation
7
Group Key Management

• Group key a secret quantity known only to
  current group members
• Group Key Distribution
• One party generates key and distributes to others
• Group Key Agreement
• Key derived collectively by two or more parties
• As a function of each members contribution
• No one can pre-determine the result

8
Whither Key Distribution in DPG?

• Key Distribution well-understood, easy semantics,
  synchronization
• Need centralized key server(s)
• Single point of failure
• Attractive attack target
• Arbitrary network faults can occur
• Key server replication is costly
• Availability in any and all possible partition

9
Need Reliable Group Communication

• Group key agreement protocols rely on the
  underlying group communication systems
• Protocol message transport
• Strong membership semantics (notification of all
  group membership change events)
• Not for security reasons
• Group communication system needs specialized
  security mechanisms

Mutual benefit and interdependency
10
Membership Events

• Join prospective member wants to join
• Leave member wants to (or is forced to) leave
• Partition group is split (or splits) into
  smaller groups
• Network failure network event causes
• Explicit partition application needs to split
  group
• Merge two or more groups unify
• Network fault heal previously disconnected
  partitions reconnect
• Explicit merge application merges multiple
  pre-existing groups

Forced by whom?
11
Key Change Triggers

• All (or some) of membership events
• E.g., sometimes a re-key on Join is not needed
• Application-specific requirements
• Explicit re-key, e.g. time- or data-out

12
Group Key Evolution Epochs
Epoch 1
Epoch 2
Epoch i
Epoch n-1
Epoch n
13
Raw Security Requirements

• Group key secrecy
• computationally infeasible for a passive
  adversary to discover a group key
• Backward secrecy
• Knowledge of any (contiguous?) proper subset of
  group keys cannot be used to discover previous
  group keys.
• Forward secrecy
• Knowledge of any (contiguous?) proper subset of
  group keys cannot be used to discover subsequent
  group keys.
• Key Independence
• Knowledge of any proper subset of group keys
  cannot be used to discover any other group key.

14
Layers of Key Agreement
Crashes, Malicious Disruption
active
Key/Content Consistency
Key Confirmation
Explicit Authentication
active
Implicit (Key) Authentication
Raw Key Agreement
passive
No defense against passive insiders except, of
course, not having a common key.
15
Layers of Key Agreement contd.
Crashes, Malicious Disruption
Amir, et al.01, Cachin/Strobl04
Key/Content Consistency
Key Confirmation
Explicit Authentication
Katz/Yung03, Bresson, et al.02
Implicit (Key) Authentication
BD93, Ateniese, et al.00, PQ01, etc.
Raw Key Agreement
ING82, STR88, BD93, GDH96, Becker/Wille99,
TGDH00
most viable approaches based on Diffie-Hellman
16
OUTLINE

• Group Communication
• Security Services
• Group Key Management Overview
• Zooming in
• DH-based Protocols
• Authentication
• Consistency
• Measurements
• Robustness / Integration with GCS
• Other models

17
Diffie-Hellman

• Setting
• p large prime
• g generator
• A ? B NA ga mod p
• B ? A NB gb mod p
• A NBa gab mod p
• B NAb gab mod p

gab
a
b
18
Diffie-Hellman Problem

• Computational Diffie-Hellman Problem Assumption
  (CDHp/a)
• Given ltg,ga,gbgt compute gab
• Given ltg,ga,gbgt computing gab is hard
• Decision Diffie-Hellman Problem Assumption
  (DDHp/a)
• Given ltg,ga,gb,gcgt check if gc gab
• Given ltg,ga,gb,gcgt checking gc ? gab is hard
• Stronger than CDH

19
Man-in-the-Middle Attack
Need authentication explicit or implicit?
20
Group Diffie-Hellman (GDH)

• Steiner, et al. (CCS 96)
• Contributory group key agreement protocols
• GDH.1 (silly), GDH.2 and GDH.3
• Security
• Proof of security (passive adversary)
• Key Independence
• No authentication
• Efficiency
• Few rounds except for merge
• Computational cost relatively high
• Sequel introduced support for dynamic group
  operation (Steiner, et al. ICDCS98)

21
Intuition

• What is the natural extension of 2-party
  Diffie-Hellman to n members?
• What is the form of the group secret?
• gN1N2Nn mod p where Ni is Mis secret share
• What information is required to compute the group
  key for each member i?
• gN1N2Nn /Ni mod p
• How can we build this information?

22
GDH.2 Example formation

• A?B g, ga
• B?C gb, ga, gab
• C?D gbc, gac, gab, gabc
• D?G gacd , gbcd , gabd, gabc
• Everyone computes gabcd

23
GDH.3 Example formation

• A?B ga
• B?C gab
• C?G gabc
• Everyone factors out its contribution
• A?D gbc
• B?D gac
• C?D gab
• D?G gbcd , gacd , gabd, gabc
• Everyone computes gabcd

24
Static vs Dynamic Groups

• Early protocols supported static groups only,
  e.g., conferencing with fixed parameters
• Not realistic for most applications
• Most peer groups evolve incrementally
• Leaves and partitions must be supported
• Notion of efficiency must be adjusted

25
Join 2 rounds

• 2n serial exp-ns

26
Join 3 rounds

• n3 serial exp-ns

27
Summary

• Efficiency worst case (merge)
• O(n) computation for controller (2 or 3 for all
  others)
• (k2) rounds
• Robustness
• What if a token is lost?
• Complex recovery steps needed to achieve
  robustness against (esp. cascaded) failures

28
TGDH

• Can be based on a binary or ternary key-tree
• One function suffices for all events
• Robust against cascaded faults
• Contributory
• Security
• Provable security (passive adversary)
• Key independence
• Efficient
• d tree height
• Maximum number of exponentiations 4(d-1)
• Number of exponentiations in GDH.3 2n1
• Relative of Becker/Wille99 hypercube/octopus
  protocols

If based on bilinear maps (e.g., Joux)
29
Key Tree (General)
ggn1gn2n3 gn6gn4n5
gn1gn2n3
gn6gn4n5
gn4n5
n6
n1
gn2n3
n4
n5
n2
n3
No more
30
Key Tree (M3s view)
GROUP KEY
ggn1gn2n3 gn6gn4n5
gn1gn2n3
ggn6gn4n5
ggn4n5
gn6
gn1
gn2n3
gn4
gn5
gn2
n3
Any member who knows blinded keys on every nodes
and its own contribution can compute the group
key.
Member knows all keys on the key-path and all
blinded keys
31
Tree Management Keep Tree Balanced

• Join or Merge Policy
• Join to leaf or intermediate node, if height of
  the tree wouldnt increase
• Join to root, if height of the tree would
  increase
• Leave or Partition policy?
• Cant predict such events
• Can choose to rebalance (costly!)
• Success metric
• Maintain logarithmic depth (height lt 2 log2 n)
• Extensions
• Ternary tree
• Alternative tree management techniques
• Rebalancing

32
Clustering Effect repeated partitions
Partition (1,3,5,7) (2,4,6,8)
2
3
4
1
5
6
7
8
3
5
7
2
4
6
8
1
Repeat Partition (1,3,5,7) (2,4,6,8)
Merge
3
5
7
2
4
6
8
1
33
Summary

• Efficiency
• Average mod exp 2 log2 n
• Max rounds log2 n (nasty partition!)
• Robustness easy due to self-stabilization
• Single function handles join, leave, merge,
  partition
• Can even handle cascaded events

34
Common DPG setting
LAN
35
Computation overhead

• Most GKA protocols involve modular exponentiation
• Contrast with typical LAN roundtrip delay lt 2ms
• On paper, communication overhead is negligible
• Number of protocol messages matters?

1024-bit mod exp 1024-bit mod exp
Pentium II 450 8 ms
Pentium III 800 4 ms
Sun Ultra 250 20 ms
36
Another realistic DPG setting
sattelite
wireless
dial-up
LAN
WAN
LAN
37
Motivation minimize rounds messages

• Over WAN (and wireless, dial-up, etc.)
  communication is more expensive than computation
• Communication has an upper bound (speed of light)
• Computation speed increases much fast than
  communication
• Too many messages ? some might be lost/corrupted
• Retransmissions
• Many rounds ? cascaded events (protocol
  interruption)

Communication roundtrip (Ping) Communication roundtrip (Ping)
UCI ? Columbia U 88 ms
UCI ? Thailand 420 ms
UCI ? Mozambique 670 ms
38
STR

• Steer, et al. (Crypto88) ? Kim, et al. (SEC01,
  ToC03)
• Communication-efficient
• Max 2 rounds
• Max 2 b-casts
• Concise one function does all
• Fault-tolerance/robustness simpler than TGDH
• Contributory
• Secure
• Provable security (passive adversary)
• Key independence
• Computation costs higher than TGDH
• Max exp-ns 4(N-1)

39
STR Key Tree
gn4gn3gn1n2
gn4
gn3gn1n2
gn3
gn1n2
gn2
gn1
40
Summary

• Efficiency
• Average mod exp-ns (leave) 2n
• Max rounds 2
• Max messages 3

41
Additive Group Diffie-Hellman (BD)

• Burmester/Desmedt (Eurocrypt94)
• K gN1N2Nn-1NnNnN1 where Ni is Mis secret
  share
• Contributory group key agreement protocol
• B-cast, star and other topologies
• Security
• Proof of security (passive adversary)
• Key Independence
• No authentication
• Dynamic Operations
• Roughly same as formation ? concise but expensive

42
BD Example formation

• Stage 1
• A?G ga
• B?G gb
• C?G gc
• D?G gd
• Stage 2
• A?G Xa(gba/gda)
• B?G Xb(gcb/gab)
• C?G Xc(gdc/gbc)
• D?G Xd(gad/gcd)
• Everyone computes K gabbccdda
• e.g., Bs version K(ga)4b (gcb/gab)3
  (gdc/gbc)2 (gad/gcd)1

43
Summary

• Efficiency
• mod exp-ns 3 (n2/2n) multiplications
• Min Rounds 2
• Messages 2n (n per round)
• B-casts 2n (n per round)
• Expensive in GCS setting

Not negligible if n gt10 or so
44
Overhead Summary
Comm Comm Comm Comm Comp
Rounds Msg Uni Broad Exp
GDH.3 Join 1 Join 2 2 3 2 n2 1 n 1 2 2n n3
GDH.3 Leave, Partition 1 1 0 1 n-1
GDH.3 Merge k2 n2k1 n2k-1 2 n2k1
TGDH Join, Merge 2 3 0 3 2log n
TGDH Leave 1 1 0 1 log n
TGDH Partition log n/2 log n 0 log n log n
STR Join 2 3 1 3 7
STR Leave, Partition 1 1 0 1 3n6
STR Merge 2 3 0 3 4k4
BD BD 2 2n 0 2n 3 (4?)
45
Other Services
46
Implicit Authentication

• Ateniese, et al. (CCS98, JSAC00)
• Motivation
• same building block (exponentiation/DH)
• little additional cost
• Cons
• not secure if membership not explicit
• requires long-term pair-wise keys
• Not recommended

47
Authenticated GKA

• State-of-the-art Katz/Yung (Crypto03)
• Compiler for transforming secure GKA into
  secure AGKA ? explicit authentication key
  confirmation
• signatures and 1 extra round
• n2 messages
• instantiated with BD

48
Consistency Malicious Insiders

• Problem malicious insider plays along but
  generates inconsistent output (messages)
• Inconsistent within a message
• Inconsistent between versions of same message
• How do we make sure such behavior is detectable?
• Possible solution apply compiler techiques to
  fortify existing protocols each time a private
  contribution is used, prove equality/consistency
  with prior uses by the same party
• E.g., Schnorr-based SKEQLOG proofs

49
BD Example formation

• Stage 1
• A?G ga
• B?G gb
• C?G gc
• D?G gd
• Stage 2
• A?G Xa(gba/gda)
• B?G Xb(gcb/gab)
• C?G Xc(gdc/gbX) or Xc(gX)
• D?G Xd(gad/gcd)
• Everyone computes? K gabbccdda

50
GDH.3 Example formation

• A?B ga
• B?C gab ? gX
• C?G gabc
• Everyone factors out its contribution
• A?D gbc
• B?D gac
• C?D gab -- gX
• D?G gbcd , gacd , gabd -- gX
• Everyone computes gabcd

51
Experimental Results (Computation)

• Results without communication
• Meaningful for LAN-s
• Avg time for each membership event
• Considerations
• 1024 Bit RSA signature
• TGDH Random Tree
• STR picking random member for leave

52
Computation Cost (Join and Leave)

• x-axis members before join
• TGDH, STR almost 0.1 sec
• GDH worst
• TGDH Joining node is near to root due to random
  tree
• BD hidden cost gt signature verification,
  modular multiplication

• x-axis members after leave
• TGDH best
• STR worst

53
Experimental Result (WAN)

• Using Spread over high delay WAN
• JHU 11 machines
• UCI 1 machine
• ICU (Korea) 1 machine
• Approx. 300 ms r/t time

54
WAN Experimental Results

• Computational cost negligible
• Communication cost dominates
• Longest path determines delay

55
Summary

• Seemingly efficient (i.e., least computation
  smallest message sizes) protocol is not always
  best
• Need to consider other parameters
• of messages (esp. b-cast!)
• Resilience to failures
• Complexity of implementation
• Behavior in high-latency and mixed networks

56
Other Models
57
Asynchronous Model CrashesRead-only Insider
Adversary

• See Cachin/Strobl (PODC04)
• Self-sufficient no reliance on view-providing
  GCS
• Needs tc-resilient consensus protocol
• n2 messages and O(1) extra rounds
• General not DH-based (though can be)
• Needs encryption
• Scalability?
• Experiments?

58
Further Info

• GKA (CLIQUES) toolkit GDH, STR, TGDH, BD
• http//sconce.ics.uci.edu/cliques
• Membership Control
• http//sconce.ics.uci.edu/gac
• Secure Spread
• http//www.cnds.jhu.edu/research/group/secure_sp
  read/

59
All done