Patrick P. C. Lee

1. Distributed and Collaborative Key Agreement Protocols with Authentication and Implementation for Dynamic Peer Groups 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 managementscheme 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 K0 = Group Key 1 2 3 4 5 6 M3 M6 7 8 11 12 M1 M2 M4 M5 0 • 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. 1 3 7

7. TGDH: Node Relationships Kv = (BK2v+1)K2v+2 = (αK2v+1)K2v+2 mod p The secret key of a non-leaf node v can be generated by: v Kv = (BK2v+2)K2v+1 = (αK2v+2)K2v+1 mod p BK2v+2 2v+1 2v+2 Kv = αK2v+1K2v+2 mod p BK2v+1 The secret key of a leaf node is randomly selected by the corresponding member.

8. TGDH: Group Key Generation 0 1 2 3 4 5 6 M3 M6 7 8 11 12 M1 M2 M4 M5 0 • E.g., M1 generates the group key via: 1 2 4 3 8 7 • K7, BK8 K3 • K3, BK4 K1 • K1, BK2 K0 (Group Key)

9. TGDH: Membership Events rekey rekey rekey rekey rekey time • 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 1 3 4 5 6 M3 M4(S) 7 8 13 14 M1 M2 M6 M7 0 0 • 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. M5 leaves 2 2 5 5 12 12 11 M4 M5

11. TGDH: Single Join Case 1 3 4 6 M3 11 7 8 13 14 M4(S) M1 M2 M6 M7 0 0 M8 joins • 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. 2 2 5 5 M4 12 M8

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 0 1 1 2 2 3 3 4 4 5 5 6 6 M4(S) M3 M6(S) M8(S) M7 7 7 8 8 11 12 M1(s) M1 M3(S) M2 M6 23 24 M4 M5 0 • 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. M2, M5, M7 leave M8 joins 1 2 3 • 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 > J > 0 0 1 2 3 4 5 6 M3 M7 7 8 11 12 3 11 M1 M2 M6 23 24 M1(S) M4(S) M4 M5 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. M2, M5, M7 leave M8 joins 1 2 3 5 6 6 M8(S) 8 11 24

16. Batch – Example 2: J > L > 0 0 1 2 3 4 5 6 6 M3 M7 13 14 7 8 11 12 8 M8(S) M1 M2 M6 M9(S) 23 24 M10(S) T2’ T1’ M4 M5 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. M8, M9, M10 join M2, M7 leave 1 2 3 6 8

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 6 13 14 3 M10(S) 27 28 M1(S) M8 M9 T’ 0 0 • T’ is attached to node 6. • M10, the sponsor, will broadcast BK6. • M1 rekeys K1. M6 rekeys K2. • M1 broadcasts BK1. M6 broadcasts BK2. M8, M9, M10 join M2, M7 leave 1 1 2 2 3 3 4 5 6 6 M3 M7 8 7 8 11 12 M6 M1 M2 23 24 M4 M5

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)rmimod p = (αrmi)xmjmod p • Physical meaning: • L.S.: generator α is authenticated, i.e., α becomes αxmj • R.S.: the short-term blinded key αrmiis 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 (αxm2)rm1 Retrieves αr2. Gets K as: (αrm2)rm1 (αxm2)rm1 (αxm1)rm2 Retrieves αr1. Gets K as: (αrm1)rm2 (αxm2)rm1 (αxm1)rm2 (αxm1)rm2 • The authenticated short-term secret key is: K = αrm1rm2 +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: α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 0 1 2 3 4 5 6 M1 M2 M3 M4 • 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)

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 REKEY REKEY REKEY REKEY REKEY REKEY REKEY REKEY The one which stays the longest

33. SEAL: 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. SEAL: Architecture Receive thread Process thread verify verify sign sign Packet queue Message queue Leader engine Member engine Keytree engine Sesskey engine Maintain reliable and ordered communication Spread daemon Packet engine Certkey engine SEAL API

35. SEAL: Leader and Sponsors Ml(s) • 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. Mr(s)

36. SEAL: Leader Components Rekey poll thread Rekey send thread sign sign Rekey queue Leader engine Member engine Keytree engine Sesskey engine Spread daemon Packet engine Certkey engine

37. SEAL: API Functions SEAL_init() SEAL_set_passwd() SEAL_send() SEAL_recv() SEAL_read_membership() SEAL_send() SEAL_recv() SEAL_read_membership() SEAL_leave() SEAL_leave() SEAL_join() SEAL_destroy() SEAL session object

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

43. Future Directions • A hybrid key tree with both physical and logical properties: LAN B LAN D LAN A Internet LAN C

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