Towards Scalable and Reliable Secure Multicast

1. Towards Scalable and ReliableSecure Multicast Presenter: Yang Richard Yang Network Research Lab Department of Computer Sciences The University of Texas at Austin 11/02/2000 Project Director: Simon S. Lam Other Members: Steve Li, Xincheng Zhang Past member: C. K. Wong

2. What is a Group Key Management System? • Provide access control to the symmetric group key that is shared by all group members • Two types of access control services: • Backward access control: • Change the group key after a new user joins • Forward access control: • Change the group key after a member leaves Towards a Scalable and Reliable Group Key Management

3. Key Trees k1-9 k123 k456 k789 k1 k6 k2 k3 k4 k5 k7 k8 (changed to k1-8) {k1-8}k123 {k1-8}k456 {k1-8}k78 (changed to k78) {k78}k7 {k78}k8 k9 u2 u1 u3 u4 u5 u6 u7 u8 u9 [Wong et al. SIGCOMM ’98, Wallner et al. Internet Draft] Towards a Scalable and Reliable Group Key Management

4. leave join registration rekey encoding individual keys rekey transport Group Key Management System Components Towards a Scalable and Reliable Group Key Management

5. Registration Component encoding transport Reg. • Issue: authentication can have large overhead • Solution: allow multiple registrars in our Keystone prototype Towards a Scalable and Reliable Group Key Management

6. Distributed Registrars Protocol new user c SSL registrar key Krclient lists SSL {IDc, Kc}Kr IDc, Kc TCP: {Join, IDc}Kc {Ack}Kc, {Keys}Kc TCP: {Leave, IDc}Kc {Ack}Kc, registrar key server Towards a Scalable and Reliable Group Key Management

7. Rekey Encoding Component transport encoding Reg. • Issue: rekey for each request in real-time may not be desired • Rekey for each request is not efficient • Rekey in real-time have out-of-sync problem • Solution: use periodic batch rekeying • Periodic batch rekeying provides tradeoffs between performance and how effective group access control is Towards a Scalable and Reliable Group Key Management

8. Periodic Batch Encoding Algorithm • Assume J joins and L leaves in a batch • If J = L, replace each departed user by a new user • If J < L, replace departed users from the left to right • If J > L, first replace departed users by joined users, then expand the tree Towards a Scalable and Reliable Group Key Management

9. Batch Encoding Performance Towards a Scalable and Reliable Group Key Management

10. Batch Encoding Performance Gains Towards a Scalable and Reliable Group Key Management

11. Rekey Transport Component encoding Reg. transport • Two Issues: • What is the workload? • What is the transport protocol? Towards a Scalable and Reliable Group Key Management

12. Rekey Transport Workload • Rekey messages have a sparseness property • Each receiver only needs to receive a fraction of the packets in a rekey message • The number of packets each receiver needs to receive depends on how encrypted keys are assigned to packets Towards a Scalable and Reliable Group Key Management

13. DFS vs BFS Packet Assignment Algorithm Towards a Scalable and Reliable Group Key Management

14. Histogram Towards a Scalable and Reliable Group Key Management

15. Rekey Transport Protocol • Rekey transport protocol design needs to consider two factors: • It is desired that rekey message is delivered before next rekey interval • Proactive FEC • Inter-dependency requires eventual reliability • User send re-synchronization at the end of rekey interval Towards a Scalable and Reliable Group Key Management

16. How to Determine Proactivity Factor? Towards a Scalable and Reliable Group Key Management

17. Two Remaining Questions encoding Reg. transport • Questions: • How to determine the rekey interval T? • How to determine the number of users a key server can support? • These answers to these questions will be tradeoff decisions Towards a Scalable and Reliable Group Key Management

18. Bandwidth Requirement vs Rekey Interval Towards a Scalable and Reliable Group Key Management

19. Determine System Parameters by Constraints • Two types of constraints: • Performance constraints give lower bounds on T • Upper bounds of key server and receiver bandwidth requirement • Rekey latency • System effectiveness constraints give upper bound on T: • E.g. T/m < 0.1, m is the mean time each user in the group • If the lower bounds < upper bound, choose the upper bound as T, otherwise, have to reduce the number of users in the group Towards a Scalable and Reliable Group Key Management

20. Extend to Distributed Key Servers • Objective: improve scalability and reliability • Issue: how to coordinate different groups? • Two distributed architectures: • Multiple key servers based on clock synchronization, larger virtual group • iolus agents with RMX like topology Towards a Scalable and Reliable Group Key Management

21. Conclusion • Investigated scalability and reliability issues of a single key server system • Registration: distributed registars • Rekey encoding: period batch processing • Rekey transport: proactive FEC + re-synchronization • Determine T and N by system constraints • Two distributed key server architectures to further improve scalability and reliability Towards a Scalable and Reliable Group Key Management