Key Management Schemes for Multilayer and Multiple Simultaneous Secure Group Communication
Many emerging applications are based on group communication model and many group communications like multimedia distribution and military applications require a security infrastructure that provides multiple levels of access control for group members. The group members are divided into a number of subgroups and placed at different privilege levels based on certain criteria. A member at higher level must be capable of accessing communication in its own level as well as its descendant lower levels but not vice versa. In this paper we propose a key management scheme for this multilayer group communication. We achieve substantial reduction in storage and encryption cost compared to the scheme proposed by Dexter et al. We also address periodic group rekeying. Applications like scientific discussion and project management may lead to a scenario in which it is necessary to set up multiple secure groups simultaneously, and few members may be part of several secure groups. Managing group keys for simultaneous secure groups is critical. In this paper we propose a novel key management scheme for multiple simultaneous groups.
Many emerging applications like secure audio and visual broadcasts, pay-per-view, scientific discussion, and teleconferencing are based on group communication model. Several users participate in these applications, and multicast communication is an efficient means of distributing data to a large group of participants [1–3] since it reduces the demands on network and bandwidth resources. But, the communication among these participants must be carried out confidentially. Thus, a common key known as group key or secret key must be established with all the users in the group, so that any group member can encrypt the message using this key, and all others can decrypt the message using the same key. The group, being dynamic in nature, allows member join and leave events. Efficiently managing group key for large, dynamically changing groups is a difficult problem. Every time when a new member joins the group, the group key must be changed in order to provide backward access control (i.e., new members should not be able to access past communication). Similarly, when a user leaves the group, the group key must be changed so that leaving member cannot have access to future communication that takes place between remaining group members, known as forward access control. This group key updating process is referred to as rekeying.
Rekeying process involves changing the group key whenever there is a membership change and distributing it among the members of the group in a secure manner. To communicate changed key among group members securely, rekey messages are constructed, encrypted, and multicast to the group. The overhead involved in rekey operation, that is, key updation, number of encryptions performed, and communication cost must be minimum and should be independent of the group size, which improves scalability.
Several secure group key management techniques have been proposed to support scalable secure multicasting [4–10]. In a typical multicast key management scheme, there is a trusted third party, known as Key Distribution Center (KDC). This single trusted centralized entity is responsible for generating and distributing keys securely to the group members. Among the schemes which involve KDC [7, 11–15], the scheme proposed by Wong et al. in  is efficient and is widely used since it improves scalability. The scheme uses a hierarchical tree structure in which users are maintained at the leaf level, and every user is assigned with keys along the path of its location till the root. Besides group key, the KDC shares auxiliary keys that are used solely for the purpose of updating the group key and other auxiliary keys. In addition, every user shares a private key that is known by itself and the KDC. These schemes are referred to as key-based schemes.
Hierarchical tree structure is also used in Centralized Key Management with Secret Sharing (CKMSS) [16, 17]. In this scheme, KDC considers a degree ( is a nonzero positive integer) polynomial with the constant term of the polynomial being the secret key. It computes distinct shares known as prepositioned information and stores them at the users. To compute the group key, () shares of the polynomial are required, and this ( share is sent as an activating share by the KDC. Once the group key is computed, it is used until a member joins or leaves the group. For every membership change (join/leave), to perform rekey operation, KDC multicasts an activating share to enable the members to compute new group key. These schemes are called share-based schemes.
Both the key-based and share-based schemes discussed above are designed for managing keys for a group of users enjoying same privilege and are not suitable for handling multilayer and multiple SGC scenario. But, for certain applications, it is necessary to have multilayer group communication scenario where members in the system have different privileges. In some applications a member in the system may be part of several groups. In this paper, we address the above two cases of Secure Group Communication (SGC) and propose key management schemes.
We organize the paper as follows: Section 2 focuses on the applications of multilayer SGC and highlights the schemes proposed to address such scenario in detail. Section 3 concentrates on our scheme to manage multilayer hierarchy. We discuss initial key computation, rekeying during join/leave operation, periodic rekeying. In section 4 we compare the performance of our scheme with Dexter et al. scheme. Section 5 deals with setting up multiple groups, initial key computation, and rekeying. Section 6 presents authentication to multiple SGC, and we conclude the paper in Section 7.
2. Applications of Multilayer SGC
(i) In multimedia applications, we can consider two categories of receivers: high-definition television (HDTV) and traditional television. Users with HDTV receivers can form one subgroup and others with traditional television receiver can form another subgroup. Users with traditional television receivers can receive the normal format, while the users with HDTV receiver can receive both the normal format and the extra information needed to achieve HDTV resolution. Thus, there are two layers, group with HDTV receiver forms higher layer subgroup and the one with traditional television receiver forms lower layer subgroup. This application requires a multilayer SGC scenario.
(ii) In multicast scalable video service, the video is encoded into quality levels: basic quality level, medium quality level, and best quality level. Here, the users can be classified into different layers based on the quality of the video they purchase: base layer (BL), enhancement layer 1 (EL1), and enhancement layer 2 (EL2). The users purchasing the basic video quality level belong to BL group, users purchasing the medium quality level belong to both BL and EL1 groups, whereas the users purchasing the best quality level belong to all the three, that is, BL, EL1, and EL2 groups. Thus, users with access to higher-quality video service must also have access to lower-quality ones.
(iii) Military troop contains different categories like Captains, Lieutenants, Sergeants, Corporals, Soldiers, and so forth, and this requires a hierarchical group communication model. Captains are at the highest layer, Lieutenants at the second higher level layer, Sergeants at a layer below Lieutenants, Corporals at the next lower layer, and Soldiers must be at the lowest layer as considered in . Soldiers should be able to communicate only with other Soldiers (peer members), whereas Sergeants can communicate with other Sergeants as well as with Corporals and Soldiers. Similarly Captains should have access to all the communications that take place between different classes.
(iv) In project management, a single project is divided into multiple modules, and set of users are made to design a particular module. Users involved in handling one module form one secure group. This may lead to a scenario in which it is necessary to set up multiple secure groups simultaneously.
To manage the above type of scenarios, a naive solution is to extend key-based and share-based tree structure, by using independent trees for each layer. But, this is inefficient and does not scale well when there are many layers. Hence, there is a need to have a multigroup key management scheme that exploits the overlap in the memberships of different layers. Two key management schemes have been developed to provide hierarchical access control. The scheme proposed in [19, 20] is key-based, where each layer has its own session key and whenever there is a membership change in any layer, corresponding session key is changed and securely transmitted to appropriate group members. The scheme proposed in  is share based. For each layer, a polynomial of degree is considered, and distinct shares of this polynomial are stored at the members of that layer (prepositioned information) and KDC sends share as an activating share so that members can compute group key for that layer. Whenever there is a membership change in any layer, KDC just sends a different activating share to the members of that layer so that they can compute a new group key for that layer.
In , a military application is considered to illustrate multilayer secure group communication. Military officers belonging to different categories (Captains, Lieutenants, Sergeants, Corporals, Soldiers, etc.) are divided into subgroups and are hierarchically placed one above the other. Higher layer officials can have access to the communication between its descendant lower-layer subgroups. To provide this feature, it uses a one-way hash function to compute a chain of keys. The main idea of using function is to relate layers' keys in such a way, that is, knowing a key of its own layer, a member can compute keys of lower layers. Thus, Captains are given with random key , for the Lieutenants is given, for Sergeants is sent, Corporals are assigned with , and Soldiers with . Captains can access the communication between the Sergeants, by computing the key .
To the best of our knowledge, only SGC within a single group is addressed in the literature. A SGC among multiple groups is not addressed in the literature. In this paper we address key management schemes for multilayer and multiple groups and our schemes can be used for the applications explained above.
2.1. Multilayer Secure Group Communication
Multilayer key management scheme proposed in [19, 20] uses the following model: a set of users is partitioned into subsets (subgroups) such that members of and can communicate with each other. However, members of can communicate with members of , , but not vice versa, . We say that the members of subgroup are at layer and members of subgroup belong to subgroup , . Members of subgroup overlap with the members of subgroup , . Figure 1 illustrates the arrangement of different subgroups in layered approach, .
To manage keys for multiple layers in traditional hierarchical tree-based key management scheme, a separate key tree is constructed for each layer. Although it is easy to implement using independent trees, a substantial overhead is introduced in managing the keys due to the overlapping membership in different layers.
In order to manage the keys of all the subgroups, independent trees are integrated into one key graph in [19, 20], and it uses a key-based scheme to manage the keys. In , integrated key graph as in [19, 20] is used, but for key management it uses share-based scheme. The key management scheme proposed in  is explained as follows: (1)KDC fixes the security parameter ,(2)KDC constructs a Logical Key Tree (LKT) as in  for the subgroup at layer . For a secure group with users, there are at most nodes in LKT and the height of the LKT, is ,(3)for each node in LKT of subgroup , KDC selects randomly number of distinct points () in (where refers to Galois Field) called prepositioned shares, , , . To each user , KDC sends securely shares pertaining to the shares for the nodes along the path from leaf node till root, (4)KDC selects another point called activating share (AS) and broadcasts it to the members of all the layers in the system, (5)a member of the subgroup constructs number of polynomials of degree using the corresponding shares it has received from KDC and AS, and evaluates each polynomial at to get the keys, and(6)KDC also constructs polynomial of degree for each node in the LKT of using the points () and and evaluates at to get the corresponding key for that node.
In this scheme, each key is computed by constructing a degree polynomial using different prepositioned shares and a common activating share. In this scheme, each user is required to store prepositioned shares of the nodes from leaf to the root.
3. Proposed Key Management Scheme for Multilayer SGC
We propose to use the key graph structure as in [19, 20]. We construct individual key trees for different layers and then integrate them. We use the same model that is explained for Dexter et al. scheme and try to reduce the amount of storage required at both KDC and users . For auxiliary keys, we use random elements, and we compute the group keys as described below.
KDC fixes the security parameter , computes, and distributes the keys and shares as follows: (1)KDC selects randomly number of points () in called prepositioned shares, and an activating share () and sends securely to the members of all the subgroups ,(2)KDC constructs LKT for the subgroup at layer with the subgroup key . The key is obtained by constructing a polynomial of degree using the points () and and evaluating at to get . KDC sends secretly to each user of , all the auxiliary keys along the path of LKT from leaf to the root,(3)KDC selects group share for the subgroup and sends secretly to the members of the subgroup , , and(4)KDC constructs LKT for the subgroup at layer with the subgroup key . The key is obtained by constructing a polynomial () of degree using prepositioned shares, , and group shares , and . It evaluates the polynomial at to get . To each user of , KDC sends secretly all the auxiliary keys along the path of LKT from leaf to root.Figure 2 shows the hierarchical key tree structure with layers.
Figure 3 shows an example integrated key graph for three layers in which three independent groups are integrated to form a three-layer hierarchy. In Figure 3, , , and represent the roots of the subgroups , , and , respectively.
We are addressing the following events: (1)a new member joins the service, (2)a member leaves the service, and(3)a member moves from one service layer to another service layer.
3.1. Member Join Event
When a new member, , joins any layer , , keys along the path from the joining point till the root must be changed and conveyed to corresponding users. Instead of KDC changing the keys or sending a new activating share, we allow the members of layer themselves to compute the new group key and auxiliary keys on their own by applying one-way hash function to the corresponding previous keys. KDC also applies one-way hash function to the previous keys on the path from the joining point till the root. Members at layers to change the group key by applying one-way hash function to previous group key . For the new user, , KDC sends prepositioned shares (), auxiliary keys of along the path to where is inserted, and group key and group shares () by encrypting with the private key of , .
3.2. Member Leave Event
If a member at layer leaves, , the following keys have to be changed: (1)keys along the path from the leaving position till root, (2)subgroup key , and (3)subgroup keys of layers from to .
KDC generates keys along the path and sends them securely to the required members of the group. KDC generates and sends a new activating share securely to the members of the subgroups , , , . Users of group construct the polynomial using prepositioned shares, group share, and new activating share and compute the group key by evaluating the polynomial at , .
We illustrate this with the following example. From Figure 3, if member leaves the group, the following messages are constructed and sent to users ( indicates key encrypted with key and AS denotes activating share) .
3.3. Member Moving from One Service Layer to Another
Here we encounter two cases.
Case 1. If a member moves from layer to its higher layer (), then it must be provided with extra group share/s meant for layers from to . To provide backward confidentiality for the messages communicated in the subgroups from to , group share of the group is changed, . KDC generates group share and encrypts with the previous group key and sends to members of the group , .
Case 2. If a member moves from layer to its descendant layer , (), then group shares of layers from to must be changed. In layer , auxiliary keys possessed by the moving member must be changed. To convey new group share to the members of subgroup , it is encrypted with the auxiliary keys at level of LKT of subgroup , .
Example 1. In Figure 3, if a member moves from layer to layer , it is inserted as sibling of member . The group share must be changed to provide backward access control. The following messages are constructed and sent to users: , , .
3.4. Periodic Rekeying
If the content has very high value, even though there is no membership change, group key must be changed for all the layers periodically. This leaves the attacker with very less time to attack on the current key values. To achieve this periodic rekeying, we fix a rekey period/interval. After the expiry of each rekey interval, rekeying process is initiated. For periodic rekeying, we propose two methods.
Method 1. (i) KDC sends an activating share by encrypting it with layer group key, .
(ii) Since all the users in the system belong to subgroup , they know the subgroup key and can decrypt the activating share.
(iii) Users of subgroup compute new subgroup keys using new activating share, prepositioned shares and group share .
Method 2. The users compute the new group key after every rekey interval by applying a one-way hash function on the current group keys. This reduces the communication and computation cost since it avoids reconstruction of the polynomial.
Storage at Each User
In Dexter et al. scheme , each user stores the shares of the keys along the path from leaf to the root, . If there are users in , then height of the tree is . Thus each user stores number of elements.
In our scheme, each user stores prepositioned shares, an activating share, number of group shares and auxiliary keys.
Storage at KDC
KDC is required to store shares of all the keys in the system. For a total of users in the system, there are at most nodes. Thus, storage required at KDC in Dexter et al. scheme is . In our scheme there are shares and auxiliary keys in the system. Hence KDC is required to store only elements.
In Dexter et al. scheme, if a member leaves any layer , , in order to change the keys along the path till the root, corresponding prepositioned shares must be changed, which leads to encryptions. Also, prepositioned shares meant for different layers must be changed, which results in encryptions. Hence, the number of elements encrypted is . Whereas in our scheme, keys along the path and an activating share are encrypted; thus, it is just encryptions.
In Dexter et al. scheme , the group key for each layer is computed by constructing a degree polynomial and evaluated at . In our scheme, as we move up the hierarchy, degree of the polynomial is incremented by . Though it requires more amount of computation as compared to degree polynomial, it improves the resistance of the system to attack; hence, the system is more secure.
Table 2 compares the performance of our scheme with Dexter et al. scheme . To have fair comparison we consider layers , , , and and a polynomial of degree , that is, . is the layer at lower privilege level, and is at higher privilege level.
Consider an example with users at layer , users each at layers and , and users at layer . Heights of the trees at layers , , , and are , , , and , respectively. Number of keys stored at KDC in Dexter et al. scheme is at each layer which sums up to be , whereas in our scheme we get only keys at the KDC which is computed as .
In Dexter et al. scheme, users at layer store sets of prepositioned information, namely, keys. Users at layer store sets of prepositioned information, users at layer store sets of prepositioned information, and users of layer store sets of prepositioned information. In our scheme, the number of keys at different layers , , , and is only , , , and , respectively.
In Table 2 we also have recorded the percentage of savings achieved in our scheme. From the values recorded in Table 2, it is clear that we achieve substantial savings in storage and encryption cost as compared to Dexter et al. scheme. For instance, for a secure group with users and with a fixed security parameter , we achieve % savings in storage at KDC and about % savings in storage at the users.
5. Multiple Simultaneous SGC
A project may be divided into several modules, and each module may be assigned to a group of members. It may be necessary for some members to deal with two or more modules depending on the requirement. It is required that each module should be developed confidentially so that members developing a particular module must communicate among themselves securely. Hence, each group should have a group key, and members belonging to two or more groups should possess group keys of all those groups for which they are members. We develop a key management scheme for such multiple SGC with efficient storage, computation, and communication costs .
5.1. Key Management Scheme
We consider a set of users and subgroups such that some users are present in more than one subgroup. For each subgroup , a logical key tree is constructed, . The height of the tree for subgroup depends on the number of users in . If there are () number of users in group , then the height is . An user is assigned with a private key , and auxiliary keys along the path from to root of the key tree. This section deals about initial group setup and computation of group key(s).
5.2. Initial Group Setup and Group Key Computation
Our scheme is based on centralized key management scheme using logical key tree (LKT) approach as proposed in . Hence, we assume a trusted KDC which is responsible for initial group(s) setup and rekeying operations. Users in the system are provided with unique identification number, and the groups are assigned with group numbers. To begin with we allow the KDC to fix the security parameter . (1)User , who would like to join the group , sends a join request to KDC. The KDC generates and sends a unique private key , to the requesting user over a secure channel (we assume that, at the initial stage, a secure channel is established between KDC and the joining user). Hence, every user shares a private key with the KDC.(2)KDC selects randomly number of points () in called prepositioned basic shares, and as activating share . These shares are sent securely to the members of all the subgroups .(3)KDC selects randomly points () in called prepositioned group shares distinct from the previously selected points and sends () securely to the members of the subgroup , .(4)KDC constructs LKT for the group with the group key . The key is obtained by constructing a polynomial of degree using the shares () of step and the prepositioned group share (). The group key is , . KDC sends secretly to each user of , all the auxiliary keys along the path of LKT from the leaf to the root.(5)If an user is a member of number of groups , it is provided with prepositioned basic shares along with and number of prepositioned group shares. It constructs distinct polynomials. A polynomial is constructed by using shares of step and prepositioned group share (), . Thus, it can construct distinct polynomials just by using one distinct group share.
Figure 4 shows an example key tree structure with groups, namely, , , and set up simultaneously. Group comprises of eight members , group contains , , , and as its members, whereas members , , , , , and belong to group . In Figure 4, -nodes represent users, and -nodes represent keys. Key nodes through are private keys of users through , respectively, and remaining -nodes in the figure represent auxiliary keys. , , and are the group keys of the groups , , and , respectively.
For example, let us consider , and the prepositioned basic shares as , and as . Assume that KDC sends , (, and as the prepositioned group share for the members of the groups ,, and , respectively. Hence, the members of the group , , now possess ; that is, shares with them, and they can construct degree polynomial and evaluate it at to get the group key. Thus the members of group get the group key as , members of get the group key as , and is computed by members of as . Hence, user , for instance, can compute group keys for both the groups and .
5.3. Member Join Event
If a new user wants to join the group , it sends a join request to KDC. KDC finds a location for the user in the LKT of and inserts it. To provide backward access control, keys along the path from the point of insertion till one level below the root are changed and communicated to the corresponding users. In order to change the group key of , KDC picks a new value of group share (), encrypts it with the previous group key , and sends it to the users of the group . For the user , KDC sends keys along the path from to root, prepositioned shares (basic shares and group share) and AS after encrypting with the private key of . The new user constructs the polynomial and evaluates it at to get the group key .
For instance, if a new user sends a join request to join the group , KDC inserts at the location as shown in Figure 5. KDC changes the key to and picks a new value for group share, say (. To convey changed keys and share to corresponding users, KDC constructs the following rekey messages: .
Now, suppose that if user sends join requests to join two groups and , the LKT looks as in Figure 6 after inserting to both the groups of Figure 5. KDC constructs the following rekey messages to convey changed keys and group shares: KDC, KDCKDC, , KDCKDC, , .
If a member joins a group with members, then at most keys are changed. To convey changed keys to the members of the group, encryptions are performed and rekey messages are constructed. In general, if a member joins number of groups, keys are changed, encryptions are performed, and rekey messages are constructed.
5.4. Member Leave Event
A member may leave the group either voluntarily or KDC may forcibly expel the member from the group. In any case, the keys known to leaving member in the LKT must be changed to provide forward confidentiality. If a member wants to leave the group , it sends a leave request to KDC. Here, we encounter two cases.
Case 1. If belongs to only one group ,(i)KDC removes the corresponding user-node and private key-node from LKT, (ii)KDC changes the keys along the path from leaving point till one level below the root in selects new group share and conveys to corresponding users in .
Case 2. If belongs to more than one group, (i)KDC detaches from the group ,(ii)KDC changes the keys along the path from leaving point till one level below the root in selects new group share and conveys to corresponding users in .
For example, consider the multiple groups scenario as in Figure 6. Now, if user wants to leave the group , it sends a leave request to KDC. KDC detaches from the LKT of and changes the keys along the path as shown in Figure 7, and to convey changed keys it constructs the following rekey messages: , , .
If a member leaves the group , which contains members, then values are changed, number of encryptions are performed, and rekey messages are constructed to convey changed keys to the members of the group.
5.5. Member Moving from One Secure Group to Another
There are two cases.
Case 1. A member wants to move from group to the group .(i) sends a move request to KDC.(ii)This request is interpreted as member leave event for the group and member join event for group .(iii)KDC detaches from the LKT of the group .(iv)To provide forward access control for group , KDC changes the keys along the path from the leaving point till one level below the root in the LKT of group .(v)KDC inserts in LKT of the group .(vi)To provide backward access control in group , KDC changes the keys along the path from insertion point till the root in LKT of group .(vii)To change group keys of the groups and , KDC changes group shares () and (). (viii)KDC conveys securely changed keys and group shares to corresponding members of the groups and .
Case 2. A member wants to join the group .(i) sends a join request to KDC.(ii)KDC inserts in the LKT of group .(iii)To provide backward access control in group , KDC changes the keys along the path from insertion point till the root in the LKT of group .(iv)To change group key of , KDC changes group share (). (v)KDC conveys securely changed keys and group share to corresponding members of the group .
To illustrate the member-moving scenario, consider Figure 7 and assume that user wants to move from group to group . It sends to KDC the move request. KDC inserts in the group as shown in Figure 8 and changes the keys and in group and the keys , in group . It picks new values for group shares () and (), and, in order to convey changed keys and shares securely, it constructs the following rekey messages: , , .
Thus, when a member moves from one group with members to another group with members, keys are changed, encryptions are performed, and rekey messages are constructed.
If there are users in group , then the height of the LKT for is . A user of the group stores auxiliary keys, prepositioned shares and an . If a user is a member of number of groups, it needs to store auxiliary keys, prepositioned shares, and an AS. Thus, even though a particular user belongs to all the groups in the system, it needs to store at most elements from and can compute keys for all the groups.
We plot the graphs to depict the percentage of savings achieved in storage cost and encryption cost when compared to Dexter et al. scheme. The graph in Figure 9 shows the percentage of savings achieved in storage at KDC. It is plotted for different values of the security parameter . Figures 10 and 11 show the percentage of savings with users in different layers. They are plotted by keeping the value of as 5 and 10, respectively. From the graphs it is clear that the storage savings at KDC varies from % to % and with the users it varies from % to %. Figures 12 and 13 show the percentage savings in encryption cost that are plotted by keeping the value of as and , respectively. Savings in encryption cost vary from % to %, and it is observed that the the percentage of savings is proportional to the value of . As we move from lower layers to higher layers, the cost of savings decreases.
6. Authenticated Secure Group Communication
Once the groups are set up, members of the group can communicate with each other securely. When a member , of group , sends an encrypted message to members of , they must identify that the message is from and also if any other user tries to act as , others must identify that it is not . This section briefs about the authenticated secure group communication. Protocol in Table 3 depicts authenticated communication between group members. In the protocol, the symbol denotes concatenation, and denotes message encrypted with key .
If user , wants to send a message to group members, it sends a request to KDC. Request includes identity of , group number , and a time stamp value . KDC picks a random number from , applies hash function to compute , and broadcasts  after encrypting with group key , so that only the members of group can decrypt it. KDC sends , the message,  after encrypting it with the private key of . Thus, the value of is available only to . Now, in order to send a message, , constructs the message , encrypts it with the group key , and sends. Only members of group can decrypt it and apply hash function for the received value of to compute and verify that this value is same as the one received from KDC. If it is true, then they realize that the message is from as it is claimed; otherwise, they realize that some one else is trying to impersonate as .
Managing multiple groups with overlapped membership is one of the important issue in group communication scenario. In this paper we proposed a scheme for such hierarchical group key management using a combination of key-based and share-based approach. It is possible for the members at higher layers to compute the keys for its own layer along with all its descendant layers just by storing extra prepositioned information. Our scheme is secure, even if a member compromises, it is not possible to get the group key unless activating share is obtained. We reduce both storage and encryption cost compared to Dexter et al. scheme. We proposed two schemes for periodic rekeying.
Managing group keys for independent simultaneous secure groups is an important issue in SGC. In this paper we considered such multiple secure groups with overlapped membership and proposed a key management scheme using a combination of key-based and share-based approach. We showed that, even if a particular user belongs to all secure groups, it needs to store at most elements from and is able to compute keys for all the groups. Encryption cost and number of key changes are of the order of for membership changes (join, leave, and a member moving from one group to another). We also provided authentication for the messages communicated between group members.
L. R. Dondeti, S. Mukherjee, and A. Samal, “Survey and comparison of secure group communciation protocols,” Tech. Rep., University of Nebraska-Lincoln, 1999.View at: Google Scholar
T. Hardjono and G. Tsudik, “IP multicast security: issues and directions,” Annales De Taleum, vol. 55, no. 7, pp. 324–340, 2000.View at: Google Scholar
Y. Amir, C. Danilov, M. Miskin-Amir, J. Schultz, and J. Stanton, “The spread toolkit: architecture and performance,” Tech. Rep. CNDS-2004-1, Johns Hopkins University, 2004.View at: Google Scholar
C. K. Wong, S. S. Lam, and Keystone, “A group key management service,” in Proceedings of International Conference on Telecommunications, Acapulco, Mexico, May 2000.View at: Google Scholar
C. Blundo, A. de Santis, A. Herzberg, S. Kutten, U. Vaccaro, and M. Yung, “Perfectly secure key distribution for dynamic conferences,” in Advances in Cryptology-CRYPTO'92, vol. 740 of Lecture Notes in Computer Science, pp. 471–486, 1993.View at: Google Scholar
S. M. Iolus, “A framework for scalable secure multicasting,” in Proceedings of the ACM SIGCOMM, vol. 27, pp. 277–288, ACM, NewYork, NY, USA, September 1997.View at: Google Scholar
A. Fiat and M. Naor, “Broadcast encryption,” in Proceedings of 13th Annual International Cryptology Conference (CRYPTO '93), D. R. Stinson, Ed., pp. 480–491, August 1993.View at: Google Scholar
D. Wallner, E. Harder, and R. Agee, “Key Management for Multicast: Issues and Architectures,” Request For Comments (Informational) 2627, Internet Engineering Task Force, June 1999.View at: Google Scholar
A. M. Eskicioglu and M. R. Eskicioglu, “Multicast security using key graphs and secret sharing,” in Proceedings of the Joint International Conference on Wireless LANS and Home Networks and Networking, pp. 228–241, Atlanta, Ga, USA, August 2002.View at: Google Scholar
A. M. Eskicioglu, S. Dexter, and E. J. Delp, “Protection of multicast scalable video by secret sharing: simulation results,” in Security and Watermarking of Multimedia Content V, Proceedings of SPIE, Santa Clara, Calif, USA, January 2003.View at: Google Scholar
H. R. Hassan, A. Bouabdallah, H. Bettahar, and Y. Challal, “An efficient key management algorithm for hierarchical group communication,” in Proceedings of the 1st International Conference on Security and Privacy for Emerging Areas in Communications Networks (SECURECOMM '05), pp. 270–276, grc, September 2005.View at: Publisher Site | Google Scholar
Y. Sun and K. J. R. Liu, “Scalable hierarchical access control in secure group communications,” in Proceedings of 23rd Annual Joint Conference of the IEEE Computer and Communication Societies (INFOCOM '04), March 2004.View at: Google Scholar
Y. Sun and K. J. R. Liu, “Multi-layer key management for secure multimedia multicast communications,” in Proceedings of International Conference on Multimedia and Expo (ICME '03), July 2003.View at: Google Scholar
S. Dexter, R. Belostotskiy, and A. M. Eskicioglu, “Multi-layer multicast key management with threshold cryptography,” in Proceedings of the Security, Steganography and Watermarking of Multimedia Content VI, San Jose, Calif, USA, January 2004.View at: Google Scholar