KEY MANAGEMENT FOR SECURE GROUP COMMUNICATION IN A WIRELESS ENVIRONMENT

Transcription

1 KEY MANAGEMENT FOR SECURE GROUP COMMUNICATION IN A WIRELESS ENVIRONMENT BABAK DAGHIGHI DISSERTATION SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE MASTER DEGREE OF COMPUTER SCIENCE FACULTY OF COMPUTER SCIENCE AND INFORMATION TECHNOLOGY UNIVERSITY OF MALAYA KUALA LUMPUR May 2010

2 UNIVERSITI of MALAYA ORIGINAL LITERARY WORK DECLARATION Name of Candidate: Babak Daghighi (I.C/Passport No: F ) Registration/Matric No: WGA Name of Degree: Master of Computer Science Title of Project Paper/Research Report/Dissertation/Thesis ( this Work ): Key Management for Secure Group Communication in a Wireless Environment Field of Study: Network Security I do solemnly and sincerely declare that: (1) I am the sole author/writer of this Work; (2) This Work is original; (3) Any use of any work in which copyright exists was done by way of fair dealing and for permitted purposes and any excerpt or extract from, or reference to or reproduction of any copyright work has been disclosed expressly and sufficiently and the title of the Work and its authorship have been acknowledged in this Work; (4) I do not have any actual knowledge nor do I ought reasonably to know that the making of this work constitutes an infringement of any copyright work; (5) I hereby assign all and every rights in the copyright to this Work to the University of Malaya ( UM ), who henceforth shall be owner of the copyright in this Work and that any reproduction or use in any form or by any means whatsoever is prohibited without the written consent of UM having been first had and obtained; (6) I am fully aware that if in the course of making this Work I have infringed any copyright whether intentionally or otherwise, I may be subject to legal action or any other action as may be determined by UM. Candidate s Signature Date: Subscribed and solemnly declared before, Witness s Signature Date: Name: Designation: ii

3 Abstract In recent years, group based applications and protocols have gradually gained popularity in term of data traffic distribution across a group of members. Examples of such applications are software updates, multimedia conferencing and information dissemination service. Since these applications typically involve communication over open network such as Internet, security has become an important requirement for them. An efficient key management is able to provide confidentiality and integrity of data exchange between members of a group. This dissertation is focused to study group key management schemes which are appropriate for wireless environment. However, most previous works on group key management have been prominently proposed for deployment in wired environment. Thus, it is the aim of this research to propose an appropriate group key management scheme for wireless environment. This work contains three main parts. First of all, a number of group key management schemes which are further classified into three design approaches including centralized, decentralized and distributed are studied. As a result, the advantages and drawbacks of these approaches are compared in order to identify the appropriate group key management design for wireless environment. Secondly, based on extracted result from the comparisons, a decentralized approach is selected as a desired architecture for group key management in this work. The components and their roles as well as protocols which involve in this architecture are then described in detail. Thirdly, an implementation of the proposed approach is conducted by using Java application programming interface (API) platform. The implementation provides a realistic evaluation of proposed scheme and tested for different aspects in regarding to join operation, leave operation and updating key materials. The work is finally concluded by identifying future research directions. iii

4 Acknowledgements It is my pleasure to thank the people who made this research possible. First and foremost, I would like to record my genuine gratitude to my supervisor, Dr. Miss Laiha Mat Kiah for her excellent supervision, advice, and guidance from the very early stage of this research as well as giving me extraordinary experiences throughout the work. Above all and the most needed, she provided me unflinching encouragement and support in various ways. I am indebted to her more than she knows. My deepest and most heart-felt thanks go to my most beloved family and adored family in-law, for their endless love and support. They have instilled in me a love for knowledge and a strong work ethic which has enabled me to accomplish anything I set my mind to. They have always supported me in whatever I do and wherever it is possible. To those who were directly and indirectly involved in this research, your contribution shall not be forgotten; please accept my utmost appreciation to all of you. Above all, I would like to thank God for His grace in granting me to complete my studies. iv

5 To my wife Sara, for her unconditional loves and supports. v

6 Table of Contents List of Figures... x List of Tables... xii Abbreviations...xiii Chapter 1. Introduction Problem statement Research Objectives Study Significance Dissertation Structure... 5 Chapter 2. Literature Review Multicast vs. Unicast Key Management Centralized Group Key Management Group Key Management Protocol (GKMP) Logical Key Hierarchy (LKH) GKM-A Hybrid GKMF for Secure Wireless Multicast Wang Scheme Summary Decentralized Group Key Management Iolus Intra-Domain Group Key Management Protocol vi

7 Kostas Scheme in Mobile Networks Hierarchy based Key Management for SGC in Mobile ad hoc Networks Wang and Atwood Scheme GKMF-WMoE Summary Distributed Group Key Management ING GDH GDH GDH Octopus Protocol STR TGDH CRTDH Summary Design Approaches Analysis Chapter Summary Chapter 3. Research Methodology Background Study System Analysis System Design System Implementation System Testing Chapter Summary vii

8 Chapter 4. System Analysis Main Components of Decentralized Approach Main Entities Domain and Area(s) Placement of Entities Type of Keys Main Protocols Proposed Scenario Description Use Case Diagram Purpose of Use Case Diagram Notation of Use Case Diagram System Requirement Use Case Diagram of Proposed scenario Chapter Summary Chapter 5. System Design Architecture Main Entities Domain and Area(s) Entities Placement Trust Relationships Type of Keys Protocol Functionalities Protocol I: New Member Join a Group Communication Protocol II: Existing Member Leaving Group Communication Protocol III: Rekeying Group-Traffic Key viii

9 Protocol IV: Rekeying the Area Key Chapter Summary Chapter 6. Implementation and Testing Implementation Requirements Software requirements Hardware Requirement Architecture Development Domain Key Manager Area Key Manager Member Testing Scenario Deployment Discussion Join Operation Leave Operation Rekeying Operation Chapter Summary Chapter 7. Conclusion and Future Works Conclusion Research Contributions Future Works Bibliography ix

10 List of Figures Figure 2.1: An example of user joining /leaving logical hierarchy tree (Wong, et al., 1998) Figure 2.2: Logical member structure Figure 2.3: An example of Iolus hierarchy Figure 2.4: Intra-Domain Group Key Management Elements Figure 2.5: An example of Kostas scheme Figure 2.6: An example of nodes placement Figure 2.7: Example of STR key tree Figure 2.8: Notation of TGDH Figure 3.1: Research methodology flow Figure 4.1: An example of basic model for group key management Figure 4.2: An example of domain and areas Figure 4.3: new member send request message Figure 4.4: DKM grants permission to new member Figure 4.5: The existing member leaves the multicast group Figure 4.6: Use case diagram of scheme Figure 5.1: An example of Domain and Areas Figure 5.2: An example of placement of entities Figure 5.3: Member joining protocol message flow Figure 5.4: Member leaving protocol message flow Figure 5.5: Member leaving (involuntary) protocol x

11 Figure 5.6: Rekeying of a Group Traffic Key protocol message flow Figure 5.7: Rekeying of an Area Key protocol message flow Figure 6.1: Illustration of architecture used for testing Figure 6.2: AKMa registers itself to DKM Figure 6.3: DKM sends DA_Key to AKMa Figure 6.4: Member M 1 receives secret key Figure 6.5: AKMa governs member M1 join request Figure 6.6: Managing join request by DKM Figure 6.7: AKMa receives ready_to_rekey Figure 6.8: Receiving new T_Key by rekey message Figure 6.9: AKMb manages member M 2 leave notification Figure 6.10: DKM governs leave operation xi

12 List of Tables Table 2.1: Comparison of centralized group key management approach Table 2.2: Comparison of decentralized group key management Table 2.3: Comparison of distributed group key management schemes Table 2.4: Comparison of various group key management design approaches Table 4.1: Notations of use case diagram Table 5.1: Symmetric encryption algorithms comparison Table 5.2: Summary of keys needed in secure group communication Table 6.1: Hardware specification used in establishment of system xii

13 Abbreviations ACL: ACM: AES: AKD: AKM: API: CKS: CRT: CRTDH: DH: DKD: DKM: GC: GCKS: GCS: GKEK: GKEK: GKMP: GKP: GKP: GKS: GSA: GSI: GTEK: GUI: IEEE: IGMP: IP: KDC: KEK: LCM: LKH: SA: TEK: TGDH: TTL: TV: UML: Access Control List Association for Computing Machinery Advanced Encryption Standard Area Key Distributor Area Key Manager Application Programming Interface Cell Key Server Chinese Remainder Theorem Chinese Remainder Theorem and Diffie Hellman Diffie Hellman Domain Key Distributor Domain Key Manager Group Controller Group Controller and Key Server Group Security Controller Group Key Encryption Key Group Key Encryption Key Group Key Management Protocol Group Key Packet Group Key Packet Group Key Server Security Association Group Security Intermediaries Group Traffic Encryption Key Graphical User Interface Institute of Electrical and Electronic Engineers Internet Group Management Protocol Internet Protocol Key Distributor Center Key Encryption Key Least Common Multiple Logical Key Hierarchy Secure Association Traffic Encryption Key Tree based Group Diffie Hellman Time To Live Television Unified Modeling Language xiii

14 Chapter 1. Introduction In recent years, group based applications have significantly grown in popularity. These include multicast conferencing, information dissemination service, satellite TV distribution services, and online interactive forums. Multicast is able to provide an efficient delivery of data from one or more authorized sender(s) to multiple recipients (Deering, 1989). Regarding to property of multicast, any multicast enabled host can send IGMP (Fenner, 1997) (Cain, Deering, Kouvelas, Fenner & Thyagarajan, 2002) request message to its neighbor router and join to a multicast group. This property of multicast causes some security issues and vulnerabilities that may occur during communication between group members. As compare to unicast, multicast communication is more susceptible to be compromised and intercepted by malicious entity (Ballardie & Crowcrof, 1995). Multicast does not provide mechanism to confine unauthorized entity from accessing the multicast traffic (Ballardie & Crowcrof, 1995). Provision of an effective method for controlling to access to multicast communication and its relevant information is one of security challenges in group communication. In order to achieve a security scheme for group communication, a key management system is required. The main challenge of system is how to generate and distribute key to retain secure data and minimize overall impact on systems. 1

15 1.1. Problem statement The objective of securing group communication is to provide confidentiality, integrity and authentication security services. Confidentiality ensures the secret information is uncompromised during transmission and accessed by authorized parties. On the other hand, integrity results in the correct information is received by members of group and make them sure information has not been modified during transmit. Finally, authentication is the process of determining whether an entity of a group is the one, who claims to be. This research is focused on provision of secrecy in a group communication. The primary method for providing secrecy is use of cryptographic keys for protecting information of group based applications. A common key is shared between all members of a group to retain information confidential (Schneier, 1996). In dynamic group communication, where members of a group frequently join or leave the specific group, the shared key should be refreshed upon any changes in group membership (MSEC, 2009). The main purpose of refreshment of this traffic key is to prevent access to previous information by newly join member (backward secrecy) as well as next communication by departure member (forward secrecy). Another complex problem which arises in group communication is distribution of new shared key to authorized members (MSEC, 2009). Although the new key can be encrypted under old traffic key and distributed to members of group during join operation, updating key in which an existing member leaves the group is more complicated. Since the departure member knows the old key, it cannot be used for protecting new key. 2

16 A simple scheme for updating key material within a group communication with n members is using an entity of central key management which shares a secret key with each member of group. Every time when it is needed to conduct key updating in the group communication, the new traffic key is generated by this key manager which sends new key to every members of group. The new group key is encrypted under each member s secret key shared with the key manager with unicast. This operation is not efficient and scalable for large group. As a result, the design of efficient key management is critical aspect for a secure group communication. A group key management scheme is required in order to govern all aspects of management of cryptographic keys including entities and processes in multicast group. Group key management scheme is all components of security architecture for group communication. (Harney & Muckenhirn, 1997) proposed the first group key management protocol for a securing group communication. A central entity (is referred as key manager) is responsible to generate traffic key and distribution key. The new traffic key is shared between members of a group for protecting group communication. The new traffic key is protected under distribution key during dissemination to the group members. Subsequent research on group key management such as (Mittra, 1997), (Wong, Gouda & S. Lam, 1998), (Waldvogel, Caronni, Dan, Weiler & Plattner, 1999), (Hardjono, Cain & Monga, 2000), (Baugher, Canetti, Dondeti & Lindholm, 2005) has attempted to improve on Harney scheme. These group key management schemes were present for deployment in wired network. 3

17 In contrast with wired network, wireless environment introduces additional constraint in design of a secure group key management scheme. Many devices that are employed in wireless environment have low computing power and storage capacity (George, 1994) (Satyanarayanan, 1996). Thus they are not able to conduct large computation processes. These devices cannot maintain many numbers of keys as well. An efficient group key management scheme should cover the limitation such an environment during design stage. The aim of this research is to investigate the current group key management schemes in order to develop an efficient and scalable key management scheme for securing a group communication in wireless environment Research Objectives The main objective of this research is development of a group key management scheme which is proper for wireless environment. Some other objectives are required to be carried out during achievement of main aim. All objectives of this work are listed as follows To carry out a comparative study on existing group key management protocols. To design an appropriate group key management scheme for wireless environment. To deploy the group key management scheme. 4

18 1.3. Study Significance This work provides a deployment of group key management in wireless environment. It presents a software model of group key management scheme for providing a secure group communication. The model identifies the main components including key as well as main functionalities. The identified components contain key managers and member. Java application programming interface (API) can be used to implement group controller functionalities along with member functionalities in our suggested model. The implementation of scheme provides a real key management for a group communication. This allows different aspects of desired group key management are tested in real environment for achieving to an efficient scheme Dissertation Structure The rest of dissertation is organized as follows Chapter 2 Background Study A number of existing group key management schemes are looked to provide a brief review of their mechanism for deployment of secure group communication. A quantitative comparison shows their advantages and withdraws. Chapter 3 Research Methodology The methodology used for development of this work is explained. It covers and organized different required stages taken to deploy proposed scheme from the commencement of its lifecycle until end of its deployment. 5

19 Chapter 4 System Analysis The appropriate design approach for development of key management in group based communication is chosen in this section. The requirement of scheme is analyzed and main involved components are described. Chapter 5 System Design Based on the blueprint of generic model, the group key management scheme is specified in details. Subsequently, it is further defined employing sequence diagrams. Chapter 6 Implementation This chapter gives explanation of scheme implementation as well as system testing. The implementation of scheme is described in detail via representing the main classes which are used in coding of system. The testing is then shown as a result of scheme deployment. Chapter 7 Conclusion The work lastly is concluded in this chapter. The potential future enhancements of the proposed group key management scheme are discussed in this section. 6

20 Chapter 2. Literature Review This section gives an introduction to multicast communication or group based communication. This also provides overview to existing key management schemes. In Section 2.1, group communication term is defined. Subsequently Section 2.2 introduces various design approaches of group key management. Review of existing group key management schemes classified in three design approaches are shown in Section 2.3, 2.4 and Multicast vs. Unicast Multicast term can be defined as a network technology for the delivery of data to specific group of destination (or recipients) by a single transmission (Deering, 1989), (Wittmann & Zitterbart, 2001), (Ciscosystem, 2009). In the multicast communication, the source (or sender of data) needs to send a packet only once, even if it should be delivered to a large number of receivers. The nodes in the network will make copies of data and transmit them to multiple destinations, which have been determined prior to transmission. This special feature provides efficient ability for distributing data to a group of recipients, and therefore makes it attractive for group based applications services such as video conferencing. Multicast is more efficient in compare with traditional unicast method, in which data is transmitted only to one recipient. 7

21 2.2. Key Management Key management in multicast communication is more complex in contrast with unicast communication. In secure environment, prior to commencement of group session, a common key should be distributed among all members of a multicast group. In secure group communication, specific problems for managing key materials can be divided in two approaches depending on the group membership in place; as follows (Hardjono, et al., 2000), (Waldvogel, et al., 1999), (Mittra, 1997): Static approach. It is required no updates in keying materials throughout the lifetime of a multicast group due to its fixed membership policy. Dynamic approach. In this approach, member can join or leave a multicast group at any time. It is therefore needed to be updated the cryptographic keys whenever any changes occur in the multicast group. the precise need for updating the keys is determined by whether the following services are required: i. Backward secrecy. This ensures that the newly joined members are not able to access to previous communication including group keys and their related information. Backward secrecy is provided by updating the keying material whenever a new member joins a multicast group. ii. Froward secrecy. This ensures that the future communication keep inaccessible from the leaving member. For provision of forward secrecy, the keying material should be updated whenever an existing member leaves the multicast group. 8

22 One of the main challenges in key management, which is emerged during group communication, is distribution of the keys required by group members (MSEC, 2009). It can be more complex in dynamic approaches where members frequently join or leave a multicast group. It is important to ensure that each member receives appropriate keys for accessing to the right group. They must deprive from access to some cryptographic keys for provision of backward and forward secrecy as well. Group key management scheme is an infrastructure comprising the basic entities and necessary functions for provision a common cryptographic keys between all members. It specifies entities and relation between them as well as key management processes. The different proposed scheme can be divided in to three approaches as follows (Rafaeli & Hutchison, 2003): Centralized schemes. A single entity undertakes governing keying material in the group. Decentralized schemes. The responsibility of key management in large group is divided between a numbers of subgroup managers. Distributed schemes. In absence of a central group key manager, all group members contribute some information in order to generate group key. The rest of this section looks at existing group key management schemes for identifying the useful attributes for this work. For this purpose, the existing schemes are classified into three design approaches including centralized, decentralized and distributed.the architecture of each scheme is briefly presented, since they may 9

23 influence the design of this work. Finally, the investigated schemes are analyzed at the end of each approach Centralized Group Key Management In centralized system, one entity is responsible to control the whole group members. It must initiates group traffic key during any either join operation or leave operation. It also distributes the new group traffic key to all members of a group. Furthermore, it governs updating of keying material within members of a group when any changes happen within the group. The central controller does not have to rely on auxiliary entity to perform access control and key distribution. The following subsections give a brief review of the architecture of (Harney & Muckenhirn 1997a, 1997b), (Wong, et al., 1998), (Wallner, Harder & Agee, 1999), (Baugher, et al., 2005), (Y. Wang, Le & Srinivasan, 2007) and (W. Wang & Wang, 2008) Group Key Management Protocol (GKMP) The group key management protocol (GKMP) (Harney & Muckenhirn 1997a, 1997b) enables the creation and maintenance of a group key. In this approach, a key distributor center is assisted by the first member joining the group for creating a group key packet (GKP) including a group traffic encryption key (GTEK) and a group key encryption key (GKEK). When a new member is interested in joining the group, the key distributor center sends a copy of GKP to new member. When a rekey is needed, the group controller generates a new GKP and encrypts it with the current GKEK. As all members 10

24 know the GKEK, there is no solution for keeping the forward secrecy when a member leaves the group except to recreate an entirely new group without that member Logical Key Hierarchy (LKH) Other contributions (Wong, et al., 1998) and (Wallner, et al., 1999) proposed the use of a logical key hierarchy (LKH). In this approach, key_node and user_node construct a logical tree of keys with a root. Leaves of tree correspond to multicast group members so that each member of a specific multicast group is located as a leaf in the tree and holds a key associated with that one member. Each member maintains a copy of keys along path from user to root of tree. Key distributor center (KDC) in this scheme assigns a key encryption key (KEK) to key_node in tree. For example in figure 2.1, U1 U8 is associated with user_node and U1 holds K 1, K 123, K 1-8 keys. There is a server that is responsible to authenticate new users, distribute new keys to node and update remaining keys. It is actually controller of group and manages the user and key node. The existing keys in the tree are as follows Individual key: when a new user sends a join request to server, server authenticate new user. If user request is accepted it will be granted with a new key that is shared between user and server. Subgroup keys: Also referred to as internal key or key encrypting key when they are between leaf and root or used for encrypting other keys. Group key: Also referred to as root key. It s used to encrypt data and share between server and users. 11

25 In this scheme, upon each join or leave, new secure group is formed. Server has to update existing key_node and add or delete some key_nodes. It then securely sends new group and subgroup key with rekey message. This message can be sent via unicast or multicast communication. Figure 2.1: An example of user joining /leaving logical hierarchy tree (Wong, et al., 1998) When a new user is interested in joining a group, it is placed in leaf which is included in the tree. Placing new member in leaf of tree causes all KEKs in the key_nodes from the new user s leaf parent in the path to root of tree is compromised. In order to provide backward secrecy the aforementioned KEKs should be changed. Suppose U 9 in above figure is granted to join the group. Server creates a user_node U 9 and key_node K 9.Server finds an existing key_node same as K 78 (which is called joining point) in the upper key graph. To provide backward secrecy, this key is changed to K 789. Moreover the root key is changed from K 1-8 to K 1-9. U 1..U 6 need to new key K 1-9, while 12

26 the U 7 and U 8 need to new keys K 789 and K 1-9. These new keys will be sent to users via rekey message. When server receives a leaving request from user, it updates the key graph by deleting user_node and individual key from key graph. Server has to update keys along path from the leaving user to root in order to providing forward secrecy. After generating new keys, server has to securely distribute them to users. In our example, suppose the U 9 leaves the group, the key K 789 is changed to key K 78, consequently key K 1-9 is changed to key K 1-8. The new group key will be distributed to all members of group via unicast or multicast communication GKM-A This proposal (Baugher, et al., 2005) is an extension of GKMPA (see Section 2.3.1). GKM-A provides a common architecture for group security key management protocols in multicast security to support a variety of protocols. They used Security Association (SA), which is set of security parameters that two entities use in order to provide secure communication including cryptographic keys, digital certificates, and introduced notion of group security association (GSA). GSA should be established prior to group communication. The following protocols assist to provision of group key management in GSA: Registration Protocol: Each desired member including sender or receiver for joining to a specific group uses registration protocol to get authorized and authenticated access to group. The authorized and authenticated member receives sufficient information for initializing Data SA and Rekey SA from 13

27 Group Controller and Key Server (GCKS) through a secure unicast association. Rekey Protocol: Group membership changes, and key expiration result in being sent rekey information to group members by GCKS. Group controller and key server is a logical separate entity that performs member authentication and authorization according group policy. It is responsible to create keying material and send them to group members. The two types of keys which are generated by GCKS are as follows Key encryption key (KEK). It is a single key for encrypting rekey message. It also provides group authentication of rekey message and key integrity. Traffic encryption key (TEK). It is used for encrypting data between sender and receivers and providing data integrity Hybrid GKMF for Secure Wireless Multicast (Y. Wang, et al., 2007) have shown a hybrid group key management approach for wireless networks. This approach has a two-level structure formed by clusters. Group members within the cluster form a peer to peer network for rekeying purpose. The rekeying procedure is confined within the cluster to significantly improve the efficiency of key management in terms of communication costs. Based on a model of two-level distributed network architecture, the whole wireless environment has been divided to administrative area or cell which is controlled by a cell key server (CKS). All CKSs are responsible to conduct updating keying material in each cell independently. The group key server (GKS) is above CKSs and responsible for 14

28 initializing the group key, distributing key material to CKSs and update group key when join or leave taking place. Figure 2.2: Logical member structure Within each cell, the authorized members are categorized into several clusters to form a two-level logical structure. There are two kinds of cluster: leaders cluster and members cluster. Each members cluster has one leader which is responsible for distributing the rekeying material to the members cluster. The members form a two or three level hierarchical relationship network. Each user in the member cluster needs to establish several peer-to-peer relationships with other cluster members. There are two kinds of relationships: upstream connection and downstream connection. These relationships are applied to distribute the keying material. Each cluster has its own cluster key for the key distribution. When a new user wishes to join a group, it should send join request message to GKS. If authentication succeeds, GKS distributes new group key to all CKSs. User can join to either leader or member cluster. 15

29 In leave operation, if the leaving member doesn t have any downstream member, CKS informs upstream node of the leaving member to break down connection. CKS distributes new group key to all leaders. Otherwise, CKS should replace a member without any downstream with leaving member and setup new connection. CKS sends new relation information to this member Wang Scheme (W. Wang & Wang, 2008) proposed an approach to secure inter- and intra-group information sharing in an integrated Ad Hoc network. The approach enables individual nodes to inject and disseminate securely multicast data from various locations in network. He has developed a method to contain and maintain membership changes in network due to member movement in network. He adopted a secure key distribution method for providing securing multicast traffic among between groups. In this protocol, during a joining event, member sends a localized broadcast to locate a member already in the group. Propagation of request in area is controlled by time to live (TTL) value. When a node receives a joining request, it examines the eligibility of request. Requester can prove its eligibility by showing its knowledge about target group. If receiving node is a member and has connection to the multicast group, it verifies the requester. Eligible requester receives a unicast reply which contains information of multicast group. In leaving event, the connection in multicast communication will be broken. The upstream nodes were notified by leaving node. Its upstream node detects changes in the path and stop sending traffic along path. The disconnected nodes have to send localized 16

30 broadcast to locate new attaching point to multicast group. The end nodes detect this change; have to update their routing table. They divided network area into zones. Predetermined central position was selected in each zone. A member which is closet to central point will be as the proxy of group in this zone. It organizes multicast group member to form a single source multicast structure. Source sends traffic by unicast communication to close proxy in its zone. When proxy receive traffic, it multicast data to other member in multicast group within its zone and to other proxy in others zone. Secure group communication was provided with two key; traffic encryption key (TEK) and key encryption key (KEK). Traffic key protects multicast traffic and key encryption key supports secret refreshment. Each node in multicast group receives these key from group manager Summary In this part, we summarize and compare the properties of those protocols presented in Section 2.2 in quantitative way. The features of comparison in Table 2.1 are secrecy, size of message and required amount of storage. The secrecy feature identifies those protocols that provide backward and forward secrecy. The size of message is shown in join and leave operation. Storage requirement represent amount of storage which is need for maintenance of keys in group controller and member. The notations that are used in Table 2.1 are as follows: n: number of member : number of member in leader cluster 17

31 Note that number of member n includes the joining member during join operation, and n excludes the leaving member in leaving operation. Table 2.1: Comparison of centralized group key management approach Feature Secrecy Message Join Backward Forward Schemes Unicast Multicast Leave GKMP LKH log 1 log GKM-A n - n Hybrid GKMF log 1 (log + ½) Wang scheme log 2 log According to Table 2.1, all protocols are able to update traffic key during joining a new member to the group. Consequently, they can provide backward secrecy within group communication. Although most of protocols provide forward secrecy through the leave operation, GKMP achieves an exceptional result by providing no method for updating key when an existing member has left the group. It cannot thus make forward secrecy in leave operation. Group controller in GKMP protocol generates new group traffic through two unicast messages to new member in join operation. The group controller sends new traffic key to all group members via a multicast transmission. LKH must update the keys along path from the new member to the root. These keys are delivered by unicast message. The generated new group traffic key distribute to remaining members of group by multicast communication. Wang scheme is like to LKH in join operation except it must distribute a new polynomials key to members of subgroup in order to prevent new member from getting access to multicast traffic from other subgroups. 18

32 Table 2.1 considers the communication cost of joining member to leader cluster in Hybrid GKMF, which has worse amount in compare to joining member to member cluster. The number of unicast messages is equal with height of the leader tree or log. One multicast message delivers the group traffic key to members of new leader. GKMP does not have any mechanism for provision of forward secrecy upon leaving an existing member from the group. Therefore it does not generate any message during this event Decentralized Group Key Management In this approach, large group split into some subgroups. Each subgroup has its own controller. Distributing management responsibility of group to some controller minimizes the problem of concentrating work on single entity. In this approach, if each controller is failed, whole group would not be affected Iolus (Mittra, 1997) proposed Iolus, a general framework for scalable secure communication based on notion of secure distribution tree. The framework constitute of independence subgroups, which create a virtual multicast group in hierarchy scheme. The proposed framework has tried to solve two scalability problems; i. 1 affects n, that n is number of group members. This scalability problem occurs when an action of one member affects entire of group. For example, when a new member joins to group, new key should be generated and distributed to all group members and new user should be joined. 19

33 ii. 1 not equal n. The second scalability problem occurs when the protocol cannot deal with group as a whole but rather should consider each member demand individually. For example when a user leaves the group, the new key should be generated and sent to existing members in group. There is no efficient means to distribute the new key due to the leaving member is aware of old key. Thus in this situation, simple solution would be using unicast keys to distribute new key securely. Two entities involved in Iolus that manage and connect the various subgroups are: Group security controller (GSC): It s root of tree and manages top level subgroup entities. Group security intermediaries (GSIs or GSAs): They are actually top level entities of each subgroup and responsible to govern each subgroups. In order to start multicast, Iolus requires initiating group secure communication. Group secure communication identifies who can or cannot to join and what access to group. For this purpose, GSC gets help an access control list (ACL). After establishing GSC, members and GSIs can join to its subgroup. It s assumed GSIs and subgroup keys are established upon new member join to their subgroup. However GSIs can be concurrently started with initiating GSC. 20

34 Figure 2.3: An example of Iolus hierarchy An interested member for joining a multicast group sends its join request via unicast association to GSA. If the member s request is approved by GSA, a secret key (K GSP-MBR ) is generated by GSA and shared by new member. On the other hand, GSA should replace the current group key by the new group key for providing backward secrecy. New group key is distributed to members of group by multicast communication since it is protected under old group key. Leaving the groups occur under two conditions: i. Member wishes to leave subgroup voluntary. ii. GSA wants to expel a user. Either way, for providing forward secrecy, GSA creates a message containing n copies of new group key encrypted with each member s K GSP-MBR. GSA sends this key through the multicast communication to all remaining members Intra-Domain Group Key Management Protocol (Hardjono, et al., 2000) proposed a group key management for multicast security by applying domain definition. Domain is a single leaf region which is administrated and 21

35 controlled by body. In this scheme, each domain is divided into a number of administratively-scoped areas and all members reside within these areas. At the domain level, domain key distributor (DKD) entity is responsible for key management. It also takes on the role of Certification Authority. Area key distributor (AKD) entities govern keying material within area level. Figure 2.4: Intra-Domain Group Key Management Elements Communication between domain key distributor and area key distributors as well as area key distributor and members carry out via secure association. The data traffic flow is protected under group key M_Key, which is common between all members of a multicast group. Domain key distributor is responsible to initiate and distribute this key within all members of a group. Group key is protected during dissemination in the domain by some secret keys which are shared between DKD and AKD as well as AKDs and members. In this scheme, when a user joins a multicast group in order to provide backward secrecy the group key M-Key of that specific multicast group in the domain must be rekey-ed. A desired host for joining a multicast group sends an authentic join-request message to its area key distributer. AKD verifies the new member and notifies DKD of the 22

36 membership changes. The domain key distributor generates new group key and delivers it to new member by assisting of new member s AKD. The domain key distributor concurrently initiates a rekey in the domain. Rekeying results in all area key distributors and all existing members in the multicast group obtain new security information. In leaving case, when a host leaves the multicast group, it must be prevented from further accessing to future traffic. For this purpose, the multicast group key MKey and Area Group Key should be rekeyed. Leaving host sends an authentic leave-request message from multicast group to its AKD. Alternatively If DKD wants to expel a member from multicast group, it notifies AKD of host. DKD notifies authentically other AKDs of the membership change. The domain key distributor conducts rekey protocol. All area key distributors and remainder members in the multicast group obtaining new group key. AKDs deliver the new group key securely by one to one secure channel to existing members Kostas Scheme in Mobile Networks (Kostas, Kiwior, Rajappan & Dalal, 2003) proposed a hierarchy of nodes in two tier hierarchical secure multicast protocol based on Hardjono scheme. Their proposed scheme divides domain into administratively scope areas. Domain key distributor (DKD) and multiple area key distributors (AKDs) are responsible for distributing group traffic key. DKD generates group key and sends it to AKDs via multicast communication. AKDs receive group key and distribute it to group members periodically. New user can decrypt data traffic after receiving new traffic key and leaving node is prevented to access to data traffic after distributing new traffic key. 23

37 Figure 2.5: An example of Kostas scheme Some existing cluster techniques assist to separate participating nodes in this system into some clusters. In each cluster, nodes divide in two groups. The first group involves some nodes which can be are key distributor and second group involve the nodes which select the AKD from the first group. The selection of different AKDs is accomplished using an asynchronous leader election algorithm. Additionally the leader may be selected periodically in order to prevent denial of service attack Hierarchy based Key Management for SGC in Mobile ad hoc Networks A key management with 2 layers structure is proposed to achieve secure communication in MANET (N. C. Wang & Fang, 2007). The layer one contains all nodes of subgroup. A node with highest weight value in this layer is selected as layer 1 head (L1-Head). Other nodes are classified in layer two subgroups based on their location information that have been already registered in the head of layer one L1-Head. In each L2 subgroup, one node with highest weight values is selected as subgroup head L2-Head. 24

38 Layer 2 head L2-Head manages its layer two subgroup and communicates with layer 1 head L1-Head. Layer 1 head L1-Head generates L1subgroupKey (L1GK) key after gathering all nodes information in its subgroup. L1GK is shared by layer 2 heads. On the other hand, layer 2 head generates L2subgroupKey (L2GK by calculating known L1GK and sends it to its subgroup nodes. Figure 2.6: An example of nodes placement In join operation, new user sends a join request message to its neighboring nodes. Upon receiving request by neighboring nodes, they send it to L2 subgroup head. If the request was accepted, L2 subgroup head sends reply message to new node and then it s allowed to join the group. L2 subgroup head updates L2Gk and sends it to its all subgroup nodes. In Leave operation, an ordinary node sends leave message to L2 head. After receiving the leave message, L2 Head sends a reply message to node and generates a new L2Gk. L2GK is sent to all of subgroup nodes. 25

39 Wang and Atwood Scheme They proposed a scalable secure multicast system which has a hierarchical structure and allows keys update to happen in subgroup(mukherjee & Atwood, 2004) (Zhao Yu & Atwood, 2007). They used hierarchical system for providing secure group communication using proxy encryption (Blaze & Strauss, 1998). In this scheme, receivers are organized into some subgroups. Each subgroup is managed by a group controller. One of the group controllers is chosen manually or dynamically as group manager. The group manager is equipped by access list and list of trusted nodes in the network. It is responsible to generates encryption and decryption keys. It also generates a session key encryption to secure any communication between itself and the group controllers in various part of network. To join a secure multicast group, participant sends join request to closest group controller using a secure channel. If the user request is accepted, group controller shares a session key encryption with group member to protect future communication between itself and member. Group controller then generates decryption key and sends it to new member. New decryption key is distributed to other members of multicast group by multicast communication which is protected under old proxy decryption key. When a leave message is received by group controller, it initiates a new proxy decryption key and distributes it to remainder of participants in the group. The new key is sent by unicast to each member whereas is protected under shared session key between group controller and each member. 26

40 GKMF-WMoE (Mat Kiah, 2007) adopted general cellular architecture based on notion of domain(s) and areas as the basic framework. The main entities in this protocol are domain key manager (DKM), area key manager (AKM) and group members. DKM is responsible for generating, distributing, storing and deleting all keys and playing the role of group controller as well. AKM is one per area and it s under control of domain. It is responsible for key management within area. Group members are sender and receiver. Each domain can contain some areas. The areas in each domain can separate from each other or have common area together. Members locate in areas. The reliable and trustworthy relation between domain and areas was supposed. Different keys which are used in this protocol are as follows: Individual key (or long term key): a unique key to every host which are generated and shared by key manager prior group creation. Group key(s): are shared between all members of group. They are generated by key manager. They encrypt data communication between sender and receiver. Auxiliary key: are used to distribute group key via multicast instead of unicast. It contains Domain_Area key, Area_Member key and Area key. Join to group: each member are interested to join a group, sends a request to group manager. If it s granted permission to join the group, then relevant key will be delivered to new member. Provision of backward secrecy requires being changed cryptographic keys. 27

41 Existing member leave: member notifies the group manager with leaving message. Group Key will be needed to change if forward secrecy is required. Re-keying procedure may occur due to group membership changes, periodic re-keying, expiration of cryptographic keys and compromised keys Summary Table 2.2 summarizes and compares properties of schemes those presented in Section 2.3. The following attribute are used to evaluate the efficiency of decentralized schemes: Key Independence: shows that disclosure of key must not compromise past keys. Decentralized controller: A centralized manager should not manage subgroup. The centralized manager raise issues same as central system. Local rekey: membership changes in group should be treated locally which means rekey of subgroup should not affect whole group. Rekey membership: related to forward and backward secrecy. Mobility of member: shows that protocol provide mechanism to avoid extra rekeying in mobile environment where member can move from one area to another one. Table 2.2: Comparison of decentralized group key management Feature Key Decentralize Local Secrecy Scheme Indep. Management KDC Rekey Backward Forward Iolus Y Y Y Y Y Y IGKMP Y Y N N Y Y Kostas Y Y N N Y Y Wang Y Y N N Y Y Wang&Atwood Y Y Y N Y Y GKMF-WMoE Y Y N N Y Y 28

42 Table 2.2 shows all discussed schemes generate new key independence of old keys. This means that the new traffic key is not extracted from old key. If any old key is compromised the future keys are disclosed. Although Kostas scheme provides key independence, it updates key periodically. A timed rekey allows the departure member to access the group communication before distribution of new key between members of the group. In all schemes, domain is divided to number of areas, which have their own controller. Although these subgroup controllers manage their jurisdiction independence from each other, except Iolus they rely on a main entity to receive traffic key during rekeying operation. Iolus confines the rekeying protocol to each subgroup, where a join or leave operation has occurred. It avoids changing key between all members of a group when any changes occur in a subgroup. The new traffic key is generated by subgroup manager and distributed between members, which are placed at that specific subgroup. This solution requires some entities to translate message transiting from one subgroup to another subgroup due to different traffic key being used by those subgroups. All schemes are able to provide backward and forward secrecy. Upon joining a new member to group communication, new traffic key is generated by group controller and distribute to all members of group. It causes the new member cannot access to previous information. They also generate a new traffic key when an existing member leaves group. The departure member would be prevented to access future data. 29

43 2.5. Distributed Group Key Management The distributed key management approach is characterized by having no group controller. The group key can be either generated in a contributory fashion, where all members contribute their own share to computation of the group key, or generated by one member. In the latter case, although it is fault-tolerant, it may not be safe to leave any member to generate new keys since key generation requires secure mechanisms, such as random number generators, that may not be available to all members. Moreover, in most contributory protocols (apart from tree-based approaches), processing time and communication requirements increase linearly in term of the number of members. Additionally, contributory protocols require each user to be aware of the group membership list to make sure that the protocols are robust ING The earliest attempt for extending two parties Diffie Hellman (DH) key exchange to a group has been done by (Ingemarsson, Tang & Wong, 1982), and is called ING. This protocol consists of (n-1) round and group members perform every round in synchronization. The member must be arranged in logical ring. During the first round, each member m i computes g x i and forwards it to its next neighbor or member M i+1. Similar to the two party DH, g is generator and p is large prime number which are known by all members. x i is secret component that is selected by each member M i. In next rounds, each members raises the previously- received intermediate key value to the power of its own exponent and forwards result to its logical neighbor. After (n-1) rounds, all participants possess a same key K n. 30

44 GDH 1 GDH1 (Michael Steiner, Tsudik & Waidner, 1996) consists of two stages: upflow and downflow. The purpose of upflow stage is to collect contribution from all group members. In round i, member M i receives a collection of intermediate value from M i-1. Member M i raises the last value in received collection, i.e. g, to the power of its secret component x i and computes g. After that member M i appends new intermediate value to incoming flow and forwards it to next member M i+1. The intended group key K n will be produced when the highest numbered group member compute g. In downflow stage, member M i receives an ordered list of intermediate values from member M i+1. It raises all values to the power of its secret component x i. The last value in the set of computed intermediate values is K n. Other values are sent to the member M i GDH2 In contrast with GDH1, GDH2 reduces the number of round by executing protocol in n rounds (Michael Steiner, et al., 1996) (Michael Steiner, Waidner & Tsudik, 1998). The protocol collects contribution from group members in upflow stage. In this stage, each member M i receives a sequence of intermediate values and a cardinal value from M i-1. The M i raises these values to its secret component x i and sends them to M i+1. In this protocol, the highest indexed group member M n plays the role of group controller. It receives the some values and raises them to its secret component. It keeps a cardinal value as an actual group key and broadcasts other intermediate values to the 31

45 entire group. Each member M i recognizes its intermediate value from the receiving values and powers it by its x i thus computing the final group key. In this protocol, when a new member is interested in joining to the group, the group controller M n generates a new secret component x n and creates a new upflow message by raising the contents of the previously received upflow message. It then sends the message to new member. The role of group controller is thus passed to new member of group. In leave event, the member M n generates a new secret component x n. Now, the M n compute a new set of n-2 sub keys (exclude sub key of leaving member M p and M n ) and broadcast them to all members of group. Since, g is missing from the set of broadcast sub keys, the leaving member m p is unable to compute new group key GDH3 Each member In GDH1 and GDH2 has to perform (i+1) exponentiation which is computationally inefficient. In order to minimize the amount of computation performed by each group member especially in large environment, GDH3 has been proposed (Michael Steiner, et al., 1996). GDH3 consist of four stages. In first stage, it collect the contribution from members M 1,, M n-1 similar to GDH1. In the second stage, M n-1 broadcasts g to all members of group. In next stage, each member factor out its exponent x i from the receive value and send the result to M n. In the final stage, M n powers the received values from group members with its exponent x n and broadcasts the results to rest of members in the group. After receiving these values, each member can compute the group key. 32

46 Member M n has to save the content of original broadcast message from M n+1 and response messages from other members (during stage2 and 3). In join event, member M n generates a new secret exponent x n and computes a new sub keys which will be forward to new member. New member M n+1 computes a new group key K n+1. It also raises received sub keys to its own secret exponent x n+1 and broadcasts them to all members in the group. Now, the group members can perform the group key K n+1. Generation key in leave event is similar to GDH Octopus Protocol This protocol has been proposed by (Becker & Wille, 1998). In this protocol, each large group split into 4 subgroups. Each subgroup performs its intermediary DH value (I subgroup = g / ) and then subgroups exchange their intermediary DH value with each other. All group members are then able to calculate the group key. The contribution from each subgroup members is collected by leader of each subgroup in order to perform intermediary DH value. For example, the M a, M b, M c and M d are in turn the leader of subgroup A, B, C and D. The M a and M b exchange their intermediary DH value (I a and I b ) using DH in order to calculating g. On the other hand, M c and M d exchange do the same and generate g. Then M a and M c exchange the new values g and g and generate g. The M b and M d do the similar process. Now, the aforementioned leader subgroups send the provided key to their respective subgroup members. The members in each group are capable to calculate group key. 33

47 STR (Kim, Perrig & Tsudik, 2001) and (Kim, Perrig & Tsudik, 2004a) proposed STR protocol to extend Steer protocol to deal with dynamic group and network failure. They used a logical key hierarchy to minimize the number of key that held by group members. The group members use two party Diffie Hellman key exchange scheme to generate group key. STR key tree has two type of node, Leaf and internal. Each member group is associated with a leaf node. An internal node IN <i> always has two nodes, leaf node and another internal node IN <i-1>. The internal node IN <1> is exception. It s also a leaf node. Each leaf node LN <i> has a session secret key x i which is kept secret by member M i. The blinded (public) key bx i of each leaf node calculate as g mod p. Every internal node has secret key K <i> and blinded key bk <i> = g mod p. The internal node IN <i> computes its secret key K i (i > 1) by using of Diffie Hellman key agreement of its two children. The K i (i > 1) is generated recursively as follow: K i = mod p = mod p = g mod p if i> 1. For example in Figure 2.7, K 1 = x 1, K 2 = g mod p, K 3 = g mod p and K 3 = g mod p. 34

48 IN <4> k 4= mod p bk 4= g mod p IN <3> k 3= mod p LN <4> bk 3= g mod p x 4/bx 4 M 4 IN <2> k 2= mod p bk 2= g mod p LN <3> x 3/bx 3 M 3 LN <1> IN <1> x 1/k 1 x 2/bx 2 LN <2> M 1 M 2 Figure 2.7: Example of STR key tree In join event, the new user broadcast his join request message that contains its own blinded key bk n+1. The group s sponsor node M n, top most node in tree, concurrently computes a blinded version of the current group key (bk n ) and sends the current tree BT <n> to new member with all blinded keys and blinded session random. The pre-existing members increase the number of node from n to n + 1. They also create a new tree so that the left node is prior tree and the right node is new member. Now, the current members can compute the group key when they receive the new member s blinded (public) key. If member M d decides to leave the group, the other group members upon hearing the leave event begin to update its key tree by deleting the node LN <d> corresponding to leaving node and its parent node IN <d>. The nodes above the leaving member M d are renumbered and the sibling of M d would be replaced by M d s parent. The sponsor M s is a leaf node directly below the M d (if d > 1). Otherwise the sponsor is M 2. The sponsor selects a new secret session random and computes all key up to the root and broadcast to BT <s>. Now, all members can regenerate the new group key. 35

49 TGDH Tree based Group Diffie Hellman (TGDH) key agreement (Kim, Perrig & Tsudik, 2000) (Kim, Perrig & Tsudik, 2004b) extends key tree by using two party Diffie Hellman key exchange scheme in order to provide a fully distributed contributory key agreement. In TGDH, all members maintain a virtual binary tree. The nodes in tree are denoted by (L, V), where 0 V 2 1 since each level L have at most 2 nodes. V indicates the sequential index of node at level L in tree. Each parent node <L, V> has two children, which are labeled as <L+1, 2V> and <L+1, 2V+1>, respectively. The root of tree indicates by label <0, 0> as it s located at level 0. In this protocol, all group members are hosted on leaf nodes respectively. Each node in tree except root is associated to a secret key K <L, V>, which is a Diffie Hellman private key, and a blinded (public) key BK <L, V> = f(k <L, V> ), where f(x) = g mod p. The parent node computes its key K <L, V> by using Diffie Hellman keys of its two children, i.e. K <L, V> = f(k <L+1, 2V> K <L+1, 2V+1> ). It s implication that secret key of each node can be computed from secret key of one of its two children and blinded key of other child by using the Diffie Hellman key exchange protocol. All blinded key are broadcasted to all members of group. Each member M i at <L, V> knows the secret key K <L, V> along path from itself to the root of tree. K <0,0> at the root node is group secret key which is shared by all members in the group. 36

50 <4, 0> K <1, 0> = g,, = g g g g mod p <3, 0> K <1, 0> = g,, = g g mod p BK <1, 0> = g, mod p <3, 1> <2, 0> K <2, 0> = g,, = g mod p <2, 1> BK <2,1> = g mod p <2, 2> <2, 3> M 3 M 4 <3, 0> K <3,0> =x 1, B 1 = g <3, 1> K <3,1> =x 2, B 2 = g M 1 M 2 Figure 2.8: Notation of TGDH In Figure 2.8 a key tree with four members is illustrated. Member M 2 or <3, 0> can calculate K <2, 0>, K <1, 0> and K <0, 0> by using BK <3, 0>, BK <2, 1> and BK <1, 1> and K <3, 1>. The key K <3, 1> is M 2 s private share key x 2 and its public share key is B 2 = g. Member M 2 can compute K <2, 0> = g,, = g mod p after receiving public share B 1 = g mod p. Next, M 2 computes and broadcasts BK <2, 0> = g g mod p. In next step, M 2 computes K <1, 0> = g,, = g g mod p after receiving BK <2,1> = g mod p from M 3. After that M 2 computes and broadcast BK <1, 0> = g, mod p, it finally computes group key K <0, 0> after receiving BK <1, 1>. When a new user is interested in joining to group, it broadcasts its request message that contains its blinded key. All pre-existing members receive this request and determine the join point in tree and its sponsor. The sponsor is rightmost leaf in the subtree rooted at 37

51 the insertion node. Each member updates the key by adding a new node for new member, new intermediate node and removing all secret key and blinded key from sponsor s leaf to root. Then, sponsor node computes all secret key and blinded key along path from its leaf node to the root. Now, sponsor node broadcast all new blinded key to all members. All members upon receiving new blinded key would be able to generate the new root key. If one of existing member M i decides to leave the group, each member updates its key tree by deleting key corresponding to M i. the former sibling of m i replace by M i s parent. The sponsor generate new secret key and computes all key and blinded key from itself to the root. After generating key, sponsor broadcasts new blinded keys BK to all members. It allows to all members to compute the new group key. Sponsor at this case is the shallowest rightmost leaf of the subtree rooted at M i s sibling node CRTDH (Balachandran, Ramamurthy, Xukai & Vinodchandran, 2005) presented a key agreement scheme for secure group communication over MANETs, referred to as the Chinese Remainder Theorem and Diffie-Hellman (CRDTH) scheme, which aims to solve two problematic issues in ad hoc environments: Key serialization and absence of a central authority in MANETs. In this scheme, all members exchange their contributed key share by using the Diffie- Hellman key exchange mechanism, and then the members independently but mutually generate the group key based on the Chinese remainder theorem (CRT). The below steps will conduct in order to generate group key: 38

52 Each node Selects the Diffie-Hellman (DH) private share x i and computes its public key ( = g mod p), and broadcast its public key to all nodes. Next, Each node which receives others nodes public key, computes secret shared key with the sender of public key. ( = mod p where j = 1,..., i 1, i + 1,..., n and j i). The least common multiple (LCM) of all the secret shared keys is found by each node. After that the node selects random key K i, such that K i < min(, j), arbitrary D such that D K i and D p such that gcd(d p, lcm i ) = 1. Now, CRT is solved in each node (crt i K i mod lcm i and crt i D mod D p ). Each member sends its CRT to other members. Each member calculates other members random key by using received CRT value. (K j = crt j mod M i for all j i and compute the group key). When each member calculate other members random key, it XORs these keys and find Group Key (GK = K 1 K 2... K n ). When a new user are interested in joining to group, one of closest member transmit hash value of group key H(GK) and all group members Diffie Hellman public key to new member. New member computes DH and CRT and broadcast new CRT to all group members. The pre-existing users can calculate the received CRT and extract the new member key K. They XOR new K with current GK and provide new Group Key. In leave event from group, one of the remaining members selects a new key K and compute new CRT. The new CRT will be broadcast to other members. Upon receiving new CRT, The new key k will be extracted from new CRT by other members. New GK will be obtained by conducting XOR operation on existing GK with new key K. Although it seems CRTDH is nice idea, it contains some problems that make it impractical in term of efficiency and security. (Magliveras, Wandi & Xukai, 2008) point 39

53 out three such problem: low efficiency, possibly a small key, and possessing the same least common multiple (LCM) that is appeared in computation of CRT. In order to sort these problem out, they have enhanced calculation of Diffie-Hellman key and computation of CRT. They skipped using of least common multiple in computation of CRT due to weaknesses that was appeared of using LCM Summary Summarization and comparison properties of those distributed key management protocol presented in Section 2.4 are shown in Table 2.3. The criteria which compare the characteristics of protocol contain number of round, number of exchange message between members including unicast and multicast during group operation. Table 2.3: Comparison of distributed group key management schemes Feature Message No round Scheme Unicast Broadcast Total ING n-1 n(n-1) 0 n(n-1) GDH1 2(n-1) 2(n-1) 0 2(n-1) GDH2 n n-1 1 n GDH3 n+1 2n-3 2 2n-1 Octopus 2(n-4)/ n n - 4 STR n-1 0 2(n-1) 2(n-1) TGDH h 0 2(n-1) 2(n-1) CRTDH 2 2n-2 2 2n We look at the number of round as a time unit that shows the number of steps taken in an operation. The number of unicast message is sum of the messages every member sends to another single member in group. The number of broadcast message is sum of all messages which is sent by a member to other members in a group for operation. This 40

54 greatly affects the communication cost in compare with unicast. The total number of message is sum of all unicast and broadcast messages which are sent in group during operation. This number is used to determine the total communication time. From Table 2.3, the number of rounds of all protocols except CRTDH in initial operation is relative to number of members n in a group. GDH1 in compare with other protocols has the biggest number of rounds with 2n-2. This means that GDH1 needs to take 2n-2 steps and consume more time to perform group key. The CRTDH has a fixed round number, which means that the number of interaction between members is independent from the number of group members. In term of number of exchange messages, ING with n-1 messages in each round is the most expensive protocol. However, STR and TGDH exploit 2(n-1) broadcast messages. As every broadcast message is sent to all members of group, It makes sense that each broadcast message will consume more bandwidth than a given unicast message Design Approaches Analysis As introduced in Section 2.2, group key management schemes can be classified by three design approaches. These approaches are well known as centralized, decentralized and distributed or contributory schemes. The discrimination of these approaches is based on main entities which are responsible for initiating key materials: i. Centralized schemes In this approach, a central entity is responsible for governing and managing key material in a group. In other word, it is a main reference for security 41

55 information for all group members (see Section 2.3). Although, adopting centralized approach have some advantages such as They are managed easily because the provision of trust is focused on one entity. Some transmission overheads are decreased as member of group need to authenticate the main entity only one time However, they also suffer from some weaknesses as follows: A single point of failure may occur in the system. If any failure happens to them, whole of system can be down. In a large size of group members, the amount of message transmission from main entity to members or vice versa can be dramatically increased at a same time. This volume of messages can make bottleneck in the system. A central entity has to hold all key materials, so it requires large capacity of storage. ii. Distributed schemes In this approach, the central entity is not required. All members in a group contribute for managing the keying materials in group, including generation of cryptography key. Although the advantage of this scheme is distributing the responsibility of key management to all members that make it more flexible, it suffers from some drawbacks as follows: Distribution of management task across large multicast groups is complicated. 42

56 The processing time and communication requirement can be increased in term of the number of members. iii. Decentralized approach This approach can be a combination of former approaches (centralized and distributed). A large group is split to some small subgroups so that they make some hierarchical levels. In each level one or more entities are responsible for management of entities in its level. These entities are dependent to their up level entity. In this scheme more entities are allowed to fail before the whole group is affected. This approach shares the advantage and disadvantage that are expressed in centralized and distributed schemes. With consideration of these reasons, this scheme is more attractive for employing in this work. Table 2.4: Comparison of various group key management design approaches Type of scheme Advantage Disadvantage Centralized Distributed Decentralized Easy to manage. Save some transmission overhead by decreasing the number of authentication. Eliminate the need for a central entity. Uniform distribution of the work load for key management across group members. Minimize the problem of concentrating on a single entity. Dependency to a central entity leaves a single point of failure. Emerging a bottleneck in large multicast group because of huge number of transmission messages at the same time. Difficulty for distributing management task across large group. Increasing the processing time and communication requirement with growing number of members. Significant communication cost must be incurred to establish a pair wise secure channel with all members. 43

57 Table 2.4 summarizes advantages and withdraws of investigated approaches. According to Table 2.4, a decentralized approach makes a compromise between discussed approaches. It also alleviates the weaknesses of two other approaches. Furthermore, this approach allows establishing a scalable secure group communication (Mittra, 1997). On the other hand, some group key management scheme in this approach such as (Mat Kiah, 2007) and (Hardjono, et al., 2000), can enable group controllers to adopt other key management schemes, which are classified in centralized and distributed approaches, for governing keying materials (DeCleene, et al., 2001). Thus, this research employs decentralized approach for implementing group key management Chapter Summary A number of existing group key management schemes has been looked in this section. The main components in each scheme were specified. The key management mechanism during join and leave operations have been described. The discussed schemes have been classified in three design approaches. A quantitative comparison at the end of each design approach shows the advantages and withdraws of schemes. Next chapter gives a general model for group key management scheme which is proper for wireless environment. 44

58 Chapter 3. Research Methodology Research methodology is a set of procedure used for carrying out a research. In other word, it is a process that defines a set of activities, methods, practices and tools which are employed for system development. Background Study System Analysis System Design System Implementation System Testing Figure 3.1: Research methodology flow This section defines several processes which are used and incorporated for carryin 45

59 This section defines several processes which are used and incorporated for carrying out this research to achieve an efficient group key management scheme in wireless environment. The processes involved in the research methodology include study, analysis, design, implementation and testing activities. Figure 3.1 illustrates flow of research methodology in this work Background Study Data gathering has been carried out by collection information from various sources such as reference books, journals, articles, and Internet. Most of useful and relevant information are obtained from online databases, which are accessible via web site of university library, and other resources such as Science Direct Institute of Electrical and Electronic Engineers (IEEE) Association for computing machinery (ACM) Springer Link Online reference thesis and dissertation of computer science and software engineering from other universities. Online forums that provide an interactive environment for scientific discussion. This step helps us to explore the existing proposal for key management of group based applications. This exploration allows us to understand what external knowledge factors have not been investigated as well as how the existing solution can be exploited in this work. These resources assist to accomplish the project. For this purpose, the 46

60 necessary information for determining definition and requirements of project are extracted from these resources. The existing group key management schemes are thus reviewed and classified in three subjects centralized, decentralized and distributed. A qualitative comparison helps to achieve the advantages and withdraws of each class System Analysis Background study provides a better insight to the different design approaches of group key management scheme. Each design approach strengthens with some advantages and suffers from some withdraws. The appropriate approach for designing a group key management scheme in wireless environment is derived from trade off these advantages and disadvantages. In this stage, the main entities and protocols contributed in the proposed group key management scheme are identified based on selected design approach. The placements of entities as well as their relations are shown for provision of overall framework. Moreover, the roles, functionalities as well as importance of these entities and protocols are explained in order to specify the reason of their presence in the scheme. It is required to specify system functionalities for achieving the aim of project. One convenience way for determining functional requirements of a system is Use Case diagram, which is one of the object oriented modeling notation in Unified Modeling Language (UML). Use case models are employed in analysis phase to identify system functionalities. This model also serves other development work as a foundation. A use case model is a diagram that shows what the proposed software system to do. It consist of 47

61 a series action that a user must initiate with system to carry out some useful works to achieve his goal. The use cases are developed based on determined general characteristics of group key management scheme, the roles of the scheme s actors and system processes. Actors are defined based on different types of roles which will be played by different users or systems. An instance of actor can be participants which are desired to join or leave a secure group communication System Design In system design functions and operation are described in details, including business rules, process diagrams and other documentation. The output of this stage will describe a new system including different modules and subsystems. Design stage takes the system requirement identified in system analysis as its initial input. For each requirement, a set of one or more design elements are produced. The design elements describe the desired features of software in details. The elements generally include some functional hierarchy diagrams, business progress diagrams as well as entity relationship diagrams. These design elements assist software programmer to develop system without need to additional input. In this phase, design of group key management scheme is carried out using results extracted from analysis phase. The functional specifications of system including detailed features and operation definitions are described in details. Some set of interaction sequence diagrams are used to model the behavior and interaction of components involved in the group key management system. An interaction defines the messages 48

62 passing between groups of objects that work together to achieve a particular functionality. A sequence diagram models a behavior of a group of objects that work together to achieve a user goal. Sequence diagram helps to identify a set of collaborating objects involved in a scenario of an operation. This diagram has two dimensions, vertical and horizontal. The vertical dimension represents the passage of time, whereas the horizontal dimension shows objects involved in the interaction. The objects are placed at the top of diagram and messages are passed between them. Different operations in the group key management scheme including join operation, leave operation as well as updating keying material operation are modeled by interaction diagram. These diagrams show the flow of messages between main entities that provide backward and forward secrecy in a secure group communication. The entire design and data model are documented so that it could be used in implementation phase System Implementation The results of system design are converted to executable functionalities during implementation stage. Java platforms enterprise edition 6 is used as a main programming language for development of scheme. Along with this, NetBeans IDE 6.7 with having an integrated development environment is employed as a convenience environment for implementing system as it simplify the process of coding and debugging in Java. Identification of required classes and modules in the system is first step prior to commencement of coding. Subsequently, each class and module is coded by Java. The 49

63 written lines should be verified to ensure of their correctness and validation. At the end, each written part is compared against earlier design to confirm it is going on accordingly System Testing All processes and applications are put together to construct the main system after testing each process. The final system must be checked against user s requirement for ensuring achievement system goals. If any deviation is recognized, system should be revised. This work expects to deploy an efficient group key management scheme. This scheme provides a secure communication between members of a group. The system should be able to generate new group traffic key and send it securely to a new member during any join operation. It should also disseminate new generated group traffic key to remainder of group members after any join or leave operation. System testing is conducted to show overall system is capable to carry out the desired expectation. Different operation including join, leave and key updating are performed to present the functionalities of system. The implemented system is run on actual network environment to evaluate its performance. For this purpose, a combination of wired and wireless network is established. The wireless network includes number of access point and wireless members. The wireless access points are attached to wired network, where the group controllers communicate controlling message through it. The different aspects of group key management scheme are tested in this environment by sending different requests from wireless member to group controllers. 50

64 3.6. Chapter Summary In this chapter, the methodology of research including approaches and processes were described in order to specify required guidelines for deployment of a group key management scheme. Next chapter looks at the provision of general key management scheme for group communication in wireless environment. 51

65 Chapter 4. System Analysis In this chapter, the main components of decentralized scheme are presented for providing a better insight in order to specify system requirements and functions, which are depicted in use case diagrams Main Components of Decentralized Approach Regarding to (Mat Kiah, 2007) and (Hardjono, et al., 2000) schemes, the main elements of decentralized group key management scheme as a desired approach for this work are identified in the following subsections Main Entities The main entities are identified in this architecture as follows i. Group Controller (GC): They are indeed some servers. They are responsible to govern all group processes. In particular, they manage cryptographic keys which are required for secure group communication, including generation, distribution of such keys between group members. ii. Host: Host or group members are lower level entities which engage in the multicast communication. Each group communication involves at least one sender of data and one (or more) receiver(s) of data. 52

66 For a better perception, Figure 4.1 depicts a basic model of group key management with a central entity. As shown in Figure 4.1, a key server is responsible for managing the group processes in order to provide a secure group communication between group members. Both members need to set up security parameters prior to multicast communication. They use secure association (SA) management as shown with doubled head arrow in Figure 4.1, to collect security parameters from key server. The dotted arrows are employed for subsequent communication from key server to members such as key update which are appeared during the multicast communication. Group Controller Sender Receiver Domain and Area(s) Figure 4.1: An example of basic model for group key management In order to have an easier key management among the group members, they are placed in different levels. It seems this model is more appropriate for wireless environment as the entities can move from one place to another place. The different levels are as follows: 53

67 Domain: Logically, it can be assumed either as a large system which covers group of subsystems or a geographical area which consist of smaller areas. Area: has similar definition to domain but it is located in smaller scale in compare with domain. It can be one of subsystem or subarea in the domain. A university and its faculties can be an instance of domain and its areas. The university covers a geographical area which is divided to smaller areas such as its faculties. Figure 3.2 illustrates an example of a domain and its areas. Domain Area Area Area Placement of Entities Figure 4.2: An example of domain and areas The identified entities in Section should be placed in domain and areas which are explain in Section The domain level usually has a managing entity which also referred as Domain entity. Area composes a managing entity and some members of group. Group members can be located in each area in the domain. 54

68 Type of Keys The required keys for securing communication between entities in this scheme are listed below. They can be symmetric or asymmetric cryptographic keys or combination of both of them. i. Traffic key. This key is primarily used for protecting actual data traffic flow between group members. It is unique and shared between all members of group. ii. Domain keys. These keys are shared between key managers in a domain. They are used for distributing traffic key within members of a domain. iii. Area keys. They are shared between an area manager and group members who are residing at that particular area. These keys are employed for disseminating traffic key within an area Main Protocols In this section, required protocols for providing a secure communication among wireless members in a group are investigated Protocol for creating a new group This protocol manages the creation of new multicast groups. This protocol is run by request of first member who is desired to establish a new multicast group. This protocol carries out the initial registration of new member to multicast group. The initial distribution of new cryptographic keys is done during the execution of this protocol. 55

69 Protocol for joining a group This protocol governs new joins of group members to multicast communication. It also contains distribution of new cryptographic key to new members in order to enable them to communicate with multicast group. In this protocol, new members must be prevented from accessing to previous data traffic or old group keys. So, all cryptographic keys are associated with that particular multicast group need to be rekeyed. The all members of that specific group would have new keys after conducting rekey Protocol for leaving from a group This protocol manages existing member leaving from multicast group. It unregisters the membership of leaving member from the multicast group. Departure members can be two types, voluntary and involuntary. Like the protocol for joining to a multicast group, it is necessary that a member leaving is prevented to access to future data traffic or new cryptographic keys within a multicast group. The remainder members in a multicast group after leaving occurrence need to be rekeyed in order to receive new cryptographic keys Protocol for rekeying within a group This protocol governs the rekeying occurrence which appears due to group membership changes, periodic rekeying, expiration of cryptographic keys and compromised keys. In wireless mobile environment, the member movement from one area to another one result in rekeying. Each of these processes causes all group members 56

70 gain new cryptographic keys which are required for secure group communication. The rekeying protocol can be run in two levels, domain and area. At domain level, it s normally managed by domain manager. It is usually initiated upon new member joins or existing member leaves a group in order to provide backward and forward secrecy. The domain entity has to generate the traffic key and disseminate it to all members in a domain. At area level, it s governed by area manager. The area entity initiates the rekeying of its area by generating a new area key and sending to all residing group members in its area Proposed Scenario Description This scenario depicts two members who are located within different areas in a domain. These members are interested in joining to a multicast group which is created by first member. The join requests are sent to group managers in the domain by aforementioned members in distinctive times. They have to receive cryptographic keys prior commencement of communication with multicast group. The protocols identified in Section assist members for establishment a secure group communication between them. In order to have a better perception, Figure 4.3 illustrates scenario. As shown in Figure 4.3, domain Z is divided to two areas, area a and area b. The domain governing entity in domain Z is a key server which is labeled DKM. It is responsible to govern cryptographic keying materials throughout the domain. It is also known as a main security reference in the domain Z. Similarly, each area includes an area key manager 57

71 labeled AKM. The AKMa, AKMb are respectively key manager server of area a, area b. The members M 1 and M 2 are placed in turn within area a, area b as identified in Section The group managers in domain and areas are assumed to be static and predetermined. They also trust to each other. A unique cryptographic key is shared between DKM and each area key manager in area a and b. These keys will be used for protecting communication between DKM and AKMs. The members M 1 and M 2 have similarly a secret key shared with their area key manager respectively AKMa and AKMb. The member obtains this key during first registration to its area key manager. A newly joined member and a leaving member should be prevented to access in turn previous and forward data traffic flow. This scenario contains three parts; creation of multicast group by member M 1, member M 2 joining to multicast group and finally member M 1 leaving the multicast group. All parts are described as follows: Creation of new multicast group by member M 1 Member M 1 sends its join request which is identified the desired multicast group identity, to the area key manager AKMa. The area key manager of area a sends the join request to domain governing entity DKM. Upon receiving join request by DKM, it initiates traffic key and send it back to AKMa. The area key manager of area a forwards traffic key to member M 1. 58

72 Figure 4.3: new member send request message Figure 4.4: DKM grants permission to new member Member M 2 joins to existing multicast group After member M 1 joining to multicast group, member M 2 gets interested in joining to multicast group. The join protocol identified in Section assists member M 2 for joining to existing multicast group. Member M 2 sends its join request to area key manager AKMb which is placed in its area. AKMb sends the join request to domain key manager DKM. The new traffic key is 59

73 generated by DKM and sent to AKMb. The new traffic key delivered to member M 2 by AKMb. Note that domain governing entity also runs rekeying protocol (see Section ) in order to deliver new traffic key to existing members in the multicast group for provision of backward secrecy. DKM delivers the new traffic key to area managers. The member M 1 is one of the participants in this group. It obtains the new traffic key through its area key manager AKMa. Member M 1 leaves multicast group After a while, member M 1 decides to leave group communication. For this purpose, the leaving protocol (see Section ) assists him. Member M 1 sends its leave request to its area key manager AKMa. The entity governing in area a sends the leave message to domain area manager. DKM receives message and checks it. Domain key manager then updates the member M 1 s information in the multicast members list. As the member M 1 should be prevented to access to future data flow, DKM executes rekeying protocol. It initiates new traffic key and distribute it to area key manager. The member M 2 thus receives the new traffic key. Figure 4.5 illustrates leaving the multicast group operation by member M 1. It should be mentioned, all communication from members, M 1 and M 1, to area key managers, AKMa and AKMb, and from area key managers to domain governing entity DKM are protected under secret key shared between them. 60

74 Leave notify Leave notify 4.3. Use Case Diagram Figure 4.5: The existing member leaves the multicast group This section reviews the purpose of use case diagram. It also describes the notations which are used in drawing use case diagrams. Finally, the use case diagram of proposed scenario is illustrated Purpose of Use Case Diagram A use case is a description of systems behavior as it interacts with the request which is originated from the outside of system. It consists of a series of actions that a user adopt them to carry out some task in order to achieve his aim. A sequence of transactions performed by a system is identified in use case that generates a measurable result for a particular external user. Use case analysis is a good tool which can provide a better communication between designer and clients. It can makes easier understanding of system for user and designer. System designers will be able to extract the requirements of target system from user's 61

75 perspective by using use case diagram. Employing use case diagram in the early stage of system development can help designer to meet the needs of the user in final system. Good use case diagram must represent the point of view of the people who will use or interact with the system Notation of Use Case Diagram A use case diagram consists of three main components which are listed as follows: Actors, Use cases, and their communications, and Some additional documentation such as use case descriptions for elaborating use cases. The corresponding notation to each component is briefly described in Table 4.2. Table 4.1: Notations of use case diagram Notation Description Scheme component An actor can be an external entity including people, device or external system that interacts with the system. Use case is illustrated by ellipse and a name. It describes a sequence of action or function that a system should carry out to reach a goal. Association relationship between actors and use cases. Include association which shows a common behavior is shared between a series of use cases. Extend association shows variation way that a user may interact with system. Member Send request Receive message Member and send request use case Member and receive message use case Encrypt message Decrypt message Join request Leave notify Join permission Rekeying message 62

76 System Requirement The system requirements are statement of system and its constraint (Kotonya & Sommerville, 2002). In the other word, it can be the specification of system which is outlined by user, stakeholder and system designer before final system development. These requirements should be clearly identified to guarantee the success of project. The requirements of this scheme are divided to three categories, general requirement, security requirement and performance requirement. The specification of each categories are presented as follows i. General requirements An efficient group key management is able to manage some issues as follows Dynamic group membership. The members are allowed to join or leave the multicast group at any time. Scalability. It is enough able to expand its group size over time. Reliable and trustworthy key managers. All group members are trusted to all group managers. ii. Security requirements Various aspects of security for providing a secure group communication are considered in these requirements. These requirements can be classified as follows: Forward and backward secrecy. Upon any changes in multicast group, rekeying should occur in order provision of forward and backward secrecy. 63

77 Data confidentiality. The distributed data among group members should be accessed by authorized members. Key distribution. All necessary key should be securely distributed to all members before any communication. Key update. The group members should be notified with secure manner when any key update should be done. iii. Performance requirements The performance requirements are associated with computation as well as communication cost. These requirements can be divided into following categories Computation requirements. As the wireless devices encounter with limitation in processing, they cannot stand intensive cryptographic computation. The number of encryption (decryption) should be kept as low as possible. Communication and bandwidth requirements. The communication overhead between group entities should be kept low because of frequent disconnection and bandwidth limitation in wireless environment Use Case Diagram of Proposed scenario In order to computerize a set of desired activities, they should prepare more detailed problem statement. A textual analysis should be conducted on them for identifying the actors and use cases. The analysis workflow can use the description of use case for this purpose. 64

78 As mentioned in Section 4.2, the main entities in this group key management scheme are members M, area key managers AKM, and domain key manager DKM. Separate system functionality is designed to meet a variety of requirement for these entities. Member initiates the request including either join to or leave from multicast group. AKM undertakes the management of members residing in its area. Moreover, it has to handle received messages from DKM. It also governs the keying material in its area. DKM is the main reference for security parameters in the domain. It handles received request from the area key managers. It also governs the keying materials within the domain. Finally, it manages the rekeying occurrence across the domain. Figure 4.6: Use case diagram of scheme 65

79 Figure 4.6 illustrate our system use case diagram. Member is an actor, who interacts with the system. The actions of member contain sending a request and receiving a message. The sending request can be either for joining or leaving a group. On the other hand, receiving message includes two subtask join permission and rekeying message. Since these subtasks including join request, leave notify, join permission and rekeying message reflect in turn the special case behavior of sending request and receiving message, they are illustrated by extend association in Figure 4.6. The encrypting message processes are always used by sending message process. Similarly, receiving message process employs the decrypting message process. These process are thus associated to other process by include notation Chapter Summary The different approaches of group key management schemes is classified in three types; centralized, distributed and decentralized. The advantages and drawbacks of these approaches have been investigated. As the decentralized shares the advantage and disadvantage of other approaches, it s been chosen for group key management of this work. The different components such as entities, needed key and definition of domain and area were identified. Besides that, a scenario was proposed In order to provide a better perception of scheme. Moreover, Requirements of the scheme were listed and finally, a variety of scheme functions have been illustrated by use case diagrams. Next chapter describes the design of the group key management scheme for wireless environment. 66

80 Chapter 5. System Design In this chapter, we describe our group key management architecture for provision a secure group communication in wireless environment in details. In Section 5.1, the architecture of group key management scheme including main entities and their responsibilities, placement of entities as well as required cryptographic keys. Section 5.2 describes the functionalities of needed protocols for join, leave and rekeying operation Architecture In this section, we review the architecture of our group key management scheme. The needed entities, which have been introduced in Section 4.2 are described and presented. The role of each component as well as its responsibility in the scheme is specified in detail Main Entities The main entities in this architecture as mentioned in Section 4.2 contain key managers and group members. The key managers comprise domain key manager and area key managers. The domain key manager governs all entities in the domain. The following subsection describes roles and responsibilities of aforementioned entities. 67

81 Domain Key Manager (DKM) At the domain level, Domain Key Manager (DKM) is assumed that is the main reference for security parameters for other key managers in a domain. It is only one per domain. Its main responsibilities which are expected in this research are generating, distributing, storing and deleting all keying material which may be required. However, DKM can play the role of Group Controller, which includes managing group policy, group membership, rekeying policy and security policy. The responsibilities of DKM are summarized as follows Key manager of Domain, Collaborating with other key managers in order to provide an secure and efficient key management service, Initiating and distributing cryptographic keys to group members, Managing rekeying event in the domain level Area Key Manager (AKM) Area key manager (AKM) is responsible for key management in its related area which includes group of members. Each area has one AKM. The AKM is under DKM s authority and responsible to conduct each rekey event which may occur. The main responsibilities of AKM come as follows Key manager of Area, Contributing with DKM to provide secure and efficient key management service for group members, Initiating and distributing cryptographic keys to group members, 68

82 Managing rekeying event at area level Group Member (M) It involves any member who wishes to participate in a group communication. It can be either sender or receiver. Each member is located within an area at any given time Domain and Area(s) In this proposal, domain is defined logically or physically. It is controlled by a trusted entity such as domain key manager (DKM) (see Section ). The domain is divided into further small administratively scope areas. Each area is managed by a trusted entity such as area key manager (AKM) (see Section ). AKM(s) contributes by DKM in order to provide an efficient key management. Domain Z Area a Area b Area c Area e Area d Figure 5.1: An example of Domain and Areas 69

83 Figure 5.1 shows the notation of domain and areas. Domain Z in Figure 5.1 is divided to small manageable areas such as area a to e which can physically or logically have overlapping each one to another. As the domain is controlled by one DKM, all entities which reside across the domain should be able to communicate with each other. On the other hand, each area is unique and has its own security information so that each member should obtain the security parameter from residing area Entities Placement This section presents the placement of identified entities in Section The entities placement is based on (Mat Kiah, 2007) and (Hardjono, et al., 2000) group key management frameworks. Regarding to Section , a DKM is responsible for key management in domain level and an AKM manages key materials in area level. A DKM collaborates with all AKMs in a domain in order to gain a secure and efficient key management service in its domain. The placement of entities is illustrated in Figure 5.2. The domain Z and area a and b are shown in Figure 5.2. The entity which is labeled by DKM in domain Z is domain key manager. Within area a and b, one entity is area key manager which is labeled with AKM. As mentioned in Section 5.1.2, the members of a group which include the sender and receivers are placed in different areas in domain Z. 70

84 Figure 5.2: An example of placement of entities The dotted arrow lines from DKM to AKM as well as from AKM to members show the control channels which are used for sending control messages such as notification on rekeying. The secure association between DKM and AKM as well as AKM and members are represented by double arrow lines. These associations are employed in order to exchange key and secure association (SA) management. The single arrow line from sender to receivers shows the data channel of group traffic which is established after receiving security parameters by members in a specific multicast group. 71

85 Trust Relationships It s assumed all key managers in a domain are trustworthy and reliable. All members in a multicast group can trust to these managers. In other words, All AKMs trust DKM as a main key manager in a domain level for various multicast communication. All members trust the AKM as a reference point for required security information for contributing in a group communication Type of Keys In this section, the variations of key which are exploited in this proposal are described. These keys are used by entities in which they want to initiate a secure group communication. Since some wireless equipment same as PDA encounters with some restrictions such as Computation and power limitation which result in such a device is not able to process severe computation. Communication and bandwidth requirements that is evolved from intuitive wireless environment characteristics. Because of frequent connection cut-off and available bandwidth in compare with wired environment, it s required the number of exchanged message are kept as low as possible. the base our design is on symmetric key cryptography. This approach in contrast with asymmetric key cryptography approach is faster and less complex technique. Table 5.1 shows a comparison among three popular symmetric encryption algorithms. Although Advanced Encryption Standard (AES) and Triple Data Encryption Standard (3DES) are considered as secure encryption algorithms, AES has superior performance 72

86 and better use of resources. AES was designed from the ground up to be fast, unbreakable and able to support the tiniest computing devices imaginable. As a result, advanced encryption standard (AES) is employed in this dissertation as a desired symmetric encryption algorithm. Table 5.1: Symmetric encryption algorithms comparison DES 3DES AES Key Length 56 bits 112 or , 192, or 256 bits Cipher Type Symmetric block Symmetric, feistel Symmetric block cipher cipher cipher Block Size 64 bits 112 or 168 bits 128, 192, or 256 bits Developed Security Proven inadequate Considered secure Considered secure Possible Keys , , 2 192, or Speed Moderate High Low Resource consumption Moderate Moderate Low Time required to For a 56-bit key: billion years For a 128-bit key: 5 x check all possible days years keys at 50 billion keys per second There are five types of keys in framework include Domain-Area key, Domain key, Area-Member key, Area key and Group-Traffic key. In next subsection, all these keys are described in detail Domain-Area keys (DA i _Key) The Domain-Area key is unique key shared between the DKM and a specific AKM. In other word, DA i _Key is a symmetric key shared between DKM and AKM i of area i. This key is set up by every AKM in the domain prior commencement of each multicast group communication in the domain. The DKM generates this key and sends it to the AKM 73

87 which has sent request, through a secure association such as SSL (Freier, Karlton & Kocher, 1996) or TLS (Dierks & Rescorla, 2008). This key is assumed static and valid until the policy determines otherwise. In addition, this key is used for encryption of message which is sent by unicast channel between DKM and a particular AKM Domain Key (D_Key) The Domain key D_Key is generated by domain key manager DKM in a domain and distributed to all area key managers AKMs within the domain. In more precisely, D_Key is a symmetric key shared between all key managers (DKM and AKMs) in a domain. Similar to Domain-Area key, this key is established prior commencement of each multicast communication in the domain. This key is delivered to all AKMs by DKM via secure unicast channel which is established under appropriate Domain-Area key. Since the group membership of all key managers is static, Domain key is fixed and valid until policy determines otherwise. This key assists to distribute other keys and control messages from DKM to all AKMs by secure multicast communication Area-Member Key (A i M_Key) Area-Member key is a unique key shared between AKM in an area and every group members residing in that particular area. In other word, A i M_Key is a symmetric key shared between area key manager of area i and a group member M. the request of this key is set up by a member who is desired to connect to a multicast group communication prior he join to multicast group. The Area-Member key is generated by AKM of 74

88 member s area. The generated Area-Member key is delivered from AKM to member M via secure association such as SSL. Since group membership can be dynamic, the Area-Member key is valid until member unregisters itself from a particular multicast group. Like Domain-Area key, the Area-Member key is used only for secure unicast communication between AKM of an area and a group member of that particular area Area Key (A_Key) The Area key is a unique key to an area. This key is generated by an AKM in particular area and distributed to group members of that area. Every area has different A_Key. The Area key is set up by member of group after it joins to a multicast group. The new generated Area key is distributed to all members of that particular group by AKM via unicast channels which are secured by Area-Member key. An Area key is assumed valid until any membership changes within a multicast group in the area. Upon any variation in a given multicast group in a domain, the new Area key should be generated and disseminated to remainder of group members. This key assists to distribute traffic key to all group members in an area through a secure multicast communication in on transmission Group-Traffic Keys (T_Key) The Group-Traffic key is a unique key shared between all members of a particular multicast group in a domain. T_Key is generated by DKM and distributed to all AKMs in the domain. The AKMs then distribute the received new T_Key to all members which are 75

89 participant of that particular multicast group in their area. The Group-Traffic key is established after sending first request for join to a multicast group from a member. The Group-Traffic key can be delivered to group members through several options. In the first option, at the domain level, T_Key is protected under Domain-Area key and sent to all AKMs in the domain via unicast communication. At the area level, AKMs employ the similar method by using Area-Member key. Another option is using multicast message to distribute Group-Traffic key to AKMs and members. At domain level, Group- Traffic key is protected under Domain key and at area level; it is protected under Area key. The main functionality of Group-Traffic key is securing data traffic in multicast communication. The Group-Traffic key is valid until any variation in group membership occurs. Upon any variation in group, the old Group-Traffic key should be replaced by new one Summary of Keys The different aspects of keys which are described in Section are tabulated in Table 5.1., which summarizes the type of key, the responsible entity for generation of that specific key, the entities which holds key and finally the function of each key. 76

90 Table 5.2: Summary of keys needed in secure group communication Type of Key Generated by Shared between Function Domain-Area key DKM DKM & AKM Domain key DKM DKM & AKMs Area-Member AKM & AKM key Member Area key AKM AKM & Members Group-Traffic DKM & AKM DKM key &Members A common unique key between DKM and an specific AKM Assist to protect unicast distribution of Domain key and Group-Traffic key. A unique share key between DKM and all AKMs in a domain. Support secure multicast distribution of keys to all AKMS. A common unique key between AKM and a specific Member Assist to protect unicast distribution of Area key and Group-Traffic key. A unique share key between AKM in an area with all members in that particular area. Support secure multicast distribution of Group-Traffic key to all Members. A unique common key between all members of a group. Protect data traffic in multicast group Protocol Functionalities In this section, the functionalities of protocols which are used in this architecture are described. These protocols are used for provision a secure communication within a multicast group. 77

91 Protocol I: New Member Join a Group Communication This protocol describes join operation of a new host member to a multicast group so that the new member cannot access to previous traffic flow before join operation. In other word, this protocol provides backward secrecy in join operation. The sequence diagram of this protocol is illustrated in Figure 5.3. The steps involved in this protocol are described as follows: i. Host M that is interested in joining to a multicast group sends join request message to the area key manager AKM i within its area i. The message is encrypted under secret key A i M_Key. ii. When the AKM i receives the request, it decrypts message with secret key A i M_Key shared by host M. AKM i checks message and then encrypts it with secret key DA i _Key which is shared by DKM. The encrypted join request message will sent to DKM. On the other hand, AKM i runs rekeying protocol (Section 5.2.4) for sending new Area key A_Key to all members within area i. iii. Upon receiving encrypted join request message with DKM, it checks the message by decrypting it with secret Domain-Area key DA i _Key which is shared by AKM i. With this assumption that the host M is granted permission to join the multicast group, DKM generates join grant message. The join grant message will be encrypted by shared secret key DA i _Key and passed to AKM i. The join grant message contains new Group-Traffic key T_Key. 78

92 Figure 5.3: Member joining protocol message flow iv. DKM generates ready to rekey message and send it to all AKM in its domain. This message enforces all AKM in the domain to execute rekeying protocol (The rekeying protocol will be described in Section 5.2.3). This protocol causes all AKMs and all members in a particular multicast group obtain the new Group-Traffic key. v. AKM i receives join grant message and checks it by decrypting it with secret shared key DA i _Key. AKM i can obtain the cryptographic key which is needed 79

93 for secure communication. Join grant message is encrypted under A i M_Key which is secret key shared with host M, and passed to host M by AKM i. After receiving join grant message with host M, it is able to communicate with multicast group. Host M gains the current set of cryptographic key, Group-Traffic Key T_Key and Area key A_Key, by receiving join grant message Protocol II: Existing Member Leaving Group Communication This section describes an existing group member leaving a multicast group with consideration no access to future data traffic. This implies to providing forward secrecy in leaving operation. A multicast group requires rekey in order to replace old keys with new cryptography keys. The sequence diagram of member leaving from a multicast is shown in Figure 5.4. With assumption of existence an established multicast group, the different steps of this protocol describe as follows: i. When host M is desired to leave a multicast group, it sends leave notify message to area key manager AKM i protected under secret key A i M_Key which is shared between member and AKM i. ii. Upon receiving leave notify message by AKM i, It checks the message with decrypting it by using secret shared key A i M_Key. AKM i encrypts leave notify message with secret key DA i _Key shared with domain key manager DKM. Encrypted message will eventually be sent to DKM by AKM i. In addition, AKM i runs rekeying protocol (see Section 5.2.4) and sends ready to rekey message to remaining members in the multicast group 80

94 (excepting leaving member). This message delivers new Area key A_Key to remainder members of multicast group in that particular area. Figure 5.4: Member leaving protocol message flow iii. On receipt, DKM decrypts the message by using secret key DA i _Key which is shared by AKM i. DKM obtains information of leaving host M from the message. DKM removes the leaving host M from multicast group. In addition, DKM initiates rekeying protocol (see Section 5.2.3) and sends ready to rekey message to all AKMs in the domain. This protocol result in all AKMs and members in a particular multicast group receive new Group- Traffic key. Rekeying protocol provides forward secrecy in the domain and prevents to access to future data traffic by leaving member. 81

95 The above case was about member who likes to leave the multicast group voluntary. In another case, involuntary leaves, member is expelled from multicast group by DKM. For this purpose, the eject notify message included ID of member is generated by DKM and sent to that AKM i which the mentioned member is residing in. AKM i sends the eject notify message to the member M. DKM also initiates rekeying protocol to replace old Group-Traffic key with new one. Figure 5.5 shows involuntary member leaving. Figure 5.5: Member leaving (involuntary) protocol Protocol III: Rekeying Group-Traffic Key This protocol conducts rekeying of group traffic key of a multicast group. As mentioned in protocol I (see Section 5.2.1) and protocol II (see Section 5.2.2), rekeying protocol is employed for provision of backward secrecy in member joining to and forward secrecy in member leaving from a multicast group. This protocol delivers the new group traffic key to all members in a domain (excluding member leaving).note that rekeying group traffic key always run immediately upon any membership changes within a multicast group in this design. However, some relaxed approaches postpone the 82

96 rekeying task until the next periodic rekeying (DeCleene, et al., 2001), (Kostas, et al., 2003). Figure 5.6: Rekeying of a Group Traffic Key protocol message flow The sequence diagram of rekeying group traffic key protocol is depicted in Figure 5.6. It is assumed the multicast group has been already established. The steps of protocol are described as follows: i. DKM generates new Group-Traffic key T_Key. It then prepares ready to rekey message which is involved new group traffic key and multicast group ID. Next, it distributes the message to all AKMs in the domain either by: Secure unicast channel, in which each message is protected under Domain-Area key DA i _Key. Secure multicast communication, in which each message is encrypted under Domain key D_Key. ii. Upon AKMs receives the message, they check it with decrypting it by Domain-Area key DA i _Key which is shared between domain and key 83

97 manger of area i. AKM i obtains new Group-Traffic key T_Key. Next, AKM i sends the ready to rekey message to all members of multicast group by: Secure unicast channel, in which each message is encrypted under Area-Member key AM_Key. Secure multicast communication, in which each message is protected under Area key A_Key. iii. When members receive the ready to rekey message, they check it by decrypting it with secret key shared with their area key manager AKM. Now, they obtain the new group traffic key T_Key Protocol IV: Rekeying the Area Key This protocol governs the rekeying of an area key in an area. As mentioned in protocol I and II (see Section and 5.2.2), this protocol is conducted when a new member joins to group with backward secrecy and existing member leaves from multicast group with forward secrecy. The step of rekeying protocol in an area is shown in Figure 5.7. Description of this protocol comes as follows: i. AKM generates new Area key A_Key. It sends the ready to rekey along with new A_Key to all members of a multicast group in its area. Distributing of area key can be done either via Secure unicast channel, in which each message is protected by secret key shared between area key manager and each member. 84

98 Secure multicast communication, in which each message is protected by old A_Key (excluding existing member leaving). ii. After receiving message by members, they encrypt message with the secret key shared by area key manager and obtain new A_Key. Figure 5.7: Rekeying of an Area Key protocol message flow 5.3. Chapter Summary In this chapter, the main components in this architecture were described. The main protocols which are adopted in the design have been explained. In next chapter, the implementation of this design will be considered. 85

99 Chapter 6. Implementation and Testing This chapter presents the implementation of the group key management scheme. System testing is subsequently explained. The chapter is organized as follows: In Section 6.1, the requirement of implementation including software and hardware is introduced. The Section 6.2 discusses implemented classes during development of group key management system. The main classes comprise domain key manager class, area key manger class and member class. In Section 6.3, the results of system execution are shown Implementation Requirements This section introduces requirements of implementation during group key management system development. These requirements comprise software tools and hardware equipment, which are used for system establishment Software requirements Software requirements in this work contain the language programming and implementation tools. The language programming is used to develop required system. The software implementation tools are employed to speed up the system building, testing and debugging process. In order to develop project NetBeans is adopted as a convenience 86

100 environment for implementation. Java is employed as a main programming language for developing this project Java Java is a high level programming language which is developed by Sun Microsystems in It is object oriented language similar C++, but simplified to eliminate language features that cause common programming errors (Arnold, Gosling & Holmes, 2005). Java includes a number of features which make it more valuable to developer by enabling them to Write software on one platform and run it virtually on another platform. Create program to run within web browser. Develop server side for online forum, HTML forms processing and more. Write efficient and powerful program for low cost consumer products and mobile phones. Java EE 6 is the current major release of the Java enterprise edition platform which is used for implementing of group key management scheme in this dissertation. The endeavor of SUN in this version was providing the following key features: Applications run faster on clients and servers. Full supported by NetBeans IDE 6.7 Simplified graphical user interface (GUI) design and expanded native platform support Improved memory usage analysis and leak detection Native platform Security (GSS/Kerberos) integration 87

101 NetBeans The NetBeans IDE is a free, open source integrated development environment for software developer. It provides all the tools that a developer needs to create a professional desktop, enterprise, web and mobile application with the java language. NetBeans allows the application to be developed from a set of modules. A module is a Java archive file that contains Java classes written to interact with the NetBeans Open application programming interfaces (API). Some of integrated modules of NetBeans are profiler, GUI design tools and Java script editor. In this project NetBeans IDE 6.7 is employed to develop the key management scheme for secure group communication Hardware Requirement The development of group key management scheme is carried out using different devices. There are three server machines which are used for deployment of area key managers and domain key manager. However, the domain key manager and area key manager can be physically run on a common server. The workstation is a client which is equipped with wireless network interface card. The operating system platform of all servers and workstation is windows XP which provides a friendly environment for executing of software requirement. Table 6.1 shows the hardware and software specification used in deployment of group key management scheme. 88

102 Table 6.1: Hardware specification used in establishment of system Domain key manager Area key manager workstation server server Processor speed 3.00 GHz Core 2 Duo 2.8 GHz Core 2 Duo 2.2 GHz Core 2 Duo RAM 3072 MB 3072 MB 1024 MB Operating system Windows XP Windows XP Windows XP 6.2. Architecture Development Different components of group key management scheme have been described in Section 5. Key managers including area and domain key managers as well as members are the main entities in this scheme. Domain key manger is placed in top level of scheme. It listens to received request and generates appropriate response for sending to requester. It also governs the rekeying occurrence which is happen in domain level. The clients are located in low level of scheme. They are indeed the members of a multicast group. They should send their request to key manager of their area in order to receive keying materials for contribution in a group communication. They concurrently listen to their area key manger to receive managers governing message. In intermediate level, the area key managers perform the role of intermediary. They listen to established connection for receiving members request and domain key manager governing message. On the other hand, they have to deliver the domain manager message to its members as well as members request to domain manger. The implementation of each entity in this scheme along with corresponding pseudo code is described in the following subsection. 89

103 Domain Key Manager The domain key manager is responsible to govern all entities within its domain (see Section 5.1.1). DKM listens to request, which has been received through the established connection between DKM and AKMs, and serves them properly. For this purpose, DKM server must create a server socket object and attach it to a specific port, which is where the server listens for connections (Calvert & Donahoo, 2008). The following server socket is created on DKM server. ServerSocket serversocket = new ServerSocket(serverPort); The DKM server waits indefinitely for an area key manager connection. It carries out this by calling method accept of ServerSocket class (Graba, 2007). Upon establishing any connection, a Socket object will be returned in order to use for next communication with that specific area key manager. The required command for accepting request from AKM server is as follows: Socket socket = serversocket.accept(); When the DKM server receives any message from area key manager server, it executes areakeymanagerhandler class for generating appropriate reply to sender of request. This class also handles the rekeying protocol in domain level. The content of areakeymanagerhandler class is as follows: 90

104 While (true) { 1. If received message is registration_request { i. Call CryptoServices class for generating Domain-Area key (DA_Key). ii. Send DA_Key to area key manager which has sent the registration request. } 2. Else if received message is join_request { i. Call CryptoServices class for generating new Group-Traffic key (T_Key). ii. Generate join_grant message. iii. Encrypt join_grant message by secret key shared by area key manager. iv. Send message to area key manager, which has requested for joining to group. v. Prepare ready_to_rekey message and send to AKMs server in domain. } 3. Else if received message is leave_notification { i. Find the information of leaving member in members list. ii. Remove leaving member information from the list. iii. Call CryptoServices class for generating new Group-Traffic key. iv. Prepare ready_to_rekey message and distribute to all AKMs. } } 91

105 DKM server checks the received message using areakeymanagerhandler class. This class enables DKM server to identify the type of request. DKM server has different reaction in encounter with various type of message, which are mentioned as follows Registration request. It is generated by AKM servers in the domain in order to obtain Domain-Area key. DKM server generates DA_Key by calling CryptoServices class. A key random generator creates DA_Key by using AES standard with length of 128 bits (Hook 2005). Key DA_Key = CryptoServices.keyGeneration(); Join request. This message contains the request of member for joining to a specific multicast group. The new Group-Traffic key T_Key is generated similar DA_Key and delivered to interested member. Leave notification. This message includes the leaving member information. DKM server updates information of leaving member in the members list Area Key Manager Area key manager has two aspects, client and server. It is a client for DKM server and a server for members within its area. The implementation of area key manger consists of distinctive classes, which have different roles including registration to DKM server, client handler and DKM message handler. Variation parts of area key manager development are described as follows: i. Registration to DKM server 92

106 AKM server sends its registration request to DKM server in order to receive Domain-Area key. AKM server must establish a socket object for communication with DKM server. The following Java line creates a socket object on AKM server by attaching DKM server IP address and its port for communicating with DKM server. Socket akmsocket = new Socket (dkmipaddress, dkmport); When the socket object is established, AKM server sends registration_request message to DKM server. It waits to receive registration_grant message from DKM server. Different stages of area key manager registration shows as follows: 1. Generates Socket object. 2. Make registration_request message. 3. Send message to DKM server. 4. Wait for receiving response from DKM server. 5. If received message is equal with registration_grant { i. Extract DA_Key from received message. ii. Run acceptclient() class. } ii. Accept Client AKM server runs its server part for accepting new connection which is established on behalf of residing clients within its area. AKM server must thus establish server 93

107 socket object like as DKM server. The chosen port number of AKM server is different from DKM server port. The port number should binds to server socket object in order to listen to request connection from client. The handleclient class as well as handledkmmessage class will be run concurrently when a connection is established between client and AKM server. The pseudo code of this procedure is shown as follows: 1. Generate Server Socket object and bind the AKM server port to it. 2. Wait for clients request for making connection. 3. Call CryptoServices class for generating AM_Key. 4. Run handleclient class. 5. Run handledkmmessage class. iii. Handle Client Message The client request is received by handleclient class. AKM server checks the requests and sends them to DKM server for next process. The following pseudo code shows handleclient class. 94

108 While (true) { 1. Decipher received message by calling CryptoServices.decipher(message). 2. if the received message is equal with join_request { i. Encrypt message by DA_Key ii. Sends join request to DKM server. } 3. Else if the received message is equal with leave_request { i. Encrypt message by DA_Key ii. Sends join request to DKM server. } } As shown in pseudo code of handleclient class, each received message is decrypted by CryptoServices class in advanced. The message is deciphered by Area-Member key which is unique secret key shared between AKM server and member. The message will be encrypted by DA_Key, which is secret key shared between AKM server and DKM server. Next, cipher message is sent to DKM server for getting permission to join or leave a multicast group. iv. Handle DKM Server Message This class is responsible to received governing messages from DKM server. These messages can be included controlling messages and permission message for 95

109 joining or leaving a multicast group. This class continuously listens to DKM server for receiving DKM server commands. A received message by handledkmmessage class is deciphered by calling function decipher(message) in CryptoServices class. handledkmmessage class checks the message. If message is equal with join_grant, the class identifies the member, who has already sent join request to AKM server, and sends the join_garnt message to member after encrypting by secret key shared between AKM server and member AM_Key. Otherwise, if the message is leave_grant, the class updates the leaving member information in its members list. As mention in Section and 5.2.2; when a new member joins to a multicast group or an existing member leaves a multicast group, DKM server distributes the ready_to_rekey message to AKM servers in order to disseminate new group traffic key to members of a multicast group for provision of backward and forward secrecy. handledkmmessage class specifies the members of specific multicast group, which is identified in ready_to_rekey message from its members list. The ready_to_rekey message is sent to each identified member after encrypting under AM i _Key, which is key shared between member i and AKM server. Pseudo code handledkmmessage class is illustrated as follows: 96

110 While (true) { 1. Decipher received message by calling CryptoServices.decipher(message). 2. if the received message is equal with join_grant { i. Encrypt message by AM_Key ii. Sends join grant to member, who is interested to join to a group. } 3. if the received message is equal with leave_grant { i. update member information in members list. } Else if the received message is equal with ready_to_rekey { i. If there are some member belong to specific group { ii. For(int i=0 until i<number of member in group; i++) { Encrypt message by AM_Key, which is key shared between AKM server and member i. Send ready_to_rekey to member i. } } } 97

111 Member Member has to send its requests to AKM server for collecting keying materials to participate in a multicast group. It establishes a socket object by specifying IP address and port number of AKM server, which is manager of member s area. The following java line shows the created socket on member side using AKM server IP address akmipaddress and server port akmpoert. Socket clientsocket = new Socket (akmipaddress, akmport); The future communication between member and AKM server will carry out through this socket. Member must obtain the secret shared key between itself and AKM server for encrypting and decrypting next messages. So it generates registration request and sends it to server. It waits until receiving the AM_Key from AKM server as follows: 1. Generate Socket object by bind the AKM server port to it. 2. Make output and input stream. 3. Send registration_request to AKM server. 4. Wait to receive registration_grant message. 5. Extract the AM_Key from received message. Member sends join_request message to AKM server for joining to a specific multicast group. The request message contains the multicast group ID which has been specified by member. Meanwhile the first join event, handlereceivemessage class is executed to 98

112 handle received message from AKM server. The pseudo code of first join is depicted as follows: 1. Get multicast group IP address. 2. Generate join_request message. 3. Encrypt message by AM_Key. 4. Send to the AKM server. 5. Run handlereceivemessag. handlereceivedmessage class manages AKM server governing message. The messages can be either join grant or ready to rekey message which arises after any join or leave the multicast group. The following pseudo code shows content of handlereceivedmessage class. While (true) { 1. Wait to receive server message. 2. Decipher received message by calling CryptoServices.decipher(message). 3. If (the received message is equal with join_grant ) { i. Extract the T_Key from received message. } 4. Else if ( the received message is equal with ready_to_rekey ) { i. Extract new T_Key from received message. } } 99

113 This class continuously listens to socket in order to receive all messages generated by AKM server for this member. The received message is decrypted under secret key AM_Key in CryptoServices class by decipher() function. The Group-Traffic key T_Key can be extracted from the join_grant message. The new T_Key can be also derived from ready_to_rekey message when any changes occur in multicast group membership Testing This section presents the deployment of main entities in actual environment. Subsequently, it illustrates the system testing, which is performed after implementation of scheme. These tests are carried out according to the scenario which has been described in Section Scenario Deployment The group managers in the scenario were domain key manager DKM and two area key manager AKMa and AKMb which are respectively manager of area a and b. We run each key manager on separate PC. However, they can be run on a common device. The member M 1 and M 2 were placed inside in turn area a and area b. Figure 6.1 illustrates the architecture of scenario along with IP addresses are assigned to all entities in the domain. 100

114 AKM Servers Registration Figure 6.1: Illustration of architecture used for testing In the first step, area key managers, AKMa and AKMb, register itself to DKM server. AKMa starts procedure by getting the DKM server IP address as shown in Figure 6.2. DKM server receives AKMa registration request and generate the DA a _Key which is unique key shared between DKM server and AKMa server. DKM server sends registration grant message to AKMa as shown in Figure 6.3. AKMb carries out a procedure like the AKMa for registration in DKM server. 101

115 Figure 6.2: AKMa registers itself to DKM Members Registration Figure 6.3: DKM sends DA_Key to AKMa Likewise the area key manager in the domain, two members M 1 and M 2 must register themselves respectively in AKMa and AKMb. Member M 1 sends its request to AKMa as depicted in Figure 6.4 and AKMa responds to member after generating AM 1 _key. Member M 2 gains shared key from AKMb similar to member M

116 Members Join the Group Figure 6.4: Member M 1 receives secret key Join event includes two steps in this scenario. First, member M 1 join to a multicast group as first member of group. Second, member M 2 joins to an existing multicast group. These parts are presented in following subsection. i. Member M 1 join to new group. As depicted in Figure 6.4, member M 1 gets the multicast group ID and sends its request for joining that multicast group to its area key manager AKMa. Consequently, AKMa informs DKM server. Upon receiving join message by DKM server, it recognizes the request is for joining a new multicast group. Subsequently it initiates a new Group-Traffic key T_Key for that specific group and delivers it to member M 1 through AKMa. Figure 6.5 and 6.6 illustrate the activities of AKMa and DKM. ii. Member M 2 joins to the existing group. Likewise member M 1, member M 2 sends its join request to the group to its area manager AKMb. The join operation for member M 2 is similar to member M 1 except an extra rekey operation that happens in DKM server. 103

117 Figure 6.5: AKMa governs member M1 join request Figure 6.6: Managing join request by DKM iii. Rekeying operation. DKM server checks the group ID which has been requested by AKMb. It finds member M 1 within area a has already joined to this multicast group. It thus generates ready_to_rekey message and sends to AKMa which is area key manager of area a. This message delivers new Group-Traffic key to member M 1 through the AKMa. Figure 6.7 and Figure 6.8 show receiving of ready_to_rekey message by AKMa and member M

118 Figure 6.7: AKMa receives ready_to_rekey Figure 6.8: Receiving new T_Key by rekey message Leave the Group According to the scenario, member M 2 leaves the group voluntarily after awhile. He sends leave notification message to AKMb which is area key manager of area b. AKMb receives the leave notification message and checks it. Figure 6.9 shows AKMb that s informed DKM server from member leaving the group. DKM server searches its members 105

119 list and updates the information corresponding to the member M 2. It also generates new Group-Traffic key for the group. Figure 6.9: AKMb manages member M 2 leave notification DKM server concurrently checks others members belonged to the group. It recognizes the member M 1 within area a exist in the group. So it sends the ready_to_rekey message to AKMa server in order to deliver new T_Key to member M 1 as shown Figure Figure 6.10: DKM governs leave operation 106