MULTI-PARTY AUTHENTICATION IN DYNAMIC SETTINGS
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.
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
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
[15] 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. 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}.
TEK
K1234
K12
K1
U1
K34
K2
U2
Figure
K3 1.
U3
K56
K4
U4
K5
U5
K6
U6
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 int
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
2n
n+2
Log2(n)+1
2n-1
Log2(n)+1 Log2(n)+1 2n-1
2
0
2n
3
Log2(n)+1
Log2(n)+1
2
Y
Y
Yes
0
Log2(n)+1 --
Log2(n)+1
Leave
Storage Overhead
Key
Member
Server
2n-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 multi-
round 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.
STR Protocol
The STR protocol [Steer et al. 1990; Kim et al. 2004a] 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
LN3
M4
IN2
LN2
M3
LN1
M1
M2
Figure: 4 STR Tree
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.
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
K3
U3
U4
Figure: DH-LKH Tree
Broadcast-Based Approach In this approach, the key agreement relies on broadcasting
secret messages and distributed computations that culminate into the group key.
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 used to evaluate the efficiency of distributed key management protocols:





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 Protocols
Centralized and distributed key management rely on symmetric encryption to distribute
group keys, while contributory protocols rely on modular exponentiations. Therefore, the
former do not provide Perfect Forward Secrecy. However, such protocols scale to large
groups and have a lighter overhead than contributory ones.
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
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 man-in-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.
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.
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.
Other Related Work:
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:
(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.
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 n-parties
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….. ....ga) 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 Diffie- Hellman
problem. This protocol however lacked authentication and was hence prone to man-in-the
–middle attack.
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
1. KAi = en-1(ga1 ….. gai-1, gai+1,……. gan )
gxi+1,…gxn ) xi
= en-1(g ….. g ) a1…… an+ x1…. xn
ai
. en-1(gx1 ….. gxi-1,
2.
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 ID-based 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
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
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
Distributed key management is not scalable
The best solution for a particular application may not be good for another.
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. Existing contributory protocols do not clearly tackle issues like dynamic group
membership control e.g who allows a member to join or leave.
3. 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.
4. Issues like reformation of a group based on pending requests have not been taken
into consideration in all the protocols so far.
5. Membership revocation issues…….if a member is to be expelled from a group
who should decide.
6.
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
6.
7.
8.
9.
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.
"Applications of Multilinear forms to Cryptography", D. Boneh and A.
Silverberg, Report 2002/080, http://eprint.iacr.org, 2002.
"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.
"An attack on some multi-party key agreement protocols" Kenneth G. Paterson,
Information Security Group, Royal Holloway, University of London, 2004.
"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.