Key Management Schemes for Multilayer and Multiple Simultaneous Secure Group Communication

Abstract

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.

1. Introduction

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 [7] 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, (𝑡+1) shares of the polynomial are required, and this (𝑡+1)th 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 3 quality levels: basic quality level, medium quality level, and best quality level. Here, the users can be classified into 3 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 [18]. 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 [21] 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 (𝑡+1)th 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 [18], 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 𝐻²(𝐾).

In [19, 20], Sun and Liu used tree-based hierarchical approach to handle broadcasting multimedia applications in different layers to different groups of users.

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, 1≤𝑖,𝑗≤𝑀. 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, 𝑖=1,2,…,𝑀.

Figure 1 

Subgroups arranged into different privilege layers.

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 [21], integrated key graph as in [19, 20] is used, but for key management it uses share-based scheme. The key management scheme proposed in [21] is explained as follows: (1)KDC fixes the security parameter 𝑡,(2)KDC constructs a Logical Key Tree (LKT) as in [7] for the subgroup 𝑃_𝑖 at layer 𝑖. For a secure group with 𝑆_𝑖 users, there are at most 2𝑆_𝑖−1 nodes in LKT and the height of the LKT, is ⌈log₂𝑆_𝑖⌉,(3)for each node in LKT of subgroup 𝑃_𝑖, KDC selects randomly 𝑡−1 number of distinct points (𝑥^𝑖𝑘𝑗,𝑦^𝑖𝑘𝑗) in GF(𝑝) (where GF refers to Galois Field) called prepositioned shares, 𝑖∈{1,2,…,𝑀}, 𝑗=1,2,…,𝑡−1, 𝑘=1,2,…,2𝑆_𝑖−1. To each user 𝑢∈𝑃_𝑖, KDC sends securely (𝑡−1)log₂𝑆_𝑖 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 log₂𝑆_𝑖 number of polynomials of degree (𝑡−1) using the corresponding shares it has received from KDC and AS, 𝑖=1,2,…,𝑀 and evaluates each polynomial at 0 to get the keys, and(6)KDC also constructs polynomial of degree (𝑡−1) for each node 𝑘 in the LKT of 𝑃_𝑖 using the 𝑡−1 points (𝑥^𝑖𝑘𝑗,𝑦^𝑖𝑘𝑗) and AS and evaluates at 0 to get the corresponding key for that node.

In this scheme, each key is computed by constructing a 𝑡−1 degree polynomial using 𝑡−1 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 [22]. 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 𝑡−1 number of points (𝑥_𝑖,𝑦_𝑖) in GF(𝑝) called prepositioned shares, 𝑖=1,2,…,𝑡−1 and an activating share (AS) and sends securely to the members of all the subgroups 𝑃₁,𝑃₂,…,𝑃_𝑀,(2)KDC constructs LKT for the subgroup 𝑃₁ at layer 1 with the subgroup key 𝐺₁. The key 𝐺₁ is obtained by constructing a polynomial 𝑃(𝑥) of degree 𝑡−1 using the 𝑡−1 points (𝑥_𝑖,𝑦_𝑖) and AS and evaluating at 0 to get 𝐺₁=𝑃₁(0). 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 𝑃_𝑗,𝑃_𝑗+1,…,𝑃_𝑀, 𝑗=2,3,…,𝑀, and(4)KDC constructs LKT for the subgroup 𝑃_𝑗 at layer 𝑗 with the subgroup key 𝐺_𝑗. The key 𝐺_𝑗 is obtained by constructing a polynomial 𝑃_𝑗(𝑥) of degree 𝑡+𝑗−2 using 𝑡−1 prepositioned shares, AS, and 𝑗−1 group shares (𝑥𝑔_𝑙,𝑦𝑔_𝑙), 𝑙=2,3,…,𝑗 and 𝑗=2,3,…,𝑀. It evaluates the polynomial 𝑃_𝑗 at 0 to get 𝐺_𝑗=𝑃_𝑗(0). 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 2 

Hierarchical key tree structure for multilayer secure group communication 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.

Figure 3 

An example integrated key graph with auxiliary keys and group keys.

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, 𝑢_new, joins any layer 𝑖, 𝑖=1,…,𝑀, 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 𝑖+1 to 𝑀 change the group key 𝐺_𝑖 by applying one-way hash function to previous group key 𝐺_𝑖. For the new user, 𝑢_new, KDC sends 𝑡−1 prepositioned shares (𝑥_𝑖,𝑦_𝑖), auxiliary keys of 𝑃_𝑖 along the path to where 𝑢_new is inserted, and group key 𝐺_𝑖 and 𝑖 group shares (𝑥𝑔_𝑖,𝑦𝑔_𝑖) by encrypting with the private key of 𝑢_new, 𝑖=1,2,…,𝑀.

3.2. Member Leave Event

If a member at layer 𝑖 leaves, 𝑖=1,2,…,𝑀, 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 𝐺₁,𝐺₂,…,𝐺_𝑖−1 of layers from 1 to 𝑖−1.

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 0, 𝑗=1,2,…,𝑖.

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)  KDC→{𝑢₁to𝑢₄}∶{AS}_𝐾1−4 KDC→{𝑢₅,𝑢₆}∶{AS}_𝐾^′5−8,{𝐾^5−8}_𝐾5−6 KDC→𝑢₇∶{AS}_𝐾^′5−8,{𝐾^5−8}_𝐾^′7−8,{𝐾^7−8}_𝐾7 KDC→{𝑢₉to𝑢₁₄}∶{AS}_𝐺2  KDC→{𝑢₁₇to𝑢₁₉}∶{AS}_𝐺3.

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 (𝑖+1) to 𝑗. To provide backward confidentiality for the messages communicated in the subgroups from 𝑖+1 to 𝑗, group share (𝑥𝑔_𝑘,𝑦𝑔_𝑘) of the group 𝑃_𝑘 is changed, 𝑘=𝑖+1,𝑖+2,…,𝑗. KDC generates group share (𝑥𝑔_𝑘,𝑦𝑔_𝑘) and encrypts with the previous group key 𝐺_𝑘 and sends to members of the group 𝑃_𝑘, 𝑘=𝑖+1,𝑖+2,…,𝑗.

Case 2. If a member moves from layer 𝑖 to its descendant layer 𝑗, (𝑖<𝑗), then group shares of layers from (𝑖+1) 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 1 of LKT of subgroup 𝑃_𝑘, 𝑘=𝑖+1,𝑖+2,…,𝑗.

Example 1. In Figure 3, if a member 𝑢₁₂ moves from layer 2 to layer 3, 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:  KDC→{𝑢₁₇,𝑢₁₈}∶{(𝑥𝑔₃,𝑦𝑔₃)}_𝐺3,AS KDC→𝑢₁₉∶{(𝑥𝑔₃,𝑦𝑔₃)}_𝐺3,{𝐾^19−20}_𝐾19,AS KDC→𝑢₁₂∶{(𝑥𝑔₃,𝑦𝑔₃),𝐾^19−20}_𝐾12,AS KDC→{𝑢₉,𝑢₁₀}∶{𝐾^9−16}_𝐾^′9−12,{𝐾^9−12}_𝐾9−10 KDC→𝑢₁₁∶{𝐾^9−16}_𝐾^′9−12, [𝐾^9−12]_𝐾^′11−12, {𝐾^11−12}_𝐾11 KDC→{𝑢₁₃,𝑢₁₄}∶{𝐾^9−16}_𝐾13−16.

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 1 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.

4. Comparison

Storage at Each User
In Dexter et al. scheme [21], each user 𝑢∈𝑃_𝑖 stores the shares of the keys along the path from leaf to the root, 𝑖=1,2,…,𝑀. If there are 𝑆_𝑖 users in 𝑃_𝑖, then height of the tree is ⌈log₂𝑆_𝑖⌉. Thus each user 𝑢∈𝑃_𝑖 stores (𝑡−1)⌈log₂𝑆_𝑖⌉ number of elements.
In our scheme, each user 𝑢∈𝑃_𝑖 stores (𝑡−1) prepositioned shares, an activating share, 𝑖 number of group shares and ⌈log₂𝑆_𝑖⌉ 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 2𝑁−1 nodes. Thus, storage required at KDC in Dexter et al. scheme is (𝑡−1)(2𝑁−1). In our scheme there are 𝑡+𝑀−1 shares and 2𝑁−𝑀−1 auxiliary keys in the system. Hence KDC is required to store only 2𝑁+𝑡−2 elements.

Encryption Cost
In Dexter et al. scheme, if a member leaves any layer 𝑖, 𝑖=1,…,𝑀, in order to change the keys along the path till the root, corresponding prepositioned shares must be changed, which leads to (𝑡−1)⌈log₂𝑆_𝑖⌉ encryptions. Also, prepositioned shares meant for different layers must be changed, which results in (𝑡−1)𝑖 encryptions. Hence, the number of elements encrypted is (𝑡−1)(⌈log₂𝑆_𝑖⌉+𝑖). Whereas in our scheme, keys along the path and an activating share are encrypted; thus, it is just (⌈log₂𝑆_𝑖⌉+𝑖𝑡) encryptions.

Computation Cost
In Dexter et al. scheme [21], the group key for each layer 𝑖 is computed by constructing a (𝑡−1) degree polynomial and evaluated at 0. In our scheme, as we move up the hierarchy, degree of the polynomial is incremented by 1. Though it requires more amount of computation as compared to (𝑡−1) degree polynomial, it improves the resistance of the system to attack; hence, the system is more secure.

Table 1 gives the comparison of our scheme with the scheme proposed by Dexter et al. [21] in terms of storage and encryption cost.

Table 1 

Comparison of storage and encryption cost.

Table 2 compares the performance of our scheme with Dexter et al. scheme [21]. To have fair comparison we consider 4 layers 𝑁₁, 𝑁₂, 𝑁₃, and 𝑁₄ and a polynomial of degree 5, that is, 𝑡−1=5. 𝑁₁ is the layer at lower privilege level, and 𝑁₄ is at higher privilege level.

Table 2 

Performance of multilayer SGC.

Consider an example with 128 users at layer 𝑁₁, 64 users each at layers 𝑁₂ and 𝑁₃, and 32 users at layer 𝑁₄. Heights of the trees at layers 𝑁₁, 𝑁₂, 𝑁₃, and 𝑁₄ are 7, 6, 6, and 5, respectively. Number of keys stored at KDC in Dexter et al. scheme is (𝑡−1)(2𝑁−1) at each layer which sums up to be 2860, whereas in our scheme we get only 588 keys at the KDC which is computed as 2𝑁+𝑡−2.

In Dexter et al. scheme, users at layer 𝑁₁ store ℎ₁+𝑖=7+1 sets of prepositioned information, namely, 8∗5=40 keys. Users at layer 𝑁₂ store 6+2=8 sets of prepositioned information, users at layer 𝑁₃ store 6+3=9 sets of prepositioned information, and users of layer 𝑁₄ store 5+4=9 sets of prepositioned information. In our scheme, the number of keys at different layers 𝑁₁, 𝑁₂, 𝑁₃, and 𝑁₄ is only 12, 12, 13, and 13, 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 4096 users and with a fixed security parameter 𝑡=10, we achieve 80% savings in storage at KDC and about 73% 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 [23].

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, 𝑖=1,2,…,𝑀. 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 ℎ_𝑖=⌈log₂𝑁_𝑖⌉. An user 𝑢_𝑖 is assigned with a private key 𝐾_i, 𝑖=1,2,…,𝑁 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 [7]. 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 𝑢_𝑖, 𝑖=1,2,…,𝑁 who would like to join the group 𝑃_𝑗, 𝑗=1,2,…,𝑀 sends a join request to KDC. The KDC generates and sends a unique private key 𝐾_𝑖, 𝑖=1,2,…,𝑁 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 𝑡−2 number of points (𝑥_𝑖,𝑦_𝑖) in GF(𝑝) called prepositioned basic shares, 𝑖=1,2,…,𝑡−2 and (𝑥_𝑡,𝑦_𝑡) as activating share (AS). These shares are sent securely to the members of all the subgroups 𝑃₁,𝑃₂,…,𝑃_𝑀.(3)KDC selects randomly 𝑀 points (𝑥𝑔_𝑖,𝑦𝑔_𝑖) in GF(𝑝) called prepositioned group shares distinct from the previously selected points and sends (𝑥𝑔_𝑖,𝑦𝑔_𝑖) securely to the members of the subgroup 𝑃_𝑖, 𝑖=1,2,…,𝑀.(4)KDC constructs LKT for the group 𝑃_𝑖 with the group key 𝐺_𝑖. The key 𝐺_𝑖 is obtained by constructing a polynomial 𝑃_𝑖(𝑥) of degree 𝑡−1 using the shares (𝑥_𝑖,𝑦_𝑖) of step 2 and the prepositioned group share (𝑥𝑔_𝑖,𝑦𝑔_𝑖). The group key is 𝐺_𝑖=𝑃_𝑖(0), 𝑖=1,2,…,𝑀. 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 (1≤𝑗≤𝑀), it is provided with (𝑡−2) prepositioned basic shares along with AS and 𝑗 number of prepositioned group shares. It constructs 𝑗 distinct polynomials. A polynomial 𝑃_𝑘(𝑥) is constructed by using 𝑡−1 shares of step 2 and prepositioned group share (𝑥𝑔_𝑘,𝑦𝑔_𝑘), 𝑘=1,2,…,𝑗. Thus, it can construct 𝑗 distinct polynomials just by using one distinct group share.

Figure 4 shows an example key tree structure with 3 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.

Figure 4 

Key tree structure for multiple groups.

For example, let us consider 𝑡=4,  𝑝=41 and the (𝑡−2) prepositioned basic shares as (1,28), (2,23) and AS as (4,4). Assume that KDC sends (3,11), (3,8), and (3,5) as the prepositioned group share for the members of the groups 𝑃₁,𝑃₂, and 𝑃₃, respectively. Hence, the members of the group 𝑃_𝑖, 𝑖=1,2,3, now possess 𝑡; that is, 4 shares with them, and they can construct (𝑡−1) degree polynomial and evaluate it at 0 to get the group key. Thus the members of group 𝑃₁ get the group key 𝐺₁ as 14, members of 𝑃₂ get the group key 𝐺₂ as 2, and 𝐺₃ is computed by members of 𝑃₃ as 34. Hence, user 𝑈₅, for instance, can compute group keys for both the groups 𝑃₁ and 𝑃₃.

5.3. Member Join Event

If a new user 𝑢_new wants to join the group 𝑃_𝑖 (1≤𝑖≤𝑀), it sends a join request to KDC. KDC finds a location for the user 𝑢_new 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 𝑢_new, KDC sends keys along the path from 𝑢_new to root, prepositioned shares (basic shares and group share) and AS after encrypting with the private key of 𝑢_new. The new user constructs the polynomial and evaluates it at 0 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 𝐾^1417 and picks a new value for group share, say (𝑥𝑔^3,𝑦𝑔^3). To convey changed keys and share to corresponding users, KDC constructs the following rekey messages:  KDC→{𝑢₁₄,𝑢₁₅}∶{𝐾^1417}_𝐾1415,{(𝑥𝑔^3,𝑦𝑔^3)}_𝐺3 KDC→{𝑢₅,𝑢₁₁,𝑢₁₂,𝑢₁₃}∶{(𝑥𝑔^3,𝑦𝑔^3)}_𝐺3 KDC→{𝑢₁₆}∶{𝐾₁₆₁₇,𝐾^1417,(𝑥𝑔^3,𝑦𝑔^3)}_𝐾16.

Figure 5 

Key tree structure for multiple groups after user 𝑢16 joins the group 𝑃3.

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→{𝑢₁₄,𝑢₁₅}∶{𝐾^1417}_𝐾1415,  {(𝑥𝑔^3,𝑦𝑔^3)}_𝐺^′3KDC→{𝑢₅,𝑢₁₁,𝑢₁₂,𝑢₁₃}∶{(𝑥𝑔^3,𝑦𝑔^3)}_𝐺^′3KDC→{𝑢₁₆}∶{𝐾^1417}_𝐾^′1417,  {𝐾^1417}_𝐾16,  {(𝑥𝑔^3,𝑦𝑔^3)}_𝐺^′3KDC→{𝑢₆,𝑢₈,𝑢₉,𝑢₁₀}∶{𝐾₆₁₀,(𝑥𝑔^2,𝑦𝑔^2)}_𝐺2KDC→{𝑢₁₇}∶{𝐾₁₇₋₂,𝐾₁₇₋₁, 𝐾^1617,𝐾^1417, (𝑥𝑔^3,𝑦𝑔^3)}_𝐾17.

Figure 6 

Key tree structure for multiple groups after user 𝑢17 joins the groups 𝑃2 and 𝑃3.

If a member joins a group 𝐺_𝑖 with 𝑁_𝑖 members, then at most ⌈log₂𝑁_𝑖⌉ keys are changed. To convey changed keys to the members of the group, ⌈2log₂𝑁_𝑖⌉ encryptions are performed and ⌈log₂𝑁_𝑖⌉ rekey messages are constructed. In general, if a member joins 𝑗 number of groups, ∑^𝑗𝑖=1log₂𝑁_𝑖 keys are changed, 2∑^𝑗𝑖=1log₂𝑁_𝑖 encryptions are performed, and ∑^𝑗𝑖=1log₂𝑁_𝑖 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 𝑃_𝑖 (1≤𝑖≤𝑀), 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:  KDC→{𝑢₁₄,…,𝑢₁₇}∶{(𝑥𝑔^3,𝑦𝑔^3)}_𝐾^{𝐾′′1417} KDC→{𝑢₁₂,𝑢₁₃}∶{(𝑥𝑔^3,𝑦𝑔^3)}_𝐾1113,{𝐾₁₁₁₃}_𝐾1213 KDC→𝑢₁₁∶{(𝑥𝑔^3,𝑦𝑔^3)}_𝐾1113, {𝐾₁₁₁₃}_𝐾11−1, {𝐾₁₁₋₁}_𝐾11.

Figure 7 

Key tree structure for multiple groups after user 𝑢5 leaves the group 𝑃3.

If a member leaves the group 𝑃_𝑖, which contains 𝑁_𝑖 members, then ⌈log₂𝑁_𝑖⌉ values are changed, ⌈2log₂𝑁_𝑖⌉ number of encryptions are performed, and ⌈log₂𝑁_𝑖⌉ 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 𝑢_new 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:  KDC→{𝑢₁,𝑢₂}∶{𝐾₁₃}_𝐾12,{(𝑥𝑔^1,𝑦𝑔^1)}_𝐾13 KDC→𝑢₃∶{𝐾₁₃}_𝐾3−1,{𝐾₃₋₁}_𝐾3,{(𝑥𝑔^1,𝑦𝑔^1)}_𝐾13 KDC→{𝑢₅,𝑢₇}∶{(𝑥𝑔^1,𝑦𝑔^1)}_𝐾58 KDC→{𝑢₆,𝑢₈}∶{(𝑥𝑔^1,𝑦𝑔^1)}_𝐾58,{(𝑥𝑔^2,𝑦𝑔^2)}_𝐺^′2 KDC→{𝑢₉,𝑢₁₀}∶{(𝑥𝑔^2,𝑦𝑔^2)}_𝐺^′2 KDC→𝑢₁₇∶{𝐾₄₁₇₋₂}_𝐾417−1, {𝐾₄₁₇₋₁}_𝐾17, {(𝑥𝑔^2,𝑦𝑔^2)}_𝐺^′2 KDC→𝑢₄∶{𝐾₄₁₇₋₂}_𝐾417−1,{𝐾₄₁₇₋₁,(𝑥𝑔^2,𝑦𝑔^2)}_𝐾4.

Figure 8 

Key tree structure for multiple groups after user 𝑢4 moves from group 𝑃1 to group 𝑃2.

Thus, when a member moves from one group with 𝑁_𝑖 members to another group with 𝑁_𝑗 members, ⌈log₂𝑁_𝑖+log₂𝑁_𝑗⌉ keys are changed, ⌈2(log₂𝑁_𝑖+log₂𝑁_𝑗)⌉ encryptions are performed, and ⌈log₂𝑁_𝑖+log₂𝑁_𝑗⌉ rekey messages are constructed.

5.6. Storage

If there are 𝑁_𝑖 users in group 𝑃_𝑖, then the height of the LKT for 𝑃_𝑖 is ⌈log₂𝑁_𝑖⌉. A user 𝑢 of the group 𝑃_𝑖 stores ⌈log₂N_𝑖⌉−1 auxiliary keys, (𝑡−1) prepositioned shares and an AS. If a user 𝑢 is a member of 𝑗 number of groups, it needs to store ∑^𝑗𝑖=1(⌈log₂N_𝑖⌉−1) auxiliary keys, (𝑡−2+𝑗) 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 ∑^𝑀𝑖=1⌈log₂N_𝑖⌉+𝑡−2 elements from GF(𝑝) 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 75% to 95% and with the users it varies from 68% to 73%. Figures 12 and 13 show the percentage savings in encryption cost that are plotted by keeping the value of 𝑡 as 5 and 10, respectively. Savings in encryption cost vary from 45% to 85%, 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.

Figure 9 

Storage cost: percentage savings at the KDC.

Figure 10 

Storage cost: percentage savings at the users with 𝑡=5.

Figure 11 

Storage cost: percentage savings at the users with 𝑡=10.

Figure 12 

Encryption cost: percentage savings with 𝑡=5.

Figure 13 

Encryption cost: percentage savings with 𝑡=10.

6. Authenticated Secure Group Communication

Once the groups are set up, members of the group can communicate with each other securely. When a member 𝑢_𝑖, 𝑖=1,…,𝑁 of group 𝑃_𝑗, 𝑗=1,…,𝑀 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 𝐾.

Table 3 

Protocol for authenticated secure group communication.

If user 𝑢_𝑖, 𝑖=1,…,𝑁 wants to send a message to group members, it sends a request to KDC. Request includes identity ID_𝑖 of 𝑢_𝑖, group number 𝑃_𝑗, 𝑗=1,…,𝑀 and a time stamp value 𝑇. KDC picks a random number 𝑟 from GF(𝑝), applies hash function to compute 𝐻(𝑟), and broadcasts [𝐻(𝑟)‖ID_𝑖‖𝑃_𝑗‖𝑇] 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 [𝑟‖ID_𝑖‖𝑃_𝑗‖𝑇‖𝑚], 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 𝑢_𝑖.

7. Conclusion

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 (𝑀ℎ+𝑡−2+𝑀) elements from GF(𝑝) and is able to compute keys for all the groups. Encryption cost and number of key changes are of the order of log𝑁 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.