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

Fig.2: Key graph

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

R-BFA algorithm

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 algorithmUsing Reed Solomon code

Send k original and k( – 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, 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.