1
Improvements to TESLA Protocol:
Using Secret Sharing Scheme
N. Ton, L. Yang, K. Mohamed, and K. Thirumalasetty

Abstract— In the wireless environment, the communication
medium is often untrusted and insecure. We study a general
version of the multicast authentication problem where the
underlying network, controlled by an adversary, may drop
chosen packets, rearrange the order of the packets in an arbitrary
way, and inject new packets into the transmitted stream.
Multicast authentication protocols such as TESLA employ the
principle of delayed key disclosure. These methods introduce
delay in authentication, force receiver side buffers, and
consequently are susceptible to denial of service (DoS) attacks.
Based on Shamir’s Secret Sharing Scheme and standard
cryptographic primitives, we propose a new and efficient group
multicast authentication (GMA) protocol that can be used to
augment the TELSA protocol for real time authentication. Our
GMA protocol can authenticate a potentially large number of
recipients. We prove the security of our scheme and analyze its
performance in terms of the computational efficiencies at the
sender and receiver and the communication overhead. We also
show that our scheme is robust to DoS attacks while providing
confidentiality and message integrity as well.
Index Terms— broadcast authentication, DoS attack resistant,
multicast authentication, secret sharing scheme
I. INTRODUCTION
D
enial-of-service (DoS) attacks that exhaust the senders’
and receivers’ resources are a growing concern on the Internet
and other open communication systems. Due to the nature of
wireless communication in sensor networks, attackers can
easily inject malicious data messages or alter the content of
legitimate messages during multi-hop forwarding. Sensor
network applications, therefore, need to rely on authentication
mechanisms to ensure that data from a valid source was not
altered in transit. Authentication is arguably the most
important security primitive in sensor network communication.
Source authentication ensures that the message originated from
the claimed sender, and data authentication ensures that the
data from that sender was unchanged (thus also providing
message integrity).
Broadcast authentication is a challenging problem, yet it is
of central importance as broadcast communications are used in
many applications. For example, routing tree construction,
network query, software updates, time synchronization, and
network management all rely on broadcast. Without an
efficient broadcast authentication algorithm, the sender and
receiver would have to resort to per-node unicast messages,
which do not scale well for large networks. The practicality of
many secure sensor network applications thus hinges on the
presence of an efficient algorithm for broadcast authentication.
Point-to-point authentication can be achieved fairly easily
through a purely symmetric mechanism: the sender and
receiver share a secret key used to compute a cryptographic
message authentication code (MAC) for each message. When
a message with a valid MAC is received, the receiver can be
assured that the message originated from the sender. However,
authentication of broadcast messages, especially in wireless
sensor networks, is much harder than point-to-point
authentication. In the broadcast communication environment,
problems such as non-repudiation and key management
become a serious issue. A possible solution to this problem is
to employ a public key-based protocol to authenticate sender
and receiver. Unfortunately, asymmetric cryptographic
mechanisms have high computation, communication, and
storage overhead, making their usage on resource-constrained
devices impractical for many applications.
On the other side of the same equation, multicast source
authentication based on symmetric cryptography has attracted
intense research efforts for the past few years. Canetti
presented a solution to multicast source authentication based
on verifying each different MAC using unique keys for each
message [2]. Another popular symmetric key approach for
multicast authentication uses delayed key disclosure. Delayed
key disclosure was first introduced by Cheung [3] to achieve
efficient authentication for link state routing. Chained Stream
Authentication [4] and FLAMeS [5] used similar ideas for
multicast source authentication.
In this paper, we propose a symmetric-based authentication
method, which we call Group Multicast Authentication (GMA)
protocol to improve upon the popular TESLA protocol. The
GMA protocol uses a group key that is derived from Shamir’s
Secret Sharing Scheme [29]. The premise of using a secret
sharing scheme is to allow a trusted group to authenticate
broadcast messages. More precisely, only those participants
within the network can generate the secret and authenticate
messages. In light of the known security weakness of TESLA,
our main objective is to design and develop the GMA protocol
to help eliminate DoS attack, while maintaining the
requirements of low communication and computation
overhead.
2
Organization
This paper is organized into the six sections. In section 2
section we describe the TESLA protocol and its weakness
against DoS attack. In section 3, we describe current
improvements to broadcast authentication protocols against
DoS attacks. In section 4 we describe our solution, as the
GMA protocol. In section 5, we describe experimental details
and analysis of results. Finally in section 6 we summarize our
findings and suggest possible future research avenues towards
improving the TESLA protocol.
protocols [1] using the scheme represented in Figure 1 below:
II. TESLA OVERVIEW
A. Description of TELSA Protocol
TESLA, the Timed Efficient Stream Loss-tolerant
Authentication protocol, provides source authentication in
multicast scenarios. TESLA is an efficient protocol with low
communication and computation overhead that scales to large
numbers of receivers and also tolerates packet loss. It is based
on loose time synchronization between the sender and the
receivers. Source authentication is realized in TESLA by using
Message Authentication Code (MAC) chaining [6].
The essential concept of TESLA is that the sender attaches
to each packet a MAC computed with a key k that is only
known to the sender. The receiver buffers the received packets
without being able to authenticate them. Finally, the sender
discloses k and the receiver is able to authenticate the packet.
Consequently, a single MAC per packet suffices to provide
broadcast authentication, provided that the receiver has
synchronized its clock with the sender ahead of time [1].
TESLA has the following properties:
 Low computation overhead for generation and
verification of authentication information.
 Low communication overhead.
 Limited buffering required for the sender and the
receiver, and therefore timely authentication for each
individual packet.
 Strong robustness to packet loss.
 Scales to a large number of receivers.
 Each receiver cannot verify message authenticity
unless it is loosely time-synchronized with the source,
where synchronization can take place at session setup.
 Non-repudiation is not supported; each receiver can
know that a stream is from an authentic source, but
cannot prove this to a third party [6].
B. Time Synchronization
For TESLA to be secure, the sender and the receiver need to
be loosely time synchronized. The synchronization does not
need to be precise; however the receiver needs to know an
upper bound on the sender’s time.
To achieve synchronization, TESLA does not need strong
time synchronization properties that sophisticated time
synchronization protocols provide. Instead, it can avoid the
complexity and the high overhead associated with such
Figure 1: The Receiver Synchronizes its Time with the Sender
[Courtesy of Perrig et al CryptoBytes, 2002].
Figure 1 shows the time synchronization process between the
receiver and the sender. In the protocol, the receiver first
records its local time tR and sends a time synchronization
request containing a nonce to the sender. Upon receiving the
time synchronization request, the sender records its local time
tS and replies with a signed response packet containing tS and
the nonce.
Upon receiving the signed response, the receiver checks the
validity of the signature and verifies that the nonce in the
response packet equals the nonce in the request packet. If all
verifications are successful, the receiver uses tR and tS to
compute the upper bound of the sender’s time. When the
receiver has the current time tr, it computes the upper bound
on the current sender’s time as ts ≤ tr – tR + tS1. The real
synchronization error after this protocol is δ. The receiver,
however, does not know the propagation delay of the time
synchronization request packet, so it must assume that the time
synchronization error is Δ [6].
C. Protocol Stages
We now describe the stages of the basic TESLA protocol in
the following order:
 Sender setup;
 Bootstrapping a new receiver;
 Sender Transmission of authenticated broadcast
messages; and
 Receiver Authentication of broadcast message.
1) Sender Setup
A sender distributes a stream of data composed of message
chunks Mi. Generally, the sender sends each message chunk
Mi in one network packet Pi. Many multicast distribution
protocols do not retransmit lost packets. The goal, therefore, is
that the receiver can authenticate each message chunk Mi
separately [1].
For the purpose of TESLA, the sender splits the time into
even intervals Ii, where each duration of time interval can be
1 t (uppercase ‘S’) = the sender actual time ; t (lowercase ‘s’) = an upper
S
s
bound on the sender’s local time calculated by the receiver.
3
designated as Tint, and the starting time of the interval Ii as Ti.
Thus, we have Ti = T0 + i*Tint. In each interval, the sender
may send zero or multiple packets.
Before sending the first message, the sender determines the
sending duration (possibly infinite), the interval duration, and
the number of keys N of the key chain. The sender then picks
the last key KN of the key chain randomly and precomputes the
entire key chain using a pseudo-random function F, which is
by definition a one-way function. Each element of the chain is
defined as Ki = F(Ki+1). Each key can be derived from KN as
Ki = FN-i (KN), where Fj (k) = Fj-1(F(k)) and F0 (k) = k. Each
key of the key chain corresponds to one interval, i.e., Kj is
active in interval Ij.
Since it is not recommended to use the same key multiple
times in different cryptographic operations, a second pseudorandom function F’ is used to derive the key used to compute
the MAC of messages in each interval. Hence, K’i = F’ (Ki).
Figure (2) below depicts this key derivation [7]:
key which corresponds to that interval is used to compute the
MAC of all included messages. This allows the sender to send
packets at any rate and to adapt the sending rate dynamically.
The key remains secret for d-1 future intervals. Packets sent
in interval Ij can therefore disclose key Kj-d. As soon as the
receivers receive that key, they can verify the authenticity of
the packets sent in interval Ij-d. The construction of packet Pj
sent in interval Ii is: {Mj | MAC(K’i,Mj) | Ki-d}.
As shown in Figure (2), if the disclosure delay is 2 intervals,
the packet Pj+4 sent in interval Ii+2 discloses key Ki. From this
key, the receiver can also recover Ki-1 and verify the MAC of
Pj, in case Pj+3 is lost [7].
4) Receiver Authentication
When the sender discloses a key, all parties potentially have
access to that key. An adversary can create a bogus message
and forge a MAC using a disclosed key. So as packets arrive,
the receiver must verify that their MACs are based on safe
keys: a safe key is one that is only known by the sender, and
safe packets or safe messages have MACs computed with safe
keys. Receivers’ primary function must therefore be able to
identify and discard any packets that are not safe before
receiving the keys from the senders, since they may have been
forged [1].
Figure 2: TESLA Key Chain and the Derived MAC Keys [Courtesy of Perrig et al, CryptoBytes, 2002].
2) Bootstrapping a New Receiver
Before a receiver can authenticate messages with TESLA, it
needs to be loosely time synchronized with the sender, know
the disclosure schedule of keys, and receive an authenticated
key of one-way key chain.
The sender sends the key disclosure schedule by
transmitting the following information to the receivers over an
authenticated channel (either via a digitally signed broadcast
message, or over unicast with each receiver) [6]:
 Time interval schedule: interval duration Tint, start
time Ti and index of interval i, length of one-way key
chain.
 Key disclosure delay d (number of interval).
 A key commitment to the key chain Ki (i < j-d where
j is the current interval index).
3) Sending Authenticated Packets
Each key of the key chain is used in one time interval.
Regardless of the number of messages sent in each interval, the
D. Concrete Example
We now explain how the authentication with TESLA works
with the following example2:
When the receiver receives packet Pj sent in interval Ii at local
time tc, it computes an upper bound on the sender’s clock tj
(we describe in section II.B). To evaluate the security
condition, the receiver computes the highest interval x the
sender could possibly be in, which is x = [(tj - T0)/Tint]. The
receiver now verifies that x < Ii + d (where Ii is the interval
index), which means that the sender must not have been in the
interval in which the key Ki is disclosed. Therefore no attacker
can possibly know that the key and spoof the message
contents.
The receiver cannot, however, verify the authenticity of the
message yet. Instead, it stores the triplet (Ii, Mj,
MAC(K’i,Mj)) to verify the authenticity later when it knows
K’i. The receiver will therefore buffers Mj until the
authenticity can be checked.
2
This example is further described by Perrig et al [6].
4
If the packet contains a disclosed key Ki-d (recall that d is the
key disclosure delay, or the number of intervals that the key
disclosure is delayed), regardless of whether the security
condition is verified or not, the receiver attempts to use Ki-d to
authenticate previous packets. If the receiver has received Ki-d
previously, it does not have any work to do. Otherwise, let us
assume that the last key value in the reconstructed key chain is
Kv (v < i). The receiver verifies that Ki-d is legitimate by
determining whether Kv = Fi-d-v(Ki-d). If that condition is
correct, the receiver updates the key chain. For each new key
Kw, it computes K’w = F’(Kw) which might allow it to verify
the authenticity of previously received packets.
Note that the security of TESLA protocol does not rely on
any assumptions on network propagation delay, since each
receiver locally determine if the packet is safe, i.e., whether the
sender disclosed the corresponding key. However, if the key
disclosure delay is not much longer than the network
propagation delay, the receivers will find that the packets are
not safe.
E. Robustness to DoS Attacks
In an IP multicast environment, Denial-of-Service (DoS) is
a considerable threat and requires careful consideration. A
major drawback of the original TESLA protocol lay within its
high vulnerability to DoS attacks particularly at the receiver
side. Below is a discussion of how these types of attacks are
quite possible:
F. DoS Attack on the Receiver
A particularly powerful attack method on a broadcast
environment is to flood the communication channel with bogus
data packets in order the increase the communication traffic.
This attack is serious because current multicast protocols do
not enforce sending access control.
If the receiver has a certain size buffer, flooding cannot do
much harm. The TESLA protocol requires the receiver to
buffer packets for the duration of one disclosure delay until the
authenticity of the packets can be verified; hence the buffer
size only needs to be the multiplication of the network
bandwidth and the disclosure delay time. However, if the
receiver's buffer size is not large enough, flooding could result
a full-interruption of the communication channel because the
receiver would drop packets due to a lack of buffer space.
III. IMPROVEMENTS AGAINST DOS ATTACKS
A. Symmetric Improvements on TESLA
After the introduction of TESLA by Perrig et al., several
improved versions have been proposed. TESLA (Micro
Timed Efficient Stream Loss-tolerant Authentication) [8] and
multi-level TESLA [9] have been developed to implement
the TESLA based algorithm in Wireless Sensor Networks
(WSN). The former promises much lower power consumption
for a severely resource-constrained environment, and the latter
focuses on solving the scalability problem of TESLA. But
according to Kui Ren et al., neither of those two schemes is
sufficient to be immune to DoS attacks because of the delayed
message authentication [10] common to both.
TESLA with Instant Key Disclosure (TIK) [11] eliminates
the authentication delay of TESLA. Unfortunately, it requires
precise time synchronization among all the nodes. In certain
circumstances, it is easy to achieve precise timing using
services such as Global Positioning System (GPS). GPS
receivers can synchronize nodes to a persistent-lifetime time
standard that is Earth-wide in scope to a precision of 200ns
[12] [13]. However, GPS units often cannot be used (e.g.,
inside buildings), and require several minutes of settling time.
In some cases, GPS units might also be large, high-power and
expensive compared to small sensors.
Qing Li, et al, propose an improvement called Staggered
TESLA [14], a method to reduce the delay of key disclosure,
and consequently mitigate the effects of DoS attacks. He
introduces the concept of multiple, staggered authentication
keys that can be used to create message authentication codes
(MACs) for a multicast packet. As a result, it requires an
adversary to attempt a DoS attack at a higher attack rate than is
necessary in conventional TESLA. Essentially, it merely
makes it harder for the adversary to execute DoS attacks
towards TESLA. The side effect of staggered TESLA is the
increased computational overhead due to multiple MAC
generation for each message.
B. Public Key Cryptography (PKC) to replace TESLA
The vulnerability of the family of TESLA protocols comes
from the time delay of key disclosure, which requires either the
sender or receiver to buffer the packets without immediate
authentication. The necessity for delay key disclosure is rooted
in the fact that regular symmetric MAC authentication is
insecure in a broadcast environment. As mentioned in RFC
4082 [15], TESLA, as a symmetric approach, tries to use timedelayed key disclosure to emulate the required asymmetric
property in broadcast authentication. As stated previously, this
delay key disclosure invites potential DoS attacks. An
asymmetric scheme like digital signature can easily solve the
broadcast authentication problem, but it is too costly for
resource-constrained environments such as WSN.
Recently, Kui Ren and colleagues are challenging the
principle that Public Key Schemes are not suitable for
resource-constrained environments like WSN [10] [16] based
on the following three factors:
1. New faster and low cost PKC are emerging;
2. Power Scavengers provide continuous energy for
WSN nodes;
3. Chips are becoming faster and smaller based on
Moore’s Law.
1) New emerging PKC
Perrig et al. [17] introduces a scheme called Efficient MultiChained Stream Signature (EMSS), which amortizes one
Digital Signature over numbers of packets. Thus the receiver
does not have to verify the signature for every packet. This
scheme reduces the power and computation consumption of
the receiving nodes.
5
In the basic scheme:
 Every packet will include a hash value of its direct
previous packet, i.e., Packet Pi = Mi + H(Pi-1).
 The next packet will include a hash value Pi+1 = Mi+1 +
H(Pi).
 By sending a signature packet at the end of the stream,
which contains the hash of the final packet along with a
signature, the scheme achieves non-repudiation and
authentication for all the packets.
Perrig also recommends two extensions to combat the
packet loss that makes it impossible for the receiver to verify a
chain of packets:
 Attach multiple previous packets’ hash values as
redundant;
 Split the hash into K chunks, where a quorum of any K’
chunks is sufficient to allow the receiver to validate the
information.
Though this scheme makes it possible to utilize the
traditional PKC algorithm to achieve non-repudiation and
authentication in broadcast applications, it still suffers from the
possible DoS attack. The receiver needs to wait for the final
packet’s arrival to verify a chain of previous packets. Thus
receiver buffering is necessary which induces the same
problem as TESLA.
New PKC algorithms are considered and tested in WSNs.
One of the alternatives is Elliptic curve cryptography (ECC).
The key size of ECC is much shorter than RSA at the same
security level. For example, ECC 160 bit is equivalent to RSA
1024 bit at security. Thus ECC achieves a significant
computational advantage over RSA. According to Wander’s
analysis [18], ECC 160 signature verification could take 1.61s
on Atmega 128 8 MHz processor, which is used in most
wireless senor node. Using custom-designed low power coprocessor, the time consumption could be reduced to only half
[19]. The result shows ECC’s possible role in WSNs.
Recently a company called NTRU Inc. introduces two PKC
products called NTRUEncrypt and NTRUSign. According to
Phong Nguyen, NTRU is a Lattice-based Cryptosystem [20].
Lattice-problem is one of hard problems like factoring
problem in RSA, which can be utilized as the base of PKC.
NTRU gains speed over RSA by using convolution product,
instead of the modular multiplication approach common to
RSA. Tables 1 and 2 describe this advantage.
Table 1: NTRU-251 vs RSA-1024 on 800MHz Pentium III
[21].
Encrypt
Decrypt
NTRU
Blocks/sec
Blocks/sec
NTRU
22727
10869
RSA
1280
110
Advantage
17 to 1
99 to 1
Table 2: NTRU-251 vs RSA-1024 on Palm V [21].
Encrypt
Decrypt
NTRU
Blocks/sec
Blocks/sec
NTRU
21
12
RSA
0.5
0.036
Advantage
42 to 1
333 to 1
Evaluations also prove that NTRU-251 is 52.5 times faster
during Encryption than ECC 160 and 9 times faster than ECC
160 during decryption in PDA platform [23]. NTRU may
become a good PKC for the WSN in the near future.
NTRUEncrypt is currently under review by the IEEE P1363
working group for inclusion in the 1363B standard. The only
disadvantage of NTRU is that the cipher text size is much
bigger than the message. NTRU is currently targeting at cell
phone and Radio Frequency Identification (RFID) chips
market.
2) Power Scavengers
Power Scavengers are devices able to harvest small amounts
of energy from ambient sources such as light, heat or vibration
[10]. In the next generation sensor node, ultra-low power
circuitry will be combined with power scavenger technology
such as Heliomote [23] [24]. The results indicate that, with the
advance of fast growing technology, PKC is no longer
impractical for WSNs. Although still prohibitively expensive
for the current generation sensor nodes, wide acceptance is
expected in the near future [25].
3) Crypto-Chips follows Moore’ Law
Moore’s law defines that chips computation power doubles
every 18 months. In 2000, for example, the crossbow wireless
sensor like Dot2000 was introduced with only 16KB Program
Memory, an outdoor range of 1-to-300 feet, data rate of 10
Kbps, and consumption of 15 mW during active. In 2002, the
wireless sensor Mica2Dot was introduced with 128KB
Program Memory, an outdoor range of 1,000 feet, data rate of
38.4 KBauds, and yet it only consumes 8 mW during active
[26] [27].
All the results above indicate that with the development of
fast growing technology, PKC is no longer impractical for
WSNs. Although it is still considered costly for the current 3rd
generation sensor nodes, its wide acceptance is expected in the
near future [28].
C. Group Authentication Scheme as a supplement to
TESLA
Although public-key-based authentication is becoming more
efficient and possibly suitable for WSN, we believe that a
simple but effective solution to the TESLA DoS attack
problem can be achieved by supplementing TESLA with an
additional group authentication [15] as follows:
1) Group authentication using group shared key
In this step, a secret key Kg is used as a shared secret among
group members. When broadcasting the packet Pj, the sender
(usually the base station in WSN) uses Kg to generate a group
MAC - MACKg(Pj). The receiver (usually the sensor node in
WSN) uses Kg to verify the MAC to ensure the packet comes
from within the group. The packets from the outside, without a
correct MAC, will be dropped. This immediate authentication
of packets using a group key mitigates DoS attacks from
outside adversaries. Of course, the outside adversary can copy
the legitimate packet with legitimate group MAC and continue
executing replay attack. To avoid this, we can add timestamp
6
value Ts or a random nonce during MAC generation provided
that loose synchronization (between the sender and the
receiver) has already been achieved.
secret S. (T-1) shares or less will not work (where T is the
threshold). This property can be achieved by a mathematical
scheme such as Shamir’s threshold scheme as follows:
2) TESLA authenticating the sender within the group
In step 1, only the receiver nodes know whether the sender
belongs to the group or not. Furthermore, the receiver nodes
cannot differentiate among senders within the legitimate
group, because every sender within the group has the same
shared key Kg and therefore could impersonate or even forge
messages. We suggest using TESLA to solve this insider
cheating, since TELSA is designed to specifically to identify
the sender through key commitment schedule. The
modification to the TELSA packet can be defined as follows:
Pj’= Pj||Ts || MACKg (Pj||Ts); where Pj = {Mj || i || MAC Ki
'(M j) || Ki-d} is the original TESLA packet.
1) Dealer Phase
Only dealer knows the secret S. The dealer creates secret
shares using the following steps:
1. Choose a very large prime number p, where p >
max(S,n) (n is the number of users).
2. Let a0 = S, where S is the secret.
3. Pick a coefficient of a polynomial function
ai = [0,p) for a1, ….,at-1, 0<aj <p-1
4. Compute the polynomial function to get S(i)
S (i) = a0+ a1i1 + a2i2 +…+ at-1it-1
IV. GROUP MULTICAST AUTHENTICATION PROTOCOL
We now describe our approach to solving the DoS attack
problem for broadcast authentication. The Group Multicast
Authentication uses Secret Sharing Scheme as a basis
establishing authentication of the sender. In our research
approach we assume that only the base station will broadcast
messages. All other nodes within the network topology will
receive and authenticate messages. The GMA Protocol has
three stages: Protocol Setup, Secret Share Exchange, and
Message Authentication. We now provide details on Shamir’s
Secret Scheme and the protocol steps.
A. Shamir’s Secret Sharing
The most notable property to this scheme is that it is very
efficient, using only one additional symmetric key and
processing one additional MAC. However, we believe that this
scheme is not secure against an adversary that can obtain the
group key. Since every node uses the same group key Kg at all
times, it is vulnerable to attack. We recommend using the
Secret Sharing Scheme to construct the key Kg dynamically.
After the key Kg is used, it should be destroyed in case of
unnecessary disclosure.
The idea of secret sharing is to start with a secret and divide
it into pieces, called shares, which are distributed amongst
users such that the pooled shares of specific subsets of users
allow reconstruction of the original secret [29]. A simple
example of secret sharing is as follows:
 A bank vault, secured with a combination lock, requires at
least two managers to open the vault;
 One combination code (the secret) is divided into two
sections (shares) S1 and S2 and assigned to those two
managers separately;
 In order to open the vault, the complete secret must be
used;
 The shares are combined to form the correct combination
to open vault.
Obviously this scheme is not convenient and does not scale
if the number of users increases. The (t, n) threshold scheme (t
 n) is a method to solve this problem. In the threshold
scheme, the secret S is shared by n users, each has Si, 1< I ≤ n.
Any group knowing T or more shares can reconstruct the
2) Reconstruction Phase
Any group of t or more users can pool (combine) their
shares to reformulate the secret. For example, users 1
through t can pool their shares to reformulate the secret as
follows:
S (1) = a0+ a111 + a212 +…+ at-11t-1
S (2) = a0+ a121 + a222 +…+ at-12t-1
……
S (t) = a0+ a1(t)1 + a2(t)2 +…+ at-1(t)t-1
The secret a0 = S can be recovered by using the Lagrange
interpolation formula to solve the above t numbers of
polynomials.
B. Protocol Setup
The nodes, upon deployment, establish connection with
their neighbors within the initial T seconds. At the end of this
connection establishment process, the routing table for each
node is configured. In the routing table, each node knows only
its neighboring nodes. The value of T is chosen based on the
number of nodes deployed and number of shares needed to
create the secret S – which would be used to authenticate the
messages from the base station. The nodes also need to
authenticate each neighbor, for which a session key is
required. In our research, we identified two possible session
keys.
1) GROUP KEY
A given node and its immediate neighbors are called a
group. A group key can be used to authenticate messages
coming from other group nodes. This key cannot be preprogrammed, as the nodes need not always be within each
others radio signal radius upon deployment. Hence, the group
key should be shared during the initial T seconds. Remember,
the need for this group key is to authenticate neighbors, a one
time process. Once the group key is shared, the nodes are
ready to authenticate the secret Si received from neighboring
nodes.
2) LINK KEY
In this approach, Node A generates a session key KAB and
sends it to its neighboring Node B during the initial setup time
t seconds. It does the same to all other neighbors as well. A
Link Key allows a node to authenticate each transmission
7
received at the expense of more computational time and
memory.
In our research, we found that the use of a Group Key
Scheme would increase the chances of an attacker guessing the
packet pattern and the group key due to the number of
transmissions made within a group. The probability increases
with the threshold of the number of shares Si needed to form
the secret S. Thus, we use a link key to make it difficult to
cryptoanalyze the key pattern between any two nodes. This
approach does have a negative effect of difficult key
management. However, we also found that using a Group key
approach poses some difficulty because within N network
nodes, there would be N-1 group keys.
C. Secret Share Exchange
The secret S, which is needed to authenticate the broadcast
messages from the base station is divided into t shares and are
pre-programmed in the nodes. Each node is initialized with
one share Si along with the threshold value t. Once the session
keys are established, the nodes start exchanging the shares. In
the simulations, we assume that the node 0 initiates the share
transmission. The share S0 is encrypted, using the session key
K of each neighbor, and then transmitted. Once the receiver
receives the share, it transmits its share back to node 1 and
then to all its other neighbors. Each node starts transmitting
shares after it receives a share from any one of its neighbors
and each node transmits the shares it receives to its other
neighbors. This process continues until all nodes reach the
threshold t. To better illustrate this process, let us consider a
network of 10 nodes with a threshold t = (n-1) / 2 = 4 shown
in Figure 3 below:
Figure 3: Sample Ten Node Topology
In this example, during the first iteration, node n0 sends one
share to its neighbor, n1. In iteration 2, n1 broadcast its shares
to neighbors, n2 and n3. The process continues with iteration 3
where n2 will broadcast to n6, n7, and n8; while n3 will
broadcast to n4, n5, and n9. The cascading effect allows the
shares to be transmitted to all neighboring node. The
termination criterion is reached when all nodes achieve share
threshold accumulation. Once the threshold is reached a node
will not accept any additional shares, instead it continues to
transmit shares to its neighbor until an internal threshold
counter for neighboring node is reached.
D. Message Authentication
Unlike TESLA protocol, GMA protocol decrypts the
packets as soon as they are received and verified. The receiver
accepts the packets only if the MAC ID attached to the packet
belongs to one of the neighbors attached to it, otherwise the
packet is immediately rejected. In this way, message
authentication is provided at the receiver end. The base station,
which is pre-programmed with all the MAC IDs of the nodes
deployed, decrypts the message as soon as it arrives and is
verified as originating from one of its nodes. This process of
immediate authentication allows the nodes to authenticate the
packet instead of buffering it; hence avoiding the chances of
being vulnerable to DoS attacks due to buffer overflow.
V. EXPERIMENTS & RESULTS
Analytically, we have shown that GMA protocol’s instant
authentication of multicast message provides protection
against DoS attack, and would be a suitable improvement to
the TESLA protocol. The focus of our experiment is to
analyze the GMA protocol’s efficiency and performance under
realistic network conditions. To collect these metrics, we
simulated the GMA protocol in Network Simulator (NS2
version 2.30) C++ simulation framework [30]. We subjected
the GMA protocol to a computing resources limited
environment such as a wireless sensor network in order to
understand its limits. For the simulation experiment we
collected the following metrics:
 Convergence time – the time for all nodes in the
network to receive enough shares to satisfy the
threshold requirement t.
 Round trip time – the time for node 0 to broadcast a
request message and receive responses from all
participating nodes.
We now summarize our procedure, experimental results, and
analysis.
A. Experimental Procedures
1) GMA Protocol in NS2 Implementation
There are several ways to implement network protocols in
NS2. The main approach is to subclass from the NS2 Agent
class and to implement a receive and send method. The other
option is to subclass from the NS2 Apps class. The main
difference is whether the protocol to be implemented is a
transport layer or a service layer. Protocols such as FTP are
developed as a subclass of the NS2 Apps class. We chose to
develop the GMA protocol as a direct subclass of the NS2
Agent for simplicity and ease of configuration of the
simulation experiments. Furthermore, we divided the GMA
protocol into two agent classes, GMA Agent and GB Agent
(Group Broadcast). This allows us to test the functionalities of
the GMA protocol individually. The GMA Agent class is
responsible for secret share transmission, accumulation and
reconstruction. The GB Agent class is responsible for
broadcast message and authentication. The GMA Agent tests
for convergence time for secret share exchange and
reconstruction. The GB Agent tests for round-trip group
broadcast authentication.
The GMA protocol was developed to only measure the
processing time of the protocol, thus the actual cryptographic
8
process is replaced by timing constants derived from internal
experiments and benchmark data [31][32]. The following
constants were used for cryptographic timing in the simulation
experiments:
 Share Reconstruction Time – the time taken to
reconstruct secret key S. The share reconstruction
time was derived from an implementation developed
by Crypto++ 5.2.1 [31]. The time is linearly
approximated for an 8 MHz processor WSN node
[34].
 Encryption/Decryption time – the time taken to
encrypt and decrypt secret share and broadcast
messages. We use benchmark data from the crypto++
website to estimate the encryption and decryption
time for Rijndael 128-bit [31]. We further linearly
approximate the timing process for a WSN processor.
Although not necessary, we choose to use Rijndael
1283 to simulate upper bound symmetric encryption
process.
Table 3 summarizes the parameters used for the simulation
experiments. All timing data was calculated for 128-bit data
packet.
Table 3: Parameter used for Experiments (128-bit data packet)
Processor
Share Reconstruction (sec)
Encryption (sec)
Decryption (sec)
Host
1.8 GHz
0.0043
2.1x10-6
2.1x10-6
Simulated
8MHz
0.02
0.04
0.04
We believe that these timing parameters provide a realistic
approximation of the behaviors on a WSN node to give
insights to the efficiency of the GMA protocol. There are other
cryptographic libraries that provide similar functionalities such
as libcrypt; however we only focus on Crypto++ because of its
simplicity and ease-of-use.
Along with the development of the GMA Agents, GMA
packet definitions are also developed. These packet classes
describe the characteristic packet structure used by the GMA
protocols. For simplicity, we define the GMA and GB packets
to include the following data:
 Src – the address of the sender.
 Seqno – the unique packet sequence number derived
for each each instance of the GMA protocol.
 qLength – the sender accumulated secret shares.
 ack – a flag to designate request acknowledgement.
 Data – the actual share or message.
Once the GMA protocol was developed in C++, additional
modifications are made to integrate the GMA protocol into the
NS2 executable. Figure 4 below outlines the additional steps:
3 Currently
Figure
Steps
AddDES
New
even4:AES
andto
Triple
arePacket
difficultto
to NS-2.
implement on WSN
[34].
These steps are described in Marc Greis online NS2 tutorial
[34]. Additional modifications to the NS2 Node class were
required to re-implement the add neighbor method because of
a potential memory leak. The modification is required since
each node within the GMA protocol requires a record of its
neighbor in order to send data packets to a neighboring node.
2) Simulation Testing
Our testing approach for the GMA protocol is to develop
random topologies for 50, 100, and 200 node networks. We
also assume that message packets are received based on the
defined links of the topology. That is, although messages are
broadcasted in free space, the reception of the packets is
defined by the pre-established routing table. We also further
assume that the nodes are closely spaced to reach their
neighboring nodes. To facilitate rapid test execution and data
collection, we developed python scripts to automate the test
generation. The timing data from the simulation are then
logged into text files. We now briefly describe our approach to
topology generation and test creation.
a)
Topology Generation
To create large random topology for our simulation, we
employed the Georgia Tech Internetwork Topology Model
(GT-ITM). The GT-ITM can create two classes of typology,
hierarchical or transit-stub. We chose to use the transit-stub
model because it closely represents the types of topology
commonly found in wireless sensor networks. Furthermore we
found that the transit-stub model was more stable and easier to
configure than the hierarchical model. Figure 5 shows a
sample GT-ITM input script:
ts 5 33
3 0 0
1 20 3 1.0
2 20 3 0.6
8 10 3
0.42
Figure 5: Sample gt-itm Transit-stub Input Script.
A transit-stub model produces hierarchical graphs by
composing interconnected transit and stub domains, as shown
in Figure 6 [30]. GT-ITM first constructs a connected random
graph where each node in that graph represents an entire
transit domain. Each node in that graph is then replaced by
another connected random graph representing the backbone
topology of one transit domain. Next, for each node in each
transit domain, it generates a number of connected random
graphs representing the stub domains attached to that node.
Finally, it adds some number of additional edges between pairs
of nodes, one from a transit domain and one from a stub
domain.
9
Figure 7 below shows various topologies that we initially
analyzed.
Figure 6: Transit-stub Graph Model.
Figure 7: Sample Topology Analyzed.
From the GT-ITM input script, 5 transit-stub graphs of 50
nodes will be created upon execution. Each graph will have
three stub-stub edges per transit node, with no extra transitstub or stub-stub edges. The line “1 20 3 1.0” indicates that
there will be one transit domain. The next line “2 20 3 0.6”
specifies domains have (on average) two nodes, and an edge
between each pair of nodes with probability 0.6. The last line
“8 10 3 0.42” indicates that each stub domain will have (on
average) eight edges, and edge probability 0.42. The number
of nodes is calculated as 1*2* (1+ 3*8) = 50.
b)
Test Creation
The test scripts are created from the output of the GT-ITM
utility, and the NS2 template file is manually created. A
python script was developed to clean up the GT-ITM output
and additional NS2 commands are added for executed test file.
Specifically we add commands to instantiate the GMA Agents
and to add neighbors to each network node. We change the
duplex-link-interface command to duplex-link in order correct
the version difference between GT-ITM and the latest NS2.
Finally, we also add the appropriate link bandwidth to simulate
a wireless sensor node. For our experiment we use a link
bandwidth of 10 Kbps [32]. The packet size is initially set to
128 bits to simulate large size packets, and to simulate when
the secret shares are divided into large numbers from a very
large prime number.
The same tests are applied to the second half of the GMA
protocol to test the group broadcast authentication. In this
round of tests, we simply duplicate the GMA Agent test file
and perform a search and replace of the GMA Agent to GB
Agent. These tests are designed to collect data on round-trip
acknowledgement of the node 0 transmission. For the sake of
simplicity we model node 0 as the base station. At a particular
instance in time we give the command to node 0 to initiate a
broadcast message to its neighbor. This message would
cascade down the network until all nodes received and
responded to node 0’s request.
B. Analysis of Results
Prior to running the simulation, we manually calculate the
share transmission of a network of ten nodes to determine the
initial observables. From our manual calculation, we
hypothesize that the root node (node 0) would be the first node
to reach threshold share accumulation. Likewise, leaf nodes
would be the last nodes to reach threshold. Furthermore, these
observations seem to be independent of the node topology.
A set of five random topologies for a network of 50, 100,
and 200 nodes are simulated in NS2. Figure 8 shows a sample
output for a 50 node topology test. The convergence time and
round-trip time are collected for the test cases individually.
Figure 8 shows the result for convergence time for different
share threshold, and network topology size.
Figure 8: Transit-stub Network with 50 Nodes at10 Kbps.
From the convergence timing data, we found that the
simulation supported our analytical (manual calculation)
observation. Specifically, we found that the root node (node 0)
is the first node to achieve threshold share accumulation; while
leaf nodes tend to be the last nodes to achieve threshold share
accumulation. The two observations seemed to also be
independent of the network topology shape.
The experimental result also provided us with a very useful
observation. For a large packet size such as 128 bit and limited
bandwidth, there is a critical point where threshold share
accumulation will never be achieved by any nodes. This
phenomenon is shown in Figure 9 for a network of 200 nodes
and secret share threshold of 20. The phenomenon occurred as
a result of packet drops due to limited bandwidth and large
secret share size. This observation suggests that the initial
secret share generation must be carefully crafted such that it is
a function of network size and bandwidth. We believe that the
secret share size is inversely proportional to the network size.
Further research is required to define the optimum share size
with respect to the network size.
10
research to fully understand its potential. We identify the
following areas for further research and development:
 Protocol analysis of the secrecy of shared secret key.
 Analysis of dynamic secret share distribution for adhoc networks.
 Analysis of the scalability of group multicast
authentication for very large networks.
 Implementation of the GMA protocol within
OmNet++.
 Implementation of the GMA protocol on WSN node.
ACKNOWLEDGEMENT
Figure 9: Convergence Time for Threshold t= 3, 10, and 20.
The experimental data for round-trip time was also
comparable with our analytical hand-calculation observation.
In particular, we anticipated that the round-trip time would be
exponentially proportional to the network size. Figure 10
provides partial evidence that supports our conclusion. We
believe that this phenomenon is the result of highly connected
network topology structure as shown in Figure 8. The message
packets travel redundant paths causing duplication of the
original message.
The data also suggests that GMA protocol could be a viable
multicast authentication protocol for small to medium size
network topology. For large and very large (i.e. network size
exceeding 1000 nodes) networks the GMA protocol could
operate in a regime that may be unsuitable for highdemand/high-throughput operations, but usable for sporadic
communication environment.
The authors wish to thanks Dr. Jens-Peter Kaps for his time
and support. The authors also wish to thank our families for
their enduring patience and support.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
12
[7]
10
Round-trip time (seconds)
[8]
8
6
[9]
4
2
[10]
0
50
100
200
# of nodes
Figure 10: Round-trip Time for 50,100,200 Node Topology.
VI. CONCLUSION
[11]
From our preliminary research we have shown that our
Group Multicast Authentication Protocol (GMA) can provide
protection against broadcast and multicast DoS attack through
immediate packet authentication. Our experiment also showed
that GMA protocol is efficient when designed properly with
the appropriate share size with respect to network group size.
However, we believe that the GMA protocol requires further
[12]
[13]
A. Perrig, R. Canetti, J. Tygar, and D. Song, “The TESLA broadcast
authentication protocol”, RSA CryptoBytes, 2002.
R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B. Pinkas,
“Multicast security: A taxonomy and some efficient constructions”, in
INFOCOMM’99, 1999.
S. Cheung, “An efficient message authentication scheme for link state
routing”, in Proceedings of the 13th Annual Computer Security
Applications Conference, December 1997, pp. 90–98.
F. Bergadano, D. Cavagnino, and B. Crispo, “Chained stream
authentication”, in Proceedings of the 7th Annual Workshop on
Selected Areas in Cryptography, August 2000, pp. 144–157.
B. Briscoe, “FLAMeS: Fast, loss-tolerant authentication of multicast
streams,” Technical report, BT Research, 2000.
A. Perrig, J. Tygar, “Secure Broadcast Communication in Wired and
Wireless”, Kluwer Academic Publishers, Norwell, MA 2003.
A. Perrig, R. Canetti, D. Song, and J. D. Tygar, “Efficient and secure
source authentication for multicast”, in Proceedings of Network and
Distributed System Security Symposium, February 2001.
Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, J. D. Tygar,
“SPINS: Security Protocols for Sensor Networks”, in Proceedings of
Seventh Annual International Conference on Mobile Computing and
Network, July 2001.
Donggang Liu, Peng Ning, “Multi-Level µTESLA: A Broadcast
Authentication System for Distributed Sensor Networks”, ACM
Transactions on Embedded Computing Systems (TECS), Vol. 3, No. 4,
pages 800--836, November 2004.
Kui Ren, Kai Zeng, Wenjing Lou, and Patrick J. Moran, "On broadcast
authentication in wireless sensor networks", Lecture Notes in Computer
Science, vol. 4138, pp. 502-514. International Conference on Wireless
Algorithms, Systems, and Applications (WASA 2006), Xi'an, China,
August 15-18, 2006.
Yih-Chun Hu, Adrian Perrig, David B. Johnson, "Packet Leashes: A
Defense against Wormhole Attacks in Wireless Ad Hoc Networks”
Technical Report TR01-384 December 17, 2001, Revised: September
25, 2002, http://monarch.cs.cmu.edu/monarchpapers/tikreport.pdf
Jeremy Elson, Deborah Estrin, “Time Synchronization for Wireless
Sensor Networks”,
http://www.circlemud.org/~jelson/writings/timesync
J. Mannermaa, K. Kalliomaki, T. Mansten, and S. Turunen. “Timing
performance of various GPS receivers”. In Proceedings of the 1999 Joint
11
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
Meeting of the European Frequency and Time Forum and the IEEE
International Frequency Control Symposium, pages 287–290, April
1999.
Q. Li and W. Trappe, “Staggered TESLA: A Scheme for Multi-grade
Multicast Authentication,” submitted to IEEE Globecom2005.
A. Perrig, D. Song, R. Canetti, J.D.Tygar, B. Briscoe, RFC 4082 Timed
Effiecient Stream Loss-Tolerant Authentication (TESLA): Multicast
Source Authentication Transform Introduction.
Gunnar Gaubatz, Jens-Peter Kaps, Berk Sunar, Public Key
Cryptography in Sensor Networks Revisited, retrieved on December 9 th,
2006 from:
http://www.crypto.wpi.edu/Publications/Documents/Gaubatz
KapsESAS04.pdf
Adrian Perrig, Ran Canetti, J.D. Tygar, Dawn Song, “Efficient
Authentication and Signing of Multicast Streams over Lossy Channels”,
retrieved on December 9th 2006 from
www.ece.cmu.edu/~adrian/projects/stream/stream.pdf
A. S. Wander, N. Gura, H. Eberle, V. Gupta, and S. Chang Shantz.
“Energy Analysis of Public-Key Cryptography on Small Wireless
Devices,” IEEE PerCom, March 2005.
G. Gaubatz, J.-P. Kaps, E. Öztürk, and B. Sunar, "State of the art in
ultra-low power public key cryptography for wireless sensor networks",
Workshop on Pervasive Computing and Communications Security PerSec'05, IEEE Computer Society, pages 146-150, March, 2005
Phong Nguy, “Lattice-based cryptosystems”, presentation made on
November 26th, 2002, retrieved on December 9th, 2006 from
http://www.stork.eu.org/slides/12_stork-phong.pdf
Cryptolab FAQs, Ntru Inc., retrieved on December 9 th, 2006 from
http://www.ntru.com/cryptolab/faqs.htm#two
Diniel Bailey , “Performance and Security of NTRU Security Suite” ,
Presentation in Project: IEEE P802.15 Working Group for Wireless
Personal Area Networks (WPANs) February 22, 2000.
G. Gaubatz, J. Kaps, and B. Sunar, “Public Keys Cryptography in
Sensor Networks – Revisited,” In the Proceedings of the 1st European
Workshop on Security in Ad-Hoc and Sensor Networks (ESAS 2004).
A. Kansal, D. Potter and M. Srivastava, “Performance Aware Tasking
for Environmentally Powered Sensor Networks,” ACM Joint
International Conference on Measurement and Modeling of Computer
Systems (SIGMETRICS), 2004.
W. Du, R. Wang, and P. Ning “An Efficient Scheme for Authenticating
Public Keys in Sensor Networks,” In Proceedings of The 6th ACM
International Symposium on Mobile Ad Hoc Networking and
Computing (MobiHoc), Pages 58-67, May 25-28, 2005.
Dario Rossi, “Sensors as hardware Motes Evolution”, presentation
retrieved on December 17th, 2006 from
www.telematica.polito.it/wsn/ppt/WSN1_Hardware.pdf
Mica2Dot Datasheet, retrieved on December 17th, 2006 from
http://bullseye.xbow.com/Products/Product_pdf_files/Wireless_pdf/MIC
A2DOT_Datasheet.pdf
W. Du, R. Wang, and P. Ning “An Efficient Scheme for Authenticating
Public Keys in Sensor Networks,” In Proceedings of The 6th ACM
International Symposium on Mobile Ad Hoc Networking and
Computing (MobiHoc), Pages 58-67, May 25-28, 2005.
A. J. Menezes, P. C. V. Oorschot, and S. A. Vanstone. Handbook of Applied Cryptography. CRC Press, Boca Raton, FL, 1997. pp 524-528.
The Network Simulator – ns-2, Information Sciences Institute. [Online]
http://www.isi.edu/nsnam/ns/. [Accessed Sept. 12, 2006]
Crypto++ 5.2.1 Benchmarks, Cryptopo Website. [Online]
http://www.cryptopp.com/benchmarks.html. [Accessed October 28,
2006].
[32] Y. Law , J. Doumen , P. Hartel, “Survey and benchmark of block
ciphers for wireless sensor networks,” ACM Transactions on Sensor
Networks (TOSN), v.2 n.1, p.65-93, February 2006.
[33] Marc Greis, “Tutorial for the ns”, Information Sciences Institute.
[Online] http://www.isi.edu/nsnam/ns/tutorial/. [Accessed November
11, 2006].
[34] C. Karlof, N. Sastry, D. Wagner,” TinySec: a link layer security
architecture for wireless sensor networks”, SenSys '04: Proceedings of
the 2nd international conference on Embedded networked sensor
systems, 2004, pp-162-175.