Secure multicast in wireless networks of mobile hosts: protocols and ...

Secure multicast in wireless networks of mobile hosts: protocols and issues D. Bruschi, E. Rosti Dipartimento di Scienze dell'Informazione Universita degli Studi di Milano Via Comelico 39/41, 20135 Milano { Italy fbruschi, [email protected]

Abstract

Multicast services and wireless interconnection networks are among the emerging technologies of the last decade. They drove the development of ecient one-to-many and many-to-many communication primitives and they raised the need for secure multicast services as well. On the other side, technology advances have made possible a wide spectrum of portable computing devices, ranging from fully equipped powerful laptop computers to hand held PDAs with non negligible interconnection and computing capabilities. A wealth of research has been separately performed in the areas of secure multicast and wireless interconnection networks. In this paper we investigate the issues of designing secure multicast services in wireless mobile environments for dynamic groups. We analyze the impact of host mobility on secure multicast and design protocols for key management in wireless environments for a variety of scenarios. Our solution relies on decoupling mobility management from group dynamics management. This is possible by taking into account the level of trust in the support stations, i.e., the xed hosts with wireless interface that connect to the mobile hosts. The cases of non-trusted, semi-trusted, and fully trusted support stations are considered. In particular, we show that protocol eciency on the mobile host side can be traded-o with the level of trust in the support stations.

1 Introduction The increasing diusion of one-to-many and many-to-many network services such as stock market applications, news distribution, video conferencing, software updates distribution, video on demand, tele-medicine, has lead to the design and implementation of new communication primitives that make a more ecient use of the network resources than the standard one-to-one communication primitives [20]. The multicast primitive is now available in several commercial implementations of the TCP/IP stack and many dierent protocols have been proposed by the computer network community. Multicast is an internetwork service that provides ecient delivery of data from a source to a group of recipients [11, 12]. It reduces the sender's transmission overhead, the network bandwidth usage, and the latency observed by receivers. Most services based on group communication, such as those mentioned above, implicitly assume that the multicast primitive satis es some basic security requirements, such as con dentiality and integrity of the information transmitted and authenticity of the group members. Several contributions have appeared in the literature that propose ecient protocols to add security features to multicast primitives. A secure multicast protocol must ensure that participants to the group may access the distributed information only when they are authorized to do so and that only authorized participants to the group may distribute information to the group. Cryptography is employed 1

to satisfy such requirements. Because secure multicast communications within the group are encrypted, when a new entity joins the group, the key used to encrypt the trac must be changed to prevent the newcomer from accessing past trac. The key must also be updated when a member leaves the group, in order to prevent the leaving member from accessing future trac. Therefore, the design of an ecient key management scheme is the critical issue characterizing the problem from the security point of view [7]. Many contributions appeared in literature on key management (see e.g., [5, 6, 7, 8, 9, 10, 13, 15, 16, 17, 21, 22, 23, 24, 25, 26, 27, 28]). They all focus on wired systems. However, since a wide spectrum of wireless computing devices are becoming increasingly popular, ranging from fully equipped powerful laptop computers to hand held PDAs with non negligible interconnection and computing capabilities, the possibility of extending their results to mobile networks should be explored. In this paper we investigate the issues of designing secure multicast primitives in wireless networks. We analyze the impact of host mobility on key management schemes for wired systems and propose protocols for key management in wireless networks. We consider the cellular model of mobile network. In this model a geographical area is divided into possibly overlapping cell and each cell is covered by a xed host with a wireless interface, called mobile support station (MSS), connected to a wired network. The mobile hosts present in a cell communicate via a wireless medium with the cell MSS. The main contributions of this paper can be summarized as follows. We identify the critical factors introduced by the mobile environment that must be considered when designing a secure multicast protocol as the following:  group members have limited computational power, thus they should be involved in intensive computations, such as cryptographic computations, as little as possible;  host mobility increases the complexity of dynamic group membership; in fact, a mobile host moving from one cell to another may result in the generation of new keying material;  the problem of who keeps track of the keying material of the mobile host during the hand-o phase arises;  the role of the MSSes with respect to group membership should be de ned, as the type of group information MSSes can access, without compromising the security properties of the protocol, depends upon the type of membership the MSSes are eligible to. We then identify three dierent scenarios based on the degree of trust in the MSSes. They fully characterize the various con gurations where a secure multicast protocol may be implemented in a cellular wireless network. The three scenarios are:  non-trusted systems, consisting of cellular networks with possibly malicious MSSes, i.e., MSSes that might try to gain access to the data trac within the group, even if they are not allowed to;  semi-trusted systems, consisting of cellular networks with MSSes that are not allowed to understand the data trac within the group but behave correctly with respect to a given protocol;  fully trusted systems, consisting of cellular networks with trusted MSSes, i.e., MSSes that may have access to the trac and will never reveal con dential information related to the group. 2

For each one of these scenarios we propose a key management protocol upon which a secure multicast service can be built. The protocols are designed balancing two con icting requirements, namely, limit the group manager and the MSSes load, so as to avoid multicast implosion, while maintaining the computational overhead of the mobile hosts as low as possible. The separation of group dynamics and host mobility management tasks among the three components of the systems, i.e., the group manager, the MSSes, and the mobile hosts, is the key idea in the design of our protocols. In case of non-trusted systems, since the MSSes cannot be relied upon at all, the eort for managing group dynamics and host mobility is shared by the group manager and the mobile hosts. This is the worst case scenario. No better solution is possible than adopting an ecient multicast protocol selected among those proposed for wired networks (see Section 3), as there is no trust to trade for eciency. The selection is determined by the way the load is distributed among the participants. In one case, the group manager takes care of all the key management aspects, which limits the solution scalability. In the other case, the mobile hosts perform a considerably higher percentage of work, which is unacceptable for the very nature of the mobile hosts. None of these solutions is adequate to the systems and applications considered in this paper. In particular, nontrusted systems should not be considered for ecient implementations of group services in mobile environments. In case of semi-trusted systems, more ecient solutions can be devised as the support stations can be trusted to honestly execute the protocol. We propose a protocol that balances the load of a secure multicast primitive among the system components. Yet, this is not the optimal scenario for a mobile host, since it is burdened with a xed overhead due to additional cryptographic operations that allow the group manager and the MSSes to limit their management of host mobility. If the support stations can be fully trusted, a protocol is proposed that relieves the mobile hosts of the additional cryptographic operations and minimizes their participation in the key management process. Mobile hosts are required to perform data trac decryption only. In this case, the overhead of group dynamics and host mobility management is completely on the group manager and the support stations. As a complementary result of our analysis, we show that a peculiar trade-o exists between the level of trust in the MSSes and the computational eort of the mobile hosts. The more trustworthy the MSSes are, the less computational eort is required from the mobile hosts. This paper is organized as follows. Section 2 de nes the system model and the properties of secure multicast protocols. Section 3 presents an overview of the related work. Sections 4, 5, and 6 illustrate the proposed protocols in case of non-trusted, semi-trusted, and fully trusted mobile support stations, respectively. Section 7 analyzes the eciency of the proposed protocols and discusses the trade-os between trust and computational eort. Conclusions are drawn in Section 8.

2 De nitions

2.1 System Model

In this paper we consider a cellular network architecture for mobile environments. The system consists of two sets of entities: a set of mobile hosts and a set of static, or xed, hosts. All xed hosts are connected by a wired communication network. Fixed hosts with a wireless network interface are called mobile support stations (MSSes), as they communicate directly with the mobile host and provide the wired infrastructure [4]. They de ne the wired network perimeter. Fixed hosts 3

with only wired network interfaces are considered conventional hosts of the static interconnection network. Mobile hosts (MHs) are connected by a wireless network. A mobile host is a host whose location relative to the rest of the network changes with time, as it is capable of moving (usually called roaming) between dierent locations, while keeping its network connection with an MSS via a cellular connection or a wireless LAN. Mobile hosts that have identi ed themselves with a particular MSS are considered local to that MSS. The communication between an MSS and a mobile host is via a shared transmission channel, typically a broadcast medium such as air. Thus, when an MSS sends information to an MH, or vice-versa, all nodes within the MSS transmission range receive the message. The geographical area covered by an MSS, i.e., the area where the MSS messages can be received directly by an MH, is called cell. Even though cells may physically overlap, an MH logically belongs to one cell only at any given instant of time. Without loss of generality, with respect to the problem investigated in this paper, we make the following assumptions: all members of the multicast group, i.e., the data trac recipients, are mobile hosts. The Group Manager (GM) is identi ed among the xed hosts, possibly the MSSes. Among the group manager's tasks are group membership management, data trac distribution to the group members, and, in case of secure multicast, distribution and management of the cryptographic material necessary to perform the security functions of the protocol.

2.2 Secure Multicast

Multicast is a communication service that provides data delivery from a source to a set of recipients, also known as multicast group. A host subscribes to a multicast group by sending a join request to the group manager. A host leaves a multicast group either by sending a voluntary leave request to the GM or when it is expelled by the GM. Participants in a secure multicast service may be distinguished between the data group and the control group. The data group comprises all the members interested in receiving data trac generated within the group. The control group includes all the components involved in the key agreement and exchange processes. In the secure multicast protocols appeared in the literature so far, either the control group and the data group coincide, or the control group was assumed to be static. Therefore, managing the control group was the same as managing the data group or was limited to the start-up task only. The precise set of security requirements for group communication is determined by the application using the service. However, a minimal set of requirements can be given that most applications share: con dentiality: all the trac within the group may be read only by group members; authenticity: it should be possible to uniquely identify messages generated by group members; backward trac secrecy: newcomers should not be able to read past trac; forward trac secrecy: former members should not be able to read present and future trac. These requirements can be satis ed only with the use of cryptographic techniques. Thus, group members also exchange keying material besides data trac. The keying material comprises the keys used to encrypt/decrypt the data trac and the keys, if any, used to encrypt/decrypt the keys used for the data trac when the latter must be updated. The keying material we consider consists of three types of keys, namely control keys, also indicated as key encryption keys, or KEKs, trac keys, also indicated as trac encryption keys, or TEKs, and cell keys, also indicated as cell 4

encryption keys, or CEKs. The group manager establishes the KEKs and the TEKs, while the CEKs are completely managed by the MSSes, as they are local to each cell. The key structure is the same for all keys regardless of their type and is the one used in [26]. Keys are identi ed by a unique key ID combined with a key version number and a key revision number. The key version number is increased every time the key changes upon a leave, the key revision number is increased every time the key is updated upon a join. We also assume that a PKI is in place and each component involved in the group operations has a digital certi cate signed by a trusted third party1.

2.3 Mobility and Secure Multicast

The innovative aspects to consider when implementing a secure multicast primitive in a mobile system are the presence of the MSSes and the host mobility. MSSes are not members of the multicast group as they are not interested in data trac but, for eciency reasons, it may be convenient to consider them members of the control group. Mobility, i.e., changes in a cell population due to host roaming, should not be confused with data group \dynamics," which is the eect of joins and leaves from the multicast group. We will use enter/exit for cell population changes, i.e., mobile hosts moving from one cell to another as they change their geographical location. Control group changes, which we refer to as control group dynamics, may occur because of the mobility of the data group members. Control group dynamics, however, does not correspond one-to-one to data group dynamics. MSSes are added to or removed from the control group upon host joins/leaves or host movements that empty or create a data group in a cell. In our system, control group changes occur if no data group member is left in a cell or if a member enters a cell that had no other members at the moment. In order to avoid confusion between data group and control group dynamics, we will use add/delete for control group changes. Because of the combined eects of data group and control group dynamics, the rate at which the keying material may change is higher than in a corresponding wired system. Therefore, it is critical to eciently distribute the workload of key management in order to avoid the group manager saturation. A key management scheme for mobile networks is characterized by the following con icting properties: minimize the participation of the mobile hosts and relieve the group manager in the key management activity. The only way to satisfy both properties is to have the MSSes take an active role in the key management process. We show in the following sections that this is possible, and give adequate protocols, only if the MSSes can be trusted to some degree. If no trust can be put in the MSSes, there is no better solution than to have the GM and the mobile hosts fully participate in the protocol.

2.4 Notation

In this section we introduce the notation we will use in Section 4 and following to describe the proposed protocols. We indicate with S = fs1 ; s2; : : : ; sNS g the set of support stations and with M = fm1 ; m2; : : : ; mNM g the set of mobile hosts, of cardinality NS and NM , respectively. Msi  M is the set of mobile hosts in the cell controlled by support station si . GM is the group manager and may belong to S . Furthermore, DG  M is the data group, and CG  S [ M is the control group. Such an assumption is not fundamental, it only simpli es the setup phase in which the various components, namely the MH, the MSS and the GM, authenticate each other and establish a shared secret between each pair. Any alternative cryptographic technique that oers comparable guarantees as for secrecy and authentication strength can be used instead, without aecting the overall procedure. 1

5

We denote a generic key encryption key and a generic cell encryption key with k and c, respectively, and the trac encryption key with t. We indicate with pj ; p?j 1 the asymmetric key pair associated with entity j in the PKI, where pj is the public key and p?j 1 is the private key p?j 1. New keys are indicated with a 0 superscript. We describe the protocol operations in terms of the messages sent to perform them. The notation ?1 A A ?! B : fmsg gpkey indicates that entity A sends message msg to entity B and msg is encrypted using the key key and is signed by A using its private key p?A1. A and B can be either individual, e.g., single MSS or MH or the GM, or group of senders/receivers, e.g., the set S or the set M , or subsets thereof, in case of multicast or broadcast messages. In this case, we use =) instead of ?!. Because of the composite eects on the control and data groups of multicast group join and leave operations, we use the term subscription and cancelation for the corresponding operations on the multicast group. We use the traditional join/leave terms for group operations that involve the wireless network components, i.e., the data group, and add/delete for group operations that involve the wired network components.

3 Related Work A considerable number of papers have investigated the issues related to the implementation of multicast in mobile networks (see e.g., [1, 3, 2]). On the contrary, to our knowledge, very little work has appeared about the problems of the implementation of a secure multicast primitive in mobile networks. In particular, these problems were rst considered in [14], where the impact of mobility on secure multicast is examined. Typical mobility constraints, such as the limitations on power consumption, storage, processing speed and channel bandwidth (with, however, wider broadcast range), and the changes in host location and network connectivity, are identi ed and high level features are listed that a security architecture for mobile multicast should emphasize. The focus is on transparency of the security features regardless of the underlying multicast protocol, self-suciency of users who wish to engage in secure multicast, mobility, simplicity, and eciency. However, the architecture outlined in [14] only considers accommodating a single mobile host in an otherwise wired network or, at most, a group of hosts that participate in a multicast session via a shared network. Our target is secure multicast for fully mobile networks. Several key management protocols have been proposed for secure group communication in wired networks, as security problems may be reduced to key distribution and management problems. Key management schemes de ne the key agreement mechanism at the beginning of a multicast session and the successive key exchanges during a session when the group changes without rebuilding the group. This operation is usually de ned as the re-keying operation and completely characterizes a key management protocol. Eciency in performing the re-keying operation is usually the adopted criterion to classify key management schemes. Re-keying eciency is evaluated based on the following parameters: the communication complexity, which is measured in terms of the number of multicast messages exchanged during a re-keying operation times their size in bit, and is usually the most important measure; the time complexity, which is measured in terms of the time required to the group members to compute the new key; the GM storage requirement, which is measured in terms of the amount of storage required to the GM for storing all the keys; and the group member storage requirement, which is measured in terms of the amount of storage required to a group member for storing the keys it handles. A detailed survey can be found in [19]. We propose here 6

a classi cation of such protocols that provides a global overview of the research area where the results presented in this paper can be positioned. Flat schemes This is the simplest solution. Each of the n group members shares a personal secret key with the GM, which is established when the group is created. The re-keying operation is performed by sending to each member the new key encrypted with its own personal key. Each such message may be combined in a single message and sent to all group members via multicast. The communication complexity is proportional to n, i.e., it is O(n). The time, GM storage, and group member storage complexities are O(1), O(n), and O(1), respectively. In this case, all the overhead of group management is on the GM, while minimum eort is required from the group members, i.e., just one message decryption to recover the new key. The IP multicast security protocol GKMP, the Group Key Management Protocol [15, 16], the Scalable Multicast Key Distribution scheme [5], which is an improvement of GKMP in terms of scalability, were designed along this philosophy. Although attractive for their simplicity, at schemes are not scalable, as they quickly lead to the GM saturation. Other solutions appeared in the literature that achieve better overall performance by shifting a certain amount of work on the group members, thus determining various trade-os between the eciency parameters. Clustered schemes The most famous clustered solution is Iolus [23]. Iolus was designed to overcome both the scalability and the key management problems of the at schemes. A given group is partitioned into clusters. Each cluster is assigned a \cluster head," which establishes the encrypting key for the cluster for each session. The cluster head communicates with the group manager with a cluster encrypting key and relays messages from the GM to the group members after a key translation phase. In this scheme, group membership changes are handled at cluster level and do not aect other subgroups. However, in the worst case scenario, their communication complexity is O(n). The GM only multicasts data trac and keys to the cluster heads, therefore it only stores an encryption key for each cluster head. Most of the work is performed by the cluster heads. Furthermore, this solution relies on the trust in dedicated nodes, i.e., the cluster heads, which weakens the overall system security. Tree based schemes Tree based schemes were suggested in [27] and independently in [28]. They address the problem of minimizing the communication complexity of the re-keying operation without relying on secure third parties. They organize all the keying material in a balanced tree whose leaves are the group members' individual keys. The key at the root of the tree is the TEK. The keys along the tree nodes are the KEKs. Each group member stores all the keys along the path from itself to the root. During a re-keying operation the group manager uses the hierarchy of KEKs to exclude a single participant or a group of participants. All the compromised KEKs and the TEK are replaced during a re-keying process. When this scheme is applied to a group of n users, it has group member storage complexity O(log n), communication complexity O(log n), GM storage complexity O(n), while the time complexity is O(1). Later work improved the original scheme with respect to various aspects [8, 25, 26]. Other schemes In the schemes outlined above, the goal is to improve the protocol communication complexity by balancing the distribution of the keying material among dierent entities, so as to spare the group manager the task of sending the new key to each group member separately. A dierent approach was taken by the authors of Securelock who proposed an ecient scheme in terms of communication complexity at the cost of intensive computations [10]. Securelock introduces a 7

trade-o between computation time and communication complexity. The solution proposed is based on the Chinese Remainder Theorem and uses public key technology. It has communication complexity O(1) but it requires that each group member perform O(n) exponentiations to \unlock" the message, thus becoming prohibitively expensive for large groups. The solution proposed in [24], where a generalized Die-Hellman algorithm is proposed for the re-keying operation, has the same drawback as [10].

4 Secure Multicast with Non-trusted MSS We consider here the most restrictive scenario where the MSSes relay the trac they receive to the MHs without modifying it but cannot be trusted to handle any keying material. In this case, the only possibility is to apply an ecient algorithm such as the centralized tree VersaKey [26] to the entire set of mobile hosts. However, such an approach does not take into consideration the speci c nature of the mobile hosts, i.e., their limited computational power and energy supply. The control group and the data group coincide. Each mobile host manages the whole set of log NM keys, which imposes a signi cant overhead on the mobile host in case of large dynamic groups. Host mobility, i.e., roaming from cell to cell, is completely handled at the communication level and does not aect the key management protocol at all. Because of the peculiar nature of mobile hosts and of mobile network architectures, protocols should be designed to exploit it. This requires that some level of trust can be placed in the MSSes. Two scenarios are presented in the next sections.

5 Secure Multicast with Semi-trusted MSSes We now consider networks where the MSSes are trustworthy enough to participate in the key management protocol, although they never access the data trac. We assume that the MSSes honestly relay the trac they receive and they correctly manage control trac. The case considered in this section applies to the most common scenario where the MSSes are under a third party administrative control, such as a telecommunication company or an ISP service provider, which is extraneous to the data source but collaborates with other network entities to provide network services. The protocol we propose has a two-tier structure that exploits the physical separation between the wired and wireless portions of the network and the clustered nature of the latter. In the rst tier, the GM manages all the access control, accounting, logging, and data trac distribution to the set of support stations. These ones act as agents of the mobile hosts in the data group DG, i.e., the service subscribers. The GM accepts subscription and cancelation requests and distributes the TEK to the group members when they subscribe. The TEK serves two purposes. First, it protects the data trac from unauthorized accesses, and second, it guarantees sender group membership. Encryption indirection is used to optimize the protocol operations. Data trac is symmetrically encrypted using a session key s k, which is in turn symmetrically encrypted using the TEK t and sent along with the data trac. The MSSes in whose cells there is at least one data group member comprise the control group CG. Their task is to relay the data trac after applying some cryptographic transformations to it. They execute the second tier of the protocol. Each MSS si acts as the group manager of a centralized tree VersaKey scheme at cell level, where the CEK csi is the local TEK and the local data group is Msi  M . An MSS receives the data trac multicast by the GM and encrypts the 8

encrypted session key using the local CEK before broadcasting it to the subscribers Msi in its cell. The GM and the MSSes execute the following: GM =) CG : fdata trafficgs k ; fs kgt 8si 2 CG; si =) Msi : fdata trafficgs k ; ffs kgtgcsi The mobile hosts in Msi recover the session key they need to access the data trac by rst decrypting ffs kgtgcsi with csi and then decrypting fs kgt using the TEK t they received when they subscribed to the group. Since the payload that must be decrypted twice by the MHs is limited to the session key, the overhead of such an additional computation due is limited and constant regardless of the size of the payload. Thanks to the encryption of sk with each csi , the impact of host mobility and group dynamics is con ned to the cell level as key updates may occur only in the interested cells. Since only those who have both the local CEK and the TEK have access to the data trac, CEK updates upon join and leave operations guarantee the backward and trac forward secrecy required by the protocol. The overhead for key management imposed on the mobile hosts is, however, less than in the case described in Section 4, since each Msi  DG. We now illustrate the single operations of the protocol.

5.1 Startup

Group creation is managed by the startup procedure. The GM is con gured with group and access control information. For every multicast group, two groups are created, the control group CG  S comprising all the currently active MSSes, and the data group DG  M comprising all the mobile hosts that have subscribed to the secure multicast service. An MH is added to DG when it subscribes to the service and is then removed from DG when it voluntarily terminates its subscription or the GM expels it. The DG is managed for Accounting, logging, data distribution, and access control are the management operations the GM performs on DG. An MSS is added to CG when a subscribed member enters its cell for the rst time or when a new member subscribes to the service from a cell whose MSS is not in CG yet. An MSS is deleted from CG when no member is left in its cell, either upon a cancelation or upon a hand-o. The CG is managed for communication purposes as the GM must know how to reach its subscribers.

5.2 Subscription

Subscription is the high level operation a mobile host executes when it wishes to enter a multicast group. Subscription requests are digitally signed to allow the GM to authenticate the newcomer. A mobile host m sends a SUBSCRIBE message to the GM by means of its MSS s, which forwards the request to the GM for approval:

m =) s : fSUBSCRIBEgp?m?11 s ?! GM : fSUBSCRIBEgpm If the request is approved, the GM adds m to the data group and gives it the current TEK t. It also noti es s to proceed with the join operation. The GM then searches the control group for s and, if s is not in CG yet, the GM proceeds with an add operation. A subscription is then a composite operation that involves two levels: the group manager level, where an add might be performed, and the MSS level, where a join is performed. The details of these two low level operations are given in the following sections. 9

5.2.1 Add

An add is a rst tier protocol operation performed upon a subscription request or upon a hand-o. It can be applied to CG and DG. Additions of MSSes to CG occur when a group member appears in a cell where there are no other group members, either upon subscription or upon a hand-o. The GM veri es m's access rights, adds m to DG, and gives m the current TEK that is used to encrypt the data trac, which guarantees group membership of all senders: ?1

GM ?! s : ftgppGM m 1 p?GM s =) m : ftgpm Additions of MHs to DG occur only upon subscription, as hand-os do not alter the membership status of a group member.

5.2.2 Join

A join is a second tier protocol operation performed when a mobile host m becomes part of the data group in a cell upon a subscription or upon a hand-o procedure. Since each cell executes a local centralized tree VersaKey scheme, m receives from its MSS s the updated set of ns = dlog jMsje KEKs and the local TEK, i.e., the CEK cs , as described in Appendix A, and a symmetric session key sm to be used for control trac with m only. Therefore, if m is the only member in the cell, s generates cs and sm, and executes:

s =) m : fcs gsm ; fsmgpp?sm1

If jMsj > 1, i.e., s 2 CG before m joined, s updates its local CEK cs to c0s and all the KEKs along the path from the leaf sm in the tree to the root. The hosts in Ms sharing some of the updated keys will update such keys when they detect the increased revision number at the rst message they receive that uses the updated keys. In this case s executes:

s =) m : fsm; kn0 s ?1; : : : ; k20 ; k10 ; c0sgsm ; fsmgpp?sm1

where kn0 s?1; : : : ; k20 ; k10 are the new keys along the path from the leaf sm to the new root c0s . In both cases, s adds m to Ms . Giving the newcomer a new CEK and a new set of KEKs guarantees backward trac secrecy, as it prevents the newcomer from accessing the trac broadcast in that cell before its subscription to the group. Note that, because of the nature of wireless communication, the described operation could be optimized in the case of hand-o. The key update in the entered cell could be avoided, as a mobile host cannot be listening to the broadcast from two dierent sources simultaneously. Therefore, the very nature of the wireless communication provides for backward trac secrecy in the case of hand-o. This would spare the mobile hosts already in the cell from the computation of a one-way hash function on possibly all the keys they have.

5.3 Cancelation

Cancelations occur under two conditions: either a member cancels its subscription voluntarily or it is expelled from DG by the GM . In the case of voluntary cancelation, the leaving member m sends a CANCEL message to the GM via its local MSS s:

m =) s : fCANCELgp?m?11 s ?! GM : fCANCELgpm 10

In case of forced cancelation, the GM noti es s that the member m in its cell has been expelled. In both cases, s proceeds with a leave operation and the GM proceeds with a delete operation in the rst level tier protocol to remove m from DG and veri es if s should also be removed from CG. No key change is required at this level since forward trac secrecy is guaranteed by cell level key updates. A cancelation is then a composite operation that involves two levels: the group manager level, where one or two deletes might be performed, and the MSS level, where a leave is performed. The details of these two low level operations are given in the following sections.

5.3.1 Delete

A delete is a rst tier protocol operation the GM executes on DG or CG when m cancels its subscription or exits from a cell that has no other members. The GM deletes m from DG when m cancels its subscription or is expelled from the group. The GM deletes an MSS s from CG when no members are left in its cell, either after a cancelation or after a hand-o procedure is executed.

5.3.2 Leave

A leave is a second tier protocol operation s executes when m cancels its subscription or exits from the cell it currently occupies when it is handed-o to the adjacent cell. s changes its local CEK cs to prevent m from accessing the data trac multicast after m leaves the cell, thus guaranteeing forward trac secrecy at cell level. In this case, according to the centralized tree VersaKey scheme, s executes:

s =) Ms : fkn0 s?1gsm ; fkn0 s?2gkn0 s ?1 ; : : : ; fk10 gk20 ; fk10 gk2 ; fc0s gk10 ; fc0s gk1

where ki is the sibling2 of node ki in the tree, and kn0 s?1; kn0 s?2; : : : ; k20 ; k10 are the new KEKs along the path from the leaf sm to the new root c0s . New keys are identi ed by an increased version number.

5.4 Hand-o

The hand-o procedure is performed by the MSSes when a mobile host physically moves from one cell to an adjacent one. It characterizes the wireless cellular systems considered in this paper. During the hand-o procedure, the MSS entitled to the management of the cell being departed transfers the information pertaining to the mobile host to the MSS controlling the cell being entered. Since in this phase the mobile host is unable to receive any data trac, the design of the hand-o procedure must account for data retransmission once the hand-o is terminated, as the mobile host should access all the data and control trac that was exchanged during the hand-o0 procedure. The hand-o procedure involves the local MSSes, the departed s and the entered s , and possibly also the GM . Since no data group membership change occurs, 0the hand-o procedure triggers the execution of a leave by s, the departed MSS, and of a join by s , the new MSS. Add and delete on CG might also be necessary. We examine the changes in the control group membership status of the MSSes and m join/leave operations separately, as they pertain to dierent protocol tiers. Let m be the mobile host exiting the cell under s control to enter the cell under s00 control. When m discovers that it is moving from the cell under s control to enter the cell under s control, m executes: 2

By siblings in a binary tree we mean the nodes in the tree with a common direct parent node.

11

m =) s0 : fm; mcast grp id; seqgp?m1 where mcast grp id is the indenti er of the multicast group to which m belongs3, and seq is the0 sequence number of the last packet received by m. Based on the information received from m, s executes a join operation (see Section 5.2.2). On the other side, s executes a leave operation (see Section 5.3.2). During the hand-o, both s and s0 membership status in the control group must be veri ed. Four cases are possible: 1. s; s0 2 CG before and after the hand-o; 2. s 2 CG before and after the hand-o, s0 2 CG only after the hand-o; 3. s; s0 2 CG before the hand-o but s 62 CG after the hand-o; 4. before the hand-o, s 2 CG and s0 62 CG; after the hand-o, s 62 CG and s0 2 CG. The rst tier protocol operations performed for each of the above cases are the following: 1. none, since s; s0 2 CG and neither of the two changes its membership status; 2. GM adds s0 to CG; 3. GM deletes s from CG; 4. GM deletes s from CG and adds s0 to CG. Furthermore, in the 0case0 of add, the GM sends also all the data trac 0with sequence number greater than seq to s . s will also receive from s the secret key sm that s can use for the initial exchange of information with m and for future CEK updates. Using a shared secret in this phase eliminates the need for public key cryptography, thus optimizing its execution time. The fact that such a key is provided to s0 by s does not compromise0 the security of the protocol and reduces the overhead of further key agreements between m and s . Such a key is used by s0 to give m the set of KEKs and the CEK it needs.

5.5 Refresh

The proposed protocol works in a dynamic environment where the eects of groups dynamics combine with those of host mobility. The frequency of keying material updates at cell level depends upon the rate at which mobile hosts subscribe and cancel their subscription to, or are expelled from, the multicast group and the speed at which they roam from cell to cell. When both rates are low, i.e., few subscriptions and cancelations occur and the hosts move mostly intra-cells rather than inter-cells, periodic key refreshes might be useful to preserve system security against cryptoanalytic attacks. In this case, each cell CEK and KEKs would change at low rate. Each MSS can periodically perform a pseudo-join operation that forces a key update with no need to ocially announce it with explicit key distribution, as it can be detected from the keys increased revision number. Each MH may belong to more than one multicast data group, but for the sake of simplicity, we assume there is only one group. Such an assumption does not limit the generality of our protocol, as it can be extended to handle more than one group easily. 3

12

Also, periodic refreshes of the TEK might be needed. Since backward and forward trac secrecy are guaranteed at cell level, the current TEK could be used to encrypt the new one when it is sent out. The GM and the MSSes would execute: GM =) CG : fdata trafficgs k ; fs kgt0 ; ft0 g0 t 8si 2 CG; si =) Msi : fdata trafficgs k ; ffs kgt0 ; ft gt gcsi

6 Secure Multicast with Fully Trusted MSSes The protocol described in case of semi-trusted MSSes imposes two additional decryption operations on a mobile host wishing to recover the session key used to encrypt the data trac. The only way to eliminate the xed overhead of those operations is to have additional work done by the MSSes. This is possible if the MSSes are fully trustworthy so that they may have access to both the key encryption keys and the trac encryption keys, which give them access to both control and data trac. Although this might appear too strong an assumption, it is not unrealistic as it applies to geographically limited and well de ned networks, such as campus networks, where all MSSes are under the campus administrative control as well as the data trac of the multicast service. In this case too, we exploit the physical separation between the wired and wireless portions of the network and the clustered nature of the latter. We propose a two-tier cluster based protocol for key management, where both tiers implement a centralized tree VersaKey scheme, the rst tier among the GM and the control group, and the second tier at cell level, among each MSS and the members in its cell. The link between the two tiers is represented by the support stations. In order to minimize the overhead of secure multicast for mobile hosts, each MSS decrypts the data trac it receives and encrypts it with its local CEK before broadcasting it to the MHs. The GM executes: GM =) CG : fdata trafficgt Each si 2 CG recovers fdata trafficg, encrypts it to fdata trafficgcsi , and executes:

si =) Msi : fdata trafficgcsi The GM manages accounting, logging, auditing, and access control information as with semitrusted MSSes, and is also the group manager of the centralized tree VersaKey with the CG. The MSSes receive the TEK and all the KEKs necessary for the TEK distribution. The GM is involved in the rst tier key updates upon changes in the control group. The wireless network components and their wired support stations execute the second tier protocol, where each si 2 CG is the group manager of the centralized tree VersaKey with the hosts in Msi . The MSSes are involved in key updates upon joins and leaves from their local data groups, i.e., the Msi . We now illustrate each operation in details.

6.1 Startup

Group creation is performed by the startup procedure. In this phase the group manager is con gured with group and access control information. For every multicast group, two subgroups are created: the data group DG, DG  M , of the mobile hosts interested in the data trac, and the control group CG, CG  S , comprising the MSSes to which the mobile hosts in the data group refer. A mobile host is added to the data group or removed from it upon group subscription and cancelation operations. Subscriptions and cancelations may cause key management operations in both tiers, as it will be explained. An MSS is added to the control group the rst time a member 13

of the multicast group enters the cell it controls or a mobile host in its cell subscribes to the data group and is the only member in the cell. An MSS is deleted from the control group when the only member of the multicast group in its cell exits the cell or cancels its subscription while remaining in the cell.

6.2 Subscription

Subscription is the high level operation a mobile host executes when it wishes to enter a multicast group. As in Section 5.2, subscription requests are digitally signed to allow the GM to authenticate the newcomer. The mobile host m communicates a subscription request to the GM by means of its MSS s. The MSS forwards the request to the GM , which decides whether to approve or reject the request. In the armative case, the GM adds m to the data group and noti es s to proceed with the join operation. The GM then searches the control group for s and, if s is not in CG yet, the GM proceeds with an add operation.

6.2.1 Add

An add is a rst tier operation performed when an MSS must be added to the CG upon a mobile host subscription request from an MSS not in CG or upon a hand-o to a cell whose MSS is not in CG. When the GM adds s to CG, it identi es the set of KEKs s needs, Ks , along the path in the key tree from the leaf corresponding to s to the root t. In order to guarantee backward secrecy, the TEK t and the KEKs Ks are passed through a hash function, their revision number is increased by one, and the keys are then distributed to s. The other nodes realize that a change has occurred by noting the increased revision number in the keys in the rst message distributed after the key update. The GM executes: ?1

GM ?! s : fKs ; t0 gGMs; fGMsgppGM s where GMs is a symmetric session key used to encrypt the payload for eciency reasons, thus limiting the use of asymmetric cryptography.

6.2.2 Join

A join is a second tier protocol operation performed when a mobile host m enters the Ms in a cell, either upon a subscription request or upon a hand-o procedure. In the former case, the GM authorizes the join, in the latter the exited MSS passes the authorization to the destination MSS. The operation is a join in the centralized tree VersaKey at cell level and is the same as the one described in Section 5.2.2.

6.3 Cancelation

Cancelations occur under two conditions: either a member does not require the group service any longer or it is expelled by the GM . In the case of forced cancelation, the GM noti es s that the member m in its cell has been expelled. The GM cancels m from the data group and veri es whether it should also remove s from CG. If s is not removed from CG, i.e., other mobile hosts are still in its cell, s is noti ed to proceed with a leave operation.

14

6.3.1 Delete

A delete is a rst tier protocol operation the GM executes when s is removed from the control group CG because no data group member is left in its cell. The set of KEKs Ks s has in common with other MSSes according to the centralized tree VersaKey scheme must be changed in order to guarantee forward secrecy of the trac at MSS level. Let nCG = dlog jCGje be the height of the tree of KEKs of the control group. GM executes the following:

GM =) CG : fkn0 CG ?1gGMs; fkn0 CG ?2gkn0

CG ?1

; fkn0 CG?2gknCG ?1 ; : : : ; ft0 gk10 ; ft0 gk1

where knCG = GMs and kn0 CG?1; : : : ; k20 ; k10 are the new KEKs along the path from GMs to t0 . New keys are identi ed by an increased version number.

6.3.2 Leave

A leave is a second tier protocol operation s executes when it removes m from Ms. s changes its local CEK and the KEKs m has, in order to prevent m from accessing data trac multicast after it left the group, thus guaranteeing forward trac secrecy at cell level. The operation is similar to the one described in Section 5.3.2.

6.4 Hand-o

As in Section 5.4, issues such as trac retransmission are handled as already described. The dierence in this case is that re-keying occurs in the rst tier protocol as well. The second level re-keying is performed like in Section 5.4. The exited MSS s executes a leave and the entered MSS 0 s executes a join. In the rst tier protocol, adds and deletes are performed according to the same cases, the dierence being that re-keying is executed for each such operation. if none of the two MSSes involved changes its membership in0 CG, the GM does not perform any re-keying. If s 2 CG before and after the hand-o, but s 2 CG only after the hand-o, GM performs a re-keying for s0 addition to CG. If s; s0 2 CG before the hand-o but s 62 CG after the hand-o, then GM 0 performs a re-keying for s deletetion from CG. Finally, if before the hand-o, s 2 CG and s 62 CG and after the hand-o, s0 62 CG and s0 2 CG, GM performs a re-keying for s delete which can serve also as a re-keying for s add, thus avoiding one add operation.

6.5 Refresh

Similar considerations to those presented in Section 5.5 apply in this case as well. However, in this case the TEK distributed by the GM changes more frequently as it is associated with changes in the CG. Still, the rates at which keying material updates occur both at cell and MSS level depend upon the rate at which mobile hosts subscribe and cancel their subscriptions to the multicast group and the speed at which they move around. If either rate is low, periodic key refreshes might be useful to maintain system security. In the presence of refreshes, a typical performance trade-o arises as to how CEK updates can be performed. In a system where the CG is fairly stable while the cell population Ms changes frequently, a more ecient CEK management scheme could be the following. CEKs do not change upon cell join/leave due to hand-os, thus optimizing hand-o execution. CEK changes are performed only upon subscription and cancelation and are noti ed to the MSSes in the control group by the GM upon noti cation of the event from the MSS involved in it. Because the keying material 15

is periodically refreshed, the chances for a mobile host to use the service without being entitled to it can be made arbitrarily small by reducing the refresh period. On the other hand, if the data group is highly dynamic and the control group changes also frequently, the scheme described in the previous sections is the most appropriate, as the overhead of centrally notifying the key updates via the GM would outweigh the bene ts of faster hand-os and less CEK update trac.

7 Discussion As we have seen in the previous sections, the amount of work performed by the various components in the three scenarios changes depending upon the level of trust in the MSSes. Since mobile hosts have limited computing power and energy supply, their participation in service execution should be as minimum as possible. Therefore, it is critical for the eective implementation of any service targeted to mobile users that the wired system components be able to execute most of the work required. In case of non-trusted systems, the peculiar nature of the system considered must be ignored as no actual collaboration can be expected from the support stations. Therefore, there is no alternative to having the mobile hosts behave as if they were wired ones, i.e., powerful and with unlimited power supply. They participate in a system wide key management that imposes O(NM ) keys on the group manager, where NM is the number of participating mobile hosts, and O(log jNM j) on each mobile host. If the support stations can be at least partially trusted, more ecient solutions can be devised. The protocol for semi-trusted systems is characterized by communication complexity O(log jMsj), time complexity O(1), storage requirement for the group manager O(1), and group member storage requirement O(log jMsj). The support stations are required to store O(Ms) keys and to encrypt each data trac session key using the local CEK. The main drawback of this protocol is the xed overhead of the double decryption operations each mobile host must perform in order to access the key used to encrypt the data trac. Such a drawback is overcome by the protocol for fully trusted systems, where only the mobile hosts decrypt the data trac. The proposed protocol is characterized by the following parameters. The communication complexity of a re-keying operation is O(log jMs j + log jCGj), where Ms is the set of mobile hosts in a cell and jCGj is the number of MSSes in the control group. The group manager stores O(jCGj) keys, each MSS support station s 2 CG stores O(log jMsj) keys for the local VersaKey it manages and O(log jCGj) keys for the VersaKey managed by the GM , and a mobile host stores O(log jMsj) keys. The greater costs of this solution compared to the previous one are compensated by a reduced overhead of the mobile hosts. From a security point of view, the trade-o with respect to the trust in the participating support stations is reversed. The advantage of using non-trusted support stations is that their security is not a concern for the correct execution of the protocol. Furthermore, the separation between security and networking aspects is clear. On the other hand, as the degree of trust in the support stations increases, thus increasing their involvement in the key management protocol, their security becomes critical for the correct execution of the protocols. Security and networking aspects are not as clearly separable as before.

8 Conclusions In this paper we investigated the problem of designing ecient key management schemes for the implementation of secure multicast primitive in mobile networks. We identi ed the characteristics 16

such schemes must exhibit and proposed two key management protocols. In order to decouple host mobility from group dynamics and to eciently perform keying material distribution, we proposed two-tier protocols that combine the cluster based approach with the tree based approach. The optimal load balance among the group manager, the support stations, and the mobile hosts is one of the driving goals in the protocol design. Our analysis shows that such a goal critically depends upon the trust that can be put on the support stations.

References [1] A. Acharya, B.R. Badrinath, \Delivering multicast messages in networks with mobile hosts," Proc. of the 13-th International Conference on Distributed Computing Systems, May 1993. [2] A. Acharya, B.R. Badrinath, \A framework for delivering multicast messages in networks with mobile hosts," to appear in ACM/Baltzer Journal of Wireless Networks, Special Issue on Routing in Mobile Communications Networks. [3] A. Acharya, A. Bakre, B.R. Badrinath, \IP multicast extensions for mobile internetworking," Proc. of the 15-th IEEE Conference on Computer Communications, Infocom '96, March 1996. [4] B.R. Badrinath, A. Acharya, T. Imielinski, \Impact of mobility on distributed computations," ACM Operating System Review, pp 15-20, 1993. [5] A. Ballardie, \Scalable multicast key distribution," RFC 1949, May 1996. [6] M. Burmester, Y.G. Desmedt, \Ecient and secure conference key distribution," Proc. of the Security protocol Workshop, pp 119-129, 1996. [7] R. Canetti, B. Pinkas, \A taxonomy of multicast security issues," Internet draft , April 1999. [8] R. Canetti, J. Garay, G.Itkis, D. Minciaccio, M. Naor, B. Pinkas, \Multicast security: a taxonomy and ecient reconstructions," Proc. of IEEE Infocom '99, 1999. [9] G. Caronni, H. Lubich, A. Aziz, T. Markson, R. Skrenta, \SKIP: Securing the Internet," Proc. of the IEEE fth Workshop on Enabling Technologies (WET ICE), 1996. [10] G.H. Chiou, W.T. Chen, \Secure broadcasting using the secure lock," IEEE Transaction on Software Engineering, 15(8), pp 929-934, August 1989. [11] S.E. Deering, \Multicast routing in internetworks and extended LANs," Proc. of the ACM SIGCOMM '88, pp 55-77, 1988. [12] S.E. Deering, \Host extensions for IP multicast," RFC 1112, 1989. [13] A. Fiat, M. Naor, \Broadcast encryption," Advances in Cryptology: CRYPTO '93, Lecture Notes in Computer Science 773, Springer Verlag, pp 480-491, 1993. [14] L. Gong, N. Sacham, \Multicast security and its extension to a mobile environment," ACM/Baltzer Journal of Wireless Networks, 1(3), pp 281-295, Oct. 1995. [15] H. Harney, C. Muckenhirn, \Group key management protocol (GKMP) speci cation," RFC 2093, July 1997. 17

[16] H. Harney, C. Muckenhirn, \Group key management protocol (GKMP) architecture," RFC 2094, July 1997. [17] D. Harkins, D. Carel, \The Internet key exchange (IKE)," RFC 2409, 1998. [18] T. Imielinski, B.R. Badrinath, \Mobile wireless computing: challenges in data management," Communication of the ACM, 37(10), pp 18-28, 1994. [19] P. Kruus, \A survey of multicast security issues and architectures," Proc. of the 21st National Information Systems Security Conference, Arlington, VA, October 1998. [20] M. Macedonia, D. Brutzman, \MBONE, The Multicast BackbONE," available from http://www.cs.ucl.ac.uk/mice/mbone review.html [21] T. Matsumoto, H. Imai, \On the Key predistribution system { a practical solution to the key distribution problem," Advances in Cryptology: CRYPTO '87, Lecture Notes in Computer Science 293, Springer Verlag, pp 185-193, 1988. [22] D. Maugham, M. Schertler, M. Schneider, J. Turner, \Internet security association and key management protocol (ISAKMP)," RFC 2408, November 1998. [23] S. Mittra, \Iolus: a framework for scalable secure multicasting," Proc. of the ACM SIGCOMM '97, pp 277-288, September 1997. [24] M. Steiner, G. Tsudik, M. Waidner, \Die-Hellman key distribution extended to group communication," Proc. of the 3rd ACM Conference on Computer and Communication Security, 1996. [25] M. Steiner, G. Tsudik, M. Waidner, \Cliques: a protocol suite for key agreement in dynamic groups," Research Report RZ 2984 (#93030), IBM Zurich research Lab, December 1997. [26] M. Waldvogel, G. Caronni, D. Sun. N. Weiler, B. Plattner, \The VersaKey framework: versatile group key management," IEEE Journal on Selected Areas in Communications, 17(9), pp 16141631, September 1999. [27] D.M. Wallner, E.J. Harder, R.C. Agee, \Key management for multicast: Issues and architectures," RFC 2627, June 1999. [28] C.K. Wong, M. Gouda, S.S. Lam, \Secure group communications using key graphs," Proc. of the ACM SIGGOMM '98, pp 68-79, September 1998.

A The VersaKey Protocol In this section we brie y recall the centralized tree VersaKey scheme, for the ease of the readers, where the participants are generic hosts mi 2 M and jM j = NM . Unless otherwise speci ed, we adopt the notation described in Section 2.4. Keys are identi ed with a key identi er, a revision number, and a version number. The revision number is increased by one when the key is passed through a hash function upon a join. The version number is increased by one when the key is changed upon a leave. In the centralized tree VersaKey protocol, each group member mi is associated with an individual key GMmi it shares with the GM. Note that such a key could be either the member's 18

public key, if a PKI is in place, or a symmetric key established with the GM for direct communications. A dynamic balanced binary tree of key encryption keys is built by the GM. Root of such a tree is the TEK t and leaves are the individual keys GMmi; i = 1; : : : ; NM . The tree depth is d = dlog2 NM e and the tree contains up to 2d ? 1 keys. A generic tree is illustrated below. t k1

k1 k2

k2 k d-2 k d-1

GMm

GMm

Figure 1: A generic key tree. The GM stores all the keys in the tree, while each member mi stores only the d keys along the path from GMmi to t. When m joins the group, a position in the tree is found for the new leaf GMm and new revisions of the keys along the path from GMm to t, including t, are given to m. The other members will realize some of the KEKs and the TEK have been updated from their increased revision numbers. When m leaves the group, that same set of KEKs and the TEK must be changed. New keys are identi ed by an increased version number. Let the KEKs along the path from GMm to the root t that must be changed be kd?1; kd?2; : : : ; k2; k1, where kd = GMm, k0 = t, and let ki be the sibling of node ki in the tree. GM executes the following:

GM =) M : fkd0 ?1gGMm; fkd0 ?2gkd0 ?1 ; fkd0 ?2gkd?1 ; : : : ; fk10 gk20 ; fk10 gk2 ; ft0 gk10 ; ft0 gk1

19