1.1

Distributed and Collaborative Key Distributed and Collaborative Key Agreement Protocols with Authentication Agreement Protocols with Authentication

and Implementation for Dynamic Peer and Implementation for Dynamic Peer GroupsGroups

Patrick Pak-Ching LEE

1.2

Presentation Outline

To identify the motivation of group key management; To introduce Tree-based Group Diffie-Hellman (TGDH); To propose three interval-based distributed rekeying algorithm

s: Rebuild, Batch and Queue-batch. To present performance evaluation results; To explain the authentication mechanism incorporated into the

rekeying algorithms; To describe an implementation library, SGCL, and To suggest future research directions.

1.3

What are the Applications?

Many group-oriented applications demand communication confidentiality. For example, chat-rooms, audio/video conferencing applications, file sharing tools, router communication paradigms, secure communication for network games in

strategy planning. We need a secure group key management

scheme so that the group can encrypt communication data with a common secret group key.

1.4

Desired Properties of Gp. Key Mgt.

Distributed: there is no centralized key server, which has the following limitations: A single point of failure; and Not suitable for peer groups and ad hoc networks.

Collaborative: all group members contribute their own part to generate a group key.

Dynamic: the protocol remains efficient even when the occurrences of join/leave events are very frequent.

1.5

Our Work

Focused on group key agreement schemes which do not rely on centralized key management.

Designed three interval-based distributed rekeying algorithms that have the distributed, collaborative and dynamic features.

Conducted performance evaluation analysis to illustrate the performance merits of the interval-based algorithms.

Incorporated an authentication mechanism into the interval-based algorithms.

Implemented a library for the development of secure group-oriented applications.

1.6

Tree-based Group Diffie-Hellman (TGDH)

A binary key tree is formed. Each node v represents a secret (private) key Kv and a blinded (public) key BKv.

BKv = αKv mod p, where α and p are public parameters. Every member holds the secret keys along the key path For simplicity, assume each member knows the all

blinded keys in the key tree.

0

M1 M2

2

4 6

7

1

53

8 11 12M3

M4 M5

M6

0

1

3

7

K0 = Group Key

1.7

TGDH: Node Relationships

Kv = (BK2v+1)K2v+2 = (αK2v+1)K2v+2 mod p

vThe secret key of a non-leaf node v can be generated by:

Kv = (BK2v+2)K2v+1 = (αK2v+2)K2v+1 mod p

2v+1 2v+2BK2v+1

BK2v+2

Kv = αK2v+1K2v+2 mod p

The secret key of a leaf node is randomly selected by the corresponding member.

1.8

TGDH: Group Key Generation

0

M1 M2

2

4 6

7

1

53

8 11 12M3

M4 M5

M6

E.g., M1 generates the group key via:

K7, BK8 K3

K3, BK4 K1

K1, BK2 K0 (Group Key)

7

3

1

0

4

2

8

1.9

TGDH: Membership Events

Rekeying (renewing the keys of the nodes) is performed at every single join/leave event to ensure backward and forward confidentiality.

A special member called sponsor is elected to be responsible for broadcasting updated blinded keys.

time

Join Leave Join Join Leave

rekey rekey rekey rekey rekey

1.10

TGDH: Single Leave Case

M4 becomes the sponsor. It rekeys the secret keys K2 and K0 and broadcasts the blinded key BK2.

M1, M2 and M3 compute K0 given BK2.

M6 and M7 compute K2 and then K0 given BK5.

5

11 12

M4 M5

0

2

M1 M2

4 6

7

1

3

8M3

M6

13 14

M7

5

12

2

0M5 leaves

5

M4(S)

1.11

M4

0

TGDH: Single Join Case

M8 broadcasts its individual blinded key BK12 on joining.

M4 becomes the sponsor again. It rekeys K5, K2 and K0 and broadcasts the blinded keys BK5 and BK2.

Now everyone can compute the new group key.

1211

M4(S)

M8 joins

2

5

M8M1 M2

4 6

7

1

3

8M3

M6

13 14

M7

5

2

0

1.12

Interval-based Distributed Rekeying Algorithms

We can reduce one rekeying operation if we can simply replace M5 by M8 at node 12.

Interval-based rekeying is proposed such that rekeying is performed on a batch of join and leave requests at regular rekeying intervals. This improves the system performance.

We propose three interval-based rekeying algorithms, namely Rebuild, Batch and Queue-batch.

Sponsors are elected at every rekeying event. They coordinate with each other in broadcasting new blinded keys.

1.13

0

M1 M2

2

4 6

7

1

53

8 11 12M3

M4 M5

M6

23 24

M7

Rebuild Algorithm

Intuition: Minimize the height of the key tree so that every member manages fewer renewed nodes in the subsequent rekeying operations.

Basic Idea: Reconstruct the whole key tree to form a complete tree.

0

M1(s) M3(S)

2

4 6

7

1

53

8M4(S) M6(S) M8(S)

0

21

3

M2, M5, M7 leaveM8 joins

We can explore the situations where Rebuild is applicable.

1.14

Batch Algorithm

Intuition: Add the joining members to suitable positions.

Basic Idea: Replace the leaving members with the

joining members. Attach the joining members to the

shallowest positions. Keep the key tree balanced.

Elect the sponsors who help broadcast new blinded keys.

1.15

0

M1 M2

2

4 6

7

1

53

8 11 12M3

M4 M5

M6

23 24

M7

11

24

Batch – Example 1: L > J > 0

M8 broadcasts its join request, including its blinded key.

M1 rekeys secret keys K1 and K0. M4 rekeys K5, K2 and K0.

M1 broadcasts BK1. M4 broadcasts BK5 and BK2.

63

8

M2, M5, M7 leaveM8 joins

0

21

5

M1(S)

3

M8(S)

6

M4(S)

11

1.16

0

M1 M2

2

4 6

7

1

53

8 11 12M3

M4 M5

M6

23 24

M7

Batch – Example 2: J > L > 0

M8 and M9 form a subtree T1’. M10 itself forms a subtree T2’. M8 and M9 compute K6, and one of them broadcasts BK6. M1 rekeys K3 and K1. M6 rekeys K2. M1 broadcasts BK3 and BK1. M6 broadcasts BK2.

0

21

3 6

8

6

13 14

M8(S) M9(S)

T1’

M8, M9, M10 joinM2, M7 leave

M10(S)

8

T2’

1.17

Queue-batch Algorithm

Intuition: Pre-process the join events during the idle rekeying interval, hence reduce the processing load at the beginning of each rekeying interval.

Basic Idea: Two stages: Queue-subtree and Queue-merge Queue-subtree: Within the idle rekeying interval, attach each joinin

g member to a subtree T’. Queue-merge: At the beginning of the next rekeying interval, add th

e subtree T’ to the existing key tree, and prune all nodes of the leaving members.

1.18

Queue-batch – Example of Queue-merge

T’ is attached to node 6. M10, the sponsor, will broadcast BK6.

M1 rekeys K1. M6 rekeys K2.

M1 broadcasts BK1. M6 broadcasts BK2.

0

21

0

M1 M2

2

4 6

7

1

53

8 11 12M3

M4 M5

M6

23 24

M7

M8, M9, M10 joinM2, M7 leave

3 6

8M1(S)

3 6

13 14

M8 M9

T’

27 28M10(S)

1.19

Performance Evaluation

Methods: mathematical models + simulation experiments

Performance Metrics: Number of renewed nodes: This metric provides a

measure of the communication cost. Number of exponentiation operations: This metric

provides a measure of the computation load. Settings:

There is only one group. The population size is fixed at 1024 users. Originally, 512 members are in the group.

1.20

Evaluation 1: Mathematical Models

Start with a well-balanced tree with 512 members. Obtain the metrics at different numbers of joining and leaving

member in a single rekeying interval. Queue-batch offers the best performance, and a significant com

putation/communication reduction when the group is very dynamic.

1.21

Evaluation 2: Simulation Experiments

Start with a well-balanced tree with 512 members. Every potential member joins the group with probability pJ, and

every existing member leaves the group with probability pL. Evaluate the average / instantaneous metrics at different join/le

ave probabilities over 300 rekeying intervals.

1.22

Evaluation 2: Simulation Experiments

Average number of exponentiations at different fixed join probabilities:

pJ=0.25 pJ=0.5

pJ=0.75

1.23

Evaluation 2: Simulation Experiments

Average number of renewed nodes at different fixed join probabilities:

pJ=0.25 pJ=0.5

pJ=0.75

1.24

Discussion of Evaluation Results

Queue-batch offers the best performance among the three interval-based algorithms.

The performance of Queue-batch is even superior under frequent joins/leaves. Frequent join: queue-batch gains from pre-

processing Batch doesn’t have the pre-processing

advantage. Frequent leave: queue-batch prunes departure

nodes Batch replaces departure nodes with joins.

1.25

Authenticated TGDH (A-TGDH)

Motivation: Non-authenticated TGDH is subject to the

man-in-the-middle attack. Simple signature is not enough.

Basic idea: Authenticate every short-term (or

session) blinded key with a certified long-term (or permanent) private component.

The group key contains both short-term and long-term components.

1.26

A-TGDH: Concepts

Each member Mi holds two pairs of keys: Short-term secret and blinded keys (rmi, αrmi mod p), which remain v

alid from the time Mi joins until it leaves. Long-term private and public keys (xmi, αxmi mod p), which remain p

ermanent and are certified by a trusted party. Mi generates an authenticated short-term blinded key using Mj

’s long-term public key:(αxmj)rmi mod p = (αrmi)xmj mod p

Physical meaning: L.S.: generator α is authenticated, i.e., α becomes αxmj

R.S.: the short-term blinded key αrmi is encrypted with a long-term private key xmj.

1.27

A-TGDH: 2-Party Case

It is based on the AK protocol (Indocrypt ’00). Assume M1 and M2 occupy the long-term public key of the other member.

The authenticated short-term secret key is:

K = αrm1rm2 + rm1xm2 + rm2xm1 (mod p)

M1 M2

(αxm2)rm1

(αxm1)rm2

Retrieves αr2.Gets K as:

(αrm2)rm1 (αxm2)rm1 (αxm1)rm2

Retrieves αr1.Gets K as:

(αrm1)rm2 (αxm2)rm1 (αxm1)rm2

1.28

A-TGDH: Multi-Party Case

Idea: Encrypt the blinded key of node v with long-term private key of Mi: α

Kvxmi mod p. The authenticated short term secret key of

node v is the product of: Non-authenticated short-term secret key Authenticated blinded keys of left child by the long-

term components of right child’s descendants Authenticated blinded keys of right child by the long-

term components of left child’s descendants

1.29

A-TGDH: Multi-Party Case

Secret key at leaf nodes: rmi mod p Authorized secret key of K1 is:

K1 =αrm1rm2 + rm1xm2 + rm2xm1 mod p Authorized group key K0 is:

K0 = αK1K2 + K1(xm3+xm4) + K2(xm1+xm2) mod p Double-protection on the group key (with rmi and xmi)

0

M1 M2

2

4 6

1

53

M3 M4

1.30

A-TGDH: Characteristics

Key authentication: no outsiders access the keys.

Key confirmation: every member possesses the same group key.

Known-key secrecy: past short-term keys cannot deduce future short-term keys.

Perfect forward secrecy: current long-term keys cannot deduce past short-term keys.

1.31

SGCL Implementation

We realized our algorithms via the Secure Group Communication Library (SGCL): Linux-based C language API

SGCL facilitates developers to build secure group-oriented applications.

Two testing applications: Chatter and Gauger Chatter: secure chat-room Gauger: performance testing tool

1.32

SGCL: Overview

Leader: responsible for notifying others to start

a rekeying operation

REKEYREKEYREKEYREKEYREKEYREKEYREKEY

REKEY

The one which stays the longest

1.33

SGCL: Overview

Leader

Blinded keyBlinded keyBlinded keyBlinded keyBlinded keyBlinded keyBlinded keyBlinded key

Sponsors: responsible forbroadcasting new

blinded keys Blinded key

Blinded key

Blinded key

1.34

SGCL: Architecture

Keytreeengine

Sesskeyengine

Memberengine

Leaderengine

Certkeyengine

Packetengine

Message queue

Packet queue

Spread daemonMaintain reliable

and ordered communication

SGCLAPI

Receivethread

Processthread

verify verify

sign sign

1.35

SGCL: API Functions

SGCL_init() SGCL_set_passwd()

SGCL_join()SGCL_send()SGCL_recv()

SGCL_read_membership()

SGCL_send()SGCL_recv()

SGCL_read_membership()SGCL_leave()SGCL_leave()

SGCL_destroy()

SGCL sessionobject

1.36

SGCL: Experiments

Gauger: study the performance of the interval-based algorithms under real network settings.

Metrics: 1) Rekeying duration, 2) no. of exponentiations,

3) no. of blinded keys, and 4) no. of broadcasts of blinded keys

Settings: 40 Gaugers, even located in eight P4/2.5GHz’s Inter-connected in a single LAN

1.37

SGCL: Result Highlights

Highlights: Average analysis of no. of exponentiations and no. of blinded keys

Queue-batch shows dominant performance under the high membership dynamics.

1.38

SGCL: Applications

Chatter

1.39

Conclusion

Three interval-based distributed rekeying algorithms: Rebuild, Batch and Queue-batch

Performance evaluation: mathematical models and simulation experiments

Authentication Implementation of SGCL

1.40

Internet

Future Directions

LAN B

LAN C

LAN DLAN A

1.41

Internet

Future Directions

A hybrid key tree with both physical and logical properties:

LAN B

LAN C

LAN DLAN A

1.42

Future Directions

Robustness against attacks: Erroneous key confirmation Forged packets/signatures Leader masquerade

Security in Spread daemons Encryption between a Spread daemon and SGCL Encryption among the Spread daemons

Key tree updates: Interval-based Threshold-based

1.43

SGCL: Leader and Sponsors

Leader: Election: the one which stays the longest in the

group. Sponsors:

Election: the rightmost member of the subtree whose root is not renewed but root’s parent is.

Coordination: the blinded key of a renewed node is broadcast by the sponsor which can broadcast a sequence of blinded keys in one round.

Ml(s) Mr(s)

1.44

SGCL: Leader Components

Keytreeengine

Sesskeyengine

Memberengine

Leaderengine

Certkeyengine

Packetengine

Rekey queue

Spread daemon

Rekeypoll

thread

Rekeysend

threadsign sign

1.45

Q: Related Work

Intra Domain Group Key Management Protocol Domain Key Distributor + Area Key Distributor

Iolus Rekeying in subgroup level Subgroup manager re-encrypt data sessions

Centralized Physical Hierarchical Schemes

DKD

AKD

AKD

AKD

M

M

M

MM

M

M

M

M

1.46

Q: Related Work

Kronos Periodic rekeying

Reversible Parametric Sequences (RPS) Router tree Group key encryption along the tree path

Centralized Physical Hierarchical Schemes

a1

a6 a7

a3

a2a4 a5

Leaf 1

Leaf 2

Leaf 3

S0 (group key)

S1S2

S3 H0,3(S3) = S0

1.47

Q: Related Work

Logical Key Hierarchy Key graph

One-way Function Tree The key of a node is a function of the keys of its left

and right children

Centralized Logical Hierarchical Schemes

1.48

Q: Related Work

Cliques A linear chain

Tree-based Group Diffie-Hellman STR

Form a skewed tree

Decentralized Schemes

M1 M2 M3 M4

1.49

Q: Instantaneous Analysis

Instantaneous number of exponentiations at different pairs of join/leave probabilities for Batch and Queue-batch:

pJ=0.25pL=0.25

pJ=0.5pL=0.5

pJ=0.75pL=0.75

1.50

Q: Instantaneous Analysis

Instantaneous number of renewed nodes at different pairs of join/leave probabilities for Batch and Queue-batch:

pJ=0.25pL=0.25

pJ=0.5pL=0.5

pJ=0.75pL=0.75

1.51

Q: N-ary tree

Do we have to stick to binary tree? Can we have ternary tree, or N-ary tree?

Answer: Not necessary good for N-ary tree, though it reduces the t

ree height Use one-round tripartite Diffie-Hellman based on Weil pa

iring 512-bit Weil pairing ~ 3 x 1024-bit exponentiation