Network Working Group D. Wallner
Request for Comments: 2627 E. Harder
Category: Informational R. Agee
National Security Agency
June 1999
Network Working Group D. Wallner
Request for Comments: 2627 E. Harder
Category: Informational R. Agee
National Security Agency
June 1999
Key Management for Multicast: Issues and Architectures
组播密钥管理：问题与体系结构
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals [1,2,4]. The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group.
本报告讨论了多播通信会话的密钥管理难题。它主要关注密钥管理的两个主要方面，即使用公共网络密钥初始化多播组和重新设置多播组密钥。在用户妥协或出于其他原因（例如，定期重新密钥）时，可能需要重新密钥。特别是，本报告确定了一种允许安全折衷恢复的技术，同时对被排除用户的共谋具有鲁棒性。这是多播密钥管理的一个重要特征，大多数其他多播密钥管理方案[1,2,4]都没有详细说明这一点。该技术的优点在于，它最小化了为多播组重新设置密钥所需的传输次数，并且对多播组施加了最小的存储要求。
It is recognized that future networks will have requirements that will strain the capabilities of current key management architectures. One of these requirements will be the secure multicast requirement. The need for high bandwidth, very dynamic secure multicast communications is increasingly evident in a wide variety of commercial, government, and Internet communities. Specifically, the secure multicast requirement is the necessity for multiple users who share the same security attributes and communication requirements to securely communicate with every other member of the multicast group using a common multicast group net key. The largest benefit of the
人们认识到，未来网络的需求将对当前密钥管理体系结构的能力造成压力。其中一个要求是安全多播要求。在各种各样的商业、政府和互联网社区中，对高带宽、非常动态的安全多播通信的需求日益明显。具体而言，安全多播需求是共享相同安全属性和通信需求的多个用户使用公共多播组网络密钥与多播组的每个其他成员安全通信的必要性。最大的利益
multicast communication being that multiple receivers simultaneously get the same transmission. Thus the problem is enabling each user to determine/obtain the same net key without permitting unauthorized parties to do likewise (initializing the multicast group) and securely rekeying the users of the multicast group when necessary. At first glance, this may not appear to be any different than current key management scenarios. This paper will show, however, that future multicast scenarios will have very divergent and dynamically changing requirements which will make it very challenging from a key management perspective to address.
多播通信是指多个接收器同时获得相同的传输。因此，问题是使每个用户能够确定/获得相同的网络密钥，而不允许未经授权的各方也这样做（初始化多播组），并在必要时安全地重新设置多播组用户的密钥。乍一看，这似乎与当前的密钥管理场景没有任何不同。然而，本文将表明，未来的多播场景将有非常不同且动态变化的需求，这将使从密钥管理的角度来解决这一问题非常具有挑战性。
The networks of the future will be able to support gigabit bandwidths for individual users, to large groups of users. These users will possess various quality of service options and multimedia applications that include video, voice, and data, all on the same network backbone. The desire to create small groups of users all interconnected and capable of communicating with each other, but who are securely isolated from all other users on the network is being expressed strongly by users in a variety of communities.
未来的网络将能够支持个人用户、大用户群的千兆带宽。这些用户将拥有各种服务质量选项和多媒体应用程序，包括视频、语音和数据，所有这些都在同一网络主干上。各种社区的用户强烈地表达了这样一种愿望，即创建一个小的用户组，所有用户都相互连接，能够相互通信，但与网络上的所有其他用户安全隔离。
The key management infrastructure must support bandwidths ranging from kilobits/second to gigabits/second, handle a range of multicast group sizes, and be flexible enough for example to handle such communications environments as wireless and mobile technologies. In addition to these performance and communications requirements, the security requirements of different scenarios are also wide ranging. It is required that users can be added and removed securely and efficiently, both individually and in bulk. The system must be resistant to compromise, insofar as users who have been dropped should not be able to read any subsequent traffic, even if they share their secret information. The costs we seek to minimize are time required for setup, storage space for each end user, and total number of transmissions required for setup, rekey and maintenance. It is also envisioned that any proposed multicast security mechanisms will be implemented no lower than any layer with the characteristics of the network layer of the protocol stack. Bandwidth efficiency for any key management system must also be considered. The trade-off between security and performance of the entire multicast session establishment will be discussed in further detail later in this document.
密钥管理基础设施必须支持从千比特/秒到千兆比特/秒的带宽，处理一系列多播组大小，并具有足够的灵活性，例如处理无线和移动技术等通信环境。除了这些性能和通信要求外，不同场景的安全要求也非常广泛。要求可以安全有效地添加和删除用户，无论是单独添加还是批量删除。系统必须能够抵抗泄露，因为被丢弃的用户不应该能够读取任何后续流量，即使他们共享他们的秘密信息。我们寻求最小化的成本是设置所需的时间、每个最终用户的存储空间以及设置、重新设置和维护所需的传输总数。还可以设想，任何拟议的多播安全机制的实现将不低于具有协议栈的网络层特征的任何层。还必须考虑任何密钥管理系统的带宽效率。整个多播会话建立的安全性和性能之间的折衷将在本文档后面进行更详细的讨论。
The following section will explain several potential scenarios where multicast capabilities may be needed, and quantify their requirements from both a performance and security perspective. It will be followed in Section 4.0 by a list of factors one must consider when designing a potential solution. While there are several security services that will be covered at some point in this document, much of the focus of this document has been on the generation and distribution of multicast group net keys. It is assumed that all potential multicast participants either through some manual or automated, centralized or decentralized mechanism have received initialization keying material (e.g. certificates). This document does not address the initialization key distribution issue. Section 5 will then detail several potential multicast key management architectures, manual (symmetric) and public key based (asymmetric), and highlight their relative advantages and disadvantages (Note:The list of advantages and disadvantages is by no means all inclusive.). In particular, this section emphasizes our technique which allows for secure compromise recovery.
下一节将解释可能需要多播功能的几个潜在场景，并从性能和安全角度量化它们的需求。在第4部分中，将列出设计潜在解决方案时必须考虑的因素的列表。虽然本文档将在某个时候介绍几种安全服务，但本文档的大部分重点是多播组网络密钥的生成和分发。假设所有潜在的多播参与者（通过某种手动或自动、集中或分散的机制）都已收到初始化密钥材料（例如证书）。本文档不解决初始化密钥分发问题。第5节将详细介绍几种潜在的多播密钥管理体系结构，即手动（对称）和基于公钥（非对称），并强调它们的相对优势和劣势（注意：优势和劣势列表并不包括所有）。本节特别强调我们的技术，它允许安全的折衷恢复。
There are a variety of potential scenarios that may stress the key management infrastructure. These scenarios include, but are not limited to, wargaming, law enforcement, teleconferencing, command and control conferencing, disaster relief, and distributed computing. Potential performance and security requirements, particularly in terms of multicast groups that may be formed by these users for each scenario, consists of the potential multicast group sizes, initialization requirements (how fast do users need to be brought on-line), add/drop requirements (how fast a user needs to be added or deleted from the multicast group subsequent to initialization), size dynamics (the relative number of people joining/leaving these groups per given unit of time), top level security requirements, and miscellaneous special issues for each scenario. While some scenarios describe future secure multicast requirements, others have immediate security needs.
存在各种可能会对关键管理基础架构造成压力的场景。这些场景包括但不限于作战模拟、执法、电话会议、指挥和控制会议、救灾和分布式计算。潜在的性能和安全要求，特别是这些用户在每个场景中可能形成的多播组，包括潜在的多播组大小、初始化要求（用户需要多快上线）、添加/删除要求（初始化后需要从多播组中添加或删除用户的速度）、大小动态（每个给定时间单位加入/离开这些组的相对人数），顶级安全需求，以及每个场景的各种特殊问题。虽然一些场景描述了未来的安全多播需求，但其他场景有即时的安全需求。
As examples, let us consider two scenarios, distributed gaming and teleconferencing.
作为例子，让我们考虑两个场景，分布式游戏和电话会议。
Distributed gaming deals with the government's need to simulate a conflict scenario for the purposes of training and evaluation. In addition to actual communications equipment being used, this concept would include a massive interconnection of computer simulations containing, for example, video conferencing and image processing. Distributed gaming could be more demanding from a key management perspective than an actual scenario for several reasons. First, the nodes of the simulation net may be dispersed throughout the country.
分布式游戏处理政府出于培训和评估目的模拟冲突场景的需要。除了正在使用的实际通信设备外，这一概念还将包括计算机模拟的大规模互连，例如包括视频会议和图像处理。从密钥管理的角度来看，分布式游戏可能比实际场景要求更高，原因有几个。首先，模拟网络的节点可能分散在全国各地。
Second, very large bandwidth communications, which enable the possibility for real time simulation capabilities, will drive the need to drop users in and out of the simulation quickly. This is potentially the most demanding scenario of any considered.
其次，非常大的带宽通信使实时仿真能力成为可能，这将促使用户快速进出仿真。这可能是所考虑的所有方案中要求最高的方案。
This scenario may involve group sizes of potentially 1000 or more participants, some of which may be collected in smaller subgroups. These groups must be initialized very rapidly, for example, in a ten second total initialization time. This scenario is also very demanding in that users may be required to be added or dropped from the group within one second. From a size dynamics perspective, we estimate that approximately ten percent of the group members may change over a one minute time period. Data rate requirements are broad, ranging from kilobits per second (simulating tactical users) to gigabits per second (multicast video). The distributed gaming scenario has a fairly thorough set of security requirements covering access control, user to user authentication, data confidentiality, and data integrity. It also must be "robust" which implies the need to handle noisy operating environments that are typical for some tactical devices. Finally, the notion of availability is applied to this scenario which implies that the communications network supplying the multicast capability must be up and functioning a specified percentage of the time.
这种情况可能涉及1000名或更多参与者的群体规模，其中一些参与者可能被收集在更小的子群体中。必须非常快速地初始化这些组，例如，总初始化时间为10秒。此场景的要求也很高，因为可能需要在一秒钟内从组中添加或删除用户。从规模动态的角度来看，我们估计大约10%的团队成员可能会在一分钟内发生变化。数据速率要求很高，从每秒千比特（模拟战术用户）到每秒千兆比特（多播视频）。分布式游戏场景有一套相当全面的安全要求，包括访问控制、用户对用户身份验证、数据机密性和数据完整性。它还必须具有“鲁棒性”，这意味着需要处理一些战术设备典型的噪声操作环境。最后，可用性的概念应用于该场景，这意味着提供多播功能的通信网络必须在指定的时间百分比内启动并运行。
The teleconference scenario may involve group sizes of potentially 1000 or more participants. These groups may take up to minutes to be initialized. This scenario is less demanding in that users may be required to be added or dropped from the group within seconds. From a size dynamics perspective, we estimate that approximately ten percent of the group members may change over a period of minutes. Data rate requirements are broad, ranging from kilobits per second to 100's of Mb per second. The teleconference scenario also has a fairly thorough set of security requirements covering access control, user to user authentication, data confidentiality, data integrity, and non-repudiation. The notion of availability is also applicable to this scenario. The time frame for when this scenario must be provided is now.
电话会议场景可能涉及1000名或更多参与者的群体规模。初始化这些组可能需要几分钟的时间。此场景要求较低，因为可能需要在几秒钟内从组中添加或删除用户。从规模动态的角度来看，我们估计大约10%的团队成员可能会在几分钟内发生变化。数据速率要求很高，从每秒千比特到每秒100 Mb不等。电话会议场景还有一套相当全面的安全需求，包括访问控制、用户对用户身份验证、数据机密性、数据完整性和不可否认性。可用性的概念也适用于此场景。必须提供此场景的时间范围现在已确定。
There are many factors that must be taken into account when developing the desired key management architecture. Important issues for key management architectures include level (strength) of security, cost, initializing the system, policy concerns, access control procedures, performance requirements and support mechanisms. In addition, issues particular to multicast groups include:
在开发所需的密钥管理体系结构时，必须考虑许多因素。密钥管理体系结构的重要问题包括安全级别（强度）、成本、系统初始化、策略问题、访问控制过程、性能要求和支持机制。此外，多播组特有的问题包括：
1. What are the security requirements of the group members? Most likely there will be some group controller, or controllers. Do the other members possess the same security requirements as the controller(s)?
1. 集团成员的安全要求是什么？很可能会有一些组控制器。其他成员是否具有与控制员相同的安全要求？
2. Interdomain issues - When crossing from one "group domain" to another domain with a potentially different security policy, which policy is enforced? An example would be two users wishing to communicate, but having different cryptoperiods and/or key length policies.
2. 域间问题-当使用可能不同的安全策略从一个“组域”跨越到另一个域时，将强制执行哪个策略？例如，两个用户希望通信，但具有不同的加密周期和/或密钥长度策略。
3. How does the formation of the multicast group occur? Will the group controller initiate the user joining process, or will the users initiate when they join the formation of the multicast group?
3. 多播组是如何形成的？组控制器将启动用户加入过程，还是用户在加入多播组时启动？
4. How does one handle the case where certain group members have inferior processing capabilities which could delay the formation of the net key? Do these users delay the formation of the whole multicast group, or do they come on-line later enabling the remaining participants to be brought up more quickly?
4. 如果某些组成员的处理能力较差，可能会延迟网络密钥的形成，如何处理这种情况？这些用户是推迟了整个多播组的形成，还是推迟了他们的上线时间，从而使剩下的参与者能够更快地被召集起来？
5. One must minimize the number of bits required for multicast group net key distribution. This greatly impacts bandwidth limited equipments.
5. 必须最小化多播组网络密钥分发所需的比特数。这极大地影响了带宽有限的设备。
All of these and other issues need to be taken into account, along with the communication protocols that will be used which support the desired multicast capability. The next section addresses some of these issues and presents some candidate architectures that could be used to tackle the key management problem for multicasting.
需要考虑所有这些和其他问题，以及将使用的支持所需多播功能的通信协议。下一节将讨论其中的一些问题，并介绍一些可用于解决多播密钥管理问题的候选体系结构。
There are several basic functions that must be performed in order for a secure multicast session to occur. The order in which these functions will be performed, and the efficiency of the overall solution results from making trade-offs of the various factors listed above. Before looking at specific architectures, these basic functions will be outlined, along with some definition of terms that will be used in the representative architectures. These definitions and functions are as follows:
为了实现安全多播会话，必须执行几个基本功能。这些功能的执行顺序以及整体解决方案的效率是通过权衡上述各种因素得出的。在查看特定体系结构之前，将概述这些基本功能，以及将在代表性体系结构中使用的一些术语定义。这些定义和功能如下：
1. Someone determines the need for a multicast session, sets the security attributes for that particular session (e.g., classification levels of traffic, algorithms to be used, key variable bit lengths, etc.), and creates the group access control list which we will call the initial multicast group participant list. The entity which performs these functions will be called the INITIATOR. At this point, the multicast group participant list is strictly a list of users who the initiator wants to be in the multicast group.
1. 有人确定对多播会话的需求，设置该特定会话的安全属性（例如，流量的分类级别、要使用的算法、密钥可变位长度等），并创建组访问控制列表，我们将其称为初始多播组参与者列表。执行这些功能的实体称为启动器。此时，多播组参与者列表严格地说是发起方希望加入多播组的用户列表。
2. The initiator determines who will control the multicast group. This controller will be called the ROOT (or equivalently the SERVER). Often, the initiator will become the root, but the possibility exists where this control may be passed off to someone other than the initiator. (Some key management architectures employ multiple roots, see [4].) The root's job is to perform the addition and deletion of group participants, perform user access control against the security attributes of that session, and distribute the traffic encryption key for the session which we will call the multicast group NET KEY. After initialization, the entity with the authority to accept or reject the addition of future group participants, or delete current group participants is called the LIST CONTROLLER.
2. 启动器确定谁将控制多播组。此控制器将被称为根（或等效为服务器）。通常，发起者将成为根，但存在将此控制传递给发起者以外的其他人的可能性。（一些密钥管理体系结构使用多个根，请参见[4]）根的工作是执行组参与者的添加和删除，针对该会话的安全属性执行用户访问控制，并为该会话分发流量加密密钥，我们称之为多播组网络密钥。初始化后，具有接受或拒绝添加未来组参与者或删除当前组参与者权限的实体称为列表控制器。
This may or may not be the initiator. The list controller has been distinguished from the root for reasons which will become clear later. In short, it may be desirable for someone to have the authority to accept or reject new members, while another party (the root) would actually perform the function.
这可能是也可能不是启动器。列表控制器已与根控制器区分开来，原因将在稍后明确。简言之，一个人有权接受或拒绝新成员可能是可取的，而另一方（根）将实际履行这一职能。
3. Every participant in the multicast session will be referred to as a GROUP PARTICIPANT. Specific group participants other than the root or list controller will be referred to as LEAVES.
3. 多播会话中的每个参与者都将被称为组参与者。除根控制器或列表控制器之外的特定组参与者将被称为叶子。
4. After the root checks the security attributes of the participants listed on the multicast group participant list to make sure that they all support the required security attributes, the root will then pass the multicast group list to all other participants and create and distribute the Net Key. If a participant on the multicast group list did not meet the required security attributes, the leaf must be deleted from the list.
4. 在root用户检查多播组参与者列表上列出的参与者的安全属性以确保他们都支持所需的安全属性之后，root用户将把多播组列表传递给所有其他参与者，并创建和分发网络密钥。如果多播组列表上的参与者不符合所需的安全属性，则必须从列表中删除该叶。
Multiple issues can be raised with the distribution of the multicast group list and Net Key.
多播组列表和网络密钥的分发可能会引发多个问题。
a. An issue exists with the time ordering of these functions. The multicast group list could be distributed before or after the link is secured (i.e. the Net Key is distributed).
a. 这些函数的时间顺序存在问题。多播组列表可以在链路安全之前或之后分发（即，分发网络密钥）。
b. An issue exists when a leaf refuses to join the session. If a leaf refuses to join a session, we can send out a modified list before sending out the Net Key, however sending out modified lists, potentially multiple times, would be inefficient. Instead, the root could continue on, and would not send the Net Key to those participants on the list who rejected the session.
b. 叶拒绝加入会话时存在问题。如果一个叶拒绝加入会话，我们可以在发送Net密钥之前发送一个修改过的列表，但是发送修改过的列表（可能多次）将是低效的。相反，root可以继续，并且不会将Net密钥发送给列表中拒绝会话的参与者。
For the scenario architectures which follow, we assume the multicast group list will be distributed to the group participants once before the Net Key is distributed. Unlike the scheme described in [4], we recommend that the multicast group participant list be provided to all leaves. By distributing this list to the leaves, it allows them to determine upfront whether they desire to participate in the multicast group or not, thus saving potentially unnecessary key exchanges.
对于下面的场景架构，我们假设在分发网络密钥之前，多播组列表将分发给组参与者一次。与[4]中描述的方案不同，我们建议向所有叶子提供多播组参与者列表。通过将此列表分发给叶子，它允许它们预先确定是否希望参与多播组，从而节省可能不必要的密钥交换。
Four potential key management architectures to distribute keying material for multicast sessions are presented. Recall that the features that are highly desirable for the architecture to possess include the time required to setup the multicast group should be minimized, the number of transmissions should be minimized, and memory/storage requirements should be minimized. As will be seen, the first three proposals each fall short in a different aspect of these desired qualities, whereas the fourth proposal appears to strike a balance in the features desired. Thus, the fourth proposal is the one recommended for general implementation and use.
提出了四种潜在的密钥管理体系结构，用于为多播会话分发密钥材料。回想一下，对于体系结构来说非常需要具备的特性包括应该最小化设置多播组所需的时间、应该最小化传输的数量以及应该最小化内存/存储需求。正如将要看到的，前三个提案在这些期望质量的不同方面都有不足之处，而第四个提案似乎在期望的特征方面取得了平衡。因此，第四项建议是建议普遍实施和使用的建议。
Please note that these approaches also address securely eliminating users from the multicast group, but don't specifically address adding new users to the multicast group following initial setup because this is viewed as evident as to how it would be performed.
请注意，这些方法还解决了安全地从多播组中删除用户的问题，但没有专门解决在初始设置后向多播组添加新用户的问题，因为这被视为是如何执行的。
Through manual key distribution, symmetric key is delivered without the use of public key exchanges. To set up a multicast group Net Key utilizing manual key distribution would require a sequence of events where Net Key and spare Net Keys would be ordered by the root of the multicast session group. Alternate (supersession) Net Keys are ordered (by the root) to be used in case of a compromise of a group participant(s). The Net Keys would be distributed to each individual
通过手动密钥分发，可以在不使用公钥交换的情况下传递对称密钥。要使用手动密钥分配设置多播组网络密钥，需要一系列事件，其中网络密钥和备用网络密钥将由多播会话组的根用户进行排序。备用（替代）网络密钥（由根用户）排序，以便在组参与者妥协时使用。网络密钥将分发给每个人
group participant, often through some centralized physical intermediate location. At some predetermined time, all group participants would switch to the new Net Key. Group participants use this Net Key until a predetermined time when they need another new Net Key. If the Net Key is compromised during this time, the alternate Net Key is used. Group participants switch to the alternate Net Key as soon as they receive it, or upon notification from the root that everyone has the new Net Key and thus the switch over should take place. This procedure is repeated for each cryptoperiod.
组参与者，通常通过一些集中的物理中间位置。在某个预定时间，所有组参与者都将切换到新的网络密钥。组参与者使用此网络密钥，直到他们需要另一个新网络密钥的预定时间。如果在此期间网络密钥被泄露，则使用备用网络密钥。组参与者在收到备用网络密钥后，或在收到来自根用户的通知（每个人都有新的网络密钥，因此应进行切换）后，立即切换到备用网络密钥。对于每个加密周期，重复此过程。
A scheme like this may be attractive because the methods exist today and are understood by users. Unfortunately, this type of scheme can be time consuming to set up the multicast group based on time necessary to order keying material and having it delivered. For most real time scenarios, this method is much too slow.
这样的方案可能很有吸引力，因为这些方法现在已经存在，并且被用户理解。不幸的是，根据订购密钥材料和交付密钥材料所需的时间来建立多播组，这种类型的方案可能非常耗时。对于大多数实时场景，这种方法太慢了。
This approach is a brute force method to provide a common multicast group Net Key to the group participants. In this scheme, the initiator sets the security attributes for a particular session, generates a list of desired group participants and transmits the list to all group participants. The leaves then respond with an initial acceptance or rejection of participation. By sending the list up front, time can be saved by not performing key exchanges with people who rejected participation in the session. The root (who for this and future examples is assumed to be the initiator) generates a pairwise key with one of the participants (leaves) in the multicast group using some standard public key exchange technique (e.g., a Diffie-Hellman public key exchange.) The root will then provide the security association parameters of the multicast (which may be different from the parameters of the initial pairwise key) to this first leaf. Parameters may include items such as classification and policy. Some negotiation (through the use of a Security Association Management Protocol, or SAMP) of the parameters may be necessary. The possibility exists for the leaf to reject the connection to the multicast group based on the above parameters and multicast group list. If the leaf rejects this session, the root will repeat this process with another leaf.
该方法是一种强力方法，用于向组参与者提供公共多播组网络密钥。在该方案中，发起方为特定会话设置安全属性，生成所需组参与者的列表，并将该列表发送给所有组参与者。然后，叶子以最初接受或拒绝参与的方式回应。通过提前发送列表，不与拒绝参加会议的人员进行关键交流可以节省时间。root用户（在此示例和未来示例中假定其为发起方）使用某种标准公钥交换技术（例如Diffie-Hellman公钥交换）与多播组中的一个参与者（叶子）生成成对密钥。然后root用户将提供多播的安全关联参数（可能不同于初始成对密钥的参数）添加到此第一个叶。参数可能包括分类和策略等项。某些协商（通过使用安全关联管理协议或SAMP）可能需要一个或多个参数。叶可能会根据上述参数和多播组列表拒绝与多播组的连接。如果叶拒绝此会话，则根将对另一个叶重复此过程。
Once a leaf accepts participation in the multicast session, these two then choose a Net Key to be used by the multicast group. The Net Key could be generated through another public key exchange between the two entities, or simply chosen by the root, depending upon the policy which is in place for the multicast group ( i.e. this policy decision will not be a real time choice). The issue here is the level of trust that the leaf has in the root. If the initial pairwise key exchange provides some level of user authentication, then it seems
一旦一个叶子接受了多播会话的参与，这两个成员就可以选择一个网络密钥供多播组使用。网络密钥可以通过两个实体之间的另一个公钥交换生成，或者由根用户简单地选择，这取决于多播组的策略（即，此策略决策将不是实时选择）。这里的问题是叶在根中的信任级别。如果最初的成对密钥交换提供了某种程度的用户身份验证，那么
adequate to just have the root select the Net Key at this stage. Another issue is the level of trust in the strength of the security of the generated key. Through a cooperative process, both entities (leaf and root) will be providing information to be used in the formation of the Net Key.
在这个阶段，只需让root用户选择Net键就足够了。另一个问题是对生成密钥的安全性强度的信任级别。通过协作过程，两个实体（叶和根）将提供用于形成网络密钥的信息。
The root then performs a pairwise key exchange with another leaf and optionally performs the negotiation discussed earlier. Upon acceptance by the leaf to join the multicast group, the root sends the leaf the Net Key.
然后，根目录执行与另一个叶目录的成对密钥交换，并可选地执行前面讨论的协商。当叶接受加入多播组时，根向叶发送网络密钥。
This pairwise key exchange and Net Key distribution continues for all N users of the multicast group.
这种成对密钥交换和网络密钥分发将继续用于多播组的所有N个用户。
Root/leaves cache pairwise keys for future use. These keys serve as Key Encryption Keys (KEKs) used for rekeying leaves in the net at a later time. Only the root will cache all of the leaves' pairwise keys. Each individual leaf will cache only its own unique pairwise Key Encryption Key.
根/叶缓存成对密钥以备将来使用。这些密钥用作密钥加密密钥（KEK），用于稍后对网络中的叶子重新设置密钥。只有根将缓存所有叶的成对键。每个单独的叶将只缓存自己唯一的成对密钥加密密钥。
There are two cases to consider when caching the KEKs. The first case is when the Net key and KEK are per session keys. In this case, if one wants to exclude a group participant from the multicast session (and rekey the remaining participants with a new Net Key), the root would distribute a new Net key encrypted with each individual KEK to every legitimate remaining participant. These KEKs are deleted once the multicast session is completed.
缓存KEKS时需要考虑两种情况。第一种情况是，Net密钥和KEK是每会话密钥。在这种情况下，如果希望将组参与者从多播会话中排除（并使用新的网络密钥对剩余参与者重新设置密钥），root用户将向每个合法的剩余参与者分发使用每个KEK加密的新网络密钥。一旦多播会话完成，这些KEK将被删除。
The second case to consider is when the KEKs are valid for more than one session. In this case, the Net Key may also be valid for multiple sessions, or the Net Key may still only be valid for one session as in the above case. Whether the Net Key is valid for one session or more than one session, the KEK will be cached. If the Net Key is only valid per session, the KEKs will be used to encrypt new Net Keys for subsequent multicast sessions. The deleting of group participants occurs as in the previous case described above, regardless of whether the Net Key is per session or to be used for multiple sessions.
要考虑的第二个情况是当KEKs对于一个以上会话有效时。在这种情况下，网络密钥也可能对多个会话有效，或者网络密钥可能仍然只对一个会话有效，如上述情况。无论网络密钥对一个会话还是多个会话有效，都将缓存KEK。如果网络密钥仅对每个会话有效，则KEK将用于加密后续多播会话的新网络密钥。与前面描述的情况一样，删除组参与者，而不管网络密钥是每个会话还是用于多个会话。
A scheme like this may be attractive to a user because it is a straightforward extension of certifiable public key exchange techniques. It may also be attractive because it does not involve third parties. Only the participants who are part of the multicast session participate in the keying mechanism. What makes this scheme so undesirable is that it will be transmission intensive as we scale
这样的方案可能对用户有吸引力，因为它是可认证公钥交换技术的直接扩展。它也可能具有吸引力，因为它不涉及第三方。只有属于多播会话一部分的参与者才参与密钥机制。这一方案之所以如此不受欢迎，是因为随着规模的扩大，它将是传输密集型的
up in numbers, even for the most computationally efficient participants, not to mention those with less capable hardware (tactical, wireless, etc.). Every time the need arises to drop an "unauthorized" participant, a new Net Key must be distributed.
即使是计算效率最高的参与者，数量也在增加，更不用说那些硬件能力较差（战术、无线等）的参与者了。每次需要删除“未经授权”的参与者时，必须分发新的网络密钥。
This distribution requires a transmission from the Root to each remaining participant, whereby the new Net Key will be encrypted under the cover of each participant's unique pairwise Key Encryption Key (KEK).
此分发需要从根用户到每个剩余参与者的传输，由此，新的网络密钥将在每个参与者的唯一成对密钥加密密钥（KEK）的保护下进行加密。
Note: This approach is essentially the same as one proposal to the Internet Engineering Task Force (IETF) Security Subworking Group [Ref 1,2].
注：该方法基本上与互联网工程任务组（IETF）安全子工作组的一项提案相同[Ref 1,2]。
Also note that there exist multiple twists to an approach like this. For example, instead of having the root do all N key exchanges, the root could pass some of this functionality (and control) to a number of leaves beneath him. For example, the multicast group list could be split in half and the root tells one leaf to take half of the users and perform a key exchange with them (and then distribute the Net key) while the root will take care of the other half of the list. (The chosen leaves are thus functioning as a root and we can call them "subroots." These subroots will have leaves beneath them, and the subroots will maintain the KEK of each leaf beneath it.) This scales better than original approach as N becomes large. Specifically, it will require less time to set up (or rekey) the multicast net because the singular responsibility of performing pairwise key exchanges and distributing Net Key will be shared among multiple group participants and can be performed in parallel, as opposed to the root only distributing the Net Key to all of the participants.
还要注意的是，像这样的方法存在多个曲折。例如，根用户可以将一些功能（和控制）传递给他下面的一些叶子，而不是让根用户进行所有N个键的交换。例如，可以将多播组列表一分为二，根节点告诉一个叶节点接收一半的用户，并与他们进行密钥交换（然后分发网络密钥），而根节点负责处理列表的另一半。（因此，所选择的叶子起着根的作用，我们可以称之为“子轨道”。这些子轨道下面将有叶子，子轨道将保持每个叶子下面的KEK。）当N变大时，这种方法比原来的方法更好。具体地说，建立（或重新设置）多播网络所需的时间更少，因为执行成对密钥交换和分发网络密钥的单一责任将在多个组参与者之间共享，并且可以并行执行，而不是根用户仅将网络密钥分发给所有参与者。
This scheme is not without its own security concerns. This scheme pushes trust down to each subgroup controller - the root assumes that these "subroot" controllers are acting in a trustworthy way. Every control element (root and subroots) must remain in the system throughout the multicast. This effectively makes removing someone from the net (especially the subroots) harder and slower due to the distributed control. When removing a participant from the multicast group which has functioned on behalf of the root, as a subroot, to distribute Net Key, additional steps will be necessary. A new subroot must be delegated by the root to replace the removed subroot. A key exchange (to generate a new pairwise KEK) must occur between the new subroot and each leaf the removed subroot was responsible for. A new Net Key will now be distributed from the root, to the subroots, and to the leaves. Note that this last step would have been the only step required if the removed party was a leaf with no controlling responsibilities.
这一方案本身也存在安全问题。此方案将信任向下推给每个子组控制器-根节点假定这些“子节点”控制器以可靠的方式运行。在整个多播过程中，每个控制元素（根节点和子节点）都必须保留在系统中。由于分布式控制，这有效地使得从网络中删除某人（尤其是子轨迹）变得越来越困难和缓慢。当从多播组中删除一个参与者（该多播组作为子角色代表根用户运行）以分发网络密钥时，需要执行其他步骤。根用户必须委派一个新的子轨迹来替换已移除的子轨迹。新的子轨道和移除的子轨道负责的每个叶之间必须进行密钥交换（以生成新的成对KEK）。现在将从根节点、子节点和叶节点分发一个新的网络密钥。请注意，如果被删除方是一个没有控制责任的leaf，那么最后这一步将是唯一需要的步骤。
Let us suppose we have N leaves. The Root performs a public key exchange with each leaf i (i= 1,2, ..., N). The Root will cache each pairwise KEK. Each leaf stores their own KEK. The root would provide the multicast group list of participants and attributes to all users. Participants would accept or reject participation in the multicast session as described in previous sections. The root encrypts the Net Key for the Multicast group to each leaf, using their own unique KEK(i). (The Root either generated this Net Key himself, or cooperatively generated with one of the leaves as was discussed earlier). In addition to the encrypted Net Key, the root will also encrypt something called complementary variables and send them to the leaves.
让我们假设我们有N片叶子。根与每个叶i（i=1,2，…，N）执行公钥交换。根目录将缓存每个成对的KEK。每片叶子都有自己的桶。root将向所有用户提供参与者和属性的多播组列表。如前几节所述，参与者将接受或拒绝参与多播会话。根用户使用自己唯一的KEK（i）将多播组的网络密钥加密到每个叶。（根或者自己生成这个网络密钥，或者像前面讨论的那样与一片叶子协同生成）。除了加密的网络密钥外，根还将加密称为互补变量的内容，并将它们发送到叶。
A leaf will NOT receive his own complementary variable, but he will receive the other N-1 leaf complementary variables. The root sends the Net Key and complementary variables j, where j=1,2,...,N and j not equal to i, encrypted by KEK(i) to each leaf. Thus, every leaf receives and stores N variables which are the Net key, and N-1 complementary variables.
一片叶子不会收到他自己的补充变量，但他会收到其他N-1片叶子的补充变量。根向每个叶发送网络密钥和补充变量j，其中j=1,2，…，N和j不等于i，由KEK（i）加密。因此，每个叶接收并存储N个变量（作为网络键）和N-1个互补变量。
Thus to cut a user from the multicast group and get the remaining participants back up again on a new Net Key would involve the following. Basically, to cut leaf number 20 out of the net, one message is sent out that says "cut leaf 20 from the net." All of the other leaves (and Root) generate a new Net Key based on the current Net Key and Complementary variable 20. [Thus some type of deterministic key variable generation process will be necessary for all participants of the multicast group]. This newly generated variable will be used as the new Net Key by all remaining participants of the multicast group. Everyone except leaf 20 is able to generate the new Net Key, because they have complementary variable 20, but leaf 20 does not.
因此，要从多播组中删除一个用户，并让剩余的参与者在新的网络密钥上重新备份，将涉及以下内容。基本上，要从网络中删除叶号20，会发送一条消息，上面写着“从网络中删除叶20”。所有其他叶（和根）都会基于当前的网络键和互补变量20生成一个新的网络键。[因此，多播组的所有参与者都需要某种类型的确定性密钥变量生成过程]。这个新生成的变量将被多播组的所有剩余参与者用作新的网络密钥。除叶20之外的所有人都能够生成新的网络密钥，因为他们有互补变量20，但叶20没有。
A scheme like this seems very desirable from the viewpoint of transmission savings since a rekey message encrypted with each individual KEK to every leaf does not have to be sent to delete someone from the net. In other words, there will be one plaintext message to the multicast group versus N encrypted rekey messages. There exists two major drawbacks with this scheme. First are the storage requirements necessary for the (N-1) complementary variables. Secondly, when deleting multiple users from the multicast group, collusion will be a concern. What this means is that these deleted users could work together and share their individual complementary variables to regain access to the multicast session.
从传输节省的角度来看，这样的方案似乎非常可取，因为不必发送用每个单独的KEK加密到每个叶子的密钥更新消息来从网络中删除某人。换句话说，将有一条明文消息发送到多播组，而不是N条加密的密钥更新消息。该方案存在两个主要缺点。首先是（N-1）互补变量所需的存储要求。其次，当从多播组中删除多个用户时，合谋将是一个问题。这意味着这些被删除的用户可以一起工作并共享各自的补充变量，以重新获得对多播会话的访问。
The Hierarchical Tree Approach is our recommended approach to address the multicast key management problem. This approach provides for the following requisite features:
分层树方法是我们推荐的解决多播密钥管理问题的方法。该方法提供了以下必要功能：
1. Provides for the secure removal of a compromised user from the multicast group
1. 提供从多播组中安全删除受损用户的功能
2. Provides for transmission efficiency
2. 提供传输效率
3. Provides for storage efficiency
3. 提高存储效率
This approach balances the costs of time, storage and number of required message transmissions, using a hierarchical system of auxiliary keys to facilitate distribution of new Net Key. The result is that the storage requirement for each user and the transmissions required for key replacement are both logarithmic in the number of users, with no background transmissions required. This approach is robust against collusion of excluded users. Moreover, while the scheme is hierarchical in nature, no infrastructure is needed beyond a server (e.g., a root), though the presence of such elements could be used to advantage (See Figure 1).
这种方法平衡了时间、存储和所需消息传输数量的成本，使用辅助密钥的分层系统来促进新网络密钥的分发。结果是，每个用户的存储需求和密钥更换所需的传输在用户数量上都是对数的，不需要后台传输。该方法对排除用户的共谋具有鲁棒性。此外，虽然该方案本质上是分层的，但除了服务器（例如根）之外不需要任何基础设施，尽管可以利用这些元素的存在（见图1）。
--------------------------
| |
| S E R V E R |
| |
--------------------------
| | |
| | . . . . |
- - -
|1| |2| |n|
- - -
--------------------------
| |
| S E R V E R |
| |
--------------------------
| | |
| | . . . . |
- - -
|1| |2| |n|
- - -
Figure 1: Assumed Communication Architecture
图1：假定的通信架构
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.
下面更详细地列举了该方案及其优缺点。请参阅下面的图2。此图说明了逻辑密钥分发体系结构，其中密钥仅存在于服务器和用户。因此，此体系结构中的服务器将保存密钥A到O以及每个用户的KEK。此体系结构中的用户11将拥有自己独特的KEK以及键F、K、N和O。
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
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
图2：逻辑密钥分发体系结构
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.
我们构造了一个根树（从下到上），每个用户对应一片叶子，如图2所示。（虽然为了方便起见，我们绘制了一个平衡的二叉树，但该树不需要是平衡的或二叉的——已经对树的形状进行了一些初步分析。）每个用户都与服务器建立一个唯一的成对密钥。对于具有传输能力的用户，这可以使用公钥交换协议来完成。对于纯接收用户，情况更为复杂；最容易假设这些用户已经预先放置了密钥。
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
一旦每个用户拥有服务器已知的成对密钥，服务器就会（根据该会话的安全策略）为树中的每个剩余节点生成一个密钥。密钥本身应该由一个健壮的过程生成。我们还假设用户没有关于他们不需要的密钥的信息。（注意：这些剩余节点上没有用户（即，它们是逻辑节点），每个节点的密钥只需由服务器生成
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.)
从所有子节点都是叶子的节点开始，向根节点前进，服务器传输每个节点的密钥，并使用每个节点子节点的密钥进行加密。在该过程结束时，每个用户都可以确定与她叶子上方的那些节点对应的密钥。特别是，所有用户都持有根密钥，根密钥用作组的公共网络密钥。深度为d的用户的存储要求是d+1个键（因此，对于图2中的示例，深度d=4的用户将持有五个密钥。即，由于成对密钥交换而生成的唯一密钥加密密钥、三个中间节点密钥（每个密钥分别加密和传输），以及多播组的公共网络密钥（也分别加密）
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.
还可以在一条消息中传输所有中间节点密钥和根节点密钥，其中所有节点密钥都将使用单个叶的唯一成对密钥进行加密。以这种方式，每个用户只需要一次（较大消息的）传输来接收所有节点密钥（与d次传输相比）。注意，对于这种方法，叶需要一些方法来确定哪个键对应于哪个节点级别。
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.
需要注意的是，这种方法需要在服务器上提供额外的处理能力，而其他替代方法可能不需要。在最坏的情况下，服务器将负责生成体系结构中所需的中间密钥。
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.
假设需要从多播组中删除用户11（图2中用黑色标记）。然后，用户11持有的所有密钥（粗体密钥F、K、N、O）必须更改并分发给需要它们的用户，而不允许用户11或任何其他人获得它们。要做到这一点，我们必须从下至上替换用户11持有的粗体键。服务器为最低节点选择一个新密钥，然后用适当的子密钥加密传输（这些传输由虚线表示）。因此，对于该示例，替换的第一个密钥是密钥F，并且该新密钥将使用用户12的唯一成对密钥加密发送。
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,
由于我们是自下而上进行的，每个替换密钥在用于加密另一个密钥之前都已被替换。（因此，对于密钥K的替换，该新密钥将在新替换的密钥F（对于用户12）中加密发送，并且还将作为在用户9和10共享的节点密钥（密钥E）中加密的一个多播传输发送。对于密钥N的替换，该新密钥将在新替换的密钥K（对于用户9、10、，
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.
并且还将在用户13、14、15和16共享的节点密钥（密钥L）中加密。对于密钥O的替换，该新密钥将在新替换的密钥N（对于用户9、10、12、13、14、15和16）中加密发送，并且还将在用户1、2、3、4、5、6、7和8共享的节点密钥（密钥M）中加密发送。所需的传输次数是被替换节点的次数之和。在深度为d的k元树中，这最多是kd-1传输。因此，在此示例中，将需要七次传输来将用户11从多播组中排除，并使其他15个用户返回到用户11无权访问的新多播组网络密钥上。很容易看出，该系统对共谋具有鲁棒性，因为没有一组用户可以一起阅读任何消息，除非其中一个用户可以单独阅读。
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.
如果采用与上一节相同的策略在一条消息中发送多个密钥，则所需的传输次数可以进一步减少到四次。再次注意，消息传输的比特数将更大。此外，每个叶必须有一种方法来确定消息中的哪个键对应于层次结构中的哪个节点。因此，在该示例中，为了向用户12替换密钥F、K、N和O，将在用户12的唯一成对密钥下在一条消息中加密这四个密钥。为了替换用户9和10的密钥K、N和O，这三个密钥将在用户9和10共享的节点密钥（密钥E）下的一条消息中加密。为了替换用户13、14、15、16的密钥N和O，这两个密钥将在用户13、14、15和16共享的节点密钥（密钥L）下的一条消息中加密。最后，为了替换用户1、2、3、4、5、6、7和8的密钥O，密钥O将在用户1、2、3、4、5、6、7和8共享的节点密钥下加密（密钥M）。因此，所需的传输数量最多为（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.
下表演示了删除用户的过程，以及存储和传输需求如何随着用户数量的增加而增长。
Table 1: Storage and Transmission Costs
表1：存储和传输成本
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
每用户传输到用户传输的次数存储（k）（d+1）剩余密钥重新密钥剩余多播组的参与者-每消息一个密钥多播（kd-1）组的参与者-每消息多个密钥（k-1）D8 2 4 5 3 9 3 5 16 2 5 7 4 2048 2 12 11 2187 3 8 14 131072 18 17 177 147 3 12 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].
1. 随着用户数量的增加，用户存储和重新密钥传输的成本是平衡的和可扩展的。[1]、[2]或[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.
2. 辅助钥匙不仅可用于传输其他钥匙，还可用于传输信息。因此，层次结构可以设计为将希望安全通信的子组（即，不向大型多播组的其余部分传输）放置在特定节点下，从而消除了为这些子组维护单独网络密钥的需要。如果用户从一开始就在一个层次结构中操作（例如军事行动），这将最有效，这可以通过键层次结构反映出来。
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).
3. 层次结构可以设计为反映网络架构，提高效率（每个用户收到的无关消息更少）。此外，服务器的责任可以在子站点之间划分（所有子站点都必须是安全的）。
4. The security risk associated with receive-only users can be minimized by collecting such users in a particular area of the tree.
4. 通过在树的特定区域中收集此类用户，可以最小化与仅接收用户相关的安全风险。
5. This approach is resistant to collusion among arbitrarily many users.
5. 这种方法可以抵抗任意多个用户之间的共谋。
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.
通过增加价格和减少树的深度，可以以增加传输的代价降低用户的存储需求。例如，在每个消息一个密钥的情况下，如果n个用户排列在k元树中，则每个用户都需要存储。删除一个用户后重新键入现在需要传输。当k接近n时，这接近本文前面描述的成对密钥方案。
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].
本节中概述的分层树方法可按第5.2节所示进行分发，以更接近于[4]中提出的建议。子节点可以存在于每个节点上，以处理任何下级用户所需的任何加入或重新设置密钥。这对于没有直接连接回根目录的用户来说尤其有吸引力。回想一下，如第5.2节所述，委托这些代位权人以根的权限和安全性行事是一个潜在的危险主张。这一思想也在[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.
需要注意的是，尽管该分布在初始化多播组所需的时间（与第5.4节中所述的初始化组所需的时间相比）和定期密钥更新方面似乎提供了一些好处，当用户受到威胁时，它似乎没有为多播组重新设置密钥提供任何好处。
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
还需要注意的是，无论密钥管理方案是什么（分层树、分布式分层树、基于核心的树、GKMP等），初始化密钥都会产生“命中”
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.
具有第一个多播组网络密钥的多播组。因此，与其他方案相比，分层树方法在初始化方面不存在额外的复杂性。
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 the multicast group need to be brought up on-line and communicating more quickly. Other participants in the multicast group can then be brought in when they wish. In this type of approach though, there does not exist a finite period of time by when it can be ensured all participants will be a part of the multicast group.
虽然本文将多播组的形成描述为根发起，但分层方法与用户发起的加入是一致的。用户发起加入是[4]中提出的多播组形成方法。当多播组中的一些核心用户子集需要在线并更快地通信时，用户发起的加入可能是可取的。然后，多播组中的其他参与者可以在他们愿意的时候加入。然而，在这种类型的方法中，不存在一个有限的时间段，可以确保所有参与者都是多播组的一部分。
For example, in the case of a single root, the hierarchy is set up once, in the beginnning, by the initiator (also usually the root) who also generates the group participant list. The group of keys for each participant can then be individually requested (pulled) as soon as, but not until, each participant wishes to join the session.
例如，在单个根的情况下，层次结构在开始时由发起人（通常也是根）设置一次，发起人也会生成组参与者列表。然后，只要每个参与者希望加入会话，就可以单独请求（提取）每个参与者的密钥组。
In the multicast environment, the possibility exists that participants of the group at times may want to uniquely identify which participant is the sender of a multicast group message. In the multicast key distribution system described by Ballardie [4], the notion of "sender specific keys" is presented.
在多播环境中，组的参与者有时可能希望唯一地标识哪个参与者是多播组消息的发送者。在Ballardie[4]描述的多播密钥分发系统中，提出了“发送方特定密钥”的概念。
Another option to allow participants of a multicast group to uniquely determine the sender of a message is through the use of a signature process. When a member of the multicast group signs a message with their own private signature key, the recipients of that signed message in the multicast group can use the sender's public verification key to determine if indeed the message is from who it is claimed to be from.
允许多播组的参与者唯一地确定消息的发送者的另一个选项是通过使用签名过程。当多播组的成员使用其自己的私有签名密钥对消息进行签名时，多播组中该签名消息的接收者可以使用发送者的公共验证密钥来确定消息是否确实来自其声称来自的人。
Another related idea to this is the case when two users of a multicast group want to communicate strictly with each other, and want no one else to listen in on the communication. If this communication relationship is known when the multicast group is originally set up, then these two participants could simply be placed adjacent to one another at the lowest level of the hierarchy (below a binary node). Thus, they would naturally share a secret pairwise key. Otherwise, a simple way to accomplish this is to perform a public key based pairwise key exchange between the two users to
与此相关的另一个想法是多播组的两个用户希望严格地相互通信，并且不希望其他人监听通信。如果在最初设置多播组时知道此通信关系，则这两个参与者可以简单地彼此相邻地放置在层次结构的最低级别（二进制节点下方）。因此，它们自然会共享一个秘密的成对密钥。否则，实现这一点的简单方法是在两个用户之间执行基于公钥的成对密钥交换，以
generate a traffic encryption key for their private unicast communications. Through this process, not only will the encrypted transmissions between them be readable only by them, but unique sender authentication can be accomplished via the public key based pairwise exchange.
为其专用单播通信生成流量加密密钥。通过这个过程，不仅它们之间的加密传输只能由它们读取，而且唯一的发送者身份验证可以通过基于公钥的成对交换来完成。
5.4.2.4 Rekeying the Multicast Group and the Use of Group Key Encryption Keys
5.4.2.4 为多播组重新设置密钥和使用组密钥加密密钥
Reference [4] makes use of a Group Key Encryption Key that can be shared by the multicast group for use in periodic rekeys of the multicast group. Aside from the potential security drawbacks of implementing a shared key for encrypting future keys, the use of a Group Key Encryption Key is of no benefit to a multicast group if a rekey is necessary due to the known compromise of one of the members. The strategy for rekeying the multicast group presented in Section 5.4.1 specifically addresses this critical problem and offers a means to accomplish this task with minimal message transmissions and storage requirements.
参考文献[4]使用可由多播组共享的组密钥加密密钥，以用于多播组的定期重新密钥。除了实现用于加密未来密钥的共享密钥的潜在安全缺陷之外，如果由于成员之一的已知危害而需要重新密钥，则使用组密钥加密密钥对多播组没有好处。第5.4.1节中介绍的多播组密钥更新策略专门解决了这一关键问题，并提供了一种以最小的消息传输和存储需求完成此任务的方法。
The question though can now be asked as to whether the rekey of a multicast group will be necessary in a non-compromise scenario. For example, if a user decides they do not want to participate in the group any longer, and requests the list controller to remove them from the multicast group participant list, will a rekey of the multicast group be necessary? If the security policy of the multicast group mandates that deleted users can no longer receive transmissions, than a rekey of a new net key will be required. If the multicast group security policy does not care that the deleted person can still decrypt any transmissions (encrypted in the group net key that they might still hold), but does care that they can not encrypt and transmit messages, a rekey will once again be necessary. The only alternative to rekeying the multicast group under this scenario would require a recipient to check every received message sender, against the group participant list. Thus rejecting any message sent by a user not on the list. This is not a practical option. Thus it is recommended to always rekey the multicast group when someone is deleted, whether it is because of compromise reasons or not.
不过，现在可以提出这样一个问题：在不妥协的情况下，是否需要重新设置多播组的密钥。例如，如果用户决定不再参与该组，并请求列表控制器将其从多播组参与者列表中删除，是否需要重新设置该多播组的密钥？如果多播组的安全策略要求已删除的用户不能再接收传输，则需要重新输入新的网络密钥。如果多播组安全策略不关心被删除的人仍然可以解密任何传输（在他们可能仍然持有的组网络密钥中加密），但关心他们不能加密和传输消息，则再次需要重新密钥。在这种情况下，重新设置多播组密钥的唯一替代方法是要求收件人根据组参与者列表检查每个收到的消息发送者。因此，拒绝不在列表中的用户发送的任何消息。这不是一个切实可行的选择。因此，建议在删除某人时始终重新设置多播组的密钥，无论是否出于妥协原因。
As indicated in Section 2, the need may arise to remove users in bulk. If the users are setup as discussed in Section 5.4.1 into subgroups that wish to communicate securely all being under the same node, bulk user removal can be done quite simply if the whole node is to be removed. The same technique as described in Section 5.4.1 is performed to rekey any shared node key that the remaining
如第2节所述，可能需要批量删除用户。如果按照第5.4.1节的讨论将用户设置为希望在同一节点下安全通信的子组，则如果要删除整个节点，则可以非常简单地进行批量用户删除。执行第5.4.1节中所述的相同技术，以重新输入剩余的共享节点密钥
participants hold in common with the removed node.
参与者与移除的节点有共同点。
The problem of bulk removal becomes more difficult when the participants to be removed are dispersed throughout the tree. Depending on how many participants are to be removed, and where they are located within the hierarchy, the number of transmissions required to rekey the multicast group could be equivalent to brute force rekeying of the remaining participants. Also the question can be raised as to at what point the remaining users are restructured into a new hierarchical tree, or should a new multicast group be formed. Restructuring of the hierarchical tree would most likely be the preferred option, because it would not necessitate the need to perform pairwise key exchanges again to form the new user unique KEKs.
当要移除的参与者分散在整个树中时，批量移除问题变得更加困难。根据要删除的参与者数量以及他们在层次结构中的位置，重新设置多播组密钥所需的传输数量可能相当于对剩余参与者的暴力重新设置密钥。此外，还可能提出这样一个问题：剩余用户在什么时候被重组为一个新的层次结构树，或者应该形成一个新的多播组。重组层次结构树很可能是首选选项，因为它不需要再次执行成对密钥交换以形成新的用户唯一KEK。
Thus far this document has had a major focus on the architectural trade-offs involved in the generation, distribution, and maintenance of traffic encryption keys (Net Keys) for multicast groups. There are other elements involved in the establishment of a secure connection among the multicast participants that have not been discussed in any detail. For example, the concept of being able to "pick and choose" and negotiating the capabilities of the key exchange mechanism and various other elements is a very important and necessary aspect.
到目前为止，本文档主要关注多播组的流量加密密钥（网络密钥）的生成、分发和维护所涉及的体系结构权衡。在多播参与者之间建立安全连接还涉及到其他一些尚未详细讨论的因素。例如，能够“挑选”和谈判关键交换机制和各种其他要素的能力的概念是一个非常重要和必要的方面。
The NSA proposal to the Internet Engineering Task Force (IETF) Security Subworking Group [Ref. 3] entitled "Internet Security Association and Key Management Protocol (ISAKMP)" has attempted to identify the various functional elements required for the establishment of a secure connection for the largest current network, the Internet. While the proposal has currently focused on the problem of point to point connections, the functional elements should be the same for multicast connections, with appropriate changes to the techniques chosen to implement the individual functional elements. Thus the implementation of ISAKMP is compatible with the use of the hierarchical tree approach.
NSA向互联网工程任务组（IETF）安全子工作组（参考文献3）提交的题为“互联网安全协会和密钥管理协议（ISAKMP）”的提案试图确定为当前最大的网络（互联网）建立安全连接所需的各种功能要素。虽然该提案目前侧重于点对点连接的问题，但对于多播连接，功能元素应该是相同的，对实现各个功能元素所选择的技术进行适当的更改。因此，ISAKMP的实现与分层树方法的使用是兼容的。
As discussed in this report, there are two main areas of concern when addressing solutions for the multicast key management problem. They are the secure initialization and rekeying of the multicast group with a common net key. At the present time, there are multiple papers which address the initialization of a multicast group, but they do not adequately address how to efficiently and securely remove a compromised user from the multicast group.
如本报告所述，在解决多播密钥管理问题时，有两个主要关注领域。它们是使用公共网络密钥对多播组进行安全初始化和重新设置密钥。目前，有多篇论文讨论了多播组的初始化问题，但它们没有充分讨论如何有效和安全地将受损用户从多播组中移除。
This paper proposed a hierarchical tree approach to meet this difficult problem. It is robust against collusion, while at the same time, balancing the number of transmissions required and storage required to rekey the multicast group in a time of compromise.
本文提出了一种层次树方法来解决这一难题。它对共谋具有很强的鲁棒性，同时，平衡了在妥协时为多播组重新设置密钥所需的传输数量和存储量。
It is also important to note that the proposal recommended in this paper is consistent with other multicast key management solutions [4], and allows for multiple options for its implementation.
还需要注意的是，本文中推荐的方案与其他多播密钥管理解决方案[4]是一致的，并且允许多个选项来实现它。
Security concerns are discussed throughout this memo.
本备忘录中讨论了安全问题。
1. Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management Protocol Architecture", RFC 2094, September 1994.
1. Harney，H.，Muckenhirn，C.和T.Rivers，“组密钥管理协议架构”，RFC 2094，1994年9月。
2. Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management Protocol Specification", RFC 2093, September 1994.
2. Harney，H.，Muckenhirn，C.和T.Rivers，“组密钥管理协议规范”，RFC 2093，1994年9月。
3. Maughan, D., Schertler, M. Schneider, M. and J.Turner, "Internet Security Association and Key Management Protocol, Version 7", February 1997.
3. Maughan，D.，Schertler，M.Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议，第7版”，1997年2月。
4. Ballardie, T., "Scalable Multicast Key Distribution", RFC 1949, May 1996.
4. Ballardie，T.，“可伸缩多播密钥分发”，RFC 1949，1996年5月。
5. Wong, C., Gouda, M. and S. Lam, "Secure Group Communications Using Key Graphs", Technical Report TR 97-23, Department of Computer Sciences, The University of Texas at Austin, July 1997.
5. Wong，C.，豪达，M.和S. Lam，“使用关键图的安全组通信”，技术报告TR 9723，得克萨斯大学奥斯汀分校计算机科学系，1997年7月。
Authors' Addresses
作者地址
Debby M. Wallner National Security Agency Attn: R2 9800 Savage Road STE 6451 Ft. Meade, MD. 20755-6451
Debby M.Wallner国家安全局收件人：马里兰州米德郡Savage Road STE 6451 Ft.20755-6451 R2 9800
Phone: 301-688-0331 EMail: dmwalln@orion.ncsc.mil
电话：301-688-0331电子邮件：dmwalln@orion.ncsc.mil
Eric J. Harder National Security Agency Attn: R2 9800 Savage Road STE 6451 Ft. Meade, MD. 20755-6451
Eric J.Harder国家安全局收件人：马里兰州米德郡萨维奇路街6451英尺R2 9800号，20755-6451
Phone: 301-688-0850 EMail: ejh@tycho.ncsc.mil
电话：301-688-0850电子邮件：ejh@tycho.ncsc.mil
Ryan C. Agee National Security Agency Attn: R2 9800 Savage Road STE 6451 Ft. Meade, MD. 20755-6451
Ryan C.Agee国家安全局收件人：马里兰州米德郡萨维奇路街6451英尺R2 9800号，20755-6451
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。