We implemented a TESLAprototype in Java. We use the MD5 hash function [26] in conjunction with the HMAC construction [4] for our pseudo-random function and the MAC. To limit the communication overhead, we only use the most significant bits of the output, which saves space over the standard bits and gives sufficient security. The initial synchronization packet is signed using an 1024 bit RSA signature [27].
In our design, all of the functionality for TESLAremains in the application layer. This design principle follows the approach of ALF, which Tennenhouse and Clark introduce [9]. In ALF, the application knows best how to handle the data, as opposed to placing services in the network or transport layer of the OSI stack. ALF is ideally suited for TESLA. Since the authentication of packets is delayed, the application knows best how to handle unauthenticated information, which might be declared invalid later. We see two main possibilities for the application to interact with a TESLAmodule on the receiver side. First, we could buffer all incoming packets and deliver them only after their authenticity is assured. Second, we could deliver incoming packets directly, but inform the application through an up-call as soon as a packet is authenticated or if the packet is faulty. We implemented the second alternative.
On the other hand, however, there are also arguments for implementing TESLAin the
transport layer, along with other security services [18]. Both variants
of interaction with the application are possible. In the first case, the network
layer buffers the stream data, and forwards it as soon as the data authenticity
is guaranteed.
In
the second case, the network layer would directly forward the data to the
application, but this would require another mechanism for the network layer to
inform the application about the validity of the data. To prevent applications
from using data that was not authentic, we can imagine a scheme where the sender
encrypts the data in each packet with a separate key and releases the key in a
later packet. In this case, the application would receive the encrypted data,
but could only use it after it receives the decryption key.
We use UDP datagrams for all communication to simulate multicast datagrams. We would like to point out that using a reliable transport protocol such as TCP does not make sense in this setting, because TCP interferes with the timing of packet arrival and does not announce incoming packets to the application if the previous packets did not arrive. This is a problem since our TESLAmodule resides in the application space. Furthermore, since TESLAis particularly well suited for lossy data streams, UDP makes perfect sense, whereas TCP is used in settings which require reliable communication.
To simplify the exposition of the protocols, we consider the case of Scheme IV, which uses one authentication chain only, as an examplar.