Multicast Security and Reliable Transport of Rekey messages over Hybrid Satellite/Terrestrial Networks
Franco Tommasi, Elena Scialpi, Antonio De · InTech eBooks · 2011
Security problems in satellite environments are one of the obstacles to the widespread deployment of satellite IP multicast and, more generally, of satellite multimedia applications (Cruickshank et al., 1998).By satellite environments we refer to networks where the satellite plays an essential role.e.g.those where it is used to multicast IP packets to many nodes of a terrestrial network.We also speak of "Hybrid Satellite/Terrestrial networks" in such cases.The broadcast nature of satellites makes eavesdropping and active intrusion much easier than in terrestrial ﾙxed or mobile networks.A further issue is speciﾙct om u l t i c a s t : t h e number of members in a multicast group can be very large and, even worse, can change very dynamically.While the process of performing and securing key management for unicast connections is well understood (Harkins & Carrel, 1998), (Maughan et al., 1998), (Orman, 1998), multicast security is still an open ﾙeld (see par. 2).Protocols that manage the process of distributing keys in a multicast environment are under development (see par. 2.3 and 2.4).Access to the encryption key is controlled by a group key management system, which is responsible for sending the encryption key to authorized new users and for performing multicast group rekeying whenever the key changes.Speciﾙcally, a group key management system is said to implement two types of access control: backward access control and forward access control.If the system changes the encryption key after a new user joins, the new user will not be able to decrypt past group communications; this is called backward access control.Similarly, if the system rekeys after a current user leaves, or is expelled from the system, the departed user will not be able to access future group communications; this is called forward access control.Many group key management solutions (see par. 2.2, (Jokela, 2006) (Mah, 2004)) have been proposed and a number of classiﾙcations of the available approaches can be found in the current literature (Dondeti et al., 1999), (Rafaeli & Hutchison, 2003), (Eskicioglu, 2003).Moreover, security mechanisms regarding satellite networks have been investigated in (Howarth et al., 2004), (Noubir & Allmen, 1999) and (Arslan & Alagöz, 2006).Group key management protocols can be categorized as following:• Centralized architectures.A single entity, a GC (Group Controller), is employed for controlling the whole group, hence a group key management protocol seeks to minimize 4 www.intechopen.com 2 Will-be-set-by-IN-TECH storage requirements, computational power on both client and server sides and bandwidth utilization.• Decentralized architectures.The management of a large group is divided among subgroup managers, trying to reduce the problems arising from concentrating the work in a single place.• Distributed architectures.There is no explicit manager and the members themselves do the key generation.All members can perform access control and the generation of the key can be contributory, meaning that all members contribute some information to generate the group key.Rekey protocols should use a scalable Group Key Management Algorithm (GKMA) to send the minimum possible number of keys in a rekey message.LKH (see par. 2.3), OFT (Balenson et al., 2000), Subset difference based schemes (Lotspiech et al., 2001) are examples of GKMA.Regardless of the chosen approach, rekey messages are generally frequent and their reception must be guaranteed in order for the multicast group members to avoid multicast services interruptions.RFC 4046 (Baugher et al., 2005) describes a Group Key Management Architecture and proposes three classes of solutions for reliably sending keys to the multicast group members:• repeatedly transmit the rekey message;• use FEC for encoding rekey packets (with NACKs as feedback) (Yang et al., 2001);• use an existing reliable multicast protocol/infrastructure (possibly proﾙting in a mixed way from the above solutions).Up to now, not much work has been dedicated to the use of reliable multicast transports for rekey messages.In most cases ((Wong & Lam, 2000) (Zhang et al., 2003)) FEC (Rizzo, 1997) has been used to improve the reliability.RFC 4046 also identiﾙes the requirements a protocol for key transmission/rekeying must satisfy:• Reliability.Every user must receive all of its (encrypted) new keys, no matter how large the group size.• Soft real-time.It is required that the delivery of new keys to all users be ﾙnished with a high probability before the start of the next rekeying.• Scalability.The processing and bandwidth requirements of the key server and those of each user should not increase much with the group size so that a single server is able to support a large group.Moreover, multicast key distribution must take care of the "feedback implosion" problem (see par. 2.2.4 and (Baugher et al., 2005) resulting from NACKs or ACKs sent as feedback.Satellite networks may intrinsically offer a serious alternative to terrestrial networks solutions in that they can enable reliable multicast techniques to scale to large group of receivers.Such advantage is an effect of their intrinsic properties such as: high bandwidth availability, their broadcast nature and the reduced occurrence of congestion between sender and receivers as compared to terrestrial networks.With these considerations in mind, we focused our attention on the following protocols for the multicast reliable transmission of encryption keys: Pragmatic General Multicast (PGM) (see par. 3.1), NACK-Oriented Reliable Multicast (NORM) (see par. 3.2 ) and our SRDP-Sign (see 84