The TESLA Broadcast Authentication Protocol∗

Adrian Perrig Ran Canetti J. D. Tygar Dawn Song

Abstract

One of the main challenges of securing broad-cast communication is source authentication, orenabling receivers of broadcast data to verifythat the received data really originates from theclaimed source and was not modified en route.This problem is complicated by mutually un-trusted receivers and unreliable communicationenvironments where the sender does not retrans-mit lost packets.

This article presents the TESLA (TimedEfficient Stream Loss-tolerant Authentication)broadcast authentication protocol, an efficientprotocol with low communication and computa-tion overhead, which scales to large numbers ofreceivers, and tolerates packet loss. TESLA isbased on loose time synchronization between thesender and the receivers.

Despite using purely symmetric cryptographicfunctions (MAC functions), TESLA achievesasymmetric properties. We discuss a PKI appli-cation based purely on TESLA, assuming that allnetwork nodes are loosely time synchronized.

∗Most of this work was done at UC Berkeley and IBMResearch. The authors can be reached atadrian+@cs.cmu.edu, canetti@watson.ibm.com,tygar@cs.berkeley.edu, skyxd@cs.cmu.edu.

1 Introduction

Broadcast communication is gaining popularityfor efficient and large-scale data dissemination.Examples of broadcast distribution networks aresatellite broadcasts, wireless radio broadcast, orIP multicast. While many broadcast networks canefficiently distribute data to multiple receivers,they often also allow a malicious user to imper-sonate the sender and inject broadcast packets —we call this a packet injection attack. (Source-Specific Multicast (SSM, EXPRESS) is a no-table exception, and attempts to prevent this at-tack [17, 40].)

Because malicious packet injection is easy inmany broadcast networks, the receivers want toensure that the broadcast packets they receive re-ally originate from the claimed source. A broad-cast authentication protocol enables the receiversto verify that a received packet was really sent bythe claimed sender.

Simply deploying the standard point-to-pointauthentication mechanism (i.e., appending a mes-sage authentication code (MAC) to each packet,computed using a shared secret key) does not pro-vide secure broadcast authentication. The prob-lem is that any receiver with the secret key canforge data and impersonate the sender. Conse-quently, it is natural to look for solutions basedon asymmetric cryptography to prevent this at-tack; a digital signature scheme is an example ofan asymmetric cryptographic protocol. Indeed,signing each data packet provides secure broad-

2

In CryptoBytes, 5:2, Summer/Fall 2002, pp. 2-13

cast authentication; however, it has high over-head, both in terms of the time required to signand verify, and in terms of the bandwidth. Severalschemes were proposed that mitigate this over-head by amortizing a single signature over sev-eral packets, e.g., [14, 25, 28, 33, 38, 39]. How-ever, none of these schemes is fully satisfactoryin terms of bandwidth overhead, processing time,scalability, robustness to denial-of-service attacks,and robustness to packet loss. Even though someschemes amortize a digital signature over multipledata packets, a serious denial-of-service attack isusually possible where an attacker floods the re-ceiver with bogus packets supposedly containinga signature. Since signature verification is oftencomputationally expensive, the receiver is over-whelmed verifying bogus signatures.

Researchers proposed information-theoreticallysecure broadcast authentication mechanisms [10,11, 12, 13, 20, 34, 35, 36]. These protocols have ahigh overhead in large groups with many receivers.

Canetti et al. construct a broadcast authentica-tion protocol based on k different keys to authen-ticate every message with k different MAC’s [7].Every receiver knows m keys and can hence ver-ify m MAC’s. The keys are distributed in sucha way that no coalition of w receivers can forge apacket for a specific receiver. The security of theirscheme depends on the assumption that at mosta bounded number (which is on the order of k) ofreceivers collude.

Boneh, Durfee, and Franklin show that one can-not build a compact collusion resistant broad-cast authentication protocol without relying ondigital signatures or on time synchronization [4].They show that any secure broadcast authenti-cation protocol with per-packet overhead slightlyless than the number of receivers can be convertedinto a signature scheme.

Another approach to providing broadcast au-thentication uses only symmetric cryptography,more specifically on message authentication codes(MACs), and is based on delayed disclosure ofkeys by the sender. This technique was indepen-dently discovered by Cheung [8] in the context ofauthenticating link state routing updates. A re-lated approach was used in the Guy Fawkes proto-col for interactive unicast communication [1]. Inthe context of multicast streamed data it was pro-posed by several authors [2, 3, 5, 27, 28].

The main idea of TESLA is that the sender at-taches to each packet a MAC computed with a keyk known only to itself. The receiver buffers thereceived packet without being able to authenti-cate it. A short while later, the sender discloses kand the receiver is able to authenticate the packet.Consequently, a single MAC per packet suffices toprovide broadcast authentication, provided thatthe receiver has synchronized its clock with thesender ahead of time.

This article is an overview of the TESLA broad-cast authentication protocol. A more detailed de-scription is in a forthcoming book [30] and in ourearlier publications [27, 28]. A standardization ef-fort for TESLA is under way in the Multicast Se-curity (MSEC) working group of the IETF [26].TESLA is used in a wide variety of applications,ranging from broadcast authentication in sensornetworks [29], to authentication of messages inad hoc network routing protocols [18].

2 Background and Assumptions

TESLA requires that the receivers are loosely timesynchronized with the sender. In this section,we review a simple protocol to achieve this timesynchronization. TESLA also needs an efficientmechanism to authenticate keys at the receiver —we first review one-way chains for this purpose.

3

2.1 One-Way Chains

Many protocols need to commit to a sequence ofrandom values. For this purpose, we repeatedlyuse a one-way hash function to generate a one-waychain. One-way chains are a widely-used crypto-graphic primitive. One of the first uses of one-way chains was for one-time passwords by Lam-port [21]. Haller later used the same approach forthe S/KEY one-time password system [16]. One-way chains are also used in many other applica-tions.

Figure 1 shows the one-way chain construction.To generate a chain of length � we randomly pickthe last element of the chain s�. We generate thechain by repeatedly applying a one-way functionF . Finally, s0 is a commitment to the entire one-way chain, and we can verify any element of thechain through s0, e.g. to verify that element si

is indeed the element with index i of the hashchain, we check that F i(si) = s0. More gener-ally, si commits to sj if i < j (to verify that sj ispart of the chain if we know that si is the ith el-ement of the chain, we check that F j−i(sj) = si).We reveal the elements of the chain in this or-der s0, s1, . . . , s�−1, s�. How can we store thischain? We can either create it all at once and storeeach element of the chain, or we can just store s�

and compute any other element on demand. Inpractice, a hybrid approach helps to reduce stor-age with a small recomputation penalty. Jakobs-son [19], and Coppersmith and Jakobsson [9] pro-pose a storage efficient mechanism for one-waychains: a one-way chain with N elements onlyrequires log(N) storage and log(N) computationto access an element.

In TESLA, the elements of the one-way chainare keys, so we call the chain a one-way key chain.Furthermore, any key of the one-way key chaincommits to all following keys, so we call such akey a one-way key chain commitment, or simplykey chain commitment.

s�s�−1s�−2s1s0

F (s�)F (s�−1)F (s2)F (s1). . .

Generate

Use / Reveal

Figure 1: One-way chain example. The sendergenerates this chain by randomly selecting s� andrepeatedly applying the one-way function F . Thesender then reveals the values in the opposite or-der.

2.2 Time Synchronization

TESLA does not need the strong time synchro-nization properties that sophisticated time syn-chronization protocols provide [22, 24, 37], butonly requires loose time synchronization, and thatthe receiver knows an upper bound on the sender’slocal time. We now outline a simple and securetime synchronization protocol that achieves thisrequirement. For simplicity, we assume the clockdrift of both sender and receiver is negligible (oth-erwise the receiver can periodically resynchronizethe time with the sender). We denote the realdifference between the sender and the receiver’stime with δ. In loose time synchronization, thereceiver does not need to know the exact δ butonly an upper bound on it, ∆, which we also referto as the maximum time synchronization error.

We now describe a simple protocol for timesynchronization, where each receiver performs ex-plicit time synchronization with the sender. Thisapproach does not require any extra infrastruc-ture to perform time synchronization. We presenta simple two-round time synchronization protocolthat satisfies the requirement for TESLA, whichis that the receiver knows an upper bound on thesender’s clock. Reiter previously describes thisprotocol [31, 32].

4

t1

t2

t3 tS

tR

∆

δ

Receiver time Sender time

Figure 2: Direct time synchronization betweenthe sender and the receiver. The receiver is-sues a time synchronization request at time tR,at which time the sender’s clock is at time t1.The sender responds to the request at its localtime tS . In TESLA, the receiver is only interestedin an upper bound on the sender’s time. Whenthe receiver has its current time tr, it computesthe upper bound on the current sender’s time asts ≤ tr − tR + tS . The real synchronization er-ror after this protocol is δ. The receiver, however,does not know the propagation delay of the timesynchronization request packet, so it must assumethat the time synchronization error is ∆ (or thefull round-trip time (RTT)).

Figure 2 shows a sample time synchronizationbetween the receiver and the sender. In the pro-tocol, the receiver first records its local time tRand sends a time synchronization request contain-ing a nonce to the sender.1 Upon receiving thetime synchronization request, the sender recordsits local time tS and replies with a signed responsepacket containing tS and the nonce.2

1The security of this time synchronization protocol re-

lies on the unpredictability of the nonce — if an attackercould predict the receiver’s nonce, it could send a timesynchronization request to the sender with that nonce, andreplay the response later to the receiver.

2Interestingly, the processing and propagation delay ofthe response message does not change δ (assuming that

1. Setup. The sender S has a digital signaturekey pair, with the private key K−1

S and thepublic key KS . We assume a mechanism thatallows a receiver R to learn the authenticatedpublic key KS . The receiver chooses a ran-dom and unpredictable nonce.

2. Protocol steps. Before sending the first mes-sage, the receiver records its local time tR.

R → S : Nonce

S → R : {Sender time tS,Nonce}K−1S

To verify the return message, the receiver ver-ifies the digital signature and checks that thenonce in the packet equals the nonce it ran-domly generated. If the message is authentic,the receiver stores tR and tS . To compute theupper bound on the sender’s clock at localtime t, the receiver computes t − tR + tS .

Upon receiving the signed response, the receiverchecks the validity of the signature and verifiesthat the nonce in the response packet equals thenonce in the request packet. If all verificationsare successful, the receiver uses tR and tS to com-pute the upper bound of the sender’s time: whenthe receiver has the current time tr, it computesthe upper bound on the current sender’s time asts ≤ tr − tR + tS . The real synchronization errorafter this protocol is δ, as Figure 2 shows. Thereceiver, however, does not know the propagationdelay of the time synchronization request packet,so it must assume that the time synchronizationerror is ∆ (or the full round-trip time (RTT)).

the sender immediately records and replies with the arrivaltime of the request packet), since the receiver is only in-terested in an upper bound on the sender’s clock. If thereceiver were interested in the lower bound on the sender’sclock, the processing delay and delay of the response mes-sage would matter. For more details on this refer to themore detailed time synchronization description [30].

5

A digital signature operation is computation-ally expensive, and we need to be careful aboutdenial-of-service attacks in which an attackerfloods the sender with time synchronization re-quests. Another problem is request implosion: thesender is overwhelmed with time synchronizationrequests from receivers. We address these issuesin our earlier paper [27].

3 The TESLA Broadcast Authentica-tion Protocol

A viable broadcast authentication protocol hasthe following requirements:

• Low computation overhead for generationand verification of authentication informa-tion.

• Low communication overhead.

• Limited buffering required for the sender andthe receiver, hence timely authentication foreach individual packet.

• Robustness to packet loss.

• Scales to a large number of receivers.

The TESLA protocol meets all these require-ments with low cost — and it has the followingspecial requirements:

• The sender and the receivers must be at leastloosely time-synchronized as outlined in Sec-tion .

• Either the receiver or the sender must buffersome messages.

Despite the buffering, TESLA has a low authen-tication delay. In typical configurations, the au-thentication delay is on the order of one round-trip delay between the sender and receiver.

3.1 Sketch of TESLA protocol

We first outline the main ideas behind TESLA.Broadcast authentication requires a source ofasymmetry, such that the receivers can only ver-ify the authentication information, but not gener-ate valid authentication information. TESLA usestime for asymmetry. We assume that receivers areall loosely time synchronized with the sender —up to some time synchronization error ∆, all par-ties agree on the current time. Here is a sketch ofthe basic approach:

• The sender splits up the time into time in-tervals of uniform duration. Next, the senderforms a one-way chain of self-authenticatingvalues, and assigns the values sequentially tothe time intervals (one key per time inter-val). The one-way chain is used in the re-verse order of generation, so any value of atime interval can be used to derive values ofprevious time intervals. The sender defines adisclosure time for one-way chain values, usu-ally on the order of a few time intervals. Thesender publishes the value after the disclosuretime.

• The sender attaches a MAC to each packet.The MAC is computed over the contents ofthe packet. For each packet, the sender de-termines the time interval and uses the cor-responding value from the one-way chain asa cryptographic key to compute the MAC.Along with the packet, the sender also sendsthe most recent one-way chain value that itcan disclose.

6

• Each receiver that receives the packet per-forms the following operation. It knows theschedule for disclosing keys and, since theclocks are loosely synchronized, can checkthat the key used to compute the MAC is stillsecret by determining that the sender couldnot have yet reached the time interval for dis-closing it. If the MAC key is still secret, thenthe receiver buffers the packet.

• Each receiver also checks that the disclosedkey is correct (using self-authentication andpreviously released keys) and then checks thecorrectness of the MAC of buffered packetsthat were sent in the time interval of the dis-closed key. If the MAC is correct, the receiveraccepts the packet.

One-way chains have the property that if inter-mediate values of the one-way chain are lost, theycan be recomputed using later values. So, evenif some disclosed keys are lost, a receiver can re-cover the key chain and check the correctness ofpackets.

The sender distributes a stream of messages{Mi}, and the sender sends each message Mi ina network packet Pi along with authentication in-formation. The broadcast channel may be lossy,but the sender does not retransmit lost packets.Despite packet loss, each receiver needs to authen-ticate all the messages it receives.

We now describe the stages of the basic TESLAprotocol in this order: sender setup, receiverbootstrap, sender transmission of authenticatedbroadcast messages, and receiver authenticationof broadcast messages.

3.2 Sender Setup

TESLA uses self-authenticating one-way chains.The sender divides the time into uniform intervalsof duration Tint. Time interval 0 will start at timeT0, time interval 1 at time T1 = T0+Tint, etc. Thesender assigns one key from the one-way chainto each time interval in sequence. The one-waychain is used in the reverse order of generation, soany value of a time interval can be used to derivevalues of previous time intervals.

The sender determines the length N of theone-way chain K0,K1, . . . ,KN , and this lengthlimits the maximum transmission duration be-fore a new one-way chain must be created.3 Thesender picks a random value for KN . Using apseudo-random function f , the sender constructsthe one-way function F : F (k) = fk(0). Theremainder of the chain is computed recursivelyusing Ki = F (Ki+1). Note that this gives usKi = FN−i(KN ), so we can compute any valuein the key chain from KN even if we do not haveintermediate values. Each key Ki will be activein time interval i.

3.3 Bootstrapping Receivers

Before a receiver can authenticate messages withTESLA, it needs to be loosely time synchronizedwith the sender, know the disclosure schedule ofkeys, and receive an authenticated key of the one-way key chain.

Various approaches exist for time synchroniza-tion [24, 37, 22]. TESLA, however, only requiresloose time synchronization between the sender

3For details on how to handle broadcast streams ofunbounded duration by switching one-way key chains,see [27]. For this article we assume that chains are suf-ficiently long for the duration of communication.

7

and the receivers, so a simple algorithm is suf-ficient. The time synchronization property thatTESLA requires is that each receiver can placean upper bound of the sender’s local time, as wediscuss in Section .

The sender sends the key disclosure schedule bytransmitting the following information to the re-ceivers over an authenticated channel (either viaa digitally signed broadcast message, or over uni-cast with each receiver):

• Time interval schedule: interval durationTint, start time Ti and index of interval i,length of one-way key chain.

• Key disclosure delay d (number of intervals).

• A key commitment to the key chain Ki (i <j − d where j is the current interval index).

3.4 Broadcasting Authenticated Messages

Each key in the one-way key chain corresponds toa time interval. Every time a sender broadcasts amessage, it appends a MAC to the message, usingthe key corresponding to the current time interval.The key remains secret for the next d−1 intervals,so messages sent in interval j effectively disclosekey Kj−d. We call d the key disclosure delay.

As a general rule, using the same key multi-ple times in different cryptographic operations isill-advised — it may lead to cryptographic weak-nesses. So we do not want to use key Kj bothto derive key Kj−1 and to compute MACs. Us-ing a pseudo-random function family f ′, we con-struct the one-way function F ′: F ′(k) = f ′

k(1).We use F ′ to derive the key to compute theMAC of messages: K ′

i = F ′(Ki). Figure 3

depicts the one-way key chain construction andMAC key derivation. To broadcast message Mj

in interval i the sender constructs packet Pj ={Mj || MAC(K ′

i,Mj) || Ki−d}.

Figure 3 depicts the one-way key chain deriva-tion, the MAC key derivation, the time intervals,and some sample packets that the sender broad-casts.

3.5 Authentication at Receiver

When a sender discloses a key, all parties poten-tially have access to that key. An adversary cancreate a bogus message and forge a MAC usingthe disclosed key. So as packets arrive, the re-ceiver must verify that their MACs are based onsafe keys: a safe key is one that is only known bythe sender, and safe packets or safe messages haveMACs computed with safe keys.

Receivers must discard any packet that is notsafe, because it may have been forged.

We now explain TESLA authentication in de-tail: A sender sends packet Pj in interval i. Whenthe receiver receives packet Pj , the receiver canuse the self-authenticating key Ki−d disclosed inPj to determine i. It then checks the latest possi-ble time interval x the sender could currently bein (based on the loosely synchronized clock). Ifx < i+d (recall that d is the key disclosure delay,or number of intervals that the key disclosure isdelayed), then the packet is safe. The sender hasthus not yet reached the interval where it discloseskey Ki, the key that will verify packet Pj .

The receiver cannot yet verify the authenticityof packet Pj sent in interval i. Instead, it addsthe triplet (i,Mj ,MAC(K ′

i,Mj)) to a buffer, andverifies the authenticity after it learns K ′

i.

8

Pj Pj+1 Pj+2 Pj+3 Pj+4 Pj+5 Pj+6

Ki−1 Ki Ki+1 Ki+2

K′i−1 K′

i K′i+1 K′

i+2

F (Ki) F (Ki+1) F (Ki+2) F (Ki+3)

F ′(Ki−1) F ′(Ki) F ′(Ki+1) F ′(Ki+2)

Interval i − 1 Interval i Interval i + 1 Interval i + 2 time

Figure 3: At the top of the figure is the one-way key chain (using the one-way function F ), and thederived MAC keys (using the one-way function F ′). Time advances left-to-right, and the time is splitinto time intervals of uniform duration. At the bottom of the figure, we can see the packets that thesender sends in each time interval. For each packet, the sender uses the key that corresponds to thetime interval to compute the MAC of the packet. For example for packet Pj+3, the sender computes aMAC of the data using key K ′

i+1. Assuming a key disclosure delay of two time intervals (d = 2), packetPj+3 would also carry key Ki−1.

What does a receiver do when it receives thedisclosed key Ki? First, it checks whether it al-ready knows Ki or a later key Kj (j > i). IfKi is the latest key received to date, the receiverchecks the legitimacy of Ki by verifying, for someearlier key Kv (v < i) that Kv = F i−v(Ki). Thereceiver then computes K ′

i = F ′(Ki) and verifiesthe authenticity of packets of interval i, and ofprevious intervals if the receiver did not yet re-ceive the keys for these intervals (the receiver canderive them from Ki).

Note that the security of TESLA does not relyon any assumptions on network propagation de-lay, since each receiver locally determines thepacket safety, i.e. whether the sender disclosedthe corresponding key. However, if the key dis-closure delay is not much longer than the networkpropagation delay, the receivers will find that thepackets are not safe.

4 Discussion

4.1 TESLA Security Considerations

The security of TESLA relies on the following as-sumptions:

• The receiver’s clock is time synchronized upto a maximum error of ∆. (We suggestthat because of clock drift, the receiver pe-riodically re-synchronizes its clock with thesender.)

• The functions F,F ′ are secure PRFs, and thefunction F furthermore provides weak colli-sion resistance.4

As long as these assumptions are satisfied, itis computationally intractable for an attacker toforge a TESLA packet that the receivers will au-thenticate successfully.

4See our earlier paper for a formal security proof [28].

9

4.2 Achieving Asymmetric Security Proper-ties with TESLA

Broadcast authentication requires an asymmetricprimitive, which TESLA provides through looselysynchronized clocks and delayed key disclosure.TESLA shares many common properties withasymmetric cryptographic mechanisms. In fact,assuming that all nodes in a network are time syn-chronized, any key of the key chain serves as a keychain commitment and is similar to a public key ofa digital signature: any loosely time synchronizedreceiver with an authentic key chain commitmentcan authenticate messages, but not forge a mes-sage with a MAC that receivers would accept.

We can construct an efficient PKI based solelyon TESLA. Consider an environment with n com-municating nodes. We assume that all nodes areloosely time synchronized, such that the maxi-mum clock offset between any two nodes is ∆; andthat all nodes know the authentic key chain com-mitment and key disclosure schedule of the certi-fication authority (CA). We further assume thatthe CA knows the authentic key chain commit-ment and key disclosure schedule of every node.If a node A wants to start authenticating packetsoriginating from another node B, A can contactthe CA for B’s key chain commitment and keydisclosure schedule, which the CA sends authen-ticated with its TESLA instance. After the CAdiscloses the corresponding key, A can authenti-cate B’s TESLA parameters and subsequently au-thenticate B’s packets.

Note that TESLA is not a signature mecha-nism and does not provide non-repudiation, asanybody could forge “authentic” TESLA packetsafter the key is disclosed. However, in conjunctionwith a trusted time stamping mechanism, TESLAcould achieve properties similar to a digital signa-ture. Consider this setup: all nodes in the network

are loosely time synchronized (as above with anupper bound on the synchronization error); andall nodes in the network trust the time stamp-ing server [6, 15, 23]. The time stamping servertimestamps all TESLA packets it receives. Thetime stamping server can broadcast the hooks tothe trust chain authenticated with its TESLA in-stance. A judge who wants to verify that a sendersent packet P performs the following operations:

1. Receive the current value of the time stamp-ing server’s trust chain, ensure that it is safe,and wait for the TESLA key to authenticateit.

2. Based on the trust chain value, verify thatpacket P is part of the trust chain.

3. Verify that packet P was safe when the timestamping server received it (not necessary ifthe time stamping server only timestampssafe packets).

4. Retrieve key from the sender and verify itusing the key chain commitment and disclo-sure schedule recorded by the time stampingserver.

5. Verify that the authenticity of the packet,which implies that the correct sender musthave generated the packet.

TESLA and a time stamping server can thusachieve non-repudiation. This example also showsthat the TESLA authentication can also be per-formed after the key is already disclosed, as longas the verifier can check that the packet arrivedsafely.

10

5 Acknowledgments

We gratefully acknowledge funding support forthis research. This research was sponsored in partthe United States Postal Service (contract USPS102592-01-Z-0236), by the United States DefenseAdvanced Research Projects Agency (contractN66001-99-2-8913), and by the United States Na-tional Science Foundation (grants 99-79852 and01-22599). DARPA Contract N66001-99-2-8913is under the supervision of the Space and NavalWarfare Systems Center, San Diego.

The views and conclusions contained in thisdocument are those of the author and should notbe interpreted as representing official policies, ei-ther expressed or implied, of the United Statesgovernment, of DARPA, NSF, USPS, any of itsagencies.

References

[1] R. Anderson, F. Bergadano, B. Crispo,J. Lee, C. Manifavas, and R. Needham. Anew family of authentication protocols. ACMOperating Systems Review, 32(4):9–20, Oc-tober 1998.

[2] F. Bergadano, D. Cavagnino, and B. Crispo.Chained stream authentication. In SelectedAreas in Cryptography, 7th Annual Interna-tional Workshop, SAC 2000, volume 2012 ofLecture Notes in Computer Science, pages144–157, August 2000.

[3] F. Bergadano, D. Cavalino, and B. Crispo.Individual single source authentication onthe mbone. In ICME 2000, Aug 2000.

[4] D. Boneh, G. Durfee, and M. Franklin. Lowerbounds for multicast message authentication.In Advances in Cryptology — EUROCRYPT

’2001, volume 2045 of Lecture Notes in Com-puter Science, pages 434–450, 2001.

[5] B. Briscoe. FLAMeS: Fast, Loss-TolerantAuthentication of Multicast Streams.Technical report, BT Research, 2000.http://www.labs.bt.com/people/briscorj/papers.html.

[6] A. Buldas, P. Laud, H. Lipmaa, andJ. Villemson. Time-stamping with binarylinking schemes. In Advances in Cryptol-ogy — CRYPTO ’98, volume 1462 of LectureNotes in Computer Science, pages 486–501,1998.

[7] R. Canetti, J. Garay, G. Itkis, D. Miccian-cio, M. Naor, and B. Pinkas. Multicast se-curity: A taxonomy and some efficient con-structions. In INFOCOMM’99, pages 708–716, March 1999.

[8] S. Cheung. An efficient message authen-tication scheme for link state routing. In13th Annual Computer Security ApplicationsConference, pages 90–98, 1997.

[9] D. Coppersmith and M. Jakobsson. Almostoptimal hash sequence traversal. In Pro-ceedings of the Fourth Conference on Finan-cial Cryptography (FC ’02), Lecture Notes inComputer Science, 2002.

[10] Y. Desmedt and Y. Frankel. Shared genera-tion of authenticators and signatures. In Ad-vances in Cryptology — CRYPTO ’91, vol-ume 576 of Lecture Notes in Computer Sci-ence, pages 457–469, 1992.

[11] Y. Desmedt, Y. Frankel, and M. Yung. Multi-receiver / multi-sender network security: Ef-ficient authenticated multicast / feedback. InProceedings IEEE Infocom ’92, pages 2045–2054, 1992.

11

[12] Y. Desmedt and M. Yung. Arbitrated un-conditionally secure authentication can beunconditionally protected against arbiter’sattacks. In Advances in Cryptology —CRYPTO ’90, volume 537 of Lecture Notesin Computer Science, pages 177–188, 1991.

[13] F. Fujii, W. Kachen, and K. Kurosawa. Com-binatorial bounds and design of broadcastauthentication. IEICE Transactions, E79-A(4):502–506, 1996.

[14] R. Gennaro and P. Rohatgi. How to sign dig-ital streams. In Advances in Cryptology —CRYPTO ’97, volume 1294 of Lecture Notesin Computer Science, pages 180–197, 1997.

[15] S. Haber and W. Stornetta. How to time-stamp a digital document. In Advances inCryptology — CRYPTO ’90, volume 537 ofLecture Notes in Computer Science, pages437–455, 1991.

[16] N. Haller. The S/Key one-time passwordsystem. In Proceedings of the Symposiumon Network and Distributed Systems Secu-rity, pages 151–157. Internet Society, Febru-ary 1994.

[17] H. Holbrook and D. Cheriton. IP multicastchannels: EXPRESS support for large-scalesingle-source applications. In Proceedings ofACM SIGCOMM ’99, September 1999.

[18] Y.-C. Hu, A. Perrig, and D. B. Johnson.Ariadne: A secure on-demand routing pro-tocol for ad hoc networks. In Proceedingsof the Eighth ACM International Conferenceon Mobile Computing and Networking (Mo-bicom 2002), September 2002. To appear.

[19] M. Jakobsson. Fractal hash sequence repre-sentation and traversal. In Proceedings of the2002 IEEE International Symposium on In-formation Theory (ISIT ’02), pages 437–444,July 2002.

[20] K. Kurosawa and S. Obana. Characteriza-tion of (k,n) multi-receiver authentication.In Proceedings of the 2nd Australasian Con-ference on Information Security and Privacy(ACISP ’97), volume 1270 of Lecture Notesin Computer Science, pages 205–215, 1997.

[21] L. Lamport. Password authentication withinsecure communication. Communications ofthe ACM, 24(11):770–772, November 1981.

[22] L. Lamport and P. Melliar-Smith. Synchro-nizing clocks in the presence of faults. Jour-nal of the ACM, 32(1):52–78, 1985.

[23] H. Lipmaa. Secure and Efficient Time-Stamping Systems. PhD thesis, Departmentof Mathematics, University of Tartu, Esto-nia, April 1999.

[24] D. Mills. Network Time Protocol (version 3)specification, implementation and analysis.Internet Request for Comment RFC 1305, In-ternet Engineering Task Force, March 1992.

[25] S. Miner and J. Staddon. Graph-based au-thentication of digital streams. In Proceed-ings of the IEEE Symposium on Researchin Security and Privacy, pages 232–246, May2001.

[26] Multicast security ietf working group(msec). http://www.ietf.org/html.charters/msec-charter.html, 2002.

[27] A. Perrig, R. Canetti, D. Song, and J. D.Tygar. Efficient and secure source authen-tication for multicast. In Proceedings of theSymposium on Network and Distributed Sys-tems Security (NDSS 2001), pages 35–46. In-ternet Society, February 2001.

[28] A. Perrig, R. Canetti, J. D. Tygar, andD. Song. Efficient authentication and signa-ture of multicast streams over lossy channels.

12

In Proceedings of the IEEE Symposium onResearch in Security and Privacy, pages 56–73, May 2000.

[29] A. Perrig, R. Szewczyk, V. Wen, D. Culler,and J. D. Tygar. SPINS: Security proto-cols for sensor networks. In Proceedings ofSeventh Annual International Conference onMobile Computing and Networks (Mobicom2001), pages 189–199, 2001.

[30] A. Perrig and J. D. Tygar. Security Protocolsfor Broadcast Networks. Kluwer AcademicPublishers, 2002. To appear.

[31] M. Reiter. A security architecture for fault-tolerant systems. PhD thesis, Departmentof Computer Science, Cornell University, Au-gust 1993.

[32] M. Reiter, K. Birman, and R. van Renesse.A security architecture for fault-tolerant sys-tems. ACM Transactions on Computer Sys-tems, 12(4):340–371, November 1994.

[33] P. Rohatgi. A compact and fast hybrid sig-nature scheme for multicast packet. In Pro-ceedings of the 6th ACM Conference on Com-puter and Communications Security, pages93–100, November 1999.

[34] R. Safavi-Naini and H. Wang. New resultson multireceiver authentication codes. In Ad-vances in Cryptology — EUROCRYPT ’98,volume 1403 of Lecture Notes in ComputerScience, pages 527–541, 1998.

[35] R. Safavi-Naini and H. Wang. Multireceiverauthentication codes: Models, bounds, con-structions and extensions. Information andComputation, 151(1/2):148–172, 1999.

[36] G. Simmons. A cartesian product construc-tion for unconditionally secure authentica-tion codes that permit arbitration. Journalof Cryptology, 2(2):77–104, 1990.

[37] B. Simons, J. Lundelius-Welch, andN. Lynch. An overview of clock syn-chronization. In B. Simons and A. Spector,editors, Fault-Tolerant Distributed Com-puting, number 448 in LNCS, pages 84–96,1990.

[38] D. Song, D. Zuckerman, and J. D. Tygar.Expander graphs for digital stream authen-tication and robust overlay networks. InProceedings of the IEEE Symposium on Re-search in Security and Privacy, pages 258–270, May 2002.

[39] C. Wong and S. Lam. Digital signatures forflows and multicasts. In IEEE ICNP ‘98,1998.

[40] Source-Specific Multicast IETF work-ing group (SSM). http://www.ietf.org/html.charters/ssm-charter.html, 2002.

13