1 / 24

Secure Group Communication: Key Management

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

lazaro
Download Presentation

Secure Group Communication: Key Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Secure Group Communication: Key Management by Robert Chirwa

  2. 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

  3. 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.

  4. 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

  5. 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?

  6. 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.

  7. 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

  8. 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

  9. 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

  10. 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.

  11. Iolus Fig.1: The Iolus framework

  12. 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

  13. Fig.2: Key graph

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. R-BFA algorithm

  20. 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.

  21. 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.

  22. 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.

  23. 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.

More Related