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.
将来のネットワークは、現在の鍵管理アーキテクチャの能力に負担になる要件を持っていることが認識されます。これらの要件の1つは、安全なマルチキャスト要件となります。高帯域幅の必要性は、非常にダイナミックセキュアマルチキャスト通信は、商用、政府、およびインターネットコミュニティの多種多様で、ますます明白です。具体的には、セキュアなマルチキャスト要件を確実に共通のマルチキャストグループネットキーを使用して、マルチキャストグループの他のすべてのメンバーと通信するために同一のセキュリティ属性と通信要件を共有する複数のユーザーのための必要性です。複数の受信機が同時に同じ透過率を得ることであるマルチキャスト通信の最大の利点。このような問題は、/決定（マルチキャストグループを初期化する）、同様に行うことが権限のない者を可能にし、確実に必要な場合、マルチキャストグループのユーザに再入力することなく、同じネットキーを取得するために各ユーザを有効にしています。一見すると、これは現在の鍵管理シナリオよりも何が違うように見えないかもしれません。本論文では、将来のマルチキャストシナリオは非常に発散し、動的アドレスへの鍵管理の観点から、それは非常に困難になります要件の変更を持っていること、しかし、表示されます。
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.
次のセクションでは、マルチキャスト機能を必要とすることができるいくつかの潜在的なシナリオを説明し、パフォーマンスとセキュリティの両方の観点から、その要件を定量化します。これは、潜在的なソリューションを設計するときに1を考慮しなければならない要因のリストで、セクション4.0に続きます。このドキュメントではいくつかの点でカバーされるいくつかのセキュリティサービスがありますが、この文書の焦点の多くは、マルチキャストグループのネット鍵の生成と配布にされています。いくつかの手動または自動、集中型または分散型メカニズムを介してのいずれかですべての潜在的なマルチキャスト参加者が初期鍵材料（例えば、証明書）を受信しているものとします。この文書では、初期鍵配布問題に対処しません。第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.
例として、私たちは2つのシナリオ、分散型ゲームやテレビ会議を考えてみましょう。
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の第2の全初期化時に、例えば、非常に急速に初期化する必要があります。このシナリオでは、非常にユーザーが1秒以内にグループから追加または削除することが必要とされ得ることで要求されています。サイズダイナミクスの観点から、私たちは、グループメンバーの約10％が1分の時間にわたって変更される可能性があることを推定します。データレート要件は、第二（マルチキャストビデオ）あたりギガビットに毎秒（戦術的なユーザーをシミュレート）キロビットに至るまで、広範です。分散型のゲームのシナリオは、アクセス制御、ユーザー認証、データの機密性、およびデータの整合性にユーザーをカバーするセキュリティ要件のかなり徹底したセットがあります。また、いくつかの戦術的なデバイスのための典型的なノイズの多い動作環境に対応する必要性を示唆している「堅牢」でなければなりません。最後に、可用性の概念は、マルチキャスト機能を供給する通信ネットワークが起動し、時間の特定の割合を機能しなければならないことを意味し、このシナリオに適用されます。
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年代に至るまで、広範です。会議のシナリオは、アクセス制御、ユーザー認証、データの機密性、データの整合性、および否認防止へのユーザーをカバーするセキュリティ要件のかなり徹底したセットがあります。可用性の概念はまた、このシナリオに適用されます。このシナリオでは、提供されなければならないときのための時間枠は今です。
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.ドメイン間の問題 - ポリシーが適用されている潜在的に異なるセキュリティポリシー、と別のドメインに1「グループドメイン」から交差？例では、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.イニシエータは、マルチキャストグループを制御する人を決定します。このコントローラは、ROOT（または同等SERVER）と呼ばれます。多くの場合、イニシエータは、rootになるだろうが、この制御は、開始剤以外の誰かにオフに渡すことがどこ可能性が存在します。 （いくつかの鍵管理アーキテクチャは、複数のルートを採用して、[4]。参照）根の仕事は、グループ参加者の追加や削除を実行することで、そのセッションのセキュリティ属性に対してユーザーのアクセス制御を行うと、セッションのためのトラフィック暗号化キーを配布しますこれは私たちがマルチキャストグループNETのKEYを呼び出します。初期化後、受け入れるか、または将来のグループ参加者の追加を拒否、または現在のグループの参加者を削除する権限を持つエンティティは、LIST CONTROLLERと呼ばれています。
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.マルチキャストセッションのすべての参加者は、GROUP参加者と呼ぶことにします。ルートまたはリストコントローラ以外の特定のグループの参加者の葉と呼ぶことにします。
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.ルートをチェックし、それらのすべては、必要なセキュリティ属性をサポートしていることを確認するために、マルチキャストグループの参加者リストに記載されている参加者のセキュリティ属性の後、ルートは、他のすべての参加者にマルチキャストグループのリストを渡し、ネットを作成し、配布しますキー。マルチキャストグループリストの参加者は、必要なセキュリティ属性を満たしていない場合は、葉がリストから削除されなければなりません。
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。葉がセッションに参加することを拒否したときに問題が存在します。葉がセッションに参加することを拒否した場合、我々は、しかし、潜在的に、複数回の修正リストを送信、ネットキーを送信する前に修正リストを送信することができ、効率が悪いです。代わりに、根は上続けることができる、とのセッションを拒否し、リスト上のもの参加者にネットキーを送信しません。
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.
マルチキャストセッションのための材料をキーイング配布する4つの潜在的な鍵管理アーキテクチャが提示されています。所有するアーキテクチャのための非常に望ましい特徴は、マルチキャストグループが最小化されるべきでセットアップするのに必要な時間が含まれていることを思い出して、送信の数が最小化されるべき、及びメモリ/ストレージ要件を最小にしなければなりません。理解されるように、第4の提案は、所望の機能にバランスをとるように見える一方で、最初の三つの提案それぞれは、これらの所望の品質の別の態様では不十分です。このように、第四の提案は一般的な実装と使用をお勧めです。
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.
手動鍵配布を介して、対称鍵は、公開鍵交換を使用せずに送達されます。ネットキーと予備ネットキーは、マルチキャストセッショングループのルートが発注されるだろうイベントのシーケンスを必要とする手動鍵配布を利用したマルチキャストグループネットキーを設定します。代替（スーパーセッション）ネットのキーは、グループの参加者（複数可）の妥協の場合に使用されるように（rootで）順序付けされます。ネットキーは、多くの場合、いくつかの集中物理的中間位置を介して、各個々のグループの参加者に配布されることになります。いくつかの所定の時点で、すべてのグループの参加者は、新たなネットキーに切り替えます。グループの参加者は、彼らが別の新しいネットキーを必要とし、所定の時間まで、このネットキーを使用しています。ネットキーがこの時間中に侵害された場合、代替ネットキーが使用されています。グループの参加者は、彼らはそれを受け取るとすぐに別のネットキーへの切り替え、または誰もが場所を取る必要がある上、新たなネットキーので、スイッチを持っていることを根本からの通知時に。この手順は、それぞれ、暗号のために繰り返されます。
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.
このアプローチは、グループ参加者に共通のマルチキャストグループネットキーを提供するために、強引な方法です。この方式では、イニシエータは、特定のセッションのセキュリティ属性を設定し、所望のグループ参加者のリストを生成し、すべてのグループ参加者にリストを送信します。葉はその後、参加の最初の合否で応答します。アップフロントリストを送信することにより、時間がセッションへの参加を拒否した人々との鍵交換を実行しないことによって保存することができます。 （これと将来の例については、イニシエータであると仮定される）ルートは、いくつかの標準の公開鍵交換技術（例えば、ディフィー・ヘルマン公開鍵交換を使用してマルチキャストグループに参加（葉）のいずれかでペアワイズ鍵を生成します。 ）ルートは、この最初のリーフに（初期鍵ペアのパラメータと異なっていてもよい）マルチキャストのセキュリティ・アソシエーション・パラメータを提供します。パラメータは、分類や政策などの項目を含むことができます。パラメータの（セキュリティアソシエーション管理プロトコル、または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.
葉は、マルチキャストセッションへの参加を受け付けた後、これらの二つは、マルチキャストグループが使用するネットキーを選択してください。ネットキーは、2つのエンティティ間の別の公開鍵交換により生成された、または単にマルチキャストグループのための場所であるポリシーに応じて、ルートによって選択することができる（すなわち、リアルタイム選択をされません。この方針の決定）。ここでの問題は、葉が根に持っている信頼のレベルです。初期ペアワイズ鍵交換は、ユーザ認証のいくつかのレベルを提供する場合、単にルートは、この段階でのネットキーを選択させるに十分なようです。もう一つの問題は、生成されたキーのセキュリティ強度の信頼のレベルです。連携処理を経て、両方のエンティティ（葉と根）は、ネットキーの形成に使用される情報を提供します。
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）としての役割を果たす。 rootだけが葉鍵ペアのすべてをキャッシュします。個々のリーフは、唯一独自の鍵ペア暗号化キーをキャッシュします。
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.
KEKをキャッシュする際に考慮すべき2つのケースがあります。ネットキーとKEKは、セッションキーごとにあるとき、最初のケースです。 1は、マルチキャストセッションからのグループ参加者を除外する（して、新しいネットキーで、残りの参加者をリキー）したい場合は、この場合、ルートは、すべての正当な残りの参加者に、個々の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.
KEKが複数のセッションのために有効である際に考慮すべき第二のケースはあります。この場合、ネットのキーは、複数のセッションに対して有効であってもよいし、ネットキーはまだのみ、上記の場合のように一つのセッションのために有効です。ネットキー1つのセッションまたは複数のセッションのために有効であるかどうか、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）セキュリティSubworkingグループ[参考文献1,2]への1つの提案と同じです。
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キー交換を行う代わりに、根を有するので、根は彼の下葉の数に、この機能（およびコントロール）のいくつかを渡すことができます。ルートは、他の半分の世話をする一方、例えば、マルチキャストグループリストは、半分に分割することができ、ルートは、ユーザーの半分を取り、彼らと鍵交換を行う（そしてネット鍵を配布）する1つのリーフを伝えますリスト。 （選ばれた葉は、このようにルートとして機能していると我々はそれらを呼び出すことができます「subrootsを。」これらsubrootsは、その下の葉を持っています、とsubrootsは、その下に各リーフの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.
この方式では、独自のセキュリティ上の問題がないわけではありません。この方式は、各サブグループのコントローラまでの信頼をプッシュ - ルートは、これらの「サブルート」のコントローラは、信頼できる方法で行動していることを前提としています。すべての制御要素（ルートとsubroots）マルチキャストを通じてシステムに残っている必要があります。これは、効果的に分散制御に硬く、遅くによるネット（特にsubroots）から誰かを削除します。ネットキーを配布するために、サブルートとして、根に代わって機能してきたマルチキャストグループからの参加者を削除する場合は、追加の手順が必要になります。新しいサブルートは削除サブルートを交換するために、ルートによって委任されている必要があります。鍵交換は、（新しいペアごとKEKを生成するために）新しいサブルートと削除サブルートが担当した各葉の間に発生しなければなりません。新しいネットキーが今subrootsに、葉に、ルートから配布されます。この最後のステップは削除当事者が無制御の責任を持つ葉であった場合に必要な唯一のステップであったであろうことに注意してください。
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をキャッシュします。各リーフは、自分のKEKを格納します。ルートは、すべてのユーザーに、参加者と属性のマルチキャストグループのリストを提供することになります。前のセクションで説明したように、参加者は、マルチキャストセッションへの参加を受け入れるか拒絶するであろう。ルートは独自の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葉補完的な変数を受け取ることになります。ルートは、各リーフにKEK（i）で暗号化されたネットキーと補完的な変数J、J = 1,2、...、NとIとJ等しくないが、送信されます。このように、すべての葉が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対マルチキャストグループへの1つの平文メッセージが存在することになるメッセージをリキー暗号化されました。このスキームを持つ2つの主要な欠点が存在します。第（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.は、マルチキャストグループからの妥協のユーザの安全な除去のために提供します
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|
- - -
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を考えてみましょう。この図は、キーがサーバーに、ユーザーにのみ存在する論理的な鍵配布アーキテクチャを示す図です。したがって、このアーキテクチャ内のサーバは、Oを介してキーAを保持し、各ユーザのの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
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のように、各ユーザに対応する1つのリーフに（下から）ルート権限を取得し、ツリーを構築します - 木の造形上のいくつかの予備的な分析が行われている。）各ユーザーは、サーバーとのユニークな鍵ペアを確立します。伝送能力を持つユーザーの場合、これは、公開鍵交換プロトコルを使用して行うことができます。状況は、受信専用のユーザーのために、より複雑です。それは、これらのユーザーは事前に置かキーを持っていると仮定するのが最も簡単です。
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におけるユーザの記憶要件は、このように、図2の例では、深さd = 4で、ユーザが5つのキーを保持するであろう（D + 1キーである。すなわち、ペアワイズの結果として生成された固有鍵暗号化鍵あります鍵交換、3つの中間ノードキー - それぞれ別々に暗号化して送信し、また、別々に暗号化されているマルチキャストグループのための共通のネット鍵）
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.
（黒色で、図2に示される）、ユーザ11は、マルチキャストグループから削除する必要があると仮定する。そして、ユーザ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, 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.
別のキーを暗号化するために使用される前に、私たちは下から上に進んでいるので、交換用キーのそれぞれが置換されています。 （このように、キーKの交換のために、この新しいキーがユーザ12のために（新たに置き換えキーFで暗号化されて送信される）と、ユーザー9および10（キーで共有ノード鍵で暗号化された1つのマルチキャスト送信として送信されますE）キーNの交換のために、この新しいキーがユーザー9、10、及び12のために新たに交換鍵K（）で暗号化されて送信され、また15、ユーザ13、14によって共用ノード鍵で暗号化されます、16（キーL）キーOの交換のために、この新しい鍵が新たに交換鍵Nで暗号化されて送信される（ユーザーのための9、10、12、13、14、15、および16）ともなりユーザー1、2、3、4、5、6、7、および8（キーM）によって共有されるノード鍵で暗号化される。）必要な送信の数は、置換ノードの度の和です。深さdに座っているのk分木では、これが最もKD-1の伝送でになります。したがって、この例では、7つの送信は、マルチキャストグループからユーザー11を除外するために、バックユーザ11がアクセス権を持っていないことを新しいマルチキャストグループネットキーの上に、他の15人のユーザーを取得する必要があります。そのうちの一つは、個別にそれを読んでいる可能性がない限り、一緒にユーザーのないセットは任意のメッセージを読むことができないという点では、システムが共謀に対して堅牢であることを確認することは容易です。
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.
同じ戦略は、1つのメッセージに複数のキーを送信するために、前のセクションでとした場合、必要な送信の数は、4つの送信をさらに低減することができます。メッセージが送信されたビットの数に大きくなることを再度留意されたいです。また、階層のどのノードに対応するメッセージ内のどのキーを決定するために、各リーフのための手段が存在しなければなりません。したがって、この例では、ユーザ12にキーF、K、N、およびOの交換のために、4つのキーは、ユーザー12の一意の鍵ペアで1つのメッセージに暗号化されます。ユーザー9および10のための鍵K、N、およびOを置き換えるために、3つのキーは、ユーザー9および10によって共有されるノード鍵（鍵e）の下で一つのメッセージに暗号化されます。ユーザー13、14、15、16のキーN及びOを置き換えるために、2つのキーがユーザー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-1 - ユーザーの送信（K）（D + 1）へのユーザの送信あたり数度記憶は、メッセージ・マルチキャスト（KD-1）グループごとに1つのキーのマルチキャスト基 - 参加者を残りの参加者をリキー残りリキー）D 8 2 4 5 3 9 3 3 4 5 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).
3.階層は、（各ユーザーが少ない無関係なメッセージを受信する）効率を向上させる、ネットワークアーキテクチャを反映するように設計することができます。また、サーバの責任はsubroots（すべてが安全でなければならない）間で分割することができます。
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.)
以前、リキー処理における1人のユーザが危険にさらされた後に、メッセージごとに一つのキーの場合に述べたように次のキーを交換することができる前に、（ユーザーが再入力メッセージをキャッシュできない場合）、各置換キーが正常に復号化されなければなりません。このボトルネックは、ノイズの多いまたは低速ネットワーク上の問題がある可能性があります。 （複数のユーザーが削除されている場合はリキーと予想時間が取り除かユーザの数の約独立しているので、これは、並列化することができます。）
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.
原子価を高め、木の深さを減少させることにより、1は増加した送信の価格でユーザーのストレージ要件を減らすことができます。 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]に出す提案に類似するように分散することができます。 Subrootsは下位ユーザのいずれかのために必要である任意の参加または再キーイングを処理するために各ノードに存在し得ます。これは戻って、ルートへの直接接続を持っていないユーザーに特に魅力的である可能性があります。 5.2節で示したように、これらのsubrootsに配置された信頼は、ルートの権限とセキュリティを持って行動することを、思い出して、潜在的に危険な提案です。この考えはまた、[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.
これらsubrootsのために作られるかもしれないいくつかの実用的な推奨事項は以下のものが挙げられます。 subrootsはルートからそれらに提供されているマルチキャストグループの参加者リストを変更することが許されるべきではありません。ルートはsubrootsにそれを提供する前に、リストに署名するために、これを達成する一つの方法は次のようになります。認定subrootsはかかわらず、階層でその下のユーザーのための新しいマルチキャストグループを設定する許可することができます。
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 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.
また、鍵管理方式があるどんなことに留意されたい（階層ツリー、分散階層ツリー、コアベースのツリー、GKMP、など）、があるだろう「ヒット」最初のマルチキャストグループのネットキーでマルチキャストグループを初期化するために計上しました。このように、階層ツリーアプローチは、初期化に関して他の方式と比較して追加の複雑さに悩まされません。
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.
例えば、単一のルートの場合、階層は、グループの参加者リストを生成する開始剤（また、通常ルート）により、beginnningに、一度設定されています。各参加者のためのキーのグループは、個別に要求することができる（引っ張る）としてすぐにではなくなるまで、各参加者がセッションに参加することを希望します。
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.
マルチキャストグループの2人のユーザーが互いに厳密に通信したい、と誰もが通信を盗聴しないようにしたいとき、これに関連する別のアイデアがケースです。マルチキャストグループが最初に設定されている場合、この通信関係が既知であれば、これらの2人の参加者は、単に、（バイナリノードの下）階層の最下位レベルで互いに隣接して配置することができます。このように、彼らは自然に秘密鍵ペアを共有することになります。それ以外の場合は、これを実現する簡単な方法は、自分のプライベートなユニキャスト通信のためのトラフィック暗号化キーを生成するために2人のユーザー間での公開鍵ベースの鍵ペア交換を実行することです。このプロセスを通じて、それらの間の暗号化送信はそれらだけで読めるようになるだけでなく、ユニークな送信者認証は、ペアワイズ交換をベースと公開鍵を介して達成することができます。
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 participants hold in common with the removed node.
第2に示されるように、必要性は、バルクのユーザを削除するために発生する可能性があります。全て同じノードの下にある安全に通信したいサブグループに、セクション5.4.1で説明したように、ユーザーが設定している場合、全ノードが削除される場合、バルクユーザ除去が非常に簡単に行うことができます。セクション5.4.1に記載したのと同じ手法は、残りの参加者が削除したノードに共通に保持する任意の共有ノード鍵をリキーするために行われます。
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.
インターネットエンジニアリングタスクフォース（IETF）セキュリティSubworkingグループ[refにNSAの提案。 3]と題し、「インターネットSecurity AssociationとKey Managementプロトコル（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.
この報告書で述べたように、マルチキャストキー管理の問題の解決に取り組むとき、心配には主に2つの領域があります。彼らは、一般的なネットキーを持つマルチキャストグループの安全な初期化と再入力されています。現時点では、そこにマルチキャストグループの初期化に取り組む複数の論文ですが、彼らは十分に効率的かつ安全に、マルチキャストグループから妥協したユーザを削除する方法を扱っていません。
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.ハーニー、H.、Muckenhirn、C.およびT.川、 "グループ鍵管理プロトコルアーキテクチャ"、RFC 2094、1994年9月。
2. Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management Protocol Specification", RFC 2093, September 1994.
2.ハーニー、H.、Muckenhirn、C.およびT.川、 "グループ鍵管理プロトコル仕様"、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.モーガン、D.、Schertler、M.シュナイダー、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.ウォン、C.、ゴーダ、M.とS.ラム、「キーグラフを使用してグループ通信をセキュア」、テクニカルレポートTR 97から23、コンピュータ科学科、オースチン、1997年7月のテキサス大学。
Authors' Addresses
著者のアドレス
Debby M. Wallner National Security Agency Attn: R2 9800 Savage Road STE 6451 Ft. Meade, MD. 20755-6451
デビーM. Wallnerの国家安全保障局（NSA）の事務局担当：R2 9800サベージ道路STE 6451フィート。ミード、MD。 20755-6451
Phone: 301-688-0331 EMail: dmwalln@orion.ncsc.mil
電話：301-688-0331 Eメール：dmwalln@orion.ncsc.mil
Eric J. Harder National Security Agency Attn: R2 9800 Savage Road STE 6451 Ft. Meade, MD. 20755-6451
エリック・J.ハーダー国家安全保障局（NSA）の事務局担当：R2 9800サベージ道路STE 6451フィート。ミード、MD。 20755-6451
Phone: 301-688-0850 EMail: ejh@tycho.ncsc.mil
電話：301-688-0850 Eメール：ejh@tycho.ncsc.mil
Ryan C. Agee National Security Agency Attn: R2 9800 Savage Road STE 6451 Ft. Meade, MD. 20755-6451
ライアン・C.アゲ国家安全保障局（NSA）の事務局担当：R2 9800サベージ道路STE 6451フィート。ミード、MD。 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 Editor機能のための基金は現在、インターネット協会によって提供されます。