1 / 52

Group Key Distribution

Group Key Distribution. Xiuzhen Cheng The George Washington University. 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.

terris
Download Presentation

Group Key Distribution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related