1 group key agreement - theory and practice - ph.d defense presentation june 29, 2015 yongdae kim

61
1 Group Key Agreement Group Key Agreement - Theory and Practice - - Theory and Practice - Ph.D Defense Presentation March 21, 2022 Yongdae Kim

Post on 21-Dec-2015

215 views

Category:

Documents


1 download

TRANSCRIPT

1

Group Key AgreementGroup Key Agreement- Theory and Practice -- Theory and Practice -

Ph.D Defense Presentation

April 18, 2023

Yongdae Kim

2

OutlineOutline

Definitions and concepts Related work Contribution Background Work Done

– TGDH– STR – Performance Comparison

Conclusion

3

General Background:General Background:Security in Group CommunicationSecurity in Group Communication

?

4

Group Communication SettingsGroup 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 need underlying peer group communication

– Video/Audio conferencing, collaborative workspaces, interactive chat, network games and gambling

– Rich communication semantics, tighter control, more emphasis on reliability and security

5

Dynamic Peer Groups (DPG)Dynamic Peer Groups (DPG)

Relatively small (<100 of members)

No hierarchy

Frequent membership changes

Any member can be sender and receiver

My focus: key management in DPGs

6

Key Management is a building blockKey Management is a building block

Encryption, Authentication

Key Management

Authorization, Access control, Non-repudiation …

Secure Applications

Secure group video / audio conference, distributed web servers,collaborative work space, Multi-player games / gambling

7

Group Key ManagementGroup Key Management

Group key: a secret quantity known only to current group

members

Group Key Distribution– One party generates a secret key and distributes to others.

Group Key Agreement– Secret key is derived jointly by two or more parties.

– Key is a function of information contributed by each member.

– No party can pre-determine the key

8

Can we use Key Distribution in DPG?Can we use Key Distribution in DPG?

Centralized key server– Single point of failure– Attractive attack target

Can key server be sufficiently replicated? Very costly– Availability of a key server in any and all possible partitions

» Network can have arbitrary faults!

9

Distribution vs. AgreementDistribution vs. Agreement

Key Distribution Key Agreement

Key Generation Center Each member’s contribution

Communication Multicast or Unicast Group communication

Computation Overhead Small(Large for center) Large(Similar complexity)

Group Size any < 100

Contributory No Yes

Number of round Single Multiple

Example

Wong and Lam

OFT(McGrew, Sherman)

IBM(Canetti et. al.)

BD(Burmester and Desmedt)

GDH(Steiner et. al.)

TGDH(Kim et. al.)

STR(Kim et. al.)

10

Research Focus

Settings for Group Key ManagementSettings for Group Key Management

Large Smallsize

Static Dynamicnature

Few-to-many Any-to-Anysetting

Distributed Centralized authority

Stronger Weaker security

Agreement Distribution key

11

Group Communication SystemGroup Communication System

Offers– Efficient messaging : any-to-any– Dynamic membership– Message / event ordering– Fault-detection service– Fault-tolerant : resistant against cascaded failure

to peer group

Different from IP Multicast

12

Membership OperationsMembership Operations

Formation

Member join Member leave

Group partition

Group merge

13

Group key agreement protocols rely on group communication

systems for:

– Protocol message transport

– Strong membership semantics (Notification of a group membership)

– Not for security reasons

Group communication system needs specialized security

mechanisms.

Secure Group CommunicationSecure Group Communication

Mutual benefit and interdependency

14

MotivationMotivation

We need group key agreement methods satisfying the following:

– Strong security

– Dynamic operation

– Robustness

– Efficiency in communication and computation

– Implementation, integration, and measurement

15

Why is computation overhead important?Why is computation overhead important?

Most group key agreement methods rely on modular

exponentiation.– 512 bit modular exponentiation on Pentium 400 Mhz = 2 msec

– 1024 bit modular exponentiation = 8 msec

Most methods require a lot of modular exponentiations for each membership operation, some as many as O(n)

16

Security RequirementsSecurity Requirements

Group key secrecy– computationally infeasible for a passive adversary to discover any

group key

Backward secrecy– Any subset of group keys cannot be used to discover previous group

keys.

Forward secrecy– Any subset of group keys cannot be used to discover subsequent

group keys.

Key Independence– Any subset of group keys cannot be used to discover any other group

keys.– Forward + Backward secrecy

17

OutlineOutline

Definitions and concepts Related work Contributions Background Work Done

– TGDH– STR – Performance Comparison

Conclusion

18

Related WorkRelated Work

Only provide formation of a group key

– Steer et. al (1988): fast join, slow leave

– Burmester and Desmedt (BD, 1993): fast but too many broadcasts

– Becker and Wille (1998): log n communication rounds and log n

computation overhead

– Tzeng and Tzeng (1999, 2000): fast but no forward and backward

secrecy

19

Related Work (Continue)Related Work (Continue)

Cliques – Key Agreement in Dynamic Peer Groups (1996, 1997, 2000)

» Steiner, Tsudik and Waidner

» Group Diffie-Hellman key agreement protocols

» Dynamic membership operations

– New Multi-party Authentication Services and Key Agreement Protocols (1998, 2000)

» Ateniese, Steiner and Tsudik

» A notion of group key authentication is considered

– Drawbacks» Slow computation: O(n) computation for each membership event

» Communication overhead: k rounds for merge (k: # of new members)

20

Contributions (TGDH)Contributions (TGDH)

Simple and Fault-tolerant Group Key Agreement– Y. Kim, A. Perrig, G. Tsudik– ACM CCS 2000, Nov. 2000– TGDH Protocol: support for all membership changes– Computation overhead reduced from O(n) to O(log n)– Providing robustness against cascaded failure inherently

Tree-based Group Diffie-Hellman– Y. Kim, A. Perrig, G. Tsudik– In submission– Journal version of the above paper– Security proof– Self-Clustering effect

21

Contributions (STR and GKA API)Contributions (STR and GKA API)

Communication-efficient Group Key Agreement– Y. Kim, A. Perrig, G. Tsudik– IFIP SEC 2001– STR Protocol– Communication overhead is lower than any other methods– Inherent robustness against cascaded faults

The Design of a Group Key Agreement API– G. Ateniese, O. Chevassut, D. Hasse, Y. Kim, G. Tsudik – DARPA DISCEX 2000– High level design of Group Key Agreement API– Detailed implementation

22

Contributions (Integration)Contributions (Integration)

Secure Group Communication in Asynchronous Networks and Failures: Integration and Experiments– Y. Amir, G. Ateniese, D. Hasse, Y. Kim, C. Nita-Rotaru, T. Schlossnagle, J.

Schultz, J. Stanton, G. Tsudik– ICDCS 2000– Integration of Cliques group key agreement and Spread group communication

system

Exploring Robustness in Group Key Agreement– Y. Amir, Y. Kim, C. Nita-Rotaru, J. Schultz, J. Stanton, G. Tsudik– ICDCS 2001– Providing robustness in Secure Spread

Robust Contributory Group Key Agreement– Y. Amir, Y. Kim, C. Nita-Rotaru, J. Schultz, J. Stanton, G. Tsudik– In submission to ACM TOCS– Journal Version of the above two

23

Contributions (Performance and Access Contributions (Performance and Access Control)Control)

On the Performance of Group Key Agreement Protocols– Y. Amir, Y. Kim, C. Nita-Rotaru, G. Tsudik– In submission to ICDCS 2002– Comparison of 5 group key agreement/distribution schemes

Peer Group Access Control– Y. Kim, D. Mazzocci, G. Tsudik– In submission– Access control mechanism for peer group

24

OutlineOutline

Definitions and concepts Related work Contributions Cryptography Background Work Done

– TGDH– STR – Performance Comparison

Conclusion

25

Diffie-HellmanDiffie-Hellman

Setting– p – large prime (e.g. 512 or 1024 bits)

– Zp* = {1, 2, … , p – 1}

– g – base generator

A B : NA = gn1 mod p

B A : NB = gn2 mod p

A : NB n1 = gn1n2 mod p

B : NA n2 = gn1n2 mod p

Diffie-Hellman Key : gn1 n2

Blinded Key of n1 : NA = gn1 mod p

n1 n2

gn1n2

26

Diffie-Hellman ProblemDiffie-Hellman Problem

Computational Diffie-Hellman Assumption (CDH)– Loose Definition: Having known ga, gb, computing gab is hard.– CDH is not sufficient to prove that Diffie-Hellman Key can be used as

secret key.» Eve may recover part of information with some confidence

» One cannot simply use bits of gab as a shared key

Decision Diffie-Hellman Assumption (DDH)– Loose Definition

Knowing ga and gb, and guessing gc, can you check gc = gab ?– Stronger than CDH

27

OutlineOutline

Definitions and concepts Related work Contributions Background Work Done

– TGDH– STR – Performance Comparison

Conclusion

28

TGDHTGDH

Simple: Two functions enough

Fault-tolerant: Robust against cascaded faults

Secure

– Contributory

– Provable security (including key independence)

Efficient

– d is the height of key tree ( < O(log 2 N)), N is the number of users

– Maximum number of exponentiation = 4(d-1)

– # of exp. in Cliques = 2N+1

29

Key Tree (General)Key Tree (General)

n4 n5

gn4n5 n6n1

n2 n3

gn2n3

gn1gn

2n

3

ggn1gn2n3 gn6gn4n5

gn6gn

4n

5

30

Key Tree (nKey Tree (n33’s view)’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 session random can compute the group key.

31

Join (nJoin (n33’s view)’s view)

n3

gn1 gn2

ggn1n

2

gn3gn

1n

2

gn4

Tree(n4)

n3

32

n3

Join (nJoin (n33’s view)’s view)

gn1 gn2

ggn1n

2

gn3gn

1n

2

gn4n3

gn3’n4

ggn1n

2gn3’n

4

n3’

33

Leave (nLeave (n22’s view)’s view)

gn1 n2

gn1n2

gn3 gn4

ggn1n

2gn3n

4

ggn3n

4

n2gn1

34

Leave (nLeave (n22’s view)’s view)

n2

gn1n2

gn3 gn4

ggn1n

2gn3n

4

ggn3n

4

n2

35

Leave (nLeave (n22’s view)’s view)

gn3 gn4

ggn3n

4n2’

gn2’gn3n

4

36

Partition (nPartition (n55’s view)’s view)

gn4 n5

gn4n5gn1

gn3

ggn2n

3

ggn1gn

2n

3

ggn1gn

2n

3 gn6gn

4n

5

gn6gn

4n

5

n6

n2

gn6

gn2

gn6

gn2 n5

37

Partition (nPartition (n55’s view)’s view)

gn4 n5

gn4n5gn1

gn3

gn2n3

38

Partition (nPartition (n55’s view)’s view)

gn1 gn3

gn4n5

gn4 n5n5gn3 n5

Change share

n5’

ggn1n

3 gn4n5’

ggn1n

3gn4n

5’

39

Partition: Both SidesPartition: Both Sides

gn4 n5

gn1

gn3

gn6

gn2

40

Partition: Both sides (NPartition: Both sides (N55 and N and N66’s view)’s view)

gn1 gn3

gn2ggn1n

3

n5’

gn4n5’

ggn1n

3gn4n

5’ gn2n6’

n6

n2

n6’

gn4

41

Merge (to intermediate node, NMerge (to intermediate node, N22’s view)’s view)

ggn3n

4

gn4

ggn5gn

3n

4

gn5

gn3

ggn1n2gn5gn

3n

4

ggn6n

7

gn7gn6

gn1n2

n2gn1

n2gn1

gn1n2

n2

42

Merge Merge (to intermediate node)(to intermediate node)

ggn3n

4

gn4

ggn5gn

3n

4

gn5

gn3

n1

n2gn1

gn1n2 ggn6n

7

gn7gn6n2

ggn1n

2gn6n

7

gggn1n

2gn6n

7gn5gn

3n

4

43

Tree Management: do one’s bestTree Management: do one’s best

Join or Merge Policy– Join to leaf or intermediate node, if height of the tree will not increase.– Join to root, if height of the tree increases.

Leave or Partition policy– No one can expect who will leave or be partitioned out.– No policy for leave or partition event

Successful– Still maintaining logarithmic (height < 2 log2 N)

44

SecuritySecurity

Group key secrecy– Intuitive Definition

Given all blinded keys of a random key tree, can we distinguish the group key from a random number?

Proof

If we can distinguish, we can distinguish 2-party DDH on a special

group

Key independence

45

DiscussionDiscussion

Efficiency– Average number of mod exp: 2 log2 n

– Maximum number of rounds: log2 n

Robustness is easily provided due to self-stabilization property

Self-clustering– Logical Key Tree: Not depending on the physical location of the group

members

– After a partition, members on the same partition will form a cluster

– After merge, next partition on the same link is much easier

46

Self-stabilizationSelf-stabilization

Four protocols actually represent different strands of a single protocolreceive msg (msg type = membership event)

construct new tree

while there are missing blinded keys

if (I can compute any missing keys && I’m the sponsor)

compute missing blinded keys

broadcast new blinded keys

endif

receive msg (msg type = broadcast)

update current tree

endwhile

47

Cascaded EventsCascaded Events

A join, leave, merge, or partition takes place while a prior event is being handled

receive msg (msg type = membership event)construct new treewhile there are missing blinded keys

if (I can compute any missing keys && I’m the sponsor) compute missing blinded keys broadcast new blinded keysendifreceive msgif (msg type = broadcast) update current treeelse (msg type = membership event) construct new tree

endwhile

48

STRSTR

Using completely unbalanced tree Communication efficient

– Max 2 rounds– Max 2 b-casts

Simple: two function enough Fault-tolerance: easier than TGDH Security:

– Contributory– Provable security (including key independence)

Computation is bit more expensive than TGDH– Max # exps = 4(N-1) – N is # users.

49

MotivationMotivation

Over WAN, communication is much more expensive than computation– Multi-round protocol is slow

Communication always has upper bound (speed of light)– Computation speed increases much fast than communication

Too many messages are also bad– May require retransmission

Computation(1024 DSA signature) Communication (Ping)

Pentium 800 Mhz 0.0037 secs USC Columbia univ 0.0884 secs

Sun Ultra 250 MHz 0.0193 secs USC Mozambique 0.6687 secs

50

MergeMerge

gn3

gn1 gn2

gn1n2

gn3gn

1n

2

n3n3`

gn4n5

gn4 gn5

gn4

Tree(n5)

Tree(n3)

gn3’gn

1n

2

gn4gn

3’gn

1n

2

KK = gn5g

n4gn

3’gn1n2

51

DiscussionDiscussion

Security– Same as TGDH, since STR key tree is a special case of TGDH key

tree

Efficiency– Average number of mod exp: 2 n

– Maximum number of rounds: 2

– Maximum number of messages: 3

Robustness is easily provided due to self-stabilization property

52

OutlineOutline

Definitions and concepts Related work Contributions Background Work Done

– TGDH– STR – Performance Comparison

Conclusion

53

Theoretical AnalysisTheoretical Analysis

Comm CompRobust

Round Msg Uni Broad Exp

CLQ

Join 4 n+3 n+1 2 n+3

HardLeave, Partition 1 1 0 1 n-1

Merge k+3 n+2k+1 n+2k-1 2 n+2k+1

TGDH

Join, Merge 2 3 0 3 2log n

EasyLeave 1 1 0 1 log n

Partition log n/2 log n 0 log n log n

STR

Join 2 3 1 3 7

EasyLeave, Partition 1 1 0 1 3n+6

Merge 2 3 0 3 4k+4

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

CKDJoin, Merge 3 k+2 k 2 k+2

Leave, Partition 1 1 0 1 1 Easy

54

Experimental Results (Computation)Experimental Results (Computation)

Simulation Results without communication Meaningful results for LAN Average time for each membership event

Considerations– 1024 Bit RSA signature with public exponent 3 for all messages– Signing: 0.007 sec, Verifying: 0.0001 sec– TGDH: Random Tree– STR: picking random member for subtractive event

55

Computational Cost (Join and Leave)Computational 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

56

Computational Cost (Merge)Computational Cost (Merge)

0

0.5

1

1.5

2

2.5

3

3.5

8 16 24 32 40 48 56 64 72 80 88 96 104112 120

Number of Current Group Members

Se

con

ds

BD

TGDH

GDH

STR

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

1 5 9 13 17 21 25 29

Number of Current Group Members

Se

con

ds

BD

TGDH

GDH

STR

Delay for member in current group when merging 2 ~ 5 groups to result in

32 (left) or 128 (Right) members x-axis: Number of current group members For small groups (< 32), BD performs best For larger groups, TGDH is best (usually merge to root) If # of merging groups increases, TGDH results worsen

57

Computational Cost (Partition)Computational Cost (Partition)

0

0.2

0.4

0.6

0.8

1

1.2

1.4

Number of Leaving Group Members

Se

con

ds

BD

TGDH

GDH

STR

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

1 3 5 7 9 11

13

15

17

19

21

23

25

27

29

31

Number of Leaving Group members

Se

co

nd

s

BD

TGDH

GDH

STR

Delay for member in current group of starting size 32 (Left) / 128 (Right) when x members leave

Usually BD is best NOTE: clustering effect in TGDH with repeated partitions/merges!

58

Experimental Result (WAN)Experimental Result (WAN)

Using Spread over high delay WAN– JHU: 11 machines– UCI: 1 machine– ICU (Korea): 1 machine

Delay (msec)– Ping: JHU – UCI = 70, UCI – ICU = 300, ICU – JHU = 270– Actual Spread delay from Sender

» at JHU: 392

» at UCI: 328

» at ICU: 334

DH parameter: |p| = 512, |q| = 160 bit 1024 RSA with public exponent 3 Membership cost is pretty high: 1 sec

59

Experimental Result on WANExperimental Result on WAN

Computational cost does not matter much Communication cost is most important On high delay network, hard to use any group key agreement

– Imagine merge or partition cost Join: implemented with merge

– For smaller delay WAN, TGDH will be best performer overall

60

Conclusion and Future WorkConclusion and Future Work

TGDH performs best overall– Self-clustering will cancel out rather expensive partition cost

On high delay WAN, STR will perform best overall

Future Work– Security proof without assuming special group– Extensive evaluation on WAN

» Medium delay WAN

» Partition and merge test

– Hierarchical design will provide better scalability over WAN

61

Thank You!