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