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(dlog d (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

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