rfc2627.txt
来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,292 行 · 第 1/4 页
TXT
1,292 行
-------------------------- | | | S E R V E R | | | -------------------------- | | | | | . . . . | - - - |1| |2| |n| - - - Figure 1: Assumed Communication Architecture The scheme, advantages and disadvantages are enumerated in more detail below. Consider Figure 2 below. This figure illustrates the logical key distribution architecture, where keys exist only at the server and at the users. Thus, the server in this architecture would hold Keys A through O, and the KEKs of each user. User 11 in this architecture would hold its own unique KEK, and Keys F, K, N, and O.Wallner, et al. Informational [Page 12] RFC 2627 Key Management for Multicast June 1999 net key Key O ------------------------------------- intermediate | | keys | | Key M Key N ----------------- -------------------- | | | | | | | | Key I Key J Key K Key L -------- -------- --------- ---------- | | | | | | | | | | | | | | | | Key A Key B Key C Key D Key E Key F Key G Key H --- --- --- --- --- ---- ---- ---- | | | | | | | | | | | | | | | | - - - - - - - - - -- -- -- -- -- -- --|1| |2| |3| |4| |5| |6| |7| |8| |9| |10| |11| |12| |13| |14| |15| |16| - - - - - - - - - -- -- -- -- -- -- -- users Figure 2: Logical Key Distribution Architecture We now describe the organization of the key hierarchy and the setup process. It will be clear from the description how to add users after the hierarchy is in place; we will also describe the removal of a user. Note: The passing of the multicast group list and any negotiation protocols is not included in this discussion for simplicity purposes. We construct a rooted tree (from the bottom up) with one leaf corresponding to each user, as in Figure 2. (Though we have drawn a balanced binary tree for convenience, there is no need for the tree to be either balanced or binary - some preliminary analysis on tree shaping has been performed.) Each user establishes a unique pairwise key with the server. For users with transmission capability, this can be done using the public key exchange protocol. The situation is more complicated for receive-only users; it is easiest to assume these users have pre-placed key. Once each user has a pairwise key known to the server, the server generates (according to the security policy in place for that session) a key for each remaining node in the tree. The keys themselves should be generated by a robust process. We will also assume users have no information about keys they don't need. (Note: There are no users at these remaining nodes, (i.e., they are logical nodes) and the key for each node need only be generated by the serverWallner, et al. Informational [Page 13] RFC 2627 Key Management for Multicast June 1999 via secure means.) Starting with those nodes all of whose children are leaves and proceeding towards the root, the server transmits the key for each node, encrypted using the keys for each of that node's children. At the end of the process, each user can determine the keys corresponding to those nodes above her leaf. In particular, all users hold the root key, which serves as the common Net Key for the group. The storage requirement for a user at depth d is d+1 keys (Thus for the example in Figure 2, a user at depth d=4 would hold five keys. That is, the unique Key Encryption Key generated as a result of the pairwise key exchange, three intermediate node keys - each separately encrypted and transmitted, and the common Net Key for the multicast group which is also separately encrypted.) It is also possible to transmit all of the intermediate node keys and root node key in one message, where the node keys would all be encrypted with the unique pairwise key of the individual leaf. In this manner, only one transmission (of a larger message) is required per user to receive all of the node keys (as compared to d transmissions). It is noted for this method, that the leaf would require some means to determine which key corresponds to which node level. It is important to note that this approach requires additional processing capabilities at the server where other alternative approaches may not. In the worst case, a server will be responsible for generating the intermediate keys required in the architecture.5.4.1 The Exclusion Principle Suppose that User 11 (marked on Figure 2 in black) needs to be deleted from the multicast group. Then all of the keys held by User 11 (bolded Keys F, K, N, O) must be changed and distributed to the users who need them, without permitting User 11 or anyone else from obtaining them. To do this, we must replace the bolded keys held by User 11, proceeding from the bottom up. The server chooses a new key for the lowest node, then transmits it encrypted with the appropriate daughter keys (These transmissions are represented by the dotted lines). Thus for this example, the first key replaced is Key F, and this new key will be sent encrypted with User 12's unique pairwise key. Since we are proceeding from the bottom up, each of the replacement keys will have been replaced before it is used to encrypt another key. (Thus, for the replacement of Key K, this new key will be sent encrypted in the newly replaced Key F (for User 12) and will also be sent as one multicast transmission encrypted in the node key shared by Users 9 and 10 (Key E). For the replacement of Key N, this new key will be sent encrypted in the newly replaced Key K (for Users 9, 10,Wallner, et al. Informational [Page 14] RFC 2627 Key Management for Multicast June 1999 and 12) and will also be encrypted in the node key shared by Users 13, 14, 15, and 16 (Key L). For the replacement of Key O, this new key will be sent encrypted in the newly replaced Key N (for Users 9, 10, 12, 13, 14, 15, and 16) and will also be encrypted in the node key shared by Users 1, 2 , 3, 4, 5, 6, 7, and 8 (Key M).) The number of transmissions required is the sum of the degrees of the replaced nodes. In a k-ary tree in which a sits at depth d, this comes to at most kd-1 transmissions. Thus in this example, seven transmissions will be required to exclude User 11 from the multicast group and to get the other 15 users back onto a new multicast group Net Key that User 11 does not have access to. It is easy to see that the system is robust against collusion, in that no set of users together can read any message unless one of them could have read it individually. If the same strategy is taken as in the previous section to send multiple keys in one message, the number of transmissions required can be reduced even further to four transmissions. Note once again that the messages will be larger in the number of bits being transmitted. Additionally, there must exist a means for each leaf to determine which key in the message corresponds to which node of the hierarchy. Thus, in this example, for the replacement of keys F, K, N, and O to User 12, the four keys will be encrypted in one message under User 12's unique pairwise key. To replace keys K, N, and O for Users 9 and 10, the three keys will be encrypted in one message under the node key shared by Users 9 and 10 (Key E). To replace keys N and O for Users 13, 14, 15, 16, the two keys will be encrypted in one message under the node key shared by Users 13, 14, 15, and 16 (Key L). Finally, to replace key O for Users 1, 2 , 3, 4, 5, 6, 7, and 8, key O will be encrypted under the node key shared by Users 1, 2 , 3, 4, 5, 6, 7, and 8 (Key M). Thus the number of transmission required is at most (k-1)d. The following table demonstrates the removal of a user, and how the storage and transmission requirements grow with the number of users.Wallner, et al. Informational [Page 15] RFC 2627 Key Management for Multicast June 1999Table 1: Storage and Transmission CostsNumber Degree Storage per user Transmissions to Transmissionsof users (k) (d+1) rekey remaining to rekey participants of remaining multicast group- participants of one key per message multicast (kd-1) group - multiple keys per message (k-1)d 8 2 4 5 3 9 3 3 5 4 16 2 5 7 4 2048 2 12 21 11 2187 3 8 20 14131072 2 18 33 17177147 3 12 32 22The benefits of a scheme such as this are: 1. The costs of user storage and rekey transmissions are balanced and scalable as the number of users increases. This is not the case for [1], [2], or [4]. 2. The auxiliary keys can be used to transmit not only other keys, but also messages. Thus the hierarchy can be designed to place subgroups that wish to communicate securely (i.e. without transmitting to the rest of the large multicast group) under particular nodes, eliminating the need for maintenance of separate Net Keys for these subgroups. This works best if the users operate in a hierarchy to begin with (e.g., military operations), which can be reflected by the key hierarchy. 3. The hierarchy can be designed to reflect network architecture, increasing efficiency (each user receives fewer irrelevant messages). Also, server responsibilities can be divided up among subroots (all of which must be secure). 4. The security risk associated with receive-only users can be minimized by collecting such users in a particular area of the tree. 5. This approach is resistant to collusion among arbitrarily many users.Wallner, et al. Informational [Page 16] RFC 2627 Key Management for Multicast June 1999 As noted earlier, in the rekeying process after one user is compromised, in the case of one key per message, each replaced key must be decrypted successfully before the next key can be replaced (unless users can cache the rekey messages). This bottleneck could be a problem on a noisy or slow network. (If multiple users are being removed, this can be parallelized, so the expected time to rekey is roughly independent of the number of users removed.) By increasing the valences and decreasing the depth of the tree, one can reduce the storage requirements for users at the price of increased transmissions. For example, in the one key per message case, if n users are arranged in a k-ary tree, each user will need storage. Rekeying after one user is removed now requires transmissions. As k approaches n, this approaches the pairwise key scheme described earlier in the paper.5.4.2 Hierarchical Tree Approach Options5.4.2.1 Distributed Hierarchical Tree Approach The Hierarchical Tree Approach outlined in this section could be distributed as indicated in Section 5.2 to more closely resemble the proposal put forth in [4]. Subroots could exist at each of the nodes to handle any joining or rekeying that is necessary for any of the subordinate users. This could be particularly attractive to users which do not have a direct connection back to the Root. Recall as indicated in Section 5.2, that the trust placed in these subroots to act with the authority and security of a Root, is a potentially dangerous proposition. This thought is also echoed in [4]. Some practical recommendations that might be made for these subroots include the following. The subroots should not be allowed to change the multicast group participant list that has been provided to them from the Root. One method to accomplish this, would be for the Root to sign the list before providing it to the subroots. Authorized subroots could though be allowed to set up new multicast groups for users below them in the hierarchy. It is important to note that although this distribution may appear to provide some benefits with respect to the time required to initialize the multicast group (as compared to the time required to initialize the group as described in Section 5.4) and for periodic rekeying, it does not appear to provide any benefit in rekeying the multicast group when a user has been compromised. It is also noted that whatever the key management scheme is (hierarchical tree, distributed hierarchical tree, core based tree, GKMP, etc.), there will be a "hit" incurred to initialize theWallner, et al. Informational [Page 17] RFC 2627 Key Management for Multicast June 1999 multicast group with the first multicast group net key. Thus, the hierarchical tree approach does not suffer from additional complexity with comparison to the other schemes with respect to initialization.5.4.2.2 Multicast Group Formation Although this paper has presented the formation of the multicast group as being Root initiated, the hierarchical approach is consistent with user initiated joining. User initiated joining is the method of multicast group formation presented in [4]. User initiated joining may be desirable when some core subset of users in⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?