Group Key Distribution

1
Group Key Distribution

• Chih-Hao Huang
• huang_at_cs.umn.edu

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

• 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 a Key Encryption Key with GC to
  encrypt TEK updates

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 (Contd)
GC sends encrypted TEK to other nodes
u
GC
13
Star-shaped Leave
U tells GC that hes leaving
GC
u
14
Star-shaped Leave (Contd)
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 T(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 T(logn)

17
LKH Key Graphs

• u-nodes are real users
• k-nodes represent keys
• u knows k if theres 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
Analysis of LKH

• Re-keying messages are sent in a top-down fashion
• Complexity depends on the tree height, T(logn)
• Some options may be used user-oriented,
  key-oriented, and group-oriented re-keying

21
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

22
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

23
LKH Join

• When u9 joins, u1 u8 feed the KEK into a
  one-way hash function to do the update

24
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

25
Centralized Flat Key Management

• Proposed by M.Waldvogel et al as well
• Another logical tree-based re-keying scheme
• It greatly reduces GCs storage requirement

26
Flat Key Table

• GC maintains the following table

TEK 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
Bits Value0 Bits Value1
27
Flat Key Management

• Node 0110 knows highlighted KEKs

TEK 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
Bits Value0 Bits Value1
28
CFKM Join

• Node 1101 is about to join the group

29
CFKM Join

• GC first sends it the new TEK and highlighted KEKs

TEK 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
Bits Value0 Bits Value1
30
CFKM Join

• GC then encrypts new TEK with the complementary
  KEKs (the highlighted ones)

TEK 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
Bits Value0 Bits Value1
31
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

32
CFKM Leave

• Node 1010 is about to leave

TEK 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
Bits Value0 Bits Value1
33
CFKM Leave

• GC sends everybody a new TEK encrypted with
  complementary KEKs

TEK 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
Bits Value0 Bits Value1
34
CFKM Leave (Contd)

• 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

35
CFKM Leave (Contd)

• 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 dont know the old value

36
CFKM Leave (Contd)

• 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

37
CFKM Pros and Cons

• Pros
• It greatly reduces GCs memory requirement only
  one table needed
• It maintains the same logarithmic bound as LKH,
  LKH its efficient

• Cons
• Removal of multiple nodes

38
CFKM Multiple Leaves

• Node 1001 and 0110 are leaving

TEK 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
Bits Value0 Bits Value1
39
One-way Function Trees

• Proposed by D.A.McGrew and A.T.Sherman
• Logical tree-based scheme as well
• Even its still of logarithmic bound, the
  coefficient is smaller than LKH

?
40
Structure of OFT
unblinded key
f
G is one-way
f(g(kleft),g(kright))
kright
kleft
g
g
41
Blinded Unblinded Keys

• Unblinded Key the value that hasnt 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 converse is not true

42
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)

43
OFT Algorithm (Contd)

• Node u knows the blinded keys of all green nodes

u
44
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, T(logn) nodes need to
  update the blinded keys, where n is the distance
  to the root

45
OFT Join/Leave (Contd)

• If u wants to join, all green nodes must update
  blinded keys

u
46
Analysis of OFT

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

47
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
48
Conclusion

• Star-shaped most naïve approach, no scalability
• LKH the basic of everything, good performance
  and functionality
• LKH a slight improvement of LKH
• CFKM reducing GCs storage need
• OFT best of all algorithms so far