group key distribution xiuzhen cheng the george washington university
TRANSCRIPT
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
IntroductionSecure group communicationPay-per-view video streamingVideo On Demand (VOD)Secure teleconferencingOnline games
Secure Group Communication
Authorization
Secure Multicasting
Forward confidentiality (revocation)
Backward confidentiality
Secure Group Multicasting
u
u2
u1
Our Assumptions
Each node shares one or more Key Encryption Keys (KEK) with GC to encrypt TEK updates
All nodes share a Traffic Encryption Key (TEK) to encrypt communication data.
There is a Group Controller (GC)
When membership changes, TEK needs to be updated
Traffic Encryption Key
u A Group of Users
A Group of Users
ETEK(msg)
u sends a message encrypted with TEK
Key Encryption Key
u
Key Encryption Key
u
KEKs are used to
encrypt TEK updates
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
GC
u
u wants to join the group
Star-shaped: Join (Cont’d)
GC
u
GC sends encrypted TEK to other nodes
Star-shaped: Leave
GC
u
U tells GC that he’s leaving
Star-shaped: Leave (Cont’d)
GC
u
GC sends encrypted TEK to other nodes
Analysis of Star-shaped Scheme
Pros:Easy to implementProvides both forward and backward confid
entiality
Cons:Doesn't scale well ~ Θ(n) Oooooops!
Logical Key Hierarchy
Proposed by C.K.Wong, M.Gouda, and S.S.LamIt provides both forward and backward confidentialityIt scales well ~ Θ(logn)
LKH: Key Graphs
u-nodes are real usersk-nodes represent keysu knows k if there’s a path from u to k
LKH: Join
u9 is about to join the group
LKH: Leave
u9 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 messagesKey-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 RekeyingEncryption Cost Join: 1 + 2 + … + h-1 + h-1 Leave: (d-1)(1+2+…+h-1)
Rekey Messages Join: h Leave: (d-1)(h-1)
k9
u9
Join rekey messages Leave rekey messages
Key-Oriented RekeyingEncryption Cost Join: 2(h-1) Leave: d(h-1)
Rekey Messages Join: 2(h-1) Leave: (d-1)(h-1)
k9
u9
Join rekey messages Leave rekey messages
Group-Oriented Rekeying
k9
u9
Two rekey messages for join:
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 top-down fashion
Complexity depends on the tree height, h=Θ(logn)
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
LKH+: JoinWhen u9 joins, u1 ~ u8 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 tree-based re-keying scheme
It greatly reduces GC’s storage requirement
Flat Key Table
TEK
ID Bit #0 KEK 0.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
GC maintains the following table
Flat Key Management
TEK
ID Bit #0 KEK 0.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
Node 0110 knows highlighted KEKs
CFKM: JoinNode #1101 is about to join the group
CFKM: JoinGC first sends it the new TEK and hig
hlighted KEKs (be updated first)TEK
ID Bit #0 KEK 0.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: JoinGC then encrypts new TEK with the complementary K
EKs (the highlighted ones)
TEK
ID Bit #0 KEK 0.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 re-keying message and get the updated TEK
CFKM: LeaveNode 1010 is about to leave
TEK
ID Bit #0 KEK 0.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: LeaveGC sends everybody a new TEK encrypted
with complementary KEKs
TEK
ID Bit #0 KEK 0.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 ConsPros: 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
CFKM: Multiple LeavesNode 1001 and 0110 are leaving…
TEK
ID Bit #0 KEK 0.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 TreesProposed 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
Structure of OFT
f
kleftkright
unblinded key
g g
f(g(kleft),g(kright))G is one-way
Blinded & Unblinded KeysUnblinded 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)
Node u knows the blinded keys of all green nodesu
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 keysu
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
Why OFT is better?
If u wants to leave, then only the green nodes need to be updated
The blue nodes can always compute the blinded key locally
u
ConclusionStar-shaped: most naïve approach, no scalabilityLKH: the basic of everything, good performance and functionalityLKH+: a slight improvement of LKHCFKM: reducing GC’s storage needOFT: best of all algorithms so far
In-Class Exercise
Design a protocol that can automatically update the group key as time evolves. 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
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