1

Group Key AgreementGene Tsudik

SCONCE Lab, UC Irvine

2

OUTLINE

1. Group Communication

2. Security Services

3. Group Key Management Overview

4. Zooming in:1. DH-based Protocols

2. Authentication

3. Consistency

4. Measurements

5. Robustness / Integration with GCS

6. Other models

3

General Setting:Security 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

Relatively small (<100 of members)

6

DPG Security Layers

Encryption, Authentication

Key Management

Authorization, Access control, Non-repudiation …

Video / audio conferencing, distributed web servers,collaborative work space, multi-player games, replication

Secure Applications

Security Starts Here

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 member’s 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

Implicit (Key) Authentication

Raw Key Agreement

Explicit Authentication

Key Confirmation

Key/Content Consistency

Crashes, Malicious Disruption

passive

activ

e*No defense against passive insiders… except, of course, not having a common key.

activ

e

15

Layers of Key Agreement – contd.

Implicit (Key) Authentication

Raw Key Agreement

Explicit Authentication

Key Confirmation

Key/Content Consistency

Crashes, Malicious Disruption

*most viable approaches based on Diffie-Hellman

Amir, et al.’01, Cachin/Strobl’04

Katz/Yung’03, Bresson, et al.’02

BD’93, Ateniese, et al.’00, PQ’01, etc.

ING’82, STR’88, BD’93, GDH’96, Becker/Wille’99, TGDH’00

16

OUTLINE

1. Group Communication

2. Security Services

3. Group Key Management Overview

4. Zooming in:1. DH-based Protocols

2. Authentication

3. Consistency

4. Measurements

5. Robustness / Integration with GCS

6. Other models

17

Diffie-Hellman Setting

• p – large prime • g – generator

A B : NA = ga mod p B A : NB = gb mod p A : NB

a = gab mod p B : NA

b = gab mod pa b

gab

18

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

19

Man-in-the-Middle Attack

),( agA ),( egA

),( bgB),( egB

Secret Key with A is .

ebgSecret Key

with B is .

eag

)(MDES eag)(MDES ebg

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. ICDCS’98)

21

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?

22

GDH.2 Example: formation

1) AB: g, ga

2) BC: gb, ga, gab

3) CD: gbc, gac, gab, gabc

4) DG: gacd , gbcd , gabd, {gabc}

Everyone computes gabcd

23

GDH.3 Example: formation

1) AB: ga

2) BC: gab

3) CG: gabc

4) Everyone ‘factors out’ its contribution• AD: gbc

• BD: gac

• CD: gab

5) DG: 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

{gN1…Nn’Nn+1/Ni | i [1, n]}

gN1…Nn’Nn+1

n exp-ns each

{gN1…Nn’/Ni | i [1, n]}

• 2n serial exp-ns

26

Join: 3 rounds

gN1…Nn’

{gN1…Nn’/Ni | i [1, n-1]}

{gN1…N

n’Nn+1/Ni | i [1, n]}

• n+3 serial exp-ns

27

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

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 = 2n+1

Relative of Becker/Wille’99 hypercube/octopus protocols

* If based on bilinear maps (e.g., Joux)

29

Key Tree (General)

n4 n5

gn4n5 n6n1

n2 n3

gn2n3

gn1gn

2n

3

ggn1gn2n3 gn6gn4n5

gn6gn

4n

5

No more

30

Key Tree (M3’s view)

gn4 gn5

ggn4n

5 gn6gn1

gn2 n3

gn2n3

gn1gn

2n

3

GROUP KEY

ggn6gn4n5

= ggn1gn2n

3 gn6gn4n

5

n3

gn2n3

gn1gn

2n

3

GROUP KEY

Key-path: Set of nodes on the path from member node to root node

gn1

gn2

ggn6gn4n5

Co-path: Set of siblings of nodes on the key-pathMember knows all keys on the key-path and all blinded keysAny member who knows blinded keys on every nodes andits own contribution can compute the group key.

31

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

32

Clustering Effect: repeated partitions

1 2 3 4 5 6 7 8 1 3 5 7 2 4 6 8

1 3 5 7 2 4 6 8

Partition: (1,3,5,7) (2,4,6,8)

Repeat Partition: (1,3,5,7) (2,4,6,8)

Merge

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 < 2ms

On paper, communication overhead is negligible

Number of protocol messages matters?

1024-bit mod exp

Pentium II 450 8 ms

Pentium III 800 4 ms

Sun Ultra 250 20 ms

36

Another realistic DPG setting

WAN

LAN

LAN

wireless dial-upsattelite

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)

UCI Columbia U 88 ms

UCI Thailand 420 ms

UCI Mozambique 670 ms

38

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)

39

STR Key Tree

gn1

gn1n2

gn3gn

1n

2 gn4

gn3

gn4gn

3gn

1n

2

gn2

40

Summary

Efficiency

• Average # mod exp-ns (leave): 2n

• Max rounds: 2

• Max messages: 3

41

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

42

BD Example: formation

Stage 1: AG: ga

BG: gb

CG: gc DG: gd

Stage 2: AG: Xa=(gba/gda) BG: Xb=(gcb/gab) CG: Xc=(gdc/gbc) DG: 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

43

Summary

* Not negligible if n >10 or so…

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

44

Overhead SummaryComm Comp

Rounds Msg Uni Broad Exp

GDH.3

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

TGDH

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

STR

Join 2 3 1 3 7

Leave, Partition 1 1 0 1 3n+6

Merge 2 3 0 3 4k+4

BD 2 2n 0 2n 3 (4?)

45

Other Services

46

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…

47

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

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: AG: ga

BG: gb

CG: gc DG: gd

Stage 2: AG: Xa=(gba/gda) BG: Xb=(gcb/gab) CG: Xc=(gdc/gbX) or Xc=(gX) DG: Xd=(gad/gcd)

Everyone computes? K = gab+bc+cd+da

50

GDH.3 Example: formation

1) AB: ga

2) BC: gab gX

3) CG: gabc

4) Everyone ‘factors out’ its contribution• AD: gbc

• BD: gac

• CD: gab -- gX

5) DG: 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)

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128

Number of Remaining Group Members

Se

co

nd

s

BD

TGDH

GDH

STR

0

0.2

0.4

0.6

0.8

1

1.2

1.4

8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128

Number of Current Group Members

Se

con

ds

BD

TGDH

GDH

STR

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

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

The herd moves at the speed of the slowest beast…

56

Other Models

57

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?

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_spread/

59

All done…