You are on page 1of 6

Keystone: A Group Key Management Service

Chung Kei Wong HRL Laboratories, LLC 3011 Malibu Canyon Rd Malibu, CA 90265 Simon S. Lam Department of Computer Sciences The University of Texas at Austin Austin, TX 78712
key management system called Keystone which uses a novel key graph technique 8] for scalable group key management. In Section 2, we illustrate the key graph technique by a simple example. In Section 3, we describe the architecture and operations of Keystone. In Section 4, we discuss how to e ciently and reliably update keys in Keystone. Conclusions are in Section 5.

Abstract
A major problem area in securing group communications is group key management. In this paper, we present the design and architecture of a scalable group key management system called Keystone. Keystone uses a novel key graph technique for scalable group key management. In Keystone, the authentication of client identity can be o oaded to one or more registrars to improve performance. For e cient and reliable key updates, Keystone uses UDP/IP multicast delivery with forward error correction (FEC) to reduce message loss, and provides an e cient resynchronization mechanism for clients to reliably update their keys in case of actual message loss. A prototype of Keystone has been implemented and its performance results are reported.

1 Introduction

Many emerging network applications (such as teleconference and information dissemination services) are based upon a group communications model. As a result, securing group communications becomes a critical networking issue. Recently, Internet Research Task Force (IRTF) has formed Secure Multicast Research Group (SMuG) 4] to investigate the problem of securing group communications. One major problem area is group key management which is concerned with the secure distribution and refreshment of keying material. A group key management system establishes and maintains group keys for groups of clients. A group key may be an encryption key, a signing key, a security association in IPsec, etc. In this paper, we describe the design and architecture of a scalable group

This research was performed at the University of Texas at Austin as part of the doctoral dissertation of Chung Kei Wong. Research sponsored in part by NSA INFOSEC University Research Program grant no. MDA904-98-C-A901 and National Science Foundation grant no. ANI-9977267. In Proceedings 1 A key server may be distributed and/or replicated to enInternational Conference on Telecommunications, Acapulco, hance reliability and performance. Mexico, May 2000.

Assume there is a trusted and secure key server 1 responsible for group access control and key management, and the key server uses key graphs 8] for group key management. A key graph is a directed acyclic graph with two types of nodes, u-nodes representing members and k-nodes representing keys. A member u is given key k if and only if there is a directed path from u-node u to k-node k in the key graph. Consider a group of nine members. Assume the key server uses the key tree (a special key graph) in Figure 1(a) for the group. In this group, member u9 is given three keys k9 , k789 , and k1?9 . Key k9 is called the individual key of u9 because it is shared with the key server only. Key k1?9 is the group key which is shared with every member, and k789 is an auxiliary key shared with u7 and u8 . Assume the key server changes the group key after each join/leave. For u9 to leave, the key server changes the group key k1?9 to k1?8 and the auxiliary key k789 to k78 . To distribute the new keys to the remaining members using a group-oriented rekeying strategy 8], the key server constructs the following rekey message and multicasts it to all members: fk1?8 gk123 , fk1?8 gk456 , fk1?8 gk78 , fk78 gk7 , fk78 gk8 where fk0 gk denotes key k0 encrypted with key k. Only the remaining members can update their keys by decrypting appropriate keys in the rekey message.

2 Key Graph

1

Application Data and the certi cates are signed directly by a Certi cate Data Processor Keystone Control Authority CA using a 1024-bit RSA key. is computationally expensive. and SHA digest Rekey Messages algorithm.perform application data functions. The SSL Data Multicast Manager System connection is established using RSA key exchange. Moreover. for u9 to join the group of eight members server server in Figure 1(b). i.11 00 00 11 00 11 111 000 k 000 111 000 789 111 k1-9 k-nodes u-nodes k123 11 00 00 11 00 11 111 000 000 111 k 000 111 000 78 111 k1-8 k123 k456 k456 u 9 joins k1 k2 k3 k4 k5 k6 k7 k8 k9 k1 k2 k3 k4 k5 k6 k7 k8 u 9 leaves u1 (a) before u9 leaves (after u9 joins) u2 u3 u4 u5 u6 u7 u8 u9 u1 u2 u3 u4 u5 u6 u7 u8 (b) after u9 leaves (before u9 joins) Figure 1: Key trees before and after a leave (join). and veri cation. Each client also has a data each client using an authentication protocol.0 from SSLeay (which is a publicly available implementation of SSL 3. such as SSL 3. and only one key For a key server to exercise access control.g. Keystone uses one or more Rekey Multicast registrars to o oad client registration from a key Requests 2 Machines running registrars can be added or server. Table 1 shows the server processing time to authenticate a client using SSL 3. and a key server becomes a bottleneck when the client registration rate is high. di erent registrars Key may use di erent authentication services to authenRegistrar Server ticate di erent sets of clients at the same time. Figure 2 shows a typical con guration of Keystone. triple DES (CBC mode) encryption. such as processor which is not a part of Keystone. There are many client control managers (one for Figure 2: Keystone architecture.. each client).3 A registrar client's identity with its individual key is called client 2 A key server and a registrar may be combined together into registration. sending requests and be authenticated. and then generate and share the client's processor uses group keys from its control manager to individual key which is used to protect future commu. fk789 gk78 The key graph technique is scalable to large dy. e. e..0. control manager" unless otherwise stated. A data SSL 3.3 In the balance of this paper. one or more registrars. Client Registration To solve this problem.Table 1: Server processing time (ms) for one SSL 3.. e. the key server constructs the following 512-bit 1024-bit 512-bit 1024-bit rekey message and multicasts it to all members: 512-bit client 7. signing. the identities of clients must for client control functions. to server. This process of associating a decryption.0 2].connection using SSLeay. 3 Keystone Architecture 2 .8 26 36 140 1024-bit client 10 29 42 146 fk1?9 gk1?8 . nications between them. putation and communication costs per join/leave increase linearly with the logarithm of the group size. one physical entity (a key server with embedded registrar).g.e. Both the client and server use certi cates (512-bit or Client Application 1024-bit RSA) to mutually authenticate each other.g.0 namic groups because the key server's average com. The key server may authenticate processing rekey messages.0). Pentium II Linux Ultra 1 Solaris Similarly. during initial group setup. The control manager of a client is responsible grant or deny a request. Client registration using an authentication proto. encryption. Rekey Messages Client removed dynamically.. we use \client" to mean \client col.

deleted. client list Figure 3: Registrar setup. f ind. rekey gkC Figure 5: Request and reply.3 Request and reply 3. the TCP channel is kept connected for the key server to send rekey messages to 4 3. After a key server S has been initialized. The client encrypts the request with its individual key. A request may have both join and leave operations or only re-synchronize operations. other authentication protocols can be used. The key server processes requests from clients. A request may contain operations to more than one group (if there are multiple groups). We use the notation x ! y : z to denote the sending of message z from x to y through a reliable channel. the operations of Keystone are described in detail. Then. The acknowledgment contains the result (granted or denied) of each operation requested and other information. The secret key kR is called registrar key and is used to encrypt/decrypt future communications between the registrar and the key server (through the TCP channel). (1) R . we assume the use of SSL 3. Figure 4 shows this client registration process. e. and distributes new keys to clients using rekey messages. The communications between the client and the key server For a new client C to register with a registrar R. The client makes a new TCP connection to the key server if there is no existing TCP connection between them. the secure channel and TCP connection between the client and the registrar are terminated. and sequence number. The individual rekey message consists of the keys to be added. We use the notation x . Keystone can deliver rekey messages to clients using either unicast or multicast (see Section 4). After decrypting and processing the request.1 Registrar setup 3. (1) C ! S : f request gkC (2) S ! C : f ack gkC . A client uses resynchronize operations to get the keys of currently joined groups. and sends the encrypted request to the key server through the TCP channel. but the TCP channel is kept connected.. kC (3) R ! S : f ID C . After that. after losing some rekey messages (see Section 4. There are three types of operations: join. 3 .authenticates the identities of clients and distributes an authenticated client's individual key to the client and the key server. one or more registrars are setup to handle client registration. otherwise. The client list contains the identities and ID numbers of clients but does not contain access control information. After having registered. Currently.0 for two entities to mutually authenticate and establish a secure communication channel. the registrar encrypts the client's individual key and ID number with registrar key kR . In the following. The key server generates a secret key kR and sends the secret key and a client list to the registrar through the secure channel. and sends them to the key server. and the notation x ) y : z to denote the sending of message z from x to y through a secure channel. To be more concrete in the descriptions.4 After that. are also protected from modi cation and replay attack by MAC the client makes a TCP connection to the registrar. a client C may send requests to the key server S . changes keys. the secure channel is terminated. Each registrar R makes a TCP connection to the key server S . kC gkR Figure 4: Client registration. the key server encrypts a reply with the client's individual key and sends the encrypted reply to the client through the TCP channel. y to represent the mutual authentication and establishment of a secure channel between x and y. or updated by the requesting client. and then they mutually authenticate and establish a secure communication channel over the TCP connection using SSL. The reply consists of an acknowledgment and an individual rekey message. However. The registrar generates the client's individual key kC and sends the client its individual key and ID number through the secure channel. and re-synchronize. the TCP channel is terminated if the key server does not use the TCP channel to send rekey messages to the client (see Section 4). leave. R : using SSL (2) R ) C : ID C . See Figure 5.2 Client registration (1) C .g.2). S : using SSL (2) S ) R : registrar key kR . After that. Figure 3 shows this registrar setup process. and then they mutually authenticate and establish a secure communication channel over the TCP channel using SSL.

104 0. the keeping a TCP connection to each current member. Then.040 0.001 0.1 FEC + UDP/IP multicast Pm (s.000 0. r = For \rs2". 6].5 Then.000 0. i.271 0. 0.590 0. r. r = 1 2 4 2 3 5 3 4 6 4 4 6 5 4 7 Number of original units. = 0:0).e. a probability less than 0.000 (a) p = 0:1 0.005 0.099 0.344 0. Keym r = s ] with three di erent values. p ) for the repair scheme To provide e cient and reliable key updates..003 0. We can bound the message loss probability by computing the number of repair units needed from the 4.832 0.a repair scheme. If no repair packet is used (i.672 0. For rekey message from any s of the s + r original and reliable key updates.488 0. We use the notations \rs1" A key server can e ciently send a rekey message to a and \rs2" to denote the repair schemes to make large number of clients using UDP over IP multicast. Pi= On the other hand. Our implementation uses the IP packets. 0.061 0.000 0.100 0.613 0.002 (b) p = 0:2 8 0.190 0. p) equation. called parity units ) are computed from the original units.004 0. s 6 7 8 9 10 11 12 5 5 5 6 6 6 7 8 8 9 9 10 10 11 13 7 11 s]. with probability p for a receiver (which is about 10%Keystone can use TCP to deliver rekey messages by 20% for UDP packets over MBone 9]). a number of repair units (also and sends rekey messages to other clients. Table 2 shows P ( s.004 0.. the rekey message is less likely to be lost.469 0. Keystone also and the message loss probability increases. Keystone uses 6 In Table 2.651 0.000" (which is not probability zero). UDP is unreliable and there may be packet tively. delivery mechanism. The probprovides an e cient re-synchronization mechanism ability P ( s.050 0. a key server may use a reliable repair units.004 0.016 0.0. r. an bility since a receiver needs to get all IP packets in IP host machine is only required to receive at least a 576-octet order to reconstruct the message.008 0. s 4 5 6 7 0.001 Table 2: Message loss probability Pm (s. r.5.002 0.0005 is denoted by forward error correction (FEC) technique 5]. Each unit is sent using UDP over IP multicast. r. r.per join/leave request for di erent repair schemes on tation occurs and the message is broken into several a Ultra 1 machine.000 0.010 0.010 0. This increases the message loss proba5 Although most path MTUs are as large as 1500 octets. e.044 0.001 9 0.001 0. IP datagram. TCP or a reliable multicast Assume UDP packet losses are independent and protocol 1.410 0. p) 0:001 for p = 0:1 and p = 0:2. p) for the receiver is This approach is clearly not scalable to large groups.g.006 0.= 0:0 = 0:5 = 1:0 = 0:0 = 0:5 = 1:0 1 0. To reduce message loss probability. The number of repair units r is a function of the number of original units s. 4 Key Updates 4 .200 0. r. for clients to reliably update their keys in case of acm more repair units are used. a key server dis.360 0.0.000 0. if a rekey message is larger than Table 4 shows the average server processing time the maximum transmission unit (MTU). Pm (s. Since a receiver can re-construct the tributes new keys to clients using rekey messages.738 0. IP fragmen. stone uses UDP over IP multicast for e cient rekey 6 and 1.893 0. e cient reliable multicast proto+r ( s + r ) pi (1 ? p)s+r?i Pm (s.790 0.570 0. See Table 3.027 3 0. losses.028 0.040 2 0. and the function is called After changing keys in a key graph. Each \0. p ) decreases when increases.056 0. message loss probability Pm (s.001 10 0.073 0.866 0. message delivery and forward error correction (FEC) a larger rekey message is partitioned into more units.000 0.e. 14 7 12 15 7 12 Table 3: Number of repair units r for repair schemes \rs1" and \rs2". 3.010 0. to send rekey messages to clients. r. the client.017 Number of original units. given by the following equation. tual rekey message loss. respecHowever. Note that the key server also constructs rekey message is partitioned into one or more 512octet units. p) where r = For \rs1". Moreover.522 0.058 0. p) = s r+1 i cols are not available for large scale use. technique for message loss reduction..086 0.009 0.

Work in progress. Moreover. the key server encrypts the current group and auxiliary keys (and possibly some previous group keys if needed) for each requested group with the client's individual key. the use of FEC increases the processing time by at most 1.3 51. E ective Erasure Codes for Reliable Computer Communication Protocols.4 ms to 2. 6] Sanjoy Paul. Instead of using message retransmission.6 51. For a key server to distribute new keys to a large group of clients. First. This approach is ine cient especially when the number of lost rekey messages is large. Lam.5 51. One straight-forward way to deal with lost rekey messages is for a client to request the lost rekey messages to be re-transmitted.2 512 51. When a client detected rekey message losses. Second.0 sages with only a slightly increase in the server pro52. The use of FEC substantially reduces (by or51. To decrease the message loss probability. 4] Internet Research Task Force (IRTF). and key server. Lin. and sends the encrypted keys back to the client. Cheriton. Sabnani. Reliable Multicast Transport Protocol (RMTP).H. the server processing time for a resynchronize request is only 2. Keystone provides an e 52. UDP over IP multicast is e cient but not reliable (with a loss probability around 10% to 20% over MBone). After receiving a re-synchronize request. . In Proceedings of ACM SIGCOMM '95.0 51. April 1997. Moreover.3 51.C. Krishan K. Freier. Holbrook. and Supratik Bhattacharyya.3 4096 51. 3] Hugh W. We observe that for group size upto 8192. Sandeep K. September 1998. Keystone uses forward error correction 8192 (FEC). B. Ching-Gung Liu..com/community/smug/.4 51.6 51. In Proceedings of ACM SIGCOMM '95.6 ms. Vancouver.7 52. Log-Based Receiver-Reliable Multicast for Distributed Interactive Simulation. 5] Jorg Nonnenmacher. The rekey message signing time is about 46. and Paul C. three components: client control manager. Parity-Based Loss Recovery for Reliable Multicast Transmission. most of these recovered rekey messages contain old auxiliary keys that are no longer needed by the client. and 512-bit RSA digital signature. Kocher. and Don Towsley.software erasure coder by Rizzo 7] to generate repair units.4 51. In Proceedings of ACM SIGCOMM '98. e. 8] Chung Kei Wong.0. the use of FEC substantially decreases the message loss probability with only a slight increase in the processing time. Steven McCanne. 7] Luigi Rizzo. 4. MD5 message digest.9 52. and David R. and Lixia Zhang. in a long loss burst that lasts for several seconds or minutes 9].. http://www.1 ms which is about 2% of the total processing time. registrar.0 cessing time. We measured the average server processing time for group-oriented rekeying using DES-CBC encryption.4 ders of magnitude) the loss probability of rekey mes51. IEEE Journal on Selected Areas in Communications. The Secure Multicast Research Group (SMuG). John C. Van Jacobson. In Proceedings of ACM SIGCOMM '97.9 51. Singhal.7 50. Netscape Communications. 5 Conclusions We have designed and implemented a group key management system called Keystone which consists of 5 1] Sally Floyd. = 0:0 = 0:5 = 1:0 \rs1" \rs2" 256 50. 1995.9 Group size 1024 2048 51. Since no expensive digital signature is needed.8 50. April 1997.g.1 52. Keystone provides an e cient re-synchronization mechanism for clients to reliably update their keys in case of message loss. November 1996.8 52. Therefore.9 50. Philip Karlton. 2] Alan O. Secure Group Communications Using Key Graphs. The expensive client registration process can be o oaded from a key server to one or more registrars.4 Table 4: Average server processing time join/leave request. Computer Communication Review.5 51.5 ms on a Ultra 1 for a group with size from 256 to 8192 using DES-CBC encryption. Ernst Biersack.2 Re-synchronization References Since FEC does not provide 100% reliability. di erent registrars can be used to provide di erent authentication services for di erent sets of clients (at the same time). In other words. 1997. it sends a re-synchronize request to the key server.5 cient re-synchronization mechanism for clients to re(ms) per liably update their keys in case of actual message loss. a key server (or a repair entity) needs to store many rekey messages.7 51. rekey messages may still be lost.0 51.2 51. and Simon S. 15(3).5 51. the client registration rate can be increased by using more machines to run registrars.ipmulticast. A Reliable Multicast Framework for Light-Weight Sessions and Application Level Framing.4 51. 1995. The SSL Protocol Version 3. Mohamed Gouda.

In IEEE Global Internet Conference. 6 . 1996.9] Maya Yajnik. Packet Loss Correlation in the MBone Multicast Network. Jim Kurose. and Don Towsley.