Towards Scalable and Reliable Secure Multicast Presenter: Yang Richard Yang Network Research Lab Department of Computer Sciences The University of Texas

Towards Scalable and ReliableTowards Scalable and ReliableSecure MulticastSecure Multicast

Presenter: Yang Richard YangPresenter: Yang Richard Yang

Network Research LabNetwork Research Lab

Department of Computer SciencesDepartment of Computer Sciences

The University of Texas at AustinThe University of Texas at Austin

11/02/200011/02/2000

Project Director: Simon S. LamProject Director: Simon S. Lam

Other Members: Steve Li, Xincheng ZhangOther Members: Steve Li, Xincheng Zhang

Past member: C. K. WongPast member: C. K. Wong

11/02/2000 Towards a Scalable and Reliable Group Key Management 2

What is a Group What is a Group Key Management System?Key Management System?

• Provide access control to the symmetric Provide access control to the symmetric

group key that is shared by all group group key that is shared by all group

membersmembers

• Two types of access control services:Two types of access control services: Backward access control:Backward access control:

•Change the group key after a new user joinsChange the group key after a new user joins

Forward access control: Forward access control:

•Change the group key after a member leavesChange the group key after a member leaves


Key TreesKey Trees

k1-9

k123 k456

k1

k789

k2 k3 k4 k5 k6 k7 k8

u2 u3 u4 u5 u6 u7 u8 u9u1

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


Group Key Management System Components

registration

rekey encoding

rekey transport

individualkeys

join leave


Registration ComponentRegistration Component

• Issue: authentication can have large Issue: authentication can have large

overheadoverhead

• Solution: allow multiple registrars in our Solution: allow multiple registrars in our

Keystone prototype Keystone prototype

encoding

transport

Reg.


Distributed Registrars ProtocolDistributed Registrars Protocol

registrar key server

SSLregistrar 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,


Rekey Encoding ComponentRekey Encoding Component

• Issue: rekey for each request in real-Issue: rekey for each request in real-time may not be desiredtime may not be desired Rekey for each request is not efficientRekey for each request is not efficient Rekey in real-time have out-of-sync problemRekey in real-time have out-of-sync problem

• Solution: use periodic batch rekeyingSolution: use periodic batch rekeying

• Periodic batch rekeying provides Periodic batch rekeying provides tradeoffs between performance and tradeoffs between performance and how effective group access control is how effective group access control is

Reg.encoding

transport


Periodic Batch Encoding Periodic Batch Encoding AlgorithmAlgorithm

• 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 If J = L, replace each departed user by a

new usernew user

• If J < L, replace departed users from the If J < L, replace departed users from the

left to rightleft to right

• If J > L, first replace departed users by If J > L, first replace departed users by

joined users, then expand the tree joined users, then expand the tree


Batch Encoding PerformanceBatch Encoding Performance


Batch Encoding Performance Batch Encoding Performance GainsGains


Rekey Transport ComponentRekey Transport Component

• Two Issues: Two Issues: What is the workload?What is the workload?

What is the transport protocol?What is the transport protocol?

Reg.encoding

transport


Rekey Transport WorkloadRekey Transport Workload

• Rekey messages have a sparseness Rekey messages have a sparseness

propertyproperty Each receiver only needs to receive a Each receiver only needs to receive a

fraction of the packets in a rekey messagefraction of the packets in a rekey message

• The number of packets each receiver The number of packets each receiver

needs to receive depends on how needs to receive depends on how

encrypted keys are assigned to packetsencrypted keys are assigned to packets


DFS vs BFS Packet DFS vs BFS Packet Assignment AlgorithmAssignment Algorithm


HistogramHistogram


Rekey Transport ProtocolRekey Transport Protocol

• Rekey transport protocol design needs Rekey transport protocol design needs

to consider two factors:to consider two factors: It is desired that rekey message is delivered It is desired that rekey message is delivered

before next rekey intervalbefore next rekey interval

Proactive FECProactive FEC

Inter-dependency requires eventual Inter-dependency requires eventual

reliabilityreliability

User send re-synchronization at the end User send re-synchronization at the end

of rekey intervalof rekey interval


How to Determine Proactivity How to Determine Proactivity Factor?Factor?

0.00

0.50

1.00

1.50

2.00

2.50

3.00

1.00 1.10 1.20 1.50 1.60 1.70 1.80 2.00 2.50

Proactivity factor

ban

dw

idth

overh

ead

0.00

1.00

2.00

3.00

4.00

5.00

6.00

reco

very

late

ncy

bw overhead

Latency


Two Remaining QuestionsTwo Remaining Questions

• Questions:Questions: How to determine the rekey interval T?How to determine the rekey interval T?

How to determine the number of users a How to determine the number of users a

key server can support?key server can support?

• These answers to these questions will These answers to these questions will

be tradeoff decisionsbe tradeoff decisions

Reg.encoding

transport


Bandwidth Requirement vs Bandwidth Requirement vs Rekey IntervalRekey Interval


Determine System Parameters Determine System Parameters by Constraintsby Constraints

• Two types of constraints:Two types of constraints: Performance constraints give lower bounds on TPerformance constraints give lower bounds on T

• Upper bounds of key server and receiver bandwidth Upper bounds of key server and receiver bandwidth requirementrequirement

• Rekey latencyRekey latency System effectiveness constraints give upper bound on T:System effectiveness constraints give upper bound on T:

• E.g. T/m < 0.1, m is the mean time each user in the E.g. T/m < 0.1, m is the mean time each user in the groupgroup

• If the lower bounds < upper bound, choose the If the lower bounds < upper bound, choose the upper bound as T, otherwise, have to reduce the upper bound as T, otherwise, have to reduce the number of users in the groupnumber of users in the group


Extend to Distributed Key Extend to Distributed Key ServersServers

• Objective: improve scalability and Objective: improve scalability and

reliabilityreliability

• Issue: how to coordinate different Issue: how to coordinate different

groups?groups?

• Two distributed architectures:Two distributed architectures: Multiple key servers based on clock Multiple key servers based on clock

synchronization, larger virtual groupsynchronization, larger virtual group

iolus agents with RMX like topologyiolus agents with RMX like topology


ConclusionConclusion

• Investigated scalability and reliability issues of Investigated scalability and reliability issues of

a single key server systema single key server system Registration: distributed registarsRegistration: distributed registars

Rekey encoding: period batch processingRekey encoding: period batch processing

Rekey transport: proactive FEC + re-synchronizationRekey transport: proactive FEC + re-synchronization

• Determine T and N by system constraintsDetermine T and N by system constraints

• Two distributed key server architectures to Two distributed key server architectures to

further improve scalability and reliability further improve scalability and reliability

Documents

Towards Scalable and Reliable Secure Multicast Presenter: Yang Richard Yang Network Research Lab Department of Computer Sciences The University of Texas