Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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