A drawback of the original TESLA protocol is that the receiver needs to buffer packets during one disclosure delay before it can authenticate them. This might not be practical for certain applications if the receivers cannot afford much buffer space and bursty traffic might cause the receivers to drop packets due to insufficient buffer space. Moreover, as we show later in section 4.2, the requirement of receiver buffering introduces a vulnerability to a denial-of-service attack. To solve these problems caused by receiver-buffering, we propose a new method to support immediate authentication, which allows the receiver to authenticate packets as soon as they arrive.
The basic observation of this method is that we can replace receiver buffering with sender buffering. If the sender can buffer packets during one disclosure delay, then it could store the hash value of the data of a later packet in an earlier packet and hence as soon as the earlier packet is authenticated, the data in the later packet is authenticated through the hash value as well.
In the new scheme, the sender buffers packets for the duration of one disclosure delay. For simplicity of illustration, we assume that the sender sends out a constant number of packets per time interval. To construct the packet for the message chunk in time interval , the sender appends the hash value of the message chunk to and then computes the MAC value also over with the key . Figure 2 illustrates how the packet is constructed by appending , , along with the disclosed key . (Note that the stands for message concatenation). When the packet arrives at the receiver which discloses the key it allows authentication of packet sent in interval . carries a hash of the data in . If is authentic, is also authentic and therefore the data is immediately authenticated. Also note that if is lost or dropped due to violation of the security condition, will not be immediately authenticated and can still be authenticated later using the MAC value.
HMjpkd MACKiHMj Kimd Dj Djpkd Mjpkd HMjp2kd MACKipdHMj
Figure 2: Immediate authentication packet example.
and .
Iip3 Pjp7 Pjp8
If each packet can only carry the hash of one other packet, it is clear that the sending rate needs to remain constant. Also it is clear that if a packet is lost, the corresponding packet cannot be immediately authenticated. To achieve flexibility for dynamic sending rate and robustness to packet loss, the sender can add the hash values of multiple future packets to a packet, similar to the EMSS scheme [25].