Download A Framework for Group Key Management for Multicast Security

A Framework for Group Key
Management for Multicast
Security
by T. Hardjono, B. Cain, N.
Doraswamy
Two planes

Network infrastructure plane
Functions and entities that define the
network (e.g. protocols, routers)

Key management plane
Functions and entities that define and
establish security in the network (e.g. GKM
protocols, IPsec, cryptosystems)
Two hierarchies within key
management plane

Trunk region:
– Contains only Group Key Manager(s)
(GKM), but no member hosts (senders,
receivers)

Leaf region:
– Contains member hosts
– Every member host is associated with at
least one GKM of its own region
Further Outline
Issues of Group Key Management
 Basic Model of the framework
 Two Examples

Issues of Group Key
Management
– Multicast application types
– Size and distribution of members
– Scalability of protocols and membership
management
– Independence of GKM protocol
– Trust-relationships
– Group authentication and sender
authentication
– Identities and anonymity
Issues of Group Key
Management (cont’d)
– Access control and membership
verification
– Failure of systems
– Denial of service attacks
– Authenticity of multicast routing exchanges
– Tamper-proof storage on network entities
– Security and practicality of protocols
– ...
Two general multicast
application types

One-to-many multicast
– One source of data, many receivers
– Two cases exist with respect to the data:


The authenticity of the data is of concern (e.g.
stock market data)
Their confidentiality is of concern (e.g. pay TV)
Receivers must subscribe to the group, hence
only the sender controls the key manager
Two general multicast
application types (cont’d)

Many-to-many multicast
– Relationship between members is equal
– Every member is both a sender and a
receiver
– Authenticity and confidentiality is of
concern (Why always both?)
Size and distribution of
members

IP multicast model is attractive
– Members can be throughout the Internet
– Source need not know the members

In GKMs which employ secure unicast
(e.g. to distribute keys to members) size
of the group and distribution of
members have an impact on scalability
Scalability of protocols and
membership management
Frequency of changes to the
membership, which may lead to rekeying
 Security managing entity (e.g. key
server) might be the bottleneck and a
attractive point for intruders
 Workload of re-keying

Independence of GKM
protocol

GKM protocol must be independent of
the underlying multicast routing protocol
Trust-relationships

On what basis can a security-related
entity be trusted (e.g. a member may
only trust entities physically within its
country)
“This problem ... is a difficult one”
Group authentication and
sender authentication

Group authentication
can be implicitly achieved with confidentiality
due to the possession of a common key

Sender authentication
can be achieved by e.g. public key
cryptography schemes -> may require a
public key infrastructure
Identities and anonymity

IP multicast
Identity of a receiver is reported to a router,
but not to the source

Secure multicast
Sender has to know the identity of the
receiver to allow him to join or not

Anonymity
Can only be achieved on application layer,
not on network layer due to IPsec
Access control and
membership verification
Issue of the application, not the
framework
 Should be decoupled from the group
key management protocol

Failure of systems
A failing entity must not allow to
compromise security information
 It must exhibit a ‘fail-closed’ behavoir

The other issues are not discussed!
Basic Model of the Framework

Network infrastructure plane
– Physical/Topological view
– Collection of autonomous systems (AS)
– Transit ASs and sub ASs
– Identifies the entities and functions that
define the network
Basic Model of the Framework
(cont’d)

Key management plane
– Functions and entities of the network
which implement security
– E.g. GKM protocols, IPsec, key generators,
key managers, ...
– divided into two regions:
trunk region and leaf region
The big picture
Trunk
KM
KM
Leaf
R BKM
R
BKM
KT R
m m m
Leaf
KT
m
R
m
m
KM: Key Manager
BKM: Border Key
Manager
R:
Router
KT: Key Translator
m: member
Key Manager

Tow types of KMs
– KMs within a region

do not participate in inter-region key
management
– Border KMs



bound the trunk regions
Every leaf region is associated with (at least)
one BKM
No clear definition of the tasks of a KM!
Key Translator

Translates payload
– from being encrypted under one key to
another
– must be done atomically and tamper-free
– may be applied to multicast data or for key
management purposes
Trunk keys and leaf keys
Each region has a different key
 The trunk key

– is only known to BKMs
– generated by a inter-region GKM protocol

The leaf key
– is known to the leaf and to the BKM of this
leaf
– is generated by a local GKM protocol (next
paper)
Communication between the
entities

is carried out using secure channels
– mutual authentication
– data confidentiality
– date integrity

is implemented using IPsec
How does it work?

This is partly my interpretation
– The sender encrypts the data using the
leaf key
– It sends the data to the trunk
– There, the data are decrypted (leaf key)
and again encrypted (trunk key). This is
done by the KTs.
– Before the trunk sends the data to the
destination leaf, the KT decrypts (trunk
key) and encrypts (leaf key) again.
How does it work? (cont’d)

Question
– Why are the KTs in the leaves and not in
the trunk?
Advantages of the framework

Scalability
– New leaf regions can be added,
independent of existing leaf regions
– Adding/dropping a member requires (at
most) re-keying within one region

Reduced complexity
– Each leaf region can use its own GKM
protocol
– Key management in trunk region is
independent from key management in leafs
Advantages of the framework
(cont’d)
Long life of trunk keys
 Independent re-key periods

Two Examples
One-to-many multicast
 Many-to-many multicast
 The given examples do not very well
demonstrate the use of the framework

One-to-many example

Assumptions:
– data have direct value for non-members
– attacker wants to redistribute to the widest
possible audience (e.g. pay TV)
– it is of the interest of the initiator/sender to
ensure that only members (subscribers)
get the data
One-to-many example (cont’d)

The sender must therefore define
– the scope/size of each leaf region
– the physical location
– the trust relationship
One-to-many example (cont’d)

The sender may choose
– direct control, i.e. all key managers are
within its leaf and associated with remote
leaves. (Hm... no trunk?)
– indirect control, i.e. the sender relies on
trusted entities of other organizations
Many-to-many example

Assumption
– attacker wants to provide data to a limited
audience
– it is of interest of all members to ensure
that only members get the data (e.g.
conference)
Many-to-many example
(cont’d)

A leaf region
– might be physically limited to one
member’s organization
– The leaf region’s BKM should be
administrated by the member itself
Conclusion

This is my conclusion. There isn’t one in
the paper
– The framework provides a scalable scheme
for group key management
– In general, the paper is not very concrete
– I think, more work is needed to have a
good basis for protocol design and
implementation