Secure Multicast Presented by: Adam J. Rosen and Ram Goverdhana CSE620, Advanced Networking Concepts.

Secure MulticastSecure Multicast

Presented by: Presented by:

Adam J. Rosen and Ram Adam J. Rosen and Ram GoverdhanaGoverdhana

CSE620, Advanced Networking CSE620, Advanced Networking ConceptsConcepts

IntroductionIntroduction

• In today’s inter-networked world, we are In today’s inter-networked world, we are creating larger demand for broadcast creating larger demand for broadcast type services over existing networks.type services over existing networks.

• These new applications, which These new applications, which broadcast audio, video, and data, have broadcast audio, video, and data, have their own security needs in order to their own security needs in order to maintain the benefits of multicast’s maintain the benefits of multicast’s performance.performance.

OverviewOverview

• How does multicast security differ from How does multicast security differ from unicast security?unicast security?

• What are the vulnerabilities of What are the vulnerabilities of multicast?multicast?

• Different methods of multicast security.Different methods of multicast security.

Multicast vs. UnicastMulticast vs. Unicast

• Simple schemes that emulate multicast Simple schemes that emulate multicast by using secure unicast exist, but we by using secure unicast exist, but we lose the advantages of multicast routinglose the advantages of multicast routing

• Must maintain security of transmission, Must maintain security of transmission, while allowing users to join or leave the while allowing users to join or leave the multicast sessionmulticast session

Multicast vs. Unicast (cont.)Multicast vs. Unicast (cont.)

• New members into the session should New members into the session should not be able to decrypt earlier not be able to decrypt earlier transmissions, nor should ex-members transmissions, nor should ex-members be able to decrypt later transmissionsbe able to decrypt later transmissions– We need a system of changing keys, while We need a system of changing keys, while

assuring ourselves that all legitimate assuring ourselves that all legitimate members are able to transmit and receive members are able to transmit and receive to/from all other legitimate membersto/from all other legitimate members

Example: A lawyers Example: A lawyers deposition…deposition…• A lawyer must be able to depose each A lawyer must be able to depose each

witness individuallywitness individually

• Each witness should not be able to find Each witness should not be able to find out what previous/later witnesses told out what previous/later witnesses told the lawyerthe lawyer– Key must change every time someone Key must change every time someone

enters/leaves the groupenters/leaves the group

Vulnerabilities of MulticastVulnerabilities of Multicast

• Multicast suffers from increased Multicast suffers from increased vulnerability due to:vulnerability due to:– Sessions are frequently advertisedSessions are frequently advertised

– Greater number of points of vulnerabilityGreater number of points of vulnerability

– Attack affects a broader base of peopleAttack affects a broader base of people

– Attacker can pose as a legitimate user Attacker can pose as a legitimate user easier (larger “crowd” of principals)easier (larger “crowd” of principals)

What does ‘security’ need What does ‘security’ need to provide?to provide?• AuthenticationAuthentication

– Verify the user is who he says he isVerify the user is who he says he is

• AuthorizationAuthorization– Only admit those with proper authorization Only admit those with proper authorization

into the groupinto the group

• IntegrityIntegrity– Group members maintain privacy from Group members maintain privacy from

those not in the groupthose not in the group

• System must be scalableSystem must be scalable

The Iolus ApproachThe Iolus Approach

• A hierarchical approach to key A hierarchical approach to key distributiondistribution

• Uses ‘Secure Agents’ to administer Uses ‘Secure Agents’ to administer securitysecurity

• Users join separate local multicast Users join separate local multicast groupsgroups

Network Security: Adding Network Security: Adding MulticastMulticast• Treat a multicast session as blocks of Treat a multicast session as blocks of

timetime

• A new block begins when someone A new block begins when someone joins/leaves the groupjoins/leaves the groupAlice joins Carol joins

Bob leaves

ti ti+1 ti+2 ti+3

Alice leaves

The Scalability ProblemThe Scalability Problem

• ““1 affects n” type failure1 affects n” type failure– the actions of one member affects the the actions of one member affects the

entire groupentire group

– i.e. creating a new source-based delivery i.e. creating a new source-based delivery tree rooted at the sender whenever a new tree rooted at the sender whenever a new sender joins the multicast group sender joins the multicast group

• ““1 does not equal n” type failure1 does not equal n” type failure– occurs when protocol cannot deal with the occurs when protocol cannot deal with the

group as a whole and must consider the group as a whole and must consider the conflicting demands of members on an conflicting demands of members on an individual basis (i.e. flow control)individual basis (i.e. flow control)

““1 affects n” Example in 1 affects n” Example in MulticastMulticast• If the entire group shares a single group If the entire group shares a single group

key (Kkey (Kgrpgrp), a new key must be generated ), a new key must be generated (K`(K`grpgrp) and distributed (may use K) and distributed (may use Kgrpgrp to to distribute K`distribute K`grpgrp) when a new user joins ) when a new user joins the groupthe group

• Joins exhibit a “1 affects n” scalability Joins exhibit a “1 affects n” scalability failure because they require all failure because they require all members to process the change in Kmembers to process the change in Kgrpgrp when one new member joinswhen one new member joins

““1 does not equal n” 1 does not equal n” ExampleExample• On leaves, we need to replace KOn leaves, we need to replace Kgrpgrp with with

K`K`grpgrp, but we cannot distribute using K, but we cannot distribute using Kgrpgrp

• Under basic scheme, we need to unicast Under basic scheme, we need to unicast the new key to each user individuallythe new key to each user individually

• Extremely inefficient in groups with Extremely inefficient in groups with large memberships or highly dynamic large memberships or highly dynamic membershipsmemberships

Additional NotesAdditional Notes

• We must insure that all receivers get a KWe must insure that all receivers get a Kgrpgrp update, or they will not be able to decrypt update, or they will not be able to decrypt later communication, and may also accept later communication, and may also accept communications from members that have communications from members that have been removed from the groupbeen removed from the group

• Senders failing to receive a KSenders failing to receive a Kgrpgrp update will update will continue to encrypt using an outdated key, continue to encrypt using an outdated key, allowing former group members to decrypt allowing former group members to decrypt their transmissions, while preventing their transmissions, while preventing legitimate users from decryptinglegitimate users from decrypting

Additional Notes (cont.)Additional Notes (cont.)

• If the underlying multicast system is If the underlying multicast system is unreliable (a reasonable assumption), unreliable (a reasonable assumption), we need additional processing will be we need additional processing will be required through the use of a reliable required through the use of a reliable multicast protocolmulticast protocol

• In highly dynamic memberships, the In highly dynamic memberships, the probability of confusion and security probability of confusion and security breaches increasebreaches increase

The Iolus FrameworkThe Iolus Framework

• Remove the concept of a flat secure Remove the concept of a flat secure multicast groupmulticast group

• Create a Create a secure distribution treesecure distribution tree composed composed of subgroupsof subgroups

• Each subgroup has its own multicast group Each subgroup has its own multicast group (with its own address)(with its own address)

• Each group has its own subgroup keying Each group has its own subgroup keying material (Kmaterial (Ksgrpsgrp ) )

• Only the local KOnly the local Ksgrpsgrp will need to be changed will need to be changed on a join or leaveon a join or leave

Two Entities of IolusTwo Entities of Iolus

• Group Security Controller (GSCs)Group Security Controller (GSCs)– Manages the top level subgroupManages the top level subgroup

• Group Security Intermediaries (GSIs)Group Security Intermediaries (GSIs)– Manage each of the subgroupsManage each of the subgroups

• Collectively, we call GSCs and GSIs Collectively, we call GSCs and GSIs Group Security Agents (GSAs)Group Security Agents (GSAs)

Iolus Structure ExampleIolus Structure Example

Functions of the GSAsFunctions of the GSAs

• The GSC maintains control of the top-The GSC maintains control of the top-level subgroup at the root of the secure level subgroup at the root of the secure distribution treedistribution tree– Ultimately responsible for the security of Ultimately responsible for the security of

the groupthe group

• GSIs are special trusted servers that are GSIs are special trusted servers that are authorized to act as proxies of the GSC authorized to act as proxies of the GSC or their parent GSIs and control their or their parent GSIs and control their local subgrouplocal subgroup

GSIsGSIs

• GSIs form a bridge between subgroupsGSIs form a bridge between subgroups

• They receive data multicast in their They receive data multicast in their parent or child subgroups and re-parent or child subgroups and re-multicast to their child or parent multicast to their child or parent subgroups respectivelysubgroups respectively

• We will show that decryption and re-We will show that decryption and re-encryption is not necessaryencryption is not necessary

StartupStartup

• GSC is provided with an GSC is provided with an access control access control listlist ( (ACLACL), which is used to set the ), which is used to set the security policy concerning user accesssecurity policy concerning user access

• GSIs and other members apply to join GSIs and other members apply to join its subgroupits subgroup

JoinsJoins

• A sender or receiver locates its A sender or receiver locates its designated GSA and sends a JOIN request designated GSA and sends a JOIN request using a secure unicast channel.using a secure unicast channel.

• GSA checks its database and decides GSA checks its database and decides whether to approve or deny requestwhether to approve or deny request

• GSA generates a secret key (KGSA generates a secret key (KGSA-MBRGSA-MBR) to ) to be shared only with the new memberbe shared only with the new member

• Stores secret key along with other Stores secret key along with other relevant information in a private relevant information in a private databasedatabase

Joins (cont.)Joins (cont.)

• Sends KSends KGSA-MBRGSA-MBR to member using the secure to member using the secure channelchannel

• GSA multicasts a GRP_KEY_UPDATE GSA multicasts a GRP_KEY_UPDATE message containing K`message containing K`sgrpsgrp encrypted with encrypted with KKsgrp sgrp to current multicast subgroupto current multicast subgroup

• Sends K`Sends K`sgrpsgrp to the joining member using the to the joining member using the separate secure channelseparate secure channel

• If the GSA is not currently part of the secure If the GSA is not currently part of the secure multicast group. It follows a similar multicast group. It follows a similar procedureprocedure

Joins (cont.)Joins (cont.)

• Example of a GRP_KEY_UPDATE Example of a GRP_KEY_UPDATE message on a joinmessage on a join

HDR {KGRP’}KGRP

RefreshesRefreshes

• Each JOIN has an expiration time Each JOIN has an expiration time associated with itassociated with it

• If the member wishes to remain in the If the member wishes to remain in the group, it sends a REFRESH messagegroup, it sends a REFRESH message

• Grants ability to gracefully handle Grants ability to gracefully handle network partitionsnetwork partitions

• Subgroups that have become partitioned Subgroups that have become partitioned from the top-level subgroup are implicitly from the top-level subgroup are implicitly removed from the group after some removed from the group after some threshold of timethreshold of time

LeavesLeaves

• Occur under two conditionsOccur under two conditions– A member wishes to leave (sends a LEAVE A member wishes to leave (sends a LEAVE

request to the GSA)request to the GSA)

– GSA wishes to expel member (sends a GSA wishes to expel member (sends a notification to expelled member)notification to expelled member)

• KKsgrp sgrp needs to be changed either wayneeds to be changed either way

• GSA can still multicast K`GSA can still multicast K`sgrpsgrp to the to the remaining group members (instead of remaining group members (instead of using several unicast messages)using several unicast messages)

Leaves (cont.)Leaves (cont.)

• Multicast one message containing n Multicast one message containing n copies of K`copies of K`sgrpsgrp

• Use separate KUse separate KGSA-MBRGSA-MBR to encrypt K` to encrypt K`sgrpsgrp

• Replaces Replaces O(n)O(n) separate messages with separate messages with a single efficient message of size a single efficient message of size O(n)O(n)

Data TransmissionData Transmission

• Having GSIs decrypt and re-encrypt data is Having GSIs decrypt and re-encrypt data is too inefficienttoo inefficient

• Instead of encrypting message with KInstead of encrypting message with Ksgrpsgrp, , sender generates a one-time random key sender generates a one-time random key and encrypts data with this keyand encrypts data with this key

• Encrypts key with KEncrypts key with Ksgrpsgrp and includes it in and includes it in transmissiontransmission

• GSAs only need to decrypt and re-encrypt GSAs only need to decrypt and re-encrypt the random key, not the whole data the random key, not the whole data packetpacket

Data Transmission Data Transmission ExampleExample

Data Transmission Data Transmission (Alternative)(Alternative)• Sender Sender unicastsunicasts message to GSA using message to GSA using

KKGSA-MBRGSA-MBR, GSA decrypts, re-encrypts with , GSA decrypts, re-encrypts with KKsgrpsgrp and signs packet, then multicasts to and signs packet, then multicasts to group and parent subgroupgroup and parent subgroup

• Eliminates worry of senders having an Eliminates worry of senders having an outdated Koutdated Ksgrpsgrp

• Receivers have the assurance of GSAs Receivers have the assurance of GSAs signature to verify message is from a signature to verify message is from a valid sourcevalid source

Data Transmission Data Transmission ComparisonComparison

ShutdownShutdown

• GSC for secure multicast group shuts GSC for secure multicast group shuts down after sending GRP_END down after sending GRP_END notification to all members in the top-notification to all members in the top-level subgrouplevel subgroup

• Any GSAs attached to top-level Any GSAs attached to top-level subgroup will then multicast the subgroup will then multicast the GRP_END message and then shutdownGRP_END message and then shutdown

• Process proceeds similarly down the Process proceeds similarly down the treetree

Deployment IssuesDeployment Issues

• GSAs can be placed in “natural” GSAs can be placed in “natural” positionspositions– Entry points at regional networks, local Entry points at regional networks, local

networks, subnets (etc.)networks, subnets (etc.)

• Use “Dynamic Grouping”Use “Dynamic Grouping”– When a specific GSA becomes overloaded, When a specific GSA becomes overloaded,

we can share membership with a newly we can share membership with a newly started GSAstarted GSA

GSA Multicast Forwarding GSA Multicast Forwarding PerformancePerformance

• Approximately 450 micro-seconds delay Approximately 450 micro-seconds delay introduced (due to cryptographic introduced (due to cryptographic operations)operations)

A Key Graph Based A Key Graph Based ApproachApproach• Hierarchy is logical, rather than physicalHierarchy is logical, rather than physical

• Key tree maintained by the Key tree maintained by the Security Security ManagerManager

• No intermediary security nodes (such as No intermediary security nodes (such as GSIs in Iolus model)GSIs in Iolus model)

Key Graph ExampleKey Graph Example

Example (cont.)Example (cont.)

• P2 has three keys:P2 has three keys:– Key (2.0)Key (2.0)

– Key (1.0)Key (1.0)

– Key (0.2)Key (0.2)

• Root key is shared by all, and used for Root key is shared by all, and used for group communicationgroup communication

Re-keyingRe-keying

• When P8 leaves key (2.0) needs to be When P8 leaves key (2.0) needs to be changed to key (2.0’) and key (1.2) changed to key (2.0’) and key (1.2) needs to be changed to key (1.2’)needs to be changed to key (1.2’)

• Use key (1.0) to encrypt key (2.0’)Use key (1.0) to encrypt key (2.0’)– Multicast to P0,P1,P2Multicast to P0,P1,P2

• Use key (1.1) to encrypt key (2.0’)Use key (1.1) to encrypt key (2.0’)– Multicast to P3,P4,P5Multicast to P3,P4,P5

Re-keying (cont.)Re-keying (cont.)

• Use key (1.2’) to encrypt key (2.0’)Use key (1.2’) to encrypt key (2.0’)– Multicast to P6,P7Multicast to P6,P7

• Send key (1.2’) to P6 and P7 individuallySend key (1.2’) to P6 and P7 individually

• To avoid sending a large number of To avoid sending a large number of messages, single message containing messages, single message containing all these keys is multicast to the groupall these keys is multicast to the group

• Size of the message is Size of the message is OO(log (log NN), where ), where NN is the number of members in the is the number of members in the groupgroup

Security ManagerSecurity Manager

• Responsible for authenticating Responsible for authenticating participants, generating and distributing participants, generating and distributing keyskeys

• Multicasts a heartbeat message to the Multicasts a heartbeat message to the group periodicallygroup periodically

• Heartbeat contains version number of Heartbeat contains version number of the current session keythe current session key– Version number is updated each time the Version number is updated each time the

session key is changedsession key is changed

EpochsEpochs

• Time managed by security manager is Time managed by security manager is divided into divided into epochs epochs for purposes of rekeyingfor purposes of rekeying

• All joins and leaves within a single epoch All joins and leaves within a single epoch are aggregatedare aggregated

• Allows for single rekey message for many Allows for single rekey message for many joins/leaves instead of several separate joins/leaves instead of several separate ones transmitted at the beginning of next ones transmitted at the beginning of next epochepoch

• Also provides time to insure that all users Also provides time to insure that all users receive the rekey messagereceive the rekey message

Epochs (cont.)Epochs (cont.)

• Actual use of new keys is delayed by 1 Actual use of new keys is delayed by 1 epochepoch

• Avoids having to drop packets due to Avoids having to drop packets due to inability to decrypt theminability to decrypt them

• Users joining group may have to wait up to Users joining group may have to wait up to 2 epochs before they can decrypt the data2 epochs before they can decrypt the data– To avoid this, SM acts as a reflector in a To avoid this, SM acts as a reflector in a

temporary multicast group of new memberstemporary multicast group of new members

• Users leaving the group may be able to Users leaving the group may be able to decrypt data for up to 2 epochsdecrypt data for up to 2 epochs

Epochs (cont.)Epochs (cont.)

• This ability to decrypt for up to 2 epochs This ability to decrypt for up to 2 epochs after a leave is minimized if epochs are after a leave is minimized if epochs are short intervalsshort intervals

• Other users can take into account Other users can take into account presence of ex-user for the extra time to presence of ex-user for the extra time to avoid broadcasting sensitive dataavoid broadcasting sensitive data

Epochs DiagramEpochs Diagram

• HB:X = Heartbeat HB:X = Heartbeat RK:X = RekeyRK:X = Rekey

Joining a SessionJoining a Session

• A participant authenticates themselves A participant authenticates themselves to the Security Manager (using SSL or to the Security Manager (using SSL or similar technology)similar technology)

• Security Manager checks an ACL to Security Manager checks an ACL to decide whether or not to admit the decide whether or not to admit the participantparticipant

• Participant is given its set of keys at the Participant is given its set of keys at the beginning of the next epochbeginning of the next epoch

• SSL connection is closedSSL connection is closed

RekeyingRekeying

• Rekey messages are digitally signed Rekey messages are digitally signed and timestamped by the Security and timestamped by the Security Manager to prevent forgery and replay Manager to prevent forgery and replay attacksattacks

• Disseminates group informationDisseminates group information

• Includes changes in group membership Includes changes in group membership along with rekey messagesalong with rekey messages– Optional, only for applications that require itOptional, only for applications that require it

ScalabilityScalability

• Can use multiple Security Managers to Can use multiple Security Managers to increase scalabilityincrease scalability

DependenciesDependencies

• Single point of failure (Security Single point of failure (Security Manager)Manager)

• Requires a reliable multicast protocol for Requires a reliable multicast protocol for key diseminationkey disemination

Secure Multicast Secure Multicast Routing using Keyed Routing using Keyed Hierarchical ProtocolHierarchical Protocol(KHIP)(KHIP)

IntroductionIntroduction

• Overview of Ordered Core Based TreesOverview of Ordered Core Based Trees

• Structure of HIP (Hierarchical Protocol)Structure of HIP (Hierarchical Protocol)

• Design goals of Keyed HIPDesign goals of Keyed HIP

• Elements of multicast treeElements of multicast tree

• Construction of secure multicast treeConstruction of secure multicast tree

• Tree MaintenanceTree Maintenance

• ConclusionConclusion

Overview of Ordered Core Overview of Ordered Core Based Trees (OCBT)Based Trees (OCBT)

• Elimination of loopsElimination of loops

• Reconstructs tree with less traffic than Reconstructs tree with less traffic than CBT and does so correctlyCBT and does so correctly

• Distribution of core points reduces the Distribution of core points reduces the repair traffic and the distance within the repair traffic and the distance within the logical levellogical level

Overview of HIPOverview of HIP(Hierarchical Multicast (Hierarchical Multicast Routing)Routing)• Use of Ordered Core Based Tree (OCBT) Use of Ordered Core Based Tree (OCBT)

to route multicast data between to route multicast data between heterogeneous multicast domainsheterogeneous multicast domains

• Makes domains appear as a single Makes domains appear as a single virtual router within the higher level virtual router within the higher level shared treeshared tree

• Hard-state protocol and recursive Hard-state protocol and recursive creation of virtual routers yields creation of virtual routers yields flexibilityflexibility

A C

B

D

E

F

MN

O P

Q

R

S

T

G

H

I

JK

L

12

3

4

5

Center Point

Border Router

Router

On-tree Link

Domain Boundary

Structure of multicast routing tree created by HIP

F

N

Q

I

A C

B

D

E

F

M

NO P

Q

R

S

T

G

H

I

JK

L

12

3

4

5SB-6

SB-5

SB-2

SB-1

SB-3

SB-4

Center Point

Trusted Router

Untrusted Router

Outline of routers making up sub-branch

Secure sub-branches on the Secure sub-branches on the HIP treeHIP tree

Design goals of Keyed HIPDesign goals of Keyed HIP

• Creates a authentication service to issue Creates a authentication service to issue certificates to hostscertificates to hosts

• Certificates are used to construct the Certificates are used to construct the Multicast treeMulticast tree

• Prevent or minimize the replay and flooding Prevent or minimize the replay and flooding attacks of trusted members with the use of attacks of trusted members with the use of certificatescertificates

• Re-processing (decrypting and re-encrypting) Re-processing (decrypting and re-encrypting) should be less expensiveshould be less expensive

Structure of Secure Keyed HIP Structure of Secure Keyed HIP TreeTree

A

B

C

P

Q T

S

F 5

E H

L

SB-1

SB-3

SB-2SB-5

SB-4

Center Point

Trusted Router

Trusted Virtual Router

Path from trusted core to Trusted Router

Elements of secure multicast Elements of secure multicast treetree Notation of GNY Logic (Gong, Needham and Notation of GNY Logic (Gong, Needham and Yahalom)Yahalom)

• Communication Entities for the multicast treeCommunication Entities for the multicast tree

• Authentication Service: Authentication Service: ASAS

• Center Point Location Service:Center Point Location Service: LSLS

• Group Initiator: Group Initiator: II

• Receivers of Multicast Group: Receivers of Multicast Group: RR

• Roots of sub-branches: Roots of sub-branches: C ,C , one of which will one of which will be the center point for the tree be the center point for the tree CPCP

Building the secure multicast Building the secure multicast treetree Notation of GNY Logic (Gong, Needham and Notation of GNY Logic (Gong, Needham and Yahalom)Yahalom)• Roots preside over sub-branches, Roots preside over sub-branches, BB made up of made up of

some number of receivers.some number of receivers.

• Any member of groupAny member of group MM contains public key, contains public key, KK+M +M and corresponding private key and corresponding private key KK– M – M ((authentication authentication

serviceservice))

• Entities Entities AA and and BB sharing a common key sharing a common key KKABAB

• Transmission of message between entities, Transmission of message between entities, AABB, with a message that is encrypted as , with a message that is encrypted as {message}K{message}KABAB

• Digitally-signed messages are as, Digitally-signed messages are as, [message][message]k-Mk-M

Certificate request from Certificate request from Authentication ServiceAuthentication Service

• Access Control List (ACL)Access Control List (ACL)

• Owning of public keyOwning of public key

• Certificate Request from authentication Certificate Request from authentication serviceservice

CERTCERTMM = [ = [IPIPMM, K, K+M+M, MC, Perm, TS, Life, MC, Perm, TS, Life]]KK––ASAS

Perm = {Create, Join, Destroy}Perm = {Create, Join, Destroy}

Time Stamp (TS) and Life should be shortTime Stamp (TS) and Life should be short

Authentication service and certificatesRequest for CERT

AuthenticationService

m e m b e r 1

Public Key

Public KeyIP Address

Multicast GroupPermissionsTime Stamp

Life

m e m b e r 1

4-Way Authentication Mechanism for Group Creation

• Some initiator, I must request and receive certificate from Authentication Service

I AS : [IPI ,K+I ,MC, Perm]K–I

• Permission would be set to Create, to the Authentication Service

• Verification of message contained within the initiator request

1

4-Way Authentication Mechanism for Group Creation

• Authentication Service would provide the certificate CERTI

AS I :

CERTI = [IPI ,K+I ,MC, Perm, TS, Life]K–AS

• Initiator I would send the message to the Location Service

2

4-Way Authentication Mechanism for Group Creation

• Announcement of the Start of the group by the Location Service, LS

I LS :

[Create, CERTI , CP, Scope, Lifetime]K–I

• Center Point would serve as the root of the multicast tree and Scope would be the domain of the group

3

4-Way Authentication Mechanism for Group Creation

• Announcement of the Start of the group by the Location Service, LS

CP AS :

[IPCP , K+CP , MC, Perm]K–CP

AS CP :

CERTCP = [IPCP ,K+CP , MC, Perm, TS,Life]K–CP

4

4-Way Authentication 4-Way Authentication Mechanism for Group CreationMechanism for Group Creation

AuthenticationService

Initiatorrequest1

2

Initiators’ Certificate

4LocationService

3

CenterPoint

Host to router communicationHost to router communication

• For secure multicast, a secure version of For secure multicast, a secure version of the IGMP needs to be developed.the IGMP needs to be developed.

• A host could then authenticate with its A host could then authenticate with its router using the 4-way authentication router using the 4-way authentication mechanismmechanism

• Host to router connection would simply Host to router connection would simply be the connection to the leaves of the be the connection to the leaves of the secure multicast treesecure multicast tree

Tree construction-secure Tree construction-secure OCBTOCBT

• Types of control messages for OCBTTypes of control messages for OCBT

• Join Request: Join Request: JRJR

• Join Acknowledgment: Join Acknowledgment: JAJA

• Quit Notice: Quit Notice: QNQN

• Flush: Flush: FLFL

Tree construction-secure OCBT

• JR and JA are used to instantiate a branch of the multicast tree between trusted receivers

• QN and FL are used to tear down branches of a tree– After a link or router failure or– Break a lower-level tree branch to allow a

higher-level branch to form

Tree construction-secure OCBT

• Digital Signatures are added to JR and JA– to prevent branches from being built to

unauthorized receivers

• Location of the trusted core is unknown

• Messages called Core Request (CR) and Core Acknowledgement (CA) are signed by each party-tree level

Tree construction-secure Tree construction-secure OCBTOCBTSteps for performing a JRSteps for performing a JR• Receiver would send a Core Request, its Receiver would send a Core Request, its

CERTCERTRR and a random nonce to its core and a random nonce to its core

R R C C : :

[[CRCR, , CERTCERTR R , N, NR R ]]KK––RR

• A A nonce nonce is a one-time unique message is a one-time unique message numbernumber– to prevent to prevent replayreplay attacks (to be discussed attacks (to be discussed

later)later)

Tree construction-secure OCBT Steps for performing a JR

• If passed, the CA is sent directly to the initiating receiver and is signed by the core. Core’s CERTC and new nonce NC

C R :

[CA, CERTC , NR , NC ]K–C

• Join Request is sent hop-by-hop to the trusted core

R C : [JR, CERTR , NC ]K–R

• Branch ID(unique to trusted receiver serviced by the particular core), starting SEQ for data

C R :

[JA, CERTC , NR , {KB, ID, SEQ}K+R ]K–C

To prevent replay attack of other join acks, the receiver would check for validations.

Tree construction-secure Tree construction-secure OCBT OCBT

Creation of BranchCreation of Branch

CP

R

JR

JA

Structure of Secure Keyed HIP Structure of Secure Keyed HIP TreeTree

A

B

C

P

Q T

S

F 5

E H

L

SB-1

SB-3

SB-2SB-5

SB-4

Center Point

Trusted Router

Trusted Virtual Router

Path from trusted core to Trusted Router

DATA

C

KB

KRand

Random Encrypted Key

Packet consisting of encrypted data

Sender

Data Flow within Secure TreeData Flow within Secure Tree

ID SEQ CS

C

Sub-branch (parent)

Flow of Encrypted Data Flow of Encrypted Data

• Transmission of data from sender to its Transmission of data from sender to its sub-branchsub-branch

R R B B : :

{{DataData}}KKRandRand , ,

{{KKRand Rand , ID, SEQ , CS , ID, SEQ , CS (({{DataData}}KKRandRand )})}KKBB

• Checksum supports avoiding attacks Checksum supports avoiding attacks such as such as cut-and-pastecut-and-paste

Flow of Encrypted DataVerification of Sender

• Sender would include its IP address and would digitally sign the data

R B :

{[Data]K–R , IPR}KRand ,

{KRand , ID, SEQ , CS ({Data, IPR}KRand )}KB

• Receiver could lookup at the origin of data and use its public key to verify

Re-keying Mechanism for Re-keying Mechanism for Leaving from the Multicast Leaving from the Multicast GroupGroup• Sub-branch key Sub-branch key KKBB would need to be would need to be

changedchanged

• Occasionally restart the sequence Occasionally restart the sequence numbers used as noncesnumbers used as nonces

C C B B : :

[[IPIPR1R1,,{{KKBNewBNew, K, KBOldBOld, SEQ, SEQ}}K+R1 K+R1 ]]KK––C ,C ,

[[IPIPR2R2,,{{KKBNewBNew, K, KBOldBOld, SEQ, SEQ}}K+R2 K+R2 ]]KK––C , …...C , …...

Re-keying Mechanism for Re-keying Mechanism for Leaving from the Multicast Leaving from the Multicast GroupGroup

• Old encryption key and nonce Old encryption key and nonce sequence would remain valid for sequence would remain valid for short period to allow messages in short period to allow messages in transit that are encrypted in the old transit that are encrypted in the old key to be accepted when they key to be accepted when they arrive . arrive .

Maintenance of Secure Maintenance of Secure Multicast Tree Multicast Tree

• Within OCBT, failure of Child/Parent and Within OCBT, failure of Child/Parent and rejoining using rejoining using FlushFlush and and QuitQuit notice notice

• Retain good Communication between Retain good Communication between trusted and untrusted routerstrusted and untrusted routers

• To limit effects of attacks, each sub-To limit effects of attacks, each sub-branch must periodically by destroyed branch must periodically by destroyed and re-constructed by the trusted and re-constructed by the trusted core sending a flush message to all its core sending a flush message to all its childrenchildren

Denial-of-service (DOS) Denial-of-service (DOS) attacks and attacks by attacks and attacks by untrusted routersuntrusted routers• KHIP limits effect of Flooding Attacks byKHIP limits effect of Flooding Attacks by

– limiting spread of brancheslimiting spread of branches

– verification of encrypted verification of encrypted SEQSEQ numbers and numbers and IDID enclosed within each data packet enclosed within each data packet

• Detection of attacksDetection of attacks– carried out by miss-match in the signaturecarried out by miss-match in the signature

ConclusionConclusion

• KHIP meets the security requirements (AAI) KHIP meets the security requirements (AAI) at the network levelat the network level

• Provides simple mechanism for distributing Provides simple mechanism for distributing encrypted keys, while little overhead on HIPencrypted keys, while little overhead on HIP

• Supports heterogeneous multicast routing Supports heterogeneous multicast routing protocols, unlike DVMRP or PIMprotocols, unlike DVMRP or PIM

• Protects the routing infrastructure against Protects the routing infrastructure against unauthorized sendersunauthorized senders

ReferencesReferences

• KHIP Scalable Protocol for Secure Multicast Routing: Clay Shields, J.J. Garcia-Luna-AcevesKHIP Scalable Protocol for Secure Multicast Routing: Clay Shields, J.J. Garcia-Luna-Aceves

• The HIP Protocol for Hierarchical Multicast Routing: Clay Shields, J.J. Garcia-Luna-AcevesThe HIP Protocol for Hierarchical Multicast Routing: Clay Shields, J.J. Garcia-Luna-Aceves

• Secure Hierarchical Multicast Routing and Multicast Internet Anonymity: Clay ShieldsSecure Hierarchical Multicast Routing and Multicast Internet Anonymity: Clay Shields

• The Ordered Core Based Tree Protocol: Clay Shields, JJ Garcia-Luna-AcevesThe Ordered Core Based Tree Protocol: Clay Shields, JJ Garcia-Luna-Aceves

• A Secure multicast protocol with copyright Protection: Hao-hua Chu, Lintian Qiao, Klara A Secure multicast protocol with copyright Protection: Hao-hua Chu, Lintian Qiao, Klara NahrstedtNahrstedt

• Core Based Trees(CBT), An Architecture for Scalable Inter-Domain Multicast Routing: Tony Core Based Trees(CBT), An Architecture for Scalable Inter-Domain Multicast Routing: Tony Ballardie, London; Paul Francis, Bellcore; Jon Crowcroft, LondonBallardie, London; Paul Francis, Bellcore; Jon Crowcroft, London

• Scalable Internet Multicast Routing: M. Parsa, J.J. Garcia-Luna-AcevesScalable Internet Multicast Routing: M. Parsa, J.J. Garcia-Luna-Aceves

• http://www.ipmulticast.com/community/smug; http://www.ipmulticast.com/community/smug; Ran Canetti, IBM ResearchRan Canetti, IBM Research

• http://www.stratacom.com/warp/public/732/multicast/literature.shtml. Cisco Systemshttp://www.stratacom.com/warp/public/732/multicast/literature.shtml. Cisco Systems

• http://www-mash.cs.berkeley.edu/. Berkeleyhttp://www-mash.cs.berkeley.edu/. Berkeley

• http://www.cs.ucl.ac.uk/staff/j.crowcroft/ UCL Network Research Group, Jon Crowcrofthttp://www.cs.ucl.ac.uk/staff/j.crowcroft/ UCL Network Research Group, Jon Crowcroft

• http://www.mbone.comhttp://www.mbone.com

• A scalable Framework for Secure Multicast: Sreedhar Mukkamalla, Randy H. Katz, U.C. A scalable Framework for Secure Multicast: Sreedhar Mukkamalla, Randy H. Katz, U.C. BerkeleyBerkeley

• Secure Group Communications Using Key Graphs: C.K. Wong, M. Gouda, S.S. LamSecure Group Communications Using Key Graphs: C.K. Wong, M. Gouda, S.S. Lam

• Iolus: A Framework for Scalable Secure Multicasting: S. MittraIolus: A Framework for Scalable Secure Multicasting: S. Mittra