Distributed and Collaborative Key Agreement Protocols with Authentication and Implementation for Dyn

1
Distributed and Collaborative Key Agreement
Protocols with Authentication and Implementation
for Dynamic Peer Groups

• Pak-Ching LEE
• M.Phil. Oral Defense
• June 2003

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, SGCL, 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)
0
1
3
7

• A binary key tree is formed. Each node v
  represents a secret (private) key Kv and a
  blinded (public) key BKv.
• BKv aKv mod p, where a 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.

7
TGDH Node Relationships
The secret key of a non-leaf node v can be
generated by
v
Kv (BK2v2)K2v1 (aK2v2)K2v1 mod p
BK2v2

• Kv (BK2v1)K2v2 (aK2v1)K2v2 mod p

2v1
2v2
Kv aK2v1K2v2 mod p
BK2v1
The secret key of a leaf node is randomly
selected by the corresponding member.
8
TGDH Group Key Generation
0
1
2
3
4
7
8

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

• K7, BK8 ? K3

• K3, BK4 ? K1

• K1, BK2 ? K0 (Group Key)

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.

Join
Leave
Join
Join
Leave

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

10
TGDH Single Leave Case
0
0
M5 leaves
2
2
5
5
12
12
11
M4
M5

• 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.

11
TGDH Single Join Case
0
0
M8 joins
2
2
5
5
M4
12
M8

• 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.

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
Rebuild Algorithm
0
M2, M5, M7 leave M8 joins
2
1
3

• 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.

• 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
Batch Example 1 L gt J gt 0
0
M2, M5, M7 leave M8 joins
2
1
3
6
5
6
M8(S)
8
11
24

• 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.

16
Batch Example 2 J gt L gt 0
0
M8, M9, M10 join M2, M7 leave
2
1
3
6
8

• 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.

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 joining member to a subtree T.
• Queue-merge At the beginning of the next
  rekeying interval, add the subtree T to the
  existing key tree, and prune all nodes of the
  leaving members.

18
Queue-batch Example of Queue-merge
0
0
M8, M9, M10 join M2, M7 leave
2
1
2
1
4
6
5
3
3
6
M3
M7
8
7
8
11
12
M6
M1
M2
23
24
M4
M5

• T is attached to node 6.
• M10, the sponsor, will broadcast BK6.
• M1 rekeys K1. M6 rekeys K2.
• M1 broadcasts BK1. M6 broadcasts BK2.

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

pJ0.25
pJ0.5
pJ0.75
23
Evaluation 2 Simulation Experiments

• Average number of renewed nodes at different
  fixed join probabilities

pJ0.25
pJ0.5
pJ0.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 doesnt 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, armi mod
  p), which remain valid from the time Mi joins
  until it leaves.
• Long-term private and public keys (xmi, axmi mod
  p), which remain permanent and are certified by a
  trusted party.
• Mi generates an authenticated short-term blinded
  key using Mjs long-term public key
• (axmj)rmi mod p (armi)xmj mod p
• Physical meaning
• L.S. generator a is authenticated, i.e., a
  becomes axmj
• R.S. the short-term blinded key armi 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.

M1
M2
(axm2)rm1
Retrieves ar2. Gets K as (arm2)rm1 (axm2)rm1
(axm1)rm2
Retrieves ar1. Gets K as (arm1)rm2 (axm2)rm1
(axm1)rm2
(axm1)rm2

• The authenticated short-term secret key is
• K arm1rm2 rm1xm2 rm2xm1 (mod p)

28
A-TGDH Multi-Party Case

• Idea Encrypt the blinded key of node v with
  long-term private key of Mi aKvxmi 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 childs descendants
• Authenticated blinded keys of right child by the
  long-term components of left childs descendants

29
A-TGDH Multi-Party Case

• Secret key at leaf nodes rmi mod p
• Authorized secret key of K1 is
• K1 arm1rm2 rm1xm2 rm2xm1 mod p
• Authorized group key K0 is
• K0 aK1K2 K1(xm3xm4) K2(xm1xm2) mod p
• Double-protection on the group key (with rmi and
  xmi)

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

32
SGCL Overview
Leader responsible for notifying others to
start a rekeying operation
REKEY
REKEY
REKEY
REKEY
REKEY
REKEY
REKEY
REKEY
The one which stays the longest
33
SGCL Overview
Blinded key
Leader
Blinded key
Blinded key
Blinded key
Blinded key
Blinded key
Blinded key
Blinded key
Blinded key
Blinded key
Sponsors responsible for broadcasting
new blinded keys
Blinded key
34
SGCL Architecture
Maintain reliable and ordered communication
Spread daemon
Packet engine
Certkey engine
SGCL API
35
SGCL API Functions
SGCL session object
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.5GHzs
• Inter-connected in a single LAN

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.

38
SGCL Applications
Chatter
39
Conclusion

• Three interval-based distributed rekeying
  algorithms Rebuild, Batch and Queue-batch
• Performance evaluation mathematical models and
  simulation experiments
• Authentication
• Implementation of SGCL

40
Future Directions
LAN B
LAN D
LAN A
Internet
LAN C
41
Future Directions

• A hybrid key tree with both physical and logical
  properties

LAN B
LAN D
LAN A
Internet
LAN C
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

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 roots 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.

Mr(s)
44
SGCL Leader Components
Spread daemon
Packet engine
Certkey engine
45
Q Related Work
Centralized Physical Hierarchical Schemes

• Intra Domain Group Key Management Protocol
• Domain Key Distributor Area Key Distributor
• Iolus
• Rekeying in subgroup level
• Subgroup manager re-encrypt data sessions

46
Q Related Work
Centralized Physical Hierarchical Schemes

• Kronos
• Periodic rekeying
• Reversible Parametric Sequences (RPS)
• Router tree
• Group key encryption along the tree path

Leaf 1
a3
a2
S0 (group key)
a4
a5
Leaf 2
a1
S1
S3
S2
a6
a7
Leaf 3
H0,3(S3) S0
47
Q Related Work
Centralized Logical Hierarchical Schemes

• 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

48
Q Related Work
Decentralized Schemes

• Cliques
• A linear chain
• Tree-based Group Diffie-Hellman
• STR
• Form a skewed tree

49
Q Instantaneous Analysis

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

pJ0.25 pL0.25
pJ0.5 pL0.5
pJ0.75 pL0.75
50
Q Instantaneous Analysis

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

pJ0.25 pL0.25
pJ0.5 pL0.5
pJ0.75 pL0.75
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 tree height
• Use one-round tripartite Diffie-Hellman based on
  Weil pairing
• 512-bit Weil pairing 3 x 1024-bit
  exponentiation