Secure Multicast
Presented by:
Adam J. Rosen and Ram Goverdhana
CSE620, 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
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
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.)
• P2 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 P8 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 P0,P1,P2
• Use key (1.1) to encrypt key (2.0’)
– Multicast to P3,P4,P5
Re-keying (cont.)
• Use key (1.2’) to encrypt key (2.0’)
– Multicast to P6,P7
• Send key (1.2’) to P6 and P7 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
Q
M
C
A
2
N
P
O
3
S
R
T
B
D
F
G
E
H
Center Point
4
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
F
G
Trusted Router
I
SB-6
E
SB-2
Center Point
4
H
5
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
Center Point
S
Trusted Router
SB-3
C
A
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B,
with 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
Center Point
S
Trusted Router
SB-3
C
A
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
Packet consisting
of encrypted data
Sub-branch
(parent)
DATA
C
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:
[IPR1,{KBNew, KBOld, SEQ}K+R1 ]K–C ,
[IPR2,{KBNew, KBOld, SEQ}K+R2 ]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.ipmulticast.com/community/smug; Ran Canetti, IBM Research
•
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