[要約] RFC 4082は、マルチキャストソースの認証を効率的に行うためのプロトコルであるTESLAの紹介を行っています。この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
Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction
タイミングの効率的なストリーム損失耐性認証（TESLA）：マルチキャストソース認証変換紹介
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）The Internet Society（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.
このドキュメントでは、時限効率の高いストリーム損失耐性認証（TESLA）を紹介します。Teslaを使用すると、すべての受信機が整合性を確認し、各パケットのソースをマルチキャストまたはブロードキャストデータストリームで認証できます。Teslaは、受信者間の信頼を必要とせず、送信者と受信機の両方でパケットごとの低コスト操作を使用し、再送信なしであらゆるレベルの損失に耐えることができ、送信者にレシーバーごとの状態を必要としません。テスラは、特定の状況でのサービス攻撃の拒否から受信機を保護できます。各レシーバーは、メッセージを検証するためにソースと時間を緩やかに同期している必要がありますが、それ以外の場合は受信機がメッセージを送信する必要はありません。テスラだけでは、データソースの第三者への非繰り返しをサポートできません。
This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts.
この情報文書は、さまざまなコンテキストのテスラに基づいて、プロトコルの標準化可能な安全な仕様を書くのを支援することを目的としています。
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
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 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].
対称MAC認証は、ブロードキャスト設定では安全ではありません。本物のデータを相互に誤った受信者に放送する送信者を検討してください。対称MACは安全ではありません。すべてのレシーバーがMACキーを知っているため、送信者になりすまし、他の受信機にメッセージを偽装する可能性があります。直感的には、認証されたブロードキャストを実現するために非対称のメカニズムが必要です。これにより、すべてのレシーバーが、本物のメッセージを生成することなく、受信するメッセージの信頼性を確認できます。これを効率的な方法で達成することは、挑戦的な問題です[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].
このドキュメントでは、時限効率の高いストリーム損失耐性認証プロトコル（TESLA）を提示します。Teslaは主に対称的な暗号化を使用し、時間に遅れたキー開示を使用して、必要な非対称性を達成します。ただし、テスラは、送信者と受信機の間でゆるく同期したクロックを必要とします。セクション3.3.1の詳細を参照してください。テスラと同様のアプローチに従うスキームは[9,10,11]です。
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).
subscriptまたは変数のインデックスを示すために、変数名とインデックスの間のアンダースコアを使用します。たとえば、インデックスIのキーKはK_Iであり、インデックスI DのキーKはK_ {I D}です。上付き文字を書くには、CARETを使用します。たとえば、関数fを使用したxを実行しましたiはf^i（x）です。
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).
Teslaは、パケットごとのデータ認証と整合性チェックの遅延を提供します。効率とセキュリティの両方を提供する重要なアイデアは、キーの開示が遅れることです。遅延キー開示により、認証遅延が発生します。実際には、遅延は1つのRTT（往復時間）のオーダーです。
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が認知されておらず、無視する必要があることを視聴者に警告する可能性があります。ただし、このドキュメントの残りの部分では、簡潔にするために、パケットはバッファリングと並行して処理されないと仮定します。
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 敵の計算リソースは非常に大きいかもしれませんが、無制限ではありません。特に、これは、敵が、妥当な数の擬似ランダム機能アプリケーションを計算するなど、効率的な計算を実行できることを意味します。それにもかかわらず、敵は擬似ランダム関数の鍵を見つけることができません（または、無視できない確率でランダム関数と区別）。
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).
Teslaは受信者が認証前にパケットをバッファすることを期待しているため、レシーバーは偽のパケットの洪水による潜在的なサービス拒否（DOS）攻撃から身を保護する必要があります（セクション3.8を参照）。
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 =送信者時間 - 受信時間）。D_Tの上限は、単純な2メッセージ交換を介して簡単に取得できることに注意してください。（このような交換は、安全なセッション開始プロトコルでピギーバックすることができます。あるいは、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 case of a PKI (public-key infrastructure). Alternatively, this initialization step can be done using any secure session initiation protocol.
2. Teslaは、通常のデータ認証システムを介してセッションのセットアップでブートストラップする必要があります。1つのオプションは、この目的のためにデジタル署名アルゴリズムを使用することです。この場合、受信者は、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. Teslaは暗号化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.
テスラのセキュリティは、ネットワーク伝播遅延に関する仮定に依存していないことを強調したいと思います。
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.
最初にテスラの背後にある主なアイデアの概要を説明します。
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:
紹介で主張するように、放送認証には非対称性のソースが必要です。テスラは非対称性に時間を使用します。最初に、上記のように、送信者と受信機がゆるく時間を抑制していることを確認します。次に、送信者はキーの一方向チェーンを形成し、チェーン内の各キーが時間間隔（たとえば、秒）に関連付けられています。これが基本的なアプローチです：
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 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 各レシーバーはパケットを受信します。各レシーバーはキーを開示するためのスケジュールを知っており、送信者の現地時間に上限があるため、Macの計算に使用されるキーが送信者によってまだ開示されていないことを確認できます。そうでない場合は、受信機がパケットをバッファリングします。それ以外の場合は、認証ができないためにパケットが削除されます。「後期パケット」が偽の1つであるか、単に遅延パケットであるかどうかを確信していないことに注意してください。パケットを認証できないため、ドロップします。（もちろん、実装はパケットをドロップしないことを選択し、それらを許可されていないことを選択する場合があります。）
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.
次に、この順序で基本的なTeslaプロトコルの段階について説明します：送信者のセットアップ、受信者ブートストラップ、認証されたブロードキャストメッセージの送信者送信、およびブロードキャストメッセージの受信者認証。
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、...、k_nの長さnを決定し、この長さは、新しい一方向チェーンを作成する前に最大透過期間を制限します。送信者は、K_Nのランダム値を選択します。擬似ランダム関数（PRF）、Fを使用して、送信者は一方向関数f（k）= f_k（0）を構築します。チェーンの残りの部分は、k_i = f（k_ {i 1}）を使用して再帰的に計算されます。これにより、k_i = f^{n-i}（k_n）が得られることに注意してください。したがって、中間値がない場合でも、レシーバーはk_nからキーチェーンの任意の値を計算できます。キー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 and Jakobsson [21]は、一方向チェーンのストレージと計算効率の高いメカニズムを提示します。長さnのチェーンの場合、ストレージはlog（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 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、および主要な開示遅延dを決定します。（T_INTは時間単位で測定され、たとえばミリ秒単位で、Dは時間間隔数で測定されます。つまり、時間間隔に使用されるキーは、時間間隔で開示されます。）スキームが残ることを強調していますt_intとd> 0の値を保護します。それでも、スキームの使いやすさには、T_INTとDの正しい選択が重要です。選択は、推定ネットワーク遅延、送信の長さ、および受信機での許容遅延の影響を受けます。短すぎる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ミリ秒ごとにパケットを送信することを期待している場合、t_intの合理的な値は最大（n、m）です。T_INTに基づいて、主要な開示遅延を決定するための経験則Dをセクション3.6に示します。
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）が増加した場合、おそらく輻輳または高い遅延パスでの遅いジョイナーのために、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でこれをどのように行うかの詳細を参照してください。（ネットワークの遅延を推定することは、送信者と受信機の間の時間同期とは別のタスクであることを強調しています。）
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 一方向キーチェーンの認証されたキー。（通常、これはチェーンの最後のキーになります。つまり、K_0。このキーは送信者によって署名され、すべてのレシーバーは署名者の公開鍵で署名を検証します。）
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の開始時間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ラウンドのメッセージ交換で認証されたテスラパラメーターを取得できます。任意のレシーバー（後期ジョイナーを含む）と送信者の間の登録プロトコルの一部として、または受信機とグループコントローラー間で時間同期を実行できることを再度強調します。
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]。Teslaは、送信者の時計に対してローカル時計の遅延に関する上限を受信者に知る必要があるため、単純なアルゴリズムで十分です。Teslaは、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 受信すると、受信機は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プロトコルを使用するか、セッションセットアッププロトコルと組み合わせて。
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の間の値d^r_tを見つけます。R内のd_tの全体的な値はd_t = dに設定されます。^r_t d^0_t。
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を効果的に開示します。主要な開示遅延と呼びます。
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
異なる暗号操作で同じキーを複数回使用したくありません。つまり、キーK_Jを使用して一方向キーチェーンK_ {J-1}の前のキーを導き出し、時間間隔でMACを計算するためのキーと同じキーK_Jを使用すると、暗号化の弱点につながる可能性があります。擬似ランダム関数（PRF）、F 'を使用して、一方向関数f'：f '（k）= f'_k（1）を構築します。f 'を使用してキーを導き出し、各間隔でメッセージのMacを計算します。送信者は、次のようにMACキーを導き出します：k'_i = f '（k_i）。図1は、一方向のキーチェーン構造とMacキーの派生を示しています。インターバルでメッセージm_jをブロードキャストするには、送信者がパケットを構築します
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-1}) | F'(K_i) | F'(K_{i+1})
| | |
V V V
K'_{i-1} K'_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 'を使用して導出）が表示されます。
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を使用して、安全なパケットまたは安全なメッセージを定義します。
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. 安全なパケットテスト：レシーバーがインターバルインデックスIを運ぶパケットP_Jを受信し、キーK_ {I-D}を開示した場合、パケットが到着したローカルタイムTを最初に記録します。レシーバーは、パケットが到着したときに送信者の時計で上限T_Jを計算します：t_j = t d_t。パケットが安全かどうかをテストするために、受信者は、送信者が入る可能性がある最高の間隔xを計算します。すなわち、x = floor（（t_j -t_0） / t_int）。受信機は、x <i d（私はインターバルインデックス）であることを確認します。これは、送信者がキー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、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_Vが現在開示されているキーK_ {I-D}と同じインデックスVですでに開示されているかどうかを確認します。つまり、v> = i-dで。
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_V（v <i-d）について、K_V = f^{i-d-v}（k_ {i-d-v}）について検証することにより、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を含むバッファー付きパケットのいずれかを認証するために、受信機はMAC（k'_（k'_{i-d}、m_h）。
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に等しい場合、パケットは認証されており、バッファから解放できます。Macが同意しない場合、緩衝型パケット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}.
受信機は、新しく開示されたキー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-v> 1の場合、受信者は、間隔v 1 ... i-d-1の保存されたパケットの信頼性を確認することもできます。
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 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.
重要なテスラパラメーターは、重要な開示遅延dです。開示遅延の選択はシステムのセキュリティに影響しませんが、それは重要なパフォーマンス要因です。短い開示遅延により、パケットが安全施設を失うことになるため、受信機はそれらを認証できません。しかし、長い開示遅延は、受信機の長い認証遅延につながります。開示遅延を次のように決定することをお勧めします。直接時間同期では、RTT、2mを、送信者とホストの最悪の輻輳遅延と最悪のケースバッファリング遅延を含む送信者とレシーバーの間の往復時間の合理的な上限とします。スタック。次に、d = ceil（2m / t_int）を選択します1.商はD> = 2を確実に保証することに注意してください。時間間隔の近くで送信されるパケットを検討してください。ネットワーク伝播遅延と受信機の時間同期エラーの後、受信者はパケットを認証できません。対応するキー。
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を決定する前に各受信機の遅延を測定すると、遅延ジョイナーへの遅延時の上限が適切に予測されない場合、またはセッションの後半に輻輳遅延が上昇する場合には適切に予測されません。最悪の遅延のハードコーディングされた歴史的見積もりを使用するのは適切かもしれません（たとえば、ルーティングが安定したままであれば、惑星内インターネット上の任意のホストへの往復遅延はめったに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.
テスラのセキュリティは、ネットワーク伝播遅延に関する仮定に依存していないことを強調します。遅延が予想よりも長い場合、本物のパケットは認識されていないと見なされる可能性があります。それでも、本物として受け入れられることはありません。
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.
Tesla認証は遅れているため、受信者は、最終的には不正であることが証明されても、過剰なパケットをバッファする原因となる洪水攻撃に対して脆弱に見えます。テスラが洪水攻撃の脅威を伴う環境に展開されると、受信者は多くの追加の予防策を講じることができます。
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 合理的な誤用テスト：キー検証テスト（ステップ3）の前に、到着するパケットの開示されたキーインデックスI-Dが以前の最高の開示キーインデックスvのg内であるかどうかを確認します。したがって、たとえば、i-d-v <= g。Gは、それを超えて順序外のキーインデックスが単なる誤ったものではなく悪意があると想定されるしきい値を設定します。このテストがなければ、攻撃者はステップ3の反復テストを悪用して、レシーバーに非常に誤ったパケットのように見えるものをハッシュチェーンに沿ってCPU時間を依存させるようにすることができます。
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はG_MAX（たとえば、16）に設定する必要があります。ただし、到着するパケットが上記の合理的な誤ったテストまたはキー検証テスト（ステップ3）に失敗する場合は、GをG_MIN（> 0および通常1）にドロップする必要があります。成功する各キー検証（ステップ3）で、g_maxでない限り、gは1で増分する必要があります。これらの予防措置により、持続的な攻撃パケットは、本物のパケットに対してペースを合わせない限り、レシーバーがそれぞれ平均でG_MINハッシュを実行することができないことを保証します。後者の場合、攻撃は各本物のパケットごとにG_MAX/（G_MAX-G_MIN）ハッシュに限定されます。
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_MAXとG_MINを選択するときは、G.Max（N、M）/Nパケットのパケットシーケンスの平均ギャップを制限することに注意してください（NおよびMの定義についてはセクション3.2を参照）。したがって、g = 1、m = 100msec rtt、およびn = 4msec間パケット期間の場合、並べ替えは平均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つの代替拡張機能の概要を説明します。最初のグループ認証を追加します。2番目のグループは、時間間隔でキーを再利用しません。
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つのスキームでは、攻撃者が無制限のリソースを消費するのを防ぐために、最初の2つのスキームがわずかに（ただし境界のある）リソースを使用しているため、各スキームの適用性を理解することが重要です。グループ認証を追加するには、パケットごとのオーバーヘッドを大きくする必要があります。キーを再利用しないと、両端がパケットごとに2つのハッシュを処理する必要があります（時間間隔ではなく）。以下に説明した後に要約された各スキームのメリットは、これらの追加費用と比較検討する必要があります。
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を追加するだけです。つまり、グループ全体に共通する共有キーK_Gは、レシーバーブートストラップ中に追加のステップとして伝えられます（セクション3.3）。次に、メッセージM_J（セクション3.4）のブロードキャスト中に、送信者は各パケットMAC（K_G、P_J）のグループMACを計算し、パケットヘッダーに追加します。グループMACは、パケットP_J全体をカバーしていることに注意してください。つまり、セクション3.4の式を使用して、メッセージM_Jと追加のTesla認証資料の連結です。
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.
Teslaソース認証は、他のグループメンバーがソースのスプーフィングを控えることを控えることができない場合にのみ必要であることに注意してください。それ以外の場合、よりシンプルなグループ認証で十分です。したがって、追加のグループ認証は、他のグループメンバーがグループの洪水を控えると信頼されているが、ソースのスプーフィングを控えると信頼されていないシナリオでのみ意味があります。
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キーを複数回使用しないことを保証する場合、開示された各キーは、以前にバッファリングされたパケットを認証することに加えて追加の目的を想定する可能性があります。また、各キーは、到着する各パケットの送信者がハッシュチェーンに沿って次のキーバックを知っていたことを各レシーバーにすぐに表示します。したがって、合理的なレシーバー戦略は、すでに見られた鍵を開示した到着パケットを破棄することです。レシーバーのバッファーの充填率は、本物の送信者によって明らかにされた各パケットによってクロックされ、メモリの洪水攻撃を防ぎます。
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に与えられたものから変わらないままです。
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.)
パケットレートが遅くなった場合、キー変更間隔でパケットが送信されない場合は、キーインデックスがハッシュチェーンに沿って1回、見逃した間隔で1回インクリメントする必要があることに注意してください。（バースト中、上記の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 キーK_Iを開示しないでください。開示は、保護するパケットに続く開示遅延d * t_intよりも早く説明しません。
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 ステップ2の後、既に受信されているキーインデックス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に対して十分であり、ネットワークが侵害されずにパケットを誤解することがあるという事実ではありません。ネットワーク要素を制御しなくても、攻撃者はそのような開口部を日和見的に活用して、レシーバーをだまして偽のパケットをバッファリングし、後の本物のパケットを破棄することができます。受信者は、固定サイズのキャッシュを脇に置くことを選択し、それを管理して、本物のパケットを破棄する可能性を最小限に抑えることができます。ただし、このような脆弱性はまれで予測不可能であることを考えると、これらのイベントをネットワーク損失率への追加としてカウントすることは簡単です。いつものように、Tesla認証は、開示の遅延後も偽のパケットを明らかにします。
To summarise, avoiding re-using keys has the following properties, even under extreme flooding attacks:
要約すると、極端な洪水攻撃の下であっても、再利用キーの回避は次の特性を持っています。
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 攻撃者がネットワーク要素を制御しない場合、有効な損失率は、ネットワークの実際の損失率とその再注文率の合計によって区切られます。
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]で説明されています。
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つの顕著な拡張機能について言及しましょう。最初の拡張により、単一のストリームに複数のTesla認証チェーンを持つことができます。各チェーンでは、キーを開示するために異なる遅延を使用します。この拡張機能は、通常、単一のマルチキャスト伝送内の不均一なネットワーク遅延を扱うために使用されます。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.
認証のために後のパケットでキーを受信するというテスラの要件により、受信者がメッセージの最後の部分を認証することができません。したがって、メッセージの最後の部分または送信停止前の最後のメッセージの認証を有効にするために、送信者はキーで空のメッセージを送信する必要があります。
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:
Tesla認証は、ネットワークスタック内の任意のレイヤーで実行できます。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 of service attacks. (Indeed, reliable multicast tools based on forward error correction are highly susceptible to denial of service due to bogus packets.)
o ネットワークレイヤーでテスラを実行するには、トランスポートまたはアプリケーションレイヤーが認証されたデータのみを受信し、信頼性プロトコルを支援し、サービス拒否攻撃を緩和する可能性があるという利点があります。（実際、前方エラーの修正に基づく信頼性の高いマルチキャストツールは、偽のパケットによるサービスの拒否に非常に敏感です。）
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 テスラはパケットのタイミングに依存しているため、テスラをプロトコルまたはレイヤーの上に展開するため、パケットを積極的にバッファリングし、真のパケット到着時間を隠すと、テスラのパフォーマンスが大幅に減少することに注意してください。
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トンネルエンドポイント）とは別に配置されている場合、検証とアプリケーションの間に信頼できるチャネルが存在する必要があります。たとえば、検証器とアプリケーションの間のインターフェイスは、アプリケーションによって受信されたパケットが検証剤によって検証されている必要があると単純に仮定する場合があります（そうでなければ削除されたため）。アプリケーションは、検証剤をバイパスすることができたパケットの受信に対して脆弱です。
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.
マイク・ルビー、マーク・ボーガー、マット・ナスルンド、デイブ・マクグルー、ロス・フィンレイソン、シルビー・ラニープセ、ラクシュミナス・ドンデティ、ラス・ハウズリー、IESGレビュアーのフィードバックとサポートについて、以下に感謝します。
[1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[1] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[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] D. Boneh、G。Durfee、およびM. Franklin、「マルチキャストメッセージ認証の下限」、暗号学の進歩 - EuroCrypt 2001（B。Pfitzmann、ed。）、vol。2045年のコンピューターサイエンスの講義ノート、（オーストリア、インスブルック）、p。434-450、Springer-Verlag、ベルリンドイツ、2001年。
[4] R. Gennaro and P. Rohatgi, "How to Sign Digital Streams", tech. rep., IBM T.J.Watson Research Center, 1997.
[4] R. GennaroおよびP. Rohatgi、「Digital Streamsの署名方法」、Tech。Rep。、IBM T.J. Watson Research Center、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、「マルチキャストパケット認証のためのコンパクトで高速ハイブリッド署名スキーム」、1999年11月、コンピューターおよび通信セキュリティに関する第6回ACM会議。
[6] C. K. Wong and S. S. Lam, "Digital signatures for flows and multicasts," in Proc. IEEE ICNP `98, 1998.
[6] C. K. WongおよびS. S. Lam、Proc。IEEE ICNP `98、1998。
[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。Canetti、J。Tygar、およびD. X. Song、「Rosyチャンネルに対するマルチキャストストリームの効率的な認証と署名」、IEEE Symposium on Security and 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. Canetti、J。Garay、G。Itkis、D。Micciancio、M。Naor、およびB. Pinkas、「マルチキャストセキュリティ：分類法といくつかの効率的な構造」、Infocom '99、1999。
[9] S. Cheung, "An efficient message authentication scheme for link state routing", 13th Annual Computer Security Applications Conference, 1997.
[9] S. Cheung、「リンク状態ルーティングの効率的なメッセージ認証スキーム」、第13回年次コンピューターセキュリティアプリケーション会議、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] F. Bergadano、D。Cavagnino、およびB. Crispo、「Chained Stream認証」、Cryptography 2000の選択領域（カナダ、Waterloo）、2000年8月。このスキームを説明する講演は、1998年8月にIBM Watsonで行われました。
[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の個々の単一ソース認証」、ICME 2000、2000年8月。この作品を含む講演は、1998年8月、IBM Watsonで行われました。
[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、WiredおよびWireless Networks Kluwer Academic Publishersでの安全な放送通信、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。Canetti、J。D。Tygar、およびD. Song、「The Tesla Broadcast Authentication Protocol」、RSA Cryptobytes、Volume 5、No。2 Summer/Fall 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。Canetti、D。Song、およびJ. D. Tygar、「マルチキャスト向けの効率的かつ安全なソース認証」、ネットワークおよび分散システムセキュリティシンポジウム、NDSS '01、p。35-46、2001年2月。
[15] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[15] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、RFC 1305、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. Simons、J。Lundelius-Welch、およびN. Lynch、「時計同期の概要」、フォールトトレラント分散コンピューティング（B. Simons and A. Spector、編）、No。448in LNCS、p。84-96、Springer-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.ミルズ、「コンピューターネットワーククロックを同期するための改善されたアルゴリズム」、通信アーキテクチャ、プロトコル、アプリケーションに関する会議の議事録、Sigcomm 94、（ロンドン、イギリス）、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. LamportおよびP. Melliar-Smith、「断層の存在下での時計の同期」、J。Acm、第32巻、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. Lowe、「モデルチェックを使用したストリーム認証プロトコルの分析」、コンピューターセキュリティに関する研究に関する第7回欧州シンポジウム（ESORICS）の議事録、2002年。
[20] M. Jakobsson, "Fractal hash sequence representation and traversal", Cryptology ePrint Archive, http://eprint.iacr.org/2002/001/, January 2002.
[20] M. Jakobsson、「Fractal Hashシーケンス表現とトラバーサル」、Cryptology Eprint Archive、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. CoppersmithとM. Jakobsson、「ほぼ最適なハッシュシーケンストラバーサル」、第6回国際金融暗号会議（FC '02）の議事録、2002年3月。
[22] Haller, N., "The S/KEY One-Time Password System", RFC 1760, February 1995.
[22] ハラー、N。、「S/キーのワンタイムパスワードシステム」、RFC 1760、1995年2月。
Authors' Addresses
著者のアドレス
Adrian Perrig ECE Department Carnegie Mellon University Pittsburgh, PA 15218 US
エイドリアンペリグECE部門カーネギーメロン大学ピッツバーグ、ペンシルバニア州15218米国
EMail: perrig@cmu.edu
Ran Canetti IBM Research 30 Saw Mill River Rd Hawthorne, NY 10532 US
RAN CANETTI IBM Research 30 Saw Mill River Rd Hawthorne、NY 10532 US
EMail: canetti@watson.ibm.com
Dawn Song ECE Department Carnegie Mellon University Pittsburgh, PA 15218 US
ドーンソングECE部門カーネギーメロン大学ピッツバーグ、ペンシルバニア州15218米国
EMail: dawnsong@cmu.edu
J. D. Tygar UC Berkeley - EECS & SIMS 102 South Hall 4600 Berkeley, CA 94720-4600 US
J. D.タイガーUCバークレー - EECS＆SIMS 102 SOUTH HALL 4600 BERKELEY、CA 94720-4600 US
EMail: doug.tygar@gmail.com
Bob Briscoe BT Research B54/77, BT Labs Martlesham Heath Ipswich, IP5 3RE UK
Bob Briscoe BT Research B54/77、BT LABS MARTLESHAM HEATH IPSWICH、IP5 3RE UK
EMail: bob.briscoe@bt.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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エディター機能の資金は現在、インターネット協会によって提供されています。