Multicast Security Cryptographic Protocols InKwan Yu.

Multicast Security

Cryptographic Protocols

InKwan Yu

Multicast Security Issues Multicast

What is it? An efficient way to communicate between 1-to-n

or m-to-n hosts Applications

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 compr

omise the system security Key independence, decentralized controller, local rekey, n

umber of rounds, number of messages

Multicast Security Issues Issues & Solutions

multicastmulticast

Open groupMembershipOpen groupMembership

All receivedata

All receivedata

Outside member sends data

Outside member sends data

Open access to distributed

content

Open access to distributed

content

Noindividualization of received data

Noindividualization of received data

Open access to send data to

group

Open access to send data to

group

Denial of serviceDenial of service EavesdroppingEavesdropping No theft deterrenceNo theft

deterrence Denial of serviceDenial of service MasqueradingMasquerading

Multicast receiver access

control

Multicast receiver access

control

Group key managementGroup key

managementMulticast

fingerprintingMulticast

fingerprintingMulticast source access control

Multicast source access control

Multicast source authentication

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 infor

mation 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

GCKS

REG REKEY REG

REG REKEY

Sender DATA

REG REKEY

Sender DATA

REG REKEY

Receiver DATA

REG REKEY

Receiver DATA

Multicast Security Architecture Centralized Multicast Security

Reference Framework

PolicySeverPolicySever

Group Controller/Key Server

Group Controller/Key Server

SenderSender

ReceiverReceiver

MulticastSecurityPolicies

GroupKey Management

MulticastDataHandling

Multicast Security Architecture Distributed Multicast Security

Reference Framework PolicySeverPolicySever

Group Controller/Key Server

Group Controller/Key Server

SenderSender

ReceiverReceiver

PolicySeverPolicySever

Group Controller/Key Server

Group Controller/Key Server

ReceiverReceiver

MulticastSecurityPolicies

GroupKey Management

MulticastDataHandling

Multicast Security Architecture Hierarchically-organized

Decentralized Key Distribution

GCKSGCKS

MemberMember MemberMemberMemberMember

Sub GCKSSub GCKS Sub GCKSSub GCKS

MemberMember MemberMemberMemberMember

. . . .

. . . .

Sub GCKSSub GCKS. . . .

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 gr

oup GTEK(Group Traffic Encryption Key) for data GKEK(Group Key Encryption Key) for the group key

Group Key Management Protocol Group Key Generation

CONTROLLER

CONTROLLER

MEMBER

MEMBER

Create Group Keys 1 (rand #)

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

Group Key Management Protocol Group Key Distribution

CONTROLLER

CONTROLLER

MEMBER

MEMBER

Create Session Keys 1 (rand #)

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

Group Key Management Protocol Rekey

CONTROLLER

CONTROLLER

MEMBER

MEMBER

Create Group Keys 1

Create Group Keys 2

Negotiate Session Keys 1

Negotiate Session Keys 2

Rekey_Multicast

Group Key Management Protocol Join

CONTROLLER

CONTROLLER

MEMBER

MEMBER

Create Session Keys 1

Create Session Keys 2

Negotiate Session Keys 1

Negotiate Session Keys 2

Download Group Keys

Key Download Acknowledge

Request Group Join

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 Key O

Key AKey A

Key JKey J

11 22 33 44 55 66 77 88 99 1010 11 1212 1313 1414 1515 1616

Key BKey B Key CKey C Key DKey D Key EKey E Key F Key GKey G Key HKey H

Key IKey I Key K Key LKey L

Key MKey M Key N

intermediatekeys

net key

users

Centralized Flat Key Distribution Architecture

Each member has a fixed length id Each bit of id is assigned to a different KE

K. Each member is assigned a set of unique K

EKs 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

KEK 2.0 KEK 2.1

KEK 3.0 KEK 3.1

Bit 0

Bit 1

Bit 2Bit 3

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

0.2}{ KEKnewTEK

0.1}{ KEKnewTEK

oldnew KEKTEKnewKEK 0.0|}0.0{1.0}{ KEKnewTEK

oldnew KEKTEKnewKEK 1.1|}1.1{

oldnew KEKTEKnewKEK 1.2|}1.2{

oldnew KEKTEKnewKEK 0.3|}0.3{ 1.3}{ KEKnewTEK

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

CoreCore

routerrouter routerrouterBB

AA

routerrouterrouterrouterrouterrouter

routerrouter

routerrouter

routerrouterrouterrouter routerrouter

routerrouter

Host hHost hA, B, router are non-core routers

Scalable Multicast Key Distribution Example Protocol

,},,,}{{:

JOIN_ACK},,}{{:

,JOIN_ACK},,}{{:

ST}JOIN_REQUE,}{,{:

ST}JOIN_REQUE,}{,{ :

},,{ where,}{ :

encryption datafor used is

}}},,{

,}},,{{

,}{,_{

hhh

Bhh

Chh

BhhB

AhhA

hhhhhh

senderhopnextCore

hostCore

Core

SAParamKEKgroupkeytokenhA

spackagegroupaccestokenAB

spackagegroupaccestokenBC

tokentokenCB

tokentokenBA

ArrandomnumetimestamptokentokenAh

groupkey

SAParamKEKgroupkey

SAParamKEKgroupkey

ACLsendertokenspackagegroupacces

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. O

nly members have KEK. CC (Capability Certificates) are issued by a higher aut

hority 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

SS

p1p1 g1g1h1h1

p2p2g2g2 h2h2 h3h3 h4h4

h6h6h5h5 h7h7 h6h6h5h5 h7h7

pigi hiparticipant member host

sender Top level

Key group 1

Dual Encryption Protocol Join

LSg

hg

sh

hssh

h

h

LSg

LShg

ACgh

KEKAChs

gCCsh

hg

CCh

}}'{{:Members Group

}}'{{:

}{:

}}}{,}{{:

,:

Id(g) Group :

:SGMs

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

]1,1[ : (Downflow) 2 Stage

]1,1[ : (Upflow) 1 Stage

1]},1[|{

1]},1[|{

]),[|(

]),1[|(

ni

MM

ni

MM

inij

in

iij

i

jikkN

jkkN

Diffie-Hellman Version 1 Example

W h e n 5n , 4M r e c e i v e s t h e s e t },,{ 321211 NNNNNN a n d f o r w a r d s

},,,{ 4321321211 NNNNNNNNNN a n d 5M r e t u r n s t o 4M t h e s e t

},,,{ 5321521515 NNNNNNNNNN a n d 54321 NNNNN i s a g r o u p k e y

Diffie-Hellman Group Key Distribution Version 2

)(Broadcast 2 Stage

]1,1[ : (Upflow) 1 Stage

]},1[|{

1]},,1[|{

)]),1[|(

1)],1[|(

nij

i

iij

i

MM

ni

MM

jknkkN

iNNjkikkN

Diffie-Hellman Version 2 Example

4M receives the set },,,{ 233121321 NNNNNNNNN and passes

},,,,{ 4234314213214321 NNNNNNNNNNNNNNNN to 3M . Then 5M generate a

message and broadcasts the message, so that each

member can calculate a group key

Diffie-Hellman Group Key Distribution Version 3

)(Broadcast 4 Stage

(Respond) 3 Stage

)(Broadcast 2 Stage

]2,1[ : (Upflow) 1 Stage

]}1,1[|{

1

1

)]),1[|(

)])1,1[|(

])1,1[|(

])},1[|(

nni

i

ni

ni

ii

MM

MM

MM

ni

MM

iknkkN

iknkkN

nkkN

ikkN

Diffie-Hellman Group Key Distribution Join for version 2

1 . A s s u m e t h a t nM s a v e s t h e c o n t e n t s o f t h e u p f l o w

m e s s a g e i n t h e s e c o n d p r o t o c o l

2 . nM g e n e r a t e s a n e w e x p o n e n t nN .

nnk NNNjkikN nj

11]},,1[|{ )],1[|( i s s e n t t o t h e n e w m e m b e r 1nM

3 . 1nM g e n e r a t e s i t s e x p o n e n t a n d c o m p u t e s n e w

1nK = 111 nnn NNNN

4 . 1nM b r o a d c a s t s t o t h e g r o u p ]},1[|{ )],1[|( njjkikN k

Diffie-Hellman Group Key Distribution Delete for version 2

nM generates a new exponent nN , and broadcasts

]},1[|{ )],1[|( njjkikNk except npp NNNN

111 where p is an index

of deleted member

Reference [1] Paul Judge and Mostafa Ammar, Security Issues and Solution

s 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 Manag

ement 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. P

inkas, 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 Mul

ticast: Isssues and Architectures, RFC 2627, 1999. [12] Lakshminath R. Dondeti and Sarit Mukherjee, A Dual Encryp

tion Protocol for Scalable Secure Multicasting, IEEE ISCC, 1999 [13] Michael Steiner, Gene Tsudik and Michael Waidner, Diffie-H

ellman 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.