26

CHAPTER 2

STATE OF ART

2.1 INTRODUCTION

This chapter discusses the architecture of IPTV and elaborately

explains the existing secure ways of broadcasting the multimedia contents in

IPTV along with its pros and cons. Though the architecture of IPTV remains

constant, the broadcasting technique varies because of the security

mechanisms adopted by the broadcast server. IP multicast reduces the

bandwidth usage considerably by transmitting a single IP packet to multiple

receivers by enabling some nodes in the network to create multiple instances

of the same message. Secure multicasting, broadcasts the multimedia contents

only to the authorized subscribers.

Secure multicasting (Christos & Dimitrios N Serpranos 2007) is

the group transmission technique that enforces confidentiality. Confidentiality

of the group is by encrypting the contents intended for the group with a

common shared secret among the members and transmitting them. At the time

of reception, the group members should decrypt the message with the shared

secret used for encryption. A secure multicast architecture needs to consider

the size of the group, group membership and the various keys used for

ensuring confidentiality (Meissner et al 2004). The challenging task in the

secure group communication is the management of the common shared secret

called as group key or session key. Since group membership is dynamic, the

group key should be updated to maintain the confidentiality of the group

27

communication. The next section presents the overview of the IPTV

architecture and the various standard algorithms of group key management

(Shu-Quan Li & Yue Wu 2010).

2.2 ARCHITECTURE OF IPTV

A typical functional architecture of IPTV(Zeadally et al 2011)

comprises of six main components as shown in Figure 2.1.

Figure 2.1 Functional architecture of IPTV service

2.2.1 Content Provision

The multimedia contents included will pass through the content

provisioning function where the encoding (ingest, transcoder, encoder)

functions will prepare digital video streams, capable of being distributed via

the IP network. Within this function, content will also be modified to include

security elements such as DRM encryption elements.

Security Functions IPTV Control Functions

Content Delivery Functions

Content Provisioning

Functions

IPTV Transport Functions

28

2.2.2 Content Delivery

The content delivery block includes the functions responsible for

delivering the encoded streams to the appropriate subscriber. When subscriber

functions interact with IPTV control functions to request specific contents,

they will be redirected to the content delivery function to obtain access to the

stream.

2.2.3 IPTV Control

The IPTV control functions are the heart of the service. They are

responsible for linking all other functions and ensure that the service is

operational at the appropriate levels to guarantee customer satisfaction. From

a security point of view, the IPTV control function is important because it acts

as the gateway for subscribing requesting contents and it coordinates flows of

data among components. Intruders could cause a denial of service (DOS)

situation if they managed to damage the middleware or other critical

components of this function.

2.2.4 IPTV Transport Functions

This is used to transport the multimedia contents with the help of

DSLAM and VLANs.

2.2.5 Subscriber Functions

The subscriber functions include different actions and elements that

are used by subscribers to have access to IPTV contents. It will also receive

the digital licenses and DRM keys to access contents. To create the expected

output, contents are decoded and displayed.

29

2.2.6 Security

All the functions within the IPTV model are supported by security

mechanisms at different levels. Content provisioning will include basic

encryption provided by content owners. Group communication service plays a

major role to ensure secure multicasting of multimedia contents through DRM

system (Yuan Zhang et al 2011). The IPTV control and transport functions

will rely on standards with embedded security to avoid unauthorized

modification or access to contents. In general, all applications and operating

systems within the IPTV environment should have security mechanisms

available to avoid security incidents (Maria et al 2011).

2.3 SECURE MULTICAST

Secure multicasting is an efficient mechanism for group-oriented

applications like video conferencing, interactive group games, e learning, and

IPTV (Eskicioglu AM 2003). Since the router does not maintain any host

information, IP Multicast is scalable which makes it attractive for any group-

oriented applications. IP Multicast uses two types of protocols: Group

management protocols and Multicast routing protocols. Members to join or

leave from the multicast group use group management protocols. Multicast

routing protocols allow routers to define the links through which the data is to

be forwarded. Figure 2.2 shows the skeleton of basic multicast transmission

along with its required elements.

30

Figure 2.2 Elements of IP Multicast

Though the strength of multicast remains in its simplicity, it

involves many security threats like,

1. Closed groups are not supported by IP Multicast. Multicast

address is publically known and does not impose any constrains

on join as well as leave. Hence, any user can join into the

multicast group and listen for the transmission and can leave at

any time.

2. Even an invalid user can also send data to the multicast group.

Multicast group lacks in access control, which can lead to

denial of service attack.

3. Multicast data are transported via unsecure channel, which may

invoke eavesdropping.

Figure 2.3 portrays the various threats and solutions of multicast

security.

31

Figure 2.3 Multicast security threat and solutions

2.4 SECURITY REQUIREMENTS OF GROUP

COMMUNICATION

A group key management protocol helps to ensure that only

members of a secure group can gain access and authenticate group data. The

main goal of the group key management protocol is to provide legitimate

group members with up-to-date cryptographic state that they need for secrecy

and authentication. (Matthew J Moyer et al 1999) Multicast applications, such

as video broadcast and multicast file transfer, typically have the following key

management requirements (Baugher et al 2005). This requirement list is

neither applicable to all applications nor exhaustive.

1. Group members receive security association (SA) that includes

encryption keys, integrity keys and cryptographic policy.

2. Keys should have well defined lifetime.

3. For improved security keys may be periodically refreshed.

Security

Multicast

Denial of Service Eavesdropping Masquerading Leaking

Access Control Confidentiality Data Origin Authentication

Watermarking

Security Threats

32

4. Key management protocol should be secure against attacks

such as replay , denial of service and so on.

5. The key management protocol should offer a framework for

replacing or renewing transforms, authorization infrastructure

and authentication systems.

2.5 TAXONOMY OF KEY MANAGEMENT SCHEMES

Group key management is an important functional building block

for any secure multicast architecture (Sakarindr & Ansari 2010). In this

section, the relevant group key management protocols are discussed and

compared against some pertinent performance criteria. Figure 2.4 depicts the

categories of group key management.

Figure 2.4 Categories of group key management

Centralized Decentralized Distributed

Group Key Management

1. Pair wise Keys 2. Broadcast Keys 3. Keys Hierarchy

1. Membership Driven rekeying

2. Time Driven Rekeying

1. Pair wise Keys 2. Broadcast Keys 3. Keys Hierarchy

33

2.6 CENTRALIZED KEY MANAGEMENT SCHEME

In a centralized system, only one entity named as Group Controller

(GC) controls the whole group. The storage requirements, computational

power on group members and controller, and bandwidth utilization are

reduced extensively because of single group controller. The GC does not rely

on any other entity for key distribution and access control. The intact group

will be disturbed if there is a glitch in the controller. The group privacy is

predominantly reliant on the successful functioning of the single group

controller. This scheme is mostly affected by single point failure or 1 affects,

n problem. When the controller is not working, the group becomes vulnerable

because the keys, which are the base for the group privacy, are not being

generated/regenerated and distributed. Furthermore, the group may become

too large to be managed by a single party, thus raising the issue of scalability.

The performance measures of the protocol is given below,

1. Storage requirements

2. Size of the rekey messages

3. Forward and backward secrecy

4. Collusion

The most popular conventional centralized approaches are listed

below and elaborately discussed in the following sections

1. Group Key Management Protocol

2. Hierarchical Binary Tree

3. One way Function Tree

4. Logical Key Hierarchy

5. Key graph

34

6. Key Management using Boolean function minimization

7. Recent Approaches

2.6.1 Group Key Management Protocol (GKMP)

Harney & Muckenhirn (1997) proposed a protocol to create group

symmetric keys and distribute them amongst communicating peers. In this

approach, the Group Controller (GC) helps the Key Distribution Center

(KDC) to join the group by creating the Group Key Packet(GKP) that

contains a group traffic encryption key (GTEK) and a group key encryption

key (GKEK). The KDC sends the copy of the GKP to the new member at the

time of joining. When a rekey is needed, the GC generates a new GKP and

encrypts it with the current GKEK. As all the members are aware of GKEK,

there is no way to ensure forward secrecy when a member leaves the group.

2.6.2 Hierarchical Binary Tree (HBT)

To manage group keys effectively, Wallner et al (1999) proposed

Hierarchical Binary Tree. In this approach, group controller maintains the

keys used for communication in a tree structure. Leaves of the tree represent

encryption keys (KEK). All the KEKs are to be maintained by the individual

group member.

For a balanced tree, each member stores log2

the number of members. The structure of the group consisting of eight

members is shown in the Figure 2.5. The group member U3 holds 4 different

keys such as K3, K34, K14 and K,this is highlighted in the Figure 2.5. Any new

member to group can be accommodated only as the leaf of the tree. All KEKs

compromised (to ensure backward secrecy) and have to be changed. A re-key

35

message is generated containing each of the new KEKs that are encrypted

produced will be at most O(2 log2n).

Figure 2.5 Hierarchal key tree of group size 8

The various KEKs are affected when a new member U3 joins is

depicted in Figure 2.6 The member receives a secret key K3 and its leaf was

attached to the node K34. The KEKs held by nodes K34, K14 and K, which are

the nodes in the path from K3 34 14

encrypted with each of its corresponding KEKs of the node, for

34 is encrypted with K3 and K4; 14 is encrypted with K12 and

34 14 and K58. The size of a re-keying message

for a balanced tree has at most O (2 log2n) keys.

K12 K34 K56 K78

K1 K2 K3 K4

U1 U2 U3 U4

K

K14 K58

K5 K6 K7 K8

U5 U6 U7 U8

36

Figure 2.6 Essential encryptions when a member joins into the tree.

When a member departs from the group, the same procedure is to

compromised (to ensure forward confidentiality) and hence have to be

changed. A re-key message is generated, containing each of the new KEKs

node).

As the key held by the leaving member was not used to encrypt any new

longer able to access the group messages.

Figure 2.7 demonstrates what happens when a member leaves.

Member U4 is leaving the group and the KEKs K34, K14 and K are

compromised. KEKs K¹34, K¹14, and K¹ are generated and encrypted with each

K¹

K¹14 K58

K12 K¹34

K3 K4

U3 U4

{ K¹} K¹14

{ K¹} K58

{ K¹14}K12

{ K¹14} K¹34

{ K¹34} K3

{ K¹34} K4

37

34.

This KEK was encrypted only with K3 which is the rem

of K34.

Figure 2.7 Essential encryptions when a member leaves from the tree

2.6.3 One way Function Tree

OFT (Balenson 2000) was developed by Network Associates

Laboratories as part of the DARPA funded Dynamic Cryptographic Context

Management (DCCM) and it was the first of the Hierarchical method to

achieve such an approximate halving of broadcast size.

In OFT scheme, the Group Controller (GC) maintains a tree of keys

computed by a special one-way function. The internal nodes of the tree hold

KEKs and the leaves correspond to group members. Each leaf holds the key

associated to a member. The root of the tree holds the group key. The internal

K¹

K¹14 K58

K12 K¹34

K3 K4

U3 U4

{ K¹} K¹14

{ K¹} K58

{ K¹14} K12

{ K¹14} K¹34

{ K¹34}K3

38

-way function and then

mixed together using mixing function. The result of this mixing function is

the KEK held by the node. This is represented by the following formula:

Ki = f(g(K Left(i) , g(KRight(i))) (2.1)

where Left(i) and Right(i) denote the children of the node i at left and right

respectively. The function g is one-way, and f is a mixing function (e.g. xor).

The GC uses a symmetric encryption function E to communicate securely

with subsets of group members. During rekeying operations, the manager

would communicate with the group members through broadcast messages.

2.6.3.1 Structure of an OFT

The OFT is a particular form of binary tree, in which each internal

node has exactly two children. Every members of the group is assigned a

randomly chosen secret and a shared secret between group controller and

member.

Figure 2.8 Structure of OFT

X1=f (X2) f(X3)

= Group Key

X2

X4 X5 X6 X7

X3=f(X6) f(X7)

K3 = g(X3)

K7 = g(X7)

39

For any interior node V in the OFT, the node secret xv of V is

defined by xv=f(xL) f(xR), where L and R denote left and right children of V.

Figure 2.8 depicts the structure of OFT

2.6.3.2 Group initialization

The three steps in the initialization of a group are given below

1.

member and the group manager (Group induction). This key

establishment can be accomplished with any pair wise

authenticated key exchange protocol, such as Internet Key

Exchange protocol (IKE).

2. The manager creates the OFT key tree and assigns initial

member to its leaves. A variety of choices are possible for

creating the OFT tree and numbering its nodes.

i. Trees can be allowed to grow and shrink dynamically as

members are added and evicted.

ii. Large complete tree can be allocated, the nodes are

numbered using in-order scheme.

3. Initial group key is computed. The members compute the initial

group key after receiving crucial information broadcast from

the manager. To compute the group key, each member needs to

compute the blinded node secret of each sibling node along the

path from the member to the root. Each member also computes

the node keys along the path to the root, because these node

keys are needed to decrypt relevant message parts from the

manager has broadcast.

40

2.6.3.3 Insertion into an OFT

For each node V, xv is the node secret of V, kv is the node key of V

, and f(xv) is the blinded node secret of V. The newly joined M is informed of

the blinded node secrets of its ancestral siblings V10, V4, and V3 through

unicast message. It also computes the new unblinded keys of its ancestors

V5,V2,V1 via multicast, the other relevant members are informed about the

blinded node secrets

root.

To accomplish this task, the manager broadcasts the following three

encrypted messages: Ek10[f(x11)],Ek4[f(x5)] and Ek3[f(x2)], where E is an

encryption function and f is a special one way function. The structure of OFT,

before and after a member insertion is illustrated in Figure 2.9 and 2.10

respectively.

Figure 2.9 Before inserting a new member into an OFT Tree

8

1

2

4

add a new member m

3

Z

6 7

7

41

Figure 2.10 After inserting a new member into an OFT Tree

2.6.3.4 Evicting a member from an OFT key tree

and v1. Via multicast, the other members who need to know are informed of

the new blinded node secrets of nodes v5, v2. To accomplish this task, the

manager broadcasts two encrypted messages Ek1[f(x5)],Ek3[f(x2)], where E is

an encryption function and f is a special one way function. The structure of

the OFT, before and after a member eviction is illustrated in Figure 2.11 and

2.12 respectively.

7

10 8

1

2

4 5

6

3

9 11

42

Figure 2.11 Before evicting a member from an OFT Tree

Figure 2.12 After evicting a member from an OFT Tree

OFT achieves a smaller broadcast through its bottom up approach.

OFT requires significantly fewer random bits. This algorithm is appropriate

for an online system. Even though the OFT achieves perfect forward secrecy

5

Z

M evict this member

Z

8

9 10 11

43

and perfect backward secrecy, the computational complexity is too high. The

performance of OFT also depends on the height of the key tree. If dynamic

trees are used, to minimize h, new members can be added as close to the root

its height may be much greater than log n. A rebalancing operation has to be

performed.

Since OFT is intended for very large groups, the amount of storage

allocated per node in the key tree, significantly affects the total amount of

memory used by the manager. This issue can be referred

storage explosion. It is important to verify whether a group member has the

correct group key. A member might compute the wrong group key for two

reasons.

1. A member might never receive some key-update messages.

2. In the sequence of key update messages, the member might not

have any knowledge about the additional key-update messages

that are yet to come.

These situations are complicated by the unreliable nature of the

multicast environment.

2.6.4 Logical Key Hierarchy (LKH)

Wallner et al (1999) and Wong et al (2000) proposed a scalable key

management scheme by constructing a logical tree of KEKs for a given

group. Figure 2.13 illustrates the structure of LKH for a group size of eight.

Since the number of leaves determines the height of the tree, the height of the

tree and the total number of nodes in the tree is fixed in this model.

44

Every node of the logical tree is assigned a KEK. The set of keys assigned to

the node along the path from a leaf node to the root are assigned to the

member associated with that particular leaf node.

Figure 2.13 Key assignments to the members in LKH

For example, a member M1 as in Figure 2.13 is assigned KEKs .

{K0, K1,1, K2,1, K3,1}The member storage is thus the height of the tree, given

as (1+loga N) for a tree of degree a. Since a member shares the root key and

all the intermediate KEKs with other users, all the keys possessed by the

member except the one at the leaf node have to be updated when the member

is deleted. For example, when M1 leaves {K0, K1,1, K2,1}, the KEK needs to be

updated. The number of key update messages is given as (a-1) loga N.

For this logical key hierarchy, the GC has to store all the keys

corresponding to the nodes of the entire tree, which is ((a*n)-1)/ (a-1) and

scales as O(n) . Hence, the key storage requirement of the GC is a bottleneck

in this model. The minimal storage scheme has constant GC storage but O(n)

as communication cost, while the logical key hierarchy has O( log N) as

communication cost, but O(n) as GC storage requirement.

45

In group key management, schemes based on logical key

hierarchies or key trees (henceforth referred to as LKH), group re-keying

involves two operations such as key encoding and key distribution. Key

encoding involves determining which keys in the logical key tree need to be

changed, and encrypting the changed keys using the LKH algorithm. Key

distribution involves packing the encrypted keys into packets and executing a

protocol that ensures that all the packets are delivered to the members of the

group in a timely fashion. For scalable group rekeying, both the key encoding

and the key distribution operations need to be clearly scalable.

2.6.5 Keygraph

A keygraph (Wong et al 2000) is a directed acyclic graph G with

two types of nodes i.e., u-nodes representing users and k-nodes representing

keys. Figure 2.14 shows the structure of key graph. Each u-node has one or

more incoming edges. If a k-node has only incoming edges and no outgoing

edges, then this k-node is called a root. The set U represents the user node, K

represents key node and the relationship between user and key is by the set R.

Each u-node has one or more incoming edges.

.

Figure 2.14 Structure of Key graph

46

2.6.5.1 Rekeying

When new members join a group, the controller initiates a rekeying

process, to ensure backward secrecy. When a member leaves the group,

rekeying process updates the group session key to prevent members who have

left the group from compromising the future group communications. In

Keygraph the following three different ways of rekeying are performed for

join and leave,

1. User oriented rekeying

2. Key oriented rekeying

3. Group oriented rekeying

2.6.5.2 Join operation

After granting a join request for user u, the server creates a new u-

node and a new k-node for its individual key ku. Later it finds an existing k-

node in the key tree and attaches k-node ku as its child.

For example, suppose u9 is granted permission to join as shown in

Figure 2.15, the key node k78 is changed to k789 and the group key k1-8 to k1-9.

The updated keys are distributed by any one of the three rekeying

methodologies.

Method 1: User-oriented rekeying

The controller creates rekey message that contains the new keys

encrypted by the keys known to the existing user. When user u9 joins, the

controller sends the following three rekey messages

47

S {u u6}: {k1-9}k1-8

S {u7,u8} : {k1-9,k789}k78

S { u9} : {k1-9,k789}k9

Figure 2.15 Key trees join and leave

This approach needs h rekey messages and the encryption cost for

the controller is (h*(h+1) -1)/2 where h denotes the height of the tree.

48

Method 2: Key-oriented rekeying

In this method, each new key is encrypted individually. For each k-

two rekey messages.

and distributed to the existing user set. The second rekey message - the new

s individual key and transmitted to the

new user. Since the height of the tree shown in Figure 2.15 is 4, the rekeying

messages are also four. This approach needs h rekey messages and the

encryption cost for the server is 2(h-1) .

S {u1 8} : {k1-9)k1-8

S u9 : {k1-9}k9

S {u7,u8} : {k789}k78

S u9 : {k789}k9

Method 3: Group-Oriented Rekeying

In group-oriented rekeying, the controller constructs a single rekey

message containing all new keys. And it is multicasted to the group. Group-

oriented rekeying method has the following advantages over key-oriented and

user-oriented rekeying

1. Group multicast can be used instead of unicast or subgroup

multicast.

2.

reduced.

49

3. The total number of bytes transmitted by the server per

join/leave request is much lesser than key-oriented and user-

oriented rekeying.

For example, when a user u9 joins the group, the controller needs

to send the following two rekey messages; one is multicasted to the group and

the other is unicasted to the joining user as shown in Figure 2.15

S {u1 u8} : {k 1-9}k 1-8,{k789}k78

S u9 : {k1-9,k789}k9.

This reduces the encryption cost to 2*(h-1), where h is the height of

the tree.

2.6.5.3 Leave operation

When a user leaves from the group the keygraph is updated by

deleting the corresponding s-node and k-node of the user. The parent of the k-

node is called as leaving point.

As illustrated in Figure 2.15, when the user u9 leaves the group, the

key node is to be changed to k78 and group key k1-9 to k1-8. For example, u9 is

granted to leave as shown in Figure 2.15. As soon as the user leaves the

group, the new keys are distributed securely through the three different

rekeying strategies.

Method 1: User-oriented rekeying

In this approach, the key held with the user encrypts the new key.

When the user u9 leaves, the controller constructs the following four rekey

messages.

50

S {u1, u2 u3} : {k1-8} k123

S {u4,u5,u6} : {k1-8 } k456

S { u7} : {k1-8,k78} k7

S { u8} : {k1-8,k78} k8 .

This approach requires ((d-1)*(h-1)) rekey messages and the

encryption cost for the server is given by the Equation (2.2)

(d- -1) = ( (d-1) h (h-1) )/2. (2.2)

Here d denotes the degree i.e. the maximum number of incoming edges of a

node in the tree.

Method 2: Key-oriented rekeying

In this approach, each new key is encrypted individually. For

example, as shown in Figure 2.15, when the user u9 leaves the group, the

controller needs to send the following four rekey messages

S {u1, u2 u3} : {k1-8} k123

S {u4,u5,u6} : {k1-8 } k456

S { u7} : {k1-8} k78, {k78} k7

S { u8} : {k1-8} k78, {k78} k8 .

Note that by storing encrypted new keys for use in different rekey

messages, the encryption cost of this approach is d(h-1), which is much less

than that of user-oriented rekeying. The number of rekeying messages is

(d-1)*(h-1), same as user oriented rekeying.

51

Method 3: Group-oriented rekeying

When user u9 raises leave request from the group as portrayed in

Figure 2.15 the controller needs to send the following rekey messages.

Let L0 denote {k1-8} k123, {k1-8} k456, {k1-8} k78 and L1 denote {k78} k7, {k78} k8

S {u1 8} : L0, L1.

This approach uses only one rekey message which is multicasted to

the group, and the encryption cost is d (h-1), where d is the average degree of

k-node.

The comparison of the three methods with respect to controller

processing time per request versus group size and controller processing time

per join versus key tree degree are shown in Figure 2.16 and 2.17 respectively

Figure 2.16 Server processing time per request vs group size (key tree degree 4)

52

Figure 2.17 Server processing time per join vs key tree degree (initial group size 8192)

2.6.6 Key Management using Boolean Function Minimization

Chang et al (1999) proposed a scheme, which had the same

properties as the flat table with an optimization for the number of messages

needed for re-keying the group based on Boolean function minimization

technique. This focuses on the problem of aggregating key updates by

cumulative member removal. The main advantage is the reduction in message

complexity by removing multiple group members simultaneously.

In this approach, each user has a unique user ID (UID) which is a

binary string of length n. A UID can be written as Xn-1, Xn-

Xi can be either 0 or 1. The length of UID depends upon the size of the

multicast group. For example in a group with 1024 members, a 10-bit UID is

to be used. Initially the group controller distributes the session key to all the

members. If any user leaves the group, the session key is changed by the

group controller in order to ensure the forward secrecy and is transmitted to

53

all the remaining members by making use of complementing the UID of the

departed member. Figure 2.18 portrays the key structure of Boolean tree.

Figure 2.18 Key distribution in Boolean function minimization

Consider the group with 8 members. Suppose C5 (101) has to be

removed from the group as shown in the Figure 2.19. The new session key,

SKnew is generated and it is transmitted to the remaining (7) members. The

departing member and it is transmitted using 3 i.e., .O (log N) = O (log 8) = 3

messages to the remaining ones. They are {SKnew}K¹0 , {SKnew}K1 and

{SKnew} K¹2 respectively where {L}M means string L is encrypted with key

M. Hence, the departed member C5 cannot decrypt the messages.

54

Figure 2.19 Departure of C5

This scheme discusses only about leave operation and does not

discuss about join operation and this is susceptible to collusion attacks by two

or more members.

2.6.7 Recent Approaches

Ronggong Song et al (2008) proposed a scalable group key

management protocol (SGKMP). SGKMP is based on the Chinese remainder

theorem and hierarchical graph in which each node contains a key and a

modulus. The new protocol reduces the hashing operations from O(log n) to 1

when compared to LKH, and the length of the lock from O(n) to O(log n)

when compared to the Secure Lock, by using a hierarchy modulus graph,

which makes the length of the secure lock more scalable. In the new protocol,

the keys and moduli are constructed as a tree and maintained by the key

server. The tree graph is similar to the tree graph in the LKH protocol but

each node of the tree in the new protocol is assigned two values: a key and a

modulus. The key server needs to store 2log2n moduli and each member

needs to store log2n moduli but they do not need to keep the moduli secret.

55

Luca Veltri et al (2013) suggested a centralized approach to

efficiently distribute and manage a group key in Internet of things, while

reducing the computational overhead and network traffic due to group

The aim of the

protocol is to minimize the computational burden of group members and the

overhead, expressed in terms of number of exchanged messages, while

achieving a sufficiently high security level. The methodology employed to

manage the keys is based on a key derivation scheme properly extended in

order to deal with both unpredictable leave events and collusive attacks.

The centralized Key Distribution Center (KDC) that takes care of:

(i) maintaining a secure association with all users belonging to the system;

(ii) generating a new group key every time the group membership changes;

and (iii) efficiently managing the distribution of the new group key to all

group members, guaranteeing both forward and backward secrecy.

The KDC handles simultaneously a bulk number of membership

changes. This can be achieved by splitting time into intervals called as slots.

The handle the leaves the different group key Ki for each time slot I with

i = 0, 1, 2, . . . , N. In order to efficiently handle both kinds of leave events,

the group key is obtained through a one-way function of two sub-keys K1i

and K2:

Ki = f(K1, K2

In order to optimize and significantly reduce the number of

exchanged messages required for handling group member changes and group

key re-distribution (rekeying), time is split into time-intervals, thus letting the

KDC to handle together all membership changes that occur in the same time

interval (batch method). For each time interval a new key is automatically

derived by all active members, without any interaction with the KDC. In such

56

way both join and pre-determined leave event can be easily handled. Only in

case of key revocation events explicit communication between KDC and

group member is required, allowing our protocol to better perform than

current key distribution protocols.

2.7 DISTRIBUTED GROUP KEY MANAGEMENT

The distributed group key management is characterized by no

explicit manager and the members themselves do the key generation. The

group key can be either generated in a contributory fashion, where all

members contribute their own share to computation of the group key, or

generated by one member. In the latter case, although it is fault-tolerant, it

may not be safe to leave any member to generate new keys since, key

generation requires secure mechanisms, such as random number generators,

that may not be available to all members (Adusumilli et al 2005). Moreover,

in most contributory protocols (apart from tree-based approaches), processing

time and communication requirements increase linearly in term of the number

of members. Additionally, contributory protocols require each user to be

aware of the group membership.

The distributed protocols have a scalability problem in case of key

update, since they are required to perform large computations, and they are

characterized by large communication overheads (Jabeenbegum et al 2010).

Further, they need all group members to have powerful resources. In a

distributed approach, there is no centralized server and the group key is to be

formed from the contribution of all members.

Steiner et al (1996) proposed the Diffie-Hellman algorithm which is

base for all the key management techniques used under this approach. This

algorithm relies upon for its effectiveness on the difficulty of computing

57

b= ai mod p, where 0<= i <= (p-1) (2.3)

generate all the integers from

1 to p-

mod p, a2 p-1mod p are distinct and consist of the integers from 1

through p-1 in some permutation.

The significance of discrete logarithm as a hard problem in key

exchange is explained in the next section.

2.7.1 Diffie Hellman Key Exchange

Diffie Hellman key exchange (Steiner et al 1996) is an extension

for the DH key agreement protocol that supports group operations. The DH

protocol is used for two parties to agree on a common key. The following

example illustrates how a common key is formed by users A and B by

exchanging the partial keys between them. In this scheme two publicly known

ger that is a primitive root of q.

User A selects a random integer XA<q and computes YAXA mod q.

Similarly user B selects a random integer XB<q and computes YBXB mod

q. Each side keeps the X value private and makes the Y value available to the

other side. User A computes the key as K= (YB) XA mod q and user B

computes the key as K= (YA) XB mod q. These two calculations produce

identical result which is nothing but a common key.

58

K = (YB) XA mod q (2.4)

X

B mod q) X

A mod q

X

B) X

A mod q//by the rules of modular arithmetic

X

B XA mod q

XA) XB mod q

XAmod q) XB mod q

= (YA) X

B mod q. (2.5)

From the Equations (2.4) and (2.5) it is evident that users A and B

arrived at their common key in a secret manner.

2.7.2 CLIQUES Protocol

Steiner et al (1998) illustrates two party Diffie-Hellman key

exchange which is extended for a group and referred as CLIQUES protocol.

A clique is an extension of Diffie-Hellman key agreement protocol. In DH

key agreement protocol, two parties agree on a common key. In cliques,

instead of two entities, the group agrees on a common key. All the members

contribute to generate the group key. The setup time is linear since all

members are involved in sequence to generate their group keys. It provides an

application-programming interface for secure group communication.

This API enables all the group operations. Here, all the members

can perform access control. It can handle group dynamism effectively and can

handle fault tolerant issues. Group controllers are necessary for membership

management and group key refreshes are based on the local polices. There are

basically two key management operations namely initial key agreement (IKA)

59

and auxiliary key agreement (AKA). It supports both static and dynamic

groups.

Since the common group key is to be agreed upon from the

contributions of all the members in a sequential manner, this method is not

suitable for large groups i.e., the key management operations increase

exponentially with respect to the number of members in a group. So,

scalability is a great issue and it does not address other security services such

as key integrity, entity authentication, non-repudiation and access control.

2.7.3 Tree Based Group Diffie-Hellman (TGDH)

Blundo et al (1993) explains about Tree Based Group Diffie-

Hellman contributory key agreement protocol which is robust and efficient in

the sense that it can deal with network partition and the number of rounds for

rekeying is limited by O(log2n), where n is the number of members currently

in the group. In TGDH, all members maintain an identical virtual binary key

tree which may or may not be balanced. The nodes in the key tree are denoted

by <l,v> where l is the level in the tree and v indicates the node in level l.

The root node is labeled as <0,0> and the two children of a node <l,v> are

labeled as <l+1,2v> and <l+1,2v+1>. Every node except the root node is

associated with a secret key K<l,v> and a blinded key BK<l,v>=f(K<l,v>) where

f(x)=gx mod p.

Diffie-Hellman protocol is used to share the secret key between

each node and to compute a common key. A sponsor of a sub tree is the

member hosted on the right most leaf in the sub-tree and the sponsor of a leaf

node is the member hosted on the rightmost leaf node of the lowest sub-tree,

where this leaf node belongs to. For every join, the sponsor is determined for

the joining member and the sponsor generates new private share and

60

computes all secret keys and blinded keys from its leaf node to the root node.

Similarly the root key is computed in one round for single leave.

Figure 2.20 Tree based Group Diffie- Hellman key distribution tree

The computation of a common key for six members M1, M2, M3,

M4, M5 and M6 using TGDH protocol is shown in the Figure 2.20. Here the

publicly available components are g which is a primitive root of p. The mod

operator is not shown in the illustration for simplicity. Considering the

node<2,0> which calculates the blinded key BK<2,0> = f((BK<3,0>)K<3,1>) =

f((BK<3,1>)K<3,0>) = gga1a2. After computing the blinded key values, they are

broadcast to the group members. The member M1 calculates

K<1,0>,BK<1,0> and it receives BK<1,1> broadcasted from the members

hosted in the right sub-tree and it calculates the root key which is equal to

BK<0,0> = f(BK<1,1>K<1,0>). Eventually, all the other members compute the

root key as M1. The problem with this protocol is seamless communication

<0,0>

<1,0>

<2,0>

<3,0> <3,1>

<2,1>

<1,1>

<2,0>

<3,6> <3,7>

<2,1>

61

and during re-keying process, the communication has to be stopped until the

new key is computed. In order to overcome these difficulties, another protocol

is discussed in the next section.

2.7.4 Block-Free Tree Based Group Diffie-Hellman (BF-TGDH)

Xukai Zou & Byrav Ramamurthy (2002) proposed the Block-Free

Tree Based Group Diffie-Hellman (BF-TGDH) as an extension of the TGDH

protocol. The BF-TGDH protocol uses two kinds of keys viz., front-end keys

and back-end keys. The front end key can be computed by all group members

whereas for back-end keys, each member can compute other member keys

except one key which is intended for that particular member. Whenever a

member leaves, the remaining members will switch over to the back end key

which is not possessed by the leaving member and the group communication

may be continued along with the re-computation of all keys in a background

process which is illustrated in Figure 2.20.

Here M1, M2, M3, M4, M5 and M6 represent the users and a1, a2,

a3, a4, a5 and a6 are the private values of above mentioned users respectively.

D1,D2,D3,D4,D5 and D6 are dummy members, the corresponding dummy

values are denoted as d1, d2, d3, d4, d5 and d6 and g is a public Diffie-

Hellman component. The keys calculated by M1is described as follows:

The notation (a1 i m) represents k(a1 i mk(a1 i m)

where k(a1 i m) is a dummy secret key , BK(a1 i m) = gk(a1 i m)

is a dummy blinded key and di's (ei = gdi ) are dummy private shares (dummy

disguised public shares) which are generated by an off-line shares

generator. For example, let us consider M1. M1 can compute (a1d2) (i.e.,

ga1d2 ga1

d2 ) and broadcast BK(a1d2) = g ga

1d2. Then M1 computes

62

(a1d2a3)(i.e., gga1

d2

a3 gga

1d2

a3 after receiving ga3 from M3) and (a1a2d3) from

gd3 which is generated by the off-line shares generator.

Finally, M1computes (a1d2a3a4a5a6) when receiving gga4ga5

a6,

(a1a2d3a4a5a6) when receiving gga4ga5a6, (a1a2a3d4a5a6) when receiving ggd4ga

5a6,

( a1a2a3a4d5a6) when receiving gga4gd5

a6, and (a1a2a3a4a5d6) when receiving

gga4ga5

d6 .

It is evident that M1 cannot calculate d1a2a3a4a5a6 and can be

calculated by all the other members. So whenever M1 leaves the group, the

remaining members manage their session with the above said key until the

new root key is calculated in a block free manner.

Since BF-TGDH is an extension of TGDH, it overcomes the

problem of seamless communication. But this leads to the problem of storage

complexity and computational efficiency. Every member has to calculate n

root keys instead of one root key. Since lots of keys are used, sharing of these

keys lead to the problem of increase in the size of messages. Regarding

security issues, when two leaving members collude; they can compute the

dummy root keys. So, it loses its perfect forward secrecy.

2.7.5 Recent Approaches

Mingyan Li et al (2002) designed a secure multicast key

management scheme for cost optimization in case of single sender and

multiple receivers. A new algorithm is proposed to optimize with

communication constraints. The scheme uses a hybrid tree scheme in which

the storage and the update communication are functions of the cluster size.

The cluster size was chosen to be scaling at least to the order of O(log N).

63

The scheme also presents a theorem for the solution to the

constraint optimization problem which is based on a largest value of M

satisfying the update communication constraint.

The design procedure is as follows:

1. Initial design data: initializing group size, tree degree, and

communication scale factor

2. If the communication scale factor value satisfies the required

condition for the design then go to step 3, otherwise the design

is not feasible.

3. Compute the optimal cluster size

4. Construct a hybrid tree of degree initialized and the cluster size

computed.

Srinivasan et al (2006) proposed a hybrid scalable group key

management approach for large dynamic multicast networks which generate

and distribute keys to the group members during leave or join of members by

using key graph based Boolean minimization technique in order to improve

man technique to generate UID for users

in the group and it uses Petricks approach to deal with multiple leave of users.

Mohamed et al (2009) proposed a new secure multicast key

distribution protocol using combinatorial Boolean approach. It is based on

Key Management using Boolean Function Minimization (KM-BFM)

technique. This technique is compared with the other approaches and is

proven to be efficient with respect to the communication overhead. The

scheme also supports multiple leave/join operations.

64

Lakshmanaperumal et al (2010) proposed an efficient key

management scheme, which uses hybrid key management scheme and is

proved to be secure way of key management. It supports multiple join /leave

operations. When a multiple member leaves, the key update procedure can be

applied k times consecutively to remove k member from the group. However,

a more efficient way is to aggregate the removal of several members from the

group. This will be useful where several members depart either

simultaneously or within very small time interval. The problem of cumulative

group removal; becomes grouping the remaining members based on the UID

bits in such a way that the members intact are grouped together and separated

from those who were removed. This is done by grouping the members based

on the way they share common bits among one another and in the way they

differ in bits with those members who were removed.

2.8 DECENTRALIZED GROUP KEY MANAGEMENT

In decentralized group key management approach, the large group

is spilt into small subgroups. Different controllers are used to manage each

subgroup, minimizing the problem of concentrating the work at a single place.

It is completely fault tolerant. These protocols need more trusted nodes and

suffer from encryption and decryption processes between sub-group

managers. Some of the standard examples of decentralized protocols are

1. Scalable Multicast Key Distribution Protocol

2. Iolus

3. Dual-Encryption Protocol (DEP)

4. Marks

5. Kronos

6. Intra domain Group Key Management Protocol

7. Hydra Protocol

65

2.8.1 Scalable Multicast Key Distribution

Ballardie (1996) proposed the scalable multicast key distribution

(SMKD) protocol, which uses the tree built by the Core Based Tree (CBT)

multicast routing protocol to deliver keys to multicast group members. In the

CBT architecture, the multicast tree is rooted at a main core and secondary

cores can exist eventually.

The main core creates an Access Control List (ACL). Group key

and key encryption key are used to update the group key. The ACL, the group

key and the key encryption key are transmitted to secondary cores and other

nodes, when they join the multicast tree after their authentication. Any router

or secondary core authenticated with the primary core can authenticate joining

members and use the ACL to distribute the keys, but only the main core

generates those keys. The SMKD protocol does not provide the forward

secrecy when a member leaves the group. It has to execute freshly each time

when a member departs.

2.8.2 Iolus

A framework which splits the large group into small sub groups is

proposed by Mittra (1997). Each subgroup is controlled by Group Security

A

controller (GSC) which is in the top-level of the group. The structure of Iolus

is illustrated in Figure 2.21.

66

Figure 2.21 Iolus Hierarchy

Every subgroup has its own independent key to communicate

within the subgroup. For instance, subgroup 1 possesses key K1 and subgroup

n has key Kn. Any changes done in one subgroup do not reflect in other

subgroups. If a subgroup controller fails, only its subgroup is being affected.

This makes the complete group to be fault tolerant and also supports graceful

degradation. Scalability, robustness and independence are the special features

of Iolus.

Though Iolus is scalable, managing the communication between

GSA creates overhead to the system. When one of the GSA and GSC fails,

data exchange between group is not possible. Mostly it affects data path. This

occurs in the sense that there is a need for translating the data that goes from

one subgroup to another. This become even more problematic when it is taken

in to account that the GSA has to manage the subgroup and perform the

translations needed.

K1 IP Multicast

K6

K2

K3 K4

K5

GSA 3 GSA 4

GSA 1

GSA 5

GSA 6

GSA 2

67

2.8.3 Dual Encryption Protocol

In order to solve the problem of trusting third parties, Dondeti et al

(1999) proposed a Dual-Encryption Protocol (DEP) uses hierarchical sub-

grouping of multicast members to address scalability. Each sub-group is

managed by a sub-group manager (SGM). SGMs are trusted routers or hosts

in the network that can handle the workload of managing a sub group in the

multicast group.

There are three kinds of KEKs and one Data Encryption Key

(DEK). KEKi1 is shared between a SGMi and its subgroup members. KEKi2

is shared between the Group Controller (GC) and the members of subgroup i,

excluding SGMi . Finally, GC shares KEKi3 with SGMi . In order to

distribute the DEK to the members, the GC generates and transmits a package

containing the DEK encrypted with KEKi2 and encrypted again with KEKi3

i decrypts its part of the

message using KEKi3 and recovers the DEK encrypted with its sub-group

KEK(KEKi2), which is not known by the SGMi. SGMi encrypts this encrypted

DEK using KEKi1 shared with its subgroup members and sends it out to

subgroup i.

Each member of sub-group i decrypts the message using KEKi1 and

then decrypting the message using KEK i2 (shared with GC), recovers DEK.

The DEK cannot be recovered for any entity that does not know both keys.

although there are third parties involved in the management of SGMs, they do

not have access to the group key (DEK). When the sub-group i

memberships changes the SGMi changes KEKi1 and sends it to its members.

Future DEK changes cannot be accessed for members of sub-group i that did

not receive the new KEKi1. However, evicted members that do not receive

KEKi1 can still to access the group communication until the DEK is changed

and hence this compromises forward secrecy. Another disadvantage of this

68

method is a trivial collusion attack existing i.e. the leaving user colludes with

a participant-SGM and the participant-SGM can get the KEK.

2.8.4 MARKS Protocol

In MARKS protocol, Bob Briscoe (1999) suggests slicing the time

length into small portions of time and using a different key for encrypting

each slice. The encryption keys are leaves in a binary hash tree that are

generated from a single seed. Rivest (1992) proposes a blinding function,

such as MD5, used to create the tree nodes. Figure 2.22 depicts an example of

the generated binary tree whose leaves are the keys that correspond to the

different slices.

Figure 2.22 MARKS key generation tree

Each intermediate node (including the root) is allowed to generate

two children (left and right). The left node is generated by shifting its parent

one bit to the left and applying the blinding function on it. The right node is

function on it. Users willing to access the group communication receive the

69

seeds needed to generate the required keys. The system cannot be used in

situations where a membership change requires the change of the group key,

since the keys are changed as a function of the time. The distribution of the

seeds and the management

managers.

2.8.5 Kronos

Setia et al (2000) proposed Kronos. It works on the principal of

periodic rekeys rather than rekeying on group membership changes. In this

approach a new group key is generated after a certain period of time,

disregarding whether any member has joined, left or been ejected from the

group. The operation of the Kronos protocol is similar to Intra-domain Group

Key Management Protocol (IGKMP). Under the IGKMP an administrative

-member of a multicast

group is assumed to reside in a particular area. IGKMP distinguishes between

multicast groups for the purpose of key management and payload delivery.

There is a Domain-wide Key Distributor (DKD) and an Area Key Distributor

(AKD) corresponding to each area.

Although Kronos can be used within a distributed framework such

as IGKMP, it works differently because the DKD does not directly generate

the group key. Instead, each AKD independently generates the same group

key and transmits it to its members at the end of the predetermined period.

The master cl

on a common rekey period to ensure the proper functionality of this scheme.

Network Time Protocol (NTP) for clock synchronization can be used. Second,

the AKDs also have to agree on two secret factors, namely K and R0, where

R0 is an initial value and K is a master key. The AKDs can receive the secret

factors from DKD via a secure channel. To generate the group key, with name

R1, the AKDs apply an encryption algorithm, E, to R0 using K as the secret

70

key (R1 D EK (R0)). The same algorithm applies for the next key generations:

RiC1 D EK (Ri ), i >D0. Although Kronos does not use a central controller

and the subgroup controllers can generate the new keys independently, yet the

system is fault-tolerant, it compromises the group security because it

generates the new key based on the previous one. If one key is disclosed, then

it compromises all following keys.

Under Kronos, group re-keys are not driven by member join or

leave requests. Instead, at periodic intervals, all the member join and leave

requests that have accumulated at an AKD are processed and the new

multicast traffic encryption key is securely transmitted to the existing

members of the group. An algorithm such as LKH can be used by each AKD

to accomplish this task in a scalable manner. Note that most of the processing

required for joins and leaves can be done during the time interval between re-

keys.

Mills (1992) addressed the issue by having the AKDs agreement in

advance on the re-keying period and by using a clock synchronization

algorithm such as the Network Time Protocol (NTP). NTP can synchronize

hosts to within a millisecond on LANs and within a few tens of milliseconds

on WANs relative to a server synchronized to Coordinated Universal Time

via a Global Positioning System (GPS) receiver. Further, NTP can be

configured to use multiple redundant paths for reliability and authentication to

prevent accidental or malicious protocol attacks.

The second issue can be addressed as follows: Firstly, all the AKDs

need to agree on two shared secrets, say K and R0. This can be accomplished

by having the DKD (or the group coordinator) selecting K and R0 and

transmitting it to the AKDs using a secure channel. Alternatively, the AKDs

can use a group key agreement algorithm such as Cliques to generate K and

R0 in a contributory fashion.

71

Once the shared secrets are established, every AKD generates the

multicast group key i.e., R1 by applying a secret-key encryption algorithm, E,

to R0 using K as the secret key and thus R1 = EK(R0). R1 is then securely

transmitted to the members of the group in the AKDs area. This process is

repeated at each iteration i.e. the AKD obtains the next multicast group key

by applying the secret key encryption algorithm to the previous group key.

Thus

Ri+1 = EK(Ri), i >= 0 (2.6)

The choice of the encryption function E and the length of the key K

is dictated by the security requirements of the application. Any function such

as DES, triple DES, or IDEA can be used. In addition, periodically, for

enhanced security the AKDs should re-establish the shared secrets K and R0.

The choice of the re-keying period for our approach is largely dependent on

the security and performance requirements of the application. However, the

fact is that the AKDs do not have to coordinate, while re-keying enables us to

select re-key periods that can be as small as one second. Using this approach,

a distributed key management framework such as IGKMP can re-key large

and dynamic groups in a scalable way while maintaining a single group-wide

multicast key.

2.8.6 Intra-Domain Group Key Management Protocol

Decleene et al (2001) proposed the Intra-domain Group Key

Management Protocol (IGKMP). Architecture divides the network into

administratively scoped areas. They are a Domain Key Distributor (DKD) and

many Area Key Distributors (AKDs). Each AKD is responsible for one area.

The group key is generated by the DKD and is propagated to the group

members through the AKDs. The DKD and AKDs belong to a multicast

72

group called All-KD-Group. The DKD uses this group to transmit re-key

messages to the AKDs who re-key in turn to their respective areas.

This architecture suffers from a single point of failure, which is the

DKD that is the entity responsible for generating the group key. Besides, in

case of an AKD failure, members belonging to the same area will not be able

to access the group communication. Figure 2.23 exemplifies this architecture.

Figure 2.23 Intra-domain group key management protocol architecture

2.8.7 Hydra Protocol

Sandro Rafaeli & Hutchison (2002) proposed Hydra protocol,

wherein the group is organized into smaller subgroups and a server called the

Hydra server (HSi) that controls each subgroup i. If a membership change

occurs at subgroup i, the corresponding HSi generates the group key and

sends it to the other HSj involved in that session. In order to have the same

group key distributed to all HSs, a special protocol is used to ensure that only

a single valid HS is generating the new group key whenever required. Figure

2.24 illustrates the Hydra architecture.

73

Figure 2.24 Hydra architecture

2.8.8 Efficient Key Agreement Protocol

Liming Wang & Chuan-Kun Wu (2006) proposed an efficient key

agreement for large and dynamic multicast Groups. It details a scalable,

efficient, authenticated group key agreement scheme for large and dynamic

multicast systems which is identity-based, that uses the bilinear map over the

elliptic curves. The advantages of this scheme are: First, it achieves group

member authentication without imposing extra mechanism; second, it solves

the scalability problem in multicast systems; and third, the keys used in each

subgroup can be generated by a group of key generation centers (KGCs) in

parallel. The Table 2.1 presents a comparison of various decentralized

frameworks.

Table 2.1 Comparison of Decentralized Frameworks

74

The various key management schemes are explored thoroughly and

its pros and cons are discussed. Selection of key management technique

mainly depends on the application and level of security needed for that

application. The next chapter focuses on the overview of IPTV architecture

and how multicasting can be an ideal solution for broadcasting of the

multimedia contents to its large dynamic pool of subscribers. The

performance of batch rekeying depends on many parameters. One among the

main decision parameter is batch rekey interval. The methodology to identify

the optimal batch rekey interval for IPTV is discussed elaborately in

chapter 3.