SECURITY ISSUES IN DYNAMIC GROUP COMMUNICATION SYSTEMS
Abstract
Emerging technologies are introducing new ways of using applications
performing transactions, and processing information in global and open networks.
Modern computer networks are a complex assembly of databases, web and other
application servers, web browsers, and various network devices. In such an
environment transactions are usually not simple client-server arrangements, but
complex actions involving multiple participants.
In distributed, multi-party environments, there is usually no clear distinction as to
who initiated a transaction, which parties should participate in a transaction,
which components are used to perform the transaction, and finally which
recipient(s) complete the transaction. Many components and aspects of a
transaction are often determined dynamically on an ad hoc basis, even after the
transaction has been initiated. In such circumstances the reliability of transactions,
authentication of participating parties, creation and verification of roles and
authorization schemes, non–repudiation, and other security issues are becoming
increasingly difficult to establish and enforce. Simple extension of client-server
security protocols to multi-party security protocols is not possible. Basic security
services needed in a multi party setting are largely the same as in point-to-point
communication: viz. data secrecy and integrity, and entity authentication. These
services cannot be attained without secure, efficient, and robust group key
management. This report gives a detailed survey and classification of group key
management protocols. We propose to look at some open challenges in the area of
admission control and access control in dynamic groups.
1. Introduction
The increasing use of collaborative applications on the Internet and new
Information technologies, is leading to a rapid change from simple client server
model towards a multi-party model. Many modern computing environments
involve dynamic peer groups. Distributed simulation, multi-user games,
conferencing applications and replicated servers, broadcasting stock quotes are
just a few examples. Security is crucial for such distributed and collaborative
applications that operate in a dynamic network environment and communicate
over insecure networks such as the Internet. Basic security services needed in
such a group setting are largely the same as in point-to-point communication: viz.
data secrecy and integrity, and entity authentication. These services cannot be
attained without secure, efficient, and robust group key management.
Security requirements for different applications may also vary. For an application
like stock broadcasting, authentication may be a fundamental requirement and not
confidentiality, while for video-conferencing applications both authentication and
confidentiality are essential. Group key management (GKM} is the most
important issue in secure group communication. The security challenge for
multicast is in providing an effective method for controlling access to the group
and its information. A primary method of limiting access to information is
through encryption and selective distribution of the keys used to encrypt group
information. The main difficulty for Group Key Management arises because of
member dynamics. The issues that arise are the method of distribution of a shared
key to all group members and computation of a new key when a new member
joins or an old member leaves the group.
Several group key agreement techniques have been proposed in the last decade,
all assuming the existence of an underlying group communication infrastructure
for reliable message delivery. The specific security requirements and needs of
dynamic peer groups, in particular key management are still considered as open
network challenges.
2. Desired Properties for a Group Key Agreement Protocol [13,15]
2.1 Security Requirements:
1.
Forward Secrecy: This requires that users who have left the group should not have
access to any future key, so that they cannot decrypt any data after leaving the
group.
2. Backward Secrecy: This states that a new user joining the session should not have
access to any old key.
3. Collusion Freedom: Any set of fraudulent users should not be able to deduce
current session key.
4. Key Independence: Disclosure of a key should not compromise other keys.
5. Minimal Trust: Key management scheme should not place trust in high number of
entities.
2.2 Quality of Service Requirements
1.
Low Bandwidth Overhead: Re-Key of a group should not induce a high number
of messages.
2. 1-effects-n: A protocol suffers from 1-effects-n if a single membership change
affects all group members.
3. Minimal Delay: Applications like multimedia are sensitive to jitters and delays. It
is essential to minimize the impact of key management on packet delays.
4. Service Availability: The failure of a single entity should not prevent the
operation of the entire group.
2.3 Other Requirements
Key Management schemes must not induce high storage of keys or high
computation overhead. Distributing the group key to valid members is a complex
problem. Re-keying a group before the join of a new member is trivial as the new
key can be sent to the old group members encrypted with the old group key, but
re-keying after a member leaves is more complicated. The old key cannot be used
to distribute a new one, because the leaving member knows the old key. There
should be a scalable mechanism to re-hkey the group.
3. Key Agreement in Peer Groups
Key management has a great impact not only on the security and fault tolerance of
the overall system, but also on its performance. Many group key management
protocols have been proposed in the past and broadly fall into three categories
 Centralized group key distribution (CGKD)
 Decentralized group key management (DGMM)
 Contributory/Distributed group key agreement (CGKA).
3.1 Centralized Group key Distribution (CGKD)
This involves a single entity or a group of entities, which function as a centralized
server to distribute keys to group members. The centralized key server must
however be continuously available and present in every possible subset of a group
in order to support continued operation. It works well in one-to-many multicast
scenarios. Centralized protocols are further classified into three categories
depending on the technique used to distribute the encryption key.
3.1.1 Pair-wise Secure Channel:
The group controller shares a secret key with each group member thus
establishing pair-wise secure channels.
3.1.1.1 Group Key Management Protocol (GKMP): Harney and Muckenhirn
[12] proposed the Group Key Management Protocol (GKMP) that uses pair-wise
secure channel approach. The key server generates a group key packet that
contains two keys: a Group Traffic Encryption key (GTEK) and a group key
encryption key (GKEK). When a new member joins the session the key server
generates a new GKP and sends it securely to the new member encrypted with the
new KEK established with this member and to the old members encrypted with
the GTEK previously established. When an old member leaves the key server
generates a new a GKP and sends it to remaining members encrypted with the old
KEK that it shares with each member. To ensure forward secrecy this approach
requires O(n) re-key messages for each leave from the group.
3.1.2
Broadcast Approach: The re-keying of a group is based on broadcast
messages instead of peer-to-peer secret transmissions.
3.1.2.1 Secure Locks: Chiou and Chen [ ] proposed Secure Locks a key
management protocol where the key server requires only a single broadcast to
establish the group key or to re-key the entire group in case of a leave.
3.1.3 Hierarchy of Keys Approach
In order to reduce the number of message updates required when a key server
shares pair-wise keys with members of the group, in this approach the key server
maintains a tree of keys and shares keys with subgroups of secure groups in
addition to pair-wise channels. Sub-group secret keys allow to reduce the number
of update messages.
3.1.3.1 Logical Key Hierarchy
Wong et al. [2000] and Wallner et al. [1999] proposed the use of a Logical Key
Hierarchy (LKH). In this approach, a KDC maintains a tree of keys. The nodes of
the tree hold key encryption keys. The leaves of the tree correspond to group
members and each leaf holds a KEK associated with that one member. Each
member receives and maintains a copy of the KEK associated with its leaf and the
KEKs corresponding to each node in the path from its parent leaf to the root. The
key held by the root of the tree is the group key. For a balanced tree, each member
stores at most (log2n) + 1 keys, where (log2n) is the height of the tree.
Example:
The figure below shows a multicast group with six members {u1, u2, u3, u4,u5,
u6}. The key server builds a hierarchy of keys.
TEK
K1234
K12
K1
U1
K34
K2
U2
K3
U3
K56
K4
U4
Figure 1: LKH Tree
K5
U5
K6
U6
Each member owns a secret key, which is a leaf in the tree as well as all the keys
on its path to the root. The root represents the encryption key TEK shared by the
members. The other keys are used to reduce the required re-keying messages.
According to the figure: u1 owns{ k1, k12, k1234, TEK}, u2 owns{ k2, k12,
k1234,TEK}, u3 owns{ k3, k34, k1234, TEK}, u4 owns{ k4, k34,k1234, TEK}, u5 owns{
k5, k56, TEK} and u6 owns{ k6, k56, TEK}.
Member Join A joining member is associated with a leaf, all KEKs in the nodes
from the new leaf’s parent in the path to the root are compromised and should be
changed. A re-key message produced is at most 2.log2n keys long.
Member Leave: Assume that u5 leaves the group, KS updates k56
56,
56 to u6 encrypted with k6. TEK is updated into TEK’ and sent to
{u1,u2,u3,u4} encrypted with k1234 and to u6
56 and hence only
three messages are required instead of five messages if GKMP were used.
The key hierarchy allows to reduce the number of re-key messages to O(logn)
instead of O(n).
3.1.3.2
3.1.3.3
One-way Function Trees (OFT): McGrew and Sherman [ ] proposed
an improvement over LKH called One-way Function Trees (OFT). OFT allows to
reduce the number of re-key messages from 2log2(n) to only log2(n).With OFT, a
KEK is calculated by members rather than attributed by the key server. Each KEK
ki is computed using its child KEKs using the formula:
ki = f(g(kleft(i)), g(kright(i)))
where left(i) and right(i) denote respectively the left and right children of node i,
and g is a one-way function. The result of applying g to a key k: g(k), is called the
blinded key version of k.
In this protocol, each member maintains its leaf secret key and its blinded
sibling key and the set of blinded sibling KEKs of its ancestors. Canetti et al. [10]
proposed a similar approach One-way Function Chain Tree(OFCT) that has the
same communication overhead. Their scheme uses a pseudo-random generator to
generate new KEKs instead of a one-way function.
Efficient Large-Group Key (ELK): Perrig et al. [2001] proposed the
Efficient Large-group Key (ELK) protocol. The ELK protocol uses a hierarchical
tree and is very similar to the OFT in the sense that a parent node key is generated
from its children keys. ELK uses pseudo-random functions (PRFs) to build and
manipulate the keys in the hierarchical tree.
Attributes used to evaluate the efficiency of centralized key management
protocols:


1-affects-n:.
Forward and Backward Secrecy: Capability of a protocol to provide secrecy
despite changes to group membership




Storage at the key server: The number of keys that should be maintained by
a key server.
Storage at a member: The number of keys that should be maintained by a
group member.
Join re-key overhead: Number of re-key messages sent by the key server to
redistribute the group TEK after a join.
Leave re-key overhead: Number of re-key messages sent by the key server to
redistribute the group TEK after a leave.
Table 1. gives a comparison of the centralized GKM protocols based on above
attributes.
Protocol
GKMP
LKH
OFT
Secure
Lock
ELK
Secrecy
Bac
k
Y
Y
Y
Y
Forw
1effect
s-n
Re-Key Overhead
Join
Multicast Unicast
N
Y
Y
Y
Yes
Yes
Yes
No
2
log2(n)-1
log2(n)+1
0
2
log2(n)+1
log2(n)+1
2
2n
Y
Y
Yes
0
log2(n)+1
Leave
Storage Overhead
Key
Member
Server
log2(n)+1
0
n+2
2n-1
2n-1
2n
3
log2(n)+1
log2(n)+1
2
--
2n-1
log2(n)+1
n: number of group members
Table 1. Comparison of Centralized Group Key Management Protocols
The GKMP protocol achieves an excellent result for storage at the members
However, the method for re-keying of the group is re-creating the entire group
which induces a O(n) re-key messages overhead, n being the number of the
remaining group members. Secure Lock also achieves excellent results for storage
and communication overheads on both members and the key server. However, these
results are achieved by increasing the computation overhead at the key server due to
the Chinese Remainder calculations. So far, the best solutions for centralized group
key management appear to be those using a hierarchical tree of KEKs. They
achieve good overall results without compromising any aspects of security.
Features that make centralized key distribution unsuitable for Dynamic Peer
Groups:





The Centralized key server acting as a trusted third party for generating and
distributing for a multitude of groups is a single point of failure and a likely
performance bottleneck.
A TTP presents a very attractive attack target for adversaries.
In highly dynamic groups, each group member cannot be assumed to be present
all the time. However, most centralized key distribution protocols assume fixed
centers.
A single party generating a group key might be unacceptable in cases where each
party needs assurance that the resulting group key is fresh and random
Achieving perfect forward secrecy and resistance to known-key attacks in an
efficient manner is very difficult in the centralized key distribution setting.
3.2 Decentralized group key management
The management of a large group is divided among sub-group managers to avoid
a single point of failure. A hierarchy of key managers, share the task of
distributing the TEK to group members. In this class of protocols re-keying is of
two kinds viz:
i) Membership Driven: Key is changed whenever a join or leave occurs
ii) Time Driven: Key is changed periodically.
3.2.1 Scalable Multicast Key Distribution (SMKD):
Ballardie proposed in RFC1949 [3] the Scalable Multicast Key Distribution
(SMKD); a protocol where the multicast tree is rooted at a main core. Secondary
cores can exist eventually. The main core creates an access control list (ACL), a
session key GTEK and key encryption key GKEK used to update the session key
GTEK. The ACL, the GTEK and the GKEK join the multicast tree after their
authentication. Any router in the path of a joining member from its location to the
primary core can authenticate the member since the router is authenticated with
the primary core.. With SMKD there is no solution for forward secrecy other than
to recreate an entirely new group without the leaving members.
3.2.2 Iolus
Mittra proposed Iolus [Mittra 1997], where a hierarchy of agents splits a large
group into small subgroups. A Group Security Agent (GSA) manages each
subgroup. The GSAs are also grouped in a top-level group that is managed by a
Group Security Controller. Changes that affect a subgroup are not reflected in
other subgroups. If a subgroup controller (namely GSA) fails, only its subgroup is
affected.
3.2.3 Kronos
Setia et al. [2000] proposed Kronos. This is based on a periodic re-key approach
where a new group key is generated after a certain period of time, irrespective of
whether any member has joined, left or been ejected from the group. The network
is divided into domains and each domain is divided into areas managed by
different Area Key Distributors (AKDs). The Domain Key Distributor DKD does
not directly generate the group key. Instead, each Area Key Distributor AKD
independently generates the same group key and transmits it to its members at the
end of the predetermined period. Kronos does not provide key independence
because it generates new keys based on old ones, and if any past key is
compromised, all future keys are disclosed.
3.2.4 Hydra
Rafaeli and Hutchison [2002] proposed Hydra. In Hydra, the large group is
divided into smaller subgroups, and a server called the Hydra Server (HS)
controls each subgroup. Hydra is a decentralized group key management scheme
without a central subgroup controller. If a membership change takes place at HSi ,
and a new key must be generated, it can generate the new group key and send this
key to the other HSj involved in that session. A special synchronized group key
distribution protocol is used to distribute the group key to all HSs, to ensure that
only a single valid HS is generating the new group key at a given time.
Attributes used to evaluate the efficiency of decentralized key management
protocols:







Key independence: Disclosure of a key must not compromise past keys.
1-affects-n
Decentralized Controller: Centralizing manager should not manage the
sub-group managers.
Local re-keying: Membership changes in a sub-group should be treated
locally.
Keys vs. data. The data path should be independent of the key
management path, which means that re-keying the subgroup should not
impose any interference or delays to the data communication;
Re-key per membership. Related to backward and forward secrecy;
Type of communication. Groups with a single data source are said to use
1-to-n communication, and groups with several or all members being able
to transmit are characterized by using n-to-n communication.
Protocol
Key
Indep
SMKD
Kronos
Hydra
Iolus
Yes
No
Yes
Yes
1efectsn
Yes
Yes
No
Local Key
re-key Data
No
No
No
Yes
Yes
Yes
Yes
No
vs Rekey
No
No
Yes
No
Fault
Tolerant
Comm
Type
No
Yes
Yes
No
Both
Both
Both
1-to-n
Table II: Comparison of some Decentralized Group Key management Protocols
3.3 Distributed Key-Agreement Protocols
With distributed key-agreement protocols, the group members cooperate to
establish a group key. Contributory group key agreement protocols compute a
group key as a (usually, one-way) function of individual contributions from all
members and can provide both key independence and PFS properties. This is
appropriate for dynamic peer groups. This approach avoids problems with single
point of trust and failure, and also does not always require the establishment of
pair-wise secure channels between group members. At the same time,
contributory group key agreement presents a tough practical challenge: Its multiround nature must be reconciled with the possibility of crashes, partitions, and
other events affecting group membership that can occur during the execution of
the group key agreement.. The protocols of this category are further classified into
three sub-categories depending on the virtual topology created by the members
for cooperation.
3.3.1 Ring-Based Cooperation
In this sub-category, the cooperation of group members forms a virtual ring.
3.3.1.1 Ingemarson et al. protocol (ING): The protocol proposed by Ingemarson
et al. in [ ] for teleconferencing is one of the earliest propositions to extend DiffieHellman key agreement protocol. In this protocol, members are organized into a
virtual ring; in a way that member Mi communicates with member Mi+1 and
member Mn with member M1. The group members compute the group key within
(n−1) rounds. Initially, each member Mi generates a random value Ni, computes
gNi and sends it to the next member Mi+1. Then, in each round, each member Mi
raises to the power Ni the intermediate value received from member Mi−1, and
sends the result to the member Mi+1. Each member performs n exponentiations
and gets the group key Kn = gN1N2...Nn after (n−1) rounds.
The ING protocol is inefficient:
1. Every member has to start synchronously
2. n-1 rounds are required to compute a group key
3. This protocol is not suitable for dynamic groups because it requires the
execution of the entire algorithm after each membership change.
3.3.1.2 Group Diffie-Hellman (GDH): GDH is a protocol based on group
extensions of the two-party Diffie–Hellman key exchange [Steiner et al. 2000]
and provides fully contributory key agreement. GDH is fairly computationintensive, requiring O(n) cryptographic operations for each key change. It is,
however, bandwidth efficient. The shared key is never transmitted over the
network (in the clear or otherwise). Instead, a list of partial keys, one for each
member, is generated and sent. Upon receipt, each member uses its partial key to
compute the group secret. One particular member of the group (controller) is
charged with the task of building and distributing this list. The controller is not
fixed and has no special security privileges. The protocol runs as follows:

The group agrees on a pair of primes (q and α) and starts calculating in a
distributed way the intermediate values.
Member 1 calculates generates a random number x1 and computes gx1 and
sends it to the next member.
Each subsequent member receiving the set of intermediary values, raises
them using its own secret number generating a new set:
A set generated by the ith member will have i intermediate values with i−1
exponents and a cardinal value containing all exponents.
So fourth member for e.g receives the set: { α x2x3, α x1x3, α x1x2, α x1x2x3}
and generates the set { α x2x3x4, α x1x3x4, α x1x2x4, α x1x2x3, α x1x2x3x4}. The
cardinal value in this example is α x1x2x3x4 .
The last member can easily calculate the group key k from the cardinal
value: k = α x1x2x3….xn mod q.
The last member raises all intermediate values to its secret value and
multicasts the whole set to all group members.
Upon receiving this message, each member j extracts its respective
intermediate value and calculates k by exponentiation of the jth value to xj
The setup time and the length of messages are linear in terms of the
number of group members n since all members must contribute to
generating the group key.







Merge Protocol (K members are added to a group of size n)






When a merge event occurs the current controller Mn generates new
exponent r'n є Zq and computes new key token α r1….rn-1rn' mod p and
unicasts the message to one of the new members Mn+1.
When the new member Mn+1 receives the token, it generates its own
contribution rn+j є Zq and computes α r1….rn'…rn+j mod p and forwards the
result to Mn+j+1 the next new member.
Eventually, the token reaches the last new member Mn+k. This new
member, who is slated to become the new controller, broadcasts the
token to the group without adding its contribution.
Upon receiving the broadcast token, each group member Mi for all i є
[1, n+k-1] factors out its contribution and unicasts the factor out token
α r1….rn'…rn+k-1/ ri mod p back to Mn+k, the new controller.
The new controller collects all the factor-out tokens, generates new
exponent rn+k and produces α r1….rn'…rn+k/ ri mod p | for all i є [1, n+k-1]
and broadcasts it to the group.
Every member obtains the group key by factoring in its contribution into
the corresponding partial key in the broadcasted list. Each Mi for all i є
[1, n+k-1] computes the key K=( α r1….rn'…rn+k/ ri)ri mod p = α r1….rn'…rn+k
mod p.
Partition Protocol
When some of the members leave the group the controller (who, at all times, is
the most recent remaining group member) removes their corresponding partial
keys from the list of partial keys, refreshes each partial key in the list and
broadcasts the list to the group. Each remaining member can then compute the
shared key. If the current controller leaves, the last remaining member becomes
the controller of the group.
Assume that L members is leaving a group of size n
Step 1: The controller Md generates a new exponent r'd є Zq and
computes
α r1….rd'/ ri mod p and broadcasts it to the remaining group
Step 2: Upon receipt of the broadcast, every member Mi, computes the
key
K = (α r1….rd'/ ri)ri = gr1….rd’ mod p.
3.3.2
Hierarchy-Based Cooperation
3.3.2.1
Octopus: Becket and Wille [ ] proposed the Octopus protocol
which is also based on Diffie-Hellman key exchange protocol []. A large group
(composed of n members) is split into four sub-groups (n/4 members each).
Each sub-group agrees internally on an intermediate DH value: Isubgroup =
αu1u2...un/ 4, where ui is the contribution from user i, and then the subgroups
exchange their intermediary values. All group members can then calculate the
group key. The leader member in each sub-group is responsible for collecting
contributions from its sub-group members and calculating the intermediary DH
value (Isubgroup).
Example: Assume four subgroup leaders A, B, C and D.
1. A and B, using DH, exchange their intermediary values Ia and Ib
2. A and B create αIa.Ib.
3. C and D do the same and create αIc.Ib .
4. A and C exchange αIa.Ib and αIc.Id.
5. Leaders, B and D do the same.
6. All calculate αIa.Ib.Ic.Id .
7. A, B, C and D send to their respective subgroups α Ia.Ib.Ic.Id /ui , where i = 1.
. . (n−4)/4, and all members of the group are capable of calculating the
group key.
3.3.2.2
STR Protocol
The STR protocol [16] is a contributory protocol with an unbalanced tree
structure whose height is always (n−1). The key tree is organized as follows:
each node is associated with a key and a corresponding blinded key. The root is
associated with the group and each leaf with a distinct member. The root key
represents the group key shared by all members, and a leaf key represents the
random contribution of a group member. Every member knows all keys on the
path from its leaf node to the root as well as all blinded keys of the entire key
tree. The protocol relies on the fact that every member can compute a group key
if it knows all blinded keys in the key tree.
The leaves are associated to group members. Each leaf is identified by its
position LNi in the tree and holds a secret random ri (generated by the
corresponding member Mi) and its public blinded version bri = gri mod p, where
g and p are DH parameters. Each internal node is identified by its position INi in
the tree and holds a secret random ki and its blinded public version bki = gki
mod p. The secret key is the result of a Diffie–Hellman key agreement between
the node’s two children. Each secret ki is recursively calculated as follows: ki =
(bki−1)ri mod p= (bri)ki−1 mod p. The group key is the key associated to the root:
kn = grngrn−1...gr2r1 . Due to the linear structure of the tree, this solution
induces a O(n) key calculations in order to establish the group key associated to
the root of the tree. Besides, each member should store and maintain all the
public
keys
associated
to
all
the
nodes
of
the
tree.
Figure 4 illustrates an STR tree with four members.
IN4
LN4
IN3
M4
LN3
IN2
M3
LN2
LN1
M1
Figure: 4 STR Tree
M2
In case of a membership change (join / leave) the tree is re-built consequently and
hence all the members update the group key which is the new key kn associated to
the root of the tree.
After a partition, the sponsor is defined as the member corresponding to the leaf
node just below the lowest leaving member. After deleting all leaving nodes the
sponsor refreshes its key share, computes all (key, blinded key) pairs up to the
level just below the root node. Finally, the sponsor broadcasts the updated key
tree thus allowing each member to compute the new group key.
STR merge runs in two rounds. In the first round, each sponsor (topmost leaf
node in each of the two merging tree) first refreshes its key share and computes
the new root key and root blinded key. Then, the sponsors exchange their
respective key tree views containing all blinded keys. The topmost leaf of the
larger tree becomes the sole sponsor in the second round in the protocol (see
Figure 8). Using the blinded keys from the key tree it received in the first round,
the sponsor computes every (key, blinded key) pair up to the level just below the
root node. It then broadcasts the new key tree to the entire group. All members
now have the complete set of blinded keys which allows them to compute the new
group key.
3.3.2.3 Diffie Hellman - Logical Key Hierarchy (DH-LKH): Perrig et al. [ ]
proposed a variant of STR using a binary tree (less deeper) in order to reduce the
number of key calculations from the order of O(n) to O(log (n)). The proposed
protocol is a distributed version of LKH. The tree is built recursively from bottom
to up. Initially, each member Mi generates a random ri as a secret key associated
to its leaf. To build upper level of the tree, two members: one as a leader of a left
subtree and another one as a leader of a right subtree, broadcast their respective
DH computations and hence allow all the members to calculate the group key
corresponding to the root of the tree. Using the tree in figure 5, intermediate keys
are k12 = αk1k2 mod p, k34 = αk3k4 mod p and the group key is k14 = αk12k34 mod p.
K14
K12
K34
K4
K1
U1
K2
U2
Figure: DH-LKH Tre
K3
U3
U4
3.3.3
Broadcast-Based Approach In this approach, the key agreement relies on
broadcasting
secret messages and distributed computations that culminate into the group key.
3.3.3.1 Burmester and Desmedt protocol(BD): Burmester and Desmedt [ ]
proposed a very efficient protocol that executes in only three rounds and is stateless.
Therefore, the same key management protocol is performed regardless of the type
of group membership change. BD is completely decentralized and has no sponsors,
controllers, or any other members charged with any special duties. The main idea in
BD is to distribute the computation among members, such that each member
performs only three exponentiations. This is performed in two communication
rounds, each consisting of n broadcasts.
Round 1. Member Mi generates its random exponent ri and broadcasts Zi = αri ;
Round 2. Mi computes and broadcasts Xi = (Zi+1/Zi−1)ri ;
Round 3. Mi computes the key Kn = Zi−1nri.Xn−ii ….Xn−2 mod p.
The group key calculated by each member is then Kn = αN1N2+N2N3+…NnN1 .
This protocol requires n+1 exponentiations per member. The drawback is the
requirement of 2n broadcast messages.
Attributes
protocols:





used to evaluate the efficiency of distributed key management
Number of rounds: The number of iterations required before the members commit
to a group key should be minimized to reduce processing and communication
requirements;
Number of messages. The number of messages exchanged between members in
order to compute the group key should be minimized to reduce unbearable delays.
Processing during setup. Setting up the group requires most of the computation
involved in maintaining the group, because all members need to be contacted;
DH exchange: Identify whether the protocol uses Diffie–Hellman (DH) [Diffie
and Hellman 1976] to generate the keys. The use of DH to generate the group key
implies that the group key is generated in a contributory fashion.
Leader required: Identify whether the protocol requires the existence of a leader
or leaders for the operation of the key agreement protocol
Protocol
ING
GDH
STR
DH-LKH
D-OFT
OCTOPUS
BD
No.
of No of messages
rounds
Multicast Unicast
DH key
0
n
n
log2n
0
0
n(n-1)
n-1
0
0
2log2n
3n-4
Yes
Yes
Yes
Yes
No
Yes
Setup
Leader
Reqd
No
No
No
No
No
Yes
n-1
n
n
log2n
log2n
2(n-4)/4
+2
3
2n
0
No
No
Others
Table III: Comparison Table of Distributed Key Management Protocol
Group Key
Management
Centralized
Pair wise
Key
GKMP
Broadcast
secret
Distributed Key
Agreement
Decentralized
Key
hierarchy
Secure lock LKH
OFT
ELK
Membership
Driven re-keying
SMKD
Hydra
Iolus
Time driven
re-keying
Kronos
Ring based
cooperation
ING
GDH
Hierarchical
cooperation
Octopus
STR
DH-LKH
D-LKH
D-OFT
Broadcast
cooperation
BD
Figure: Taxonomy of Group Key management Protocols
3.4 Authenticated n-party Key Agreement Protocols
The initial contributory group key agreement protocols were obtained by extending
Diffie-Hellman exchange method to groups of n-parties[1, 1996]. Drawback was that
it did not provide authentication of the parties involved and hence was prone to manin-the middle attacks Giuseppe Ateniese, Michael Steiner, and Gene Tsudik[2,2000],
studied the security services in the context of dynamic peer groups (DPG's). They
leveraged the results of [1] to develop practical and secure authenticated key
agreement protocols for DPG's viz Authenticated Diffie Hellman Key Exchange
protocol for groups A-GDH. Other relevant security features such as key
confirmation, key integrity and entity authentication were also considered here. AKE
protocols perform an initial key agreement IKA within a group. Once a group is
formed and initial key agreed upon, members may leave or new members may join.
Any membership change causes a corresponding group key change. Re-running the
full IKA for each membership change is expensive. Auxillary key agreement (AKA)
protocols handle issues like member addition, member deletion etc.
3.4.1
A-GDH.2 Contributory Key Agreement Protocol
Michael Steiner and Gene Tsudik [] developed an extension to the Diffie Hellman
key agreement method for n-parties which provides key authentication. Their
protocol is a contributory protocol that provides PFS, implicit key authentication, and
is resistant to known key attacks .
Protocol A- GDH.2:
Round i (1 ≤ i < n):
Mi → Mi+1 : {α(r1...ri)/rj |j € [1, i]}, αr1...ri
Round n:
Mn →All Mi: {α(r1...rn)/ri. Kin |i € [1, n[}
Upon receipt of the above, every Mi computes the group key as:
Sn(Mi) = α(r1...rn)/ri ·ri·K−1in = αr1...rn
The above protocol (A-GDH.2) achieves implicit key authentication in a relatively
weak form since the key is not directly authenticated between an arbitrary Mi and Mj
(i ≠ j). Instead, all key authentication is performed through Mn. This may suffice in
some environments, e.g., when the exact membership of the group is not divulged to
the individual Mi's. Another reason may be that Mn is an entity trusted by all other
members, e.g., Mn is an authentication server.
A-GDH.2 will result in all participants agreeing on the same key if Mn behaves
correctly. However, no one, including Mn, can be sure of other members'
participation. In fact, one or more of the intended group members may be “skipped"
without detection. Also, a dishonest Mn could partition the group into two without
detection by group members. On the one hand, we assume a certain degree of trust in
all group members (including Mn), e.g., not to reveal the group key to outsiders. On
the other hand, when it comes to group membership, Mn might not be universally
trusted to faithfully include all (and only) group members.
3.4.2
Distributed Group Key Distribution (DGKD): P Adusumill et all
[2005] proposed a new class of protocols called Distributed Group Key Distribution
with Authentication capability. This protocol does not assume any trusted third party
but allows equality of capability, responsibility and trustiness among all group
members. The protocol organizes the members in a tree structure and performs any
rekeying operation in just two rounds which do not need to be strictly synchronized.
Advantages:
 Provides strong authentication
 One key per node
 Independence of node keys
 Robust against transmission delay, network failure or compromise of node keys.
 No dependence on single entity, if a sponsor node fails a new sponsor for the
joining/leaving member is chosen by the other members.
3.5 Other Related Work:
3.5.1
Multi-party key agreement protocols based on multi-linear forms:
Boneh and Silverberg [6,2002] studied the problem of finding efficiently computable
non-degenerate multi-linear maps and presented several applications to cryptography
using multi-linear forms. The efficiently computable multi-linear forms would enable
one round multi-party key exchange, a unique signature scheme and secure broadcast
encryption with very short broadcasts. They proposed a one round multi-party key
agreement protocol from multi-linear forms, where security was based on the
hardness of multi-linear Diffie Hellman problems and the n-parties shared a session
key after one round of broadcast.
The disadvantage of their protocol is that this key is not authenticated and hence is
subject to the classic man-in-the-middle attacks.
Lee et.al.[7,2002] presented multi-party authenticated key agreement protocols.
Their protocols are also based on multilinear forms. They presented a single protocol
with (n+1) different methods for deriving a session key (MAK protocols). Their
protocols overcome the disadvantage of lack of authentication in Boneh and
Silverberg’s protocol by incorporating authentication into the protocol using
certificates. A certification authority (CA) is used in the initial set-up stage to provide
the certificates which bind user’s identities to long-term keys. Each entity verifies the
authenticity of the certificates he receives. If any check fails, then the protocol is
aborted. When no check fails, one of the possible session keys are computed.
Consequently, this system requires a large amount of computing time and storage.
Multi-linear forms: Definition
A map e : G 1n → G2 is an n-multilinear map if it satisfies the following properties:
3.5.2
(1) G1 and G2 are groups of the same prime order;
(2) if a1, . . . , an є Z and x1, . . . , xn є G1 then
e(x1a1 , . . . , xnan ) = e(x1, . . . , xn)a1···an;
(3) The map e is non-degenerate in the following sense: if g є G1 is a generator
of G1 then e(g, ..., g) is a generator of G2.
The efficiently computable multilinear forms would enable secure broadcast
encryption
with very short broadcasts and private keys, a unique signature scheme, and one
round multi-party key exchange.
The multi-linear Diffie-Hellman assumption.
This assumption says that giveng, ga1 , . . . , g an + 1 in G1, it is hard to compute
e(g, . . . , g)a a1···aan + 1 in G2.
3.5.3
A one round multi-party key agreement using multilinear forms:
Boneh and Silverberg [ ] proposed a simple one-round multi-party Diffie Hellman
key exchange protocol using multi-linear forms in which the secret session key for nparties could be created using just one broadcast per entity.
Protocol
 Assume A1…… An are n participants who want to share a key.

Each Ai selects a uniformly random integer ai є [1, p-1] and computes gai
and broadcasts it..
 Each Ai computes conference key KAi as :

KAi = en-1(g a1.. …gai-1, gai+1,……. gan ) ai = en-1(g.. ....g) a1…an є G2
Where en-1 : G1n-1 → G2 is an (n-1) multilinear map and G1 and G2 are two finite
cyclic groups of the same prime order p and g is a generator of G1.
The security of this protocol is based on the hardness of the multilinear DiffieHellman problem. This protocol however lacked authentication and was hence prone
to man-in-the –middle attack.
3.5.4
Multi-Party Authenticated Protocols:
Lee et al(2004) presented authenticated multi-party key agreement protocols with n+1
methods for deriving a session key. Their protocols were also based on multi-linear
forms A certification authority (CA) is used in the initial set-up stage to provide
certificates which bind user’s identities to long-term keys. The certificate for entity Ai
will be of the form :
CetAi = (IAi║
µAi║g║SCA(IAi║µAi ║g)):
IAi denotes the identity string of Ai, ║ denotes the concatenation of data
items, and SCA denotes the CA’s signature. Entity Ai’s long-term public key is
µAi = gxi , where xi € Zp is the long-term secret key of Ai. Element g is the public
value and is induced in order to specify which element is used to construct µAi
and the short term public values.
Each Ai broadcasts to all other entities the short-term public value gai along with a
certificate Cert Ai containing his long-term public key. Each Ai verifies the certificate
he receives. If any check fails, the protocol should be aborted. When no check fails,
one of the following possible session keys is computed
KAi = en-1(ga1 .... gai-1, gai+1,……. gan ) ai . en-1(gx1 . …gxi-1, gxi+1,…gxn ) xi
= en-1(g .... g ) a1…… an+ x1…. xn
3.5.5
ID-based authentication:
Another direction of research on key agreement protocols is identity based protocols.
In traditional PKI settings, key agreement protocols relies on the parties obtaining
each other’s certificates, extracting each other’s public keys, checking certificate
chains (which may involve many signature verifications) and finally generating a
shared secret. The technique of identity-based encryption (IBE) greatly simplifies this
process. Shamir in 1984 [ ] first formulated the concept of Identity-Based
Cryptography (IBC) in which a public and private key pair is set up in a special way,
i.e., the public key is the identifier (an arbitrary string) of an entity, and the
corresponding private key is created by using an identity-based key extraction
algorithm, which binds the identifier with a master secret of a trusted authority. The
advantage of ID-based cryptosystems is that it simplifies the key management process
which is a heavy burden in PKI based cryptosystems. Lee et all [2005] proposed IDbased multi party authenticated key agreement protocols based on multi linear forms.
Their protocols provided perfect forward secrecy, implicit and explicit key
authentication and key confirmation.
Security
features
Key
confirmation
Implicit Key
Authentication
Perfect
Forward
secrecy
Known
key
secure
Key
independence
Table IV: Comparison of security attributes for multi party key agreement
protocols
4. Summary:
Group key management protocols were placed into three main classes. Every class
has its own features, requirements and goals.






There is no unique solution that can achieve all requirements.
While centralized schemes are easy to implement they impose an overhead on a
single entity
Centralized and decentralized key management rely on symmetric encryption to
distribute group keys, so do not provide Forward secrecy
Protocols based on hierarchial sub-grouping are relatively harder to implement
and raise other issues such as interfering with data or imposing security hazards
on a group
Contributory protocols rely on modular exponentiations but have larger overhead
and are not scalable
The best solution for a particular application may not be good for another.
4.1 Motivation for future work :
1. In distributed multi party environments there is no clear distinction as to who
initiated a transaction, which parties should participate and finally who completes
the transaction.
2. Key management and trust management are effective only after a member is
allowed to join (access) the group. Without a secure admission process (which, at
the very least, should include the authentication of the prospective member),
secure key management has no meaning.
3. Currently static group access control is done via the flush mechanism which is
used by each current group member to acknowledge every membership change
(e.g., join, leave, partition, merge). A prospective member can join a group only
after it has received flush OK message from all current group members
4. Existing contributory protocols do not clearly tackle issues like dynamic group
membership control e.g who allows a member to join or leave.
5. Prioritized leave and join of members has not been considered. Currently all
members are assumed to have equal rights and equal trustiness. However at times
it may be desirable to have unequal rights for individuals. For e.g in a gaming
application, while a certain level of players have formed a group, if a member
playing at a lower level requests to join the group he should not be allowed.
6. Issues like reformation of a group based on pending requests have not been taken
into consideration in all the protocols so far.
7. Membership revocation issues i.e if a member is to be expelled from a group, who
should decide.
8.
References
1. "Diffie Hellman key distribution extended to groups," Michael Steiner, Gene
Tsudik, and Michael Waidner, In Third ACM Conference on Computer and
Communications Security. Mar. 1996, pp. 31{37, ACM Press.
2. "New Multiparty Authentication Services and Key Agreement Protocols"
Giuseppe Ateniese, Michael Steiner, and Gene Tsudik, Member, IEEE, In IEEE
Journal of Selected Areas in Communications, VOL 18, NO. 4, April 2000
3. “Key Agreement in Dynamic Peer Groups”, Michael Steiner, Gene Tsudik and
Michael Waidner, In IEEE Transactions on Parallel and Distributed Systems,
2000.
4. "Some Attacks upon Authenticated Group Key Agreement Protocols"
Oliver Periera, Jean-Jacques UCL Crypto Group, Belium, October 2002.
5. "On the Performance of Group Key Agreement Protocols" Yair Amir
Johns Hopkins University Yongdae Kim, University of Minnesota, Twin
Cities Cristina Nita-Rotaru, Purdue University and Gene Tsudik, University of
California, Irvine In "ACM Transactions on Information and System Security",
Vol. 7, No. 3, August 2004, Pages 457–488.
6. "Applications of Multilinear forms to Cryptography", D. Boneh and A.
Silverberg, Report 2002/080, http://eprint.iacr.org, 2002.
7. "Multi-party Authenticated Key Agreement Protocols from multilinear forms"
Ho-Kyu-Lee, Hyan-Sook Lee, Youn-Ran Lee, "App. Math. and Comp. Vol. 159 ,
2004, pp. 317-331, Seoul, Korea, 2002.
8. "An attack on some multi-party key agreement protocols" Kenneth G. Paterson,
Information Security Group, Royal Holloway, University of London, 2004.
9. "ID-based Multi-party Authenticated Key Agreement Protocols from Multilinear
Forms” Hyung Mok Lee, Kyung Ju HaP, and Kyo Min Ku1 J, Zhou et al. (Eds.):
ISC 2005, LNCS 3650, pp. 104-117, 2005, Springer-Verlag Berlin Heidelberg
2005.
10. “Identity based cryptosystems and signature schemes”, Shamir. In Advances in
Cryptology – Crypto’84, volume 0196 of Lecture Notes in Computer Science,
pages 47–53. Springer-Verlag, 1984.
11. “Tree-based group key agreement” Kim, Y.,Perrig, A., And Tsudik, G. 2004..
ACM Trans. Inf. Syst.Secur. 7, 1
12. “Group Key Management Protocol”, H. Harney and C. Muckenhirn.
(GKMP) Architecture, July 1997. RFC 2093.
13. “A Survey of Key Management for Secure Group Communication”, Sandro
Rafaeli and David Hutchison Computing Department, Lancaster University ACM
Computing Surveys, Vol. 35, No. 3, September 2003, pp. 309–329.
14. “Authenticated Group Key Agreement with Admission Control", Wen Hailong
Gu Dawu, InfoSecu'04, November 14-16, 2004, Shanghai, China
15. “Group Key Management Protocols: A Novel Taxonomy” Yacine Challal,
Hamida Seba, International Journal of Information Technology, Vol 2 Number 1
2005 ISSN:1305-2403
16. “Group Key Agreement Efficient in Communication”, Yongdae Kim, Adrian
Perrig and Gene Tsudik, IEEE Transactions on Computers, Vol. 53, No. 7, JULY
2004.