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 server
Wallner, 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 1999
Table 1: Storage and Transmission Costs
Number Degree Storage per user Transmissions to Transmissions
of 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 14
131072 2 18 33 17
177147 3 12 32 22
The 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 Options
5.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 the
Wallner, 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 + -
显示快捷键?