A Framework for Group Key Management for Multicast Security

1. A Framework for Group Key Management for Multicast Security by T. Hardjono, B. Cain, N. Doraswamy

2. 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)

3. 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

4. Further Outline • Issues of Group Key Management • Basic Model of the framework • Two Examples

5. 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

6. 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 • ...

7. 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

8. 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?)

9. 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

10. Scalability of protocols and membership management • Frequency of changes to the membership, which may lead to re-keying • Security managing entity (e.g. key server) might be the bottleneck and a attractive point for intruders • Workload of re-keying

11. Independence of GKM protocol • GKM protocol must be independent of the underlying multicast routing protocol

12. 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”

13. 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

14. 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

15. Access control and membership verification • Issue of the application, not the framework • Should be decoupled from the group key management protocol

16. 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!

17. 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

18. 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

19. The big picture KM: Key Manager BKM: Border Key Manager R: Router KT: Key Translator m: member Trunk Leaf KM KT m m m KM BKM R R R BKM KT R m m m Leaf

20. 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!

21. 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

22. 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)

23. Communication between the entities • is carried out using secure channels • mutual authentication • data confidentiality • date integrity • is implemented using IPsec

24. 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.

25. How does it work? (cont’d) • Question • Why are the KTs in the leaves and not in the trunk?

26. 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

27. Advantages of the framework (cont’d) • Long life of trunk keys • Independent re-key periods

28. Two Examples • One-to-many multicast • Many-to-many multicast • The given examples do not very well demonstrate the use of the framework

29. 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

30. One-to-many example (cont’d) • The sender must therefore define • the scope/size of each leaf region • the physical location • the trust relationship

31. 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

32. 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)

33. 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

34. 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