Distributed security – Dynamic Group Key Management by Jaman Bhola 4/17/2019

Introduction Example #1 Conclusion 4/17/2019

Introduction It is important to have peer to peer connections in today’s world – where file sharing, video conferencing, etc. are used more extensively. But we need good security between groups. We need to manage group key – enforce security when joining and/or leaving a group (includes single or group join as well as single or group split) (Disconnection can occur) 4/17/2019

The Diffie-Hellman key generation used as the basis to generate secure keys for group members. 4/17/2019

What is the Diffie-Hellman key generation method What is the Diffie-Hellman key generation method? The protocol has two system parameters p and g. They are both public and may be used by all the users in a system. Parameter p is a prime number and parameter g (usually called a generator) is an integer less than p, with the following property: for every number n between 1 and p-1 inclusive, there is a power k of g such that n = gk mod p. 4/17/2019

They proceed as follows: If there are two users A and B who wants to share a secret key using the Diffie-Hellman protocol: They proceed as follows: First, A generates a random private value a and B generates a random private value b. 4/17/2019

Both a and b are drawn from the set of integers {1, ..., p-2}. Then they derive their public values using parameters p and g and their private values. A's public value is ga mod p and B's public value is gb mod p. They then exchange their public values. Finally, A computes gab = (gb)a mod p, and B computes gba = (ga)b mod p. 4/17/2019

Since gab = gba = k, A and B now have a shared secret key k. This secret key can be broken if a third party, C, intercepts by sending A the secret key of C and B the secret key of C, so now C can listen in to the exchange of messages between A and B. 4/17/2019

In many cases where the Diffie-Hellman protocol is used, some modification is attached to prevent the third party interception. One approach relies on a single, centralized entity to generate keys and distribute them to the group. This entity maintain a long-term shared key with each group member to ensure two-party communication. 4/17/2019

Another method is dynamic selecting a group member who is charged with generating and distributing keys to other group members. Similar to the first. Another method is the contributory key management where each group member is asked to contribute equally to the generation of a common group key. 4/17/2019

Example # 1 – Contributory key Agreement This example uses a key-tree to implement the key – the authors used a binary tree. That is each node can only have a maximum of two children. The following notations are used to compute the tree: N - # of protocol parties (group members) Mi – ith group member i ε {1, …, N} h – height of tree 4/17/2019

<l,v> - vth node at level l in tree Ti – Mi’s view of the key tree Ti – Mi’s modified tree after membership operation p, q – prime integers α – exponentiation base Each node is labeled <l,v> where l is the level and 0<= v<= 2l - 1 4/17/2019

Each node is associated with a key K<l,v> and a blinded key BK<l,v> = f(K<l,v>) where the function f() is a modular exponentiation in prime order groups i.e. f(K) = αk mod p (analogous with Diffie-Hellman). The following is a key-tree. 4/17/2019

Key-tree M3 M4 M6 M5 M1 M2 N=6 l= 0 l= 1 h=3 l= 2 l= 3 <0,0> <1,1> <1,0> h=3 l= 2 <2,3> <2,0> <2,1> <2,2> M3 M4 <3,7> l= 3 <3,6> <3,1> <3,0> M6 M5 M1 M2 N=6 4/17/2019

Explanation of Tree A member Mi at node <l,v> knows every key along the path from <l,v> to <o,o> called the key path. In the tree, if M2 owns T2, then M2 knows every key at {K<3,1>, K<2,0>, K<1,0>, K<0,0>} in all KEY2 = {<3,1>, <2,0>, <1,0>, <0,0>} It also knows every blinded key on T2 – BK2 = {BK<0,0>, BK<1,0>, … , BK<3,7>} So to compute a key <l,v>, all that is needed is to know the key of one of the two child nodes and the blinded key of the other child node. 4/17/2019

K<0,0> is the root node and consist of the group secret shared by all nodes. The group secret is computed from setting Kgroup = h(K<0,0>) where h is a cryptographically strong hash function In the above example, M2 can calculate K<2,0>, K<1,0> and K<0,0> using BK<3,0>, BK<2,1>, BK<1,1> and K<3,1>. The final group key K<0,0> is: K<0,0> = α(α r3(α r1r2)) (α r4(α r5r6)) 4/17/2019

Group Communication and Group Key management A reliable group communication platform is required for communication in the modern collaborative and distributed environment. Which leads to effective group key management to establish reliable security. Two commonly used strong group communication semantics are: Extended Virtual Synchrony (EVS) and View Synchrony(VS) Both ensure that: 4/17/2019

2: The sender’s requested message order is preserved. 1: Group members see the same set of messages between two sequential group membership events and 2: The sender’s requested message order is preserved. Both of these ensure strong security using key agreement protocol as demonstrated in the Key-tree diagram and enforcing proper cryptographic properties for secrecy. But before we look at the secrecy, we need to be familiar with the different group membership events. 4/17/2019

Membership events Group partition can happen for several reasons 2 of which are: 1: Network failure – some network event causes disconnectivity 2. Explicit partition – happens when the application decides to split into groups. 4/17/2019

Group merge can be voluntary or involuntary: 1: Network fault heals – so subgroups merge together. 2: Explicit merge – application decides to merge multiple existing groups. 4/17/2019

Cryptographic Properties Four important security properties: 1: Group Key Secrecy – the most basic property – to make sure that an outsider cannot feasibly discover any group key 2: Forward Secrecy – make sure that if an outsider knows a continuous subset of old group key, they cannot find subsequent keys. 4/17/2019

3: Backward Secrecy – An outsider who knows a contiguous subset of group keys cannot discover previous group keys 4: Key Independence – the strongest property – if an outsider knows a proper subset of group keys (L subset of K) then the outsider cannot discover L ε (K – L). 4/17/2019

The tree-based group Diffie-Hellman (TGDH) Protocols The suite of protocols include join, leave, merge and partition. No matter which of the above is carried out: 1: Each group member contributes its equal share to the group key which is computed as a function of alkl shares of the current group members. 2: This share is secret to each group member and is never revealed. 4/17/2019

5: All protocol messages are signed by the sender. 3: As the group grows, new members’ shares are factored into the group key but old members’ shares remain the same 4: As the group shrinks, departing members shares are removed from the new key and at least one remaining member changes its share. 5: All protocol messages are signed by the sender. 4/17/2019

Join Protocol A new member wants to join a group He sends a request to join. The current group member has to decide where to insert the new member – generally at the shallowest rightmost node, where the join does not increase the height of the tree. If the tree is well balanced, at the root. The sponsor node is the rightmost leaf of the sub-tree rooted at the insertion node. 4/17/2019

The sponsor now creates a new intermediate node and new member node, and promotes the new intermediate node as the parent of both the insertion node and the new member node. After updating the tree, the sponsor node computes the new group key, (it already knows all blinded keys), and broadcasts the new tree which contains all blinded nodes. All of the other members update their trees accordingly. Example: 4/17/2019

Join Example M3 M2 M1 M4 M1 M2 M3 New Mem. <0,0> <0,0> New interm. Node <1,0> <1,1> <1,0> <1,1> M3 <2,1> <2,0> <2,3> <2,0> <2,1> <2,2> M2 M1 M4 M1 M2 M3 New Mem. 4/17/2019

Leave Protocol Assume that there are n members and Md is leaving The sponsor here is the rightmost leaf node of the sub-tree rooted at the leaving member’s sibling node Every member updates its key tree by deleting the leaf node corresponding to Md The former sibling of Md is promoted to replace Md‘s parent node 4/17/2019

All members can now recompute the new group key. The sponsor picks a new secret share, computes all keys on its path up to the root and broadcast the new set of Blinded keys to the group. All members can now recompute the new group key. 4/17/2019

Leave Example M1 M2 M3 M4 M1 M2 M5 M5 M4 Deleted Nodes Leaving Group <0,0> <0,0> Deleted Nodes <1,0> <1,1> <1,0> <1,1> <2,0> <2,1> <2,2> <2,0> <2,1> <2,2> <2,3> <2,3> M1 M2 M3 M4 M1 M2 M5 <3,7> <3,6> M5 M4 Leaving Group 4/17/2019

The Partition Protocol and the Merge Protocol are similar to the Leave and Join respectively. Even though these protocols seems to be different, when implemented, they pretty much look the same, I.e. both partition and merge result in a new key tree with a number of blinded missing keys. This similarity allows a single unified protocol with the following pseudocode: 4/17/2019

Pseudocode receive msg (msg type = membership event) construct new tree while there are missing blinded keys if(I can compute any missing keys) compute missing blinded keys broadcast new blinded keys endif receive msg(msg type = broadcast) update current tree Endwhile 4/17/2019

Conclusion Because we are dealing with binary tree, building of new key will take at most O(log n) time for any one of the merge or leave protocol. 4/17/2019

Bibliography Kim, Yongdae., Perrig, Adrian., and Tsudik, Gene.:”Simple and Fault-Tolerant Key Agreement for Dynamic Collaborative Groups”, Conference on Computer and Communications Security Proceedings of the 7th ACM conference on Computer and communications security Athens, Greece Pages: 235 – 244, 2000. http://portal.acm.org/citation.cfm?id=352638&dl=ACM&coll=portal&CFID=11111111&CFTOKEN=2222222 4/17/2019

Amir, Yair. , Yongdae, Kim. , Nita-Rotaru, Cristina. , Schultz, John Amir, Yair., Yongdae, Kim., Nita-Rotaru, Cristina., Schultz, John., Stanton, Jonathan., and Tsudik, Gene.:”Exploring Robustness in Group Key Agreement” Published in the Proceedings of the 21st IEEE International Conference on Distributed Computing Systems, Phoenix, Arizona, April 16-19, 2001, pp 399-408. http://www.cerias.purdue.edu/homes/crisn/publications.html 4/17/2019