Multicast Security
Cryptographic Protocols
InKwan Yu
Multicast Security Issues
Multicast
What is it?
Applications
An efficient way to communicate between 1-to-n or mto-n hosts
Audio/video streaming, conferencing, multi-player
gaming, stock quotes distribution, command and control
communication, and much more.
Features
Open access to receive data
Open membership
Open access to send data in a multicast group
Multicast Security Issues
Multicast Security Issues
Receiver Access Control
Group policy specification functions
Authentication & authorization /w public key
cryptography
Source Authentication
Digital signature, MAC
Multicast Security Issues
Multicast Security Issues (Cont)
Multicast Fingerprint
Watermarking is embedding copyright
information in the contents
Fingerprint is a watermarking for a specific user
Desirable features of fingerprint
non-removable, collusion resistance, asymmetric
fingerprinting, protection granularity, efficiency
Multicast Security Issues
Multicast Security Issues (Cont)
Multicast Fingerprint (Cont)
Methods
Intermediate routers can cooperate with the sender
to create a unique stream to each member
Sender may multicast the most of data and unicast
some of unique data to each member
Two different streams can uniquely arbitrate for a
different user
Multicast Security Issues
Multicast Security Issues (Cont)
Group Key Management
Shared group key to encrypt the multicast data
Rekey
Core functionality for the multicast security
Group Key Management Issues
Member identification and authentication between GCKS
(Group Controller/Key Server) and members
Access control to validate the join operation
Generation, distribution and installation of key materials.
Keys should be regularly changed and key generation
should be independent of past and future keys
Multicast Security Issues
Group Key Management Issues(Cont)
Forward secrecy to prevent a leaving group member to
access the group communication.
Backward secrecy to prevent a joining group member to
decipher previous messages before its join.
Storage requirements. The number of keys necessary to
operate the system
Size of messages. The message size needed to rekey.
Collusion. Members of the group can cooperate to
compromise the system security
Key independence, decentralized controller, local rekey,
number of rounds, number of messages
Multicast Security Issues
Issues & Solutions
multicast
All receive
data
Open group
Membership
Outside member
sends data
Open access to
distributed
content
No
individualization
of received data
Open access to
send data to
group
Denial of service
Eavesdropping
No theft
deterrence
Denial of service
Masquerading
Multicast
receiver access
control
Group key
management
Multicast
fingerprinting
Multicast source
access control
Multicast source
authentication
Properties
Security issues
Security
vulnerabilities
Security
solutions
Multicast Security Architecture
Reference
RFC 3740
What’s in it
Overview and rationale of multicast
security architecture
Reference frameworks of secure multicast
protocols
Multicast Security Architecture
GSA (Group Security Association)
SA (Security Association)
Necessary shared information between two
parties for a secure comm.
Selectors (destination transport address)
Properties (algorithms, modes, key lifetimes,
key lengths)
Keys for authentication, encryption and signing
Multicast Security Architecture
GSA (Cont)
Def. of GSA
Aggregate of Sas
REG SA
Unicast SA that a group member uses to pull GSA
information from Group Controller/Key Server (GCKS)
REKEY SA
SA used for rekeying
DATA SA
Shared by among the group members
Superset of SAs
Includes Attributes of SA
Multicast Security Architecture
GSA (Cont)
GCKS
REG REKEY REG
REG
REG
REKEY
REKEY
Sender
Receiver
DATA
DATA
Multicast Security Architecture
Centralized Multicast Security Reference
Framework
Multicast
Security
Policies
Group
Key
Management
Policy
Sever
Group Controller/
Key Server
Receiver
Multicast
Data
Handling
Sender
Multicast Security Architecture
Distributed Multicast Security Reference
Framework
Multicast
Security
Policies
Group
Key
Management
Policy
Sever
Policy
Sever
Group Controller/
Key Server
Group Controller/
Key Server
Receiver
Multicast
Data
Handling
Sender
Receiver
Multicast Security Architecture
Hierarchically-organized Decentralized
Key Distribution
GCKS
Member
Sub GCKS
Sub GCKS
Member
Member
....
Member
....
Member
Sub GCKS
....
Member
Group Key Management
Protocol
Reference
RFC 2093 and RFC 2094
Features
Public key algorithm for authentication certificates
Pairwise key exchange
Member compromise can be solved only by creating a new
group
GTEK(Group Traffic Encryption Key) for data
GKEK(Group Key Encryption Key) for the group key
Group Key Management
Protocol
Group Key Generation
Create Group Keys 1 (rand #)
C
O
N
T
R
O
L
L
E
R
Create Group Keys 2 (# for GTEK, GKEK)
Negotiate Group Keys 1 (GTEK, GKEK,
permission,group id, group member,
rekey interval,CRL
(compromise recovery list)
Negotiate Group Keys 2
M
E
M
B
E
R
Group Key Management
Protocol
Group Key Distribution
Create Session Keys 1 (rand #)
C
O
N
T
R
O
L
L
E
R
Create Session Keys 2 (# for SKEK)
Negotiate Session Keys 1
(SKEK, permission, group id, members)
Negotiate Session Keys 2
Download Group Keys(GTEK, GKEK,
group id, group permission, rekey interval)
Key Download Acknowledge
M
E
M
B
E
R
Group Key Management
Protocol
Rekey
Create Group Keys 1
C
O
N
T
R
O
L
L
E
R
Create Group Keys 2
Negotiate Session Keys 1
Negotiate Session Keys 2
Rekey_Multicast
M
E
M
B
E
R
Group Key Management
Protocol
Join
Request Group Join
Create Session Keys 1
C
O
N
T
R
O
L
L
E
R
Create Session Keys 2
Negotiate Session Keys 1
Negotiate Session Keys 2
Download Group Keys
Key Download Acknowledge
M
E
M
B
E
R
Tree Based Multicast Group
Key Management
Reference
RFC 2627
Features
The secure removal of a compromised user
from the multicast group
Transmission efficiency
Storage efficiency
Net key is a root key used as DEK
Tree Based Multicast Group
Key Management
Initialization
Pair wise KEKs with each user by the public key
exchange protocol
Key for each node is generated
From the parents of leaf nodes up to the root, the
server transmits the key for each node encrypted
with the keys of each of the node’s children
Each leaf has all keys on the path to the root
Tree Based Multicast Group
Key Management
Member Deletion
Ex) When the user 11 is deleted
New key for F is encrypted with the user 12’s
KEK and sent
New key for K is encrypted with the new key
for F and sent. New key for K is encrypted with
the new key for E and sent for the users 9 and
10
New key for N is encrypted with keys of K and
L, etc. until a new root key(DEK) is distributed.
Tree Based Multicast Group
Key Management
Logical Key Distribution Architecture
net key
Key O
intermediate
keys
Key M
Key N
Key I
Key A
1
2
Key J
Key B
3
4
Key K
Key C
Key D
5
7
6
Key E
8
9
users
10
Key L
Key F
11
12
Key G
13
14
Key H
15
16
Centralized Flat Key
Distribution
Architecture
Each member has a fixed length id
Each bit of id is assigned to a different KEK.
Each member is assigned a set of unique
KEKs according to the id bit values
Centralized Flat Key
Distribution
Flat ID Assignment (e.g 0110)
TEK
KEK 0.0
KEK 0.1
KEK 1.0
KEK 1.1
Bit 2
KEK 2.0
KEK 2.1
Bit 3
KEK 3.0
KEK 3.1
Bit 0
Bit 1
Bit value 0
Bit value 1
Centralized Flat Key
Distribution
Join
Assign KEKs from the KEK space
Leave
KEKs related to the deleted member’s id bits are
assigned new KEKs. And new TEK is generated
New KEKs are encrypted with the new TEK and
the old KEK of that bit. KEKs related to bits not
used by the deleted member is used to encrypt
the new TEK
Centralized Flat Key
Distribution
KEK for Member 0110 Deletion
{KEK 0.0 new }TEK new | KEK 0.0 old {TEK new }KEK 0.1
{TEK new }KEK 1.0
{KEK 1.1new }TEK new | KEK 1.1old
{TEK new}KEK 2.0
{KEK 2.1new }TEK new | KEK 2.1old
{KEK 3.0 new }TEK new | KEK 3.0 old {TEK new }KEK 3.1
Scalable Multicast Key
Distribution
Reference
RFC 1949
CBT (Core Based Tree Multicast Routing)
RFC 2201
IP layer protocol
CBT protocol creates a hard state routing tree
among a multicast group. The multicast data
follow the fixed multicast tree structure
Tree branch is formed when there is at least one
member join from a subtree
In SMKD, the primary core of CBT establishes the
security parameters used in the multicast
Scalable Multicast Key
Distribution
Scalability
With enough information including keys
and ACL (group access control list), each
router can distribute the group key (DEK)
and KEK
This operation is dependent on the
structure of CBT tree
Scalable Multicast Key
Distribution
Multicast Key Distribution using CBT
router
router
router
router
router
router
router
router
router
Core
B
router
router
A
Host h
A, B, router are non-core routers
Scalable Multicast Key
Distribution
Example Protocol
groupaccesspackage {token _ sender ,{ ACL}Core ,
{{ groupkey, KEK , SAParam}Core }host ,
{groupkey, KEK , SAParam}Core }next hop }sender
groupkey is used for data encryption
h A : {tokenh }h , where tokenh {timestamph , randomnumerh , A}h
A B : {tokenA , {tokenh }h , JOIN_REQUE ST} A
B C : {tokenB , {tokenh }h , JOIN_REQUE ST} B
C B : {{tokenh }h , groupaccesspackage, JOIN_ACK}C ,
B A : {{tokenh }h , groupaccesspackage, JOIN_ACK}B
A h : {{tokenh }h , groupkey, KEK , SAParam}h ,
Dual Encryption Protocol
Architecture
Top level nodes may have different KEKs
Using several KEKs may extend the key lifetime
Each subgroup has a subgroup key
Participating group manager will not be given a
KEK. Only members have KEK.
CC (Capability Certificates) are issued by a higher
authority
AC (Access Capability) is used to prevent multiple
join
DEK is encrypted with the KEK and the subgroup
key
Dual Encryption Protocol
Key Distribution Tree
Top level
sender
S
Key group 1
p1
g2
h5
gi
h6
participant
g1
h1
h2
h3
p2
h4
h7
h5
pi
member
h6
h7
hi
host
Dual Encryption Protocol
Join
h SGMs : CCh
g h : Group Id(g)
h s : CCh , g
s h : {{ ACh }s ,{KEK}s }}h
h g : { ACh }s
g h : {{ LS '}g }h
g Group Members : {{ LS '}g }LS
Dual Encryption Protocol
Leave
The group manager multicast a message
containing a new subgroup key encrypted with the
rest of group member’s public keys
To decrypt the DEK, KEK and subgroup key are
necessary. Since the leaving member just has KEK
and the old subgroup key, it cannot access the
multicast data afterwards ensuring the forward
secrecy.
Diffie-Hellman Group Key
Distribution
3 Protocols are proposed
No group controller. All members should
cooperate to generate a group key
Diffie-Hellman Group Key
Distribution
Version 1
{ ( N k | k [1, j ]) | j[1,i ]}
M i
M i 1
Stage 1 (Upflow) : i [1, n 1]
{ ( N k | k[ i , j ]) | j[1,i ]}
M ni
M n i 1
Stage 2 (Downflow) : i [1, n 1]
Diffie-Hellman
Version 1 Example
When
n 5 , M4
receives the set
{ N 1 , N 1 N 2 , N 1 N 2 N 3 , N 1 N 2 N 3 N 4 }
{ N 5 , N 1 N 5 , N 1 N 2 N 5 , N 1 N 2 N 3 N 5 }
and
and
M5
N N
1
2 N3N4 N5
{ N 1 , N 1 N 2 , N 1 N 2 N 3 }
returns
to
and forwards
M4
is a group key
the
set
Diffie-Hellman Group Key
Distribution
Version 2
{ ( Nk |k[1,i ]k j ) | j[1,i ]}, N1Ni
M i M i 1
Stage 1 (Upflow) : i [1, n 1]
{ ( Nk |k[1,n ]) k j ) | j[1,i ]}
M i
M n
Stage 2 (Broadcast )
Diffie-Hellman
Version 2 Example
M4
receives
the
set
{ N 1 N 2 N 3 , N 1 N 2 , N 1 N 3 , N 3 N 2 }
{ N 1 N 2 N 3 N 4 , N 1 N 2 N 3 , N 1 N 2 N 4 , N 1 N 3 N 4 , N 3 N 2 N 4 }
to
M3
. Then
and
M5
passes
generate a
message and broadcasts the message, so that each
member can calculate a group key
Diffie-Hellman Group Key
Distribution
Version 3
( N k |k[1,i ])}
M i
M i 1
Stage 1 (Upflow) : i [1, n 2]
( N k |k[1,n 1])
M i M n 1
Stage 2 (Broadcast )
( N k |k[1,n 1]) k i )
M i M n
Stage 3 (Respond)
{ ( N k |k[1,n ]) k i ) |i[1, n 1]}
M i M n
Stage 4 (Broadcast )
Diffie-Hellman Group Key
Distribution
Join for version 2
1. Assume that
Mn
saves the contents of the upflow
message in the second protocol
2. M
generates
n
a
{ ( N k | k [1, i ] k j ) | j [1, n]}, N1 N n1 N n
3. M
n 1
K n 1
4.
M n 1
new
exponent
Nn
is sent to the new member M
.
n 1
generates its exponent and computes new
N N
=
1
n 1 N n N n 1
broadcasts to the group
{ ( N k | k [1, i ] k j ) | j [1, n ]}
Diffie-Hellman Group Key
Distribution
Delete for version 2
Mn
generates a new exponent N , and broadcasts
{ ( N k | k [1, i ] k j ) | j [1, n ]}
n
except
of deleted member
N 1 N p 1 N p 1 N n
where
p
is an index
Reference
[1] Paul Judge and Mostafa Ammar, Security Issues and
Solutions in Multicast Content Distribution: A Survey, IEEE
Network, Jan/Feb 2003.
[2] T. Hardjono and B Weis, RFC 3740, IETF, 2004
[3] SanFord Rafaeli and David Hutchison, A Survey of Key
Management for Secure Group Communication, ACM Computing
Survey, Vol 35, No. 3, Sept., 2003.
[4] Lakshminath R. Dondeti, Sarit Mukherjee and Ashok Samal,
Survey and Comparison of Secure Group Communication
Protocols, Technical Report, University of Nebraska-Lincoln, June
1999.
[5] Thoams Hardjono and Gene Tsudik, IP Multicast Security:
Issues and Directions, Annales de Telecom, 2000.
Reference
[6] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B.
Pinkas, Multicast Security: A Taxonomy and Efficient
Constructions. IEEE Infocom, NY, USA, March 1999.
[7] A. Eskicioglu, Multimedia security in group communications:
recent progress in key management, authentication, and
watermarking. ACM Multimedia Systems Journal, Special Issue
on Multimedia Security, September 2003.
[8] H. Harney, C. Muckenhirn, Group Key Management Protocol
(GKMP) Specification, RFC 2093, 1997.
[9] H. Harney, C. Muckenhirn, Group Key Management Protocol
(GKMP) Architecture, 2094, 1997.
[10] A. Ballardie, Scalable Multicast Key Distribution, RFC 1949,
1996
Reference
[11] D. Wallner, E. Harder and R. Agee, Key Management for
Multicast: Isssues and Architectures, RFC 2627, 1999.
[12] Lakshminath R. Dondeti and Sarit Mukherjee, A Dual
Encryption Protocol for Scalable Secure Multicasting, IEEE ISCC,
1999
[13] Michael Steiner, Gene Tsudik and Michael Waidner, DiffieHellman Key Distribution Extended to Group Communication,
ACM CCS, 1996.
[14]Marcel Waldvogel, GErmano Caronni, Dan Sun, Nathalie
Weiler and Berhard Plattner, The VersaKey FrameWork: Versatile
Group Key Management, IEEE Journal on Selected Areas in
Communications, 1999.
© Copyright 2026 Paperzz