Transcript Document 7266427

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
Introduction
Secure group communication
Pay-per-view video streaming
 Video On Demand (VOD)
 Secure teleconferencing
 Online games

Secure Group
Communication
Authorization
Secure Multicasting
Forward confidentiality (revocation)
Backward confidentiality
Secure Group
Multicasting
u2
u1
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
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
 Provides both forward and backward
confidentiality

Cons:

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
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 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
Encryption Cost


k9
u9
Join rekey messages
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
Key-Oriented Rekeying
Encryption Cost


k9
u9
Join rekey messages
Join: 2(h-1)
Leave: d(h-1)
Rekey Messages


Join: 2(h-1)
Leave: (d-1)(h-1)
Leave rekey messages
Group-Oriented
Rekeying
Two rekey messages for join:
k9
u9
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
VersaKey Framework”
They use a one-way
function to update TEK
when a ‘join’ happens
LKH+: Join
When 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 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.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.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.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.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.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.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
 It maintains the same logarithmic bound as
LKH, LKH+ ~ it’s efficient

Cons:

Removal of multiple nodes
CFKM: Multiple Leaves
Node 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 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
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
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
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.


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