Multicast Security: Towards a Standardized Solution Ran Canetti - - PowerPoint PPT Presentation

Multicast Security: Towards a Standardized Solution

Ran Canetti IBM Research

In this talk:

• A taxonomy of multicast security issues
• Some outstanding algorithmic problems
• Work at the SMuG (IRTF):

– Some design principles – Overall architecture – IPSec-based host architecture

(draft proposal)

Multicast communication:

Whenever there are multiple recipients

• Typical applications:

– File and software updates – News-feeds – Video/audio broadcasts – Virtual conferences, town-hall meetings – Multiparty video games

Multicast group characteristics

• Number of sources, receivers
• Membership dynamics
• Bandwidth and latency requirements
• Duration
• Physical separation

(network topology and political separation)

Security requirements

• Limiting access to group communication:

– Long-term secrecy – Ephemeral access restriction

• Authentication:

– Group – Source

• Anonymity
• Availability (against denial of service attacks)

Trust issues

• Trust in centralized group manager

– To generate keys properly – To distribute keys properly Ways to reduce trust requirements:

• Distribute center’s tasks
• Use hierarchic control structure
• Trust in group members

– To not impersonate other group members – To not re-distribute keys

Performance parameters of security solutions

• Time to verify and decrypt data
• Time to authenticate and encrypt data
• Communication bandwidth overhead
• Key set-up and refreshment overhead
• Group set-up and member enrollment time

An outstanding problem: Source authentication

• MACing with shared key is not enough
• Signing every data packet is unrealistic
• Possible solutions:

– Sign every nth packet (and hash in between) [GR, R, WL, …] – MAC with multiple keys (Receivers have different subsets of keys) [CGIMNP]

An outstanding problem: Membership revocation

• To hide future communication from a

leaving member, need to change group key.

• How to send new group key to everyone

except the leaving member?

– Can use a data structure that gives O(log n) communication (and O(n) memory for center) [WHA, WGL]. – Is it possible to do better?

(some improvements & bounds in [CGIMNP,CMN])

Wallner’s tree

k k0 k00 k001

Work done at Secure Multicast Group (SMuG)

• f the

Internet Research Task Force (IRTF)

http://ipmulticast.com/community/smug

A first-cut scenario:

• One-to-many communication
• Medium to large groups (10-100K)
• Centralized group management
• No trust in group members
• Need source authentication,

ephemeral encryption

• Dynamic membership

A basic design principle:

• Divorce security from the routing method.

This implies:

– Data packets are routed without change (e.g., using any IP multicast, reliable multicast,

• r even TCP)

– All crypto is done at endpoints (No re-encryption of data en-route!) – Possible exceptions: Firewalls, political barriers

More design guidelines

• Separate key management from data

handling

• Use existing components when possible

(SSL, IPSec)

• Minimize changes to OS kernel
• Maintain ability to plug-in different crypto

algorithms

Global architecture (I):

Control communication Data communication

Global architecture (II):

Control communication Data communication

IPSec-based host architecture

(proposal developed at IBM Research)

Control API Data API Multicast Internet Key Exchange Source Authentication Module AH/ESP (IPSEC) Multicast Secu- rity Association Line

(group controller)

Line

(group members) OS kernel

• App. space

Control API Data API Multicast Internet Key Exchange Source Authentication Module AH/ESP (IPSEC) Multicast Secu- rity Association Line Line

OS kernel

• App. space

IPSEC transforms (AH/ESP):

• Data encryption with group key
• Group authentication with group key
• Operates on individual packets (No state across packets)

Control API Data API Multicast Internet Key Exchange Source Authentication Module AH/ESP (IPSEC) Multicast Secu- rity Association Line Line

OS kernel

• App. space

SAM Signing data efficiently requires:

• Signing data in large chunks
• Keeping state across packets

Therefore, SAM is in transport layer (UDP),

• perates on UDP frames.

Control API Data API Multicast Internet Key Exchange Source Authentication Module AH/ESP (IPSEC) Multicast Secu- rity Association Line Line

OS kernel

• App. space

MSA is a database that holds:

• IPSEC SA for AH/ESP (group key, algorithms, group address, etc.)
• Information for SAM (Signing/verification keys, algorithms, etc.)
• MSA is periodically updated by MIKE.

Control API Data API Multicast Internet Key Exchange Source Authentication Module AH/ESP (IPSEC) Multicast Secu- rity Association Line Line

OS kernel

• App. space

MIKE:

• Invoked by API to join/leave multicast group.

Join/leave interaction done via standard point-to-point secure connection (such as IPSec, SSL) with the center.

• Receives key updates from controller and updates MSA
• Key updates assume a “reliable multicast shim”

(Can be implemented by any RM protocol /TCP)

Conclusion

• Security is a central concern in almost any

multicast application on the Internet.

• Have made initial steps towards designing a

standardized solution.

• Much more work to be done...