Secure Multicast

Xun Kang

Content

• Why need secure Multicast?

• Secure Group Communications Using Key Graphs

• Batch Update of Key Trees

• Reliable Group Rekeying

• Group key management in n-to-n multicast

• Recent progress in wired and wireless networks

• Other related issues

Unicast to Multicast

• What is Multicast?• Currently, unicast is dominant, while the

requirement for IP multicast is increasing– Audio and video distribution– Push application– Tele conferencing– Group collaboration applications– Some file transfer applications

Obstacles for Deployment

• Scalability: group management

• Group Management

• Security (why?)

• Address Allocation

• Network Management

• Billing Multicast Service

What to protect?

• Group management: – Authorization for group creation– Receiver authorization– Sender authorization

• Security: – Protection against attacks on multicast routes and

sessions – Support for data integrity mechanisms

Factors affect Design of Security

• Multicast Application Type:– (1to n) or (n to n)– Confidentiality, or source-authentication– Frequency and rate of data transmission

• Group Size and Group Dynamics– Affect the scalability of security– Join/leave– Nodes distribution

• Trust Model

Secure Group Communications Using Key Graphs

• Center point is GM and GKM– Scalability– Independence– Reliability– Security

Basic Design of SGC• Assume that the S(ource) is trusted• Each node shares a secret individual key with S• A shared key used for the whole group

Source

Shortcoming of one Group Key

• When updating key, requires n messages encrypted with individual keys

• While it must be updated frequently:– Group session is longer than peer session– Forward access control: Leave– Backward access control: Join

Solution: A hierarchy of keys

• A full and balanced d-ary tree (directed) kept on server• For each user, a directed path to the root

– The root key is shared by the whole group– The leave key belongs to an individual user– Some intermediate keys shared by a subgroup of users

• Server needs to perform O(dlogd(n)) encryption

Some terms using Key Graph

Extend to U’ and K’:• keyset(U’)• userset(K’)

•For (U, K, R), and a subset S of U, find a minimum size subset K’ of K, such that userset(K’)=S

Key Graph Types• Star• Tree

– Height h

– Degree d

• Complete– Each combination of users has at least a key

Rekeying Strategies - Star KG

• Joining or leaving a star key graph

Join: Leaving:

Rekeying Strategies - tree KG

Rekeying Strategies - tree KG• Joining: User-oriented rekeying

– For each user, creates a rekey msg that contains all needed

• This approach needs h rekey messages. • The encryption cost for the server is:

– 1+2+…+(h-1)+(h-1) = h(h+1)/2-1

Rekeying Strategies - tree KG• Joining: Key-oriented rekeying

– Each new key is encrypted individually.– A user may have to get multiple rekey messages.

• This approach needs 2(h-1) rekey messages. • The encryption cost for the server is:

– 2(h-1)

Rekeying Strategies - tree KG• Joining: Group-oriented rekeying

– Construct a single rekey message containing all new keys.– Do we need to consider whether the message will be too large? What is

the size of the msg?

• This approach needs 2 rekey messages. • The encryption cost for the server is:

– 2(h-1)

What’s the advantage of group-based over other two kinds?

Rekeying Strategies - tree KG• Leaving: User-oriented rekeying

– For each user, creates a rekey msg that contains all needed

• This approach needs (d-1)(h-1) rekey messages. • The encryption cost for the server is:

– (d-1)(1+2+…+(h-1)) = (d-1)h(h-11)/2

Rekeying Strategies - tree KG• Leaving: Key-oriented rekeying

– Each new key is encrypted individually.– A user may have to get multiple rekey messages.

• This approach needs (d-1)(h-1) rekey messages. • The encryption cost for the server is:

– d(h-1)

Rekeying Strategies - tree KG• Leaving: Group-oriented rekeying

– Construct a single rekey message containing all new keys.

• This approach needs 1 rekey messages. • The encryption cost for the server is:

– d(h-1)

Encryption cost

How to Sign Rekey Messages

• Use Merkle hash tree– Root of the tree is the hash of all msgs– Leaves are the hash for each individual msg– Root is signed by the Server– For each rekey msg, the server will combine it with a

path to the root of the tree

Performance conclusion

• Server side, group-oriented rekeying is the best, then key-oriented, then user-oriented;

• Client side, exactly reversed;• Optimal key tree degree is around four? For

certain number of node, or for all?• If large number of clients are slow, then

group-oriented rekeying is not good;

Batch Updates of Key Trees

• Any problem in previous solution?– Synchronization problems among rekey msgs

and between rekey and data msgs; How?– Individual rekeying can be inefficient;

especially when join/leave happens frequently, there will be a huge burden on server for signing keys;

Periodic batch rekeying• Rekey subtree;• Collect requests during a rekey interval and

rekey them in a batch;

• Advantage:– For a J join and L leave, only needs 1 signing;– Less number of encrypted keys;

• Disadvantage:– Delayed group access control;

• A balance between rekeying overhead and group access control, the degree of forward access control vulnerability.

Three ways of Batch Rekeying

• Periodic batch rekeying;

• Periodic bath leave rekeying;

• Periodic bath join rekeying;

• Question:– What’s the advantage and disadvantage of each

one? Which one is better?

Batch Rekeying Algorithm

• Strategy 1: always keep a balanced tree

Batch Rekeying Algorithm

• Strategy 2– New nodes form a subtree – Grafted to a departed node with smallest height?

• Strategy 3– ?

Reliable rekey protocol

• Eventual reliability– A receiver should receive all needed keys;

• Soft real-time requirement– A rekey msg is finished before the start of the

next rekey interval

• Solution– Send re-synchronization requests when cannot

recover a rekey msg in time;– Proactive FEC for reducing recovery latency;

Proactive FEC• Partition rekey msgs into blocks• Generate (p-1)k PARITY packets (FEC) for

each block

Conclusion