A survey of Key Management for Secure Group Communication Sandro - PowerPoint PPT Presentation

A survey of Key Management for Secure Group Communication Sandro Rafaeli and David Hutchison Presented By: Anil Bazaz CS6204, Spring 2005

Intro: Group Communication ♦ Uses IP multicast to transmit data ♦ Does not limit access to data ♦ No authentication or access control CS6204, Spring 2005

Intro: Basic Solution ♦ Encryption – Encryption using a group key – Selective Key Distribution ♦ Challenges – Rekeying Group Key with membership changes – Backward Secrecy – Forward Secrecy CS6204, Spring 2005

A simple scheme ♦ A secret key for all members ♦ Group key distributed using secret keys ♦ Problems: – Requires extensive computation – Size of message containing group key CS6204, Spring 2005

Categories of key management schemes ♦ Centralized key management protocols ♦ Decentralized key management protocols ♦ Distributed key management protocols CS6204, Spring 2005

Centralized Key Management ♦ Single Entity Controls the group (KDC) ♦ Single point of failure ♦ Scalability Issues ♦ Measuring Efficiency – Storage Requirements – Size of Messages – Backward & forward Secrecy – Collusion CS6204, Spring 2005

Logical Key Hierarchy CS6204, Spring 2005

Logical Key Hierarchy Join Operation Leave Operation CS6204, Spring 2005

Centralized Flat Table ♦ Table has one entry for TEK ♦ 2w entries for KEKs (w = No. of Bits in member ID) ♦ ID determines KEKs held by members CS6204, Spring 2005

Centralized flat table ♦ Rekeying: – {TEK new } unchanged KEKs – {KEKs new }KEKs old , TEK new ♦ Susceptible to collusion attacks CS6204, Spring 2005

Decentralized Architecture ♦ Large group split into smaller groups ♦ Controllers for subgroups ♦ More fault tolerant ♦ Measuring Efficiency – Key independence – Decentralized controller – Local Rekey – Key vs. Data – Backward & forward secrecy – Type of Communication (1 to n or n to n) CS6204, Spring 2005

Intra-Domain Group Key Management ♦ DKD: Domain Key Distributor ♦ AKD: Area Key Distributor ♦ Single key for everybody ♦ Single point of failure CS6204, Spring 2005

MARKS ♦ Applies to time lengths (TV transmission) ♦ Keys changed as function of time CS6204, Spring 2005

Distributed Key Management ♦ No group controller ♦ Group key generation: contributory or single member ♦ Evaluating efficiency – Number of rounds – Number of messages – Processing during setup – DH key CS6204, Spring 2005

Group Diffie-Hellman Key Exchange ♦ Group agrees on public Values q and α ♦ Upflow: – First member calculates α x1 , passes it along – Subsequent members receive set, raise it, pass it along – Example: • Fourth member receives set: { α x1 , α x1x2 , α x1x2x3 } • Sends set: { α x1 , α x1x2 , α x1x2x3 , α x1x2x3x4 } CS6204, Spring 2005

Group Diffie-Hellman Key Exchange ♦ Member n calculates key using : α x1x2x3…Xn mod q ♦ Downflow: – Each member calculates Key – Each member provides intermediate values to lower index members – Example (n = 5) • Fourth member recieves: { α x5 , α x1x5 , α x1x2x5 , α x1x2x3x5 } • Fourth member sends: { α x5x4 , α x1x5x4 , α x1x2x5x4 } CS6204, Spring 2005

Distributed Logical Key Hierarchy ♦ Key Hierarchy generated among members ♦ Subtrees agree on mutual key ♦ Left subtree: leader m l , key k L ♦ Right subtree: leader m r , key k R ♦ Protocol – m l chooses k LR , sends it to k R – m l encrypts k LR with k L sends it to subtree L – m r encrypts k LR with k r sends it to subtree R CS6204, Spring 2005

Distributed Logical Key Hierarchy CS6204, Spring 2005

Conclusion ♦ Lots of schemes for key management ♦ Centralized: – Simplest and easiest – Single point of failure, scalability ♦ Decentralized: – Relatively harder – Interfering with data paths ♦ Distributed – Not scalable – Not fault tolerant CS6204, Spring 2005