The complex software structures and procedures to establish multicast group key distribution are analyzed, with resulting performance timings and trial applications reported. Existing solutions for very-large scale group key distribution with a hierarchical virtual tree topology are engineered for commercial applications using a public key infrastructure and open source Java security libraries. To solve a major but understated problem with existing schemes, the cost of initial key distribution,

more »

... privileged members are proposed. Comparison is made with existing proposals showing how the features of this proposal would impact. The paper contains review material on existing schemes, including the security flaws of some schemes. groups become large, beyond 1,000 members in [10], the logistics of key distribution pose a significant threat to the viability of any scheme. For example, to maintain forward security [11] [12], whereby leaving members do not have access to any future group key 1 , an approach which scales linearly requires re-keying of a new group key to all current members. This would be the case whether IGMP was used or not. For example, if each group member was initialised with their own Key for Encrypting a group Key, a KEK, then in a centralized scheme a single message could be multicast containing multiple copies of the group key, each copy encrypted with a different member's KEK. For a large group over 1000, and using a simple 56-bit Data Encryption Standard (DES) key [15] , the message size would be at least 8 kB and, hence, would be fragmented. In fact, groups very much larger than this are being contemplated with [12] mentioning 100,000, [16] mentioning 1 million members, and [17] mentioning 10 million members for pay television. For such large groups, even modest join/leave rates rapidly cause intolerable queues [18] at key server(s). However, it should be noted that for applications with large numbers of members such as pay-to-view, typically with only one sender, perfect forward (or backward) secrecy is not a requirement, as the broadcast takes place at a fixed time after pre-payments. A considerable number of multicast group key distribution schemes have been proposed, for surveys refer to [16][19][20][9]. The two multicast group key management research forums 2 [21][22], assuming centralized key management, have focused on: policy matters -how access to the group is authorized and authenticated, and how an encryption scheme is chosen; key management -when should the group key be changed and how is a new shared group key distributed; and data traffic encryption -the choice of suitable encryption methods. However, some of proposals remain complex, may have weaknesses in authentication, and are apparently unproven in the field. Published results may rely on simulations, e.g. for the Kronos [18] using the ns-2 network simulator, or simply algorithmic descriptions, rather than a software prototype such as that for Iolus [23] . A number of security flaws [24] [25] for at least one class of group key establishment algorithm have been identified (refer to Section 5.2). Mobile and wireless networks for multicast [26] introduce bandwidth restrictions, which for some applications have implications on key distribution latency, and which in its turn is related to message sizes. Such networks are more likely to have device nodes with reduced 1 A method has t-forward security [13] if and only if no t colluding evicted multicast group members can read any future communications. For some applications, (say) military ones, t-backward security is also necessary, whereby no t new group members can read any previous communications. Perfect Forward Secrecy (PFS) [13] is a differing and often desirable criterion, whereby compromise of long term keys (key encoding keys) does not lead to compromise of past session keys (group keys), and requires authenticated group key agreement, normally through authenticated Diffie-Helman exchange [14] . Group keys are symmetric, as the computational cost of asymmetric (public/private keys) encryption remains prohibitive. 2 The two research groups represent the IETF and IRTF organizations.