The proliferation of group applications associated with the growing con- cern for secure group communication drives the need for efficient and se- cure solutions for group communication services [168 - 172]. Multicasting is an effective mechanism for supporting group communication. In a mul- ticast communication, each sender transmits only one copy of each mes- sage that is replicated within the network and delivered to multiple receiv- ers. For this reason, multicasting typically requires less total bandwidth than separately unicasting messages to each receiver. Since most of com- munications occurring on a grid imply many participants that can be geo- graphically spread over the entire planet, multicast protocols can provide an efficient way of handling the data transfer. Several multicast systems have been developed for grid based applications [173]. Since there are lots of security issues in multicasting where still research is being carried out, most of the grid based implementations do not have them in place. In this section, we provide a brief overview of existing general multicast security issues and solutions.
8.5.1 Secure Multicasting
Secure multicasting, like any other fields of security, is based on the prin- ciple of confidentiality and integrity. These solutions cannot be trivially extended to multicasting scenario for multiple reasons:
• Unlike unicasting, in multicasting, data has to be shared among multiple group members.
• Group members may join/leave the multicast session at any time.
• Nonmembers must be prevented from collaborating (colluding) to recover the session key.
The issues that differentiate secure multicasting from any other modes of secure communication can be broadly categorized into member authentication, key management and packet authentication. An interaction between the different modules of secure multicasting is shown in Fig. 8.5. Whenever a user (A in the figure) is accepted into the multicast group, a distance vector update. Several other variations of this algorithm [167] have
8.5 Multicasting 179 new key is generated (in the rekeying module) and distributed (in the key distribution module). The source authentication module comes into the pic- ture when the multicast group receives packets from the sender S. The sender may be part of the group or may be outside the group. When a member leaves the multicast group, rekeying and key distribution modules are invoked. The three issues along with their proposed solutions are listed in Fig. 8.5.
Fig. 8.5. Overview of the different issues in secure multicasting
Member Authentication
Group management involves the fundamental functionality of admission control of the group members. In secure multicasting, only valid users should be able to access data. For example, in a live lecture session only the registered users should be able to listen to the lectures. Member au- thentication has been traditionally performed in multicasting using a cen- tralized architecture. Recently some systems have been proposed which authenticate members in a hierarchical fashion. Scalability and complexity in implementation are the main selection criteria.
• In centralizedmember authentication, a centralized controller is used for authentication purposes. It is simple to implement. How- ever, it introduces a single point of failure. An example of such schemes is the Core Based Tree (CBT) mechanisms.
• In a hierarchical member authentication scheme, there are mul- tiple controllers arranged in a hierarchical fashion. The member joins to the nearest controller. Iolus architecture [174] introduces the hierarchical member authentication approach. These systems are more scalable; however controllers need to be deployed in each multicast node.
• In case of distributed authentication techniques, the authentica- tion capability is distributed throughout the network. In [175], the authors describe a mechanism where the authorization server pro- vides access tokens to the group members and access control lists to the routers. These types of schemes require additional intelli- gence at the router level.
Key Management
After the establishment of multicast session, management of keys needs to be handled. Management of keys involve: distribution of keys in a scalable and secure manner to all the group members, and rekeying when members join/leave the multicast group. Distribution of keys remains an interesting and challenging problem. This is quite different from a unicast scenario, where a key is to be shared by the sender and the receiver only. In multi- casting, keys need to be shared among the group members in a scalable manner.
• Core based techniques were discussed by [176]. In this scheme the core of the multicast group is also responsible for distribution of keys.
• In the hierarchical key distribution scheme, the distribution is split up among different entities in a hierarchical fashion. Two common hierarchical key distribution schemes are [174], and KHIP [177].
• In the last few years, a new technique [178, 179] has been proposed which allows the use of single group data key for data transmission (as in core based schemes), as well as having scalable add and delete operations (as in hierarchical schemes). These tech- niques are referred to as tree based techniques or key graph tech- niques. The main idea behind these techniques is to have a single server or core, and to have the server distribute subgroup keys in
8.5 Multicasting 181 addition to the individual user and group keys. To balance the cost of addition and deletion, the keys are arranged in logical hierarchy (instead of physical hierarchy as in Iolus), with the root key being the root and the individual user keys being the leaves. The sub- group keys then correspond to the intermediate nodes of this con- ceptual tree.
Rekeying is needed as keys need to be changed to prevent the users from accessing them after the user leaves a multicast group.
• Individual Rekeying: In this technique, new keys are created as soon as a member joins/leaves a multicast group to provide join/leave secrecy.
• Periodic Batch Rekeying: In this type of rekeying, requests are collected for a certain amount of time (called the rekey interval), and then rekeying is carried out in a batch. The batch rekeying techniques have been explained and analyzed in [180].
Source Authentication
The source authentication problem is different in multicasting than in tradi- tional unicasting, as the authentication has to be carried out in a scalable manner, and there is a possibility of group members colluding.
• Individual Signature: The simplest way to deal with the authenti- cation problem is to sign each and every packet. This is not a prac- tical scheme as this is computationally very expensive. However, the scheme does not introduce any extra delay into the authentica- tion mechanism, i.e. the latency is low. The scheme also is not vulnerable to collusion, as each and every packet is signed.
• Single MAC Schemes: Message Authentication Codes (MAC) are also traditionally used for authentication. A MAC creates an out- put from a shared secret key and the message itself. The output, the signature of the packet, is then appended to the packet itself for transport across the network. MACs are generally faster to com- pute than the public key signatures; they also require that every re- ceiver has access to a shared key. This is different from the public key approach, where any user can have access to the key. These schemes are more efficient than the individual signature scheme. Any receiver can pose as a sender by signing a message of its own with the shared key.
• Stream Signing: A stream can be defined as a potentially very long (infinite) sequence of bits that a sender sends to a receiver [181]. The key aspect of the stream is that the receiver must take data as received, and process it as soon as possible. In [181], the authors assumed that it is possible for the sender to embed authen- tication information into the stream, and the receiver has a small buffer where it can authenticate received bits. The stream is di- vided into blocks, and the authentication information is embedded into the stream. The information from the ith block is used to au- thenticate the (i+1)th block. The signer needs to sign only the first block, this signature will propagate through the rest of the stream through authentication information. The above mechanism re- quires high efficiency and packet loss cannot be tolerated. There- fore, there must exist an underlying reliable transport protocol like TCP.
• Chaining: To increase the efficiency of the stream signing proto- cols, in [182] efficient schemes have been proposed which remove the deficiencies of the stream signing problems. To accomplish these requirements two chaining schemes have been proposed to sign and verify multiple packets, denoted as blocks, in a single op- eration. Since all the packets in a block are signed and verified in only one operation, the procedure can be amortized over the entire block, making the overall rates much faster than the other meth- ods. The basic function of both these methods is to compute the block digest of each block as part of the authentication informa- tion. The authentication information consists of the signed digest of the block and some addition chaining information so the re- ceiver may verify where it belongs in the block. This is a very effi- cient approach. However, unequal authentication information may lead to bursty traffic.