Multicasting is an efficient communication mechanism
for group-oriented applications such as video
conferencing, interactive group games, and video
on demand. IP multicast [1 ] saves bandwidth by sending the
source traffic on a multicast tree that spans all the members
of the group. In this communication model, groups are identified
by a group address, and any node of the network may
join or leave the group freely. However, this simplicity, which
is the strength of multicast routing, presents many vulnerabilities
[2]:
• IP multicast does not support closed groups. In fact, multicast
addresses are publicly known: joining or leaving a
group does not require specific permissions [3 ]. Hence,
any user may join a multicast group and receive messages
sent to the group.
• There is no access control to the group: an intruder may
send data to the group without being a valid member,
thus disturbing the multicast session or eventually creating
bottlenecks in the network.
• D ata sent to the group may transit via many unsecure
34
THIRD QUARTER 2004, VOLUME 6, NO. 3
IEEE
COM M U N ICA TION S
S U R V E Y S
The Ele ctro nic M a g a zine o f
Orig ina l P e e r-R e v ie w e d S u rv e y A rticle s
www.comsoc.org/pubs/surveys
A TAXONOMY OF
MULTICAST DATA ORIGIN AUTHENTICATION:
ISSUES AND SOLUTIONS
YACINE CHALLAL, HATEM BETTAHAR, AND ABDELMADJID BOUABDALLAH,
COMPIEGNE UNIVERSITY OF TECHNOLOGY
AB STR ACT
Multicasting is an efficient communication mechanism for group-oriented applications such as
videoconferencing, broadcasting stock quotes, interactive group games, and video on demand.
The lack of security obstructs a large deployment of this efficient communication model. This
limitation motivated a host of research works that have addressed the many issues relating to
securing the multicast, such as confidentiality, authentication, non-repudiation, integrity, and
access control. Many applications, such as broadcasting stock quotes and video-conferencing,
require data origin authentication of the received traffic. Hence, data origin authentication is
an important component in the multicast security architecture. Multicast data origin
authentication must take into consideration the scalability and the efficiency of the underlying
cryptographic schemes and mechanisms, because multicast groups can be very large and the
exchanged data is likely to be heavy in volume (streaming). Besides, multicast data origin
authentication must be robust enough against packet loss because most multicast multimedia
applications do not use reliable packet delivery. Therefore, multicast data origin authentication
is subject to many concurrent and competitive challenges, when considering these miscellaneous
application-level requirements and features. In this article we review and classify recent works
dealing with the data origin authentication problem in group communication, and we discuss
and compare them with respect to some relevant performance criteria.
channels. Thus, eavesdropping opportunities are more
abundant.
A ssuring a certain level of security is a strong requirement
for a large deployment of the multicast communication model
[4]. Some applications need confidentiality (such as a pay per
view application), others need data origin authentication
(such as broadcasting stock quotes), and others need both
authentication and confidentiality (such as video-conferencing),
etc. [5, 6]
Even though a multitude of data origin authentication
mechanisms currently exist, data origin authentication in
multi-party communications remains a challenging problem in
terms of scalability, efficiency, and performance. In fact, hashes
[7 – 9 ], MA Cs [1 0], and digital signatures [1 1 , 1 2] are the
cryptographic answers to data integrity, data origin authentication,
and non-repudiation in data transmission. However,
these mechanisms have been designed typically for point-topoint
transmissions, and using them in multicasting yields
inefficient and non-adequate solutions. This non-suitability of
existing authentication mechanisms is mainly due to the num-
IEEE Communications Surveys & Tutorials • Third Quarter 2004
ber of group members, which may be high in multi-party
applications, and to the type of transmitted data, which consists
generally in continuous streaming of multicast messages
with real-time transmission. W e distinguish between two types
of authentication in group communication [6]:
• Group authentication: consists of assuring that the
received multicast messages by group members originate
from a valid group member (regardless of its identity).
• Data origin authentication: consists of assuring that the
received multicast messages by group members originate
from a source having a specific identity.
In order to assure group authentication, generally group
members use a shared key. This key is commonly called the
group key. Applying a MAC to a message with the group key
assures that the message originates from a valid group member,
since only valid group members share the group key.
Hence, the group authentication problem is reduced to group
key management and mainly to its scalability to large groups
[4, 6, 13, 14]. In contrast, multicast data origin authentication is
more complicated because the group key, which is known by
all group members, cannot be used to identify a specific
sender. W e distinguish between two levels of multicast data
origin authentication:
A first level guarantees only data origin authentication of
the multicast flow. In this case a sender needs to use an asymmetric
mechanism that allows receivers to verify the authenticity
of multicast messages without being able to generate valid
authenticators for messages on behalf of the sender. Some
solutions propose to introduce asymmetry in the key material
used to authenticate messages. In other words, the sender
knows the entire key material required to authenticate messages,
and the receivers know only a partial view of the key
material, which allows them to verify the authenticity of
received messages without being able to generate valid authenticators.
This kind of solution is subject to collusions, where a
set of fraudulent receivers collaborate to reconstruct a part of
the whole key material used by the sender. O ther solutions
suggest the use of time as a source of asymmetry. In other
words, receivers are synchronized with the sender’s clock and
are instructed when to accept a specific key being used to
authenticate received messages. In this case a fraudulent
receiver cannot use a received (or eavesdropped) sender’s key
to forge messages on behalf of the sender. Indeed, by the time
a fraudulent receiver uses a sender’s key to forge an authenticator
of a message, receivers will reject the fraudulent member’s
message because the used key would have expired. This
approach makes possible new security attacks relating to time
synchronization disturbance.
A sec o n d level guarantees non-repudiation in addition to
data origin authentication. In this case the multicast stream
should be signed. Current digital signature mechanisms are
very computationally expensive. Therefore, it is not practical to
sign each packet of the multicast stream. Most of proposed
solutions rely on the concept of amortizing a single digital signature
over multiple packets. The signature and its amortization
induce some extra-information called authentication
information. Most multicast media streaming applications do
not use a reliable transport layer. Hence, some packets may
be lost in the course of transmission. Therefore, the proposed
solutions introduce redundancy into the authentication information,
in such a way that even if some packets are lost the
required authentication information can be recovered in order
to verify received packets’ authenticity. In this case, the bandwidth
overhead, induced by the redundant authentication
information, increases. Proposed solutions deal with how to
trade bandwidth for tolerance to packet loss.
Multicast data origin authentication has matured over the
last twenty years and many solutions have been proposed to
solve this challenging problem. In this article, we review and
classify existing solutions. The discussion of protocols is followed
by a comparison and discussion that highlights the
strengths and shortcomings of each protocol with respect to
relevant performance criteria.
This article is organized as follows. First we recall background
material relating to information security and cryptography.
Then we present multicast data origin authentication
requirements, and we propose a taxonomy of existing solutions.
Then the survey will be divided into two sections. In the
first section we present solutions relating to multicast data origin
authentication. In the second section we present solutions
relating to multicast data origin authentication with non-repudiation.
Each section is followed by a comparison and discussion
of presented protocols. W e end the survey with our
conclusions and a discussion of open issues.
INF O RMATIO N SECU RITY AND CRYP TO GRAP HY
In this section we recall common information security properties
and present an overview of the cryptographic mechanisms
used to achieve them. 1
DATA INTEGRITY
Definition 1: D a ta in teg rity is the property by which data has
not been changed, destroyed, or lost in an unauthorized or
accidental manner [16].
C ryptographic hash functions are typically used to assure
data integrity [17]. L et us consider the following definition
and then present a typical usage of cryptographic hash functions
to assure data integrity:
Definition 2: A h a sh fu n c tio n is a computationally efficient
function mapping binary strings of arbitrary length to binary
strings of some fixed length, called hash-values [17].
W e denote the hash-value of a message m by h(m). Cryptographic
hash functions have the following properties
[16–19]:
• Given m, it is easy to compute h(m).
• Given h(m), it is hard to compute m such that h(m) = h.
• Given m, it is hard to find another message, m′, such that
h(m) = h(m′).
A hash-value is also called a message digest, a hash-result, or
simply a hash.
E xample: 2 Suppose that you want to save a large digital
document (a program or a database) from alterations that
may be caused by viruses or accidental misuses. A straightforward
solution would be to keep a copy of the digital document
on some tamper-proof backup and periodically compare
it to the active version. W ith a cryptographic hash function, you
can save storage: you simply save the message digest of the
document on the tamper-proof backup (which, because the
hash is small, could be a piece of paper or a floppy disk). (See
Fig. 1, steps 1 and 2.)
Then you periodically re-calculate the message digest of
the document (Fig. 1, step 3) and compare it to the original
message digest (Fig. 1, step 4). If the message digest has not
changed, you can be confident that none of the data has
1 The given measurements are from a benchmark due to Dai [15]. The
author used Pentium 4 2.1 GHz processor under Windows XP SP 1.
2 This example is cited by many authors such as Kaufman et al. in [18]
and Menezes et al. in [17].
IEEE Communications Surveys & Tutorials • Third Quarter 2004 35
     
     
changed. Examples of hash functions are MD2 (Message
Digest 2) [8], MD5 [9], and SHA-1 (Secure Hash Algorithm
1) [7]. Table 1 lists measurements for commonly used hash
algorithms.
36
Digest
(2) Secure
storage
Digital
document
Protected floppy disk
(1) Hash
computation
Later in time
Digital
document
Document
safe from
alterations
(3) Hash recomputation
FIGURE 1. Assuring data integrity using message digests.
DATA ORIGIN AUTHENTICATION
(4) Data integrity
verification
Definition 3: Data origin authentication is the corroboration
that the source of the data received is as claimed [16].
Message authentication codes (MACs) is a cryptographic
mechanism that can be used to assure data origin authentication
and data integrity at the same time.
Definition 4: A message authentication code ( M AC ) algorithm
is a family of functions h k parameterized by a secret key
k, with the following properties:
• Given a key k and an input m, h k(m) is easy to compute.
• h k maps an input m of an arbitrary finite bit length to an
output h k(m) of fixed bit length.
Furthermore, given a description of the function family h,
for every fixed allowable value of k (unknown to an adversary),
the following property holds:
• Given zero or more pairs (m i, h k(m i)), it is computationally
infeasible to compute any pair (m, h k(m)) for any
new input m [17].
A MAC can also be seen as “ a cryptographic hash in which
the mapping to a hash result is varied by a second input parameter
that is a cryptographic key” [16]. Thus, the point of a MAC
is to send something that only someone knowing the secret
key can compute and verify. For example, a MAC can be constructed
by concatenating a shared secret K AB with the message
m, and use H(m⎜K AB) as the MAC (where H is a hash
function) [18].
Then, to assure data origin authentication, a sender (A)
and a receiver (B) have to share a secret key K AB. Then the
sender computes the digest (MAC(K AB, m)) corresponding to
the message (m), to be sent using the secret key (K AB) (Fig. 2
step 1). U pon receiving the message as well as the digest, the
receiver verifies the origin of the received message as follows:
it recalculates the digest of the received message using the
secret key K AB (Fig. 1 step 3) and compares it to the received
digest (Fig. 1 step 4). If the two digests are equal, the message
is said to be authentic (has not been altered) and originates
from the sender (A) since only (A) and (B) know the secret
K AB. Otherwise, the received message has been altered or fabricated
by a sender who is not (A). An example of a MAC is
HMAC [10]. Table 2 lists measurements for HMAC.
Yes
?
=
Digest
The
document
has been
modified
Computation speed
Hash algorithm Digest size (bits) (MBytes/s)
MD5 128 204.55
SHA-1 160 72.60
Table 1. Measurements of some hash algorithms.
No
     
     
K AB
Sender (A)
Message
(1)
MAC
Digest
(2)
(2)
K AB
Receiver (B)
Message
MAC
Digest
Digest
Authentic
Not
authentic
FIGURE 2. Assuring data origin authentication using MACs.
(3)
MAC algorithm Digest size (bits) Computation speed
(MBytes/s)
Table 2. Measurements of HMAC.
DATA CONFIDENTIALITY
Definition 5: Data confidentiality is the property by which
information is not made available or disclosed to unauthorized
individuals, entities, or processes [16].
Confidentiality is guaranteed using encryption.
Definition 6: E ncryp tion is a cryptographic transformation
of data (called “ plaintext” ) into a form (called “ ciphertext” )
that conceals the data’s original meaning to prevent it from
being known or used. If the transformation is reversible, the
corresponding reversal process is called decryption, which is a
transformation that restores encrypted data to its original
state [16].
With most modern cryptography, the ability to keep
encrypted information secret is based not on the cryptographic
encryption algorithm, which is widely known, but on a piece
of information called a key that must be used with the algorithm
to produce an encrypted result or to decrypt previously
encrypted information. Depending on whether the same or
different keys are used to encrypt and to decrypt the information,
we distinguish between two types of encryption systems
used to assure confidentiality:
Symmetric-Key Encryption: In a symmetric-key encryption
system, a secret key is shared between the sender and the
receiver and it is used to encrypt the message by the sender
and to decrypt it by the receiver. The encryption of the message
produces a non-intelligible piece of information; the
decryption reproduces the original message (Fig. 3).
Examples of symmetric-key encryption systems are DES
[20], AES [21], and IDEA [18]. Table 3 lists measurements for
commonly used symmetric encryption algorithms.
P u b lic-Key Encryption: Public-key encryption (also called
asymmetric encryption) involves a pair of keys (a public key
and a private key) associated with the sender. Each public key
is published, and the corresponding private key is kept secret
by the sender. Data encrypted with the sender’s public key
can be decrypted only with the sender’s private key (Fig. 4).
In general, to send encrypted data to someone, the sender
encrypts the data with that receiver’s public key, and the receiver
of the encrypted data decrypts it with the corresponding pri-
IEEE Communications Surveys & Tutorials • Third Quarter 2004
(4)
?
=
Yes
HMAC/MD5 128 215.76
No
¡ ¡ ¡¡
¡ ¡ ¡¡
Sender
Message
Encryption
Encryption/decryption key
Encrypted message
Decryption
FIGURE 3. Assuring confidentiality using symmetric-key encryption.
vate key. Compared with symmetric-key encryption, public-key
encryption requires more computation and is therefore not
always appropriate for large amounts of data. However, it is
possible to use public-key encryption to send a symmetric key,
which can then be used to encrypt additional data. An example
of asymmetric encryption systems is R SA [12].
NON-REPUDIATION WITH PROOF OF ORIGIN
Receiver
Message
Encryption algorithm Encryption speed (MBytes/s)
DES 22.19
IDEA 17.65
AES-128 bits 62.04
Table 3. Computation speed of some encryption algorithms.
Definition 7: Non-repudiation with proof of origin provides
the recipient of data with evidence that proves the origin of
the data, and thus protects the recipient against an attempt by
the originator to falsely deny sending the data [16].
N ote that a MAC cannot be used as a proof (to a third
party) that a message originates from a specific entity. In fact,
let us consider that a sender A and a receiver B share a secret
key K AB. If A denies having sent a message m, the receiver B
cannot use the received MAC of m as a proof of m’s origin,
because A would then say that B might have created the m’s
MAC himself! Thus, asymmetric cryptography is the basic
answer for non-repudiation. With asymmetric cryptography,
the piece of information sent with the message as a proof of
integrity and data origin is computed using a private key held
only by the sender and is verified by the receiver using the
public key that corresponds to the private key. Hence, since
only the sender can compute the piece of information, this
latter can be used as a proof of origin to a third party and
hence non-repudiation is assured. This cryptographic mechanism
is called digital signature.
To sign a message, a sender generates a pair of private/public
keys using an asymmetric cryptographic system. The sender
keeps the private key secret and publishes the public key.
Then the sender calculates the digest of the message to be
sent using any hash function (Fig. 5 step 1). The digest is then
cryptographically transformed using the private key (Fig. 5
step 2). The result of this transformation is called the digital
signature of the message. Upon receiving the message and the
signature, the receiver verifies the signature using the public
key as follows. First, the receiver recalculates the digest of the
received message (Fig. 5 step 4). Then the receiver verifies
the received signature using the public key (Fig. 5 step 5). If
the signature is valid then the message as well as its origin are
authentic and non-repudiation is guaranteed. Otherwise, the
message is rejected.
Examples of digital signature schemes are R SA [12] and
DSA [11]. Table 4 lists measurements for commonly used digital
signature systems.
Certification: To verify a signature, a receiver needs to be
assured that the public key used in verifying a signature corresponds
to the private key of the real sender of the signed message
and not generated by an intruder who tries to
impersonate the real sender. The electronic document that
assures this matching is called a public-key certificate.
Definition 8: A pub lic-k ey certificate is a digital certificate
that binds a system entity’s identity to a public key value, and
possibly to additional data items, i.e. a digitally-signed data
structure that attests to the ownership of a public key [16].
Definition 9: Certification is the process of vouching for
the ownership of a public key by issuing a public-key certificate
that binds the key to the name of the entity that possesses
the matching private key [16].
A certificate is digitally signed by a certification authority
(CA) that is trusted by receivers and whose public key is
known by receivers in a secure way. Thus, to publish a public
key a sender should issue a signed certificate of its public key
to receivers. The enclosed public key is used, then, by receivers
to verify the digital signatures generated by the sender whose
identity is also enclosed in the same certificate.
In the rest of the article we assume that the public keys
used to verify digital signatures are certified.
O ne-T ime Sig ning : Conventional digital signature mechanisms
such as R SA and DSA are very computationally expensive.
O ne-time signing is a fast alternative scheme, with the
price of weaker security that limits the use of a pair of onetime
private/public keys to a single message. The general idea
IEEE Communications Surveys & Tutorials • Third Quarter 2004 37
¡ ¡ ¡¡
¡ ¡ ¡¡
¡ ¡ ¡¡
Sender
Message
Public key
Encrypted message
Private key
Receiver
Message
FIGURE 4. Assuring confidentiality using asymmetric-key encryption.
Digital Signing speed Verification speed Public key
signature (ops/s) (ops/s) size (bits)
RSA-1024 215 5263 1024
DSA-1024 467 420 1024
Table 4. Measurements of some digital signature systems.
Private key
(2)
(1)
Sender
Message
Hash
Digest
Signing
Signature
(3)
(3)
Public key
Receiver
Message
Hash
Digest
Signature
verification
Verification
result
FIGURE 5. Assuring non-repudiation using digital signatures.
(4)
Signature
(5)
of a one-time signature scheme is that the private key is used
as the input to a sequence of one-way function evaluations
that result in a sequence of intermediate results and finally in
the public key. The “one-wayness” of the functions implies
that it is infeasible to compute the private key, or any intermediate
result of the computation, from the public key. A signature
for a given message consists of a subset of the
intermediate results of this computation, where the message
to be signed determines which particular subset is revealed as
the corresponding signature [22, 23]. To verify a one-time signature,
a receiver applies a subset of the one-way evaluations
to the one-time signature. If the result of these evaluations is
equal to the public key, then the one-time signature is valid. A
one-time signature scheme allows the signature of only a single
message using a given pair of private/public keys. One
advantage of such a scheme is that it is generally quite fast.
However, it is known that the produced one-time signature is
quite large. Besides, since a pair of one-time (private/public)
keys can be used to sign only a single message, the sender is
required to issue a new public-key certificate each time it
changes this pair of keys. This very frequent need for new
public keys may induce high computation and bandwidth
overheads. A one-time signature scheme was first introduced
by Lamport in [24], and more efficient schemes have been
proposed since then [23, 25–29].
The expression k-time signature is also used to designate a
signature scheme whose pair of private/public keys can be
used with k messages at most.
38
NOTATIONS
Table 5 summarizes the notations used throughout this article.
In what follows, if we do not specify that a signature scheme is
k-time, then we mean a conventional digital signature scheme,
such as RSA.
MULTICAST DATA ORIGIN
AUTHENTICATION ISSUES AND REQUIREMENTS
In this section we state the problem of multicast data origin
authentication and highlight the issues and challenges related
to this security service. Consider a sender that streams data to
a set of receivers in a multicast session. We consider a stream
as an infinite sequence of packets that are sent successively.
Receivers of the multicast session are not trusted. The sender
authenticates a multicast message using some authentication
procedure that generates the authentication information associated
with the message. The message and its authentication
information are multicast to receivers. A receiver verifies the
authentication information using a verification procedure. Figure
6 summarizes multicast data origin authentication requirements
from four perspectives: security, quality of service,
sender’s resources, and receivers’ resources.
Security
• Receivers require the ability to verify the origin of
received data. This requirement is called data origin
authentication.
• Any subset of receivers must be unable to collude in
order to impersonate the sender of data. This requirement
is called collusion freedom.
• The sender must be unable to deny having sent data to
the multicast session. This requirement is called nonrepudiation.
Quality of Service
• The authentication information must induce a low band-
¢ ¢ ¢¢
H(m) The h ash code (digest) produced by the h ash
function H applied to the message m.
MAC(k,m) The Message Authentication Code (MAC)
produced by the MAC function MAC applied to the
message m using the sy mmetric key k.
S SK(m) The conventional digital signature produced by the
signature algorithm S applied to message m using
the sender’s private key SK.
V PK(m,s) The conventional signature verification process V
applied to message m and its signature s using the
sender’s public key PK.
σ s k k (m) The k-time signature produced by the k-time
signature algorithm σ applied to message m using
the sender’s k-time private key sk. If k is omitted,
we then consider one-time signing.
a⎪b Means that a is concatenated to b.
Table 5. Cryptographic notation.
width overhead.
• Since most multicast media-streaming applications use
unreliable packet delivery, multicast data origin authentication
mechanisms must be robust against packet loss.
• Since most multicast media-streaming applications
require real-time transmission, multicast data origin
authentication must not induce latencies at the sender
before authenticating stream packets, nor at receivers
before verifying the authenticity of received packets.
Sender’s Resources
• The generation of the authentication information must
induce low computation and/or memory overheads, so the
multicast data origin authentication scheme can be
implemented with resource constrained devices.
Receivers’ Resources
• The verification of the authentication information must
induce low computation and/or memory overheads, so
that the multicast data origin authentication scheme can
be implemented with resource constrained devices.
In the following sections we will see that none of the proposed
solutions satisfies all of these requirements, but each
proposed approach tries to make the best trade-off from a
specific point of view.
TAXONOMY OF MULTICAST
DATA ORIGIN AUTHENTICATION PROTOCOLS
In Fig. 7 we classify existing multicast data origin authentication
protocols depending on the security objective in a first
stage. Thus we distinguish between two major classes of
existing protocols: those that assure data origin authentication
and non-repudiation, and those that assure data origin
authentication but not non-repudiation. Then we refine the
classification according to the common underlying solution
concept. Throughout this article we will present each class of
this taxonomy and illustrate it with relevant solutions. Each
solution is then presented and its advantages and drawbacks
are discussed. Eventually, works that extend or improve
these solutions are also presented. At the end of the presentation
of each class, we compare and discuss the solutions
relating to the class with respect to some relevant performance
criteria.
IEEE Communications Surveys & Tutorials • Third Quarter 2004
£ £ ££
MULTICAST DATA ORIGIN AUTHENTICATION
WITHOUT NON-REPUDIATION
To assure data origin authentication for a given message, a
receiver has to share a secret with the sender. This secret is
involved in computing the authenticator of the message, and it
is used to verify this authenticator by the receiver. Data origin
authentication is guaranteed because only the sender and the
receiver know the secret. In multicast data origin authentication,
a straightforward solution is to make the members of the
multicast group share a secret key with the sender. To authenticate
a multicast message, the sender computes the MAC of
the message using this key and multicasts it along with the
message. Upon receiving the message and its MAC, receivers
verify data origin authentication by verifying the received
MAC using the secret key. The problem with this naive solution
is that all group members know the secret key and hence
everyone can impersonate the valid sender and forge the
MACs of messages on the sender’s behalf. Therefore, to
assure multicast data origin authentication, the authentication
information must be asymmetric. By asymmetric we mean that
receivers can verify authentication information but cannot
generate it.
Existing solutions considered three major approaches to
introduce asymmetry in authentication information.
•In one approach, multicast messages are authenticated
using a set of secrets instead of a single secret as in the above
naive solution. Each receiver knows a share of these secrets,
which allows him to verify the authenticity of received messages.
In this approach, knowledge of the whole secret is necessary
to generate valid authentication information. Hence,
receivers cannot forge authenticators of messages on behalf of
the valid sender. This approach corresponds to the sub-category
called secret-information asymmetry in the taxonomy
depicted in Fig. 7.
£ £ ££
Security
requirements
1) Source
authentication
2) Collision
freedom
3) Nonrepudiation
FIGURE 6. Multicast data origin authentication requirements.
Security objective
Protocol concept
Secret information
asymmetry
Multicast source
authentication requirements
QoS
requirements
1) Real-time
transmission
2) Tolerance to
packet loss
3) Low
bandwidth
overhead
Desmedt et al.
Safavi and Wang
Fujii et al.
Obana and Kurosawa
Canetti et al.
Sender
requirements
1) Efficient
generation of
authentication
information
Bergadano et al.
TESLA
µ TESLA
Receiver
requirements
1) Efficient
verification of
authentication
information
BiBa
Powerball
Better than BiBa
FIGURE 7. Classification of data origin authentication protocols.
•In a second approach, the sender changes the secret key
used to authenticate multicast messages periodically. Thus,
the validity of a secret key is limited within an interval of
time. Then the sender guarantees that the key used to authenticate
the messages, corresponding to an interval of time, is
known by the receivers only after all of them have received
the authenticated messages using this key. Hence, an attacker
cannot use this key to forge a message on behalf of the
sender, because receivers (which are synchronized with the
sender) know that all messages authenticated using this key
are supposed to be received. This approach corresponds to
the sub-category called time asymmetry in the taxonomy
depicted in Fig. 7.
•In a third approach, asymmetry is based on both time and
the secret information, so that disadvantages of both
approaches are eliminated. This approach corresponds to the
sub-category called hybrid asymmetry in the taxonomy depicted
in Fig. 7.
In the following sections we discuss and illustrate each subcategory
with relevant solutions from the literature.
SECRET-INFORMATION ASYMMETRY
In this approach, the sender uses a set of secrets to authenticate
a multicast message and gives to each receiver a partial
view of the used secrets that allow him only to verify authenticity
of received messages without being able to generate
valid authentication information for messages.
Example: Consider a group of n receivers. To assure
multicast data origin authentication for a given message m,
the sender shares a secret key K i with each receiver i.
Thus, the sender knows n secret keys: { K i , 1 ≤ i ≤ n} ,
and each receiver i knows only its secret key K i. To authenticate
a message m, the sender computes n MACs using the
n secret keys, and concatenates them to the message:
MAC(K n, m)⎜… ⎜MAC(K 1, m)⎜m. Then the sender multicasts
the message along with the n computed MACs. Upon receiving
them, each receiver i verifies the authenticity of m using
its secret key K i and the corresponding MAC: MAC(K i, m).
To forge a message on behalf of the valid sender, a fraudulent
receiver has to acquire secret keys of the other members to
compute valid MACs.
On the one hand this naive solution is not scalable, because
the size of a message authenticator is proportional to the
number of receivers (n × ⎜MAC ⎜, where n is the number of
receivers and ⎜MAC ⎜ is the size of a MAC). On the other
hand, this solution is perfectly resistant to collusions, which
means that even if n – 1 fraudulent receivers out of n receivers
collaborate, they cannot forge a valid message authenticator
Data origin authentication
Without non-repudiation With non-repudiation
Time-asymmetry
Hybrid-asymmetry Signature propagation
Off-line signing
On-line signing
EMSS
P-random graph
Periodic chaining
Piggybacking
Signature dispersal
Tree chaining
SAIDA
Pannetrat et al.
Differed signing
Off-line/on-line signing
Off-line/on-line k-time
Signing
IEEE Communications Surveys & Tutorials • Third Quarter 2004 39
¤ ¤ ¤¤
to a receiver on behalf of the valid sender. In order to cope
with the scalability issue, we can imagine that the sender uses
a secret key per subset of receivers instead of using a secret
key per receiver. In other words, receivers are subdivided into
p subsets. Each subset of receivers shares a secret key with the
sender. To authenticate a message, the sender now computes
only p MACs (p < n) and concatenates them to the message.
Upon receiving the message and the MACs, each receiver
uses its secret key that it shares with other receivers to verify
the authenticity of the received message. With this scheme,
the authenticator size is reduced to p × ⎜MAC ⎜ with p constant.
But this scheme is sensitive to collusions. In fact, if
there are fraudulent receivers in different subsets, by exchanging
their known secret keys they can forge message authenticators
to the other receivers in their subsets on behalf of the
valid sender. From these two simple examples we can see that
there is a trade-off between resistance to collusions and the
size of the authentication information. Existing solutions
attempt to minimize the size of the authentication information
on the one hand, and to tolerate the largest possible collusion
on the other hand. We distinguish between the
following two sub-categories depending on the desired level of
security
•A first approach consists of unconditionally secure authentication
where it is imperative that the security of the authentication
scheme is not based on unproven assumptions. Thus,
absolute security is guaranteed by making sure that there is
not enough information to enable attacks. Protocols of this
approach rely on the theoretic strength of the information.
•A second approach consists of conditionally secure authentication
where an attacker is assumed to have finite resources
and hence cannot make an attack that require complex computations
that exceed its computation capacities. Figure 8
summarizes this taxonomy refinement.
We now present solutions that fit into each sub-category
respectively.
40
Protocol
concept
Level of
security
Protocols
Polynomialbased
asymmetry
Desmedt et al.
Safavi and
Wang
Unconditionally
secure multicast
authentication
Cover-free
set systems
Fujii et al.
Obana and
Kurosawa
Secret information
asymmetry
Conditionally
secure multicast
authentication
Multiple
MACs-based
asymmetry
Canetti et al.
FIGURE 8. Classification of data origin authentication protocols
based on secret information symmetry.
UNCONDITIONALLY SECURE MULTICAST AUTHENTICATION
Desmedt, Frankel, and Y ung [30] introduced k out of n multireceiver
authentication schemes ((k, n) MRA) as follows [30]:
Definition 10: An authentication scheme is a k out of n
multi-receiver authentication schemes, when any k out of n
receivers cannot commit a substitution or impersonation
attack on even a single receiver.
A substitution attack is committed when a receiver accepts
a message that has been altered by the attacker in the course
of transmission; an impersonation attack succeeds when a
receiver accepts a message from an attacker on behalf of a
legitimate sender. In other words, in a k out of n authentica-
tion scheme, the largest coalition of cheating receivers can
have k – 1 members out of n receivers.
Desmedt et al. Protocol
Overview: Desmedt et al. [30] proposed a polynomial based
scheme to assure a k out of n multicast authentication. The
main idea of the proposed scheme is that the source generates
a polynomial A M(x) of degree k, using the message M to be
sent. Then the source sends to each receiver a share of the
polynomial, in such a way that to forge an authenticator of a
message it is required to use at least k shares of the polynomial
to reconstruct it using interpolation technique. Since the
largest coalition of cheating receivers can have only k – 1
members, the security of the system holds. The following steps
describe the proposed protocol.
1) The sender chooses a large prime p where p is equal or
greater than the number of possible messages. All the
following operations are done in the finite field Z p (integers
modulo p).
2) For each message M the sender creates two polynomials
P 0( x) and P′( x) of degree k.
3) The sender privately transmits the shares P 0(i) and P ′(i)
to each receiver (i).
4) The sender generates the authenticator (polynomial) of
the message M: A M ( x) = P 0( x)+M × P ′( x) and multicasts
it to receivers.
5) The receivers verify the authenticator by testing if A M(i)
= P 0(i) + M × P ′(i) .
In [30] the authors proved that this protocol is a k out of n
unconditionally secure authentication scheme.
A d va n ta g es a n d D ra wb a c k s : This protocol deserves to be
considered a pioneer by introducing multicast data origin
authentication using unconditional security. It is clear that this
scheme tolerates packet loss, since each packet carries its own
authentication information and hence can be verified independently
from other packets as soon as the packet is received.
Desmedt et al. showed that the proposed scheme requires the
receivers to store 2 × ⎡log 2 p⎤ bits and the sender to store 2 × (k
+ 1) × ⎡log 2 p⎤ bits. Each message has an authenticator of size
(k + 1) × ⎡log 2 p⎤ bits. The authors also proved that k receivers
cannot perform an impersonation or substitution attack with a
probability greater than 1/ p ( p is chosen large enough so that it
is hard for the attacker to make a good guess). S. Obana and K .
K urosawa [31, 32] derived lower bounds on the cheating probabilities
(substitution and impersonation) and the sizes of keys of
k out of n multi-receiver authentication schemes and showed
that the scheme proposed by Desmedt et al. meets all their
bounds with equality, which means that this scheme is optimum.
Nevertheless, this scheme is not practical for most mediastreaming
applications (which are subject to time delivery constraints)
since the sender has to generate and distribute
polynomial shares for each message for each receiver. However,
this is the price to pay for unconditional security.
E x ten s io n s a n d Im p ro vem en ts : Safavi-Naini and Wang [33,
34] generalized the Desmedt et al. polynomial scheme in such
a way that instead of a single message, each polynomial can
be used to authenticate multiple messages. The authors then
proposed to construct k out of n authentication schemes using
cover-free set systems. The main idea of the cover-free set system
is that given a set of keys used by the sender to authenticate
messages, how can the subsets of these keys to receivers
be affected in such a way that j (j < k) fraudulent receivers
cannot collaborate using their subsets of keys to cover the
keys’ subset of a group member. Similarly, Fujii et al. [35] proposed
unconditionally secure broadcast authentication
schemes based on cover-free set systems. The authors gave
IEEE Communications Surveys & Tutorials • Third Quarter 2004
¥ ¥ ¥¥
K 0
Generate
H(K1) H(K2) H(Kk-1) H(Kk) K1 K2 Kk-2 Kk-1 Kk Use/reveal
FIGURE 9. Generating MAC keys using a hash chain.
combinatorial bounds and proposed constructions that meet
those bounds.
CONDITIONALLY SECURE MULTICAST AUTHENTICATION
Conditional security assumes that an attacker does not have
sufficient computational resources to guess secret keys, used
to authenticate messages, in a reasonable time. Proposed
solutions within this category rely on the fact that it is difficult
to guess a valid MAC for a message without having the secret
key used by legitimate communicating parties.
Canetti et al. Protocol
Overview: The main idea behind the protocol proposed by
Canetti et al. in [5] is that the sender appends to each multicast
message M, l MACs using l different keys. Each receiver
holds a subset of keys among the l sender’s keys and verifies
the authenticity of received messages using its subset of keys.
For an adversary to forge a message of the valid sender, it
needs to acquire the l keys from a coalition of w receivers.
The cornerstone of the solution is that an appropriate choice
of receivers’ subsets of keys ensures that with high probability
no coalition of up to w colluding bad members (where w is a
parameter) knows all the keys held by a good member, thus
maintaining authenticity.
We denote by S the source of the transmissions and by u a
receiver in the multicast group. The basic scheme proceeds as
follows:
• S maintains a set R of l keys, R = {K 1, … , K l}.
• Each receiver knows a subset of this set of keys: receiver
u knows the subset R u ⊂ R.
• When S sends a message M it first authenticates it with
each of the l keys that it maintains, using a MAC. Then
it sends the message M along with MAC(K 1, M)⎜MAC(K 2,
M)⎜… ⎜MAC(K l, M).
• Each receiver u verifies all the MACs that were created
using the keys of its subset R u. If any of these MACs is
incorrect then u rejects the message.
The strength of this solution depends on the probability
that the key subsets of a fraudulent coalition completely cover
the key subset R u of a given user u. In order to upper-bound
this probability by a certain constant q, the authors suggested
that the sender uses l = 4e wln1/q keys, where w is the size of
the largest coalition, and that each key is chosen to a user’s
subset with probability 1/(w + 1). According to this construction,
the authors proved that if the probability of computing
the output of a MAC without knowing the key is at most q′,
then the probability that a coalition of w corrupt users can
authenticate a message M to u is at most q + q′.
A dv antages and Draw back s: The proposed solution allows
a relatively efficient generation and verification of the authentication
information since it relies only on MAC’s computations,
which are efficient to generate and verify. The authors
propose to use MACs with a single bit as output. Hence, the
authentication information is reduced to l bits. Boneh, Dur-
fee, and Franklin showed in [36] that the Canetti et al. construction
has optimal length (up to a small constant factor) for
an authenticator that is based purely on pseudo random functions.
Each packet carries its authentication information and
hence each packet is individually verifiable. Thus, the solution
tolerates packet loss. The main drawback of this solution is
that it remains vulnerable to collusions of bad members.
TIME ASYMMETRY
This approach consists of limiting the lifetime of keys used to
authenticate multicast packets, in a way that if an attacker
uses a key to compute message authentication information on
behalf of the valid sender, receivers reject its message because
the key would have expired. Therefore, the sender generates
the keys periodically to authenticate multicast packets by
interval of time. The following solutions deal with authenticating
the keys themselves and how to generate those keys, so
that even if some keys are lost the required keys are recovered
from received keys to authenticate received packets. A
common mechanism used by the proposed solutions is oneway
key chains. The following paragraph describes how such a
key generation mechanism makes it possible to authenticate
the keys themselves and how to recover lost keys from
received ones.
One-W ay Ch ains: In order to use a MAC to authenticate a
multicast message, the sender has to communicate a secret
key to receivers in a secure way. Otherwise, any attacker can
send a key to receivers and pretend to be the valid sender,
then start to send messages on the sender’s behalf. Multicast
streaming requires the secure transmission of keys to be fast.
Therefore, it is not affordable to sign each secret key. The
main idea of one-way chains is to certify (using a digital signature,
for example) only a single secret. This certified secret is
the culmination of recursive one-way computations that form
a chain of secrets. Thus the single certification makes it possible
to certify the whole one-way chain of secrets. Figure 9
shows the one-way chain construction. To generate a chain of
length k, the sender randomly picks the last element of the
chain K k. Then it generates the chain by repeatedly applying
the one-way function H. Finally, K 0 is the secret that should
be sent securely (certified) to receivers. Then the secrets
are revealed in the inverse direction. To verify whether
a received secret K i is valid (i.e., that it actually originates
from the valid sender), the receiver of the secret checks that
H i (K i) = K 0. Generally, given that K j is valid, a received
secret K i is valid if H i–j (K i) = K j. Moreover, if a secret K i is
lost, once a subsequent secret of the chain Kf (f > i) is
received, the lost secret K i can be recovered by: K i = H
(K f) .
Lamport [37] and Haller [38] used one-way chains in onetime
password systems. In our case the secrets of the chain
correspond to MAC-keys and hence we use the expression
one-way key chains to designate this key-generation mechanism.
Proposed solutions that use this mechanism take advantage
of the fast manner in which one-way chains make it
possible to verify keys’ authenticity as well as the fact that lost
keys can be recovered once a valid subsequent key is received.
Note that the “one-wayness” of the function H, used in the
one-way chain construction, prevents receivers from generating
valid future keys given a valid key.
Bergadano et al. Protocol
Overview — The essence of the solution proposed by
Bergadano et al. in [39] is to authenticate each packet of data
IEEE Communications Surveys & Tutorials • Third Quarter 2004 41
f – i
¦ ¦ ¦¦
with a MAC using a key generated using a one-way key chain.
The recursive relation between keys makes it possible to
recover lost keys and to verify the validity of received keys.
The MACed packets as well as the keys used in calculating
their MACs are multicast to receivers. To avoid a fraudulent
receiver using a received key to forge a data packet on behalf
of the legitimate sender, the sender guarantees that keys are
known by receivers only when all receivers have received the
packets authenticated with their respective keys. Therefore,
receivers are synchronized with the sender’s clock and instructed
to reject any data packet whose MAC arrives late.
The sender uses two processes: a data sender and a key
sender.
• The data sender broadcasts data information A i,
MAC(α k– i, A i) after each period of time T.
• The key sender also broadcasts the keys α k– i after each
delay+T period of time. The delay is required to assure
that data packets arrive at all receivers before their
respective keys.
Receivers consume data and verify authenticity in two separate
processes. When a receiver receives data information, it
waits for the key to decide on the authenticity of the received
data .
Advantages and Drawbacks: It is clear that this solution
minimizes considerably the size of the authentication information,
since only a single MAC is required to authenticate a
packet of the stream. Packet loss is also tolerated since losing
a key, a MAC, or a data packet does not obstruct the authentication
of subsequent packets of the stream. However, if significant
jitters exist in the network, the authenticity status of
some packets may be unknown. Indeed, if a key is late, its corresponding
packet is marked with the label unknown authentication
since the delay could be due to forging a packet and its
MAC by an intruder using an eavesdropped key. Hence synchronizing
receivers with the sender’s clock remains the main
drawback of the solution. Besides, the length of the one-way
key chain is limited, and hence to use this solution with infinite
streams, the sender would commit to a new one-way keychain
and announce it periodically. This periodic
announcement induces a new overhead that consists of a digital
signature over the first MAC key (and other required
information) of the announced chain.
The TESLA Broadcast Authentication Protocol
Overview: Perrig et al. have proposed the TESLA (Timed
Efficient Stream Loss-tolerant Authentication) protocol in
[40, 41]. The main idea of TESLA is that the sender uses a
different key in each interval of time to authenticate multicast
messages sent within this interval of time. TESLA uses oneway
key chains to generate the MAC keys. A secret MAC key
used to authenticate multicast messages sent within a period
of time is kept secret by the sender, to avoid an attacker
receiving the key before other receivers and using it to forge
42
K i-1
K' i-1
H(K i)
H'(K i-1)
K i
K' i
Interval i-1 Interval i Interval i+1 Interval i+2 Time
FIGURE 10. TESLA protocol.
H(K i+1) H(K i+2) H(K i+3)
H'(K i)
K i+1
H'(K i+1)
K' i+1
K i+2
H'(K i+2)
K' i+2
P j P j+1 P j+2 P j+3 P j+4 P j+5 P j+6
authenticated messages on behalf of the valid sender. When
the period of time corresponding to the use of this key elapses,
the sender discloses the key used to authenticate messages
within this elapsed period. Then receivers use this disclosed
key to verify the authenticity of the previously received messages.
If an attacker uses this key to forge a message on
behalf of the sender, receivers will reject its message because
they have their clocks synchronized with the sender’s clock
and they know then that the sender would have committed to
another key corresponding to the following interval of time.
Figure 10 shows how TESLA generates and discloses MAC
keys used in authenticating broadcast packets.
At the top of the figure is the one-way key chain (using the
one-way function H), and the derived MAC keys (using the
one-way function H ′). Time advances left-to-right, and the
time is split into time intervals of uniform duration. At the
bottom of the figure we can see the packets the sender sends
in each time interval. For each packet the sender uses the key
that corresponds to the time interval to compute the MAC of
the packet. For example, for packet P j + 3, the sender computes
a MAC of the data using key K ′ i+1. When a receiver
receives packets corresponding to an interval of time, it
buffers them and waits for the first packet of the following
time interval (key disclosure). This packet will carry the key
used to authenticate the buffered packets and hence allows
their verification. In Fig. 10, assuming a key disclosure delay
of two time intervals (d = 2), packet P j+3 would carry key
K i–1 which will allow the verification of P j.
Advantages and Drawbacks: With TESLA, the authentication
information size is reduced to the size of one MAC. In
contrast to the Bergadano et al. protocol, TESLA discloses
only a single MAC key per period of time. The MACing at
the sender and the verification at receivers are very efficient.
Packets can be individually authenticated and hence the protocol
tolerates packet loss. Besides, if a key is lost the chaining
used in their construction makes it possible to recover a
lost key from subsequent keys. The main drawback of TESLA
is its synchronization requirement between the source and
receivers, which creates a new potential security hole for
adversaries. Besides, if different users experience large differences
in network propagation delays, many TESLA instances
should be run to satisfy all those receivers in terms of synchronization.
Notice also that TESLA requires that received packets
be buffered until their corresponding keys are disclosed
and hence cannot be used with resource-constrained devices
or applications that require real-time transmission.
Extensions and Improvements — Perrig et al. also proposed
in [42] extensions to TESLA in order to cope with some of its
drawbacks. Namely, the authors proposed a modification that
allows receivers to authenticate most packets as soon as they
arrive by the mean of a slight increase in the size of the
authentication information. They also proposed other modifications
that improve the scalability of the scheme in the case
where different receivers have different network propagation
delays. Perrig et al. proposed in [43] a light version of TESLA
called µTESLA which is more suitable for ad hoc sensor networks
that are known to be severely resource-constrained
environments.
HYBRID ASYMMETRY
The advantage of the secret information asymmetry approach is
that packets are verified as soon as they are received. The
main drawback of this approach is that it is sensitive to collu-
IEEE Communications Surveys & Tutorials • Third Quarter 2004
§ § §§
S 1 S 2 S 3 S 4 S t
Signature
FIGURE 11. BiBa one-time signature.
sions of k fraudulent receivers out of n receivers. In contrast,
the advantage of the time asymmetry approach is that collusions
are impossible because a disclosed key would be useful
only for verification. Its main drawback is the requirement of
buffering packets before verification. The main idea of the
proposed solution within this sub-category is to eliminate the
drawbacks of both of these approaches by mixing their underlying
asymmetry mechanisms.
The BiBa One-Time Signature and Broadcast Authentication
Protocol
Overview: The main idea proposed by Perrig [28] is that the
sender uses a set of keys to authenticate messages. When the
sender authenticates a message it discloses only a subset of
keys that allow the verification of the packet’s authentication
information without being able to generate it. Hence, the
authenticity of packets is verified as soon as packets are
received, and this complies with the secret information asymmetry
approach. But if the same set of keys is used to authenticate
a certain number of packets, each receiver would
acquire the whole set of the sender’s keys after some subset
disclosures, and hence would be able to forge messages on
behalf of the valid sender. To avoid that, the sender changes
the set of keys that it uses to authenticate messages periodically,
before receivers would know all of them. The key generation
uses a one-way key chain mechanism so that receivers
can verify their authenticity and can recover them whenever
some of them are lost. This complies with the time asymmetry
approach. Thus, the proposed scheme is a hybrid of the two
approaches presented above, eliminating the drawbacks of
both of them.
Perrig [28] achieved this hybrid asymmetry using a new
one-time signature scheme called Bins and Balls (BiBa). In
the following section we present the BiBa one-time signature
scheme, then show how it is extended for the case of broadcast
data origin authentication.
B iba One- time S ignatu re: In this section balls are random
numbers that can be seen as keys and bins are numbers within
the range [0… n – 1] of a family of hash functions G. Each
hash function within the family G is indexed by a number h
and denoted by G h. Therefore, we can see hashing the balls
using a hash function G h as throwing the balls into the bins.
Suppose that the number of balls is very high compared to the
number of bins. Thus, there is a high probability that when we
throw the balls into the bins at least two balls fall into the
same bin. This is the informal concept underlying BiBa onetime
signing. Indeed, with the BiBa scheme the balls are held
by the sender. The message to be signed parameterizes the way
the sender throws the set of balls into the bins, and the balls
that fall into the same bin form the signature of the message.
Then the sender sends the message along with its signature,
which consists of the small subset of balls that fell into the
same bin. Therefore, an adversary may have only this small
number of balls that form the signature and hence there is a
low probability that a signature for a new message can be
forged using this small subset of balls. Indeed, Perrig [28]
showed that if the number of thrown balls decreases, then the
G h
probability that two balls fall into the same bin decreases
exponentially. In the following sections we consider balls with
the property that a receiver can verify their authenticity
instantly using the corresponding public key, and we assume
that the public key used to authenticate the balls is transmitted
to receivers in an authentic way, and that the public key
cannot be used to generate valid balls.
Example: Consider a scheme with t balls {S 1, …, S t}, and n
bins. The balls correspond to random numbers that can be
considered as keys, and the bins correspond to the range [0…
n – 1] of the used hash functions.
• To sign a message m, the signer first computes the hash
h = H(m ⎜c), where c is a counter value that the signer
increments if it cannot find a signature.
• The signer then applies the hash function G h to all the
balls S 1, S 2, … , S t (where G h is an instance of a hash
family G selected with the indicator h).
• The signer looks for a two-way collision of tow balls:
G h(S i) = G h(S j) and S i ≠ S j, (Fig. 11).
• If the two-way collision does not happen, the signer
increments the counter c and resumes the process from
the beginning.
• The signature is formed by the two-way collision balls
<S i, S j> concatenated to the counter c.
• The verifier receives message m and the BiBa signature
< S i , S j > ⎜c. To verify the BiBa signature the verifier
computes h = H(m ⎜c), checks that S i ≠ S j , and G h(S i )
= G h(S j).
To increase the security, the proposed scheme considers kway
collisions instead of two-way collisions.
B iB a B roadcast Au th entication P rotocol: To authenticate
a stream of messages, each message is authenticated using the
BiBa scheme presented above. Thus, k out of t balls are disclosed
as a signature of each message, and receivers verify the
signature as soon as it is received along with the message.
Therefore, after a certain number of disclosures due to signing
consecutive messages of the stream, receivers would know
all the balls and hence would be able to forge messages on
behalf of the sender. To avoid that, the sender commits to a
different set of balls after each period of time. The sets of t
balls are generated using t one-way key chains. Figure 12
shows the time periods and the corresponding rows (sets) of t
balls. At each period of time i the sender uses the row of t
balls: S < l , i> {1 ≤ i ≤ t} to one-time sign messages sent in that
time period i. When the sender one-time signs a message, it
discloses only the k balls that correspond to its one-time signature
(k-way collision). At the end of a time period the
sender commits to the following row of t balls.
In order to prevent a fraudulent receiver from reconstructing
an entire row of balls and hence being able to forge onetime
signatures, the sender should not disclose more than a
certain threshold of balls per interval of time. If the packets’
arrival rate exceeds this threshold, the sender would have to
run multiple BiBa instances simultaneously, and disclose balls
from these different instances in round robin.
Advantages and Drawbacks: BiBa tolerates packet loss
since each packet is accompanied with its BiBa signature independently
from other packets, and even if some balls that constitute
the signature are lost, they can be recovered from
subsequent received balls using the one-way chain. BiBa is not
vulnerable to collusions of fraudulent receivers since the
sender commits to a new set of balls after each period of time.
The BiBa one-time signature scheme has a one-time signature
size that is much smaller than most other one-time signatures.
Indeed, a BiBa signature is reduced to k balls, where k is on
IEEE Communications Surveys & Tutorials • Third Quarter 2004 43
¨ ¨¨¨
the order of 10 to 16 bits and a ball’s size is on the order of 64
bits. However, BiBa’s public keys are larger than most other
systems. Indeed, a public key consists of a row of t balls in
addition to a key, where t is on the order of 1024 bits and a
ball is on the order of 64 bits. Thus a public key size is on the
order of 10 Kbytes. Moreover, since the sender cannot disclose
more than a certain threshold of balls per period of time
(to prevent a fraudulent receiver from reconstructing an
entire row of balls), the sender has to use multiple BiBa
instances to meet the application rate requirement. Thus
sending many public keys of 10 Kbytes each to all receivers
could cause a bottleneck at the sender. Also, the time required
to generate signatures is also high. Each signature generation
requires 2 × t + 1 hash computations, where t is on the order
of 1024 bits. The BiBa broadcast authentication protocol
requires that the sender and receivers be time synchronized so
that receivers know which disclosed balls to use in verifying
signatures.
Extensions and Improvements: Mitzenmacher and Perrig
[27] proposed an improvement of the BiBa one-time signature
scheme called Powerballs. The authors showed that Powerballs
is worth almost another ball; that is, using x Powerballs is
almost as secure as requiring x + 1 balls to fall into a bin
using the original BiBa scheme. Leonid Reyzin and Natan
Reyzin [29] also proposed a one-time signature scheme based
on one-way hash functions that is as fast as BiBa in verifying.
Signing is even faster than verifying and the key and signature
sizes are slightly improved. Thus, the proposed one-time signature
scheme maintains the advantages of BiBa’s one-time
signature scheme and eliminates its main disadvantages.
44
F
S <1,i>
F
S <1,j-1>
F
S <1,j>
COMPARISON AND DISCUSSION
The efficiency of a data origin authentication protocol can be
measured according to many criteria. Tables 6 and 7 compare
some data origin authentication protocols (without non-repudiation)
with respect to the following criteria sets (respectively).
Security Strength:
F
S <2,i>
F
S <2,j-1>
F
S <2,j >
F
F
F
Time
Time
period i
Time
period j-1
Time
period j
FIGURE 12. BiBa broadcast protocol. F is a pseudo random
function.
F
S <t,i>
F
S <t,j-1>
F
S <t,j>
• Security level: corresponds to the fact that the authentication
scheme relies on a theoretic security model (unconditional
security) or on a computational security model
(conditional security).
• V ulnerability to collusions: corresponds to the fact that the
authentication scheme fails under a collusion of bad
users.
Quality of Service:
• The latency at the source: corresponds to the fact that the
source needs to buffer packets before sending them.
• The latency at a receiver: corresponds to the fact that a
receiver needs to buffer packets before authenticating
them.
• Tolerance to packet loss: corresponds to the fact that the
authentication process is possible even if some packets
are lost.
• Authentication information size: the size of the authentication
information embedded to a packet.
• Synchronization required: corresponds to the fact that
receivers need to be synchronized with the source.
Let us now make a vertical analysis of the proposed protocols,
by discussing the suitability of each protocol with respect
to relevant practical requirements.
Robustness Against Packet Loss: Most media-streaming
applications do not use a reliable transport layer. Therefore, it
is important that multicast data origin authentication protocols
tolerate loss of some packets of the stream, so that even
if some packets are lost, received packets’ authenticity can be
verified. Fortunately, most of the protocols that assure multicast
data origin authentication (without non-repudiation) tolerate
packet loss, because each packet carries its own
authentication information independently from other packets.
This can be justified by the fact that the proposed protocols
(except those in the unconditionally secure authentication category)
rely on fast cryptographic mechanisms to assure data
origin authentication. Namely, Canetti et al., Bergadano et al.,
and TESLA use MACs; BiBa uses one-time signatures.
Therefore, the sender can afford the computation of the
authentication information for each packet to be individually
verifiable. Unconditionally secure broadcast authentication
schemes such as the polynomial-based scheme proposed by
Desmedt et al. also tolerate packet loss. However, the computation
required to generate the authentication information for
each packet is very complex, but this is the price to pay for
unconditional security.
Real-time Transmission: Some applications, such as videoconferencing,
do not tolerate important delays in generating or
verifying the authentication information. Thus, the unconditionally
secure authentication approach cannot be used with
¨ ¨¨¨
Vulnerability
Protocol Security level to collusions
Desmedt et al. U nconditional security Yes
Canetti et al. Protocol Conditional security Yes
Bergadano et al. Protocol Conditional security No
TESLA Conditional security No
BiBa Conditional security No
Table 6. Comparison of data origin authentication protocols
with respect to security strength criteria.
IEEE Communications Surveys & Tutorials • Third Quarter 2004
© © ©©
Latency at Latency at Tolerance to Synchronization
Protocol the source receivers packet loss Authentication information size required
Desmedt et al. (k, n) — No No Yes (k + 3) × ⎡log 2p⎤ bits, where p is a large prime No
MRA equal or greater than the number of messages
Canetti et al. Protocol No No Yes l bits, where l depends on the size of the No
largest fraudulent receivers coalition
Bergadano et al. Protocol No Yes Yes ⎜MAC ⎢ + ⎜k m ⎜ Yes
TESLA No Yes Yes ⎜MAC ⎜ [+ ⎜k m ⎜], where k m is disclosed only Yes
once per period of time
BiBa No No Yes k × ⎜ball ⎜ + ⎜counter ⎜[+⎜k m ⎜], where k is on Yes
the order of 15, ⎜ball ⎜ in the order of 64 bits
k m: denotes a MAC key. ⎜x⎜: denotes the size of x.
Table 7. Comparison of data origin authentication protocols with respect to selected QoS criteria.
this kind of application. Indeed, the complexity of the underlying
computation (in both generation and verification) as well
as the requirement of distributing new keys for each small
number of packets introduce important delays at both the
sender and receiver sides. TESLA and the solution proposed
by Bergadano et al. suffer from the fact that receivers should
buffer received packets until the corresponding verification
key is disclosed by the sender. Thus, receivers experience
some delay before being able to verify received packets. 3 One
promising solution is the protocol proposed by Canetti et al.,
since the authentication and the verification are restricted to
instant (without delay) MAC computations . However, this
solution can be used only in environments where coalitions of
up to a certain number of fraudulent receivers are impossible.
This would be the case, for example, with most video-conferencing
applications where participants are trusted and known
beforehand. Another prominent solution is BiBa. With BiBa,
the authentication information is generated and verified
instantly (without waiting for other information) and it is not
vulnerable to collusions. However, the process of generating
the authentication information is relatively slow (compared to
the Canetti et al. solution, for example) since it requires about
2 × t hash computations, where t is on the order of 1024 bits.
Bandwidth Consideration: Bandwidth is a worthy resource
in communication, especially in some environments such as
wireless networks. In this case, it is important that the size of
the authentication information be as small as possible. With
respect to this criterion, the best proposed solution (to our
knowledge) is TESLA. Indeed, the bandwidth overhead
induced by TESLA is reduced to one MAC (on the order of
128 bits using MD5), in addition to one key disclosure per
period of time. The solution proposed by Bergadano et al. has
almost the same bandwidth overhead (one MAC per packet),
but it also has one key disclosure per each packet. Nevertheless,
as we saw before, these solutions require that receivers
be synchronized with the sender and important jitters in the
network may result in rejecting some authentic data. Another
solution with relatively low bandwidth and without the latter
drawback is the protocol proposed by Canetti et al., which
relies on the asymmetry of multiple MACs. The bandwidth
overhead induced by this protocol is l MACs per packet,
where l depends on the size of the largest coalition of fraudu-
3 We note that Perrig et al. proposed a new version of TESLA in [42] to
overcome this limitation but then introduce some complexity in the chaining
process and increase slightly the bandwidth required by the authentication
information.
lent receivers that can exist in the session. In their example,
Canetti et al. showed that l can be chosen on the order of 190
MACs of 10 bits in a basic scheme, 380 MACs of 10 bits in
the improved security scheme, or on the order of 760 MACs
of 1 bit in the lower communication overhead scheme. Again,
this solution can be promising in environments where most of
the participants are trusted. With BiBa, a packet signature is
reduced to k balls of 64 bits, where k is on the order of 10 to
16 bits. However, the problem with BiBa is the required bandwidth
to distribute the public key (which is on the order of 10
Kbytes) of each BiBa instance to all receivers. Typically, when
the session is dynamic, new members may join the session frequently,
and each new member needs to get the public keys of
the overall BiBa running instances. In this case, distributing
BiBa public keys will cause a bottleneck at the sender. With
the solution of Desmedt et al., the authentication information
size per packet is (k + 3) × ⎡log 2 p⎤ bits where p is a large
prime equal or greater than the number of messages, and
k – 1 is the largest coalition of fraudulent receivers. This overhead
could be important with streams that are supposed to be
infinite. Otherwise, this overhead could be relatively low in
the case of small, previously stored media.
Computation and M emory Considerations: Today’s networks
involve too many heterogeneous terminal devices with
respect to resource availability in terms of memory, computation
power, and energy in the case of wireless devices. For a
large deployment of secure multicast applications, data origin
authentication has to take into consideration this performance
criterion. BiBa is not suitable for severely resource constrained
environments, such as ad hoc sensor networks, because each
receiver has to maintain many public keys of 10 KB each, corresponding
to the BiBa instances running at the sender. The
complex computation behind the unconditionally secure
authentication, such as the polynomial scheme proposed by
Desmedt et al., are also not suitable for this kind of network.
The solution proposed by Canetti et al. requires a low storage
overhead: the sender stores l MACs and each receiver stores
l/(w + 1) MACs, where w is the largest coalition of fraudulent
receivers that may exist in the session. In the improved scheme
(using 1-bit MACs) a receiver is required to store only 76
MACs (76 bits) and the sender is required to store 760 MACs
(760 bits). Each receiver verifies received packets by computing
l/(w + 1) (76) MACs. Thus, the verification time is relatively
high compared to solutions that require only a single
MAC computation to verify a received packet’s authenticity.
To our knowledge, the best protocols with respect to the computation
power requirement are TESLA and the solution proposed
by Bergadano et al. Indeed, both of them reduce
IEEE Communications Surveys & Tutorials • Third Quarter 2004 45
� ���
authentication information generation and verification to a single
MAC computation. However, the two protocols suffer
from the requirement to buffer packets received in a specific
time interval in addition to the verification key at receivers.
Besides, the sender may manage long one-way MAC key
chains. In the case of TESLA, the time interval, and hence the
buffering requirement at receiver side, is more important than
in Bergadano et al. However, the Bergadano et al. solution
requires the sender to manage longer MAC-key chains, since
each key is used to authenticate only a single packet.
Nodes’ Mobility Consideration: Even if proposed multicast
data origin authentication schemes are independent from the
lower network layers, the nodes’ mobility can have a major
impact on the proposed protocols’ efficiency. The rule of
thumb is that time-based asymmetry protocols are not suitable
for highly dynamic networks, such as dynamic ad hoc networks
where nodes freely join and leave the session and the network
topology may change over time. In fact, the TESLA, BiBa,
and Bergadano et al. protocols suppose that receivers are synchronized
with the sender, so that receivers are assured that
all of them receive the authenticated packets before the disclosure
of the corresponding MAC key. The security of these
schemes relies on this assumption, because otherwise a fraudulent
receiver could receive a MAC key before other receivers
in the session and forge MACs over messages on behalf of the
sender. This synchronization takes into consideration the
packets’ propagation delays in the network. Therefore, if the
network topology changes, the packets’ propagation delays
may change. Hence, some mobile nodes may reject authentic
packets that they consider late. But in reality, it is the propagation
delay that becomes longer due to an important topology
change or a handover. To solve this problem, mobile nodes
have to re-calculate the disclosure interval time with the sender
after each handover, but this would cause a bottleneck at the
sender in the case of highly dynamic networks.
46
P' n
P n
H
P' k
P k
H(P' k+1)
H
P' k-1
FIGURE 13. Simple stream signing scheme using signature propagation
concept.
MULTICAST DATA ORIGIN AUTHENTICATION
WITH NON-REPUDIATION
To assure data origin authentication and non-repudiation for
a given message, the sender has to sign it using its private key.
Hence, a naive solution to guarantee multicast data origin
authentication with non-repudiation would be to sign each
multicast message and then multicast the message as well as
its signature. Upon receiving the message and its signature,
receivers would be able to verify the message’s data origin
authenticity using the public key of the sender and non-repudiation
is guaranteed. Existing digital signature mechanisms
are very computationally expensive. Therefore, this naive solution
raises the problem of the required computation power to
sign and to verify each multicast message. Thus, this naive
solution is not practical with most media-streaming applications
that require real-time transmission. Besides, power constrained
devices cannot afford the required energy to
guarantee the operation of this naive solution. To cope with
P k-1
H
P' 1
P 1
H(P' k) H(P' 2)
S SK
S SK(P' 1)
the limitations of this solution, existing alternatives offered
three types of reasoning.
A first alternative is to sign only a small piece of information
which makes it possible to verify the data origin authenticity
of a reduced number of packets. The latter packets
carry, in turn, information that makes it possible to verify the
data origin authenticity of other packets, and so on. Each
packet carries authentication information that makes possible
the verification of other packets. This recursive relation
between packets is made in a way that the single digital signature
effects (authentication and non-repudiation) propagate to
cover all the related packets. This alternative corresponds to
the category called signature propagation in the taxonomy
depicted in Fig. 7.
A second alternative is to sign only a small piece of information
and to disperse the resulting authentication information
among a set of packets. Afterward, each received packet
will contribute its share of the authentication information to
reconstitute the entire required information to verify data origin
authentication. This alternative corresponds to the category
called signature dispersal in the taxonomy depicted in Fig. 7.
Another alternative is to sign only a small piece of information
(keys) which is used, in turn, to sign packets, but this
time using one-time signing, a cryptographic mechanism that
is known to be not computationally expensive. This alternative
corresponds to the category called differed signing in the taxonomy
depicted in Fig. 7.
In the following sections we will discuss and illustrate each
category with some relevant solutions from the literature.
SIGNATURE PROPAGATION
Recall that the essence of the schemes in this category is to
make each packet carry authentication information of other
packets, and this process yields a small piece of information
that is signed. Hence, the single-signature effects propagate
throughout the packets’ relationship. This propagation assures
data origin authentication and non-repudiation of all related
packets. The following simple example introduces the main
idea of this category.
Example: Let us consider a stream of n packets, denoted by
Pn, Pn–1, …, P2, P1. Instead of signing each packet, the sender
calculates the hash of the last packet H(Pn) = d n and appends
it to packet Pn–1 to form a new packet Pn–1 ′ = Pn –1⎜d n. Then
the sender calculates the hash of this latter packet H(Pn–1 ′ ) =
d n–1 and appends it to packet Pn–2. This process is undertaken
recursively with the rest of the packets in the stream (Fig. 13).
The last hash of this process d1 is signed and multicast to
receivers. Then the new computed packets Pi′ are also multicast
successively. Upon receiving the signature, a receiver
knows the hash d1 to be used to verify packet P1′ and hence to
verify P1. P1′ will carry the hash to be used to verify P2 and so
on, with each packet carrying the hash to be used in verifying
the following packet. Thus, the single signature will propagate
throughout this chain, guaranteeing data origin authentication
with non-repudiation of all the packets of the stream.
Here we notice that if a single packet Pi′ is lost, all subsequent
packets cannot be verified because of the lack of Pi′ +1
authentication information which is carried by Pi′. Therefore,
we distinguish between two types of schemes: those that do
tolerate packet loss and those that do not. Figure 14 further
classifies proposed solutions regarding tolerance to packet loss.
SCHEMES NOT TOLERANT TO PACKET LOSS
Some data-streaming applications use a reliable transport
IEEE Communications Surveys & Tutorials • Third Quarter 2004
� ���
Protocol
concept
Tolerance to
packet loss
Protocols
No tolerance to
packet loss
Off-line
signing
Off-line
signing
Signature propagation
On-line
signing
On-line
signing
Random
chaining
EMSS
P-random
graph
Tolerance to
packet loss
Deterministic
chaining
Periodic
chaining
Piggybacking
FIGURE 14. Taxonomy refinement for multicast non-repudiation
using signature propagation concept.
layer such as TCP and hence packet loss is not a concern for
data origin authentication in this kind of application. An
example of applications that can be modeled as streaming is
executing applets [44]. Applets are organized into modules that
are downloaded and executed module by module. In this case
instant data origin authentication is required to avoid an
attacker sending malicious code, and non-repudiation is also
required in order to prove the identity of the entity responsible
for sending malicious code. In the following sections we
present protocols that fit into this sub-category.
Simple Off-line Chaining
Overview: The main idea of the solution proposed by Gennaro
and Rohatgi in [44, 45] is to divide the stream into
blocks and embed some authentication information in the
stream itself. The authentication information of the ith block
is used to authenticate the (i + 1)st block. In this way the
signer needs to sign only the first block and then the properties
of this single signature will propagate to the rest of the
stream through the authentication information.
In this solution it is assumed that the sender knows the
entire stream in advance (off-line). To authenticate the
stream, the sender embeds in the current block a hash of the
following block, which in turn includes the hash of the following
block and so on. Then the sender signs only the first
block. To verify the stream’s data origin authenticity, a receiver
first receives the signature on the hash of the first block.
After verification of the signature the receiver knows what the
hash of the first block should be and then starts receiving the
full stream and starts verifying the stream’s authenticity block
by block by comparing the hash of the current block with the
hash received in the previous block. Figure 15 illustrates the
construction of the authentication information chain for a
stream composed of n blocks {b n, b n–1, … , b 2, b 1}.
The sender constructs, off-line, the authentication chain
{B n, B n–1, …, B 2, B 1} such as B i = B i ⎜H(B i–1). The first block
of the authentication chain B 1 is signed using the private key
of the sender SK.
A receiver first verifies the signature of the first block,
S SK(B 1). Then the receiver authenticates the block B i using
the hash H(B i) received in B i–1. In this way all the blocks of
the stream are recurrently authenticated.
Advantages and Drawbacks: The major merit of this proposition
is that authors introduced and proved the security (data
origin authentication and non-repudiation) of the hash-chaining
scheme. With this solution the authentication information
is reduced to one hash per block. The sender signs only the
hash of the first block. The other blocks are authenticated
using only a hash computation. Receivers can verify the
block’s authentication as soon as the block is received. However,
this solution is not fault tolerant: if a block is lost, the
authentication chain is broken and hence all subsequent
blocks can no longer be authenticated. Besides, the fact that
the entire stream must be known in order to construct the
chain (get-all-before) is too strong of a requirement for practical
Internet applications.
On-line Signing
Overview: The essence of the second solution proposed by
Gennaro and Rohatgi in [44, 45] is to make each data block
carrying the one-time public key used to one-time sign the following
block. Hence, by signing the first one-time public key,
the signature is amortized over the stream. The major contribution
of this solution is to get rid of the get-all-before
requirement of the previous solution.
With this solution, Gennaro and Rohatgi have supposed
that the sender does not know the entire stream in advance
(e.g., a live broadcast). In this scenario it is important that the
signing operation (and not just the verification) be fast, since
the sender itself is bound to produce an authenticated stream
at a potentially high rate. In this case the stream is split into
blocks. Initially the sender sends a signed public key for a
one-time signature scheme. Then it sends the first block along
with a one-time signature on its hash based on the one-time
public key sent in the previous block. The first block also contains
a new one-time public key to be used to verify the signature
on the second block, and this structure is repeated in all
the blocks.
Example: Figure 16 illustrates the construction of the
authentication chain for a stream of n blocks: {…, bn, bn–1, …,
b2, b1}. The sender constructs, on-line, the authentication
chain {…, Bn ⎜σ1 skn(B
n), Bn–1 ⎜σ 1
sk n –1 (Bn–1)…, B2 ⎜σ 1
s k 2(B2),
B 1
1⎜σsk1 (B1), SSK(pk 1)} such as Bi = bi ⎜pk i+1 and pk i is the
one-time public key corresponding to the one-time private key
sk i.
The receiver authenticates the block Bi by verifying the
one-time signature received with the block using the one-time
public key received in B i –1. Hence, all the blocks of the
stream are recurrently authenticated.
Advantages and Drawbacks: With this solution the authentication
information is composed of one one-time public key
in addition to one one-time signature per block (which is
known to be not computationally expensive). Receivers can
verify blocks’ authentication as soon as they are received. As a
new one-time public key is generated for each block, it is not
necessary to know the length of the stream a priori. However,
this solution is not fault tolerant: if a block is lost, the authentication
chain is broken and hence all subsequent blocks can
no longer be authenticated. Besides, one-time signatures are
known to be too large, and hence this solution leads to high
bandwidth consumption.
SCHEMES TOLERANT TO PACKET LOSS
IEEE Communications Surveys & Tutorials • Third Quarter 2004 47
� ���
B n
b n
H
B k
b k
H(B k+1 )
B k-1
b k-1
FIGURE 15. Simple off-line chaining (example).
H
H
B 1
b 1
H(B k ) H(B 2 )
S SK
S SK (B 1 )
� ���
Most media-streaming applications do not use a reliable transport
layer since they require real-time transmission and hence
packets’ re-transmission cannot be used to recover lost data.
The general concept used to cope with packet loss in this category
of data origin authentication schemes is to create redundancy
in the packets’ authentication information so that even if
some packets are lost, the required authentication information
is recovered from received packets. In other words, instead of
embedding the hash of a packet only in the next (or previous)
packet, the packet’s hash is embedded within several packets.
These embeddings of a packet’s hash into other packets to create
authentication information redundancy form a topology of
packet relations. This technique is subject to the following performance
law: the more important is redundancy, the higher is
robustness against packet loss. But we also know that the more
important is redundancy, the higher is bandwidth consumption.
Therefore, the aim of the proposed solutions using the authentication
information redundancy approach is to define the best
topology that minimizes redundancy on the one hand and provides
better resistance to packet loss on the other hand. (See
the taxonomy refinement in Fig. 14.)
Terminology: We now define terminology to simplify the following
discussion. If a packet P j contains the hash of a packet
P i, we say that a hash-link connects P i to P j, and we call P j a
target packet of P i. We designate by redundancy degree the
number of times that a packet hash is embedded in subsequent
packets to create redundancy in chaining the packet to
a signature packet. A signature packet is a sequence of packet
hashes that is signed using a conventional digital signature
scheme. A hash-link points from a packet P k to a signature
packet S l, if S l contains the hash of P k. We assume that some
of the packets can be dropped between the sender and the
receiver. It has been proven that a packet P i is verifiable if it
remains a path (following the hash-links) from P i to a signature
packet S j [44]. We designate by verification ratio the
number of verifiable packets by the number of received packets.
The verification ratio is a good indicator of the verification
probability, which means the probability for a packet to
be verifiable given that it is received: P (packet is
verifiable/packet is received).
Typographic Conventions: Figures in this section use the
following conventions. A packet P i is represented with a circle
(node) numbered by i . If a hash-link connects P i to P j, then
we draw a directed edge from node i to node j. A signature
packet is represented with a grayed node. In the following
section we review proposed solutions that fit within this category.
EMSS: Efficient Multi-chained Stream Signature
Overview: Perrig et al. [40] introduced the notion of redundant
hash-chaining, which means that each packet of the
stream is hash-linked to several target packets. Thus, even if
some packets are lost, a received packet is verifiable if it
remains a hash-link path that relates the packet to a signature
packet. For a given packet, EMSS chooses target packets randomly.
Hence, EMSS provides more or less probabilistic guar-
48
B k
b k
pk k+1
σ skk (B k)
B k-1
b k-1
pk k
σ skk-1 (B k-1)
B 2
b 2
pk 3
σ sk2 (B 2)
FIGURE 16. On-line one-time signing.
B 1
b 1
pk 2
σ sk1 (B 1)
S SK (pk 1 )
� ���
i i+j i+b
i+k S
FIGURE 17. EMSS hash chaining with redundancy degree equal
to 3.
antees that it remains a hash-link path between the packet
and a signature packet, given a certain rate of packet loss in
the network.
EMSS operates as follows. When a packet is presented to
be sent, the sender embeds some hashes of other packets in
this packet and computes the overall hash code. This hash
code is buffered to be included later in d target packets chosen
randomly by the sender (where d is the redundancy
degree). Figure 17 shows an example where the redundancy
degree d is equal to three. In this example, packets i + j,
i + b, and i + k are target packets of packet i. If we suppose
that lost packets are removed from the graph, then packet i is
verifiable because it maintains a hash-link path to the signature
packet S via packet i + b .
In order for the sender to continuously assure the authentication
of the stream, the sender sends periodic signature
packets. To verify the authenticity of received packets, a
receiver buffers received packets and waits for their corresponding
signature packet. The signature packet carries the
hashes that allow the verification of few packets. These latter
packets carry, in turn, the hashes that allow to verify other
packets, and so on until the authenticity of all received packets
is verified.
Advantages and Drawbacks: EMSS provides probabilistic
robustness against packet loss. Using simulations, the authors
showed that using a redundancy degree equal to six, more
than 90 percent of received packets can be verified (hold a
hash-link path to a signature packet) even if 60 percent of
stream packets are lost. The main drawback of this scheme is
that receivers experience latencies before verifying received
packets, since they must wait for the signature packet corresponding
to the received packets. Besides, the periodic signing
makes the solution not suitable for most energy-constrained
devices.
Extension: Y. Challal et al. have proposed the A 2 Cast protocol:
Adaptive source Authentication protocol for multiCAST
streams [46]. A 2 Cast relies on EMSS, with the addition that it
assumes that there exists a means by which receivers can communicate
to the sender the packet loss ratio in the network
(for example, by sending periodic RTCP [47] receiver reports).
Relying on this receivers’ feedback, the source decides on the
best redundancy degree to use in order to tolerate the actual
packet loss ratio in the network. In this way, A 2 Cast makes it
possible to not only save unnecessary authentication information
overhead but also to reach the best authentication verification
ratio of received packets.
The p-random Authentication Scheme
Overview: Minner and Staddon [48] proposed a redundant
and random hash-chaining scheme to tolerate packet loss in a
network where each packet is lost independently at random
with probability q. Authors were interested in applications in
which the sender has a priori knowledge of the content.
Therefore, the hash-link topology is constructed before the
first packet of the stream is sent. The random redundant topology
proposed by the authors is called p-random graph. In a
basic p-random graph scheme, packets of the stream are num-
IEEE Communications Surveys & Tutorials • Third Quarter 2004
� ���
P 1 P i P i+1 P i+2 P i+3
FIGURE 18. In a p-random graph, each edge indicated above
occurs with probability p.
bered from 1 to n. P 1 is the signature packet, and for all pairs
of packets (P i, P j) where j < i, the hash of packet P i is embedded
within packet P j with probability p. Once the p-random
graph of the stream is constructed, the packets of the stream
are sent respectively. A receiver starts by receiving the signature
packet. If it is valid, the receiver verifies subsequent
packets on the fly by checking the existence of a hash-link
path between the received packet and the signature packet.
Figure 18 illustrates a simple p-random graph.
Advantages and Drawbacks: Authors proved that with a
p-random authentication scheme in a network where each
packet is lost independently at random with probability q, the
authentication probability of each packet P i , i ≥ 2, is lowerbounded
by:
P r[P i is verifiable ⎜P i is received]
≥ 1 – (1 – p) (1 – (p (1 – q)) 2 ) i–2 .
This lower-bound depends on the position i of the packet
P i in the stream in such a way that this lower bound is higher
for packets that are far from the signature packet. To ensure
the same minimum authentication probability for all packets,
authors extend the construction of p-random graphs by adding
more redundancy using MACs in order to increase the effective
distance of the earlier packets from the signature.
Receivers verify received packets instantly, but the sender is
required to buffer the overall stream in order to build the
p-random graph of the stream. The authentication information
overhead may be high, depending on the parameter p.
Indeed, each packet has an average expected redundancy
degree equal to p(n – 1) hashes (in the basic p-random
graphs).
Periodic Chaining Approach
Overview: Modadugu and Golle [49] have proposed to use
a similar strategy to EMSS, but target packets of a given
packet are chosen in a deterministic way rather than randomly.
The proposed deterministic topologies of packet relations
are designed to be optimized to resist a burst loss.
Indeed, in the Internet consecutive packets tend to get lost
together in a burst [50, 51]. The goal of the proposed
schemes is to maximize the size of the longest single burst
of loss that the authentication scheme can withstand. (After
a few packets have been received after a burst, the scheme
recovers and is ready to maintain authentication even if further
loss occurs.) To construct a topology of hash-links
between packets, the sender needs to buffer some packets
to create hash-links between them, denoting the size of this
sender’s side packet buffer by p (packets). The authors classified
the proposed topologies depending on the possible
sender’s buffer size (p).
• N o buffering at the sender side (p = 1): In this case the
authors have proposed a topology called C a, a periodic
authentication scheme of period one defined as follows:
the target packets of a packet P i are P i+1 and P i+a. The
last packet P n is signed. C a is called a chain of strength a.
Figure 19 represents an example of a C 3 authentication
scheme.
• Buffering of size p > 1 at the sender: In this case the
authors have proposed the topology called the C a augmented
chain, denoted by C a, p. The C a, p topology relies
on a C a topology by inserting p – 2 packets recursively
between two packets of the C a topology, as illustrated in
the following example. Figure 20 illustrates a C 3,6 topology.
Packets A and B correspond to packets chained
according to a C a topology. Then packets 1 and 2 are
inserted as shown in Fig. 20a. Finally, packets 3 and 4
are inserted between packets 1 and 2 in the same manner
these latter were inserted between A and B. To
assure continuous data origin authentication of the
stream, the proposed scheme is applied to each block of
n packets.
Advantages and Drawbacks: With a C a scheme, bursts of
length up to a – 1 do not disconnect any packet from the signature.
The authors proved that the scheme C a is optimally
resistant to bursty loss among all the schemes that can be executed
by a sender who buffers one packet and has a hash
buffer of size a. The authentication information is also mitigated
and reduced to only two hashes per packet. With a C a , p
scheme the maximum number of hashes appended to any
packet is constant (five in the maximum case) and the average
number of hashes appended to a packet is two. The authors
proved that any burst of length up to p(a – 1) leaves the rest
of the stream verifiable. However, the number of loss bursts
that may occur during a block transmission is likely to be
more important than a single burst. The proposed solution is
not optimized for these situations. Besides, with this topology
the sender needs to buffer p packets before sending them.
Thus, this topology may not be suitable for some applications
that require live-broadcasting.
Piggybacking
Overview — Miner and Staddon [48] proposed a similar
authentication scheme based on hash-chaining techniques,
specifically designed to resist multiple bursts. The proposed
scheme deals with the scenario in which data carried by different
packets has more or less importance from the point of
view of the application level. Thus, packets are organized
into classes with different priorities. Then hash-chaining is
made in a way that the higher the priority of a class, the
more redundant is the hash-chaining of packets belonging to
that class, in order to provide greater resistance against
bursty losses.
In this scheme the packets are split into priority classes
(S 0… S r). The first packet of the stream and those packets for
which the sender requests highest tolerance are placed into S 0
(the highest priority class), those with the next highest level of
requested tolerance go into S 1 (the next highest class), and so
on. The packets in the highest priority class are supposed to
be regularly spaced throughout the stream, in order to minimize
their probability to be all lost in a burst. The topology of
hash-links is structured in such a way that the nodes in S 0 tolerate
the greatest bursty losses and do not require receipt of
any nodes from lower priority classes. Then hash-links that
originate at lower priority packets and always terminate at a
IEEE Communications Surveys & Tutorials • Third Quarter 2004 49
� ���
FIGURE 19. A periodic chain of strength 3: C 3.
� ���
packet in S 0 are added to the topology. T his means that the
hashes of low er priority packets are placed only into the packets
of the highest priority class.
Advantages and Drawbacks: In the proposed scheme each
priority class S i has associated w ith it tw o parameters, b i and
x i: b i indicates the max imum siz e of bursts that packets in the
class should tolerate, and x i indicates the max imum number of
bursts that packets in the class should tolerate. T his scheme is
particularly attractive w hen the sender w ants significant control
over the tolerance of each packet. Its main draw back is
that the redundancy degree w ithin each class is low er-bounded
by the max imum number of bursts that should be tolerated,
but in practice this information is not easy to acquire.
B esides, the proposed scheme requires buffering at both the
receiver and sender sides. T his yields latencies before verifying
and signing, respectively. T hus the proposed solution
w ould not be suitable for most media-streaming applications
that require real-time transmission.
50
A 1 2
A 1 3 4
2
B
FIGURE 2 0. A C 3,6 augmented chain.
SIGNA TU R E DISP ER SA L
R ecall that authentication information dispersal schemes are
based on processing authentication information and dispersing
it throughout a set of packets. T his processing is made in a
w ay that even if some amount (that does not ex ceed a certain
threshold) of this processed information is lost, all of the
authentication information can be recovered from received
data. L et us consider the follow ing intuitive ex ample to clarify
� ���
(2)
(1)
(3)
d1 d2
(a)
(b)
H H H
P1
P1
S
FIGURE 2 1 . Signature dispersal (example)
B
=S SK (d1|d2|d3)
d3
P2 P3
d2 d3
a
S
Transmission
the aim of this approach.
E xample: L et us consider a sequence of n packets to be
signed. Instead of signing each packet, the sender computes a
single signature on the entire sequence of packets as follow s.
T he sender first computes the hash of each packet, and then
computes the digital signature on the concatenation of these
latter hashes. W e call this signature the block signature. Figure
21a illustrates this authentication information generation
phase for a block of three packets. If the sender multicasts the
packets along w ith the block signature, it is clear that if all the
packets are received along w ith the block signature, a receiver
can verify the authenticity of a received sequence of packets
using the public key of the sender. B ut w e know a priori that
some packets may be lost. In this case the verification is
impossible because the concatenation of the packets’ hashes
cannot be calculated to be verified against the block signature.
Figure 21 illustrates a straightforw ard solution to this problem.
4 It consists of making each packet carry all of the authentication
information consisting of the block signature in
addition to all the hashes of the other packets (Fig. 21, step
3). T herefore, even if all the packets ex cept one are lost, the
received packet can be verified since it carries all the required
information to allow its verification. Indeed, to verify a
received packet, its hash is computed, then this hash is concatenated
to the other hashes carried by the packet follow ing
the original sequence order (Fig. 21, step 4). T his concatenation
of digests is then verified against the signature, w hich is
also carried by the packet, using the public key of the sender
(Fig. 21, step 5).
W e notice in this simple ex ample that authentication information
processing is reduced to replication. In fact, each packet
carries almost an entire copy of the authentication information
consisting of a signature w ith a concatenation of the
packets’ hashes. W e also notice that the tolerated packet loss
threshold is n – 1 lost packets out of n sent packets. T his is the
ex treme case, in w hich each packet is individually verifiable.
H ow ever, the price to pay is the large siz e of the authentication
information share carried by each packet. S ince in practice
w e know that only some of the packets are lost (let’s say k
out of n packets are lost w ith k < n), the aim of the proposed
solutions on the one hand is to reduce the siz e of the authentication
information share carried by each packet, and on the
other hand to increase the tolerated packet loss threshold.
4 This technique is proposed by Wong and Lam in [52, 53].
(4)
(5)
Signature verification
V PK (d1|d2|d3, S)
d1 d2 d3
H H H
P1
d2 d3
IEEE Communications Surveys & Tutorials • Third Quarter 2004
S
PK
� ���
In the following sections we review proposed solutions that
rely either on an explicit redundancy of the authentication
information by means of replication, or on an implicit redundancy
of the authentication information by means of some
extra-processing.
Tree-Chaining
Overview: Wong and Lam [52, 53] have proposed that each
packet carries the required authentication information so that
it can be individually verifiable. In other words, even if n – 1
out of n packets are lost, the authenticity of the single received
packet can be verified. The stream is signed block by block.
The number of packets m within a block depends on the available
packets to be sent during a period of time T, and hence
depends on the application level packets’ rate. To prevent a
packet from carrying an entire copy of the authentication
information, as stated in the introductory example above, the
digests of the block packets are organized into a tree by means
of extra-hash-processing.
In order to simplify the presentation of the proposed
scheme let us consider the case in which the constructed tree
is a binary tree. In this case the block packets are the leaves
of a binary tree. Each internal node of the tree is the message
digest of its children in the level of the tree beneath it. Finally,
the root is a signed digest of its children and forms the
block signature. Figure 22 illustrates an example of such a
binary tree. A packet signature consists of the block signature,
the packet position in the block, and the siblings of each node
in the packet’s path to the root. To verify a packet individually,
a receiver verifies the path from the received packet to the
root. The authenticated nodes are cached at the receiver. By
caching verified nodes the receiver only needs to compute
each node in the authentication tree once, at most.
Example: Consider a block of eight packets with packet
digests D1, D2, …, D8. The packet digests are the leaf nodes
of a binary tree, with other nodes of the tree computed as
message digests of their children, as shown in Fig. 22. The
block signature is a signature over the root digest.
Consider the dashed path in Fig. 22 for the third packet.
Each node in the path needs to be verified. A receiver computes
the digest D3′ of the received packet, and the digests of
its ancestors in the tree. That is, D3–4 ′ = H(D3′⎜D 4), D1–4 ′ =
H(D1–2⎜D 3–4 ′ ), and D1–8 ′ = H(D1–4 ′ ⎜D5–8), where D4, D1–2 and
D5–8 are carried in the packet signature. The receiver then
executes the verification operation to determine whether
D 1–8
D 1-2
D1-4
D 1-8
FIGURE 22. Authentication tree (example).
D 5-8
D 3-4 D 5-6 D 7-8
D 1 D 2 D 3 D 4 D 5 D 6 D 7 D 8
′ is a valid digest with respect to the block signature
S SK (D 1–8). The packet is verified if the verification operation
returns true. Suppose that the third packet is the first in the
block to arrive. A fter verifying it, the verifier knows the following
nodes in the authentication tree: D 3, D 4, D 1–2, D 3–4,
D 1–4, D 5–8 , and the block digest D 1–8 . These are verified
nodes that can be cached. By caching verified nodes, the verifier
only needs to compute each node in the authentication
tree once, at most.
Advantages and Drawbacks: Since each packet is individually
verifiable, this approach is perfectly tolerant to packet loss.
This solution has the drawback of including a large authentication
information within each packet. If a block of packets
contains m packets, then each packet includes log d(m) – 1
packet digests in addition to the block signature and its position
in the block (d being the constructed hash-tree degree).
This amount of authentication information presents a relatively
important communication overhead and requires buffering
and caching at receivers that may be limited in storage
resources. Besides, the solution presents the drawback of
requiring a digital signature (which is computationally expensive)
for each block of packets. This adds a computation overhead
at both signing and verifying.
SAIDA: Signature Amortization using IDA
Overview: In order to reduce the size of the authentication
information carried by each packet, the approach proposed by
P ark et al. [54, 55] uses a famous mechanism called ID A 5 to
disperse the n hashes of n block packets, as well as the block
signature into n pieces in such a way that the n pieces (and
hence the n hashes as well as the block signature) can be
reconstructed even if n – m pieces are lost (m being a parameter).
The proposed protocol proceeds as follows:
• The stream is divided into blocks of n packets, denoted
by B 1, B 2, … , B i, … .
• The sender computes the packet hashes in a block B i
using some hash function H. Then it concatenates them
to form F i = H(P 1 i )⎜H(P2 i )⎜… ⎜H(Pn i ), where P j i is the jth
packet in the block B i.
• Then the sender signs the block B i by signing F i (the
hashes’ concatenation). We denote this block signature
by S i.
• The source then applies the ID A algorithm to both the
hashes F i and the signature S i, and thus we get the ID A -
pieces (F i j ) 1 ≤ j ≤ n and (S i j ){ 1 ≤ j ≤ n (respectively), where
F i j is the jth ID A -piece of Fi, and S i j is the jth ID A -piece
of S i.
• To each packet P j in the block B i the sender appends the
corresponding ID A -pieces F i j and Si j to form a block of
authenticated packets (Fig. 23).
• The sender can now send the authenticated packets, and
the scheme tolerates that n – m authenticated packets be lost.
• N ow, by applying the ID A -algorithm a receiver can
reconstruct the authentication information (the packets’
hashes and the block signature) to verify packets using
only at least m received authenticated packets.
Advantages and Drawbacks: The authors showed that with
the SA ID A protocol the authentication information size is
reduced to n/m × ⎜F i ⎜, where F i is the concatenation of the n
packets’ hashes of block B i . This protocol makes it possible to
achieve a trade-off between the authentication information
overhead (bandwidth) and tolerance to packet loss (parameter
m). However, this scheme requires a high computation over-
5 IDA has been proposed by Rabin in [56]. It was originally developed to
provide safe and reliable storage or transmission of information in distributed
systems. The basic idea of IDA is to process the original data
denoted by F, by introducing some amount of redundancy and splitting the
result into n pieces, which are then transmitted. Reconstruction of F is possible
with any combination of m pieces (assuming n-m pieces are lost during
transmission), where m ≤ n.
IEEE Communications Surveys & Tutorials • Third Quarter 2004 51
� ���
head due to the IDA processing. Besides, it introduces delays
at both the sender and receivers to generate and verify the
authentication information using IDA.
Variant: Pannetrat and Molva [57] proposed a stream authentication
scheme that is similar to the above scheme [54]. They
propose authenticating real-time data streams by piggybacking
the current block’s encoded authentication information (via
an erasure code) onto the next block, the previous block, or
itself, depending on the available memory at the sender or
receiver side.
52
P 1
F 1 i
S 1 i
Block B i
FIGURE 23 . Authenticated packets using IDA.
P 2
F 2 i
S 2 i
DIF F ERED SIGNING
Instead of signing data itself, with Differed Signing the sender
signs a small piece of information consisting of one-time keys
in a way that this signing does not interfere with real-time transmission
required by most media-streaming applications. These
signed one-time keys are then used to one-time sign data itself
in a fast way. Notice that the first conventional signing step
makes it possible to certify the authenticity of the one-time
keys used in signing data. To further clarify this approach let
us consider an example.
Example: We want to sign a sequence of n packets. Signing
each packet using a conventional digital signature mechanism
is very expensive in both time and computation. O ne alternative
to this naive solution is to generate a pair of one-time (private/public)
keys per packet. Then the sender one-time signs
each packet using a different pair of previously generated onetime
(private/public) keys. O ne-time signing is known to be not
computationally expensive and hence signing in this case does
not obstruct real-time transmission. The problem with this simple
solution is that one-time public keys are not certified and
hence cannot be trusted by receivers. To cope with this limitation
the sender must prove that one-time public keys actually
originate from him. Instead of issuing a certificate for each
one-time public key (which is a heavy process), the sender
takes advantage of the existing certified conventional publickey
to digitally sign one-time public keys that will be used, in
turn, to one-time sign packets. The remaining problem with
this simple solution is how to sign and verify one-time public
keys without interfering with real-time transmission required
by most media-streaming applications. In the following sections
we present works that deal with this issue.
On-line/Off-line Digital Signatures
Overview: The main idea of the solution proposed by Shimon
Even et al. in [58, 59 ] is to sign keys off-line and cache them
within a buffer for future use. The cached keys are then used
to authenticate messages on-line using a speedy cryptographic
mechanism (one-time signing). Hence, the off-line signing
does not interfere with the real-time transmission requirement
of media streaming applications.
Shimon Even et al. [58, 59 ] suggest that slower pre-computations
using conventional digital signature mechanisms can
be tolerated, provided that they do not have to be performed
on-line (i.e., once the message to be signed is handed to the
signer and while the verifier is waiting for the signature). The
P n
F n i
S n i
authors introduced the notion of an on-line/off-line signature
scheme, in which the signing process can be broken into two
phases:
• The first phase, performed off-line, is independent of the
particular message to be signed. This phase consists of
generating a pair of one-time signing/verifying keys (sk,
pk) and producing an ordinary signature of the one-time
verification key SSK(pk) (where SK is the sender’s conventional
private key). Both one-time keys and the signature
are stored for future use in the on-line phase.
• The second phase is performed on-line after the message
M is presented. It consists of retrieving a precomputed
unused pair of one-time keys (sk, pk), and using the onetime
signing key to sign the message σ1 sk(M).
The corresponding
one-time verification key and its precomputed
signature are attached to the one-time message signature
to produce the final signature, pk⎜SSK(pk)⎜σsk(M). To verify that the triple pk⎜SSK(pk)⎜σ sk(M) is indeed a signature
of m with respect to the public key PK of the sender, the
receiver acts as follows:
• The receiver first checks that SSK(pk) is indeed a signature
of the one-time verification key pk with respect to
the public key PK.
• The receiver then checks that σsk(M) is indeed a onetime
signature of the message M with respect to the onetime
verification key pk.
Advantages and Drawbacks: Since each message is onetime
signed independently from other messages, the proposed
scheme tolerates packet loss and received messages can be
verified as soon as they arrive at a receiver. The main drawback
of the proposed scheme is that a receiver has to verify a
conventional digital signature on a one-time verification key
in addition to a one-time signature on the received message.
The conventional digital signature verification may not be
suitable for most resource constrained devices. Besides, it is
well known that the size of one-time signatures may be very
large, and hence the proposed scheme may lead to high bandwidth
consumption. The off-line phase can raise some limitations
when the message arrival rate is very high, especially
with streaming-media applications such as live video-broadcasting.
The best solution to this problem is to parallelize the
solution in a way that the off-line expensive phase be processed
by a powerful server.
E x tensio ns and Im p ro vem ents: Pankaj Rohatgi [60] proposed
to have the off-line computation create and sign ktime
key pairs instead of one-time key-pairs, so that the cost
of the most expensive operation, i.e. signing k-time verification
keys using conventional digital signing, can be amortized
over k-signatures. With this scheme the multicast
sender has an off-line process that generates k-time keypairs
and signs the k-time verification keys using the sender’s
long-term conventional signature key. The sender uses such
a k-time key-pair to sign each of k successive messages in the
on-line phase. Since the main drawback of one-time/k-time
signatures is the large size of the produced signatures, the
authors proposed techniques to reduce the size of k-time signatures,
but then the speed of the underlying mechanisms is
also decreased.
CO M PARISO N AND DISCUSSIO N
The efficiency of a data origin authentication protocol with
non-repudiation can be measured according to many criteria.
Table 8 compares data origin authentication with non-repudi-
IEEE Communications Surveys & Tutorials • Third Quarter 2004
� ���
Latency at Latency at
Protocol the source receivers Tolerance to packet loss Authentication information size
Offline chaining Yes No No ⎜d ⎜
Online chaining No No No ⎜pk ⎜ + ⎜σ ⎜
EMSS No Yes The authentication probability of a packet 6 ⎜d ⎜
is at least 90 percent
p – random graphs Yes No Pr(P i is verifiable ⎜ P i is received) ≥ 1 – p(n – 1) hashes per packet in average
(1 – p)(1 – (p(1 – q)) 2 ) i–2
Periodic chaining C a No Yes Yes: each block of packets tolerates a 2 ⎜d ⎜
single burst of length up to (a – 1)
Augmented chain C a, p Yes Yes Yes: each block of packets tolerates a 2 ⎜d ⎜ in average
single burst of length up to p(a – 1)
Piggybacking Yes Yes Yes: each prioritized packets’ set S i ⎜d ⎜ × (x i + 1) at least, for a packet in
tolerates x i bursts of b i packets class S i
Tree chaining Yes No Yes (log k(n) – 1) ⎜d ⎜ + ⎜S ⎜, where k is the
degree of the constructed hash tree
SAIDA (n, m) Yes Yes Tolerates up to n – m lost packets 2 IDA-pieces = ⎜S ⎜ + n × ⎜d ⎜/m
Online/offline signing No No Yes ⎜σ ⎜ + ⎜S ⎜ + ⎜pk ⎜
⎜d ⎜: size of a digest (hash). n: number of packets in a block. ⎜S ⎜: size of a signature. ⎜σ ⎜: size of a one-time signature. ⎜pk ⎜: size of a
one-time public key. q: loss probability of a packet.
Table 8. Comparison of data origin authentication with non-repudiation protocols.
ation protocols with respect to the following criteria: 6
• The latency at the sender: corresponds to the fact that
the sender needs to buffer packets before sending them.
• The latency at a receiver: corresponds to the fact that a
receiver needs to buffer packets before authenticating them.
• Tolerance to packet loss: corresponds to the fact that the
authentication process is possible even if some packets are lost.
• Authentication information size: the size of the authentication
information embedded to a packet.
Let us now make a vertical analysis of the proposed protocols,
by discussing the suitability of each protocol with respect
to some relevant practical requirements:
Robustness Against Packet Loss: Multicast applications
cannot afford to sign each multicast message because existing
signing mechanisms are very computationally expensive.
Therefore, most proposed multicast data origin authentication
with non-repudiation protocols rely on the concept of amortizing
a single digital signature over a sequence of packets.
This amortization creates dependencies between packets with
respect to the shared authentication information. Besides,
most multicast applications do not use a reliable transport
layer. Therefore, some packets as well as the carried authentication
information may be lost in the course of transmission.
This raises the problem of whether the authenticity of received
packets can be verified, even if some packets that carry a
share of the authentication information are lost. Perfect
robustness is reached when received packets can be verified
individually independently from the receipt of other packets.
This is true with tree-chaining, in which each packet carries its
own authentication information (a block signature in addition
to some information that proves that it belongs to the block).
Another solution that perfectly resists packet loss is on-
6 With EMSS, we consider results of the special case simulated by authors.
line/off-line signing, where each packet carries its own authentication
information consisting of a one-time signature on the
packet and a signed copy of the one-time verification key. The
perfect tolerance to packet loss is not for free, since there is a
trade-off between the robustness to packet loss and the
required resources in terms of bandwidth, memory, and computation,
to afford authentication information generation and
verification. For instance, the tree-chaining technique requires
a relatively important authentication information size compared
to other solutions. The on-line/off-line signing approach
requires a very expensive off-line phase to certify one-time
verification keys using conventional digital signing. This
approach may be difficult to implement without a parallelization
that separates the on-line phase from the off-line phase.
The other proposed schemes try to find the best trade-off
between robustness and required resources and hence have a
probabilistic tolerance to packet loss that depends on the
packet loss rate in the network. Park et al. [55] showed by
using simulations that EMSS, SAIDA, piggybacking, and augmented-chain
schemes have a verification rate that decreases
almost linearly with respect to packet loss in the network.
Namely, when packet loss increases from 5 percent to 35 percent
in the network, the verification rates vary as follows:
EMSS varies from 94 percent to 49 percent; piggybacking and
augmented chains have almost the same behavior and vary
from 95 percent to 66 percent; and SAIDA varies from 100
percent to 92 percent. 7
Real-time Transmission: The concept of signature amortization
underlying most data origin authentication with nonrepudiation
protocols makes it difficult to cope with latencies
at both the sender and receivers at the same time. Indeed,
7 These results depend on the settings of the simulations carried by the
authors [55]..
IEEE Communications Surveys & Tutorials • Third Quarter 2004 53
except for the on-line/off-line and the on-line signing schemes,
the other protocols require either that packets are buffered at
the sender before signing, or that packets are buffered at the
receivers before verification. Some protocols require both
buffering techniques. On-line/off-line signing allows instant
signing of available packets and instant verification of received
packets. However, this can be guaranteed only if it is assumed
that the off-line phase can produce certified one-time public
keys at a rate that is higher than the rate of the packets’
arrival at the sender. The best way to assure this assumption is
to parallelize this signing scheme by processing the off-line
phase in a powerful server. On-line signing allows also instant
signing and verification but does not tolerate packet loss.
Tree-chaining buffers packets that are available during a period
of time. When that period of time expires, the sender
builds the authentication tree and starts sending the packets.
In this case packets are verified as soon as they are received.
Similarly, off-line signing constructs the hash-chain of the
stream’s blocks of packets in the reverse order and signs the
first block. Hence, this solution requires that the whole stream
be known in advance. A receiver first verifies the signature,
then starts verifying the blocks’ authenticity block by block. In
contrast, EMSS sends packets as soon as they are available
and buffers their hashes to construct the redundant random
hash-chains. After a certain period of time the signer sends a
signature packet to allow the verification of the sent packets.
Therefore, receivers buffer received packets until the corresponding
signature packet is received, then receivers start the
verification of the buffered packets. SAIDA disperses the
authentication information over n packets of a block, and
hence requires buffering n packets before authenticating and
sending them. Receivers wait for the receipt of at least m
packets out of the n packets to reconstruct the authentication
information, and thus buffering of at least m packets before
verification is required at receivers before verification. The
remaining schemes (piggybacking and augmented chains) also
require buffering of packets at both the sender and receivers
in order to construct the hash-links topology at the sender,
and to verify the existence of hash-link paths between packets
and their corresponding signature packet at receivers.
Bandwidth Consideration: To tolerate packet loss it is necessary
to create redundancy in the authentication information
using mechanisms that have been discussed above. This
redundancy yields a certain extra-bandwidth-consumption. In
an extreme case the on-line/off-line scheme assures a perfect
tolerance to packet loss, but then it requires a very large
bandwidth overhead. Namely, each packet carries a signature
composed of a one-time verification key, a digital signature of
the key, and a one-time signature of the packet. The overall
packet’s signature size is in the range of a few K bytes. 8 In the
other extreme case the off-line solution reduces the bandwidth
overhead to only a single hash (128 bits for MD5) but
does not tolerate packet loss. The on-line scheme does not tolerate
packet loss and requires that each packet carry a onetime
public key of 128 bits in addition to a one-time signature
of 1080 bytes. 9 Tree-chaining techniques assure a perfect tolerance
to packet loss and reduce the bandwidth overhead per
packet to ⎜S ⎜+⎜h ⎜(log dn – 1)+1, where ⎜S ⎜ is the size of a
signature (the authors proposed using RSA-512 bits), ⎜h ⎜ is
the size of a hash code (128 bits for MD5), and n is the num-
8 Authors proposed four implementations of their scheme. The four signature
sizes of their respective schemes are: 2752 bytes, 526 bytes, 960 bytes
and 3949 bytes depending on the security level and the affordable verification
processing.
54
ber of packets within a signed block. However, this overhead
remains significant for a reasonable block size compared to
other protocols that trade better bandwidth for tolerance to
packet loss. The other protocols trade tolerance to packet loss
for bandwidth overhead. With EMSS, bandwidth overhead is
d × ⎜h⎜ per packet, where d is the redundancy degree and ⎜h⎜
is the size of a hash. Depending on the affordable bandwidth
(parameter d) the protocol achieves more or less tolerance to
packet loss. With augmented chains the bandwidth overhead is
reduced to two hashes per packet on average. The bandwidth
overhead per packet in the piggybacking technique depends
on the priority given to the packet and the number of bursts
that the packet’s class has to withstand. Besides, these latter
protocols (EMSS, piggybacking, and augmented chains)
require that block signatures be sent multiple times to avoid
their loss. Otherwise, entire blocks would not be verifiable if
their corresponding signatures are lost. SAIDA requires a
bandwidth overhead per packet equal to ( ⎜S ⎜+n⎜h⎜)/m,
where ⎜S⎜ is the size of a signature, n is the number of packets
in a block, and m is the required number of IDA-pieces
that allow the reconstruction of the entire authentication
information even if n – m packets are lost. Cucinotta et al.
showed in their simulations [61] that SAIDA has the lowest
bandwidth overhead (30 bytes per packet to achieve a 94 percent
verification ratio, given that 20 percent of the packets are
lost) compared to protocols that use chaining techniques
(EMSS, piggybacking, and augmented chains) with multiple
transmissions of block signatures. However, SAIDA requires
the highest verification time compared to the same protocols.
In contrast, the authors showed that EMSS has the highest
bandwidth overhead (60 bytes per packet to achieve a 94 percent
verification ratio, given that 20 percent of the packets are
lost) and the lowest verification and generation times.
Comp utation and M emory Consideration: Assuring nonrepudiation
requires the multicast sender to digitally sign the
multicast stream. Since digital signatures are computationally
expensive, most proposed solutions use the concept of signature
amortization over multiple packets. In order to avoid
important latencies and to assure continuous non-repudiation
for the stream, the sender signs the stream packet block by
packet block (or periodically). This periodic signing makes
non-repudiation difficult to achieve in networks of severely
resource-constrained devices, such as wireless devices and sensor
networks. Moreover, all the proposed solutions require
that receivers store at least the public key of the sender (1024
bits with RSA-1024 bits). Even worse, receivers are required to
store the public key of each sender in many-to-many multicast
communications. Some protocols do not suffer from periodic
signing, but then do not satisfy the overall requirements of
most multicast media-streaming applications. Namely, off-line
signing uses a single digital signature but requires the knowledge
of the whole stream beforehand. Therefore, this solution
is not suitable for most live broadcasting applications, and it
does not tolerate packet loss. On-line signing also uses a single
digital signature, but requires one-time signing of each packet
and hence yields high bandwidth consumption as discussed
above. On-line signing does not tolerate packet loss. In the online/off-line
signing scheme, one-time verification keys are
signed off-line and used to one-time sign packets. Even if we
assume that the sender can afford the expensive off-line phase,
the main drawback of this solution is the requirement of high
bandwidth consumption because of the requirement of a large
9 With the SHA implementation of the protocol, these values become: 160
bits and 1344 bytes respectively.
IEEE Communications Surveys & Tutorials • Third Quarter 2004
one-time signature per packet. Block by block signing schemes
trade resource requirements (computation, memory, and bandwidth)
for packet loss tolerance. While tree-chaining schemes
assure a perfect packet loss tolerance, they induce a relatively
important bandwidth overhead compared to other solutions. In
tree-chaining, the sender buffers available packets during a
period of time and then constructs a hash tree that requires 2n
– 1 hash computations and a digital signature (assuming that
the hash tree is a binary tree and n is the number of buffered
packets during the period of time). The verification process is
reduced to a few hash computations per packet. Cucinotta et
al. [61] showed that SAIDA incurs the highest verification time
due to the IDA processing, whereas piggybacking incurs the
highest authentication information generation time due to the
complex hash-link topology. In contrast, EMSS and augmented
chains have the lowest computation overhead at both generation
and verification, which are reduced to a few hash computations.
When considering storage requirements at the sender
side, EMSS performs better since it requires caching hashes of
only some packets which are discarded as soon as they are
embedded in their respective target packets. SAIDA, piggybacking,
and augmented chains require the storage of a block
of packets in order to generate the authentication information.
At the receiver side SAIDA performs better since it is only
necessary to receive m out of n packets of a block, whereas
EMSS, piggybacking, and augmented chains require that all
received packets are buffered until the receipt of their corresponding
signature packet.
CONCLUSIONS
In this article we provided an overview of the problems relating
to data origin authentication in group communication.
After having presented a classification of existing protocols,
we described many protocols within each identified class. We
also discussed and addressed a comparison between typical
solutions regarding a set of important criteria. This survey
allowed us to come up with many interesting conclusions.
First, data origin authentication is a required component in
the entire multicast security architecture. However, many
challenges obstruct the design of a data origin authentication
scheme: the large number of multicast group members and
the significant volume of data conveyed by multicast applications
require scalability. Since many applications use an unreliable
transport layer, the authentication scheme should
tolerate packet loss (the authentication process should be possible
even if some packets are lost). Moreover, receivers may
have limited resources in terms of computation and storage
(such as PDAs and notebooks) and hence the data origin
authentication scheme should not assume high availability of
such resources at the receivers. It is difficult to satisfy the
overall constraints and requirements involved in data origin
authentication and hence there is no best solution. However,
there are good solutions regarding specific requirements and
features. Multicast data origin authentication has matured
over the last 20 years, but there remain open problems in the
area that must be resolved to allow a larger deployment of
multicast applications that require data origin authentication.
Efficient Multicast Non-repudiation in Real-time
Transmission: Most proposed solutions focus on trading tolerance
to packet loss for bandwidth overhead. All of these
solutions require latencies at either the sender or receivers.
Development of non-repudiation mechanisms without the
requirement of packet buffering remains an open issue.
Efficient Multicast Non-repudiation in Many-to-Many
Communications: The problem above becomes worse when
considering many-to-many communications. With current proposed
schemes, receivers would have to manage packet
buffering for each source. In addition, storing senders’ public
keys may be an issue for resource-constrained devices. In our
opinion advances in cryptography are required to abate these
problems.
Efficient Multicast Non-repudiation in Sev erely
Resource-Constrained Networks: Although there have been
attempts to deal with data origin authentication in severely
resource-constrained networks (such as sensor networks),
non-repudiation in this type of network remains a challenging
problem because of the expensive underlying cryptographic
mechanisms.
Mobility-aware Multicast Data Origin Authentication:
When considering mobile multicast receivers, the collusion
problem becomes more relevant. In addition, time asymmetry
approaches are not efficient in such settings because of packet
propagation delay variations due to topology changes in such
networks. In mobile networks other sources of asymmetry are
required to assure efficient data origin authentication.
Adaptability to Packet Loss: Packet loss rate may change
over time depending on the incidents and congestions in the
network. Furthermore, the repartition of packet loss throughout
a large network is not uniform. Therefore it is important
to design multicast data origin authentication mechanisms
that take into consideration the variation of packet loss rate in
order to better trade tolerance to packet loss for other performance
requirements.
ACKNOWLEDGMENTS
Our first and most heartfelt thanks go to Martin Reisslein and
to the anonymous reviewers who took time out of their busy
schedules to send valuable comments and feedback about this
work. Without their concise and constructive criticism this
survey would not have been achieved. A note of gratitude
goes to the folks of the networking group, in the Heudiasyc
Lab. at Compiegne U niversity of Technology (U TC-France),
for their help and encouragement.
REFERENCES
[1] S. E. Deering, “Multicast Routing in Internetworks and Extended
LANs,” ACM SIGCOMM, Aug. 1988.
[2] T. Ballardie and J. Crowcroft, “Multicast-Specific Security
Threats and Counter-Measures,” Symp. Netw ork and D istributed
System Security, Feb. 1995, pp. 2–16.
[3] W . Fenner, “Internet G roup Management Protocol, version 2,”
Nov. 1997, RFC 2236.
[4] P. Judge and M. Ammar, “Security Issues and Solutions in
Multicast Content Distribution: A Survey,” IE E E Netw ork,
Jan./Feb. 2003, pp. 30–36.
[5] R. Canetti et al., “Multicast Security: A Taxonomy and Efficient
Constructions,” INFOCOM, 1999.
[6] T. Hardjono and G . Tsudik, “IP Multicast Security: Issues and
Directions,” Annales de Telecom, 2000.
[7] D. Eastlake and P. Jones, US Secure Hash Algorithm 1 (SHA1),
Sept. 2001, RFC 3174.
[8] B. K aliski, “The MD2 Message-Digest Algorithm,” Apr. 1992,
RFC 1319.
[9] R. Rivest, “The MD5 Message-Digest Algorithm,” Apr. 1992,
RFC 1321.
[10] H. K rawczyk, M. Bellare, and R. Canetti, “HMAC: K eyed-
Hashing for Message Authentication,” Feb. 1997, RFC 2104.
[11] Federal Information Processing Standards Publication, Digital
Signature Standard (DSS), May 1994, FIPS PUB 186.
[12] R. L. Rivest, A. Shamir, and L. M. Adelman, “A Method for
Obtaining Digital Signatures and Public-K ey Cryptosystems,”
Commun. ACM, vol. 21, no. 2, 1978, pp. 120–26.
[13] Y. Challal, H. Bettahar, and A. Bouabdallah, “A Scalable and
IEEE Communications Surveys & Tutorials • Third Quarter 2004 55
Adaptive Key Management Protocol for Group Communication,”
Wired and Wireless Internetl Communications
(WWIC’04), LNCSvol., no. 2957, Feb. 2004, pp. 260–71.
[14] S. Rafaeli and D. Hutchison, “A Survey of Key Management
for Secure Group Communication,” ACM Computing Surveys,
vol. 35, no. 3, Sept. 2003, pp. 309–29.
[15] W. Dai, “Comparison of Popular Cryptographic Algorithms,”
http://www.eskimo.com/˜weidai/benchmarks.html, 2003.
[16] R. Shirey, “Internet Security Glossary,” May 2000, RFC 2828.
[17] A. J. Menezes, P. C. van Oorschot, and S. A. V anstone, H andbook
of Applied Cryptography, CRC Press, 1996.
[18] C. Kaufman, R. Perlman, and M. Speciner, Network Security:
Private Communication in a Public World, Prentice Hall series
in Computer Networking and Distributed Systems Ed., 2002.
[19] B. Schneier, “Applied Cryptography: Protocols, Algorithms,
and Source Code in C,” 2nd Ed., 1996.
[20] Federal Information Processing Standards Publication, Data
Encryption Standard (DES), Dec. 1993, FIPS PUB 46.
[21] Federal Information Processing Standards Publication,
Advanced Encryption Standard (AES), Nov. 2001, FIPS PUB 197.
[22] D. Bleichenbacher and U. Maurer, “On the Efficiency of Onetime
Digital Signatures,” Advances in Cryptography — ASI-
ACRYPT, Nov. 1996, pp. 145–58.
[23] D. Bleichenbacher and U. M. Maurer, “Optimal Tree-based
One-time Digital Signature Schemes,” 1 3th Symp. Theoretical
Aspects of Computer Science (STACS’96 , L NCS(1 046 ), 1996,
pp. 363–74.
[24] L. Lamport, “Constructing Digital Signatures from a One-way
Function,” Technical Report SRI Int’l., CLS 98, Oct. 1979.
[25] R. Merkle, “A Digital Signature Based on a Conventional
Encryption Function,” CRYPTO’87, LNCS vol., no. 293, 1987,
pp. 369–78.
[26] R. Merkle, “A Certified Digital Signature,” CRYPTO’89,
LNCSvol., no. 435, 1989, pp. 218–38.
[27] M. Mitzenmacher and A. Perrig, “Bounds and Improvements
for BiBa Signature Schemes,” Technical Report (TR-02- 02),
Harvard University, 2002.
[28] A. Perrig, “The BiBa One-time Signature and Broadcast
Authentication Protocol,” 8th ACM Conf. Comp. and Commun.
Security, Nov. 2001.
[29] L. Reyzin and N. Reyzin, “Better than BiBa: Short One-time
Signatures with Fast Signing and V erifying,” 7th Australian
Conf. Info. Security and Privacy, LNCS vol., no. 2384, 2002,
pp. 144–53.
[30] Y. Desmedt, Y. Frankel, and M. Yung, “Multi-receiver/Multisender
Network Security: Efficient Authenticated
Multicast/Feedback,” IEEE INFOCOM’92, 1992, pp. 2045–54.
[31] K. Kurosawa and S. Obana, “Characterization of (k, n) Multireceiver
Authentication,” Information Security and Privacy,
ACISP’97, LNCS, vol., no. 1270, 1997, pp. 204–15.
[32] S. Obana and K. Kurosawa, “Bounds and Combinatorial
Structure of (k, n) Multi-receiver A-codes,” Designs, Codes and
Cryptography, vol. 22, no. 1, 2001, pp. 47–63.
[33] R. Safavi-Naini and H. Wang, “New Results on Multi-receiver
Authentication Codes,” Advances in Cryptology: EU RO-
CRYPT’98, LNCS vol., no. 1403, 1998, pp. 527–41.
[34] R. Safavi-Naini and H. Wang, “Multireceiver Authentication
Codes: Models, Bounds, Constructions, and Extensions,” Information
and Computation, vol. 151, 1999, pp. 148–72.
[35] H. Fujii, W. Kachen, and K. Kurosawa, “Combinatorial Bounds
and Design of Broadcast Authentication,” IEICE Trans., E79-
Avol., no. 4, 1996, pp. 502–06.
[36] D. Boneh, G. Durfee, and M. Franklin, “Lower Bounds for
Multicast Message Authentication,” Eurocrypt ’01 , LNCSvol.,
no. 2045, 2001, pp. 437–52.
[37] L. Lamport, “Password Authentication with Insecure Communication,”
Commun. ACM, vol. 24, no. 11, Nov. 1981, pp.
770–72.
[38] N. M. Haller, “The S/Key™ One-time Password System,” ISOC
Symp. Network and Distributed Security, Feb. 1994.
[39] F. Bergadano, D. Cavagnino, and B. Crispo, “Individual Single-Source
Authentication on the Mbone,” IEEE Int’l. Conf.
Multimedia and Expo, 2000.
[40] A. Perrig et al., “Efficient Authentication and Signing of Multicast
Streams over Lossy Channels,” IEEE Symp. Security and
56
Privacy, 2000.
[41] A. Perrig et al., “The TESLA Broadcast Authentication Protocol,”
RSA CryptoBytes, vol. 5, Summer 2002.
[42] A. Perrig et al., “Efficient and Secure Source Authentication
for Multicast,” 8th Annual Internet Society Symp. Network and
Distributed System Security, 2001.
[43] A. Perrig et al., “SPINS: Security Protocols for Sensor Networks,”
Wireless Networks, vol. 8, 2002, pp. 521–34.
[44] R. Gennaro and P. Rohatgi, “How to Sign Digital Streams,”
Information and Computation, vol. 165, no. 1, Feb. 2001, pp.
100–16.
[45] R. Gennaro and P. Rohatgi, “How to Sign Digital Streams,”
Advances in Cryptology, CRYPTO’97, 1997.
[46] Y. Challal, H. Bettahar, and A. Bouabdallah, “A 2 Cast: An
Adaptive Source Authentication Protocol for MultiCast
Streams,” IEEE-ISCC’2004, June 2004.
[47] H. Schulzrinne et al., “RTP: A Transport Protocol for Real-Time
Applications,” July 2003, RFC 3550.
[48] Sara Miner and Jessica Staddon, “Graph-Based Authentication
of Digital Streams,” IEEE Symp. Security and Privacy,
2001.
[49] P. Golle and N. Modadugu, “Authenticating Streamed Data
in the Presence of Random Packet Loss,” NDSS’01 : The Network
and Distributed System Security Symp., 2001.
[50] V . Paxson, “End-to-End Internet Packet Dynamics,” IEEE/ACM
Trans. Net., vol. 7, no. 3, June 1999, pp. 277–92.
[51] M. Yajnik et al., “Measurement and Modeling of the Temporal
Dependence in Packet Loss,” INFOCOM’99, Mar. 1999, pp.
345–52.
[52] C. K. Wong and S. S. Lam, “Digital Signatures for Flows and
Multicasts,” IEEE ICNP’98, Oct. 1998.
[53] C. K. Wong and S. S. Lam, “Digital Signatures for Flows and
Multicasts,” IEEE/ACM Trans. Net., vol. 7, no. 4, Aug. 1999.
[54] J. M. Park, E. K. P. Chong, and H. J Siegel, “Efficient Multicast
Packet Authentication Using Signature Amortization,” IEEE
Symp. Security and Privacy, 2002, pp. 227–40.
[55] J. M. Park, E. K. P. Chong, and H. J. Siegel, “Efficient Multicast
Stream Authentication Using Erasure Codes,” ACM Trans.
Info. and Sys. Security, vol. 6, no. 2, May 2003, pp. 258–85.
[56] M. O. Rabin, “Efficient Dispersal of Information for Security,
Load Balancing, and Fault Tolerance,” J. Association for Computing
Machinery, vol. 36, no. 2, Apr. 1989, pp. 335–48.
[57] A. Pannetrat and R. Molva, “Authenticating Real-Time Packet
Streams and Multicasts,” 7th Int’l. Symp. Comp. and Commun.,
ISCC’02, July 2002, pp. 490–95.
[58] S. Even, O. Goldreich, and S. Micali, “On-line/Off-line Digital
Signatures,” Advances in Cryptology – Crypto’89, LNCS vol.,
no. 435, 1990, pp. 263–75.
[59] S. Even, O. Goldreich, and S. Micali, “On-line/Off-line Digital
Signatures,” J. Cryptology, vol. 9, no. 1, 1996, pp. 35–67.
[60] P. Rohatgi, “A Compact and Fast Hybrid Signature Scheme
for Multicast Packet Authentication,” 6 th ACM Conf. Comp.
and Commun. Security CCS’99, Nov. 1999, pp. 93–100.
[61] T. Cucinotta, G. Cecchetti, and G. Ferraro, “Adopting Redundancy
Techniq ues for Multicast Stream Authentication,” 9th
IEEE Wksp. Future Trends of Distributed Comp. Sys. (FTDCS
’03), 2003.
BIOGRAPHIES
YACINE CHALLAL (yacine.challal@ utc.fr) is a Ph.D. student in the
department of computer science at the Compiegne University of
Technology (UTC-France). He is member of the networking group
at Heudiasyc Laboratory. He received his master’s degree in computer
science (2002) at the Compiegne University of Technology,
and the engineering degree from the National Computer Science
Institute (INI- Algiers- Algeria). He works with professor A. Bouabdallah
(UTC) on multicast security. His current research interests
are in the eras of group communication security, ad hoc networks,
and QoS.
HATEM BETTAHAR (Hatem.Bettahar@ utc.fr) received the M.S. degree
and the Ph.D. degree in computer science for work on multicast
routing and Quality of Service in IP networks from the University
of Technology of Compiegne (UTC), France in 1998 and 2001,
IEEE Communications Surveys & Tutorials • Third Quarter 2004
respectively. Since 2001 he has been an assistant professor in the
department of computer engineering at the UTC. He is a member
of the networking and optimization research group within the
Heudiasyc UMR-CNRS-6599 Laboratory. His research interests
include Internet QoS routing, multicast communication, multicast
security, and Mobile IP.
ABDELMADJID BOUABDALLAH (Bouabdal@utc.fr) received the engineer
diploma in computer science from the University of Technology of
Algiers (USTHB) in 1986, and received a master’s (DEA) degree
and Ph.D. from the University of Paris-sud Orsay (France) in 1988
and 1991, respectively. From 1992 to 1996 he was an assistant
professor at the University of Evry-Val-d’Essonne, France. Since
1996 he has been a professor in the department of computer
engineering at the University of Technology of Compiegne (UTC)
where he is the leader of the networking and optimization
research group. His research interests include Internet QoS and
security, unicast/multicast communication, and fault tolerance in
wired/wireless networks and distributed systems.
IEEE Communications Surveys & Tutorials • Third Quarter 2004 57
