Efficient Authentication and Signing of
Multicast Streams over Lossy Channels
Adrian Perrig
Ran Canetti
J. D. Tygar
Dawn Song
UC Berkeley,
IBM T.J. Watson
perrig,tygar,dawnsong@cs.berkeley.edu, canetti@watson.ibm.com
Abstract
Multicast stream authentication and signing is an im-
portant and challenging problem. Applications include the
continuous authentication of radio and TV Internet broad-
casts, and authenticated data distribution by satellite. The
main challenges are fourfold. First, authenticity must be
guaranteed even when only the sender of the data is trusted.
Second, the scheme needs to scale to potentially millions of
receivers. Third, streamed media distribution can have high
packet loss. Finally, the system needs to be efficient to sup-
port fast packet rates.
We propose two efficient schemes, TESLA and EMSS,
for secure lossy multicast streams. TESLA, short for Timed
Efficient Stream Loss-tolerant Authentication, offers sender
authentication, strong loss robustness, high scalability, and
minimal overhead, at the cost of loose initial time synchro-
nization and slightly delayed authentication. EMSS, short
for Efficient Multi-chained Stream Signature, provides non-
repudiation of origin, high loss resistance, and low over-
head, at the cost of slightly delayed verification.
This work began in Summer 1999 when Adrian Perrig and Dawn Song
were visiting the IBM T. J. Watson research lab. Initial research on stream
authentication was done during Summer 1999 by Ran Canetti, Adrian Per-
rig, and Dawn Song at IBM. Additional improvements were suggested by
J. D. Tygar in Fall 1999 at UC Berkeley. Implementation was done in Fall
1999 by Adrian Perrig at UC Berkeley. The work on stream signatures was
done by J. D. Tygar, Adrian Perrig, and Dawn Song at UC Berkeley. Ad-
ditional work was performed by Ran Canetti in Spring 2000. Ran Canetti
is at IBM T. J. Watson Research Center, and Adrian Perrig, Dawn Song,
and J. D. Tygar are at the Computer Science Division, UC Berkeley. This
research was suported in part by the Defense Advanced Research Projects
Agency under DARPA contract N6601-99-28913 (under supervision of the
Space and Naval Warfare Systems Center San Diego), by the National Sci-
ence foundation under grant FD99-79852, and by the United States Postal
Service under grant USPS 1025 90-98-C-3513. Views and conclusions
contained in this document are those of the authors and do not necessarily
represent the official opinion or policies, either expressed or implied of the
US government or any of its agencies, DARPA, NSF, USPS, or IBM.
1 Introduction
As the online population continues to expand, the Inter-
net is increasingly used to distribute streamed media, such
as streamed radio and video. We expect this trend to con-
tinue.
To enable a widespread and trusted streamed media dis-
semination, one must first provide sufficient security guar-
antees. A most prominent security risk from a user point
of view is data authenticity. The user needs assurance that
the data stream originated from the purported sender. Oth-
erwise, a malicious ISP could replace parts of the stream
with its own material. For example, an adversary might al-
ter stock quotes that are distributed through IP multicast.
In that scenario, the receiver needs strong sender and data
authentication.
The problem of continuous stream authentication is
solved for the case of one sender and one receiver via stan-
dard mechanisms, e.g. [12, 18]. The sender and receiver
agree on a secret key which is used in conjunction with a
message authenticating code (MAC) to ensure authenticity
of each packet. In case of multiple receivers, however, the
problem becomes much harder to solve, because a symmet-
ric approach would allow anyone holding a key (that is, any
receiver) to forge packets. Alternatively, the sender can use
digital signatures to sign every packet with its private key.
This solution provides adequate authentication, but digital
signatures are prohibitively inefficient.
Real-time data streams are lossy, which makes the secu-
rity problem even harder. With many receivers, we typically
have a high variance among the bandwidth of the receivers,
with high packet loss for the receivers with relatively low
bandwidth. Nevertheless, we want to assure data authentic-
ity even in the presence of this high packet loss.
A number of schemes for solving this problem (i.e. au-
thenticating the data and sender in a setting where only the
sender is trusted) have been suggested in the past few years
[7, 13, 28, 31], but none of these schemes is completely sat-
1
isfactory. We discuss these schemes in section 4.
This paper presents two very different solutions to the
problem of authenticating data streams efficiently in a
lossy environment. The first solution, called TESLA (for
Timed Efficient Stream Loss-tolerant Authentication), uses
only symmetric cryptographic primitives such as pseudo-
random functions (PRFs) and message authentication codes
(MACs), and is based on timed release of keys by the
sender. More specifically, the scheme is based on the fol-
lowingidea: The sender commits to a random key
without
revealingit and transmits it to the receivers. The sender then
attaches a message authenticating code to the next packet
and uses the key
as the MAC key. In a later packet
,
the sender decommits to
, which allows the receivers to
verify the commitment and the MAC of packet
. If both
verifications are correct, and if it is guaranteed that packet
was not sent before packet
was received, then a re-
ceiver knows that the packet
is authentic. To start this
scheme, the sender uses a regular signature scheme to sign
the initial commitment. All subsequent packets are authen-
ticated through chaining.
Our first scheme, TESLA, has the following properties:
Low computation overhead. The authentication in-
volves typically only one MAC function and one hash
function computation per packet, for both sender and
receiver.
Low per-packet communication overhead. Overhead
can be as low as
bytes per packet.
Arbitrary packet loss tolerated. Every packet which is
received in time can be authenticated.
Unidirectional data flow. Data only flows from the
sender to the receiver. No acknowledgments or other
messages are necessary after connection setup. This
implies that the sender’s stream authentication over-
head is independent on the number of receivers, so our
scheme is very scalable.
No sender-side buffering. Every packet is sent as soon
as it is ready.
High guarantee of authenticity. The system provides
strong authenticity. By strong authenticity we mean
that the receiver has a high assurance of authenticity,
as long as our timing and cryptographic assumptions
are enforced.
1
Freshness of data. Every receiver knows an upper
bound on the propagation time of the packet.
1
However, the scheme does not provide non-repudiation. That is, the
recipient cannot convince a third party that the stream arrived from the
claimed source.
The second scheme, called EMSS (for Efficient Multi-
chained Stream Signature), is based on signing a small num-
ber of special packets in a data stream; each packet is linked
to a signed packet via multiple hash chains. This is achieved
by appending the hash of each packet (including possible
appended hashes of previous packets) to a number of sub-
sequent packets. Appropriate choice of parameters to the
scheme guarantees that almost all arriving packets can be
authenticated, even over highly lossy channels. The main
features of this scheme are:
It amortizes the cost of a signature operation over mul-
tiple packets, typically about one signature operation
per
to
packets.
It tolerates high packet loss.
It has low communication overhead, between
to
bytes per packet, depending on the requirements.
It provides non-repudiability of the sender to the trans-
mitted data.
2 TESLA: Timed Efficient Stream Loss-
tolerant Authentication
In this section, we describe five schemes for stream au-
thentication. Each scheme builds up on the previous one
and improves it to solve its shortcomings. Finally, scheme
V, which we call TESLA (short for Timed Efficient Stream
Loss-tolerant Authentication), satisfies all the properties we
listed in the introduction. The cryptographicprimitivesused
in this section are reviewed in Appendix A, which also con-
tains a sketch of a security analysis for our scheme.
We use the following notation:
denotes the con-
catenation of
and
,
stands for sender, and
stands for
receiver. A stream
is divided into chunks
!
(which we
also call messages),
#"$% &'( *)+-,,-,./ 10
. Each mes-
sage
*
is sent in a packet
, along with additional au-
thentication information.
2.1 Threat Model and security guarantee
We design our schemes to be secure against a powerful
adversary with the following capabilities:
Full control over the network. The adversary can
eavesdrop, capture, drop, resend, delay, and alter pack-
ets.
The adversary has access to a fast network with negli-
gible delay.
The adversary’s computational resources may be very
large, but not unbounded. In particular, this means that
2
the adversary can performefficient computations, such
as computing a reasonable number of pseudo-random
function applications and MACs with negligible delay.
Nonetheless the adversary cannot invert a pseudoran-
dom function (or distinguish it from a random func-
tion) with non-negligible probability.
The security property we guarantee is that the receiver
does not accept as authentic any message
unless
was
actually sent by the sender. A scheme that provides this
guarantee is called a secure stream authentication scheme.
Note that the above security requirements do not include
protectionagainst message duplication. Such protectioncan
(and should) be added separately by standard mechanisms,
such as nonces or serial numbers. Schemes I-III below do
have protection against message duplication. Note also that
we do not address denial-of-service attacks.
2.2 Initial synchronization (preliminary discus-
sion)
All five schemes below begin with an initial synchroniza-
tion protocol where each receiver compares its local time
with that of the sender, and registers the difference. We re-
mark that a rough upper bound on the clock difference is
sufficient. In fact, all that the receiver needs is a value
such that the sender’s clock is no more than
time-units
ahead of the receiver’s clock, where
can be on the order
of multiple seconds.
2
In section 2.8 we describe a simple
protocol and discuss scalability issues related to the initial
synchronization.
A basic assumption that underlies the security of our
scheme is that the local internal clocks of the sender and
recipient do not drift too much during a session.
2.3 Scheme I: The Basic Scheme
Here is a summary of scheme I: The sender issues a
signed commitment to a key which is only known to it-
self. The sender then uses that key to compute a MAC
on a packet
, and later discloses the key in packet
,
which enables the receiver to verify the commitment and
the MAC of packet
. If both verifications are successful,
packet
is authenticated and trusted. The commitment
is realized via a pseudorandom function with collision re-
sistance. More details on the requirements on the pseudo-
random functions are in appendix A. This protocol is simi-
lar to the Guy Fawkes protocol [1].
We now describe the basic scheme in more detail.
The scheme is depicted in Figure 1. We assume
that the receiver has an authenticated packet
"
2
Many clock synchronization algorithms exist, for example the work of
Mills on NTP [22], and its security analysis [5].
authenticated authenticated after
reception of Pi+1
not yet authenticated
PSfrag replacements
MAC
MAC
!
"
MAC
#
Figure 1. Basic stream authentication
scheme.
stands for message
$
,
is packet
$
,
%
denotes the secret key
$
,
&
&('
are pseudo-random functions,
and MAC
)"%*'
+
,
computes the MAC
of packet
$
using the secret key
%-'
"
&(')%
.,
.
+
MAC
)%-'
.
/+
0,
to start with (where
+
"
%
&1)"%
,
%
)
). The fields have the following
meanings.
is the message contained by the packet,
%*'
"
2&('.)"%
",
is the secret key used to compute the MAC
of the next packet, and
&1)"%
",
commits to the key
%
with-
out revealing it. The functions
&
and
&3'
are two different
pseudo-randomfunctions. Commitment value
&1)%
,
is im-
portant for the authentication of the subsequent packet
.
To bootstrap this scheme, the first packet needs to be au-
thenticated with a regular digital signature scheme, for ex-
ample RSA [27].
To send the message
, the sender picks a fresh ran-
dom key
%
and constructs the following packet
"
+
MAC
)%-'
/+
,
, where
+
"
/&1)%
0,
%
.
and the MAC
)%-'
+
.,
computes a message authenticating
code of
+
under key
%-'
.
When the receiverreceives packet
, it cannotverify the
MAC instantly, since it does not know
%
and cannot re-
construct
%
'
. Packet
"
"+
+
MAC
)%
'
/+
,
(where
+
" % +
&1)%
.)
,
/%
%
) discloses
%
and
allows the receiver first to verify that
%
is correct (
&1)%
,
equals the commitment which was sent in packet
); and
second to compute
%4'
"
5&(')%
",
and check the authenticity
of packet
by verifying the MAC of packet
.
After the receiver has authenticated
, the commitment
&1)%
0,
is also authenticated and the receiver repeats this
scheme to authenticate
after
.)
is received.
This scheme can be subverted if an attacker gets packet
before the receiver gets
, since the attacker would
then know the secret key
%
which is used to compute the
MAC of
, which allows it to change the message and the
commitment in
and forge all subsequent traffic. To pre-
vent this attack, the receiver checks the following security
3
condition on each packet it receives, and drops the packet if
the condition does not hold.
Security condition: A data packet
arrived safely,
if the receiver can unambiguously decide, based on its
synchronized time and
, that the sender did not yet
send out the corresponding key disclosure packet
.
This stream authentication scheme is secure as long as the
security condition holds. We would like to emphasize that
the security of this schemedoes not rely on any assumptions
on network latency.
In order for the receiver to verify the security condition,
the receiver needs to know the precise sending schedule of
packets. The easiest way to solve this problem is by using a
constant packet rate. The sending time of packet
is hence
"
$
where
is the time on the sender’s clock
and
is the packet rate (number of packets per second). In
that case, the security condition which the receiver checks
has the following form:
, where
stands for the arrival time (on the synchronized receiver’s
clock) of packet
. The main problem with this scheme is
that, in order to satisfy the security condition, the sending
rate must be slower than the network delay from the sender
to the receiver. This is a severe limitation on the throughput
of the transmission. In addition, the basic scheme cannot
tolerate packet loss. In particular, once a packet is dropped
no further packets can be authenticated. We now gradually
extend the basic scheme to eliminate these deficiencies.
2.4 Scheme II: Tolerating Packet Loss
To authenticate lossy multimedia streams, tolerating
packet loss is paramount. Our solution is to generate a se-
quence of keys
%
through a sequence generated through
pseudo-random function applications. We denote
con-
secutive applications of the pseudo-random function
&
as
&
)
,
"
&
.
)"&1)
,,
. By convention,
&
)
,
"#
. The
sender picks a random
%
and pre-computes a sequence of
key values, where
%
"
&
)%
,
, and
%
"
&
)%
,
.
We call this sequence of values the key chain. Each
%
looks pseudorandom to an attacker; in particular, given
%
,
the attacker cannot invert
&
and compute any
%
for
$
.
On the other hand, the receiver can compute all
%
from a
%
it received, where
$
, since
%
"
5&
)%
,
. Hence,
if a receiver received packet
, any subsequently received
packet will allow it to compute
%
and
%-'
"
2&(')%
,
and
verify the authenticity of
. This scheme tolerates an arbi-
trary number of packet losses.
Similarly, dropping unsafe packets (i.e. those packets
where the security condition does not hold) does not cause
any problems in the authentication of later packets.
In the basic scheme I, an adversary might try to capture
two consecutive packets before the recipient received the
first of them, and then forge the packet stream. Although the
security condition prevents this, the key chain also prevents
this attack, because the initial commitment commits to the
entire key chain and it is computationally infeasible for the
attacker to invert or find collisions in the pseudo-random
function.
3
An additional benefit is that the key commitment does
not need to be embedded in each packet any more. Due to
the intractability of inverting the pseudo-random function,
any value of the chain is a commitment for the entire chain.
Hence the commitment in the initial authenticated packet is
sufficient. Figure 2 shows an example of scheme II.
not yet authenticatedauthenticated authenticated after
reception of Pi+1
PSfrag replacements
! #"%$ ! ! '&%$
(
#"%$
(
(
)&*$
+
,"%$
+
+
)&*$
-. ,"0/
-. ,"%$
-. ,"%$
-1
-1
-1 )&*$
MAC
2
-3
#"%$!4
+5 #"%$6
MAC
2
-3
4
+5 76
MAC
2
-3
)&*$
4
+5 '&%$6
-3
,"%$
-3
-
3
)&*$
803803893
8 8
Figure 2. Scheme II. The packet format
is the same as in scheme I, except that the
commitment
&1)%
,
is omitted and the
keys form a one-way key chain.
2.5 Scheme III: Achieving Fast Transfer Rates
As we mentioned earlier, the receiver needs to be assured
that it receives the packet
before the corresponding key
disclosure packet
is sent by the sender. This condi-
tion severely limits the transmission rate of the previoustwo
schemes since
can only be sent after everyreceiver has
received
.
We solve this problem by disclosing the key
%
of the
data packet
in a later packet
;:
, instead of in the fol-
lowing packet, where
<
is a delay parameter that is set by
the sender and announced as the session set-up.
The sender determines the delay
<
based on the packet
rate
, the maximum tolerable synchronization uncertainty
3
I.e., it is infeasible, given
=?>A@CBEDF=G>)HJIK
to find
=ML
>'HI
such
that
BED,=ML
>)HJI
KM@N=G>
. Even if the attacker could find such a collision
BEDF=
L
>'HI
KO@N=G>
then it would be able to forge only a single message
P
>'HI
. Forging additional messages would require inverting
B
, i.e., find-
ing
=ML
>)HRQ
such that
BED,=ML
>'H.Q
K.@S=ML
>'HI
.
4
tMax
, and the maximum tolerable network delay
<
NMax
.
Setting
<
"
)"
tMax
<
NMax
,
allows the receiver to suc-
cessfully verify the security condition even in the case of
maximum allowable network delay and maximal synchro-
nization error. The choice of
tMax
and
<
NMax
presents the
following tradeoff: Large delay values will cause a large
<
which results in long delays until the packet authentica-
tion. On the other hand, short maximum delays cause the
the security condition to drop packets at receivers with a
slow network connection. However, multimedia data pack-
ets become obsolete if they are received after their segment
of the stream was already played or presented to the user. In
that case, dropping unsafe packets might not interfere with
the multimedia stream since the packets are likely to be ob-
solete. We stress that the choice of
<
does not affect the
security of the scheme, only its usability.
For the case of a constant packet rate, the security con-
dition is easy to state. We assume that the sending time of
the first packet is
J
and the sending time of packet
is
"
$
. To verify the security condition for an in-
coming packet, the receiver checks that
;:
,
where
is the arrival time of packet
at the receiver.
2.6 Scheme IV: Dealing with Dynamic Packet
Rates
Our previous schemes used a fixed or predictable sender
schedule, with each recipient knowing the exact sending
time of each packet. Since this severely restricts the flexibil-
ity of senders, we design a scheme which allows senders to
send at dynamictransmission rates, without the requirement
that every receiver needs to know about the exact sending
schedule of each packet. The solution to this problem is to
pick the MAC key and the disclosed key in each packet only
on a time interval basis instead of on a packet index basis.
The sender uses the same key
%
to compute the MAC for
all packets which are sent in the same interval
$
. All packets
sent in interval
$
disclose the key
%
J:
.
At session set-up the sender announces values
and
, where the former is the starting time of the first interval
and the latter is the duration of each interval. In addition
the delay parameter
<
is announced. These announcements
are signed by the sender. The interval index at any time
period
is determined as
$
"
. A key
%
is as-
sociated with each interval
$
. The keys are chained in the
same way as in Scheme II. The sender uses the same key
%*'
"
&('.)%
,
to compute the MAC for each packet which
is sent in interval
$
. Every packet also carries the interval
index
$
and discloses the key of a previous interval
%
:
.
We refer to
<
as disclosure lag. The format of packet
is
" %
$
(
/%
:
MAC
)%-'
(
,
. Figure 3 shows an
example of this scheme, where
<
"
.
In this scheme, the receiver verifies the security con-
dition as follows. Each receiver knows the values of
,
, and
. (
is the value obtained from the initial
synchronization protocol.) Assume that the receiver gets
packet
at its local time
, and the packet was appar-
ently sent in interval
$
. The sender can be at most in interval
$!'
"
#
. The security condition in this case is sim-
ply
$
<
$!'
, which ensures that no packet which discloses
the value of the key could have been sent yet. Figure 4 il-
lustrates the verification of the security condition.
It remains to describe how the values
and
<
are
picked. (We stress that the choice of these values does not
affect the security of the scheme, only its usability.) Be-
fore the sender can pick values for
and
<
, it needs to de-
termine the maximum tolerable synchronization uncertainty
tMax
, and the maximum tolerable network delay
<
NMax
. The
sender defines
Max
!
"
tMax
<
NMax
The sender’s choice for
and
Max
both present a
tradeoff. First, a large value for
Max
will allow slow re-
ceivers to verify the security condition correctly, but re-
quires a long delay for packet authentication. Conversely,
a short
Max
will cause slow receivers to drop packets be-
cause the security condition is not satisfied. The second
tradeoffis that a long intervalduration
saves on the com-
putation and storage overhead of the key chain, but a short
more closely achieves the desired
Max
.
After determining
tMax
,
<
NMax
, and
, the disclosure
lag is
<
"
"
tMax
;:
NMax
.
This scheme provides numerous advantages. First, the
sender can predict how long a pre-computed key chain lasts,
since the number of necessary keys is only time dependent
and not on the number of packets sent. Second, the re-
ceiver can conveniently verify the security condition and
the sender does not need to send its packets at specific in-
tervals (we will discuss the details of this in Section 2.9).
Another advantage is that new receivers can easily join the
group at any moment. A new group member only needs to
synchronize its time with the sender and receive the interval
parameters and a commitment to the key chain.
2.7 Scheme V: Accommodate a Broad Spectrum
of Receivers
For the previous schemes, we showed that there was a
tradeoff in the choice of the key disclosure period. If the
time difference is short, the packet can be authenticated
quickly, but if the packet travel time is long the security
condition will not hold for remote receivers, which forces
them to drop the packet. Conversely, a long time period
will suit remote receivers, but the authentication time delay
may be unacceptable for receivers with fast network access.
Since the scheme needs to scale to a large number of re-
ceivers and we expect the receivers to have a wide variety
of network access, we need to solve this tradeoff. Our ap-
proach is to use multiple authentication chains (where each
chain is as in scheme IV) with different disclosure periods
5
