IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 17, NO. 9, SEPTEMBER 1999 1
The VersaKey Framework:
Versatile Group Key Management
Marcel Waldvogel, Germano Caronni, Member, IEEE, Dan Sun, Student Member, IEEE,
Nathalie Weiler, Student Member, IEEE, Bernhard Plattner, Member, IEEE
Abstract—
Middleware supporting secure applications in a distributed environment
faces several challenges. Scalable security in the context of multicasting or
broadcasting is especially hard when privacy and authenticity is to be as-
sured to highly dynamic groups where the application allows participants
to join and leave at any time.
Unicast security is well-known and has widely advanced into production
state. But proposals for multicast security solutions that have been pub-
lished so far are complex, often require trust in network components or
are inefficient. In this paper, we propose a framework of new approaches
for achieving scalable security in IP multicasting. Our solutions assure that
that newly joining members are not able to understand past group traffic,
and that leaving members may not follow future communication.
For versatility, our framework supports a range of closely related
schemes for key management, ranging from tightly centralized to fully
distributed and even allows switching between these schemes on-the-fly
with low overhead. Operations have low complexity (
for joins
or leaves), thus granting scalability even for very large groups. We also
present a novel concurrency-enabling scheme, which was devised for fully
distributed key management.
In this paper we discuss the requirements for secure multicasting,
present our flexible system, and evaluate its properties, based on the ex-
isting prototype implementation.
Keywords— Secure multicasting middleware, Tree-based key distribu-
tion, Multicast key distribution schemes, Distributed key management,
Concurrent key distribution.
I. INTRODUCTION
ITH the increasing ubiquity of the Internet and the grow-
ing popularity of IP multicasting, multi-party commu-
nication is fast becoming a requirement for distributed appli-
cations, as is demonstrated with the popularity of the exper-
imental Mbone multicast service and the applications it sup-
ports. Today, the most important class of applications taking
advantage of multicast transport services are collaborative mul-
timedia applications and conferencing services [1]. This usage
will grow and include new applications such as fault-tolerant,
distributed database systems [2] or massively-parallel super-
computers made of workstations [3].
Besides the basic need to exchange information among the
members of a group, the requirements of specific applications
differ greatly. Resulting groups come in very different sizes:
small (in the case of a simple multi-party desktop conference),
medium (e.g., distance-education scenario), or very large groups
(e.g., broadcasting of a major sports event). In many applica-
tions, group members may also decide to join or leave the group
frequently and at any time. Best-effort IP multicast service was
specifically designed to address these requirements, and does
Marcel Waldvogel, Nathalie Weiler, and Bernhard Plattner are with the
Computer Engineering and Networks Laboratory, ETH Z¨urich, Switzer-
land (
last name@tik.ee.ethz.ch
). Germano Caronni is with the Net-
work and Security group of Sun Labs, Palo Alto, California, U.S.A.
(
gec@acm.org
). Dan Sun is with OpenCon Systems, New Jersey, U.S.A.
(
kathysunwang@hotmail.com
).
this very well.
But it is missing additional features that have to be provided
by other means: Quality of Service and resource reservation is-
sues are being covered by numerous schemes such as [4], [5].
Reliable transmission of data and concurrency resolution are
generally considered to be application-specific, if overhead is to
be minimal [6], [7]. But currently the provision of privacy and
authenticity for group members, e.g. by cryptographic means, is
still missing. Current solutions often require human intervention
(manual keying is common), or restrict the dynamics provided
by multicasting and required by many applications.
In this paper, we investigate how secure multicasting can be
provided as a universal service in an application-transparent
middleware, while preserving the properties of scalability and
flexibility as offered by the basic IP multicast service. We main-
tain and will demonstrate that such solutions exist; our tech-
niques, however, are not only applicable to IP multicast, they
may also be used in other environments, e.g. with connection-
oriented multicast services as found in ATM [8] or even one-way
broadcast services.
Like many unicast applications, a large group of multi-party
multi-media applications will only be successful if privacy and
authenticity of participants can be provided efficiently. Con-
sider, for example, a tele-education service, which distributes its
program to a large number of customers around the globe. It is
obvious that only those people who have subscribed to the ser-
vice should be able to receive it. If a new customer subscribes,
she should be able to receive data immediately, but not to un-
derstand information which was released before the time of her
subscription. Conversely, a customer canceling his subscription
should not be able to process information beyond the time of
cancellation.
Similarly, consider a teleconference meeting between man-
agers of a virtual corporation which need some outside expert
opinions during their meeting, but do not want this expert to
learn about the other topics they are discussing.
By consequence, this paper will discuss key management
schemes which guarantee that at each instance in time only ac-
tual group members will be in possession of the cryptographic
keys needed to participate. A na¨ıve solution would be to create
a new session key whenever a member leaves the group, and to
securely distribute the key to each member of the group, one by
one. However, such a solution would not scale, as it requires that
the new session key be encrypted individually for each partici-
pant.
Even though multicast routing itself implements a kind of
closed user group, the property of closedness is rather weak:
Multicast routing protocols known to date are designed to dis-
First publ. in: IEEE Journal on selected areas in communications, 17 (1999), 9, pp. 1-16
Konstanzer Online-Publikations-System (KOPS)
URL: http://www.ub.uni-konstanz.de/kops/volltexte/2007/2431/
URN: http://nbn-resolving.de/urn:nbn:de:bsz:352-opus-24315
2 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 17, NO. 9, SEPTEMBER 1999
tribute multicast datagrams to a set of links hosting group mem-
bers, i.e. to grant, and not to prevent access to information. This
is most prominent with routing protocols based on flooding al-
gorithms, such as DVMRP [9], and generally with approaches
using reverse path broadcasting/multicasting [10], which dis-
tribute multicast datagrams quite generously to a set of poten-
tial recipients which is much larger than the actual set of group
members. Cryptographic mechanisms to restrict the real flow of
information will therefore be of primary importance if tightly
controlled closed user groups are to be created.
We argue that a solution for secure multicasting must offer
the following properties:
Groupwide privacy and authenticity, including the unability
of newcomers to read past traffic.
Efficient distribution of keying material in large groups with
frequent membership changes (minimize traffic and computa-
tion effort for all parties involved).
No trust in intermediate or third party components.
Avoid multicast implosion.
No restriction of the services offered by the underlying multi-
cast infrastructure (e.g. avoid unicasts and relaying).
Minimize knowledge needed by participating entities.
Minimize attack vulnerabilities.
Additionally, the system should address the following issues:
Provide Perfect Forward Secrecy [11].
Cope with system and network failures (failure recovery
and/or resilience).
Work with (mostly) one-way traffic, such as satellite broad-
casts.
Allow sender authentication (as opposed to group-wide au-
thentication).
In this paper, we present three closely related schemes for key
distribution and management, ranging from tightly centralized
to completely distributed. Each of them already meets most of
the requirements above. For the case that requirements change
during the life-time of a group (e.g. unexpected growth), we also
provide for a set of efficient transitions from one scheme to an-
other. This yields a truly versatile framework that achieves scal-
able security in IP multicast, enabling secure multi-party multi-
media applications in which members of large and highly dy-
namic groups may participate.
Our approaches allow all group members to establish a mu-
tually shared secret, which can be used to provide group-wide
privacy and message authenticity, or any other property relying
on shared secrets. The system can offer perfect forward secrecy
[11], requires only a small amount of calculations and storage
from the participants, can be made highly resilient to compo-
nent and network failures, and avoids the need for trust into third
party components such as routers. It is independent of the secu-
rity algorithms used, so it can work together well with IP Secu-
rity (IPsec [12]) encryption and authentication mechanisms.
The remainder of the paper is organized as follows: Section II
presents related work, Section III introduces the three key man-
agement solutions, and Section IV explains the transitions be-
tween them. Section V then evaluates the functionality and per-
formance of VersaKey. Section VI draws conclusions and ex-
plores further work.
II. RELATED WORK
Although a number of cryptographic techniques have been
proposed to secure group communication in broadcast or multi-
cast scenarios, very few of them are targeted at a large group set-
ting with highly dynamic membership without third party trust,
and if they do, they are complex and inefficient in dealing with
this issue.
The existing approaches or applications concerning multicast
key management can be separated into two classes. Those offer-
ing dynamic operations are able to change group keying material
on the fly. Static solutions, forming the second class, require the
establishment of a new group to cope with membership changes.
Manual keying, still being the prevalent solution to multicast key
management as e.g. used in the MBone applications, is consid-
ered an insufficient key management solution.
A. Static Key Management Approaches
The static approaches distribute an unchanging group key to
members as they join. They provide no solutions for changing
the key when the group membership changes other than estab-
lishing a new group from scratch.
For IP multicast security, several key management schemes
are proposed, e.g. the Group Key Management Protocol
(GKMP) [13], [14], the Simple Key-Management for Internet
Protocols (SKIP) [15], the Internet Key Exchange (IKE) [16],
making use of the Internet Security Association and Key Man-
agement Protocol (ISAKMP) [17] and the the Oakley Key De-
termination Protocol [18], and the Scalable Multicast Key Dis-
tribution Scheme (SMKD) [19]. None of them provides a so-
lution for key change upon membership changes or for Perfect
Forward Secrecy (PFS). The properties of all presented schemes
are summarized in Table I.
B. Dynamic Key Management Approaches
In order to prevent the joining members from understanding
the past traffic and the left members from listening to future
messages, dynamic changes of the session key must be possi-
ble without rebuilding the whole group. Among the existing dy-
namic approaches, centralized and distributed schemes can be
distinguished depending on if they rely on a designated central
entity.
A few schemes can be enumerated as centralized dynamic
approaches, like Key Pre-distribution [20], Fiat-Naor Broad-
cast Encryption, [21], Secure Lock [22], the spanning tree-based
scheme [23] and [24]. All of them require a designated central-
ized controller to take care of distributing and/or updating key-
ing material. However, they also share the inherent drawbacks:
possible setup implosion, single point of failure and relatively
large database for the keying material.
To reduce the storage at the user’s end and the message length
broadcast by a center for dynamically changing privileged sub-
set of users, several schemes were presented by Fiat and Naor
[21].
Wallner et al. [25] propose a key management scheme for
multicast communication which requires each of the N users to
store
keys. In order to remove a user from the group,
a new group key must be generated. Unlike in the Fiat-Noar
THE VERSAKEY FRAMEWORK: VERSATILE GROUP KEY MANAGEMENT 3
TABLE I
PROPERTIES OF DIFFERENT SCHEMES
Property
Static Approaches
(GKMP, SMKD, SKIP,
ISAKMP/Oakley)
Centralized Approaches
(Pre-distribution, Secure Lock,
Fiat-Naor, Spanning tree, Iolus)
Distributed
Approaches
(Cliques)
VersaKey
Group-wide key yes Iolus: no; others: yes yes yes
Dynamic join and leave
handled
no yes yes yes
Scalability no Iolus/Spanning tree: yes;
others: no
yes yes
Perfect forward secrecy no no no yes
Centralized entity required yes yes variable variable
Trust in third parties required SMKD: yes; others: no Iolus: yes; others: no no no
Trust in other participants no Spanning tree: yes; others: no yes no
a
Memory with each entity
required
small Pre-distribution: huge;
others: small
small small
b
High Delay in key
distribution
no Spanning tree: yes;
others: no
Initial setup: yes;
otherwise: no
no
Distributed Flat: yes, but untrusted participants can be safely ignored
Except group manager in Centralized Tree: large
broadcast encryption schemes, the number of transmissions re-
quired to rekey the multicast group is small. However, in this
scheme every group member must assure that he receives all the
update messages sent by the group manager. A similar approach
has been proposed in [26].
Secure lock is implemented based on the Chinese Remainder
Theorem. Here, the group session key is secured in a way that
only the keys of authorized users can retrieve it. This scheme
requires the association of one large number (relatively prime
to all other group members’ numbers) with each participant. In
addition, the retrieval of the group session key is an expensive
operation. These conditions confine this protocol to being used
only within small groups.
The spanning tree [23] needs to be extended or pruned, when-
ever the membership changes, to make sure that only the group
members can get the updated conference key. The delay in dis-
tributing a conference key along the spanning tree makes this
approach not applicable for frequent changes of membership.
Iolus deals with the scalability issues in highly dynamic large
groups by decomposing large groups into subgroups. Thus, a
group membership change can be handled in the respective sub-
group without affecting any other subgroups. While improving
scalability, the absence of a global group key requires the intro-
duction of secure agents, one for each subgroup, to relay mes-
sages and perform ”key translation”. In addition to requiring full
trust into each subgroup agent, extra delays in message delivery
must be accepted.
Cliques, described by Steiner et al. [27], is a natural exten-
sion to the Diffie-Hellman key exchange protocol and presents
the capability to distribute session keys in dynamic groups. The
group controller can be either fixed with a designated node or
transferred to the newly joint member. While this protocol pro-
vides a way to distribute a session key in highly dynamic groups,
the solution does not scale well to large groups, where the group
manager has to perform
!#"$
exponentiations for each group
change, and messages get prohibitively large.
As summarized in Table 1, most existing protocols for secure
multicasting are limited to distribute session keys in static and/or
small groups. For dealing with the group key distribution in a
large group with frequent membership changes, some good ex-
plorations have been done in [24], [27]. However, several is-
sues must be improved: the reduction of computational com-
plexity, decrease of trust in dedicated nodes (e.g. network com-
ponents), and the necessity for group members to interoperate
for the generation of a group-wide secret. We will now present
several schemes that demonstrate the ability to successfully han-
dle these issues in large and highly dynamic groups.
III. SECURE MULTICASTING ALGORITHMS
In the solutions presented here, changes to the group’s mem-
bership are possible with minimal involvement of dedicated
nodes and group members. The approaches cope with several
properties inherent to multicast and broadcast environments:
There is an unreliable (and in the case of IP also unordered)
transmission channel, and the transmissions may be one-way,
with no or only a minimal return channel, to reflect the nature
of wide-scale distribution environments – likely users of secure
multicasting. Last but certainly not least, it is important that as
little trust as possible should be necessary towards third party
entities such as routers or other intermediate systems. While
those third party components may be trusted to distribute a ses-
sion directory, certified public key material, or access control
information signed by a group memeber, they should never be
able to gain access to actual keying material and decrypted pay-
load.
As seen earlier, it is important to have a system which — even
with large groups and frequent joins or leaves — neither is sus-
ceptible to implosion nor enables users to understand what was
4 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 17, NO. 9, SEPTEMBER 1999
Managing Entity
Admission
Control
Multicast Data Flow
Multicast Control Flow
One-Shot Control Connection
(Unicast)
Multiple Instances
Key
Control
Group
Data
Multicast
Group
Group
Manager
Sending
Entity
Encryption
Key
Manager
Data
Source
Receiving
Entity
Decryption
Key
Manager
Data
Sink
Control Plane Data Plane
(a) Broadcast-like scenario
Participant
Key
Control
Group
Data
Multicast
Group
Encryption
Key Manager
(including Goup
Management and
Admission
Control)
Data Source
Decryption
Data Sink
Control Plane Data Plane
(b) Group collaboration scenario
Fig. 1. Two Possible Multicast Scenarios
transmitted at times they were not part of the group, either before
they joined or after they left or were expulsed. Additionally, any
third party recording ongoing transmission and later capturing
the secrets held by a participant must not be able to understand
its recordings. This is known as “perfect forward secrecy” [11].
To completely achieve this, also the unicast connections need to
be set up using ephemeral secrets.
This section is organized as follows: First, the general archi-
tecture and components of the framework are discussed, fol-
lowed by the detailed descriptions of the three key management
approaches (Tree-based, Centralized Flat, and Distributed Flat),
explaining the properties they make available to large, dynamic
groups. The presented schemes cover a wide range of applica-
tions and security needs: From very tight control in the cen-
tralized approach to extreme tolerance to system and network
failures in the completely distributed scheme. A selection of ad-
vanced topics concludes the discussion.
A. Components and Group Operations in Multicast Scenarios
Figure 1(a) illustrates the basic architecture for a simple sce-
nario consisting of a single sending entity and any number of
receiving entities. Generally the components are separated into
two groups: (1) a group of data related components, covering
components very similar to those of current insecure multicast
or broadcast communication architecture. It consists of the data
source, data sink, encryption and decryption units and the data
multicast group(s). (2) a group of control (or key management)
related components, which includes all components involved in
the key agreement and key exchange process. Note that in the
centralized approaches described below, it is possible to locate
instances of the admission control component on different ma-
chines, thus mitigating a potential implosion problem.
The outline of the multicast data flow from the sending entity
to one of the receiving entities is as depicted in Figure 1(a): The
data source is fed to the encryption unit to be multicast to the
addressed data multicast group. The receiving entity performs
the necessary decryption and hands its result on to the data sink.
The control related components provide the necessary keys to
the encryption and decryption units.
An overview of the roles of the different components in
Figure 1(a) during group management operations are shown in
Table II (for the distributed approach explained below, the du-
ties of the group manager are shared by all participants). Fur-
ther possible operations concern the group setup: creation, de-
struction, merging, and splitting of groups. They are highly de-
pendent on the key management scheme and will therefore be
discussed in the corresponding sections. Also, the exclusion of
multiple colluding participants is to be treated differently in
some of the schemes.
The components have been described for a simple scenario.
However, there often is more than one sender, and senders and
receivers may not be distinguishable. Also, any receiving entity
is free to send data encrypted or authenticated using the cur-
rent group-wide symmetric key, and in a group collaboration
environment every member of the group holds both roles at the
same time, resulting in a situation as shown in Figure 1(b). This
group collaboration scenario arises from a transformation of
Figure 1(a) where sending and receiving entity were integrated,
yet the group manager remains isolated. All of the schemes also
work in this scenario, and the later presented distributed key
management scheme (cf. Section III-D) is very well suited for
it. If senders and receivers are treated equally, they will be re-
ferred to using the more generic term participant.
In the following two subsections, we will illustrate additional
aspects, namely the properties of keying material, and the basic
operations in the groups.
A.1 Identification of Keying Material
We distinguish two types of keys. Firstly, we need a key to
encrypt, decrypt, and possibly authenticate the data traffic. For
this purpose, the Traffic Encryption Key (TEK) is given by the
local key manager to the appropriate unit. Secondly, a number
of Key Encryption Keys (KEKs) are used to encrypt the control
traffic in the key control group, ultimately containing the TEK.
To distinguish the keys, each key is addressed through a key
selector, consisting of (1) a unique ID which will stay the same
even if the secret keying material changes, and (2) a version
and revision field, reflecting updates in the keying material (cf.
Figure 2). The version is increased whenever new keying ma-
terial is sent out by the group manager on a leave, while the
revision is increased whenever the key is passed through a one-
way function, eliminating the need for sending update messages
on joins.
Fixed ID Version Revision Secret Material
Key DataKey Selector
Fig. 2. Structure of a Key
A.2 Basic Operations on the Group
The abovementioned components and keys will be involved
in different activities:
Group Creation The Group Manager is configured with group
and access control information. Additionally, the group param-
eters are published using a directory service.
Single Join The new participant’s Key Manager sends its re-
quest to the Group Manager, which checks whether this par-
ticipant is allowed to join. If yes, the Group Manager assigns
THE VERSAKEY FRAMEWORK: VERSATILE GROUP KEY MANAGEMENT 5
TABLE II
INTERACTIONS OF THE DIFFERENT COMPONENTS DURING THE OPERATIONS
Operations
Components Join Leave
Single Multiple
Participant key manager update keying material (4)
a
update keying material (3)
Key manager of
entity/-ies requesting
operation
request (1)
update keying material (4)
no comprehensibility of the keying material
update (3)
Group manager change keying material,
notification of the
joining entity (3)
common handling
of several requests
(3)
change keying material (3)
Admission control asymmetric cryptographic operations,
check of access rights (2)
change of access rights for leaving entity (1)
notification of the group manager(2)
b
The numbers in parentheses indicate the sequence of steps.
This is policy-dependent. In case of a voluntary leave, the keying material may be kept the same.
a unique ID to him, and selects a series of KEKs which will
be transmitted to the newcomer. The selection of KEKs will be
discussed separately for each key management scheme.
The Group Manager now increases the revision of all keys (TEK
and KEKs) to be transmitted to the participant by passing the
keying material through a one-way function (e.g. a cryptograph-
ically secure hash), then sends the keys out to the new partic-
ipant. It also informs the sender(s) to use the new TEK. The
other participants will notice the revision change visible in ordi-
nary data packets, and also pass their TEK through the one-way
function. Since the function is not reversible, the newcomer has
no way to determine the key used beforehand.
Single Leave There are three ways to leave a group:
1. Silent Leave: A receiver just stops participating in the group
without telling anyone. No action is needed.
2. Voluntary Leave: A receiver announces that it’s leaving. De-
pending on the policy, its keying material can be made unusable
through a leave message as described below, the leave message
may be delayed until another leave has to be performed, or no
action is done, allowing the receiver to continue listening, if it
wishes so.
3. Forced Leave: If the Admission Control feels a need to
forcibly exclude a participant, a leave message is to be sent out.
Also, participants may ask the Admission Control to exclude a
member. It is up to the admission policy how to deal with such
requests.
To exclude a member, all keys known to it need to be replaced
with entirely new keying material. To make all remaining par-
ticipants aware of this change, the key’s version number is in-
creased.
The Group Manager sends out a message with new keying ma-
terial which can be decrypted by all the remaining participants’
Key Managers, but not the member which just left. Additionally,
it frees the slot previously utilized by the leaving participant,
making it available for reuse. As soon as all participants throw
away prior keying material, perfect forward secrecy for the past
traffic is assured.
Multiple Join, Multiple Leave, Group Merge, Group Split
These functions have a number of dependencies on the chosen
scheme and will thus be detailed there.
Group Destruction The Group Manager notifies all remaining
participants of the destruction, closes all network connections,
destroys all keying material and frees all memory. As soon as
all parties have thrown away their keying material, perfect for-
ward secrecy covering all traffic against third party opponents is
guaranteed.
B. Centralized, Tree-Based Key Management
In our first approach, we proposed and implemented a central-
ized, easy maintainable scheme which achieves tightest control
over the individual participants [28]. It is suitable for applica-
tions with high security demands, and poses very little load on
the network and the receivers. All keying material is managed
centrally by the group manager, where all joining entities have
to register. To store the keying material, a tree is used in which
all participating entities are represented by its leaves. For sim-
plicity of the explanation assume that a fully balanced binary
tree is used. The example in Figure 3 depicts such a tree with a
maximum of 16 group members (address length
%
of 4 bits).
Key
Encryption
Keys
Traffic
Encryption
Key
Level 0
Level 1
Level 2
Level 3
Level 4 (=W)
(Leaves)
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
01 23 45 67 89 AB EF
03 47 8B CF
07 8F
0F
CD
Fig. 3. Binary Hierarchy of Keys. Labels in hexadecimal define the range of
participants knowing this key.
During a setup phase, which includes admission control, each
participant establishes a shared secret with the group manager.
This shared secret is known only by the group manager and the
individual participant, and is used as the lowest level KEK. The
group manager stores it in the leaf node associated with this par-
