Multicast Security

1. Multicast Security CS239 Advanced Network Security April 16th, 2003 Yuken Goto

2. Multicast(reference: CS118/Feb. 10th, 2000 Lecture notes by Professor Zhang/UCLA) • Transmits a packet to a group of receivers • When sending the same data to multiple receivers, multicast minimizes: • Link bandwidth consumption • Sender and router processing • Delivery delay

3. Multicast(reference: CS118/Feb. 10th, 2000 Lecture notes by Professor Zhang/UCLA) Multiple unicasts

4. Multicast(reference: CS118/Feb. 10th, 2000 Lecture notes by Professor Zhang/UCLA) Multicast

5. IP Multicast Addresses(reference: CS118/Feb. 10th, 2000 Lecture notes by Professor Zhang/UCLA) • Each group is identified by an IP address • Any group size • Sender sends a multicast packet in the same way as sending a unicast packet • Members of groups may be located anywhere in the Internet • Members can join and leave at will • Senders need not be members • Class D IP addresses: • 1110[28 bits group ID]

6. Multicast(reference: CS118/Feb. 10th, 2000 Lecture notes by Professor Zhang/UCLA) • Components of IP Multicast Architecture • Host-to-router protocol • IGMP(Internet group management protocol) • Multicast routing protocols • Various protocols

7. How IGMP Works(reference: CS118/Feb. 10th, 2000 Lecture notes by Professor Zhang/UCLA) • One router is elected the “querier” on each link • Querier periodically sends Membership Query message “Are you a member of any multicast?” to all-systems group (224.0.0.1) with TTL=1 • Hosts start random timers (0,10 sec) for each multicast group to which they belong

8. How IGMP Works(reference: CS118/Feb. 10th, 2000 Lecture notes by Professor Zhang/UCLA) • When host’s timer for group G expires, it sends a Membership Report to group G with TTL=1 • Other members of G hear the report, stop their timers • Routers do not need to know who all the members are, only that members exist

9. Multicast protocol • Nice to have these things for multicast • Scalable reliability • Flow control • Congestion control • Security • Individual authentication • Key revocation • Others

10. Characteristics of Multicast Group • Group size • 100? Several millions? • Membership dynamics • Static, known in advance? • Join only, or members are allowed to leave? • How frequently the group changes? • Lifetime of a group • Minutes, days or unbounded?

11. Characteristics of Multicast Group • Number and type of senders • Single sender, several or all? • Are non-members allowed to send data? • Member characteristics • Computing power • On-line at all time? • Volume and type of traffic

12. Basic Security Requirements • Secrecy (within the group) • Authenticity • Group authenticity • Individual authenticity • Anonymity • Non-repudiation • Access control • Usage amount (for billing) • Service availability

13. Performance • Latency and work overhead per sending/receiving data packets • Bandwidth overhead incurred by inflating the data packets via cryptographic transformations • Group Initialization • Member addition & deletion • Peak sign-on/sign-off times

14. Scenario 1single source broadcast • Very large number of recipients • Source = top-end machine • Maybe parallelized or split to several sources in different locations • Dynamic membership • High volume of sign-on/off at peak times • Need to prevent non-member from using the service (though no real secrecy requirement) • A leaving member must lose its ability to decrypt

15. Scenario 2virtual conference • Number of members may not be as large as broadcast scenario • Similar computational resources • Signing data packets may be prohibitively slow • Most, or all, members may wish to transmit data • Group is short-lived • Usually static membership • Authenticity of data and sender is crucial

16. Individual Authenticationsingle sender case recipient sender Subset of l keys Has l keys recipient Subset of l keys

17. Individual Authenticationsingle sender case Data l MACs sender • 1-bit MACs are computed from the data with l different keys • Efficient because the data is hashed to a short string before MACed • Efficient (in terms of both computation and communication overhead) because its only single bit per key Has l keys

18. Individual Authenticationsingle sender case recipient Subset of l keys Data l MACs recipient Subset of l keys

19. Individual Authenticationmultiple senders case Sender Global set of l keys Subset of l keys Data <l MACs recipient Recipient checks: (Sender’s set of keys)U(Recipient’s set of keys) Subset of l keys

20. User Revocation • When a user joins • All existing members receive a new key via secure multicast • The new user receives the new key via secure unicast connection • So that new user cannot access communication prior to its join • How about when user leaves?

21. User Revocation • Straightforward approach • Central server establishes secure unicast connection with every remaining member and passes the new group key • Divide and Conquer approach • Tree Based Scheme

22. User RevocationA Tree Based Scheme Group Key K User 0 has K, K0, K00 and K000. K1 K0 K00 K01 K10 K11 K000 User 0 K001 User 1 K010 User 2 K011 User 3 K100 User 4 K110 User 6 K111 User 7 K101 User 5

23. User RevocationA Tree Based Scheme New group key K’ User 0 is going to be removed Group Key K K1 K0 K00 K01 K10 K11 K000 User 0 K001 User 1 K010 User 2 K011 User 3 K100 User 4 K110 User 6 K111 User 7 K101 User 5

24. User RevocationA Tree Based Scheme • For User 4 through 7, we can use K1 to deliver new group key K’ • For User 2 and 3, we can use K01 to deliver K0’ • For User 1, we need to use K001 to deliver K00’ and K0’ • Now we can use K0 to deliver K’ to User 1 through 3 • Total 4 key deliveries instead of 7

25. The End