1. Towards Scalable and Reliable Secure 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. 11/02/2000Towards a Scalable and Reliable Group Key Management2 What is a Group Key Management System? Provide access control to the symmetric group key that is shared by all group membersProvide access control to the symmetric group key that is shared by all group members Two types of access control services:Two types of access control services: q Backward access control: Change the group key after a new user joins Change the group key after a new user joins q Forward access control: Change the group key after a member leaves Change the group key after a member leaves

3. 11/02/2000Towards a Scalable and Reliable Group Key Management3 Key Trees k1-9 k123k456k1k789k2k3k4k5k6k7k8 u2 u3u4u5u6u7u8u9u1 k9 (changed to k78) (changed to k1-8) [Wong et al. SIGCOMM ’98, Wallner et al. Internet Draft] {k78} k7 {k78} k8 {k1-8} k123 {k1-8} k456 {k1-8} k78

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

5. 11/02/2000Towards a Scalable and Reliable Group Key Management5 Registration Component Issue: authentication can have large overheadIssue: authentication can have large overhead Solution: allow multiple registrars in our Keystone prototypeSolution: allow multiple registrars in our Keystone prototype encodingtransport Reg.

6. 11/02/2000Towards a Scalable and Reliable Group Key Management6 Distributed Registrars Protocol registrarkey server SSL registrar key Kr client lists new user c IDc, Kc SSL {IDc, Kc}Kr TCP: {Join, IDc}Kc {Ack}Kc, {Keys}Kc TCP: {Leave, IDc}Kc {Ack}Kc,

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

8. 11/02/2000Towards a Scalable and Reliable Group Key Management8 Periodic Batch Encoding Algorithm Assume J joins and L leaves in a batchAssume J joins and L leaves in a batch If J = L, replace each departed user by a new userIf J = L, replace each departed user by a new user If J < L, replace departed users from the left to rightIf J < L, replace departed users from the left to right If J > L, first replace departed users by joined users, then expand the treeIf J > L, first replace departed users by joined users, then expand the tree

9. 11/02/2000Towards a Scalable and Reliable Group Key Management9 Batch Encoding Performance

10. 11/02/2000Towards a Scalable and Reliable Group Key Management10 Batch Encoding Performance Gains

11. 11/02/2000Towards a Scalable and Reliable Group Key Management11 Rekey Transport Component Two Issues:Two Issues: q What is the workload? q What is the transport protocol? Reg. encoding transport

12. 11/02/2000Towards a Scalable and Reliable Group Key Management12 Rekey Transport Workload Rekey messages have a sparseness propertyRekey messages have a sparseness property q 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 packetsThe number of packets each receiver needs to receive depends on how encrypted keys are assigned to packets

13. 11/02/2000Towards a Scalable and Reliable Group Key Management13 DFS vs BFS Packet Assignment Algorithm

14. 11/02/2000Towards a Scalable and Reliable Group Key Management14 Histogram

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

16. 11/02/2000Towards a Scalable and Reliable Group Key Management16 How to Determine Proactivity Factor?

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

18. 11/02/2000Towards a Scalable and Reliable Group Key Management18 Bandwidth Requirement vs Rekey Interval

19. 11/02/2000Towards a Scalable and Reliable Group Key Management19 Determine System Parameters by Constraints Two types of constraints:Two types of constraints: q Performance constraints give lower bounds on T Upper bounds of key server and receiver bandwidth requirement Upper bounds of key server and receiver bandwidth requirement Rekey latency Rekey latency q System effectiveness constraints give upper bound on T: E.g. T/m < 0.1, m is the mean time each user in the group 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 groupIf the lower bounds < upper bound, choose the upper bound as T, otherwise, have to reduce the number of users in the group

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

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