ORMAT 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.
- 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.1ORMAT 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.
Figure 1: LKH Tree
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 into k56, sends k56 to u6 encrypted with k6. TEK is updated into TEK’ and sent to {u1,u2,u3,u4} encrypted with k1234 and to u6 encrypted with k56 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 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.
3.1.3.3 ORMAT 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 / Secrecy / 1-effects-n / Re-Key Overhead / Storage OverheadJoin / Leave / Key Server / Member
Back / Forw / Multicast / Unicast
GKMP / Y / N / Yes / 2 / 2 / 2n / n+2 / 3
LKH / Y / Y / Yes / log2(n)-1 / log2(n)+1 / 2n-1 / log2(n)+1
OFT / Y / Y / Yes / log2(n)+1 / log2(n)+1 / log2(n)+1 / 2n-1 / log2(n)+1
Secure Lock / Y / Y / No / 0 / 2 / 0 / 2n / 2
ELK / Y / Y / Yes / 0 / log2(n)+1 / -- / 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.
ORMAT 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: