260 likes | 391 Views
This outline provides an introduction to secure group communication, challenges in key management, existing approaches, and motivation for reliability enhancements. It discusses key areas like policy, key management, and data encryption and addresses issues in group key management research. It highlights existing approaches like GKMP, SMKD, GSAKMP, and Iolus, along with scalability concerns and performance analysis. The outline also covers Batch rekeying, careful key packaging methods, and the reliability requirements of group key management.
E N D
Secure Group Communication: Key Management by Robert Chirwa
Outline • Introduction: overview of Secure Group Communication • Key Management in Secure Group Communication: challenges • Existing approaches to key management • Motivation for reliability enhancements • Reliability solutions • Performance analysis of reliability
Introduction • Some group communication applications have security requirement • Example: Cable company broadcasting pay-per-view movies desires to broadcast/multicast a movie. Movie should be viewed by only paying customers not all multicast recipients • Solution: Sender and paying-customers share a secret (key). Sender encrypts movie packets and paying-customers decrypt. All other receivers are unable to decrypt.
Three problem areas • Policy: how is access to the group authorized and authenticated, how is an encryption scheme chosen • Key management: When should the group key be changed and how is a new shared group key distributed. A group key manager required. • Data traffic encryption: suitable encryption methods
Issues addressed in group key management research • Layer: At which layer should group key management be implemented: Network/Transport or Application? • Backward access control: should new members have access to old communication? • Forward access control: should members that have left have access to new communication? • Rekeying period: should the group key be changed? How often?
The big problem • One affects many: Mittra observed that group communication security has the property of all members being affected by the leaving, revocation, or joining of one member. Scalability is critical for large groups. Note that encryption/decryption has performance overhead.
Existing approaches • Group Key Management Protocol (GKMP) • Scalable Multicast Key Distribution (SMKD) • Group Secure Association Key Management Protocol (GSAKMP) • Iolus • Key hierarchy schemes: Key graphs, Binary key trees, Boolean key tree • Set difference
Group Key Management Protocol (GKMP) • Initially developed for military use with unicast communication • Commander chooses group key manager • Untrusted leaves, create new group • Keys have lifetime • Later modified for multicast: group key manager selected by voting • Group key manager generates group key encryption packets • Others generate group traffic encrypted packets
Scalable Multicast Key Distribution (SMKD) • Network layer secure multicast key management • Key management integrated in the Core Based Tree (CBT) multicast protocol • Each core node acts as a domain key manager • Scales but not multicast protocol independent
Iolus • The members of a secure group subdivided into subgroups • The overall group is managed by a group security controller (GSC) • Subgroups are managed by group security intermediaries (GSI) or group security agents (GSA) • A message traversing multiple groups will be decrypted and encrypted several times at each GSA.
Iolus Fig.1: The Iolus framework
Keygraphs • Secure group members allocated to subgroups. Subgroups may be subsets of larger subgroups • A key graph has group keys at internal nodes and user keys at leaves maintained by group controller • Each member is allocated all keys on the path from the root to the leaf • New key for a subgroup encrypted with all keys from root to the key node that has changed • Need only log(n) messages to rekey a group instead of n messages
Keygraph member leave example • u9 in lower tree leaves • Group controller creates new group key k1-8 • Group controller creates new subgroup key k78 and unicasts to u7 and u8 encrypted with individual keys
Keygraph member leave example(continued) • Group controller encrypts k1-8 with k456 and multicasts for u4, u5 and u6 • Group controller encrypts k1-8 with k123 and multicasts for u1, u2 and u3 • Group controller encrypts k1-8 with k78 and multicasts for u7 and u8 • Top tree in the figure results
Reliability requirements of group key management • If some members receive rekey messages late, they are unable to decrypt new messages OR they encrypt messages using old keys • Rekey messages workload has a sparseness property • Eventual reliability and soft real-time requirements
Batch rekeying • Collect join and leave requests for a period of time and rekey after several requests are received • Can reduce out-of-synch problems • Improves worst case number of rekey messages from LdlogdN to Ldlogd(N/L) where L is number of leaving members, d is tree degree, N is number of users
Careful key packaging • Assume keys required for a rekey cannot fit in one packet • Keys can be packaged from the keygraph using breadth first assignment (BFA) or depth first assignment (DFA) • BFA is fair (low variance) but distributes keys for a user into many packets (large average) • DFA is not fair (high variance) but puts keys for a user in few packets (low average) • A new algorithm called Recursive-BFA is both fair and has a low average
Reliable key transport • Receivers send a re-synch request if they cannot recover a rekey message in time. This solves the synchronization problem. • Forward error correction (FEC) with a proactive factor used to provide the soft real-time requirement.
Proactive FEC algorithm Using Reed Solomon code • Send k original and k(r – 1) FEC packets • At end of a round collect amax as the largest ar • At the beginning of the next round: generate amax FEC packets, multicast k is number of required packets, ar is number of packets to resend, r is proactivity factor.
Performance • Batch rekey improves performance. • R-BFA optimizes number of key packets and fairness. • Metrics were developed to determine a good tradeoff between bandwidth requirements and rekey interval.
References • Yang, Li, Zhang, and Lam, “Reliable Group Rekeying: A Performance Analysis”,SIGCOMM2001, August 2001, San Diego, CA, USA. • Harney and Muckerin, “Group Key Management Protocol (GKMP) Architecture”, RFC2094,July 1997. • Ballardie A,“Scalable Multicast Key Distribution”, RFC1949, May 1996. • Mittra Suvo, “Iolus: A Framework for Scalable Secure Multicasting”,SIGCOMM1997, 1997. • Wong, Gouda, and Lam, “Secure Group Communication using Key Graphs”, SIGCOMM1998, September 1998. • Lotspiech, Naor, and Naor, “Subset-Difference based Key Management for Secure Multicast”, Internet Draft, July 2001.