Secure Multicast Presented by Adam J Rosen and

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

Introduction • In today’s inter-networked world, we are creating larger demand for broadcast type services over existing networks. • These new applications, which broadcast audio, video, and data, have their own security needs in order to maintain the benefits of multicast’s performance.

Overview • How does multicast security differ from unicast security? • What are the vulnerabilities of multicast? • Different methods of multicast security.

Multicast vs. Unicast • Simple schemes that emulate multicast by using secure unicast exist, but we lose the advantages of multicast routing • Must maintain security of transmission, while allowing users to join or leave the multicast session

Multicast vs. Unicast (cont. ) • New members into the session should not be able to decrypt earlier transmissions, nor should ex-members be able to decrypt later transmissions – We need a system of changing keys, while assuring ourselves that all legitimate members are able to transmit and receive to/from all other legitimate members

Example: A lawyers deposition… • A lawyer must be able to depose each witness individually • Each witness should not be able to find out what previous/later witnesses told the lawyer – Key must change every time someone enters/leaves the group

Vulnerabilities of Multicast • Multicast suffers from increased vulnerability due to: – Sessions are frequently advertised – Greater number of points of vulnerability – Attack affects a broader base of people – Attacker can pose as a legitimate user easier (larger “crowd” of principals)

What does ‘security’ need to provide? • Authentication – Verify the user is who he says he is • Authorization – Only admit those with proper authorization into the group • Integrity – Group members maintain privacy from those not in the group • System must be scalable

The Iolus Approach • A hierarchical approach to key distribution • Uses ‘Secure Agents’ to administer security • Users join separate local multicast groups

Network Security: Adding Multicast • Treat a multicast session as blocks of time • A new block begins when someone joins/leaves the group Alice joins ti ti+1 Carol joins ti+2 Bob leaves ti+3 Alice leaves

The Scalability Problem • “ 1 affects n” type failure – the actions of one member affects the entire group – i. e. creating a new source-based delivery tree rooted at the sender whenever a new sender joins the multicast group • “ 1 does not equal n” type failure – occurs when protocol cannot deal with the group as a whole and must consider the conflicting demands of members on an individual basis (i. e. flow control)

“ 1 affects n” Example in Multicast • If the entire group shares a single group key (Kgrp), a new key must be generated (K`grp) and distributed (may use Kgrp to distribute K`grp) when a new user joins the group • Joins exhibit a “ 1 affects n” scalability failure because they require all members to process the change in Kgrp when one new member joins

“ 1 does not equal n” Example • On leaves, we need to replace Kgrp with K`grp, but we cannot distribute using Kgrp • Under basic scheme, we need to unicast the new key to each user individually • Extremely inefficient in groups with large memberships or highly dynamic memberships

Additional Notes • We must insure that all receivers get a Kgrp update, or they will not be able to decrypt later communication, and may also accept communications from members that have been removed from the group • Senders failing to receive a Kgrp update will continue to encrypt using an outdated key, allowing former group members to decrypt their transmissions, while preventing legitimate users from decrypting

Additional Notes (cont. ) • If the underlying multicast system is unreliable (a reasonable assumption), we need additional processing will be required through the use of a reliable multicast protocol • In highly dynamic memberships, the probability of confusion and security breaches increase

The Iolus Framework • Remove the concept of a flat secure multicast group • Create a secure distribution tree composed of subgroups • Each subgroup has its own multicast group (with its own address) • Each group has its own subgroup keying material (Ksgrp ) • Only the local Ksgrp will need to be changed on

Two Entities of Iolus • Group Security Controller (GSCs) – Manages the top level subgroup • Group Security Intermediaries (GSIs) – Manage each of the subgroups • Collectively, we call GSCs and GSIs Group Security Agents (GSAs)

Iolus Structure Example

Functions of the GSAs • The GSC maintains control of the top-level subgroup at the root of the secure distribution tree – Ultimately responsible for the security of the group • GSIs are special trusted servers that are authorized to act as proxies of the GSC or their parent GSIs and control their local subgroup

GSIs • GSIs form a bridge between subgroups • They receive data multicast in their parent or child subgroups and re-multicast to their child or parent subgroups respectively • We will show that decryption and reencryption is not necessary

Startup • GSC is provided with an access control list (ACL), which is used to set the security policy concerning user access • GSIs and other members apply to join its subgroup

Joins • A sender or receiver locates its designated GSA and sends a JOIN request using a secure unicast channel. • GSA checks its database and decides whether to approve or deny request • GSA generates a secret key (KGSA-MBR) to be shared only with the new member • Stores secret key along with other relevant information in a private database

Joins (cont. ) • Sends KGSA-MBR to member using the secure channel • GSA multicasts a GRP_KEY_UPDATE message containing K`sgrp encrypted with Ksgrp to current multicast subgroup • Sends K`sgrp to the joining member using the separate secure channel • If the GSA is not currently part of the secure multicast group. It follows a similar procedure

$Joins (cont. ) • Example of a GRP_KEY_UPDATE message on a join HDR {KGRP’}KGRP$

Joins (cont. ) • Example of a GRP_KEY_UPDATE message on a join HDR {KGRP’}KGRP

Refreshes • Each JOIN has an expiration time associated with it • If the member wishes to remain in the group, it sends a REFRESH message • Grants ability to gracefully handle network partitions • Subgroups that have become partitioned from the top-level subgroup are implicitly removed from the group after some threshold of time

Leaves • Occur under two conditions – A member wishes to leave (sends a LEAVE request to the GSA) – GSA wishes to expel member (sends a notification to expelled member) • Ksgrp needs to be changed either way • GSA can still multicast K`sgrp to the remaining group members (instead of using several unicast messages)

Leaves (cont. ) • Multicast one message containing n copies of K`sgrp • Use separate KGSA-MBR to encrypt K`sgrp • Replaces O(n) separate messages with a single efficient message of size O(n)

Data Transmission • Having GSIs decrypt and re-encrypt data is too inefficient • Instead of encrypting message with Ksgrp, sender generates a one-time random key and encrypts data with this key • Encrypts key with Ksgrp and includes it in transmission • GSAs only need to decrypt and re-encrypt the random key, not the whole data packet

Data Transmission Example

Data Transmission (Alternative) • Sender unicasts message to GSA using KGSAMBR, GSA decrypts, re-encrypts with Ksgrp and signs packet, then multicasts to group and parent subgroup • Eliminates worry of senders having an outdated Ksgrp • Receivers have the assurance of GSAs signature to verify message is from a valid source

Data Transmission Comparison

Shutdown • GSC for secure multicast group shuts down after sending GRP_END notification to all members in the top-level subgroup • Any GSAs attached to top-level subgroup will then multicast the GRP_END message and then shutdown • Process proceeds similarly down the tree

Deployment Issues • GSAs can be placed in “natural” positions – Entry points at regional networks, local networks, subnets (etc. ) • Use “Dynamic Grouping” – When a specific GSA becomes overloaded, we can share membership with a newly started GSA

GSA Multicast Forwarding Performance • Approximately 450 micro-seconds delay introduced (due to cryptographic operations)

A Key Graph Based Approach • Hierarchy is logical, rather than physical • Key tree maintained by the Security Manager • No intermediary security nodes (such as GSIs in Iolus model)

Key Graph Example

Example (cont. ) • P 2 has three keys: – Key (2. 0) – Key (1. 0) – Key (0. 2) • Root key is shared by all, and used for group communication

Re-keying • When P 8 leaves key (2. 0) needs to be changed to key (2. 0’) and key (1. 2) needs to be changed to key (1. 2’) • Use key (1. 0) to encrypt key (2. 0’) – Multicast to P 0, P 1, P 2 • Use key (1. 1) to encrypt key (2. 0’) – Multicast to P 3, P 4, P 5

Re-keying (cont. ) • Use key (1. 2’) to encrypt key (2. 0’) – Multicast to P 6, P 7 • Send key (1. 2’) to P 6 and P 7 individually • To avoid sending a large number of messages, single message containing all these keys is multicast to the group • Size of the message is O(log N), where N is the number of members in the group

Security Manager • Responsible for authenticating participants, generating and distributing keys • Multicasts a heartbeat message to the group periodically • Heartbeat contains version number of the current session key – Version number is updated each time the session key is changed

Epochs • Time managed by security manager is divided into epochs for purposes of rekeying • All joins and leaves within a single epoch are aggregated • Allows for single rekey message for many joins/leaves instead of several separate ones transmitted at the beginning of next epoch • Also provides time to insure that all users receive the rekey message

Epochs (cont. ) • Actual use of new keys is delayed by 1 epoch • Avoids having to drop packets due to inability to decrypt them • Users joining group may have to wait up to 2 epochs before they can decrypt the data – To avoid this, SM acts as a reflector in a temporary multicast group of new members • Users leaving the group may be able to decrypt data for up to 2 epochs

Epochs (cont. ) • This ability to decrypt for up to 2 epochs after a leave is minimized if epochs are short intervals • Other users can take into account presence of ex-user for the extra time to avoid broadcasting sensitive data

Epochs Diagram • HB: X = Heartbeat RK: X = Rekey

Joining a Session • A participant authenticates themselves to the Security Manager (using SSL or similar technology) • Security Manager checks an ACL to decide whether or not to admit the participant • Participant is given its set of keys at the beginning of the next epoch • SSL connection is closed

Rekeying • Rekey messages are digitally signed and timestamped by the Security Manager to prevent forgery and replay attacks • Disseminates group information • Includes changes in group membership along with rekey messages – Optional, only for applications that require it

Scalability • Can use multiple Security Managers to increase scalability

Dependencies • Single point of failure (Security Manager) • Requires a reliable multicast protocol for key disemination

Secure Multicast Routing using Keyed Hierarchical Protocol (KHIP)

Introduction • Overview of Ordered Core Based Trees • Structure of HIP (Hierarchical Protocol) • Design goals of Keyed HIP • Elements of multicast tree • Construction of secure multicast tree • Tree Maintenance • Conclusion

Overview of Ordered Core Based Trees (OCBT) • Elimination of loops • Reconstructs tree with less traffic than CBT and does so correctly • Distribution of core points reduces the repair traffic and the distance within the logical level

Overview of HIP (Hierarchical Multicast Routing) • Use of Ordered Core Based Tree (OCBT) to route multicast data between heterogeneous multicast domains • Makes domains appear as a single virtual router within the higher level shared tree • Hard-state protocol and recursive creation of virtual routers yields flexibility

Structure of multicast routing tree created by HIP 1 M C A Q 2 N P O 3 S R T B D G E H Center Point 4 F Border Router I 5 Router J K On-tree Link L Domain Boundary

Secure sub-branches on the HIP tree SB-1 Q M 1 C A P O S R 2 N 3 T SB-4 B SB-3 D G E SB-2 H Center Point 4 F Trusted Router I 5 SB-6 J Untrusted Router K L SB-5 Outline of routers making up sub-branch

Design goals of Keyed HIP • Creates a authentication service to issue certificates to hosts • Certificates are used to construct the Multicast tree • Prevent or minimize the replay and flooding attacks of trusted members with the use of certificates • Re-processing (decrypting and re-encrypting) should be less expensive

Structure of Secure Keyed HIP Tree P SB-3 C A Center Point S Trusted Router SB-4 Q Trusted Virtual Router T Path from trusted core to Trusted Router SB-1 F B SB-2 5 SB-5 E H L

Elements of secure multicast tree Notation of GNY Logic (Gong, Needham and Yahalom) • Communication Entities for the multicast tree • Authentication Service: AS • Center Point Location Service: LS • Group Initiator: I • Receivers of Multicast Group: R • Roots of sub-branches: C , one of which will be the center point for the tree CP

Building the secure multicast tree Notation of GNY Logic (Gong, Needham and Yahalom) • Roots preside over sub-branches, B made up of some number of receivers. • Any member of group M contains public key, K+M and corresponding private key K– M (authentication service) • Entities A and B sharing a common key KAB • Transmission of message between entities, Aà , with B a message that is encrypted as {message}KAB • Digitally-signed messages are as, [message]k-M

Certificate request from Authentication Service • Access Control List (ACL) • Owning of public key • Certificate Request from authentication service CERTM = [IPM, K+M, MC, Perm, TS, Life]K–AS Perm = {Create, Join, Destroy} Time Stamp (TS) and Life should be short

Authentication service and certificates Authentication Service member 1 Public Key IP Address Multicast Group Permissions Time Stamp Life Request for CERT member 1 Public Key

4 -Way Authentication Mechanism for Group Creation • Some initiator, I must request and receive certificate from Authentication Service 1 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

4 -Way Authentication Mechanism for Group Creation • Authentication Service would provide the certificate CERTI 2 AS àI : CERTI = [IPI , K+I , MC, Perm, TS, Life]K–AS • Initiator I would send the message to the Location Service

4 -Way Authentication Mechanism for Group Creation • Announcement of the Start of the group by the Location Service, LS 3 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

4 -Way Authentication Mechanism for Group Creation • Announcement of the Start of the group by the Location Service, LS 4 CP àAS : [IPCP , K+CP , MC, Perm]K–CP AS àCP : CERTCP = [IPCP , K+CP , MC, Perm, TS, Life]K–CP

4 -Way Authentication Mechanism for Group Creation Authentication Service 1 request Initiators’ Certificate 2 4 Initiator 3 Center Point Location Service

Host to router communication • For secure multicast, a secure version of the IGMP needs to be developed. • A host could then authenticate with its router using the 4 -way authentication mechanism • Host to router connection would simply be the connection to the leaves of the secure multicast tree

Tree construction-secure OCBT • Types of control messages for OCBT • Join Request: JR • Join Acknowledgment: JA • Quit Notice: QN • Flush: FL

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 OCBT Steps for performing a JR • Receiver would send a Core Request, its CERTR and a random nonce to its core R àC : [CR, CERTR , NR ]K–R • A nonce is a one-time unique message number – to prevent replay attacks (to be discussed 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

Tree construction-secure OCBT 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.

Creation of Branch JR CP R JA

Structure of Secure Keyed HIP Tree P SB-3 C A Center Point S Trusted Router SB-4 Q Trusted Virtual Router T Path from trusted core to Trusted Router SB-1 F B SB-2 5 SB-5 E H L

Data Flow within Secure Tree Sub-branch (parent) C Packet consisting of encrypted data DATA Random Encrypted Key KRand KB ID SEQ CS Sender C

Flow of Encrypted Data • Transmission of data from sender to its subbranch R àB : {Data}KRand , {KRand , ID, SEQ , CS ({Data}KRand )}KB • Checksum supports avoiding attacks such as cut-and-paste

Flow of Encrypted Data Verification 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 Leaving from the Multicast Group • Sub-branch key KB would need to be changed • Occasionally restart the sequence numbers used as nonces C àB : [IPR 1, {KBNew, KBOld, SEQ}K+R 1 ]K–C , [IPR 2, {KBNew, KBOld, SEQ}K+R 2 ]K–C , …. . .

Re-keying Mechanism for Leaving from the Multicast Group • Old encryption key and nonce sequence would remain valid for short period to allow messages in transit that are encrypted in the old key to be accepted when they arrive.

Maintenance of Secure Multicast Tree • Within OCBT, failure of Child/Parent and rejoining using Flush and Quit notice • Retain good Communication between trusted and untrusted routers • To limit effects of attacks, each sub-branch must periodically by destroyed and reconstructed by the trusted core sending a flush message to all its children

Denial-of-service (DOS) attacks and attacks by untrusted routers • KHIP limits effect of Flooding Attacks by – limiting spread of branches – verification of encrypted SEQ numbers and ID enclosed within each data packet • Detection of attacks – carried out by miss-match in the signature

Conclusion • KHIP meets the security requirements (AAI) at the network level • Provides simple mechanism for distributing encrypted keys, while little overhead on HIP • Supports heterogeneous multicast routing protocols, unlike DVMRP or PIM • Protects the routing infrastructure against

References • KHIP 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-Aceves • Secure Hierarchical Multicast Routing and Multicast Internet Anonymity: Clay Shields • The Ordered Core Based Tree Protocol: Clay Shields, JJ Garcia-Luna-Aceves • A Secure multicast protocol with copyright Protection: Hao-hua Chu, Lintian Qiao, Klara Nahrstedt • Core Based Trees(CBT), An Architecture for Scalable Inter-Domain Multicast Routing: Tony Ballardie, London; Paul Francis, Bellcore; Jon Crowcroft, London • • Scalable Internet Multicast Routing: M. Parsa, J. J. Garcia-Luna-Aceves • http: //www. stratacom. com/warp/public/732/multicast/literature. shtml. Cisco Systems • http: //www-mash. cs. berkeley. edu/. Berkeley • http: //www. cs. ucl. ac. uk/staff/j. crowcroft/ UCL Network Research Group, Jon Crowcroft • http: //www. mbone. com • A scalable Framework for Secure Multicast: Sreedhar Mukkamalla, Randy H. Katz, U. C. Berkeley • Secure Group Communications Using Key Graphs: C. K. Wong, M. Gouda, S. S. Lam • Iolus: A Framework for Scalable Secure Multicasting: S. Mittra http: //www. ipmulticast. com/community/smug; Ran Canetti, IBM Research