SECURING COMMUNICATION OF DYNAMIC GROUPS IN DYNAMIC ...

SECURING COMMUNICATION OF DYNAMIC GROUPS IN DYNAMIC NETWORK-CENTRIC ENVIRONMENTS* Roger I. Khazan†, Robert A. Figueiredo, Ran Canetti‡, Cynthia D. McLain and Robert K. Cunningham MIT Lincoln Laboratory 244 Wood Street, Lexington, MA 02420-9108

ABSTRACT We developed a new approach and designed a practical solution for securing communication of dynamic groups in dynamic network-centric environments, such as airborne and terrestrial on-the-move networks. The solution is called Public Key Group Encryption (PKGE). In this paper, we define the problem of group encryption, motivate the need for decentralized group encryption services, and explain our vision for designing such services. We then describe our solution, PKGE, at a high-level, and report on the prototype implementation, performance experiments, and a demonstration with GAIM/Jabber chat. INTRODUCTION Dynamic groups are integral to the DoD’s vision of Network-Centric Operations and Warfare (NCO/W); they are fundamental to many emerging military applications, such as group chat, voice and video conferencing, collaborative workspaces, collaborative planning, and command-andcontrol on the move applications. Existing schemes for securing communication of dynamic groups generally follow one of two approaches: they either utilize external (centralized) group keying services, or they construct group keys using multi-round group keying protocols that are executed by all group members (see for example, [1-6]). Neither of the two approaches is appropriate for dynamic tactical environments, with intermittent connectivity and limited bandwidth. In this paper, we propose a new approach and describe a practical solution for securing communication of dynamic groups in dynamic network-centric environments, such as airborne and terrestrial on-the-move networks. ∗

† ‡

This research was sponsored by the United States Air Force under Air Force Contract FA8721-05-C-0002. Opinions, interpretations, conclusions, and recommendations are not necessarily endorsed by the US Government.

Our overall approach and the specific solution are driven by the realities of dynamic tactical environments and by the security needs of group-oriented military applications. Our three fundamental design goals are 1. High-availability and robustness; 2. Low communication overhead; and 3. Simplicity of the API and the underlying design. We achieve these goals by combining a highly-available stateless group encryption scheme with a number of stateless and stateful optimizations. The resulting scheme is called Public-Key Group Encryption (PKGE). The stateless scheme is an extension of a recent breakthrough result for “Collusion Resistant Broadcast Encryption with Short Ciphertexts and Private Keys1” by Boneh et al. [7]. This scheme is decentralized and stateless: it allows users to encrypt messages to any sets of users using only pre-placed keying material, without having to exchange any protocol messages with other users or with an external server. The user sets can be small or large. The remarkable property of the stateless scheme by Boneh et al. is that the encryption space overhead is a small constant, independent of the user set size! In comparison, the standard solution of encrypting messages under each receiver’s public key has the encryption space overhead that is linear in the user set size. Our optimizations are layered on top of this stateless scheme and reduce its, already low, computation and bandwidth overheads even further. The system is designed to use the stateless scheme until the optimized modes get fully established; thus the group encryption service is not blocked while the optimized modes are being established. As a consequence, PKGE is highly-available and robust, and it imposes low communication and computation overheads. The high availability and the low communication 1

Roger Khazan is the contact author (781-981-5976; rkh @ mit.edu). Ran Canetti is a visiting scientist at the MIT Computer Science and AI Laboratory and a research scientist at the IBM T.J.Watson Research Center, Yorktown Heights, NY, USA.

1 of 8

“Collusion resistant” means that users outside of the intended receiving set cannot combine their keys to break the scheme; “short ciphertexts” means that the encryption space overhead is small; and “short private keys” means small local secure storage requirements.

•

overhead are especially critical in dynamic tactical environments. Summary of contributions •

•

•

•

A novel design approach: The stateless-stateful layering was described above. Also, PKGE leverages the communication facilities of its applications. Thus, PKGE does not implement its own communication, but instead communicates state information by piggybacking it onto application messages. This keeps the design simple and allows us to focus on the group encryption problem.

Decrypt(c) Æ (m or error status): where c is the ciphertext and m is the resulting decryption. If decryption fails, an appropriate error code is returned.

Depending on the implementation, ciphertext c may have certain structure, such as include the identity of the sender, the key encapsulation block, the encryption of the message under the encapsulated key, the signature block, etc. In addition to these two main methods, other methods can be exposed to the application, such as AddUserCertificate and RemoveUserCertificate.

Extensions and practical refinements to the stateless scheme by Boneh et al. [7]. These include efficient ways to achieve key roll-over and Perfect Forward Security, and Chosen-Ciphertext Security. We will mention these extensions briefly, as they are the subjects of separate publications, currently under preparation. We have also worked out a number of practical issues and introduced several scheme refinements.

It may also be convenient to allow the application to use named groups instead of sets in Encrypt(group, m); if this method is provided it needs to be accompanied with the following group management methods: NewGroup, AddMember, and RemoveMember. In this paper, we will use the terms set and group interchangeably.

Prototype implementation: We have implemented a prototype PKGE service in C. The implementation uses X.509 certificates. In addition to group encryption, the service implements sender authentication, message integrity, and anti-replay protection. (We are currently tuning the implementations of the stateful optimizations and are testing and evaluating PKGE.)

•

Confidentiality: Communicated data is protected from non-members.

•

Sender authentication and non-repudiation: Participants can authenticate message senders.

•

Membership dynamism: It is possible to form groups and to add/remove participants.

A PKGE plugin for the GAIM chat client. In order to demonstrate our solution, we have integrated our PKGE prototype with GAIM, a popular chat client.

•

Perfect Forward Security: Compromise of long term keys of a member does not compromise earlier communication of that member.

The GAIM plugin and the PKGE prototype can run on Windows XP under Cygwin, Linux, and Mac OS X.

•

Group Forward and Backward Secrecy: Secrecy of new communication from revoked members, and old communication from new members.

PROBLEM STATEMENT

Intended Deployment Environment

Our goals are to design and develop a localized group encryption service that allows its application clients to encrypt data/messages to sets of recipients. The service should have a simple API and guarantee appropriate security properties. It should also be reasonably simple and be appropriate for deployment in tactical NCW environments. Finally, the design should allow for a hardware implementation in the future. Simple Interface At the high-level, two main methods of this group encryption service are •

Security Properties

Encrypt(set, m) Æ c: where set is a set of participant identifiers to which message m is to be encrypted. This method returns the corresponding ciphertext c.

We make the realities of tactical environments to be a part of the problem statement. Machines can crash, and when they do they lose their volatile (RAM) state, including the states of the application and PKGE processes. Recovering applications and PKGE processes initialize to their initial state. The underlying communication network is dynamic. Connections are intermittent, and typically have lowbandwidth and possibly high-latency. The specific communication services that are available and are used by applications vary; they may be TCP or UDP, IP multicast, broadcast, or some higher-level service, such as reliable multicast.

2 of 8

Important performance properties Given these realities of the intended deployment environment, the following performance goals are of high-priority:

These are the components necessary for a complete solution. It is important to understand how they are involved, and how they influence requirements for group encryption, but we are not advancing these areas.

1. High availability and robustness; 2. Low communication overhead: message size (bandwidth) and number of message exchanges (rounds); 3. Simplicity of the design. Computation and storage overheads are not a primary concern, as long as they are realistically reasonable. Also, we are against “paranoid” rekeying, such as changing group keys whenever a member simply looses or regains connection, which in our environment may happen often due to underlying network instabilities. (This is in contrast to most contributory group-keying schemes, which seem to treat network fluctuations as membership changes and hence rekey whenever disconnects and reconnects occur.) Complementary and orthogonal capabilities Our goals focus narrowly on supporting encryption of messages to groups. In addition, there are several important capabilities that have to be worked out for tactical NCW networks: •

Networking and communication, such as routing, monitoring, and message transmissions (point-topoint, multicast, etc.).

•

Membership policy and membership management, as well as admission and revocation policies. Some of these are (or should be) implemented by applications, others should be implemented as generic stand alone services. For example, chat applications typically implement their own membership and access control mechanisms.

•

•

Sender authentication and PKI (and also nonrepudiation, traitor-tracing, certificate revocations policies and enforcement, etc.). We can use available non-group solutions. In particular, our current PKGE prototype uses X.509 certificates for sender authentication. Optionally, we can include a keyed-hash message authentication code (HMAC) of messages using the group key to provide a quick and cheap group authentication mechanism. Auditing, key escrowing, and message archiving. Existing solutions can be used here. In our scheme public-private keys are generated by the authorized authority, such as the NSA; this authority holds all the keys in escrow and can decrypt and audit recorded communication.

EXTERNAL VERSUS LOCAL SERVICE A large body of research to-date has focused on external group keying services (see for example, IETF Multicast Security Working Group [1] and [2, 6]). These services have either a centralized group key manager or several distributed managers, whose task is to manage group keys and to provide users with the keys they can use to secure their communication. These services have to be trusted and secured because they know all the keys of all the groups and all the user sets. Such external services are appropriate for wired, wellbehaved networks. However, in dynamic NCW environments, it is critically important to also have solutions that do not rely on the presence of online, external group keying servers. There are several reasons for this: •

Availability: Relying on a single external group keying server for real-time communication is potentially problematic; consider natural network dynamism and malicious DoS attacks. It is also challenging to simply replicate and distribute an external server to multiple locations, because of synchronization issues and because servers know everyone’s keys/secrets.

•

Some networks are disconnected or stealthy: For example, consider a group of US fighter jets joining up with coalition forces; or special ops paratroopers linking up with coalition buddies on the ground.

•

Urban environments often have limited connectivity because of signal blockage.

•

Robustness: even if our applications can rely on an external group keying service, we still need to provision for the possibility of this service being unavailable (due to any number of factors).

•

Simplicity: Not having a dependency on an external service makes the design and deployment simpler. This is just like securing point-to-point communication (as done by IPSec and TLS). External services are not used to obtain point-to-point keys, rather keys are obtained through key agreement protocols, such as Diffie-Hellman or MQV.

To summarize, there is a good case for having localized group encryption services in dynamic NCW environments.

3 of 8

OUR VISION FOR DESIGNING SUCH SERVICES We now present the high-level vision for how a localized group encryption service that is tailored for the deployment in tactical NCW environments should be designed. •

•

•

•

Highly-available foundation: Start with a simple, robust, highly-available scheme. Use pre-placed data; storage is cheap, especially storage that does not need to be secure. This scheme may not be the most efficient in bandwidth or computation, but it should be simple, robust, and highly-available. Optimizations: On top of this basic scheme layer stateful optimizations that make the overall system more efficient. For example, reduce bandwidth and computation with session keys and group identifiers. The important thing is to remain available. Do not block service while establishing these optimized modes of communication – keep using the basic scheme until the optimized modes are established and it is safe to switch over. Focus on the right parameters: Availability, communication overhead, robustness, and simplicity. It is less critical to worry about storage and computation overheads, as long as they are reasonable. Perfect Forward Security is an important property and should be implemented according to the external key renewal policy. This policy can be based simply on time (e.g., refresh keys daily) and/or the amount of data communicated with a given key.

online key server – any user can encrypt messages to any set of users using pre-placed public keys. High-level overview of PKGE Here we sketch out how PKGE could be setup and then used by applications. In general, PKGE can be applied to group-oriented communications among various applications, low-level processes, or machines. For simplicity of the description we focus on groups involving people, as those involved in text chat or email. There are three parts to this description: a) initial offline system setup, in which the system is generated; b) user registration, in which individual users join the system and are given their secret keys; and c) online operations, in which a local PKGE service can be used by users’ applications to encrypt messages to sets of users and to decrypt these messages. The initial description of PKGE does not include our extension for Perfect Forward Security; this extension is described later in the section. a) Initial offline system setup System generation and setup is done once by an authorized authority, such as the NSA. It involves the following steps: •

Pick the UID space: Decide on the size of the user id (UID) space to support for the lifetime of the system. For example, |UID| = 107, that is, ten million users.

•

Pick constants: Pick certain system-wide parameters and constants, and generate certain secret constants.

•

Generate a public key vector PKV: This vector is large; it has twice the number of elements as |UID|. The size of each element depends on the system-wide parameters chosen. A possible size of PKV is 2 x |UID| * 64 bytes ~= 1.2 GB.

PUBLIC KEY GROUP ENCRYPTION PKGE builds on a recent breakthrough scheme called “Collusion Resistant Broadcast Encryption with Short Ciphertexts and Private Keys” by Boneh, Gentry, Watters [7]. This scheme uses Bilinear Map Elliptic Curve Cryptography, which nowadays is utilized in numerous crypto applications.2 The security of the Boneh scheme is based on the complexity of “Bilinear Diffie-Hellman Exponent” assumption, which is a natural extension of the Bilinear Diffie-Hellman assumption; the latter was proved to hold in generic bilinear groups.

b) User registration When individual users register, they are given the following information, which can be stored on a CAC or a USB dongle: •

A unique user identifier i from the UID space. This identified has to be certified by a recognized Certificate Authority; the most natural thing is to make it a part of the standard DoD X.509 certificate. In the paper, we refer to users by their ids.

•

Secret key di, corresponding to the user’s identifier i. A possible size of a secret key is 64bytes.3

The main benefits of the Boneh et al. scheme are a) the small encryption size overhead; and b) the absence of an

2

Perhaps the most well-known application of bilinear-maps is in Identity-Based Encryption. A general property of elliptic-curve crypto systems is requiring smaller keys for the same or higher level of security than traditional crypto systems. Bilinear maps also enable solutions that previously have been thought impossible.

3

4 of 8

In actuality, each user gets multiple secret keys to support Perfect Forward Security and key rollover – we discuss this later.

•

A part of the public key vector, PKV. How large a portion is given to the user depends on how the system is deployed. For example, if only 105 users are expected to register in the first deployment stage, the users need to store only a ~12MB portion of PKV. In the worst case, when all 107 users have registered and any user can talk to any set of users, the users need to have the entire PKV. But even in this worst case, 1.2 GB is not prohibitive (considering the 4GB capacity of modern USB “keychain-memory” devices and Moores law).

c) Online operations: Now, a user’s application (such as a text chat client) can use its local PKGE service to encrypt messages M to any set of users from the UID space, and then send the encrypted message to them. When the application of a user i in S receives this encrypted message, it passes the message to its local PKGE service, which decrypts M using the user’s secret key di. More specifically, the local PKGE service generates a random key K, encrypts message M with K, and then encrypts (or encapsulates) key K to the set S of users. This encapsulation is done in such a way that only users in S can decrypt key K using their secret keys. Users not in S cannot obtain K even if they pull together their secret keys. The key encapsulation and de-encapsulation algorithms are based on [7]; they use elements from the public key vector PKV. (The actual PKGE messages are also authenticated and have message integrity and anti-replay blocks.) What is new here? Small key encapsulations: One of the critical issues here is the size of key encapsulations. A straightforward way to implement key encapsulation is to encrypt key K separately under the public key of each user in set S; this is exactly how secure email is implemented nowadays. The size of such an encapsulation is linear in |S|. For example, for 64-byte public keys (the security of which for Elliptic Curve algorithms is roughly equivalent to that of 256-bit symmetric key algorithms [8]) and for 50 users, each key encapsulation would be 3200 bytes. In bandwidth-limited environments transmitting such large key encapsulations may impose an unacceptably high overhead. Instead of the straightforward solution, PKGE encapsulates keys using the scheme by Boneh et al. [7]. As the result, key encapsulations take small, constant size, independent of the size of set S. Specifically, for a reasonable choice of parameters, PKGE key encapsulations are only 128 bytes for stateless operations! Stateless operation: The total space overhead for a PKGE encrypted-and-signed message is 200-300 bytes; this overhead is due to the key encapsulation, signature, formatting,

and symmetric-encryption overhead. Because the 200-300 byte overhead is small (compare to 3200 bytes), for some applications, it is reasonable to consider supporting purely stateless operations, in which the key encapsulation is added to each message. This way, users can successfully decrypt each message regardless of whether they have received prior messages. Stateless operations are important for situations when message loss is possible, and they also avoid complexities of stateful protocols. However, for communication-intensive applications operating in low-bandwidth networks, even the 200-300 byte overhead on each message can be prohibitive. Stateful optimizations: PKGE adds a number of stateful optimizations on top of the stateless scheme. In particular, the stateless scheme is used to distribute the same symmetric 32-byte set-key to the users of a given set S. This setkey is then used by the users of S to encrypt messages that are sent to set S. We use the term set-key instead of a more commonly used term group key to highlight the fact that these keys change when groups’ memberships change. PKGE continues to use the stateless scheme while establishing the set-key, until it is determined to be safe to switch to the optimized mode. Whenever set-keys expire or the application needs to send messages to new sets of users, application messages and new keys are communicated using the stateless scheme. Sets can change for example when existing user’s leave or their membership is revoked or when new users join the group. Our PKGE prototype provides a pessimistic and an optimistic option for establishing set-keys. The pessimistic option continues to use the stateless scheme until explicit set-key acknowledgments are received from all the users. The optimistic option switches to the optimized mode immediately after proposing a set-key; as the result, it has a much smaller communication overhead. The optimistic option is especially appropriate for the applications that utilize reliable communications (e.g., TCP/IP). Piggybacking state onto applications messages: PKGE is a local service used by applications to encrypt and decrypt group messages. PKGE does not have any direct communication capabilities (at least in the current prototype version); this was a very interesting design decision for us. As such, it can be used by a wide variety of applications and in various settings. In order to communicate state information as part of its stateful optimizations, PKGE piggybacks state information onto applications messages. There is also a way for PKGE to ask the application to send an empty message to the current group of recipients, so that PKGE can piggyback state information. (This part of the design is has not been finalized and is work in progress.)

5 of 8

Perfect Forward Security (PFS) We now discuss PFS and briefly describe how PKGE implements this property. Definition: Perfect Forward Security (or Secrecy) is the property that compromise of a user’s long-term key does not compromise communication of earlier runs; PFS was originally introduced by Diffie et al. [9]. Public-private encryption schemes are not PFS: It is a known fact that standard public key encryption, in which user’s public keys are used to encrypt messages, does not provide PFS. To use secure email as an example: Imagine that an adversary is able to record email messages that are encrypted to a given user with his/her public key. Then months or years later, the adversary can succeed in breaking into the user’s computer system and stealing his/her private key. The adversary is able to use this private key to decrypt all those captured messages. The problem stems from the fact that public-private key pairs are long-term and it is cumbersome to frequently roll-over users’ public keys. The stateless scheme of Boneh et al. [7], which we use for key encapsulation, is also a public-key-based scheme. As such it is not PFS. If an adversary captures group messages for months and then later gets one of the user’s secret key di, the adversary can decrypt all the captured messages. How can this problem be avoided? One possible solution is to implement PKGE in a temper-resistant hardware. Using temper-resistant hardware is a good idea in general. However, it still leaves the problem of the same long-term public-private key-pairs being used for encryption over long periods of time. Past messages can be broken through crypto-analysis or by using captured hardware. Thus, it is important to be able to periodically roll-over encryption keys (e.g., daily). Another possibility is to use a fresh public/private keypair for each user for every day of the year. However, the problem with this simple key-replication approach is the size of the new public key vector, PKV. Having daily public keys for each user would mean that a year-worth PKV would be ~440GB; totally impractical! Our Solution: Forward Secure PKGE: We invented a practical PFS extension of the Boneh et al. scheme. Our solution amortizes the cost of public key replication for all the users. As the result, the size of PKV hardly changes. In our solution, each user i is given multiple secret keys {di,t}, each corresponding to day t. If a single key di is 64 bytes, then a year-worth of secret keys takes only ~23KB. The user’s public keys PKV[i] remain the same. However, PKV now has additional system-wide public constants Vt,

each corresponding to day t; a year-worth of these constants takes ~23KB. PKGE encryption uses the users’ public keys and the current system-wide public constant Vt.; PKGE decryption uses the users’ corresponding secret keys di,t. The security proof of this PFS extension is done by reducing it to one of the proofs in the Boneh et al. paper [7]. Every year, the PKGE authority (e.g., the NSA) can compute new system-wide public constants and make PKV updates available. Also, every year, users can get new batches of secret keys from the authority; this update can be done at the same time the users renew their X.509 certificates. To implement PFS, PKGE erases previous day’s secret key each day. This way, if an adversary compromises the user’s PKGE device, the device has no prior keys to help the adversary decrypt earlier communication. Preventing clock tampering and reliably erasing keys can be tricky of course, but this is the only way to achieve PFS; any PFS system has to solve this problem. IMPLEMENTATION AND MEASUREMENTS Prototype implementation We have implemented a prototype of the PKGE service in C/C++. Our implementation uses Benn Lynn’s PairingBased Cryptography library (PBC) [10]. In implementing PKGE, we benefited from seeing a protype implementation of BCE by Matt Steiner, who kindly shared it with us. (Our implementation does not use his code.) We have also implemented a PKGE plugin for the GAIM chat client (http://sourceforge.net/projects/gaim/). “Gaim is a GTK+ instant messaging application. It supports multiple protocols, including AIM, ICQ, Yahoo!, MSN, Jabber, IRC, Napster, Gadu-Gadu, Zephyr, and SILC. It has many common features found in other clients, as well as many unique features.” So far we have tested PKGE-GAIM with the Jabber chat protocol and observed no noticeable delays associated with encryption/decryption. We expect PKGE-GAIM to work with other chat protocols as well. Experimental measurements We are currently in the process of testing and evaluating the prototype. Here we discuss results from a recent experiment in which thirty 550-byte messages were exchanged by a group of five users over a lossy network. Refer to the figure below. The bottom line corresponds to the original, unencrypted messages. Observe that some messages (#s 11, 19, 22, and 23) are lost and that one user leaves the group after message #12. The three upper lines

6 of 8

correspond to the messages being encrypted and authenticated with three different PKGE protocols: stateless; stateful-pessimistic; and stateful-optimistic. Stateless PKGE encryption adds ~300 bytes of overhead (consisting mainly of a PKGE key-encapsulation, an ECDSA signature, message formatting, and the overhead from AES-256-CBC symmetric encryption). The pessimistic protocol runs in the stateless mode until all users acknowledge the set-key; then it switches to the optimized mode. In contrast, the optimistic protocol switches to the optimized mode after a single stateless message. The overhead in the optimized mode is only 134 bytes; there is no key encapsulation, but there is still an ECDSA signature, message formatting, and AES encryption. Message Size 1000 900 800

number of addressees. Also, this approach does not support key rollover and Perfect Forward Security (PFS); there is a reason why in DoD systems public keys are used for authentication, but not for encryption. Some public key encryption systems can be made PFS, as in [11]. (Note that PKGS implements PFS). Symmetric keys: We can also consider a straightforward solution of having every pair of users establish pair-wise symmetric keys. Then, a message key can be encrypted separately with each of the symmetric keys. This scheme requires the senders to have a current pair-wise symmetric key with each of the recipient users; establishing these keys carries an additional communication and computation overhead. An attractive feature of this approach is that it is easy to implement key rollover and PFS by simply expiring and re-establishing symmetric keys. However, the encryption space overhead is still linear, though it is smaller than in the secure email solution. Stateful session-key approach

700

Each of these two schemes could be used as a base for a stateful scheme, which has a leader of the group distribute a session key to the users. With this stateful scheme, the linear overhead is incurred only when the current session key needs to be changes, as when users join, leave, or their membership is revoked, as well as when session keys expire and need to be renewed.

Bytes

600 500 Original message

400

Stateless 300

Stateful: Pessimistic Stateful: Optimistic

200 100 0 0

5

10

15

20

25

30

35

Message #

This experiment was run on a Powerbook G4, 1GHz PowerPC, 1GB SDRAM. Stateless PKGE operations (encrypt-and-sign and verify-and-decrypt) took ~75-85 ms for the first message in a new groups and ~20ms for subsequent messages (the encapsulation header does not have to be recomputed). In the optimized mode (with symmetric set-keys) encrypt-and-sign took ~15ms and decrypt-andverify was ~20ms; these are dominated by signature generation and verification. Note: PKGE performance can be improved with further caching-based optimizations. EXISTING DECENTRALIZED APPROACHES For comparison, we review other approaches that can be used for providing a localized group encryption service. Straightforward non-group approaches Asymmetric keys: Secure email messaging is typically implemented by encrypting (encapsulating) a random message key separately using each of the addressee’s public key. These key encapsulations are attached to the encrypted message; each of the addressees can extract the message key from one of the encapsulations. The encapsulation space overhead of this approach is linear in the

Designing such a stateful scheme in away that achieves the performance goals listed on page 3 (high-availability, robustness, low communication overhead, and simplicity) is a real challenge in dynamic NCW networks. Contributory group keying schemes In addition to these straightforward non-group approaches, there is a large body of research work on contributory group key agreement protocols (e.g., [5, 6, 12]). These protocols extend pair-wise key agreement protocols, such as Diffie-Hellman or MQV, to group settings. In a nutshell, every member of a group maintains the same key tree, in which leaves correspond to members, internal nodes represent intermediate key values, and the root node contains the group key. All members participate in group key construction. For a group of n members, there are generally log(n) rounds, each computing the keys of one layer in the tree. Each round involves communication and a Diffie-Hellman or MQV computation. Whenever group membership changes, the group key need to be recomputed. Some optimizations are possible to reduce the number of rounds for certain membership change events. There are several points that make these schemes inappropriate for dynamic low-bandwidth, high-latency networks:

7 of 8

•

Scheme complexity: Correctness of these schemes depends on every member maintaining the same tree and factoring correct key shares in correct order. As a result, these schemes utilize complex group communication middleware, which keeps members synchronized.

their communication without the need to rely on an external keying service. Such solutions are among the top prerequisites for achieving the vision of NCO/W, through improved mission effectiveness, C2, information sharing, and collaboration in real tactical environments.

•

Multiple communication rounds: In addition to the group keying schemes requiring multiple rounds of communication in order to compute group keys, there are also multiple synchronization rounds performed by the underlying group communication middleware.

•

Frequent rekeying and associated overhead: Because these schemes are contributory, every member must be online and connected to contribute its share and perform key computations. Thus, these schemes have to rekey every time a member disconnects or reconnects. Consider how often this happens in a dynamic wireless ad hoc network!

Acknowledgments: We thank Joseph Cooley for his contribution to the project, Dan Boneh and Ben Lynn for answering questions about the Broadcast Encryption scheme and PBC library, and Matt Steiner for sharing with us his BCE prototype. We also appreciate feedback from Mr. Robert Flores and Ms. Lynn Carroll of HQ-CPSG/NIS.

Current state of the art Text chat can be considered a disruptive technology; it is used everywhere in the world, including the military during tactical operations ([13-15]). Most chat systems support both user-to-user and group messaging (a.k.a. instant messages and room chat). It is somewhat telling that while most of existing chat systems support message encryption for user-to-user messages, virtually none, to our knowledge, support message encryption for group communication. Skype [16] is the only system that supports encrypted conferences, but such conferences have to be disbanded as soon as the creator of the conference goes offline or disconnects. CONCLUSION In this paper, we motivated and described the problem of group encryption, and presented an approach for solving this problem. We also described PKGE, a highly-efficient solution to this problem. At its foundation, PKGE uses the bilinear-map-based broadcast scheme by Boneh et al. The security of this underlying scheme relies on a certain complexity assumption, called BDHE (see [7]). While strong evidence exists for this assumption to be valid, keep in mind that it has not stood the test of time, nor has it been standardized. A different part of our project is pursuing the design of a group encryption scheme that is based entirely on standardized crypto primitives. The scheme is called, Dynamic Set Key Encryption (DSKE). The design of DSKE follows the approach and the vision described in this paper. The overarching goal for our project is to develop simple and usable solutions that enable NCW groups to secure

REFERENCES [1] "IETF Multicast Security Working Group http://www.securemulticast.org/." [2] T. Hardjono and L. Dondeti, Multicast and Group Security: Artech House, Inc., 2003. [3] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B. Pinkas, "Multicast security: A taxonomy and some efficient constructions," NFOCOMM, pp. 708-716, 1999. [4] D. Naor, M. Naor, and J. B. Lotspiech, "Revocation and Tracing Schemes for Stateless Receivers," presented at Proceedings of the 21st Annual International Cryptology Conference on Advances in Cryptology, 2001. [5] Y. Kim, A. Perrig, and G. Tsudik, "Tree-based group key agreement," ACM Trans. Inf. Syst. Secur., vol. 7, pp. 60-96, 2004. [6] S. Rafaeli and D. Hutchison, "A survey of key management for secure group communication," ACM Comput. Surv., vol. 35, pp. 309-329, 2003. [7] D. Boneh, C. Gentry, and B. Waters, "Collusion Resistant Broadcast Encryption With Short Ciphertexts and Private Keys," presented at Crypto, 2005. [8] NSA, "The Case for Elliptic Curve Cryptography," http://www.nsa.gov/ia/industry/crypto_elliptic_curve.cfm. [9] W. Diffie, P. C. Van-Oorschot, and M. J. Weiner, "Authentication and authenticated key exchanges.," Designs, Codes, and Cryptography, vol. 2, pp. 107-125, 1992. [10] B. Lynn, "Pairing based cryptography c library, http://rooster.stanford.edu/~ben/pbc/." [11] R. Canetti, S. Halevi, and J. Katz, "A Forward-Secure Public-Key Encryption Scheme," presented at Cryptology ePrint Archive: Report 2003/083; Eurocrypt 2003, 2003. [12] F. Geck, K. McFarland, R. Serenelli, M. Straw, S. Lucas, and B. Yau, "GECKA -- A Distributed Group Key Agreement Protocol," presented at MILCOM, 2005. [13] A. Butler, "War Planners Talk In 'Chat Rooms' to exchange targeting data, tips. ," in Inside the Air Force, 2003. [14] S. T. Dougherty, "JEFX 2002 ends with positive results," in Air Force Link, 2002. [15] R. Khazan and others, "Robust Collaborative Multicast Service for Airborne Command and Control Environment," presented at MILCOM, 2004. [16] Skype, "Free internet telephony that just works, http://www.skype.com.."

8 of 8