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 P. C. Lee

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 algorithms: 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, SEAL, and

To suggest future research directions.

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.

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.

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.

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

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.

8

TGDH: Group Key Generation0

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

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

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)

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

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.

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.

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.

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

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’

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, atta

ch each joining member to a subtree T’. Queue-merge: At the beginning of the next rekeying in

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

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)

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.

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 computation/communication reduction when the group is very dynamic.

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/leave probabilities over 300 rekeying intervals.

22

Evaluation 2: Simulation Experiments

Average number of exponentiations at different fixed join probabilities:

pJ=0.25 pJ=0.5

pJ=0.75

23

Evaluation 2: Simulation Experiments

Average number of renewed nodes at different fixed join probabilities:

pJ=0.25 pJ=0.5

pJ=0.75

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.

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.

26

A-TGDH: Concepts Each member Mi holds two pairs of keys:

Short-term secret and blinded keys (rmi, αrmi mod p), which remain valid from the time Mi joins until it leaves.

Long-term private and public keys (xmi, αxmi mod p), which remain permanent 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.

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

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

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

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.

31

SEAL Implementation

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

SEAL facilitates developers to build secure group-oriented applications.

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

32

SEAL: Overview

Leader: responsible for notifying others to start

a rekeying operation

REKEYREKEYREKEYREKEYREKEYREKEYREKEY

REKEY

The one which stays the longest

33

SEAL: Overview

Leader

Blinded keyBlinded keyBlinded keyBlinded keyBlinded keyBlinded keyBlinded keyBlinded key

Sponsors: responsible forbroadcasting new

blinded keys Blinded key

Blinded key

Blinded key

34

SEAL: Architecture

Keytreeengine

Sesskeyengine

Memberengine

Leaderengine

Certkeyengine

Packetengine

Message queue

Packet queue

Spread daemonMaintain reliable

and ordered communication

SEALAPI

Receivethread

Processthread

verify verify

sign sign

35

SEAL: 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)

36

SEAL: Leader Components

Keytreeengine

Sesskeyengine

Memberengine

Leaderengine

Certkeyengine

Packetengine

Rekey queue

Spread daemon

Rekeypoll

thread

Rekeysend

threadsign sign

37

SEAL: API Functions

SEAL_init() SEAL_set_passwd()

SEAL_join()SEAL_send()SEAL_recv()

SEAL_read_membership()

SEAL_send()SEAL_recv()

SEAL_read_membership()SEAL_leave()SEAL_leave()

SEAL_destroy()

SEAL sessionobject

38

SEAL: 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

39

SEAL: Result Highlights

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

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

40

SEAL: Applications

Chatter

41

Conclusion

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

Performance evaluation: mathematical models and simulation experiments

Authentication

Implementation of SEAL

42

Internet

Future Directions

LAN B

LAN C

LAN DLAN A

43

Internet

Future Directions

A hybrid key tree with both physical and logical properties:

LAN B

LAN C

LAN DLAN A

44

Future Directions Robustness against attacks:

Erroneous key confirmation Forged packets/signatures Leader masquerade

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

Key tree updates: Interval-based Threshold-based