136
CHAPTER 5
REKEYING PROCESS
5.1 INTRODUCTION TO REKEYING
Any member may leave or join the sub-group at any time.
Whenever there is any change in the number of members in a sub-group,
rekeying is done. In this section, the rekeying is discussed with respect to
single leave, single join, multiple leaves and multiple join situations in the
group. In the database of KGC/GC, the data of member is deleted and stored
in leaving member database as soon as the subscription span is finished.
The present research supports multiple join and leaves. At the
same time it ensures both forward and backward secrecies. The GK is
generated only once and it will not be changed even when member leaves and
joins occur and only the SGK will be changed during each leave and join
events. Further, the UIDs for the new members along with the public-private
key pair and signature will be generated and the complexities and the
overheads depend on the number of members present in the new sub-group.
5.1.1 Single-Member Join
The newly joined member will be given a new UID. The detail of
the newly joined member is stored in the existing member’s database at GC.
The process of key generation, signature generation, and communication can
then be done as explained in the previous sections.
137
Figure 5.1 SEKMS – Single Member Join
Let a new member m9,1 join the sub-group SGC1 (Figure 5.1), then
the Sub Group Controller 1 generates and assigns new User Identity for m9,1
i.e. UID9,1 which is stored in the offered member database at GC. The new
member may try to access the data exchanges before its joining. Here, GC has
the knowledge of the time subscription span of m9,1, so that it compares the
time of joining with the time of the data exchange when it is trying to access.
If the time does not fall under the member’s subscription span, the request is
rejected.
5.1.2 Multiple Joins
The member join under a particular sub-group depends on the
subscription span of a member. Backward secrecy strategy is maintained as
138
previously explained. When multiple members are to be joined, their
subscription span may fall under the same sub-group or different sub-groups.
5.1.2.1 Multiple joins in the same sub-group
Two or more members may join the same sub-group at the same
time. Let, members, m10,1 and m11,1 join SGC1 at the same time as shown in
the Figure 5.2.
Figure 5.2 SEKMS – Multiple joins in SGC1
SGC1 generates UIDs for the members and the UIDs and their
subscription spans are stored in the KGC/GC database. SGC1 generates a
new SGK1 and distributes to the members under it and the group key (GK) is
given to the member.
139
5.1.2.2 Multiple joins in different sub-groups
Two or more members may join the multicast group at the same
time. Let members m12,1 and m3,2 join the sub- groups SGC1 and SGC2 at the
same time as shown in the Figure 5.3.
Figure 5.3 SEKMS – Member Joins in SGC1 and SGC2
Both SGCs generate and distribute new UID for the newly joined
member and then send data about their UIDs and the subscription spans to the
GC which is stored in the database. The GC then generates and distributes the
new public-private key and signatures for the newly joined members.
5.1.3 Single-Member Leave
When a member’s subscription span is completed, the data about
this member in the database of KGC/GC is removed and inserted in the
140
leaving member’s database. The signatures, public-private keys and the group
key of the other members remain the same and only the sub-group key is
changed as explained in the previous sections.
In the Figure 5.4, member m4,1 (m4 of sub-group SGC1) leaves its
sub-group. Hence, the respective Sub-group Controller 1 generates a new
Sub-Group Key SGK1. All m4,1 member data is shifted to the leaving
member’s database for future reference.
Figure 5.4 SEKMS: Single-Member Leave
If the user wants to communicate with the current users/members
in the group, there are two cases as discussed below.
i) A member may try to communicate with the member in his
previous sub-group. In this case, the member should have the
valid sub-group key. However, GK is renewed as soon as the
member leaves the group. Hence, this communication fails.
141
ii) A member may try to communicate with a member in a sub-
group a than his previous sub-group. In this case, the member’s
request for communication should go through GC using UID.
The UID does not exist in database and hence the request is
rejected. Hence, forward secrecy is achieved in SEKMS. The
member who left the group can again join the same or other
group. However, the member is given new UID and the keys.
5.1.4 Multiple Leaves
If the time subscription span is completed for two or more
members at the same time, the data about these members are then deleted and
posted in the departure member’s database at GC. Hence, the forward secrecy
strategy is maintained. The multiple depart takes place from the same sub-
group or may be from a di erent sub-group.
5.1.4.1 Multiple leaves from the same sub-group controller
Two or more members leaving from the same SGC is shown, new
SGKs and the other procedures have been explained in the previous sections.
Let the members, m1,1 and m5,1, be the leaving-members as indicated in
the Figure 5.5.
142
Figure 5.5 SEKMS – Member-leaves from SGC1
If the number of members under SGC1 is changed, it gets the
partial keys from the currently available members and generates a new SGK1
and distributes it to the other members in the group.
5.1.4.2 Multiple leaves from different sub-groups
Whenever leave event takes place, the SGK will be changed for
each sub-group .Let m2,1 be the member leaving from SGC1 and m1,2 be the
member leaving from SGC2 as shown in the Figure 5.6.
143
Figure 5.6 SEKMS – Member-leaves from SGC1 and SGC2
SGC1 and SGC2 generate new SGKs like as SGK1 and SGK2 on
the notification of member leave and distributes to its respective members.
5.2 SYSTEM OPERATIONS AND WORKFLOW
Figure 5.7 SEKMS - Operations Involved
144
The Figure 5.7 shows the operations involved in each component of
the network in SEKMS. It indicates the following:
a) SGC and Members come under KGC/GC.
b) Members come under SGC based on their subscription span.
c) Each module shows the operations performed by these
components.
i) KGC: Its function is to collect each join requests along
with their subscription spans, assign each member to SGCs
with respect to their subscription spans. It collects partial
keys from each SGC and generates group key. It then
collects UIDs to generate public-private keys and
signatures. It also helps in transmitting data from one SGC
to the other.
ii) SGC: Its function is to generate UIDs using subscription
spans. Sub-group keys are generated using partial keys. It
helps in forwarding data in intra-cluster and inter-cluster
communications.
iii) Member: Its main function is to encrypt/decrypt the
messages sent/received.
d) The operations involve the input taken and the resulting output.
145
Figure 5.8 SEKMS – Flowchart
The workflow is as follows:
i) Member makes a join request to KGC and sends subscription
span along with request.
ii) KGC assigns the members to different SGCs based on their
subscription spans.
146
iii) SGC generate UID for each member.
iv) Members send partial keys to their SGCs.
v) SGCs use the partial keys received, adds their own partial
keys, generates sub-group keys and distributes to their
members.
vi) SGCs then send their partial keys to KGC.
vii) KGC uses the partial keys received, adds its own partial key,
generates group key and distributes to SGCs.
viii) SGCs forward group key to their members.
ix) SGCs send the UIDs of their members to KGC.
x) KGC generates public-private key and signatures for each
member and sends to SGCs.
xi) SGCs forward these keys and signatures to the respective
members.
xii) Once all the above processes are completed, members can
communicate with each other irrespective of their sub-
groups.
Algorithm 1 presents the overall procedure involved in the
proposed scheme. The algorithm shows the following steps:
First, the SGCs generate UIDs for each member under them.
These UIDs are sent to KGC/GC along with the partial keys.
Then, KGC/GC generates public-private keys pairs for each
member using their UIDs, the GK and hence, registers each
member.
147
KGC/GC distributes all the keys to the members using
proactive secret sharing scheme.
Member-leave and -join:
o The SGC function is done for the number of times equal
to the number of members left.
o The SGC and KGC/GC functions are repeated for the
number of times equal to the number of members joined.
The member functions are done when a member wants to
communicate with the other member.
Algorithm 1- SEKMS: A secure and e cient group key management scheme
in multicast networks
1: Begin
2: Si,j - signature of member i of the sub-group j
3: mi,j - member i of the sub-group j
4: SKi,j - session key of mi,j
5: n-number of members under a SGC
6: iLjf -partial keys of members
7: jKf -partial key of each sub-group under KGC/GC
8: GK-group key
9: SGK- sub-group key
10: at each SGC:
11: input: n, iLjf
12: output: UID of n members, SGK
13: repeat
14: apply Hu man coding technique to all UIDs
15: until all the member are assigned with UIDs
16: compute SGK using Eq. 1
148
17: distribute SGK using Proactive secret sharing
18: at KGC/GC:
19: input: n and subscription span of n members, UIDi,j , Kj
20: output: public and private keys, signatures, group key
21: compute GK using Eq. 2
22: repeat
23: apply RSA to obtain public and private keys for all the members
under each sub-group
24: use UIDs of each member to generate Si,j
25: distribute GK along with Si,j
26: until all the members get public-private keys, Si,j , and GK
27: if member leave then
28: if n = 1 then
29: go to step 18
30: end if
31: if n > 1 then
32: repeat
33: go to step 16 and 17
34: until all the members undergoes each step
35: end if
36: end if
37: if member join then
38: if n = 1 then
39: go to step 13 to 26
40: end if
41: if n > 1 then
42: repeat
43: go to step 13 to 26
44: until all the members undergoes each step
45: end if
149
46: end if
47: at members:
48: apply Eq. 5 to Eq. 10
49: repeat
50: compute SKi,j
51: until each mi,j gets own SKi,j
52: check Eq. 13
53: End
5.3 SIGNIFICANCE
This section covers the advantages that are obtained in SEKMS.
5.3.1 Communication Overhead
The packet sent contains the UID of the receiver, UID of the
sender, x and y values, and the timestamp. The SK is calculated and
exchanged by each communicating member. The actual data is then
exchanged. Hence, there are three types of messages exchanged between the
members. The first and the second message sizes are almost the same each
time, since they are the session keys and public-private keys. However, the
size of the actual data to be sent may vary for each session.
If the communication is between the members of different sub-
groups, then the ID of the SGC of the receiving members is also to be added
in the packet being sent which increases the size of the packet. Hence, the
communication overhead for the data exchange between different sub-groups
is more than to that within a sub-group. The session keys are generated by the
members, instead of KGC/GC being involved in session key generation and
distribution. Hence, the communication overhead on KGC/GC is reduced.
150
5.3.2 Computation Overhead
The computations involved in this scheme are shown in Section 3.
i) The KGC/GC acts only for the generation of public-private
key pair, signatures and the group key. The generation of
group key is done only once i.e. the group key will not change
even when there is a change in the number of members in a
group since it is independent of members in the group.
ii) The SGCs generate UIDs and SGKs.
iii) The proactive secret sharing scheme used for key distribution
is cost effective compared to Shamir’s secret sharing scheme.
iv) During the rekeying, KGC/GC and SGCs take part depending
upon different member-leave and join situations. The roles of
both are limited depending upon the need.
v) Once the group key is generated, it is not changed as the
number of sub-groups is constant.
5.3.3 Other Benefits
SEKMS achieves flexibility in the size of each sub-group i.e. any
number of members can be joined in SEKMS. Since the joining of a member
is based on the subscription span and whenever subscription span is
completed the member leaves the sub-group. The communication and key
distribution in SEKMS ensures the security of the message exchanged
between the members. Use of database for the current members in the group
and for the members left previously helps in achieving forward and backward
secrecies. It generates variable length UIDs and hence variable length
signatures and session keys.
151
When an intruder tries to access the information being exchanged,
it is difficult to obtain without the use of the required keys. In SEKMS, only
the communicating members know the sub-group keys, group keys, and other
necessary keys required for the decryption of the data received. Even if the
group key is static, the data cannot be accessed without the present sub-group
key and other keys as the session keys change for each communication. If the
intruder was the member under the group in the past, it cannot access the data
without its information being present in the database. Whenever a past
member or a newly joined member tries to access any information, it is
possible only if the session falls under their subscription span.
5.4 ANALYSIS AND COMPARISON
Before the UID generation under any Sub-group, the subscription
span of all the members willing to join the group initially are to be sorted in
an increasing order. A simple sorting operation requires minimum N number
of comparisons and maximum N2 where ‘N’ is the number of members.
Further, UIDs are generated using Modified Huffman Coding technique. It
operates in O(N log N) times. If the subscription spans are already sorted and
then this coding technique is applied, it operates in O (N) time where the
sorting takes O(N log N) times.
Let the number of Sub-Group Controllers (SGCs) under Group
Controller (GC) be C and the number of members under any SGC be Ni,
where, i=1,2…C. The GC uses the partial keys received from each SGC and
also its own partial key to generate GK and it takes O (log C+1) operations
for GK generation. In the same way, SGC uses partial keys of its members
and also its own to generate SGK. Hence, it takes O (log N+1) operations for
SGK generation.
152
SEKMS uses RSA concept for public-private key generation. If K
is the number of bits in modulus M, then public key operations take O (K2)
steps and private key operations take O (K3) steps.
Whenever a change occurs in the number of members under a sub-
group, it may be because of a member-leave or member-join. SEKMS
supports multiple join and leaves at the same time ensuring both forward and
backward secrecies. The group key once generated, will not be changed even
when leaves and joins occur. Only the cluster key will be changed during
leave and join events. Further, the UIDs for the new members along with the
public-private key pair and signature will be generated. Further, the
complexities and the overheads depend on the number of members present in
the new sub-group.
The first scheme in comparison to SEKMS is a one-way function
tree for key establishment in large dynamic groups in Wang et.al (2006).
There are several aspects in one-way function trees (OFT) compared to which
SEKMS performs better.
SEKMS prefers top-down approach achieving advantages in
both storage requirements and the key broadcasts. OFT can be
used for both top-down and bottom-up references, where the
former is used to reduce the storage requirement of information
and the latter is used to reduce rekeying broadcasts to about
log n keys.
OFT uses binary tree structure and assigns randomly chosen
keys for the users. SEKMS UID tree can accommodate new
nodes based on the subscription spans of the new user.
In OFT there is a split in the leaf node of the tree making room
for new member along with a change in the keys of the sharing
153
sibling along with a new member. In SEKMS, when a new
member joins, only the sub-group key of the other member
falling under the group is changed to ensure forward and
backward secrecies. All the other keys of the existing users
remain the same.
In OFT, when a member leaves, sibling of the leaving member
is reassigned with the new parent causing a change of the keys.
In SEKMS, when a member leaves, the siblings still remain
under the same parent and the sub-group controller causing
change in only the cluster key to ensure forward and backward
secrecies.
When compared to Logical Key Hierarchy (LKH), the following
points can be noticed.
In LKH, the degree of the LKH tree is constant and the number
of members under each sub-group is constant. In the case of
arrival of new members with time span falling under any sub-
group and the respective sub-group is full, it causes the
formation of new root node that results in the addition of new
sub-group and also the possibility of doubling the number of
members. In SEKMS, this is achieved with the constant number
of sub-groups. The usage of Modified Huffman Coding
technique helps the addition of new members in the same group
with the flexibility in the group size.
In LKH, the group key and all the other keys for the members
are regenerated at every member leave/join whereas in SEKMS,
the group key remains the same for any change in the number
of members and also ensures backward and forward secrecies
with the help of the databases used.
154
In LKH, each member stores the set of keys that stores the path
from the root node. Hence, key storage is O (log N+1) where N
is the sub-group size. In SEKMS a member uses the cluster key
and the session key for the communication.
SEKMS is also comparable to some of the other approaches. Vijay
Saradhi and Ravi Krishna (2009) have proposed Group Key Management
(GKM) approach for multicast cryptosystems. Srinivasan et al (2010)
presented a Secure Group Key management (SGK) for multicast networks,
and Pavithira and Purushothaman (2011) proposed an energy efficient
Topology Aware Key Management scheme (TAKM). Following are the
points noticed in comparison with these approaches:
PGKM operates on a static network structure with a limit on the
number of members under each controller. SGK uses a cluster-
based network structure with an equal number of members in
each cluster. The number of members is defined before dividing
the network into a cluster, in TAKM; the members are grouped
according to their physical distance. However, it may have a
disadvantage in grouping a single member who is existing in a
farther distance from the majority of members. In SEKMS, the
network structure is dynamic i.e. the number of members under
each sub-group differs depending upon the number of join
eventually occurring in the network.
PGKM uses Chinese Remainder Theorem and a hierarchical
graph. Hence, each member contains a key and a modulus. In
TAKM all the members compute their group key i.e. group key
generation is the responsibility of the members. In SGK, since
it uses CRT, the sub-group controller has to compute the
common solution X which again has to be multicast to all the
155
members under it. In SEKMS, generation of group key is done
by the group controller and only once. There is less
computation overhead on the members compared to the other
approaches.
In addition, the key storage value at server in PGKMP is 2n-1
and at member is log 2n+1 which is n+1 and 3 respectively for
SEKMS.
5.5 RESULTS AND DISCUSSION
Experiments have been simulated in NS2 simulator for various
cases discussed in the previous sections and the following complexity
analyses are given based on the results obtained. In this thesis, we focused on
secure multicast protocol communication. By working on NS2 simulator, we
achieved 90 percentage of efficiency and ensured secure group
communication within the network. This concept can also be implemented in
JAVA, J2ME to enhance more security.
i) Communication cost
ii) Computation cost
iii) Number of messages needed during rekeying
iv) Key storage cost
SEKMS is compared to LKH and OFT and the following results
are obtained.
5.5.1 Communication Cost
Whenever a member leaves or joins, there is a change in the
database which is notified to the sub-group controller once for each change.
Hence, only one message is sufficient for any change in the network. The
156
number of messages exchanged at any change in a group is 1. It contains data
about the members left/joined and the current status of the sub-group. The
computation cost then goes up to O (1) for SEKMS. The Table 5.1 presents
the communication costs of the other approaches compared to SEKMS.
Table 5.1 Communication Cost
Protocol Join LeaveOFT log2 n+1 log2 n+1LKH 2 log2 n-1 log2 n
SEKMS 1 1
Figures 5.9 and 5.10 shows the graphical representation of the
above analytical measures.
Figure 5.9 Communication Cost at Joins
157
Figure 5.10 Communication Cost at Leaves
5.5.2 Computation Cost
Like all the other approaches, there is a rekeying process in
SEKMS, except that the group key remains the same for any change in the
number of members along with the necessary ensuring securities. The
rekeying is done only in the sub-group where the change takes place. The
Table 5.2 gives a brief comparison of the computation costs for group key
generation of OFT, LKH and SEKMS for a single member join and leave.
The Figures 5.11 and 5.12 gives the statistical comparison. In SEKMS, the
group key is not changed once it is generated. Whereas, in OFT and LKH, the
group key is regenerated every time there is a change in the number of users.
Here, m, is the sub-group size and n is the group size. When a
member joins the group, the sub-group key is regenerated along with the UID,
Public-private keys pair and signature. For each newly joining member three
new keys and one UID is generated. If there are n members joining at the
same time, then 4n computations are done. Here n is a constant for any
158
number of members since it depends only on the members joining or leaving
but not on the members in the sub-group.
Table 5.2 Computation Cost
Protocol Join LeaveOFT log2 n+1 log2 n+1LKH 2 log2 n-1 2log2 n
SEKMS 1 1
Whenever a member leaves the group, only the SGK is regenerated.
Hence, if n members are leaving the group, n times the SGK is generated. If
they leave at the same time, only one SGK is regenerated. If joining and
leaving occurs at the same time, the number of computations done is only
one.
Figure 5.11 Computation Cost at Joins
159
Figure 5.12 Computation Cost at Leaves
5.5.3 Number of Rekey Messages
The number of computations, whenever a member joins or leaves
given in section 5.4. The comparison of the number of rekey messages at a
single join and leave is given in the Table 5.3. The Figures 5.13 and 5.14
show the graphical representation.
Table 5.3 Number of Rekey Messages Needed
Protocol Join LeaveOFT n+1 n+1
LKH n+1 2nSEKMS 4 1
160
Figure 5.13 Rekey Messages at Joins
Figure 5.14 Rekey Messages at Leaves
161
5.5.4 Key Storage at Join and Leave
For the group size of n, the key storage is given in the Table 5.4. In
SEKMS, a member stores just three keys but the KGC/GC (server) stores
n+ 1 key. The Figures 5.15 and 5.16 show the graphical representation.
Table 5.4 Key Storage at Jo in and Leave
Protocol Join LeaveOFT 2n 2 log2 n+1
LKH 2n log2 n+1
SEKMS n+1 3
Figure 5.15 Key Storage at Joins
162
Figure 5.16 Key Storage at Leaves