Group Key Distribution Chih-Hao Huang [email protected].
-
Upload
phillip-morris -
Category
Documents
-
view
217 -
download
2
Transcript of Group Key Distribution Chih-Hao Huang [email protected].
![Page 2: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/2.jpg)
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
![Page 3: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/3.jpg)
IntroductionSecure group communicationPay-per-view video streamingVideo On Demand (VOD)Secure teleconferencingOnline games
![Page 4: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/4.jpg)
Secure Group Communication
Authorization
Secure Multicasting
Forward confidentiality (revocation)
Backward confidentiality
![Page 5: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/5.jpg)
Secure Group Multicasting
u
u2
u1
![Page 6: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/6.jpg)
Our Assumptions
Each node shares a Key Encryption Key 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
![Page 7: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/7.jpg)
Traffic Encryption Key
u A Group of Users
A Group of Users
ETEK(msg)
u sends a message encrypted with TEK
![Page 8: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/8.jpg)
Key Encryption Key
u
![Page 9: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/9.jpg)
Key Encryption Key
u
KEKs are used to
encrypt TEK updates
![Page 10: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/10.jpg)
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
![Page 11: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/11.jpg)
Star-shaped Re-keying Scheme : Join
GC
u
u wants to join the group
![Page 12: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/12.jpg)
Star-shaped: Join (Cont’d)
GC
u
GC sends encrypted TEK to other nodes
![Page 13: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/13.jpg)
Star-shaped: Leave
GC
u
U tells GC that he’s leaving
![Page 14: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/14.jpg)
Star-shaped: Leave (Cont’d)
GC
u
GC sends encrypted TEK to other nodes
![Page 15: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/15.jpg)
Analysis of Star-shaped Scheme
Pros:Easy to implementProvides both forward and backward confid
entiality
Cons:Doesn't scale well ~ Θ(n) Oooooops!
![Page 16: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/16.jpg)
Logical Key Hierarchy
Proposed by C.K.Wong, M.Gouda, and S.S.LamIt provides both forward and backward confidentialityIt scales well ~ Θ(logn)
![Page 17: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/17.jpg)
LKH: Key Graphs
u-nodes are real usersk-nodes represent keysu knows k if there’s a path from u to k
![Page 18: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/18.jpg)
LKH: Joinu9 is about to join the group
![Page 19: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/19.jpg)
LKH: Leaveu9 is about to leave the group
![Page 20: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/20.jpg)
Analysis of LKH
Re-keying messages are sent in a top-down fashion
Complexity depends on the tree height, Θ(logn)
Some options may be used: user-oriented, key-oriented, and group-oriented re-keying
![Page 21: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/21.jpg)
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
![Page 22: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/22.jpg)
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
![Page 23: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/23.jpg)
LKH+: JoinWhen u9 joins, u1 ~ u8 feed the KEK into a
one-way hash function to do the update
![Page 24: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/24.jpg)
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
![Page 25: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/25.jpg)
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
![Page 26: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/26.jpg)
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
![Page 27: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/27.jpg)
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
![Page 28: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/28.jpg)
CFKM: JoinNode #1101 is about to join the group
![Page 29: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/29.jpg)
CFKM: JoinGC first sends it the new TEK and hig
hlighted KEKsTEK
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
![Page 30: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/30.jpg)
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
![Page 31: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/31.jpg)
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
![Page 32: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/32.jpg)
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
![Page 33: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/33.jpg)
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
![Page 34: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/34.jpg)
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
![Page 35: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/35.jpg)
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
![Page 36: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/36.jpg)
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
![Page 37: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/37.jpg)
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
![Page 38: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/38.jpg)
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
![Page 39: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/39.jpg)
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
![Page 40: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/40.jpg)
Structure of OFT
f
kleftkright
unblinded key
g g
f(g(kleft),g(kright))G is one-way
![Page 41: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/41.jpg)
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 converse is not true
![Page 42: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/42.jpg)
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)
![Page 43: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/43.jpg)
OFT Algorithm (Cont’d)
Node u knows the blinded keys of all green nodesu
![Page 44: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/44.jpg)
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
![Page 45: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/45.jpg)
OFT: Join/Leave (Cont’d)
If u wants to join, all green nodes must update blinded keysu
![Page 46: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/46.jpg)
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
![Page 47: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/47.jpg)
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
![Page 48: Group Key Distribution Chih-Hao Huang huang@cs.umn.edu.](https://reader035.fdocuments.in/reader035/viewer/2022062421/56649d765503460f94a5774f/html5/thumbnails/48.jpg)
ConclusionStar-shaped: most naïve approach, no scalability
LKH: the basic of everything, good performance and functionality
LKH+: a slight improvement of LKH
CFKM: reducing GC’s storage need
OFT: best of all algorithms so far