RFC4082 日本語訳
4082 Timed Efficient Stream Loss-Tolerant Authentication (TESLA):Multicast Source Authentication Transform Introduction. A. Perrig, D.Song, R. Canetti, J. D. Tygar, B. Briscoe. June 2005. (Format: TXT=54316 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Perrig
Request for Comments: 4082 D. Song
Category: Informational Carnegie Mellon University
R. Canetti
IBM
J. D. Tygar
University of California, Berkeley
B. Briscoe
BT
June 2005
Perrigがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4082年のD.歌のカテゴリ: 情報のカーネギーメロン大学のTygarカリフォルニア大学バークレイ校B.ブリスコウBT R.カネッティIBM J.D.2005年6月
Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
Multicast Source Authentication Transform Introduction
調節された効率的なストリーム損失許容性がある認証(テスラ): マルチキャストソース認証変換序論
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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.
このドキュメントはTimed Efficient Stream Loss許容性があるAuthentication(テスラ)を導入します。 テスラは、すべての受信機にマルチキャストか放送データ・ストリームで保全をチェックして、それぞれのパケットの源を認証させます。テスラは、受信機の間で信頼を全く必要としないで、また送付者と受信機の両方で1パケットあたりの安価の操作を使用して、「再-トランスミッション」なしでどんなレベルの損失も黙認できて、送付者で1受信機あたりの状態を全く必要としません。 テスラはある特定の状況ではサービス不能攻撃に対して受信機を保護できます。 それぞれの受信機はメッセージについて確かめるために時間によって緩くソースに連動されていなければなりませんが、さもなければ、受信機はどんなメッセージも送る必要はありません。 テスラだけがデータ送信端末の非拒否を第三者にサポートすることができません。
This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts.
この情報のドキュメントが、異なった文脈でテスラに基づくプロトコルのための標準化可能であって安全な仕様を書くのを助けることを意図します。
Perrig, et al. Informational [Page 1] RFC 4082 TESLA Introduction June 2005
Perrig、他 [1ページ]情報のRFC4082テスラ序論2005年6月
Table of Contents
目次
1. Introduction ....................................................2
1.1. Notation ...................................................3
2. Functionality ...................................................4
2.1. Threat Model and Security Guarantee ........................5
2.2. Assumptions ................................................5
3. The Basic TESLA Protocol ........................................6
3.1. Protocol Sketch ............................................6
3.2. Sender Setup ...............................................7
3.3. Bootstrapping Receivers ....................................8
3.3.1. Time Synchronization ................................9
3.4. Broadcasting Authenticated Messages .......................10
3.5. Authentication at Receiver ................................11
3.6. Determining the Key Disclosure Delay ......................12
3.7. Denial of Service Protection ..............................13
3.7.1. Additional Group Authentication ....................14
3.7.2. Not Re-using Keys ..................................15
3.7.3. Sender Buffering ...................................17
3.8. Some Extensions ...........................................17
4. Layer Placement ................................................17
5. Security Considerations ........................................18
6. Acknowledgements ...............................................19
7. Informative References .........................................19
1. 序論…2 1.1. 記法…3 2. 機能性…4 2.1. 脅威モデルとセキュリティ保証…5 2.2. 仮定…5 3. 基本的なテスラプロトコル…6 3.1. スケッチについて議定書の中で述べてください…6 3.2. 送付者セットアップ…7 3.3. 受信機を独力で進みます…8 3.3.1. 時間同期化…9 3.4. 放送はメッセージを認証しました…10 3.5. 受信機での認証…11 3.6. 主要な公開遅れを決定します…12 3.7. サービス妨害保護…13 3.7.1. 追加グループ認証…14 3.7.2. キーを再使用しません…15 3.7.3. 送付者バッファリング…17 3.8. いくつかの拡大…17 4. プレースメントを層にしてください…17 5. セキュリティ問題…18 6. 承認…19 7. 有益な参照…19
1. Introduction
1. 序論
In multicast, a single packet can reach millions of receivers. Unfortunately, this introduces the danger that an attacker can potentially also reach millions of receivers with a malicious packet. Through source authentication, receivers can ensure that a received multicast packet originates from the correct source. In these respects, a multicast is equivalent to a broadcast to a superset of the multicast receivers.
マルチキャストでは、単一のパケットは何百万台もの受信機に達することができます。 残念ながら、これはまた、攻撃者が悪意があるパケットで潜在的に何百万台もの受信機に達することができるという危険を導入します。 ソース認証で、受信機は、容認されたマルチキャストパケットが正しいソースから発するのを確実にすることができます。 これらの点で、マルチキャストはマルチキャスト受信機のスーパーセットへの放送に同等です。
In unicast communication, we can achieve data authentication through a simple mechanism: the sender and the receiver share a secret key to compute a message authentication code (MAC) of all communicated data. When a message with a correct MAC arrives, the receiver is assured that the sender generated that message. Standard mechanisms achieve unicast authentication this way; for example, TLS or IPsec [1,2].
ユニキャストコミュニケーションでは、私たちは簡単なメカニズムを通してデータ認証を達成できます: 送付者と受信機は、すべてのコミュニケートしているデータのメッセージ確認コード(MAC)を計算するために秘密鍵を共有します。 正しいMACがあるメッセージが到着するとき、受信機は送付者がそのメッセージを生成したことが保証されます。 標準のメカニズムはユニキャスト認証をこの道に実現します。 例えば、TLSかIPsec[1、2]。
Symmetric MAC authentication is not secure in a broadcast setting. Consider a sender that broadcasts authentic data to mutually mistrusting receivers. The symmetric MAC is not secure: every receiver knows the MAC key and therefore could impersonate the sender and forge messages to other receivers. Intuitively, we need an asymmetric mechanism to achieve authenticated broadcast, such that
左右対称のMAC認証は放送設定で安全ではありません。 互いに疑っている受信機に典拠のある資料を放送する送付者を考えてください。 左右対称のMACは安全ではありません: したがって、あらゆる受信機が、MACキーを知って、送付者をまねて、他の受信機にメッセージを作り出すかもしれません。 直観的に、私たちは認証された放送を達成するために非対称のメカニズムを必要として、そのようなものはそれです。
Perrig, et al. Informational [Page 2] RFC 4082 TESLA Introduction June 2005
Perrig、他 [2ページ]情報のRFC4082テスラ序論2005年6月
every receiver can verify the authenticity of messages it receives, without being able to generate authentic messages. Achieving this in an efficient way is a challenging problem [3].
あらゆる受信機がそれが正統のメッセージを生成することができないで受け取るメッセージの信憑性について確かめることができます。 効率的な方法でこれを達成するのは、やりがいがある問題[3]です。
The standard approach to achieving such asymmetry for authentication is to use asymmetric cryptography; e.g., a digital signature. Digital signatures have the required asymmetric property: the sender generates the signature with its private key, and all receivers can verify the signature with the sender's public key, but a receiver with the public key alone cannot generate a digital signature for a new message. A digital signature provides non-repudiation, a stronger property than authentication. However, digital signatures have a high cost: they have a high computation overhead for both the sender and the receiver, and most signatures also have a high- bandwidth overhead. Since we assume broadcast settings for which the sender does not retransmit lost packets, and the receiver still wants to authenticate each packet it receives immediately, we would need to attach a digital signature to each message. Because of the high overhead of asymmetric cryptography, this approach would restrict us to low-rate streams, and to senders and receivers with powerful workstations. We can try to amortize one digital signature over multiple messages. However, this approach is still expensive in contrast to symmetric cryptography, since symmetric cryptography is in general 3 to 5 orders of magnitude more efficient than asymmetric cryptography. In addition, the straight-forward amortization of one digital signature over multiple packets requires reliability, as the receiver needs to receive all packets to verify the signature. A number of schemes that follow this approach are [4,5,6,7]. See [8] for more details.
認証のためにそのような非対称を達成することへの標準のアプローチは非対称の暗号を使用することです。 例えば、デジタル署名。 デジタル署名には、必要な非対称の特性があります: 送付者は秘密鍵で署名を生成します、そして、すべての受信機が送付者の公開鍵がある署名について確かめることができますが、公開鍵が単独の受信機は新しいメッセージのためのデジタル署名を生成することができません。 デジタル署名は非拒否、認証より強い資産を提供します。 しかしながら、デジタル署名には、高い費用があります: また、彼らは送付者と受信機とほとんどの署名の両方のための高い計算オーバーヘッドに高い帯域幅オーバーヘッドを持たせます。 それでも、送付者が無くなっているパケットを再送しない放送設定、および受信機がそれがすぐに受ける各パケットを認証する必需品であると思って、私たちは、各メッセージにデジタル署名を付ける必要があるでしょう。 非対称の暗号の高いオーバーヘッドのために、このアプローチは私たちを低率ストリームと、そして、強力なワークステーションがある送付者と受信機に制限するでしょう。 私たちは複数のメッセージの上の1つのデジタル署名を清算しようとすることができます。 しかしながら、このアプローチは左右対称の暗号と対照してまだ高価です、左右対称の暗号が一般にそうので。3〜5の非対称であるより何桁も効率的な暗号。 さらに、複数のパケットの上の1つのデジタル署名の簡単な清算は信頼性を必要とします、受信機が、署名について確かめるためにすべてのパケットを受ける必要があるとき。 このアプローチに続く多くの体系が[4、5、6、7]です。 その他の詳細のための[8]を見てください。
This document presents the Timed Efficient Stream Loss-tolerant Authentication protocol (TESLA). TESLA uses mainly symmetric cryptography, and uses time-delayed key disclosure to achieve the required asymmetry property. However, TESLA requires loosely synchronized clocks between the sender and the receivers. See more details in Section 3.3.1. Schemes that follow a similar approach to TESLA are [9,10,11].
このドキュメントはTimed Efficient Stream Loss許容性があるAuthenticationプロトコル(テスラ)を提示します。 テスラは、必要な非対称の特性を獲得するのに主に左右対称の暗号を使用して、時間で遅れた主要な公開を使用します。 しかしながら、テスラは送付者と受信機の間の緩く連動している時計を必要とします。 セクション3.3.1におけるその他の詳細を見てください。 テスラへの同様のアプローチに続く体系は[9、10、11]です。
1.1. Notation
1.1. 記法
To denote the subscript or an index of a variable, we use the
underscore between the variable name and the index; e.g., the key K
with index i is K_i, and the key K with index i+d is K_{i+d}. To
write a superscript, we use the caret; e.g., function F with the
argument x executed i times is F^i(x).
変数の添字かインデックスを指示するために、私たちは変数名とインデックスの間の強調を使用します。 例えば、インデックスiがある主要なKはK_iです、そして、インデックスi+dがある主要なKはK_i+dです。 上付き文字を書くために、私たちは脱字記号を使用します。 例えば、議論のx実行されたi回数がある機能FはF^i(x)です。
Perrig, et al. Informational [Page 3] RFC 4082 TESLA Introduction June 2005
Perrig、他 [3ページ]情報のRFC4082テスラ序論2005年6月
2. Functionality
2. 機能性
TESLA provides delayed per-packet data authentication and integrity checking. The key idea to providing both efficiency and security is a delayed disclosure of keys. The delayed key disclosure results in an authentication delay. In practice, the delay is on the order of one RTT (round-trip-time).
テスラは1パケットあたりの遅れたデータ認証と保全の照合を提供します。 効率とセキュリティの両方を提供することへの主要な考えはキーの遅れた公開です。 遅れた主要な公開は認証遅れをもたらします。 実際には、1RTT(往復の時間)の注文には遅れがあります。
TESLA has the following properties:
テスラには、以下の特性があります:
o Low computation overhead for generation and verification of
authentication information.
o 認証情報の世代と検証のための低い計算オーバーヘッド。
o Low communication overhead.
o 低いコミュニケーションオーバーヘッド。
o Limited buffering required for the sender and the receiver, and
therefore timely authentication for each individual packet.
o 株式会社バッファリングがそれぞれの個々のパケットのための送付者と受信機の、そして、したがって、タイムリーな認証に必要です。
o Strong robustness to packet loss.
o パケット損失への強い丈夫さ。
o Scales to a large number of receivers.
o 多くの受信機へのスケール。
o Protects receivers from denial of service attacks in certain
circumstances if configured appropriately.
o ある特定の状況では適切に構成されるなら、サービス不能攻撃から受信機を保護します。
o Each receiver cannot verify message authenticity unless it is
loosely time-synchronized with the source, where synchronization
can take place at session setup. Once the session is in
progress, receivers need not send any messages or
acknowledgements.
o それが時間によってソース(同期はセッションセットアップで行われることができる)に緩く連動させられていない場合、各受信機はメッセージの信憑性について確かめることができません。 セッションがいったん進行していると、受信機は少しのメッセージや承認も送る必要はありません。
o Non-repudiation is not supported; each receiver can know that a
stream is from an authentic source, but cannot prove this to a
third party.
o 非拒否はサポートされません。 各受信機は、ストリームが信頼できる筋から来ていますが、第三者にこれを立証できないのを知ることができます。
TESLA can be used in the network layer, in the transport layer, or in the application layer. Delayed authentication, however, requires buffering of packets until authentication is completed. Certain applications intolerant of delay may be willing to process packets in parallel to being buffered while awaiting authentication, as long as roll-back is possible if packets are later found to be unauthenticated. For instance, an interactive video may play out packets still awaiting authentication, but if they are later found to be unauthenticated, it could stop further play-out and warn the viewer that the last x msec were unauthenticated and should be ignored. However, in the remainder of this document, for brevity, we will assume that packets are not processed in parallel to buffering.
トランスポート層の中、または、ネットワーク層か、応用層の中でテスラを使用できます。 しかしながら、遅れた認証は、認証が終了するまでパケットがバッファリングするのを必要とします。 遅れで偏狭なあるアプリケーションは、認証を待っている間、バッファリングされると平行なパケットを処理しても構わないと思っているかもしれません、パケットが後で非認証されるのがわかっているなら後退復帰が可能である限り。 例えば、双方向テレビがまだ認証を待っているパケットを終えるかもしれませんが、彼らが後で非認証されるのがわかっているなら、それは、外での一層のプレーであるのを止めて、最後のx msecが非認証されて、無視されるべきであるとビューアーに警告するかもしれません。 しかしながら、このドキュメントの残りでは、簡潔さのために、私たちは、パケットが平行でバッファリングに処理されないと思うつもりです。
Perrig, et al. Informational [Page 4] RFC 4082 TESLA Introduction June 2005
Perrig、他 [4ページ]情報のRFC4082テスラ序論2005年6月
2.1. Threat Model and Security Guarantee
2.1. 脅威モデルとセキュリティ保証
We design TESLA to be secure against a powerful adversary with the following capabilities:
私たちは以下の能力がある強敵に対して安全になるようにテスラを設計します:
o Full control over the network. The adversary can eavesdrop,
capture, drop, re-send, delay, and alter packets.
o ネットワークの完全なコントロール。 敵は、パケットを盗み聞いて、キャプチャして、下げて、再送して、遅らせて、変更できます。
o Access to a fast network with negligible delay.
o 取るにたらない遅れがある速いネットワークへのアクセス。
o The adversary's computational resources may be very large, but
not unbounded. In particular, this means that the adversary can
perform efficient computations, such as computing a reasonable
number of pseudo-random function applications and MACs with
negligible delay. Nonetheless, the adversary cannot find the
key of a pseudo-random function (or distinguish it from a random
function) with non-negligible probability.
o 敵のコンピュータのリソースは、非常に大きいのですが、限りなくないかもしれません。 特に、これは、敵が効率的な計算を実行できることを意味します、取るにたらない遅れがある擬似ランダム関数適用とMACsの相当な数を計算するのなどように。 それにもかかわらず、敵は非取るにたらない確率で擬似ランダム機能(確率関数とそれを区別する)のキーを見つけることができません。
The security property of TESLA guarantees that the receiver never accepts M_i as an authentic message unless the sender really sent M_i. A scheme that provides this guarantee is called a secure broadcast authentication scheme.
テスラのセキュリティの特性は、送付者が本当にM_iを送らなかったなら受信機が正統のメッセージとしてM_iを決して認めないのを保証します。 この保証を提供する体系は安全な放送認証体系と呼ばれます。
Because TESLA expects the receiver to buffer packets before authentication, the receiver needs to protect itself from a potential denial of service (DoS) attack due to a flood of bogus packets (see Section 3.8).
テスラが、受信機が認証の前にパケットをバッファリングすると予想するので、受信機は、にせのパケットの洪水によるサービス(DoS)攻撃の潜在的否定から我が身をかばう必要があります(セクション3.8を見てください)。
2.2. Assumptions
2.2. 仮定
TESLA makes the following assumptions in order to provide security:
テスラはセキュリティを提供するために以下の仮定をします:
1. The sender and the receiver must be loosely time-synchronized.
Specifically, each receiver must be able to compute an upper
bound on the lag of the receiver clock relative to the sender
clock. We denote this quantity with D_t. (That is, D_t =
sender time - receiver time). We note that an upper bound on
D_t can easily be obtained via a simple two-message exchange.
(Such an exchange can be piggybacked on any secure session
initiation protocol. Alternatively, standard protocols such
as NTP [15] can be used.
1. 送付者と受信機は時間によって緩く連動されていなければなりません。 明確に、それぞれの受信機は受信機時計の立ち遅れのときに送付者時計に比例して上限を計算できなければなりません。 私たちはD_tでこの量を指示します。 (送付者すなわち、D_t=時間--受信機時間)。 私たちは、簡単な2交換処理で容易にD_tの上限を得ることができることに注意します。 どんな安全なセッション開始プロトコルでもそのような交換を背負うことができます。(あるいはまた、NTP[15]などの標準プロトコルを使用できます。
2. TESLA MUST be bootstrapped at session setup through a regular
data authentication system. One option is to use a digital
signature algorithm for this purpose, in which case the
receiver is required to have an authentic copy of either the
sender's public key certificate or a root key certificate in
2. 通常のデータ認証システムを通してセッションセットアップでテスラを独力で進まなければなりません。 1つのオプションは受信機がどの場合にこのために送付者の公開鍵証明書かルートキー証明書のどちらかの正本を持たなければならないかにデジタル署名アルゴリズムを使用することです。
Perrig, et al. Informational [Page 5] RFC 4082 TESLA Introduction June 2005
Perrig、他 [5ページ]情報のRFC4082テスラ序論2005年6月
case of a PKI (public-key infrastructure). Alternatively,
this initialization step can be done using any secure session
initiation protocol.
PKI(公開鍵インフラストラクチャ)に関するケース。 あるいはまた、この初期化ステップはどんな安全なセッション開始プロトコルも使用し終わることができます。
3. TESLA uses cryptographic MAC and PRF (pseudo-random
functions). These MUST be cryptographically secure. Further
details on the instantiation of the MAC and PRF are in Section
3.4.
3. テスラは暗号のMACとPRF(擬似ランダム機能)を使用します。 これらは暗号でそうであるに違いありません。安全。 MACとPRFの具体化に関する詳細がセクション3.4にあります。
We would like to emphasize that the security of TESLA does NOT rely on any assumptions about network propagation delay.
テスラのセキュリティがネットワーク伝播遅延に関する少しの仮定にも依存しないと強調したいと思います。
3. The Basic TESLA Protocol
3. 基本的なテスラプロトコル
TESLA is described in several academic publications: A book on broadcast security [12], a journal paper [13], and two conference papers [7,14]. Please refer to these publications for in-depth proofs of security, experimental results, etc.
テスラはいくつかのアカデミックな刊行物で説明されます: 放送セキュリティ[12]に関する本、ジャーナル論文[13]、および2つの会議論文[7、14]。 セキュリティの徹底的な証拠、実験結果などについてこれらの刊行物を参照してください。
We first outline the main ideas behind TESLA.
私たちは最初に、テスラの後ろに本旨について概説します。
3.1. Protocol Sketch
3.1. プロトコルスケッチ
As we argue in the introduction, broadcast authentication requires a source of asymmetry. TESLA uses time for asymmetry. We first make sure that the sender and receivers are loosely time-synchronized as described above. Next, the sender forms a one-way chain of keys, in which each key in the chain is associated with a time interval (say, a second). Here is the basic approach:
私たちが序論で論争するように、放送認証はソースに非対称を要求します。 テスラは非対称のために時間を費やします。 私たちは、最初に、送付者と受信機が上で説明されるように時間によって緩く連動されているのを確実にします。 次に、送付者はキーの一方向チェーンを形成します。(そこでは、チェーンにおけるそれぞれのキーが時間間隔(たとえば、1秒)に関連しています)。 ここに、基本的なアプローチがあります:
o The sender attaches a MAC to each packet. The MAC is computed
over the contents of the packet. For each packet, the sender
uses the current key from the one-way chain as a cryptographic
key to compute the MAC.
o 送付者は各パケットにMACを取り付けます。 MACはパケットのコンテンツに関して計算されます。 各パケットに関しては、送付者は、MACを計算するのに暗号化キーとして一方向チェーンから現在のキーを使用します。
o The sender discloses a key from the one-way chain after some
pre-defined time delay (e.g., the key used in time interval i is
disclosed at time interval i+3).
o 或るものが時間遅れを事前に定義した後に送付者が一方向チェーンからキーを明らかにする、(例えばiが時間間隔を置いて明らかにされる時間間隔で使用されるキー、i+3)
o Each receiver receives the packet. Each receiver knows the
schedule for disclosing keys and, since it has an upper bound on
the local time at the sender, it can check that the key used to
compute the MAC was not yet disclosed by the sender. If it was
not, then the receiver buffers the packet. Otherwise the packet
is dropped due to inability to authenticate. Note that we do
not know for sure whether a "late packet" is a bogus one or
o 各受信機はパケットを受けます。 各受信機はキーを明らかにするので、スケジュールを知っています、そして、現地時間に送付者に上限を持っているので、MACを計算するのに使用されるキーが送付者によってまだ明らかにされていなかったのはチェックできます。 そして、それがそうでなかったなら、受信機はパケットをバッファリングします。 さもなければ、パケットは認証する無能のため落とされます。 または私たちが、「遅いパケット」がにせのものであるかどうかを確かに知らないことに注意してください。
Perrig, et al. Informational [Page 6] RFC 4082 TESLA Introduction June 2005
Perrig、他 [6ページ]情報のRFC4082テスラ序論2005年6月
simply a delayed packet. We drop the packet because we are
unable to authenticate it. (Of course, an implementation may
choose not to drop packets and to use them unauthenticated.)
単に遅れたパケット。 私たちは、それを認証できないので、パケットを落とします。 (もちろん、実現はパケットを落とさないのを選ぶかもしれなくて、それらを使用するのは非認証されました。)
o Each receiver checks that the disclosed key belongs to the
hash-chain (by checking against previously released keys in the
chain) and then checks the correctness of the MAC. If the MAC
is correct, the receiver accepts the packet.
o 各受信機は、明らかにされたキーが細切れ肉料理チェーン(以前にリリースされたキーに対してチェーンでチェックするのによる)のもの、をチェックして、次に、MACの正当性をチェックします。 MACが正しいなら、受信機はパケットを受け入れます。
Note that one-way chains have the property that if intermediate values of the one-way chain are lost, they can be recomputed using subsequent values in the chain. Even if some key disclosures are lost, a receiver can recover the corresponding keys and check the correctness of earlier packets.
片道チェーンには片道チェーンの中間的値が無くなって、それらがあることができるということであるならチェーンにその後の値を使用することで再計算された特性があることに注意してください。 いくつかの主要な公開が無くなっても、受信機は、対応するキーを回収して、以前のパケットの正当性をチェックできます。
We now describe the stages of the basic TESLA protocol in this order: sender setup, receiver bootstrap, sender transmission of authenticated broadcast messages, and receiver authentication of broadcast messages.
私たちは現在、この順で基本的なテスラプロトコルのステージについて説明します: 送付者セットアップ、受信機は独力で進んで、認証されることの送付者トランスミッションはメッセージ、および同報メッセージの受信機認証を放送しました。
3.2. Sender Setup
3.2. 送付者セットアップ
The sender divides the time into uniform intervals of duration T_int. The sender assigns one key from the one-way chain to each time interval in sequence.
送付者は時間を持続時間T_intの一定の間隔に分割します。 送付者は連続して1個の片道チェーンからそれぞれの時間間隔までのキーを割り当てます。
The sender determines the length N of the one-way chain K_0,
K_1, ..., K_N, and this length limits the maximum transmission
duration before a new one-way chain must be created. The sender
picks a random value for K_N. Using a pseudo-random function (PRF),
f, the sender constructs the one-way function F: F(k) = f_k(0). The
rest of the chain is computed recursively using K_i = F(K_{i+1}).
Note that this gives us K_i = F^{N-i}(K_N), so the receiver can
compute any value in the key chain from K_N, even if it does not have
intermediate values. The key K_i will be used to authenticate
packets sent in time interval i.
送付者は片道チェーンK_0、K_1の長さNを測定します…, K、およびaの前に新しく片道の最大のトランスミッション持続時間がチェーニングするこの長さの限界はそうであるに違いありません。作成にされる。 送付者は無作為の値をKに選びます。 擬似ランダム機能(PRF)、fを使用して、送付者は一方向関数Fを構成します: F(k)はf_k(0)と等しいです。 チェーンの残りは、K_i=F(K_i+1)を再帰的に使用することで計算されます。 これがK_iを私たちに与えるというメモは^F N-iと等しいです。(K) したがって、受信機はKからキーチェーンにおけるどんな値も計算できます、それに中間的値がなくても。 主要なK_iは、時間間隔iで送られたパケットを認証するのに使用されるでしょう。
Jakobsson [20] and Coppersmith and Jakobsson [21] present a storage- and computation-efficient mechanism for one-way chains. For a chain of length N, storage is about log(N) elements, and the computation overhead to reconstruct each element is also about log(N).
Jakobsson[20]、Coppersmith、およびJakobsson[21]は片道チェーンのために格納と計算効率的なメカニズムを提示します。 長さNのチェーンにおいて、格納はログ(N)要素に関するものです、そして、各要素を再建する計算オーバーヘッドはログ(N)に関してもものです。
The sender determines the duration of a time interval, T_int, and the key disclosure delay, d. (T_int is measured in time units, say milliseconds, and d is measured in number of time intervals. That is, a key that is used for time interval i will be disclosed in time interval i+d.) It is stressed that the scheme remains secure for any values of T_int and d>0. Still, correct choice of T_int and d is
送付者は時間間隔、T_int、および主要な公開遅れ、dの持続時間を決定します。 (ミリセカンドを言って、T_intはタイム・ユニットで測定されます、そして、dは時間間隔の数で測定されます。 すなわち、iが中で明らかにされる時間間隔の間に使用されるキーは間隔を調節します。i+d。) 計画がT_intとd>0のどんな値にも安全なままで残っていると強調されます。 それでも、T_intとdの正しい選択はそうです。
Perrig, et al. Informational [Page 7] RFC 4082 TESLA Introduction June 2005
Perrig、他 [7ページ]情報のRFC4082テスラ序論2005年6月
crucial for the usability of the scheme. The choice is influenced by the estimated network delay, the length of the transmission, and the tolerable delay at the receiver. A T_int that is too short will cause the keys to run out too soon. A T_int that is too long will cause excessive delay in authentication for some of the packets (those that were sent at the beginning of a time period). A delay d that is too short will cause too many packets to be unverifiable by the receiver. A delay d that is too long will cause excessive delay in authentication.
計画のユーザビリティのために、重要です。 選択はおよそネットワーク遅延、トランスミッションの長さ、および受信機の許容できる遅れによって影響を及ぼされます。短過ぎるT_intはあまりに早く、キーをなくならせるでしょう。 長過ぎるT_intはいくつかのパケット(期間の始めに送られたもの)の認証の過度の遅れを引き起こすでしょう。 少し過ぎる遅れdは、受信機であまりに多くのパケットが立証不可能であることを引き起こすでしょう。長過ぎる遅れdは認証の過度の遅れを引き起こすでしょう。
The sender estimates a reasonable upper bound on the network delay between the sender and any receiver as m milliseconds. This includes any delay expected in the stack (see Section 4, on layer placement). If the sender expects to send a packet every n milliseconds, then a reasonable value for T_int is max(n,m). Based on T_int, a rule of thumb for determining the key disclosure delay, d, is given in Section 3.6.
送付者は、送付者とmとしてのどんな受信機の間のネットワーク遅延に関する妥当な上限がミリセカンドであると見積もっています。 これはスタックで予想されたどんな遅れも含んでいます(層のプレースメントにセクション4を見てください)。 送付者が、nミリセカンドあたり1つのパケットに発信すると予想するなら、T_intのための適正価値は最大(n、m)です。 T_intに基づいて、セクション3.6で主要な公開遅れを決定するための経験則(d)を与えます。
The above value for T_int is neither an upper or a lower bound; it is merely the value that reduces key change processing to a minimum without causing authentication delay to be higher than necessary. If the application can tolerate higher authentication delay, then T_int can be made appropriately larger. Also, if m (or n) increases during the session, perhaps due to congestion or a late joiner on a high delay path, T_int need not be revised.
T_intのための上の値はどちらの上側の、または、下側でないバウンドであるのも。 必要とするより高いのは、単に認証遅れを引き起こさないでキーチェンジ処理を最小限まで抑える値です。 アプリケーションが、より高い認証遅れを許容できるなら、適切にT_intをより大きくすることができます。 また、m(または、n)がセッションの間、増加するなら、恐らく混雑か高い遅れ経路の故joinerのため、T_intは改訂される必要はありません。
Finally, the sender needs to allow each receiver to synchronize its time with the sender. See more details on how this can be done in Section 3.3.1. (It is stressed that estimating the network delay is a separate task from the time synchronization between the sender and the receivers.)
最終的に、送付者は、各受信機が時間を送付者と同期させるのを許容する必要があります。 セクション3.3.1でどうこれができるかに関するその他の詳細を見てください。 (ネットワーク遅延を見積もるのが、送付者と受信機の間の時間同期化からの別々のタスクであると強調されます。)
3.3. Bootstrapping Receivers
3.3. 受信機を独力で進みます。
Before a receiver can authenticate messages with TESLA, it needs to have the following:
受信機がテスラがいるメッセージを認証できる前に、以下を必要とします:
o An upper bound, D_t, on the lag of its own clock with respect to
the clock of the sender. (That is, if the local time reading is
t, the current time reading at the sender is at most t+D_t.).
o 上限、D_tはそれ自身の立ち遅れのときに送付者の時計に関して時間を計ります。 (すなわち、現地時間の読書がtであるなら、送付者での現在の時間読書は高々t+D_t.です。)
o One authenticated key of the one-way key chain. (Typically,
this will be the last key in the chain; i.e., K_0. This key
will be signed by the sender, and all receivers will verify the
signature with the public key of the signer.)
o 1つは片道キーチェーンのキーを認証しました。 (これはチェーンで最後の通常、キーになるでしょう; すなわち、K_0、このキーは送付者によってサインされて、すべての受信機が署名者の公開鍵がある署名について確かめるでしょう。)
Perrig, et al. Informational [Page 8] RFC 4082 TESLA Introduction June 2005
Perrig、他 [8ページ]情報のRFC4082テスラ序論2005年6月
o The disclosure schedule of the following keys:
o 以下のキーの公開スケジュール:
- T_int, the interval duration.
- T_0, the start time of interval 0.
- N, the length of the one-way key chain.
- d, the key disclosure delay d (in number of intervals).
- T_int、間隔持続時間。 - T_0、間隔0の開始時刻。 - N、片道キーチェーンの長さ。 - d、主要な公開遅れd(間隔の数における)。
The receiver can perform the time synchronization and get the authenticated TESLA parameters in a two-round message exchange, as described below. We stress again that time synchronization can be performed as part of the registration protocol between any receiver (including late joiners) and the sender, or between any receiver and a group controller.
受信機は、ラウンドの2交換処理で時間同期化を実行して、認証されたテスラパラメタを得ることができます、以下で説明されるように。 私たちは、どんな受信機(故joinersを含んでいる)と送付者か、どんな受信機とグループコントローラの間の登録プロトコルの一部として時間同期化を実行できると再び強調します。
3.3.1. Time Synchronization
3.3.1. 時間同期化
Various approaches exist for time synchronization [15,16,17,18]. TESLA only requires the receiver to know an upper bound on the delay of its local clock with respect to the sender's clock, so a simple algorithm is sufficient. TESLA can be used with direct, indirect, and delayed synchronization as three default options. The specific synchronization method will be part of each instantiation of TESLA.
様々なアプローチは時間同期化[15、16、17、18]のために存在しています。 テスラが地方の時計の遅れで送付者の時計に関して上限を知るために受信機を必要とするだけであるので、簡単なアルゴリズムは十分です。 ダイレクトで、間接的で、遅れた同期と共に3つの省略時のオプションとしてテスラを使用できます。 特定の同期方法はテスラのそれぞれの具体化の一部になるでしょう。
For completeness, we sketch a simple method for direct synchronization between the sender and a receiver:
完全性のために、私たちは送付者と受信機の間のダイレクト同期のための簡単な方法をスケッチします:
o The receiver sends a (sync t_r) message to the sender and
records its local time, t_r, at the moment of sending.
o 受信機は、(同時性t_r)メッセージを送付者に送って、現地時間の_t rを記録します、発信の瞬間に。
o Upon receipt of the (sync t_r) message, the sender records its
local time, t_s, and sends (synch, t_r,t_s) to the receiver.
o (同時性t_r)メッセージを受け取り次第、送付者は、受信機に現地時間の_t sを記録して、(同時性、t_r、t_s)を送ります。
o Upon receiving (synch,t_r,t_s), the receiver sets D_t = t_s -
t_r + S, where S is an estimated bound on the clock drift
throughout the duration of the session.
o 受信(同時性、t_r、t_s)のときに、受信機セットD_tはt_sと等しいです--t_r+S。(そこでは、Sがセッションの持続時間中で時計ドリフトでおよそ制限されています)。
Note:
以下に注意してください。
o Assuming that the messages are authentic (i.e., the message
received by the receiver was actually sent by the sender), and
assuming that the clock drift is at most S, then at any point
throughout the session T_s < T_r + D_t, where T_s is the current
time at the sender and T_r is the current time at the receiver.
o メッセージが正統であると(すなわち、受信機によって受け取られたメッセージは実際に送付者によって送られました)仮定して、時計ドリフトが高々Sであると仮定する場合、セッションT_s<T_r+D_t中の任意な点では、T_sが送付者とT_rのどこの現在の時間であるかが受信機の現在の時間です。
o The exchange of sync messages needs to be authenticated. This
can be done in a number of ways; for instance, with a secure NTP
protocol or in conjunction with a session set-up protocol.
o 同時性メッセージの交換は、認証される必要があります。 多くの方法でこれができます。 例えば、安全なNTPプロトコルかセッションセットアップに関連して、議定書を作ってください。
Perrig, et al. Informational [Page 9] RFC 4082 TESLA Introduction June 2005
Perrig、他 [9ページ]情報のRFC4082テスラ序論2005年6月
For indirect time synchronization (e.g., synchronization via a group controller), the sender and the controller engage in a protocol for finding the value D^0_t between them. Next, each receiver, R, interacts with the group controller (say, when registering to the group) and finds the value D^R_t between the group controller and R. The overall value of D_t within R is set to the sum D_t = D^R_t + D^0_t.
間接的な時間同期化(例えば、グループコントローラを通した同期)、送付者、およびコントローラに関しては、それらの間で値Dが^0_tであることがわかるためにプロトコルに従事してください。 次に、各受信機、Rは、グループコントローラ(たとえばグループに登録するとき)と対話して、R. Rの中のD_tのグループコントローラと総合的な値の間の値D^Rの_tがD^R_t+D合計D_t=^0_tに用意ができているのがわかります。
3.4. Broadcasting Authenticated Messages
3.4. 放送はメッセージを認証しました。
Each key in the one-way key chain corresponds to a time interval. Every time a sender broadcasts a message, it appends a MAC to the message, using the key corresponding to the current time interval. The key remains secret for the next d-1 intervals, so messages that a sender broadcasts in interval j effectively disclose key K_j-d. We call d the key disclosure delay.
片道キーチェーンにおける各キーは時間間隔に対応しています。 送付者がメッセージを放送するときはいつも、MACをメッセージに追加します、現在の時間間隔に対応するキーを使用して。 キーが次のd-1間隔の間、秘密のままで残っているので、送付者が間隔jで有効に放送するというメッセージは主要なK_j-dを明らかにします。 私たちは、dを主要な公開遅れと呼びます。
We do not want to use the same key multiple times in different
cryptographic operations; that is, using key K_j to derive the
previous key of the one-way key chain K_{j-1}, and using the same key
K_j as the key to compute the MACs in time interval j may potentially
lead to a cryptographic weakness. Using a pseudo-random function
(PRF), f', we construct the one-way function F': F'(k) = f'_k(1). We
use F' to derive the key to compute the MAC of messages in each
interval. The sender derives the MAC key as follows: K'_i = F'(K_i).
Figure 1 depicts the one-way key chain construction and MAC key
derivation. To broadcast message M_j in interval i the sender
constructs the packet
異なった暗号の操作に同じキー倍数回数を使用したいと思いません。 すなわち、時間間隔jでMACsを計算するキーが潜在的に暗号の弱点に通じるかもしれなくて_片道キーチェーンK j-1の前のキーを引き出すのにキーK_jを使用して、同じ主要なK_jを使用すること。 '擬似ランダム機能(PRF)、fを使用し'て、私たちは一方向関数F'を構成します: F'(k)はf'_k(1)と等しいです。 '私たちは、各間隔でメッセージのMACを計算するためにキーを引き出すのにF'を使用します。 送付者は以下のMACキーを引き出します: 'K'_iはF'と等しいです(K_i)。 図1は片道キーチェーン建築とMACの主要な派生について表現します。 送付者がパケットを組み立てる間隔iでメッセージM_jを放送するために
P_j = {M_j || i || MAC(K'_i,M_j) || K_{i-d}}
P_j='_M_j| | i| | MAC(K'_i、M_j)| | K i-d
where || denotes concatenation.
どこ|| 連結を指示します。
F(K_i) F(K_{i+1}) F(K_{i+2})
K_{i-1} <------- K_i <------- K_{i+1} <------- K_{i+2}
_F(K_i)F(K_i+1)F(K_i+2)K i-1、<。------- K_i<。------- K_i+1<。------- K_i+2
| | |
| F'(K_{i-1}) | F'(K_i) | F'(K_{i+1})
| | |
V V V
| | | | 'F'(_K i-1)| 'F'(K_i)| 'F'(K_i+1)| | | V V V
K'_{i-1} K'_i K'_{i+1}
_'K'i-1K'_i K'_i+1
Figure 1: At the top of the figure, we see the one-way key chain (derived using the one-way function F), and the derived MAC keys (derived using the one-way function F').
図1: '図の先端では、私たちは片道キーチェーン(一方向関数Fを使用することで、引き出される)、および派生しているMACキー(一方向関数F'を使用することで、引き出される)を見ます。
Perrig, et al. Informational [Page 10] RFC 4082 TESLA Introduction June 2005
Perrig、他 [10ページ]情報のRFC4082テスラ序論2005年6月
3.5. Authentication at Receiver
3.5. 受信機での認証
Once a sender discloses a key, we must assume that all parties might have access to that key. An adversary could create a bogus message and forge a MAC using the disclosed key. So whenever a packet arrives, the receiver must verify that the MAC is based on a safe key; a safe key is one that is still secret (known only by the sender). We define a safe packet or safe message as one with a MAC that is computed with a safe key.
送付者がいったんキーを明らかにすると、私たちは、すべてのパーティーがそのキーに近づく手段を持っているかもしれないと思わなければなりません。 敵は、明らかにされたキーを使用することでにせのメッセージを作成して、MACを鍛造できるでしょう。 それで、パケットが到着するときはいつも、受信機は、MACが安全なキーに基づいていることを確かめなければなりません。 安全なキーはまだ秘密の(単に送付者によって知られています)ものです。 私たちは安全なキーで計算されるMACと共に安全なパケットか安全なメッセージを1つと定義します。
If a packet proves safe, it will be buffered, only to be released when its own key, disclosed in a later packet, proves its authenticity. Although a newly arriving packet cannot immediately be authenticated, it may disclose a new key so that earlier, buffered packets can be authenticated. Any newly disclosed key must be checked to determine whether it is genuine; then authentication of buffered packets that have been waiting for it can proceed.
パケットが安全であると判明すると、それはバッファリングされて、それ自身のものであるときに、リリースされるためだけに、後のパケットで明らかにされたキーは、信憑性を立証します。 すぐに新たに到着しているパケットは認証できませんが、それは、より早くバッファリングされたパケットを認証できるように新しいキーを明らかにするかもしれません。 それが本物であるかどうか決定するためにどんな新たに明らかにされたキーもチェックしなければなりません。 そして、それを待っているバッファリングされたパケットの認証は続くことができます。
We now describe TESLA authentication at the receiver with more detail, listing all of these steps in the exact order they should be carried out:
私たちは現在受信機でその他の詳細でテスラの認証について説明して、正確なオーダーにおけるこれらのステップのすべてを記載して、それらが行われるべきです:
1. Safe packet test: When the receiver receives packet P_j, which
carries an interval index i, and a disclosed key K_{i-d}, it
first records local time T at which the packet arrived. The
receiver then computes an upper bound t_j on the sender's
clock at the time when the packet arrived: t_j = T + D_t. To
test whether the packet is safe, the receiver then computes
the highest interval x the sender could possibly be in; namely
x = floor((t_j - T_0) / T_int). The receiver verifies that x
< i + d (where i is the interval index), which implies that
the sender is not yet in the interval during which it
discloses the key K_i.
1. 安全なパケットテスト: 受信機がいつ、パケットP_jを受けるか、そして、aは_キーK i-dを明らかにして、それは最初に、パケットが到着した記録現地時間Tです。パケットは間隔インデックスiを運びます。 次に、パケットが到着したとき、受信機は送付者の時計の上で上限t_jを計算します: t_jはT+D_tと等しいです。 次に、パケットが安全であるか否かに関係なく、テストするために、受信機は送付者がいるかもしれない最も高い間隔xを計算します。 すなわち、xは床(t_j--T_0)/T_int)と等しいです。 受信機はそのx<i+d(iが間隔インデックスであるところ)について確かめます。(それは、送付者がまだそれが主要なK_iを明らかにする間隔にいないのを含意します)。
Even if the packet is safe, the receiver cannot yet verify the
authenticity of this packet sent in interval i without key
K_i, which will be disclosed later. Instead, it adds the
triplet ( i, M_j, MAC( K'_i, M_j) ) to a buffer and verifies
the authenticity after it learns K'_i.
パケットが安全であっても、受信機はまだ後でのキーK_iのない間隔iの間の送られたこのパケットの信憑性について確かめることができません。キーは明らかにされるでしょう。 'それは、代わりに、三つ子(i、M_j、MAC(K'_i、M_j))をバッファに追加して、K'_iを学んだ後に信憑性について確かめます。
If the packet is unsafe, then the receiver considers the
packet unauthenticated. It should discard unsafe packets,
but, at its own risk it may choose to use them unverified.
パケットが危険であるなら、受信機は、パケットが非認証されたと考えます。 危険なパケットを捨てるべきですが、自分の責任でそれは、非検証されていた状態でそれらを使用するのを選ぶかもしれません。
2. New key index test: Next the receiver checks whether a key K_v
has already been disclosed with the same index v as the
current disclosed key K_{i-d}, or with a later one; that is,
with v >= i-d.
2. 新しいキー索引テスト: 次に、受信機は、主要なKが_現在の明らかにされた主要なK i-dと同じインデックスv、または後のもので既に明らかにされたかどうかチェックします。 すなわち、vで、>はi-dと等しいです。
Perrig, et al. Informational [Page 11] RFC 4082 TESLA Introduction June 2005
Perrig、他 [11ページ]情報のRFC4082テスラ序論2005年6月
3. Key verification test: If the disclosed key index is new, the
receiver checks the legitimacy of K_{i-d} by verifying, for
some earlier disclosed key K_v (v<i-d), that K_v = F^{i-d-
v}(K_{i-d}).
3. キー検証テスト: 明らかにされたキー索引が新しいなら、受信機は、何らかの以前の明らかにされた主要なK(<i-dに対する)のために、F^そのK=i-d v(_K i-d)について確かめることによって、_K i-dの合法性をチェックします。
If key verification fails, the newly arrived packet P_j should
be discarded.
キー検証が失敗するなら、新たに到着したパケットP_jは捨てられるべきです。
4. Message verification tests: If the disclosed key is
legitimate, the receiver then verifies the authenticity of any
earlier safe, buffered packets of interval i-d. To
authenticate one of the buffered packets P_h containing
message M_h protected with a MAC that used key index i-d, the
receiver will compute K'_{i-d} = F'(K_{i-d}) from which it can
compute MAC( K'_{i-d}, M_h).
4. メッセージ検証はテストされます: 明らかにされたキーが正統であるなら、受信機は間隔i-dのどんな以前の安全で、バッファリングされたパケットの信憑性についても確かめます。 'キー索引i-dを使用したMACと共に保護されたメッセージM_hを含んでいて、バッファリングされたパケットP_hの1つを認証するために、受信機はそれがMAC(_K'i-d、M_h)を計算できる_K'i-d=F'(_K i-d)を計算するでしょう。
If this MAC equals the MAC stored in the buffer, the packet is
authenticated and can be released from the buffer. If the
MACs do not agree, the buffered packet P_h should be
discarded.
このMACがバッファに格納されたMACと等しいなら、パケットを認証して、バッファから放出できます。 MACsが同意しないなら、バッファリングされたパケットP_hは捨てられるべきです。
The receiver continues to verify and release (or not) any
remaining buffered packets that depend on the newly disclosed
key K_{i-d}.
受信機は、(or not)を確かめて、リリースし続けています。どんな残りも_新たに明らかにされた主要なK i-dによるパケットをバッファリングしました。
Using a disclosed key, we can calculate all previous disclosed keys, so even if packets are lost, we will still be able to verify buffered, safe packets from earlier time intervals. Thus, if i-d- v>1, the receiver can also verify the authenticity of the stored packets of intervals v+1 ... i-d-1.
明らかにされたキーを使用して、前のすべての明らかにされたキーが計算高いことができるので、パケットが無くなっても、私たちは以前の時間間隔からバッファリングされて、安全なパケットについてまだ確かめることができるでしょう。 したがって、また、i-dである、対>1なら、受信機は+1に対して間隔の保存されたパケットの信憑性について確かめることができます… i-d-1。
3.6. Determining the Key Disclosure Delay
3.6. 主要な公開遅れを決定します。
An important TESLA parameter is the key disclosure delay d. Although the choice of the disclosure delay does not affect the security of the system, it is an important performance factor. A short disclosure delay will cause packets to lose their safety property, so receivers will not be able to authenticate them; but a long disclosure delay leads to a long authentication delay for receivers. We recommend determining the disclosure delay as follows: In direct time synchronization, let the RTT, 2m, be a reasonable upper bound on the round trip time between the sender and any receiver including worst-case congestion delay and worst-case buffering delay in host stacks. Then choose d = ceil( 2m / T_int) + 1. Note that rounding up the quotient ensures that d >= 2. Also note that a disclosure delay of one time interval (d=1) does not work. Consider packets sent close to the boundary of the time interval: After the network propagation delay and the receiver time synchronization error, a
重要なテスラパラメタは主要な公開遅れdです。 公開遅れの選択はシステムのセキュリティに影響しませんが、それは重要な性能要素です。 パケットが少し公開遅れで彼らの安全の特性をなくすので、受信機はそれらを認証できないでしょう。 しかし、長い公開遅れは受信機のための長い認証遅れにつながります。 私たちは、以下の公開遅れを決定することを勧めます: ダイレクト時間同期化では、RTTをさせてください、そして、最悪の場合混雑遅れとホストスタックの遅れをバッファリングする最悪の場合を含む送付者とどんな受信機の間の周遊旅行時間の2m、妥当な上限になってください。 その時、d=ceil(_の2m/Tのint)+1は選ばれます。 商がそのd>=2を確実にするその一斉逮捕に注意してください。 また、1回の時間間隔(d=1)の公開遅れが働かないことに注意してください。 時間間隔の境界の近くで送られたパケットを考えてください: ネットワーク伝播遅延と受信機時間同期化誤り、aの後に
Perrig, et al. Informational [Page 12] RFC 4082 TESLA Introduction June 2005
Perrig、他 [12ページ]情報のRFC4082テスラ序論2005年6月
receiver will not be able to authenticate the packet, because the sender will already be in the next time interval when it discloses the corresponding key.
受信機はパケットを認証できないでしょう、送付者がそれが対応するキーを明らかにする次の時間間隔に既にいるので。
Measuring the delay to each receiver before determining m will still not adequately predict the upper bound on delay to late joiners, or where congestion delay rises later in the session. It may be adequate to use a hard-coded historic estimate of worst-case delay (e.g., round trip delays to any host on the intra-planetary Internet rarely exceed 500msec if routing remains stable).
それでも、mを決定する前に各受信機に遅れを測定するのは、故joinersへの遅れの上限かそれとも混雑遅れがセッションのときに、より遅くどこに上昇するかを適切に予測しないでしょう。 最悪の場合遅れの一生懸命コード化された歴史的な見積りを使用するのは適切であるかもしれません(ルーティングが安定した状態を保つなら、例えば、イントラ惑星ののインターネットのどんなホストへの周遊旅行遅れもめったに500msecを超えていません)。
We stress that the security of TESLA does not rely on any assumptions about network propagation delay: If the delay is longer than expected, then authentic packets may be considered unauthenticated. Still, no inauthentic packet will be accepted as authentic.
私たちは、テスラのセキュリティがネットワーク伝播遅延に関する少しの仮定にも依存しないと強調します: 遅れが予想より長いなら、正統のパケットは非認証されていると考えられるかもしれません。 それでも、どんな本物でないパケットも正統であるとして認められないでしょう。
3.7. Denial of Service Protection
3.7. サービス妨害保護
Because TESLA authentication is delayed, receivers seem vulnerable to flooding attacks that cause them to buffer excess packets, even though they may eventually prove to be inauthentic. When TESLA is deployed in an environment with a threat of flooding attacks, the receiver can take a number of extra precautions.
テスラの認証が遅れるので、受信機はそれらが余分なパケットをバッファリングするフラッディング攻撃に被害を受け易く見えます、結局、本物でないと判明するかもしれませんが。 テスラがフラッディング攻撃の脅威で環境で配布されるとき、受信機は多くの付加的な注意を払うことができます。
First, we list simple DoS mitigation precautions that can and should be taken by any receiver independently of others, thus requiring no changes to the protocol or sender behaviour. We precisely specify where these extra steps interleave with the receiver authentication steps already given in Section 3.5.
まず最初に、私たちは払うことができて、他のものの如何にかかわらずどんな受信機によっても払われるべきである簡単なDoS緩和注意を記載します、その結果、プロトコルか送付者のふるまいへの変化を全く必要としません。 私たちは、これらの付加的なステップが受信機でセクション3.5で既に与えられた認証ステップをどこにはさみ込むかを正確に指定します。
o Session validity test: Before the safe packet test (Step 1),
check that arriving packets have a valid source IP address and
port number for the session, that they do not replay a message
already received in the session, and that they are not
significantly larger than the packet sizes expected in the
session.
o セッション正当性テスト: 安全なパケットテスト(ステップ1)の前に、到着パケットには有効なソースIPアドレスとポートナンバーがセッションのためにあって、セッションのときに既に受け取られたメッセージを再演しないで、またそれらがセッションのときに予想されたパケットサイズよりかなり大きくないのをチェックしてください。
o Reasonable misordering test: Before the key verification test
(Step 3), check whether the disclosed key index i-d of the
arriving packet is within g of the previous highest disclosed
key index v; thus, for example, i-d-v <= g. g sets the
threshold beyond which an out-of-order key index is assumed to
be malicious rather than just misordered. Without this test, an
attacker could exploit the iterated test in Step 3 to make
receivers consume inordinate CPU time checking along the hash
chain for what appear to be extremely misordered packets.
o 合理的なmisorderingテスト: キー検証テスト(ステップ3)の前に、前の最も高い明らかにされたキー索引vのgの中に到着パケットの明らかにされたキー索引i-dがあるかチェックしてください。 このようにして、例えば、i-d-v<=g.gは、不適切なキー索引が想定される敷居にただmisorderedしたよりむしろ悪意があるように設定します。 このテストがなければ、受信機に何が非常にmisorderedされたパケットであるように見えるかがないかどうかハッシュチェーンに沿ってチェックしながら過度のCPU時間を費やさせるのに攻撃者はStep3での繰り返されたテストを利用できました。
Perrig, et al. Informational [Page 13] RFC 4082 TESLA Introduction June 2005
Perrig、他 [13ページ]情報のRFC4082テスラ序論2005年6月
Each receiver can independently adapt g to prevailing attack
conditions; for instance, by using the following algorithm.
Initially, g should be set to g_max (say, 16). But whenever an
arriving packet fails the reasonable misordering test above or
the key verification test (Step 3), g should be dropped to g_min
(>0 and typically 1). At each successful key verification (Step
3), g should be incremented by 1 unless it is already g_max.
These precautions will guarantee that sustained attack packets
cannot cause the receiver to execute more than an average of
g_min hashes each, unless they are paced against genuine
packets. In the latter case, attacks are limited to
g_max/(g_max-g_min) hashes per each genuine packet.
各受信機は独自に行き渡っている攻撃状態にgを適合させることができます。 例えば、使用するのによる以下のアルゴリズム。 初めは、gはg_最大(たとえば、16)に設定されるべきです。 しかし、到着パケットが上のテストかキー検証テスト(ステップ3)をmisorderingしながら妥当に失敗するときはいつも、gはg_分(>0と通常1)に下げられるべきです。 それぞれのうまくいっているキー検証(ステップ3)のときに、gはそれが既にg_最大でない場合1つ増加されるべきです。 これらの注意は、パケットで十二分に平均にg_分を受信機を実行できない持続している攻撃がそれぞれを論じ尽くすのを保証するでしょう、それらが本物のパケットに対して歩調を合わせられない場合。 後者の場合では、攻撃はそれぞれの本物のパケットあたりのg_最大/(g_最大g_分)ハッシュに制限されます。
When choosing g_max and g_min, note that they limit the average
gap in a packet sequence to g.max(n,m)/n packets (see Section
3.2 for definitions of n and m). So with g=1, m=100msec RTT,
and n=4msec inter-packet period, reordering would be limited to
gaps of 25 packets on average. Bigger naturally occurring gaps
would have to be written off as if they were losses.
g_最大とg_分を選ぶときには、彼らがパケット系列の平均したギャップをg.最大(n、m)/nパケットに制限することに注意してください(nとmの定義に関してセクション3.2を見てください)。 それで、g=1、m=100msec RTT、および4msec相互パケットのn=期間で、再命令は25のパケットのギャップに平均的に制限されるでしょう。 より大きい自然に起こっているギャップはまるでそれらが損失であるかのようにすぐに書かれなければならないでしょう。
Stronger DoS protection requires that both senders and receivers arrange additional constraints on the protocol. Below, we outline three alternative extensions to basic TESLA; the first adding group authentication, the second not re-using keys during a time interval, and the third moving buffering to the sender.
より強いDoS保護は、送付者と受信機の両方がプロトコルに追加規制を配置するのを必要とします。 以下では、私たちが3つの代替の拡大について基本的なテスラに概説します。 最初の付加は認証、時間間隔の間にキーを再使用しない秒、および3番目の感動的なバッファリングを送付者に分類します。
It is important to understand the applicability of each scheme, as the first two schemes use slightly more (but bounded) resources in order to prevent attackers from consuming unbounded resources. Adding group authentication requires larger per-packet overhead. Never re-using a key requires both ends to process two hashes per packet (rather than per time interval), and the sender must store or re-generate a longer hash chain. The merits of each scheme, summarised after each is described below, must be weighed against these additional costs.
それぞれの体系の適用性を理解しているのは重要です、最初の2つの体系が攻撃者が限りないリソースを消費するのを防ぐのにわずかに多くて(境界がある)のリソースを使用するとき。 グループ認証を加えるのは1パケットあたりの、より大きいオーバーヘッドを必要とします。 キーを決して再使用しないのが1パケットあたり2つのハッシュを処理するために両端を必要とする、(むしろ、時間間隔、)、送付者は、より長いハッシュチェーンを保存しなければならないか、または作り直さなければなりません。 それぞれが以下で説明された後に略言したそれぞれの体系の長所についてこれらの別途費用に比較考量しなければなりません。
3.7.1. Additional Group Authentication
3.7.1. 追加グループ認証
This scheme simply involves addition of a group MAC to every packet. That is, a shared key K_g common to the whole group is communicated as an additional step during receiver bootstrap (Section 3.3). Then, during broadcast of message M_j (Section 3.4), the sender computes the group MAC of each packet MAC(K_g, P_j), which it appends to the packet header. Note that the group MAC covers the whole packet P_j; that is, the concatenation of the message M_j and the additional TESLA authentication material, using the formula in Section 3.4.
この体系は単にグループMACの追加にあらゆるパケットにかかわります。 受信機の間の追加ステップが(セクション3.3)を独力で進むとき、すなわち、全体のグループに共通の共有されたキーK_gは伝えられます。 そして、メッセージM_j(セクション3.4)の放送の間、送付者は各パケットMAC(K_g、P_j)のグループMACを計算します。(それはMACをパケットのヘッダーに追加します)。 グループMACが全体のパケットP_jをカバーすることに注意してください。 すなわち、セクション3.4の公式を使用するメッセージM_jと追加テスラ認証の材料の連結。
Perrig, et al. Informational [Page 14] RFC 4082 TESLA Introduction June 2005
Perrig、他 [14ページ]情報のRFC4082テスラ序論2005年6月
Immediately upon packet arrival, each receiver can check that each packet came from a group member, by recomputing and comparing the group MAC.
すぐパケット到着のときに、各受信機は、各パケットがグループのメンバーから来たのをチェックできます、グループMACを再計算して、比較することによって。
Note that TESLA source authentication is only necessary when other group members cannot be trusted to refrain from spoofing the source; otherwise, simpler group authentication would be sufficient. Therefore, additional group authentication will only make sense in scenarios where other group members are trusted to refrain from flooding the group, but where they are still not trusted to refrain from spoofing the source.
他のグループのメンバーが、ソースを偽造するのを控えると信じることができないときだけ、テスラのソース認証が必要であることに注意してください。 さもなければ、より簡単なグループ認証は十分でしょう。 したがって、追加グループ認証は他のグループのメンバーがグループをあふれさせるのを控えると信じられますが、彼らはソースを偽造するのを控えるとまだ信じられていないシナリオで理解できるだけでしょう。
3.7.2. Not Re-using Keys
3.7.2. キーを再使用しません。
In TESLA as described so far, each MAC key was used repeatedly for all the packets sent in a time interval. If instead the sender were to guarantee never to use a MAC key more than once, each disclosed key could assume an additional purpose on top of authenticating a previously buffered packet. Each key would also immediately show each receiver that the sender of each arriving packet knew the next key back along the hash chain, which is now only disclosed once, similar to S/KEY [22]. Therefore a reasonable receiver strategy would be to discard any arriving packets that disclosed a key seen already. The fill rate of the receiver's buffer would then be clocked by each packet revealed by the genuine sender, preventing memory flooding attacks.
今までのところ説明されるテスラでは、それぞれのMACキーは時間間隔で送られたすべてのパケットに繰り返して使用されました。 送付者が、代わりに一度よりMACキーをさらに決して使用しないのを保証するなら、以前にバッファリングされたパケットを認証する上でそれぞれの明らかにされたキーは追加目的を仮定するかもしれないでしょうに。 また、各キーは、すぐにそれぞれの到着パケットの送付者がハッシュチェーンに沿って次のキーを知っていたのを各受信機に示すでしょう、S/KEY[22]と同様です。チェーンは現在、一度明らかにされるだけです。 したがって、合理的な受信機戦略はどんな到着パケットも捨てるために、それが既に見られたキーを明らかにしたということでしょう。 次に、受信機のバッファの中詰め率は本物の送付者によって明らかにされた各パケットによって時間を計られるでしょう、メモリフラッディング攻撃を防いで。
An attacker with control of a network element or of a faster bypass network could intercept messages and overtake or replace them with different messages but with the same keys. However, as long as packets are only buffered if they also pass the delay safety test, these bogus packets will fail TESLA verification after the disclosure delay. Admittedly, receivers could be fooled into discarding genuine messages that had been overtaken by bogus ones. But it is hard to overtake messages without compromising a network element, and any attacker that can compromise a network element can discard genuine messages anyway. We will now describe this scheme in more detail.
ネットワーク要素か、より速い迂回ネットワークのコントロールの攻撃者は、異なったメッセージにもかかわらず、同じキーにそれらをメッセージを傍受して、追いつくか、または取って代わることができました。 しかしながら、また、遅れ安全性試験に合格する場合にだけバッファリングされる限り、これらのにせのパケットは公開遅れの後にテスラの検証に失敗するでしょう。 明白に、にせのものによって追いつかれた本物のメッセージを捨てるように受信機をだますことができました。 ネットワーク要素に感染することができるどんな攻撃者も、しかし、ネットワーク要素に感染しないでメッセージに追いつきにくくて、とにかく本物のメッセージを捨てることができます。 私たちは現在、さらに詳細にこの体系について説明するつもりです。
For the sender, the scheme is hardly different from TESLA. It merely uses an interval duration short enough to ensure a new key back along the hash chain for each packet. So the rule of thumb given in Section 3.2 for an efficient re-keying interval T_int no longer applies. Instead, T_int is simply n, the inter-arrival time between packets in milliseconds. The rule of thumb for calculating d, the key disclosure delay, remains unchanged from that given in Section 3.6.
送付者にとって、体系はテスラとほとんど異なっていません。 それは単に各パケットのためにハッシュチェーンに沿って新しいキーを確実にすることができるくらい短い間隔持続時間を使用します。 それで、効率的な再の合わせる間隔T_intのためにセクション3.2で与えられた経験則はもう適用されません。 代わりに、T_intは単にn、パケットが間ミリセカンドで表現されるところの相互到着時間です。 計算のdのための経験則(主要な公開遅れ)はセクション3.6で与えられたそれから変わりがありません。
Perrig, et al. Informational [Page 15] RFC 4082 TESLA Introduction June 2005
Perrig、他 [15ページ]情報のRFC4082テスラ序論2005年6月
If the packet rate is likely to vary, for safety n should be taken as the minimum inter-departure time between any two packets. (In fact, n need not be so strict; it can be the minimum average packet inter- departure time over any burst of d packets expected throughout the session.)
パケットレートが安全のために異なりそうであるなら、nは最小の相互出発時間としてどんな2つのパケットの間にもみなされるべきです。 (事実上、nはそれほど厳しい必要はありません; それはdパケットのどんな炸裂もセッションの間中予想した最小の平均したパケット相互出発タイム・オーバーであるかもしれません。)
Note that if the packet rate slows down, whenever no packets are sent in a key change interval, the key index must increment along the hash chain once for each missed interval. (During a burst, if the less strict definition of n above has been used, packets may need to depart before their key change interval. The sender can safely continue changing the key for each packet, using keys from future key intervals, because if n has been chosen as defined above, such bursts will never sustain long enough to cause the associated key to be disclosed in a period less than the disclosure delay later.)
キーチェンジ間隔でパケットを全く送らないときはいつも、パケットレートが減速するなら、キー索引がそれぞれの逃された間隔の間ずっとハッシュチェーンを一度増加しなければならないことに注意してください。 (炸裂の間、nの上のそれほど厳しくない定義が使用されたなら、パケットは、彼らのキーチェンジ間隔の前に出発する必要があるかもしれません。 送付者は、各パケットのために安全にキーを変え続けることができます、将来の主要な間隔からキーを使用して、nが上で定義されるように選ばれたなら、そのような炸裂が後で公開遅れより少ない時代に明らかにされるために十分長い間関連キーを原因に決して支えないので。)
To be absolutely clear, the precise guarantees that the sender keeps to by following the above guidance are:
絶対に明確に、なるように、送付者が上の指導に続くことによって保つ正確な保証は以下の通りです。
o not to re-use a MAC key,
o MACキーを再使用しないように
o not to use a MAC key K_i after its time interval i, and
o そして時間間隔iの後にMACキーK_iを使用しないように。
o not to disclose key K_i sooner than the disclosure delay d *
T_int following the packet it protects.
o パケットに続いて、_公開遅れd*T intより早くキーK_iを明らかにしないように、それは保護されます。
Sender setup, receiver bootstrapping, and broadcasting authenticated messages are otherwise all identical to the descriptions in Sections 3.2, 3.3, and 3.4, respectively. However, the following step must be added to the receiver authentication steps in Section 3.5:
そうでなければ、送付者セットアップと、受信機ブートストラップ法と、認証されたメッセージを放送するのはセクション3.2、3.3、および3.4で記述とすべてそれぞれ同じです。 しかしながら、セクション3.5の受信機認証ステップに以下のステップを追加しなければなりません:
o After Step 2, if a packet arrives carrying a key index i-d that
has already been received, it should not be buffered.
o Step2の後に、パケットが既に受け取られた主要なインデックスi-dを運びながら到着するなら、それをバッファリングするべきではありません。
This simple scheme would suffice against DoS, were it not for the fact that a network sometimes misorders packets without being compromised. Even without control of a network element, an attacker can opportunistically exploit such openings to fool a receiver into buffering a bogus packet and discarding a later genuine one. A receiver can choose to set aside a fixed size cache and can manage it to minimise the chances of discarding a genuine packet. However, given such vulnerabilities are rare and unpredictable, it is simpler to count these events as additions to the network loss rate. As always, TESLA authentication will still uncover any bogus packets after the disclosure delay.
この簡単な体系はDoSに対して十分でしょう、aが時々感染されないでmisordersパケットをネットワークでつなぐという事実がなければ。 ネットワーク要素のコントロールがなくても、攻撃者は、受信機がにせのパケットをバッファリングして、後の本物のものを捨てるようにだますのにそのような始まりを便宜主義的に利用できます。 受信機は、固定サイズキャッシュをかたわらに置くのを選ぶことができて、本物のパケットを捨てるという機会を最小化させるためにそれに対処できます。 しかしながら、そのようなものを考えて、脆弱性がまれであって、予測できない、ネットワーク損失率への追加にこれらのイベントをみなすのは、より簡単です。 いつものように、それでも、テスラの認証は公開遅れの後にどんなにせのパケットも覆いを取るでしょう。
To summarise, avoiding re-using keys has the following properties, even under extreme flooding attacks:
キーが以下の特性で、極端なフラッディング攻撃で同等にする再使用を避けて、略言するために:
Perrig, et al. Informational [Page 16] RFC 4082 TESLA Introduction June 2005
Perrig、他 [16ページ]情報のRFC4082テスラ序論2005年6月
o After delayed TESLA authentication, packets arriving within the
disclosure delay will always be identified as authentic if they
are and as inauthentic if they are not authentic.
o 遅れたテスラの認証の後に、正統でないなら、あって、同じくらい本物でないなら、公開遅れの中で到着するパケットは正統であるとしていつも特定されるでしょう。
o The fill rate of the receiver's buffer is clocked by each packet
revealed by the genuine sender, preventing memory flooding
attacks.
o 受信機のバッファの中詰め率は本物の送付者によって明らかにされた各パケットによって時間を計られます、メモリフラッディング攻撃を防いで。
o An attacker with control of a network element can cause any loss
rate it chooses (but that's always true anyway).
o ネットワーク要素のコントロールの攻撃者はそれが選ぶどんな損失率も引き起こす場合があります(それはとにかくいつも本当です)。
o Where attackers do not have control of any network elements, the
effective loss rate is bounded by the sum of the network's
actual loss rate and its re-ordering rate.
o 攻撃者にはコントロールがないところでは、どんなネットワーク要素、レートは境界がある有効な損失ではも、ネットワークの実際の損失率の合計とその再注文は評価します。
3.7.3. Sender Buffering
3.7.3. 送付者バッファリング
Buffering of packets can be moved to the sender side; then receivers can authenticate packets immediately upon receipt. This method is described in [14].
パケットのバッファリングを送付者側に動かすことができます。 そして、受信機はすぐ領収書でパケットを認証できます。 このメソッドは[14]で説明されます。
3.8. Some Extensions
3.8. いくつかの拡大
Let us mention two salient extensions of the basic TESLA scheme. A first extension allows having multiple TESLA authentication chains for a single stream, where each chain uses a different delay for disclosing the keys. This extension is typically used to deal with heterogeneous network delays within a single multicast transmission. A second extension allows having most of the buffering of packets at the sender side (rather than at the receiver side). Both extensions are described in [14].
基本的なテスラ体系の2つの顕著な拡大について言及しましょう。 最初の拡大はただ一つのストリームのための複数のテスラ認証チェーンを持っています。そこでは、各チェーンが、キーを明らかにするのに異なった遅れを使用します。 この拡張子は、ただ一つのマルチキャスト送信の中で異機種ネットワーク遅れに対処するのに通常使用されます。 送付者側に2番目の拡大でパケットのバッファリングの大部分を持っている、(むしろ、受信機側、) 両方の拡大は[14]で説明されます。
TESLA's requirement that a key be received in a later packet for authentication prevents a receiver from authenticating the last part of a message. Thus, to enable authentication of the last part of a message or of the last message before a transmission suspension, the sender needs to send an empty message with the key.
キーが認証のための後のパケットで受け取られているというテスラの要件は、受信機がメッセージの最後の部分を認証するのを防ぎます。 したがって、トランスミッションサスペンションの前でメッセージの最後の部分か最後のメッセージの認証を可能にするために、送付者は、キーで空のメッセージを送る必要があります。
4. Layer Placement
4. 層のプレースメント
TESLA authentication can be performed at any layer in the networking stack. Three natural places are the network, transport, or application layer. We list some considerations regarding the choice of layer:
ネットワークスタックのどんな層でもテスラの認証を実行できます。 3つの自然な場所が、ネットワーク、輸送、または応用層です。 私たちは層の選択に関するいくつかの問題を記載します:
o Performing TESLA in the network layer has the advantage that the
transport or application layer only receives authenticated data,
potentially aiding a reliability protocol and mitigating denial
o ネットワーク層でテスラを実行して、潜在的に信頼性のプロトコルを支援して、否定を緩和して、輸送か応用層が受けるだけである利点はデータを認証しましたか?
Perrig, et al. Informational [Page 17] RFC 4082 TESLA Introduction June 2005
Perrig、他 [17ページ]情報のRFC4082テスラ序論2005年6月
of service attacks. (Indeed, reliable multicast tools based on
forward error correction are highly susceptible to denial of
service due to bogus packets.)
サービス攻撃について。 (本当に、前進型誤信号訂正に基づく信頼できるマルチキャストツールはにせのパケットのためにサービスの否定に非常に影響されやすいです。)
o Performing TESLA in either the transport or the application
layer has the advantage that the network layer remains
unchanged, but it has the potential drawback that packets are
obtained by the application layer only after being processed by
the transport layer. Consequently, if buffering is used in the
transport, then this may introduce additional and unpredictable
delays on top of the unavoidable network delays.
o 輸送か応用層のどちらかの中でテスラを実行するのにおいて、利点があります。ネットワーク層は変わりがありませんが、存在の後のだけ応用層のそばでトランスポート層によって処理されて、得た状態でパケットは潜在的欠点ですが、それは変わりがありました。 その結果、バッファリングが輸送が使用されているなら、これは避けられないネットワーク遅延の上で追加していて予測できない遅れを導入するかもしれません。
o Note that because TESLA relies upon timing of packets, deploying
TESLA on top of a protocol or layer that aggressively buffers
packets and hides the true packet arrival time will
significantly reduce TESLA's performance.
o プロトコルか層の上の積極的にパケットと獣皮をバッファリングするテスラに本当のパケット到着時間を配布するとテスラがパケットのタイミングを当てにするのでテスラの実績がかなり抑えられることに注意してください。
5. Security Considerations
5. セキュリティ問題
See the academic publications on TESLA [7,13,19] for several security analyses. Regarding the security of implementations, by far the most delicate point is the verification of the timing conditions. Care should be taken to make sure that (a) the value bound D_t on the clock skew is calculated according to the spec at session setup and that (b) the receiver records the arrival time of the packet as soon as possible after the packet's arrival, and computes the safety condition correctly.
数個の証券分析に関してテスラ[7、13、19]に関するアカデミックな刊行物を見てください。 実装のセキュリティに関して、断然最もデリケートなポイントはタイミング状態の検証です。 受信機が(a) 仕様に従って時計斜行の値のバウンドD_tがセッションセットアップで計算されて、パケットの到着の後にできるだけ早くパケットの到着時間を記録して、(b) 正しく安全状態を計算するのを確実にするために注意するべきです。
It should be noted that a change to the key disclosure schedule for a message stream should never be declared within the message stream itself. This would introduce a vulnerability, because a receiver that did not receive the notification of the change would still believe in the old key disclosure schedule.
メッセージストリームのための主要な公開スケジュールへの変化がメッセージストリーム自体の中で決して宣言されるべきでないことに注意されるべきです。 これは脆弱性を導入するでしょう、変化の通知を受け取らなかった受信機がまだ古い主要な公開スケジュールを信じているでしょう、したがって。
Finally, in common with all authentication schemes, if verification is located separately from the ultimate destination application (e.g., an IPSec tunnel end point), a trusted channel must be present between verification and the application. For instance, the interface between the verifier and the application might simply assume that packets received by the application must have been verified by the verifier (because otherwise they would have been dropped). The application is then vulnerable to reception of packets that have managed to bypass the verifier.
最終的に、検証が別々に最終仕向地アプリケーション(例えば、IPSecトンネルエンドポイント)から見つけられているなら、すべての認証体系と共用して信じられたチャンネルは検証とアプリケーションの間に出席していなければなりません。 例えば、検証とアプリケーションとのインタフェースは、アプリケーションで受け取られたパケットが検証によって確かめられたに違いないと単に仮定するかもしれません(さもなければ、それらが下げられたでしょう、したがって)。 アプリケーションはその時、検証を何とか迂回させたパケットのレセプションに被害を受け易いです。
Perrig, et al. Informational [Page 18] RFC 4082 TESLA Introduction June 2005
Perrig、他 [18ページ]情報のRFC4082テスラ序論2005年6月
6. Acknowledgements
6. 承認
We would like to thank the following for their feedback and support: Mike Luby, Mark Baugher, Mats Naslund, Dave McGrew, Ross Finlayson, Sylvie Laniepce, Lakshminath Dondeti, Russ Housley, and the IESG reviewers.
感謝申し上げる、彼らのフィードバックとサポートのための以下: マイクLuby、マークBaugher、マッツ・ジーター、デーヴ・マグリュー、ロスフィンリースン、シルヴィーLaniepce、Lakshminath Dondeti、ラスHousley、およびIESG評論家。
7. Informative References
7. 有益な参照
[1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[1] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[2] IPsec, "IP Security Protocol, IETF working group"
http://www.ietf.org/html.charters/OLD/ipsec-charter.html.
[2]IPsec、「IPセキュリティー・プロトコル、IETFワーキンググループ」、 http://www.ietf.org/html.charters/OLD/ipsec-charter.html 。
[3] D. Boneh, G. Durfee, and M. Franklin, "Lower bounds for
multicast message authentication," in Advances in Cryptology --
EUROCRYPT 2001 (B. Pfitzmann, ed.), Vol. 2045 of Lecture Notes
in Computer Science, (Innsbruck, Austria), p. 434-450,
Springer-Verlag, Berlin Germany, 2001.
[3] EUROCRYPT2001年(B.Pfitzmann(教育))のCryptology--Advances、コンピュータScience、(インスブルック(オーストリア))、pのLecture NotesのVol.2045におけるD.Boneh、G.DurfeeとM.フランクリン、「マルチキャスト通報認証のための下界。」 434-450、追出石-Verlag、ベルリンドイツ2001。
[4] R. Gennaro and P. Rohatgi, "How to Sign Digital Streams", tech.
rep., IBM T.J.Watson Research Center, 1997.
[4] 技術者R.ジェンナロとP.Rohatgi、「どうDigitalに署名するかは流れる」レップ、IBM T.J.ワトソン研究所、1997
[5] P. Rohatgi, "A compact and fast hybrid signature scheme for
multicast packet authentication", 6th ACM Conference on Computer
and Communications Security , November 1999.
[5]P.Rohatgiと「マルチキャストパケット認証のコンパクトで速いハイブリッド署名体系」とコンピュータの上の第6ACMコンファレンスとCommunications Security(1999年11月)。
[6] C. K. Wong and S. S. Lam, "Digital signatures for flows and
multicasts," in Proc. IEEE ICNP `98, 1998.
[6] C.K.ウォン、S.S.ラム、およびProcの「流れのためのデジタル署名とマルチキャスト。」 IEEE ICNP1998 98年。
[7] A. Perrig, R. Canetti, J. Tygar, and D. X. Song, "Efficient
authentication and signing of multicast streams over lossy
channels", IEEE Symposium on Security and Privacy, May 2000.
[7] A.PerrigとR.カネッティとJ.TygarとD.X.Songと「損失性チャンネルの上のマルチキャストストリームの効率的な認証と署名」とSecurityの上のIEEE SymposiumとPrivacy(2000年5月)。
[8] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B.
Pinkas, "Multicast security: A taxonomy and some efficient
constructions", Infocom '99, 1999.
[8] R.カネッティ、J.ガライ、G.Itkis、D.Micciancio、M.Naor、およびB.ピンカス、「マルチキャストセキュリティ:」 1999年の'Infocom'99の「分類学といくつかの効率的な構造」
[9] S. Cheung, "An efficient message authentication scheme for link
state routing", 13th Annual Computer Security Applications
Conference, 1997.
[9] S.チェン、「リンク州のルーティングの効率的な通報認証体系」、第13AnnualコンピュータSecurity Applicationsコンファレンス、1997。
[10] F. Bergadano, D. Cavagnino, and B. Crispo, "Chained stream
authentication," in Selected Areas in Cryptography 2000,
(Waterloo, Canada), August 2000. A talk describing this scheme
was given at IBM Watson in August 1998.
[10] Cryptography2000のSelected Areas、(ウォータールー(カナダ))、2000年8月のF.Bergadano、D.CavagninoとB.Crispo、「チェーニングされたストリーム認証。」 1998年8月にIBMのワトソンでこの体系について説明する話を与えました。
Perrig, et al. Informational [Page 19] RFC 4082 TESLA Introduction June 2005
Perrig、他 [19ページ]情報のRFC4082テスラ序論2005年6月
[11] F. Bergadano, D. Cavalino, and B. Crispo, "Individual single
source authentication on the mbone", ICME 2000, August 2000. A
talk containing this work was given at IBM Watson, August 1998.
[11] F.Bergadano、D.Cavalino、およびB.Crispo、「mboneにおける個々のただ一つのソース認証」、ICME2000、2000年8月。 IBMのワトソン、1998年8月にこの仕事を含む話を与えました。
[12] A. Perrig and J. D. Tygar, Secure Broadcast Communication in
Wired and Wireless Networks Kluwer Academic Publishers, October
2002. ISBN 0792376501.
[12] A.PerrigとJ.D.Tygar、Kluwerのアカデミックな出版社、2002年10月をワイアードにおける放送通信とワイヤレス・ネットワークに確保してください。 ISBN0792376501。
[13] A. Perrig, R. Canetti, J. D. Tygar, and D. Song, "The tesla
broadcast authentication protocol," RSA CryptoBytes, Volume 5,
No. 2 Summer/Fall 2002.
[13]A.PerrigとR.カネッティ、J.D.TygarとD.Song、「テスラ放送認証プロトコル」RSA CryptoBytes、Volume5、No.2Summer/秋の2002。
[14] A. Perrig, R. Canetti, D. Song, and J. D. Tygar, "Efficient and
secure source authentication for multicast", Network and
Distributed System Security Symposium, NDSS '01, p. 35-46,
February 2001.
[14] A.Perrig、R.カネッティ、D.Song、J.D.Tygar、「マルチキャストのための効率的で安全なソース認証」、Network、およびDistributed System Security Symposium(NDSS'01、p')。 35-46と、2001年2月。
[15] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992.
[15] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[16] B. Simons, J. Lundelius-Welch, and N. Lynch, "An overview of
clock synchronization", Fault-Tolerant Distributed Computing (B.
Simons and A. Spector, eds.), No. 448 in LNCS, p. 84-96,
Springer-Verlag, Berlin Germany, 1990.
[16] B.サイモンズ、J.ランデリウス-ウェルチとN.リンチ、「時計同期の概要」Fault許容性があるDistributed Computing(B.サイモンズとA.スペクター(eds))、LNCS(p)のNo.448。 84-96、追出石-Verlag、ベルリンドイツ1990。
[17] D. Mills, "Improved algorithms for synchronizing computer
network clocks", Proceedings of the conference on Communications
architectures, protocols and applications, SIGCOMM 94, (London,
England), p. 317-327, 1994.
[17] D.工場、「コンピュータネットワーク時計を連動させるための拡張アルゴリズム」、Communicationsアーキテクチャ、プロトコル、およびアプリケーションの会議のProceedings、SIGCOMM94、(ロンドン(イギリス))、p。 317-327, 1994.
[18] L. Lamport and P. Melliar-Smith, "Synchronizing clocks in the
presence of faults", J. ACM, Volume 32, No. 1, p. 52-78, 1985.
[18] L.ランポートとP.Melliar-スミス、「欠点があるとき時計を連動させます」、J. ACM、Volume32、No.1、p。 52-78, 1985.
[19] P. Broadfoot and G. Lowe, "Analysing a Stream Authentication
Protocol using Model Checking", Proceedings of the 7th European
Symposium on Research in Computer Security (ESORICS), 2002.
[19] P.BroadfootとG.ロウ、「モデルの照合を使用することでストリーム認証プロトコルを分析します」、研究のコンピュータセキュリティ(ESORICS)、2002による第7ヨーロッパのシンポジウムの議事。
[20] M. Jakobsson, "Fractal hash sequence representation and
traversal", Cryptology ePrint Archive,
http://eprint.iacr.org/2002/001/, January 2002.
[20]M.Jakobsson、「フラクタルは系列表現と縦断を論じ尽くす」Cryptology ePrintアーカイブ、 http://eprint.iacr.org/2002/001/ 、2002年1月。
[21] D. Coppersmith and M. Jakobsson, "Almost optimal hash sequence
traversal", Proceedings of the Sixth International Financial
Cryptography Conference (FC '02), March 2002.
[21]D.銅細工師とM.Jakobsson、「ほとんど最適のハッシュ系列縦断」、Sixthの国際Financial Cryptographyコンファレンス(FC'02)(2002'年3月)のProceedings。
[22] Haller, N., "The S/KEY One-Time Password System", RFC 1760,
February 1995.
[22] ハラー、1995年2月、N.、「S/主要なワンタイムパスワードシステム」RFC1760。
Perrig, et al. Informational [Page 20] RFC 4082 TESLA Introduction June 2005
Perrig、他 [20ページ]情報のRFC4082テスラ序論2005年6月
Authors' Addresses
作者のアドレス
Adrian Perrig ECE Department Carnegie Mellon University Pittsburgh, PA 15218 US
エードリアン・Perrig ECE部のカーネギーメロン大学PA15218ピッツバーグ(米国)
EMail: perrig@cmu.edu
メール: perrig@cmu.edu
Ran Canetti IBM Research 30 Saw Mill River Rd Hawthorne, NY 10532 US
米国でカネッティIBM Research30製材機械川の第サンザシ、ニューヨーク 10532を走らせました。
EMail: canetti@watson.ibm.com
メール: canetti@watson.ibm.com
Dawn Song ECE Department Carnegie Mellon University Pittsburgh, PA 15218 US
ドーン・歌のECE部のカーネギーメロン大学PA15218ピッツバーグ(米国)
EMail: dawnsong@cmu.edu
メール: dawnsong@cmu.edu
J. D. Tygar UC Berkeley - EECS & SIMS 102 South Hall 4600 Berkeley, CA 94720-4600 US
J.D.Tygar UCバークレー--南ホール4600EECSとシムズ102カリフォルニア94720-4600バークレー(米国)
EMail: doug.tygar@gmail.com
メール: doug.tygar@gmail.com
Bob Briscoe BT Research B54/77, BT Labs Martlesham Heath Ipswich, IP5 3RE UK
ボブブリスコウBT研究B54/77、BT研究室Martlesham HeathイプスウィッチIP5 3REイギリス
EMail: bob.briscoe@bt.com
メール: bob.briscoe@bt.com
Perrig, et al. Informational [Page 21] RFC 4082 TESLA Introduction June 2005
Perrig、他 [21ページ]情報のRFC4082テスラ序論2005年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Perrig, et al. Informational [Page 22]
Perrig、他 情報[22ページ]
一覧
スポンサーリンク
