balanced lkh for secure multicast josep pegueroles and francisco rico-novella

Security and Protection of Information. Brno 2003B

ala

nced

LK

H

for

Secu

re M

ult

icast

Balanced LKH for Secure Multicast

Josep Pegueroles and Francisco Rico-Novella

Telematics Engineering Department.

Technical University of Catalonia

Barcelona, Spain


ala

nced

LK

H f

or

Secu

re M

ult

icast

Agenda

• Introduction

• Key Management (KM) for multicast

• Logical Key Hierarchy. LKH

• Problems with LKH

• Balanced LKH

• Ongoing work

• Conclusions


ala

nced

LK

H

for

Secu

re M

ult

icast

Introduction

Many commercial applications need security (also military applications)• Video/audio-conference (many-many)• WebTV (1-many)• news, on-line stock information (1-many)

All these have a common feature: Group Communication

Security for Group Communication means• Confidenciality• Authentication of the communication• Policy management


ala

nced

LK

H

for

Secu

re M

ult

icast

Security for Group Communication

Confidentiality• Cipher data sent to the group.• Distribution of keys to the participants.• Update keys when necessary.

Authentication of the communication.• Be sure the data comes from the group.• Be sure the data comes from the source

Policy Management• Who dictates the rules• How we distribute them


ala

nced

LK

H f

or

Secu

re M

ult

icast

Agenda

• Introduction

• Key Management (KM) for multicast



• Balanced LKH

• Ongoing work

• Conclusions


ala

nced

LK

H

for

Secu

re M

ult

icast

Key Management (KM) for multicast

A secret shared by all the group members (Group Key) provides confidentiality and group authentication.

Open challenges:• Key distribution for huge groups.

– Usual group size: 100, 1K, 10K, 100K and more

• Re-distribution of keys for dynamic groups– The behavior of one member affects the whole group.

• Reliable transmission of rekeying messages.

Confidentiality level - Perfect Forward & Backward Secrecy • No member has to be able to access group

communication data...– …before joining the group. Perfect Backward Secrecy (PBS)

– …after leaving the group. Perfect Forward Secrecy (PFS)

The only solution: Change the group key every time membership in the group changes.


ala

nced

LK

H

for

Secu

re M

ult

icast

Naïve solution: Trivial Key Distribution

First stagei. Open a secure channel with each of the members.ii. Send the group key

– Complexity order = N [O(N)]

Rekeying when membership changesi. Send the new group key, separately to each of the

remaining members.– complexity O(N)


ala

nced

LK

H

for

Secu

re M

ult

icast

KD applied to Multicast Environment

GKCsGKCs

MM33 MM44

MM55 MM66 MM77

MM22MM11RouterRouter

RouterRouter

RouterRouter

MulticastMulticast

MulticastMulticast

MulticastMulticast

Unicast behavior

6

6 3

2

2

3

Multicast behavior

1

1 1

1

1

1AdvantagesDistributed scenarioBandwidth efficiency using Multicast channel

Contradictions /ChallengesCentralized ServerBW usage inefficient


ala

nced

LK

H

for

Secu

re M

ult

icast

Tree Based algorithms

2 types of keys • SEKs (Session Encryption Key)• KEKs (Key Encryption Key)

A Group Controller constructs a tree based hierarchy of KEKs

Logical entities

Group key

members

Group Controller

N number of members

d tree degree

depth1( )ln N

( )ln d


ala

nced

LK

H f

or

Secu

re M

ult

icast

Agenda

• Introduction

• Key Management (GKM) for multicast



• Balanced LKH

• Ongoing work

• Conclusions


ala

nced

LK

H

for

Secu

re M

ult

icast

Logical Key Hierarchy (LKH)

Wallner, Harder, Agee NSA 1999

Updates the group key and the key encryption key by means of the ciphering of key-nodes in a hierarchical tree where members are located at the leaves.

Achieve rekeying with only O(logN) messages instead of O(N) showed by trivial approach.

Very simple cryptographic properties. Keys are generated independently.

Different ciphering algorithms can be used (DESede, AES…)


ala

nced

LK

H

for

Secu

re M

ult

icast


Initializationd ( )N 1

1 dKEKs stored in GKCs

KEKs stored in Ms1( )ln N

( )ln d

KK3232KK3131 KK3333 KK3434 KK3535 KK3636 KK3737 KK3838

KK2222KK2121 KK2323 KK2424

KK1111 KK1212

KK00 GKCsGKCs

MM11 MM22 MM44 MM66MM55MM33 MM77 MM88

N secure channels


ala

nced

LK

H

for

Secu

re M

ult

icast


Leaving Member

GKCsGKCs

KK3232KK3131 KK3434 KK3535 KK3636 KK3737 KK3838

KK2222KK2121 KK2323 KK2424

KK1111 KK1212

KK00


( )ln N

( )ln dRekeying Messages

K’K’1111

K’K’2222

K’K’00 KK34 34 { K{ K1111’}’}KK34 34 { K{ K00’}’} KK34 34 { K{ K2222’}’}

KK21 21 { K{ K1111’}’}KK21 21 { K{ K00’}’}

KK12 12 { K{ K00’}’}


ala

nced

LK

H

for

Secu

re M

ult

icast


Joining Member

GKCsGKCs


KK2222KK2121 KK2323 KK2424

KK1111 KK1212

KK00


( )ln N

( )ln dRekeying messages

K’K’2121

K’K’1111

K’K’00

KK21 21 { K{ K2121’}’} KK11 11 { K{ K1111’}’} KK0 0 { K{ K00’}’}

KK31 31 { K{ K2121’}’} KK31 31 { K{ K1111’}’} KK31 31 { K{ K00’}’}


ala

nced

LK

H f

or

Secu

re M

ult

icast

Agenda

• Introduction




• Balanced LKH

• Ongoing work

• Conclusions


ala

nced

LK

H

for

Secu

re M

ult

icast

Problems with LKH

Length of rekeying messages (computation of effective bandwidth)

Latency for rekeying messages• When can the KS actually change the ciphering key

Suitability to real environments• If many changes happen suddenly, some updated

keys will never be used

Join/Leave pattern for multiparty games benchmark scenario


ala

nced

LK

H

for

Secu

re M

ult

icast

Updated keys not used

M2 Leaves de group

Before the rekeying messages reach the destination members M4 leaves the group

K´11 and K’0 have not been used

The same if now M’2 and M’4 join the group


KK2222KK2121 KK2323 KK2424

KK1111 KK1212

KK00


KK’’2121

KK’’1111

KK’’00

KK’’2222

KK’’’’1111

KK’’’’00Number of messages 4 Log2N


ala

nced

LK

H

for

Secu

re M

ult

icast

Lam-Gouda Proposal – Batch-LKH

Batch rekeying introduced by Lam and Gouda in 2001

Process all joinings and leavings periodically instead of individually

New joinings are located substituting leavings

If number of joinings exceeds leavings a subtree is constructed and placed under the shallowest leaf

The algorithm is efficient if and only if the tree is kept balanced all the time -> Not realistic approach.


ala

nced

LK

H

for

Secu

re M

ult

icast

Lam-Gouda Proposal not balanced

Member 4 and Member 8 leave the group

33,,2233,,11 33,,55 33,,66

22,,2222,,11 22,,33 22,,44

11,,11 11,,22

00,0,0

MM11 MM22

33,,44

MM44 MM66MM55MM33 MM77

33,,88

MM88

33,,33 33,,77


ala

nced

LK

H

for

Secu

re M

ult

icast


2 joinings and no leaving

33,,2233,,11 33,,55 33,,66

22,,11 22,,33

11,,11 11,,22

00,0,0

MM11 MM22 MM66MM55

MM77MM33

33,,33 33,,77

33,4,433,3,3

22,2,2

4,64,64,54,5

MM33 MM88

MM88


ala

nced

LK

H

for

Secu

re M

ult

icast


M5 and M6 leave the group

33,,2233,,11

22,,11

11,,11 11,,22

00,0,0

MM11 MM22

33,,55 33,,66

22,,33

MM66MM55

33,,33

MM77

33,,77

33,4,433,3,3

22,2,2

4,64,64,54,5

MM33 MM88

MM88


ala

nced

LK

H f

or

Secu

re M

ult

icast

Agenda

• Introduction




• Balanced LKH

• Ongoing work

• Conclusions


ala

nced

LK

H

for

Secu

re M

ult

icast

Balanced LKH

We allow members to change their position in the tree

Treat siblings of departed members as new joinings

KK3131 KK3333 KK3535 KK3636 KK3737 KK3838

KK2323 KK2424

KK1212

MM11

KK3232 KK3434

KK2222KK2121

KK1111

KK00

MM22 MM44 MM66MM55MM33 MM77 MM88


ala

nced

LK

H

for

Secu

re M

ult

icast

Balanced LKH

Prune the tree

Regroup remaining members with new joinings following a balanced algorithm

KK3535 KK3636 KK3737 KK3838

KK2323 KK2424

KK1212

MM66MM55 MM77 MM88

KK3131 KK3333

MM11 MM33

KK3333

MM33


ala

nced

LK

H

for

Secu

re M

ult

icast

Balanced LKH (performance evaluation)

Every batch ends with a balanced tree

Members can change their position in the tree(a modification of the GDOI is required)

Tree depth evolution for different batch periods in multiparty games environments


ala

nced

LK

H f

or

Secu

re M

ult

icast

Agenda

• Introduction




• Balanced LKH

• Ongoing work

• Conclusions


ala

nced

LK

H

for

Secu

re M

ult

icast

Ongoing work

Development of a Key Server for multicast streaming servers

Development of a JAVA library for tree based key management algorithms

Simulation of rekeying algorithms for multicast using NS-2

LKH support for GDOI

Human behavior modeling for multicast environments


ala

nced

LK

H f

or

Secu

re M

ult

icast

Agenda

• Introduction




• Balanced LKH

• Ongoing work

• Conclusions


ala

nced

LK

H

for

Secu

re M

ult

icast

Conclusions

Group communications have increasingly importance

The use of a common secret key provides data confidentiality and group authentication

The key must be updated every time membership changes (Perfect Forward and Backward Secrecy)

LKH algorithm is one of the most accepted for key management in group communications

LKH leaks some functionalities

LKH with batch rekeying does not lead to balanced trees

A new proposal have been presented


ala

nced

LK

H

for

Secu

re M

ult

icast

Contact Information

Josep Pegueroles

Telematics Engineering Dept.

Technical University of Catalonia

[email protected]

balanced lkh for secure multicast josep pegueroles and francisco rico-novella

Documents