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 n th 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 k 0 k 00 k 001

Work done at Secure Multicast Group (SMuG) • of 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, or 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 Source Authentication Key Exchange Module Multicast Secu- App. space rity Association OS kernel AH/ESP (IPSEC) Line Line (group controller) (group members)

Control API Data API Multicast Internet Source Authentication Key Exchange Module Multicast Secu- App. space rity Association OS kernel AH/ESP (IPSEC) Line Line 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 Source Authentication Key Exchange Module Multicast Secu- App. space rity Association OS kernel AH/ESP (IPSEC) Line Line SAM Signing data efficiently requires: -Signing data in large chunks -Keeping state across packets Therefore, SAM is in transport layer (UDP), operates on UDP frames.

Control API Data API Multicast Internet Source Authentication Key Exchange Module Multicast Secu- App. space rity Association OS kernel AH/ESP (IPSEC) Line Line 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 Source Authentication Key Exchange Module Multicast Secu- App. space rity Association OS kernel AH/ESP (IPSEC) Line Line 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...