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

3
Key Trees

(changed to k1-8)
k1-8k123
k1-8k456
k1-8k78
(changed to k78)
k78k7
k78k8
k9
u2
u3
u4
u5
u6
u7
u8
u9
u1
Wong et al. SIGCOMM 98, Wallner et al. Internet
Draft
4
Group Key Management System Components
5
Registration Component
Reg.

• Issue authentication can have large overhead
• Solution allow multiple registrars in our
  Keystone prototype

6
Distributed Registrars Protocol
registrar
key server
7
Rekey Encoding Component
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

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 lt L, replace departed users from the left to
  right
• If J gt L, first replace departed users by joined
  users, then expand the tree

9
Batch Encoding Performance
10
Batch Encoding Performance Gains
11
Rekey Transport Component
Reg.
transport

• Two Issues
• What is the workload?
• What is the transport protocol?

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

13
DFS vs BFS Packet Assignment Algorithm
14
Histogram
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

16
How to Determine Proactivity Factor?
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

18
Bandwidth Requirement vs Rekey Interval
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 lt 0.1, m is the mean time each user in
  the group
• If the lower bounds lt upper bound, choose the
  upper bound as T, otherwise, have to reduce the
  number of users in the group

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

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