Group Key Agreement
Gene Tsudik
SCONCE Lab, UC Irvine
1
OUTLINE
1.
2.
3.
4.
Group Communication
Security Services
Group Key Management Overview
Zooming in:
1. DH-based Protocols
2. Authentication
3. Consistency
4. Measurements
5. Robustness / Integration with GCS
6. Other models
2
General Setting:
Security in Group Communication
?
3
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
4
Dynamic Peer Groups (DPGs)
 No hierarchy
 Anyone can send and receive
 Membership changes
Relatively small (<100 of members)
5
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
Security Starts Here
6
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 member’s contribution
• No one can pre-determine the result
7
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
8
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
9
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?
10
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
11
Group Key Evolution: Epochs
Epoch 1
Epoch 2
Epoch i
Epoch n-1
Epoch n
12
‘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.
13
Layers of Key Agreement
Crashes, Malicious Disruption
Key/Content Consistency
Key Confirmation
Explicit Authentication
Implicit (Key) Authentication
Raw Key Agreement
*No defense against passive insiders… except, of course, not having a common key.
passive
14
Layers of Key Agreement – contd.
Crashes, Malicious Disruption
Amir, et al.’01, Cachin/Strobl’04
Key/Content Consistency
Key Confirmation
Katz/Yung’03, Bresson, et al.’02
Explicit Authentication
Implicit (Key) Authentication
Raw Key Agreement
*most viable approaches based on Diffie-Hellman
BD’93, Ateniese, et al.’00, PQ’01, etc.
ING’82, STR’88, BD’93, GDH’96,
Becker/Wille’99, TGDH’00
15
OUTLINE
1.
2.
3.
4.
Group Communication
Security Services
Group Key Management Overview
Zooming in:
1. DH-based Protocols
2. Authentication
3. Consistency
4. Measurements
5. Robustness / Integration with GCS
6. Other models
16
Diffie-Hellman
 Setting
• p – large prime
• g – generator




AB:
BA:
A:
B:
NA = ga mod p
NB = gb mod p
NBa = gab mod p
NAb = gab mod p
gab
a
b
17
Diffie-Hellman Problem
 Computational Diffie-Hellman Problem &
Assumption (CDHp/a)
• Given <g,ga,gb> compute gab
• Given <g,ga,gb> computing gab is hard
 Decision Diffie-Hellman Problem &
Assumption (DDHp/a)
• Given <g,ga,gb,gc> check if: gc = gab
• Given <g,ga,gb,gc> checking gc =?= gab is hard
• Stronger than CDH
18
Man-in-the-Middle Attack
Secret Key
with B is
g ea
.
a
( A, g )
e
( B, g )
DES g ea (M )
e
( A, g )
Secret Key
with A is
g eb
.
( B, g b )
DES g eb (M )
Need authentication: explicit or implicit?
19
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. ICDCS’98)
20
Intuition
 What is the “natural” extension of 2-party
Diffie-Hellman to n members?
• What is the form of the group secret?
gN1N2…Nn mod p
where Ni is Mi’s secret
share
• What information is required to compute the
group key for each member i?
gN1N2…Nn /Ni mod p
• How can we build this information?
21
GDH.2 Example: formation
1) AB:
g, ga
2) BC:
gb, ga, gab
3) CD:
gbc, gac, gab, gabc
4) DG:
gacd , gbcd , gabd, {gabc}
Everyone computes gabcd
22
GDH.3 Example: formation
AB:
ga
BC:
gab
CG: gabc
Everyone ‘factors out’ its contribution
1)
2)
3)
4)
•
•
•
5)
gbc
gac
gab
DG: gbcd , gacd , gabd, {gabc}
AD:
BD:
CD:
Everyone computes gabcd
23
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
24
Join: 2 rounds
• 2n serial exp-ns
{gN1…Nn’Nn+1/Ni | i  [1, n]}
{gN1…Nn’/Ni | i  [1, n]}
gN1…Nn’Nn+1
n exp-ns each
25
Join: 3 rounds
• n+3 serial exp-ns
{gN1…Nn’/Ni | i  [1, n-1]}
26
Summary
 Efficiency worst case (merge)
• O(n) computation for controller (2 or 3 for all
others)
(k+2) rounds
•
 Robustness
• What if a ‘token’ is lost?
• Complex recovery steps needed to achieve
robustness against (esp. cascaded) failures
27
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 = 2n+1
Relative of Becker/Wille’99 hypercube/octopus
protocols
* If based on bilinear maps (e.g., Joux)
28
Key Tree (General)
ggn gn n
1
gn g
1
gn6gn4n5
n2n3
gn g
6
gn n
n1
gn n
2 3
n2
No more
2 3
n6
4 5
n3
n4
n4n5
n5
29
Key Tree (M3’s view)
GROUP KEY
gn g
1
gn1 gn2 n3 gn6 gn4 n5
=g
n2n3
gn6gn4n5
g
gn1
n4n5
g
g
gn2n3
gn
2
n3
3
gn
4
gn
gn
6
5
Any member
who
knows
blinded
keysonon
every
nodes and
Co-path:
Set
of
siblings
of
nodes
the
key-path
Member
knows
all
keys
on
the
key-path
and
all
blinded
keys
Key-path: Set of nodes on the path from member node to root node
its own contribution can compute the group key.
30
Tree Management: Keep Tree Balanced
 Join or Merge Policy
• Join to leaf or intermediate node, if height of the tree
wouldn’t increase
• Join to root, if height of the tree would increase
 Leave or Partition policy?
• Can’t predict such events…
• Can choose to rebalance (costly!)
 Success metric
• Maintain ‘logarithmic’ depth (height < 2 log2 n)
 Extensions
• Ternary tree
• Alternative tree management techniques
• Rebalancing
31
Clustering Effect: repeated partitions
Partition:
(1,3,5,7)
(2,4,6,8)
1
2
3
4
5
6
7
8
3
1
Merge
5
7
2
4
6
8
Repeat Partition:
(1,3,5,7) (2,4,6,8)
1
3
5
7
2
4
6
8
32
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
33
Common DPG setting
LAN
34
Computation overhead
 Most GKA protocols involve modular exponentiation
1024-bit mod exp
Pentium II 450
8 ms
Pentium III 800
4 ms
Sun Ultra 250
20 ms
 Contrast with typical LAN roundtrip delay < 2ms
 On paper, communication overhead is negligible
 Number of protocol messages matters?
35
Another realistic DPG setting
sattelite
wireless
dial-up
LAN
WAN
LAN
36
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)
UCI  Columbia U
88 ms
UCI  Thailand
420 ms
UCI  Mozambique
670 ms
37
STR:
 Steer, et al. (Crypto’88)  Kim, et al. (SEC’01, ToC’03)
 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)
38
STR Key Tree
nn
n
g
1 2
3
n
g
4
g
gn
n1 n2
n
g
g3
gn
gn1n2
gn1
gn
4
3
2
39
Summary
 Efficiency
• Average # mod exp-ns (leave): 2n
• Max rounds: 2
• Max messages: 3
40
Additive Group Diffie-Hellman (BD)
 Burmester/Desmedt (Eurocrypt’94)
K= gN1N2+…+Nn-1Nn+NnN1 where Ni is Mi’s 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
41
BD Example: formation
Stage 1:
 AG:
 BG:
 CG:
 DG:
Stage 2:
 AG:
 BG:
 CG:
 DG:
ga
gb
gc
gd
Xa=(gba/gda)
Xb=(gcb/gab)
Xc=(gdc/gbc)
Xd=(gad/gcd)
Everyone computes: K = gab+bc+cd+da
e.g., B’s version: K=(ga)4b * (gcb/gab)3 * (gdc/gbc)2 * (gad/gcd)1
42
Summary
Efficiency

# mod exp-ns: 3 + (n2/2+n) multiplications*

Min #Rounds: 2

Messages: 2n (n per round)

B-casts: 2n (n per round)
Expensive in GCS setting
* Not negligible if n >10 or so…
43
Overhead Summary
Comm
GDH.3
TGDH
Comp
Rounds
Msg
Uni
Broad
Exp
Join 1
Join 2
2
3
2
n+2
1
n
1
2
2n
n+3
Leave, Partition
1
1
0
1
n-1
Merge
k+2
n+2k+1
n+2k-1
2
n+2k+1
Join, Merge
2
3
0
3
2log n
Leave
1
1
0
1
log n
Partition
log n/2
log n
0
log n
log n
Join
2
3
1
3
7
1
1
0
1
3n+6
2
3
0
3
4k+4
2
2n
0
2n
3 (4?)
STR Leave, Partition
Merge
BD
44
Other Services
45
Implicit Authentication
 Ateniese, et al. (CCS’98, JSAC’00)
 Motivation:
• same building block (exponentiation/DH)
• little additional cost
 Cons:
• not secure if membership not explicit
• requires long-term pair-wise keys
 Not recommended…
46
Authenticated GKA
 State-of-the-art: Katz/Yung (Crypto’03)
 “Compiler” for transforming secure GKA into
secure AGKA  explicit authentication +
key confirmation
• signatures and 1 extra round
• n2 messages
• instantiated with BD
47
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
48
BD Example: formation
Stage 1:
 AG:
 BG:
 CG:
 DG:
Stage 2:
 AG:
 BG:
 CG:
 DG:
ga
gb
gc
gd
Xa=(gba/gda)
Xb=(gcb/gab)
Xc=(gdc/gbX) or Xc=(gX)
Xd=(gad/gcd)
Everyone computes?
K = gab+bc+cd+da
49
GDH.3 Example: formation
1)
2)
3)
4)
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
5) DG:
gbcd , gacd , gabd -- gX
Everyone computes gabcd
50
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
51
Computation Cost (Join and Leave)
1.6
1.4
1.2
1.2
STR
0.8
0.6
0.4
0.8
0.6
0.2
0
0
8
16 24 32 40 48 56 64 72 80 88 96 104 112 120 128
8
Number of Current Group Members




STR
1
0.4
0.2

GDH
GDH
Seconds
Seconds
TGDH
TGDH
1
BD
1.4
BD
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 => signature
verification, modular multiplication
16 24 32 40 48 56 64 72 80 88 96 104 112 120 128
Number of Remaining Group Members



x-axis: # members after leave
TGDH best
STR worst
52
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
53
WAN Experimental Results
 Computational cost negligible
 Communication cost dominates
 Longest path determines delay
54
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
The herd moves at the speed of the slowest beast… 
55
Other Models
56
Asynchronous Model: Crashes+Read-only
Insider Adversary
 See Cachin/Strobl (PODC’04)
 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?
57
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_spread/
58
All done…
59