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
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).
版权所有（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.
本文档介绍了定时高效流丢失容忍认证（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
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
对称MAC身份验证在广播设置中不安全。考虑发送者将真实数据广播给相互不信任的接收者。对称MAC是不安全的：每个接收者都知道MAC密钥，因此可以模拟发送者并向其他接收者伪造消息。直观地说，我们需要一种非对称机制来实现认证广播，例如
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.
实现这种不对称身份验证的标准方法是使用不对称加密技术；e、 例如，数字签名。数字签名具有所需的不对称属性：发送方使用其私钥生成签名，所有接收方都可以使用发送方的公钥验证签名，但仅使用公钥的接收方无法为新消息生成数字签名。数字签名提供了不可否认性，这是一种比身份验证更强大的特性。然而，数字签名有很高的成本：它们对发送方和接收方都有很高的计算开销，而且大多数签名也有很高的带宽开销。由于我们假设发送方不重新传输丢失的数据包的广播设置，并且接收方仍然希望立即对接收到的每个数据包进行身份验证，因此我们需要在每个消息上附加一个数字签名。由于非对称加密的高开销，这种方法将限制我们使用低速率流，以及使用强大工作站的发送方和接收方。我们可以尝试将一个数字签名分摊到多个消息上。然而，与对称加密相比，这种方法仍然昂贵，因为对称加密通常比非对称加密效率高3到5个数量级。此外，一个数字签名在多个数据包上的直接摊销需要可靠性，因为接收方需要接收所有数据包来验证签名。采用这种方法的方案有[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）。特斯拉主要使用对称加密技术，并使用延时密钥公开来实现所需的不对称性。然而，特斯拉要求发送方和接收方之间的时钟松散同步。详见第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).
为了表示变量的下标或索引，我们在变量名和索引之间使用下划线；e、 例如，索引为i的键K是K_i，索引为i+d的键K是K_{i+d}。要写上标，我们使用插入符号；e、 例如，参数x执行i次的函数F是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).
特斯拉提供延迟每包数据认证和完整性检查。提供效率和安全性的关键思想是延迟密钥公开。延迟的密钥公开导致身份验证延迟。实际上，延迟大约为一个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毫秒的数据包未经身份验证，应予以忽略。然而，在本文档的其余部分中，为了简洁起见，我们将假定数据包不会与缓冲并行处理。
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 对手的计算资源可能非常庞大，但并非无穷无尽。特别是，这意味着对手可以执行有效的计算，例如以可忽略不计的延迟计算合理数量的伪随机函数应用程序和MAC。尽管如此，对手无法以不可忽略的概率找到伪随机函数（或将其与随机函数区分开来）的密钥。
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节）。
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的上界。（这样的交换可以搭载在任何安全会话启动协议上。或者，可以使用标准协议，如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. 特斯拉必须在会话设置时通过常规数据认证系统进行引导。一种选择是为此目的使用数字签名算法，在这种情况下，接收方需要具有发送方公钥证书或根密钥证书的真实副本
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.
我们想强调的是，特斯拉的安全性不依赖于任何关于网络传播延迟的假设。
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]，以及两篇会议论文[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
o 每个接收器接收数据包。每个接收者都知道公开密钥的时间表，并且由于它在发送者的本地时间上有一个上限，所以它可以检查用于计算MAC的密钥是否还没有被发送者公开。如果不是，则接收器缓冲数据包。否则，由于无法进行身份验证，数据包将被丢弃。请注意，我们不确定“迟来的数据包”是假的还是假的
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.
现在，我们按照以下顺序描述基本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的统一间隔。发送方将单向链中的一个键按顺序分配给每个时间间隔。
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: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).
Jakobson[20]和Coppersmith and Jakobson[21]提出了一种单向链的高效存储和计算机制。对于长度为N的链，存储是关于log（N）个元素的，重构每个元素的计算开销也是关于log（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的正确选择仍然是错误的
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毫秒发送一个数据包，那么T_int的合理值是max（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）在会话期间增加，可能是由于拥塞或高延迟路径上的延迟加入，则不需要修改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的开始时间。-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.
接收机可以执行时间同步，并在两轮消息交换中获得经过身份验证的TESLA参数，如下所述。我们再次强调，时间同步可以作为注册协议的一部分在任何接收者（包括延迟加入者）和发送者之间执行，或者在任何接收者和组控制器之间执行。
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]。特斯拉只要求接收方知道其本地时钟相对于发送方时钟的延迟上限，因此一个简单的算法就足够了。特斯拉可以使用直接、间接和延迟同步作为三个默认选项。具体的同步方法将成为特斯拉每次实例化的一部分。
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 接收方向发送方发送（sync 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 在收到（sync t_r）消息后，发送方记录其本地时间t_s，并向接收方发送（sync，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 在接收（synch，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协议或结合会话设置协议。
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\u t=D^R\u 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。我们称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}的先前密钥，并且使用与密钥相同的密钥K_j在时间间隔j内计算mac可能导致密码弱点。利用伪随机函数f'，我们构造了单向函数f'：f'（k）=f''uk（1）。我们使用F'来推导密钥，以计算每个间隔中消息的MAC。发送方按如下方式导出MAC密钥：K''u i=F'（K'u 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-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. 安全数据包测试：当接收器接收到数据包P_j（它携带一个间隔索引i）和一个公开的密钥K_{i-d}时，它首先记录数据包到达的本地时间T。然后，接收方在数据包到达时计算发送方时钟上的上界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''u i，M_j））添加到缓冲区，并在学习K''u 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公开；也就是说，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}）来检查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的任何早期安全缓冲数据包的真实性。为了验证包含消息M_h的缓冲包P_h中的一个，该消息M_h由使用密钥索引i-d的MAC保护，接收器将计算K''{i-d}=F'（K'{i-d}），它可以从中计算MAC（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
特斯拉的一个重要参数是关键披露延迟d。虽然披露延迟的选择不会影响系统的安全性，但它是一个重要的性能因素。短的公开延迟将导致数据包丢失其安全属性，因此接收方将无法对其进行身份验证；但是长的公开延迟会导致接收器的长认证延迟。我们建议如下确定披露延迟：在直接时间同步中，让RTT 2m为发送方和任何接收方之间往返时间的合理上限，包括主机堆栈中最坏情况下的拥塞延迟和最坏情况下的缓冲延迟。然后选择d=ceil（2m/T_int）+1。请注意，将商四舍五入可确保d>=2。还要注意，一个时间间隔（d=1）的披露延迟不起作用。考虑发送到接近时间间隔边界的分组：在网络传播延迟和接收机时间同步误差之后，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.
接收方将无法对数据包进行身份验证，因为发送方将在下一个时间间隔内公开相应的密钥。
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之前测量每个接收器的延迟仍然不能充分预测延迟加入者的延迟上限，或者在会话后期拥塞延迟上升的地方。使用硬编码的最坏情况延迟历史估计值可能足够了（例如，如果路由保持稳定，行星内互联网上任何主机的往返延迟很少超过500毫秒）。
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.
由于特斯拉认证被延迟，接收者似乎容易受到洪水攻击，导致他们缓冲多余的数据包，即使最终证明这些数据包是不真实的。当特斯拉部署在具有洪水攻击威胁的环境中时，接收器可以采取一些额外的预防措施。
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_max（比如16）。但是，每当到达的数据包未能通过上述合理的误序测试或密钥验证测试（步骤3）时，g应降至g_min（>0，通常为1）。在每次成功的密钥验证（步骤3）时，g应增加1，除非它已经是g_max。这些预防措施将确保持续的攻击数据包不会导致接收器每次执行的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=100毫秒RTT，n=4毫秒数据包间隔时，重新排序将被限制在平均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保护要求发送方和接收方在协议上安排额外的约束。下面，我们概述了基本特斯拉的三种替代扩展；第一个是添加组身份验证，第二个是在一段时间间隔内不重复使用密钥，第三个是向发送方移动缓冲。
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.
了解每个方案的适用性很重要，因为前两个方案使用的资源稍多（但有界），以防止攻击者消耗无界资源。添加组身份验证需要更大的每包开销。决不重复使用密钥需要两端对每个数据包（而不是每个时间间隔）处理两个哈希，发送方必须存储或重新生成更长的哈希链。每项计划的优点（在下文描述后进行总结）必须与这些额外成本进行权衡。
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和附加特斯拉认证材料连接起来。
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.
请注意，特斯拉来源认证仅在无法信任其他集团成员避免欺骗来源时才有必要；否则，更简单的组身份验证就足够了。因此，额外的组身份验证只有在其他组成员被信任以避免淹没组，但他们仍然不被信任以避免欺骗源的情况下才有意义。
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.
对于发送方来说，该方案与特斯拉几乎没有什么不同。它只使用足够短的间隔持续时间，以确保每个数据包沿着哈希链返回一个新密钥。因此，第3.2节中给出的有效重设密钥间隔T_int的经验法则不再适用。相反，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应被视为任何两个数据包之间的最小间隔时间。（事实上，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，则此类突发将不会持续足够长的时间以导致关联d密钥在少于披露延迟的时间内披露。）
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 在步骤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.
如果不是因为网络有时会错误地对数据包进行排序而不被破坏，这种简单的方案就足以对付拒绝服务。即使在不控制网络元素的情况下，攻击者也可以机会主义地利用这些漏洞欺骗接收者缓冲虚假数据包并丢弃后来的真实数据包。接收方可以选择留出一个固定大小的缓存，并对其进行管理，以最大限度地减少丢弃真实数据包的机会。但是，由于此类漏洞非常罕见且不可预测，因此将这些事件计算为网络丢失率的增加更为简单。一如往常，特斯拉认证仍将在披露延迟后发现任何虚假数据包。
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].
让我们提到特斯拉基本方案的两个显著扩展。第一扩展允许针对单个流具有多个特斯拉认证链，其中每个链使用不同的延迟来公开密钥。此扩展通常用于处理单个多播传输中的异构网络延迟。第二个扩展允许在发送方（而不是接收方）对数据包进行大部分缓冲。[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:
特斯拉认证可以在网络堆栈的任何层上执行。三个自然位置是网络层、传输层或应用层。我们列出了有关选择图层的一些注意事项：
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 在网络层执行TESLA的优点是，传输层或应用层只接收经过身份验证的数据，这可能有助于可靠性协议和减少拒绝
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 在传输层或应用层中执行TESLA的优点是网络层保持不变，但其潜在缺点是应用层仅在传输层处理之后才获得分组。因此，如果在传输中使用缓冲，那么这可能会在不可避免的网络延迟之上引入额外的和不可预测的延迟。
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.Pfizmann，ed.），计算机科学课堂讲稿第2045卷，（奥地利因斯布鲁克），p。434-450，施普林格·维拉格，德国柏林，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，“如何签署数字流”，技术代表，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，“用于多播分组认证的紧凑快速混合签名方案”，第六届ACM计算机与通信安全会议，1999年11月。
[6] C. K. Wong and S. S. Lam, "Digital signatures for flows and multicasts," in Proc. IEEE ICNP `98, 1998.
[6] 黄志光和林世森，“流和多播的数字签名”，摘自Proc。IEEE ICNP'981998。
[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，“有损信道上多播流的有效认证和签名”，IEEE安全和隐私研讨会，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'991999。
[9] S. Cheung, "An efficient message authentication scheme for link state routing", 13th Annual Computer Security Applications Conference, 1997.
[9] 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，“链式流认证”，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，《有线和无线网络中的安全广播通信》，Kluwer学术出版社，2002年10月。ISBN 0792376501。
[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，“特斯拉广播认证协议”，RSA CryptoBytes，第5卷，第2期，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，第页。2001年2月35日至46日。
[15] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[15] Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC13051992年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和A.Spector，编辑），LNCS第448号，p。84-96，德国柏林斯普林格·维拉格，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.Mills，“计算机网络时钟同步的改进算法”，通信体系结构、协议和应用会议记录，SIGCOMM 94，（英国伦敦），第页。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卷，第1页。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，“使用模型检查分析流认证协议”，第七届欧洲计算机安全研究研讨会论文集，2002年。
[20] M. Jakobsson, "Fractal hash sequence representation and traversal", Cryptology ePrint Archive, http://eprint.iacr.org/2002/001/, January 2002.
[20] M.Jakobson，“分形散列序列表示和遍历”，密码学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.Coppersmith和M.Jakobson，“几乎最优散列序列遍历”，第六届国际金融加密会议论文集（FC'02），2002年3月。
[22] Haller, N., "The S/KEY One-Time Password System", RFC 1760, February 1995.
[22] Haller，N.，“S/KEY一次性密码系统”，RFC1760，1995年2月。
Authors' Addresses
作者地址
Adrian Perrig ECE Department Carnegie Mellon University Pittsburgh, PA 15218 US
美国宾夕法尼亚州匹兹堡卡内基梅隆大学欧洲经委会系阿德里安·佩里格15218
EMail: perrig@cmu.edu
EMail: perrig@cmu.edu
Ran Canetti IBM Research 30 Saw Mill River Rd Hawthorne, NY 10532 US
Ran Canetti IBM Research美国纽约州霍桑市锯木勒河路30号，邮编10532
EMail: canetti@watson.ibm.com
EMail: canetti@watson.ibm.com
Dawn Song ECE Department Carnegie Mellon University Pittsburgh, PA 15218 US
美国宾夕法尼亚州匹兹堡卡内基梅隆大学欧洲经委会系Dawn Song 15218
EMail: dawnsong@cmu.edu
EMail: dawnsong@cmu.edu
J. D. Tygar UC Berkeley - EECS & SIMS 102 South Hall 4600 Berkeley, CA 94720-4600 US
J.D.泰格加州大学伯克利分校-EECS&SIMS 102南大厅4600伯克利，加利福尼亚州94720-4600美国
EMail: doug.tygar@gmail.com
EMail: doug.tygar@gmail.com
Bob Briscoe BT Research B54/77, BT Labs Martlesham Heath Ipswich, IP5 3RE UK
Bob Briscoe英国电信研究B54/77，英国电信实验室Martlesham Heath Ipswich，IP5 3RE英国
EMail: bob.briscoe@bt.com
EMail: bob.briscoe@bt.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（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.
本文件受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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。