Group Key Distribution Xiuzhen Cheng The George Washington

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 Versa. Key Framework D. Mc. Grew and A. T. Sherman: Key Establishment in Large Dynamic Groups Using One-way Function Trees

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

Secure Group Communication Authorization Secure Multicasting Forward confidentiality (revocation) Backward confidentiality

Secure Group Multicasting u 2 u 1 u

Our Assumptions 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 Each node shares one or more Key Encryption Keys (KEK) with GC to encrypt TEK updates

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

Key Encryption Key u

Key Encryption Key KEKs are used to encrypt TEK updates u

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

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

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

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

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

Analysis of Starshaped Scheme Pros: Easy to implement l Provides both forward and backward confidentiality l Cons: l Doesn't scale well ~ Θ(n) Oooooops!

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)

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

LKH: Join u 9 is about to join the group

LKH: Leave u 9 is about to leave the group

User, Key, or Group? 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 Group-oriented is putting all re-keying messages together to generate a big, fat message ~ only one gigantic message

User-Oriented Rekeying k 9 u 9 Encryption Cost l l Join: 1 + 2 + … + h-1 Leave: (d-1)(1+2+…+h-1) Rekey Messages Join: h l Leave: (d-1)(h-1) Leave rekey messages l Join rekey messages

Key-Oriented Rekeying Encryption Cost l l k 9 u 9 Rekey Messages l l Join rekey messages Join: 2(h-1) Leave: d(h-1) Join: 2(h-1) Leave: (d-1)(h-1) Leave rekey messages

Group-Oriented Rekeying Two rekey messages for join: k 9 u 9 Encryption cost for join: 2(h-1) Leave Operation: Encryption cost: d(h-1) Rekey messages: 1

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

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

LKH+: Join When u 9 joins, u 1 ~ u 8 feed the KEK into a one-way hash function to do the update

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

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

Flat Key Table GC maintains the following table TEK ID Bit #0 KEK 0. 1 ID Bit #1 KEK 1. 0 KEK 1. 1 ID Bit #2 KEK 2. 0 KEK 2. 1 ID Bit #3 KEK 3. 0 KEK 3. 1 Bit’s Value=0 Bit’s Value=1

Flat Key Management Node 0110 knows highlighted KEKs TEK ID Bit #0 KEK 0. 1 ID Bit #1 KEK 1. 0 KEK 1. 1 ID Bit #2 KEK 2. 0 KEK 2. 1 ID Bit #3 KEK 3. 0 KEK 3. 1 Bit’s Value=0 Bit’s Value=1

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

CFKM: Join GC first sends it the new TEK and highlighted KEKs (be updated first) TEK ID Bit #0 KEK 0. 1 ID Bit #1 KEK 1. 0 KEK 1. 1 ID Bit #2 KEK 2. 0 KEK 2. 1 ID Bit #3 KEK 3. 0 KEK 3. 1 Bit’s Value=0 Bit’s Value=1

CFKM: Join GC then encrypts new TEK with the complementary KEKs (the highlighted ones) TEK ID Bit #0 KEK 0. 1 ID Bit #1 KEK 1. 0 KEK 1. 1 ID Bit #2 KEK 2. 0 KEK 2. 1 ID Bit #3 KEK 3. 0 KEK 3. 1 Bit’s Value=0 Bit’s Value=1

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

CFKM: Leave Node 1010 is about to leave TEK ID Bit #0 KEK 0. 1 ID Bit #1 KEK 1. 0 KEK 1. 1 ID Bit #2 KEK 2. 0 KEK 2. 1 ID Bit #3 KEK 3. 0 KEK 3. 1 Bit’s Value=0 Bit’s Value=1

CFKM: Leave GC sends everybody a new TEK encrypted with complementary KEKs TEK ID Bit #0 KEK 0. 1 ID Bit #1 KEK 1. 0 KEK 1. 1 ID Bit #2 KEK 2. 0 KEK 2. 1 ID Bit #3 KEK 3. 0 KEK 3. 1 Bit’s Value=0 Bit’s Value=1

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

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

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

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

CFKM: Multiple Leaves Node 1001 and 0110 are leaving… TEK ID Bit #0 KEK 0. 1 ID Bit #1 KEK 1. 0 KEK 1. 1 ID Bit #2 KEK 2. 0 KEK 2. 1 ID Bit #3 KEK 3. 0 KEK 3. 1 Bit’s Value=0 Bit’s Value=1

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

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

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

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)

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

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

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

Analysis of OFT has the same log-bound as 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

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

Conclusion Star-shaped: most naïve approach, no scalability LKH: the basic of everything, good performance and functionality

In-Class Exercise Design a protocol that can automatically update the group key as time evolves. l l Must guarantee backward and forward confidentiality Each group member joins/leaves at some specific instance of time: join at the beginning of a time slot and leave at the end of a time slot l l Time is discretised into slots with fixed length The time schedule (join/leave) of each node is known ahead of time Assume a GC is available to assist the job Hint: use two one-way hash chains