Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Multicast SecurityMay 10, 2004Sam IrvineAndy NguyenMulticast Overview•Bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to thousands of recipients (multicast group)•Applications include video-conferencing, streaming audio, sending out stock quotes, etc.•Scalable reliability, flow control, congestion control, security are all active areas of researchSecurity Objectives•Usual suspects:–Authentication•How do we authenticate members within the multicast group?–Confidentiality–Integrity–ExclusivityMulticast Security•Inherently more susceptible to attack–Many more opportunities and points for interception of traffic and attacks–Attacks affect many systems–Usually multicast address is well-known–Possible for attacker to pose as one of the many possible systems in the multicast group•Solutions must be scalable and address the dynamic nature of membershipUnicast versus Multicast Security•Security association defines a set of keying material in order to setup a secure link between two systems in a unicast protocol–Membership remains static throughout the session•In multicast, the security association is among many people–Membership is dynamic throughout the sessionDynamic Membership•Must ensure that a member is only allowed to participate when it is authorized to do so•New members must not be able to access old multicast data (joins)•Old members must not be able to access new multicast data (leaves)•Multicast security protocol must be prepared to change the keying material on each and every join to insure integrity•How do we do key management for dynamic security associations?Key management solutions•Centralized group key management protocols•Decentralized Architectures–Management divided into subgroups•Distributed Key Management protocols–No explicit key distribution center, members themselves handle key generationCentralized Key Management Example•Canetti et al. use one way function trees in conjunction with pseudo-random generators•Each user holds log(n+1) keys•Issuing a new keys takes log(n) sendsGroup Creationkk1k01k0k10k11k00u1u2u3u4{k00,k01,k0,k10,k11,k1,k}{k,k0,k00,k01}{k,k0,k00}{k,k0,k01}{k,k1,k10}{k,k1,k10,k01}{k,k1,k11}k is the shared keykk1k01k0k10k11k00u1u2u3u4Revoke u1's accessk is the shared key for the multicast groupRevoke u1's accesskk1k01k0k10k11k00u1u2u3u4Generate k', k0'Revoke u1's accesskk1k01k0k10k11k00u1u2u3u4{k'}:k1Revoke u1's accesskk1k01k0k10k11k00u1u2u3u4{k'}:k1Revoke u1's accesskk1k01k0k10k11k00u1u2u3u4{k', k0'}:k01Revoke u1's accesskk1k01k0k10k11k00u1u2u3u4{k', k0'}:k01Decentralized Architectures Example•Iolus–Splits a large group into small subgroups–Group Security Controller at the top, Group security intermediaries manage subgroups–In order to update key for leaves, must send out new key encrypted with everyone’s secret key. Size of message is O(n)–Data path affected when sending out data (Translating data between groups)Distributed key management•Group Diffie-Hellman Key Exchange–N rounds, single key•Distributed Logical Key Hierarchy–log(n) rounds–log(n) keysDistributed Logical Key Hierarchym2m3m4m1m1 and m2 agree on key k12m3 and m4 agree on key k34Key (12),(34)m2m3m4m1(m1,m2) and (m3,m4) agree on key k (12),(34) k12k34•Digital Signatures–RSA,DSA, Elliptic Curve–Very expensive to compute for each message•Message Authentication Codes (MAC)–Given a shared key K, a positive integer L and a one way function F•Compute FL(K + message), where•F0(X) = F(X)•FL(X) = F(FL-1(X))Message authenticationMessage authentication•MAC exclusivity–If all receivers have the MAC key, than any receiver can fake a message•Solution–Generate a set of m keys–Distribute n < m of the keys randomly to each receiver–Sender knows all m keysMessage authentication•Solution (cont)–Sender computes m MACs and sends them with the message–Receivers verify the MAC for each of their known n keys–Senders cannot independently create all m MACs without collusion–Randomness prevents intentional collusionMessage authentication•Sets of keys can reduce MAC length overhead–Use previous scheme with 1 alteration: MACs map to a single bit–Can arbitrarily forge a MAC with 1/2m probability–Receivers can forge a MAC with 1/(2m-n) probabilityWhat haven't we talked about•Routing table security–Unauthenticated clients cannot change the routing topology–Can legitimate clients affect routing tables?Differing multicast requirements•1-N multicasting–1 Sender, N receivers•M-N multicast–M senders transmit to N receivers•N-N full duplex communication–Any member can communicate to any other
View Full Document
Unlocking...