group key distribution xiuzhen cheng the george washington university

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