Multicast Security

As internet continues to grow phenomenally, the desire for more efficient ways of distributing information across network is increasing. Multicast technology is used for distributing data to a group of participants by conserving bandwidth more efficiently than traditional unicast mechanism. This is done by replicating IP streams in the router at the same time thus achieving better delivery to multiple users.

This would mean conservation of computational resources of the sender and bandwidth efficiency in the network .A group membership can be performed using the Internet Group Multicast Protocol (IGMP) protocol. It provides admission control operation such as "join" and "leave". Some examples of applications that take advantage of multicast technology are video conferencing, digital broadcasting, software distribution and electronic learning. The Figure 1 depicts an example of a multicast distribution tree where information from a single sender traversing to multiple receivers.

Security in the other hand is a critical element for the deployment of IP multicast technology. According to the recommendation from International Standards Organization (ISO), criteria’s for designing a secure system are confidentiality, integrity, authentication, non-repudiation and access control. Cryptography is fundamental to these criteria as it involves asymmetric and symmetric key operations. Therefore, management of these keys plays an important role in designing multicast security. On the standardization front, IETF has formed Multicast Security (MSEC) Workgroup to standardize protocols for securing group communication over the internet. The workgroup has made it an important objective to standardize group key management architecture. This paper will incorporate many of the features documented in MSEC Group Key Management Architecture, Multicast Security Architecture, Group Security Association  Key Management Protocol , Group Domain of Interpretation and other related group key management documentations within IETF multicast security workgroup.

Group Key Management

Group Key Management refers to the process of managing cryptographic keys in a secure multicast group .The handling of these keys in multicast security is complex because it has to operate in a very dynamic environment. Typically in a unicast key management mechanism usually works only between two hosts. Multicast in the other hand requires handling scenarios that involves one-to-many or many-to-many

Communication. Consequently, these may require more than one keys required for a session. Ideally, due to handling of more cryptographic keys, a trusted entity is needed to manage them. Therefore, multicast security workgroup proposals are mainly base on the Group Controller and Key Server (GCKS) trust model developed in GKMP. It provides a high-level overview on the relationship of the entities involved

In multicast security that is centered on GCKS. Additionally, Group Security Association (GSA) is an important element for the construction of a secure multicast group.

It provides a way to associate cryptographic attributes so that all members in the group can communicate together securely. The trust model and GSA forms the basis for group key management. The following subsection will elaborate on them.

 2.1 Trust Model

The trust model used as the building block for group key management are mainly base on the Group Controller and Key Server (GCKS) model developed in GKMP [3]. Figure 2 shows the components of this trust model. The model provides a high-level overview on all entities relating to group key management. The idea behind this is a trusted entity called GCKS.

The Group Controller/Key Server (GCKS) is responsible for the issuance and management of cryptographic keys. GCKS also plays the important role for admission control for the multicast group and performs user authentication when a member joins the group. Since this com onent is so integral to the trust model, all components require interfacing with GCKS. Conse uently, any compromise to GCKS can possibly lead to the security integrity breakdown of the ulticast system. In figure 2, the Sender is the entity that transmits data to the multi         ast group while the Receiver is the entity that receives the data. In a multicast group, there can be a 1-to-N multicast group where only a single sender is allowed transmit data while in a M-to-N multicast group more than one sender is allowed to transmit data to the group. In some cases, all members of the groups are allowed to be senders.The senders and receivers require performing authentication, admission control and keys downloading from GCKS. Policies in the other hand have to be The Policy server shown in figure 2 is responsible for creation and management of the policies. The policies are managed, disseminated and accessed via GCKS to group the members. Policies are important in multicast security group key management, as it will decide on how keys are to be managed and cryptographic operation to be performed. The relationship of these entities illustrated in the model provides a good reference framework for an architectural group key management design.

2.2 Group Security Association (GSA)                                          

              In typical unicast operation in IPSec [4], Security Association (SA) is used as a way to map identical security attributes so that two host can communicate securely. These attributes include cryptographic keys, algorithm, identifier and other related attributes used to associate with the security material. Multicast however needs to handle more complex scenarios where it has to communicate with more than one host at a time. Due to its complexity, it requires more than one key to keep a multicast session secure. Therefore, group key management introduces the concept of Group Security Association (GSA) [6] to group multiple SAs. In multicast security system, a GSA can contain three or more SAs. GSA is constructed in two distinct ways. They are the superset and aggregation that is illustrated in Figure 3. Superset is when GSA forms the superset of an SA. An example would be signed credentials to certify group membership if it will be allowed new keys when a join or leave operation occurs. Aggregation is when a GSA comprises multiple SAs where each of them may be used for different purposes such as Key Encryption Keys (KEK) and Traffic Encryption Keys (TEK) that will be explained in dynamic secrecy section.

Architecture

                As mentioned earlier in the paper, multicast security workgroup has made it an important objective to standardize the group key management architecture. It is described and documented in the internet draft. Its purpose is to be used as a guideline for designing group key management protocols supporting different types of applications, transport and network layer security protocol.

3.1 Requirements

                According to group key management architecture [11], it has listed out twelve requirements for group key management protocol. The following is the list of the requirements. First, the requirement suggests that group members should receive SA that includes cryptographic keys for encryption and authentication, the policies to describe these keys and attributes for referencing the SA. Second, GCKS requires providing access control mechanism in regards to the policies associated with the group keys. These access control mechanism may include definition and enforcement for group Membership, key management functionalities and policies. Third, when keys are created, it requires having a predetermined

Life time. The keys may also be periodically updated to maintain group secrecy. Fourth, key material should always be delivered in a secure manner to group members. It has to be protected using integrity and verifiable mechanism

Such as public key cryptography or keyed hash. Fifth, the protocols designed for group key management should be able to protect against replay attacks and denial of service (DOS) attacks. Sixth, the protocol should provide the ability

For the addition,or removal of group members. In the event of addition, group members can be optionally denied access to previous group session keys. On the other hand, member removal of the group will cause the member to lose access

the key material. Seventh, the protocol should allow support for scalable group rekeying. Unicast rekeying operations is undesirable as it will overload GCKS managing a large multicast group. Eight, when designing the protocol, it should be compatible with current infrastructure and performance requirements of the data security application. Examples of these applications are IPsec security protocols, such as Authentication Header (AH) and Encapsulating Security Protocol (ESP) and application layer security protocols such as Secure Real Time Protocol (SRTP) and Transport Layer Protocol (TLS) ninth; the protocol should offer framework for updating transforms authorization and authentication system. Tenth, it should be designed to protect against collusion among excluded members or non-members. Collusion is the term used when members collaborate to deduce keys that they are not privileged to have. Eleventh, the protocol should provide a mechanism to be able to recover from some of the compromised key material securely if not all. Twelve, the key management protocol should support deployment issues such as Network Address Traversal (NAT) and legacy systems that are widely in used. These requirement however is not intended to be an exhaustive list nor applicable to all applications. So, an adaptive approach should be used when incorporating these requirements in the design.

Conclusion:

Group key management itself is a complex topic. The paper has focused mainly on the trust model and GSA as a reference for group key management. Since multicast security needs to support deployment issues, a single protocol

alone so far is incapable to support the various scenarios in multicast security. GSAKMP,MIKEY and GKDP are examples of protocols developed to support the difference kind of use cases. Although policies are not mentioned much in this

paper, it is also an important component of group key management as it is responsible for many decision-making roles. They are essential for deployment of secure multicast system. On the other hand, rekeying algorithms such as LKH

helps in protecting group secrecy in a dynamic multicast environment. In light of this study, multicast security still have some way to go for us to experience a full fledge secure system. Issues are complex that needs to be studied and standardized. And from there, it requires effort from the industry to implement it so that it eventually becomes a reality.