Group Key Distribution

1. Group Key Distribution Xiuzhen Cheng The George Washington University

2. Paper List • C.K.Wong et al: Secure Group Communications Using Key Graphs • M.Waldvogel et al: the VersaKey Framework • D.McGrew and A.T.Sherman: Key Establishment in Large Dynamic Groups Using One-way Function Trees

3. Introduction • Secure group communication • Pay-per-view video streaming • Video On Demand (VOD) • Secure teleconferencing • Online games

4. Secure Group Communication • Authorization • Secure Multicasting • Forward confidentiality (revocation) • Backward confidentiality

5. Secure Group Multicasting u2 u1 u

6. Our Assumptions • Each node shares one or more Key Encryption Keys (KEK) with GC to encrypt TEK updates • There is a Group Controller (GC) • All nodes share a Traffic Encryption Key (TEK) to encrypt communication data. • When membership changes, TEK needs to be updated

7. Traffic Encryption Key A Group of Users ETEK(msg) u u sends a message encrypted with TEK

8. Key Encryption Key u

9. Key Encryption Key KEKs are used to encrypt TEK updates u

10. An Easy Re-keying Scheme : Star-shaped • Each user shares a secret KEK with GC • When a user joins or leaves, GC sends each node a re-keying message encrypted with its own KEK

11. Star-shaped Re-keying Scheme : Join u u wants to join the group GC

12. Star-shaped: Join (Cont’d) GC sends encrypted TEK to other nodes u GC

13. Star-shaped: Leave U tells GC that he’s leaving GC u

14. Star-shaped: Leave (Cont’d) GC sends encrypted TEK to other nodes GC u

15. Analysis of Star-shaped Scheme • Pros: • Easy to implement • Provides both forward and backward confidentiality • Cons: • Doesn't scale well ~ Θ(n) Oooooops!

16. Logical Key Hierarchy • Proposed by C.K.Wong, M.Gouda, and S.S.Lam • It provides both forward and backward confidentiality • It scales well ~ Θ(logn)

17. LKH: Key Graphs • u-nodes are real users • k-nodes represent keys • u knows k if there’s a path from u to k

18. LKH: Join u9 is about to join the group

19. LKH: Leave u9 is about to leave the group

20. User-oriented re-keying is nothing more than grouping re-keying messages by users ~ less but bigger messages Key-oriented re-keying is just grouping them by keys ~ more but smaller messages User, Key, or Group? • Group-oriented is putting all re-keying messages together to generate a big, fat message ~ only one gigantic message

21. k9 u9 User-Oriented Rekeying • Encryption Cost • Join: 1 + 2 + … + h-1 + h-1 • Leave: (d-1)(1+2+…+h-1) • Rekey Messages • Join: h • Leave: (d-1)(h-1) Leave rekey messages Join rekey messages

22. k9 u9 Key-Oriented Rekeying • Encryption Cost • Join: 2(h-1) • Leave: d(h-1) • Rekey Messages • Join: 2(h-1) • Leave: (d-1)(h-1) Leave rekey messages Join rekey messages

23. k9 u9 Group-Oriented Rekeying Two rekey messages for join: Encryption cost for join: 2(h-1) Leave Operation: Encryption cost: d(h-1) Rekey messages: 1

24. Analysis of LKH • Re-keying messages are sent in a top-down fashion • Complexity depends on the tree height, h=Θ(logn)

25. An Improvement: LKH+ • Proposed by M.Waldvogel et al in “The VersaKey Framework” • They use a one-way function to update TEK when a ‘join’ happens

26. LKH+: Join When u9 joins, u1 ~ u8 feed the KEK into a one-way hash function to do the update

27. Analysis of LKH+ • GC doesn't need to send re-keying messages when a join happens • When a join happens, every member can compute the new TEK locally • The newly joined member cannot compute the old TEK ~ backward confidentiality

28. Centralized Flat Key Management • Proposed by M.Waldvogel et al as well • Another logical tree-based re-keying scheme • It greatly reduces GC’s storage requirement

29. Flat Key Table GC maintains the following table

30. Flat Key Management Node 0110 knows highlighted KEKs

31. CFKM: Join Node #1101 is about to join the group

32. CFKM: Join GC first sends it the new TEK and highlighted KEKs (be updated first)

33. CFKM: Join GC then encrypts new TEK with the complementary KEKs (the highlighted ones)

34. CFKM: Join • GC then broadcasts these message to everybody • Since other nodes differ from it in at least 1 position, they can decrypt the re-keying message and get the updated TEK

35. CFKM: Leave Node 1010 is about to leave

36. CFKM: Leave GC sends everybody a new TEK encrypted with complementary KEKs

37. CFKM: Leave (Cont’d) • Similarly, since other nodes differ from it in at least 1 position, they can decrypt the re-keying message and get the updated TEK • Now, all KEKs known by the leaving node become invalid and need to be updated

38. CFKM: Leave (Cont’d) • For each of the invalid KEKs, GC selects a new replacement encrypted with both the old KEK and the new TEK • For those who are not supposed to know the replacement KEKs, they cannot decrypt the message as they don’t know the old value

39. CFKM: Leave (Cont’d) • For each of the invalid KEKs, GC selects a new replacement encrypted with both the old KEK and the new TEK • The evicted node cannot decrypt the message either, as it doesn't know the new TEK

40. CFKM: Pros and Cons • Pros: • It greatly reduces GC’s memory requirement ~ only one table needed • It maintains the same logarithmic bound as LKH, LKH+ ~ it’s efficient • Cons: • Removal of multiple nodes

41. CFKM: Multiple Leaves • Node 1001 and 0110 are leaving…

42. One-way Function Trees • Proposed by D.A.McGrew and A.T.Sherman • Logical tree-based scheme as well • Even it’s still of logarithmic bound, the coefficient is smaller than LKH ?

43. Structure of OFT unblinded key f G is one-way f(g(kleft),g(kright)) kright kleft g g

44. Blinded & Unblinded Keys • Unblinded Key: the value that hasn’t been passed though g • Blinded Key: the value that has already been passed though g • If you know the unblinded key, you can compute the blinded key • The reverse is not true

45. OFT Algorithm • Each member knows the blinded keys which are siblings to its path to the root • Each member knows its unblinded key • Each member can then compute the key of the root, which is the TEK (root maintains only one key)

46. OFT Algorithm (Cont’d) Node u knows the blinded keys of all green nodes u

47. OFT: Join/Leave • If a blinded key changes, its new value must be communicated to all members who store it • For a join/leave operation, Θ(logn) nodes need to update the blinded keys, where n is the distance to the root

48. OFT: Join/Leave (Cont’d) If u wants to join, all green nodes must update blinded keys u

49. Analysis of OFT • OFT has the same log-bound as LKH • LKH’s leading coefficient is 2 (binary), since updates must be sent to both children along the path to the root • OFT’s leading coefficient is 1, since updates has only to be sent to the sibling along the path to the root

50. Why OFT is better? • If u wants to leave, then only the green nodes need to be updated • The blue nodes can always computethe blinded key locally u