Now that we have presented a detailed description of our scheme, we shall provide an analysis per our original requirements in section 4.1 and compare its performance to PARM in section 4.2.
4.1. Protocol Analysis
We analyze the security of our scheme in terms of its ability to authenticate packets, resume from packet loss, reject replayed packets, recover from reordered packets, and resist pollution attacks.
4.1.1. Packet Authenticity
Given any received packet, a receiver can determine the authenticity of the packet. We assume every receiver possesses an authentic copy of a legitimate sender’s temporal public key and that h is a collision-resistant hash function. To successfully forge a packet by injection or modification, an adversary must either obtain the set of temporal secret key chains or perform a brute force attack on the hash function to find collisions. In our scheme, only the sender has knowledge of the set of TSK chains. Since the security strength of a hash function against a brute force attack depends solely on the length of the resultant hash value, our scheme provides a strong collision resistance of 2p(n/2), where p is the number of hash values per packet and n is the number of bits per hash value. For a hash function to have strong collision resistance, it is computationally infeasible to find any pair ( yx, ) such that
) ( ) (x h y
h = . Therefore, it is impractical for an adversary to inject new packets or modify existing ones.
4.1.2. Packet Loss Robustness
Although a network may inadvertently lose packets or an adversary may deliberately drop packets, a receiver can continue to verify other received packets.
Because each packet’s verification information contains both the hash value and the amount of hash calculations per hash value, a receiver can validate each packet both immediately and independently of other packets. Thus, the loss of packets does not affect the ability of the receiver to check the authenticity of other packets.
4.1.3. Packet Replay Rejection
Because an adversary can collect packets and replay them later, a receiver must be able to identify a duplicate packet and discard it. In our scheme, each packet contains evidence of each packet. Before evidence generation, we append a sequence a number to each packet. We then generate the evidence over both the content of the original packet and its sequence number. Therefore, the receiver concurrently validates the sequence number when it checks the authenticity of the packet. Since the receiver keeps track of spent sequence numbers, it can expose replayed packets.
4.1.4. Packet Reordering Robustness
Due to the exposed nature of networks, an adversary can intercept and reorder packets before delivering them to the receiver. The receiver must retain the ability to immediately validate any packet even though it receives packets out-of-order. With the exception of the TPK, which we assume the receiver possesses, a packet’s verification information is self-contained. Based upon the contents of the packet, a receiver can calculate the index of each segment of the evidence. Since the evidence contains both a segment’s hash value and the number of times to execute the hash, the receiver can individually authenticate each packet. Therefore, a receiver can verify reordered packets without delay.
4.1.5. Denial of Service Resistance
An adversary can initiate various types of denial of service (DoS) attack against its target, depending on which resource of its target it is attempting to deplete. In a network environment, the adversary can attack the sender, the network infrastructure, or the receiver. Because the sender must deliver the current temporal public key to its receivers, an adversary can launch a DoS attack against the sender by repeatedly requesting the TPK. Secure distribution of the TPK is beyond the scope of this work, thus, we do examine this situation. Moreover, we also do not consider DoS attack which exhaust network bandwidth. However, we must investigate the possibility of an adversary launching a DoS attack on the receiver’s computational and storage resources. Since our scheme only relies on fast one-way hash functions for its cryptographic primitive, a receiver can quickly verify a received packet’s evidence.
In addition, a receiver does not buffer forged packets since it can immediately check the packet’s validity with the evidence. Thus, our scheme can resist DoS attacks that try to consume a receiver’s computation and storage resources.
4.2. Overhead Comparison
In this section, we compare the computation, communication, and storage costs of our scheme to PARM.
4.2.1. Computation
To verify a packet, PARM must hash each segment of a packet’s evidence the number times specified in the usage table. Thus, validation consumes
∑
−=
hash operations per packet. Because the receiver recalculates hash operations for each packet, this technique wastes a considerable number of computations. This trend is especially detrimental towards the end of a long hash chain. Under the
best-case scenario, our scheme simply requires one hash operation per packet segment.
That is, verifying a packet uses 1+ p hash operations. While operating in near optimal conditions in which packets arrive slightly out-of-order, our scheme requires significantly fewer computations than PARM, since it only hashes each segment of evidence a few times. A receiver need only hash each segment to the nearest hash value within the window of current hash values. For all remaining situations, our scheme expends the same amount of computation cost as PARM.
4.2.2. Communication
The communication overhead per packet, which consists of the evidence, remains constant in size for both PARM and our scheme. The overhead of PARM depends on the number of segments p per packet and the size of each TSK element n, that is, a cost of p *n bits. Our scheme requires an additional p*
⎡
lg(l)⎤
bits forthe usage number of each segment and
⎡
lg(q bits for the sequence number. Thus, )⎤
the total overhead per packet is p*(n+
⎡
lg(l)⎤ ⎡
)+ lg(q)⎤
bits. Since the additional overhead grows logarithmically, it is not a significant increase.4.2.3. Storage
In both PARM and our scheme, the sender stores a set of temporal secret key chains. The sender generates k chains of length l with n-bits per TSK elements; thus, the set of TSK chains totals k*l*n bits of storage. Moreover, the sender tracks the usage amount of each TSK chain; therefore, both schemes require k*
⎡
lg(l)⎤
bitsof additional space.
These two schemes differ in the size of the space used by the receiver. To store the TPK in PARM, the receiver uses a buffer size of k *n bits. Because a receiver must also remember the number of times each TSK chain is used, it must set aside
⎡
lg( )⎤
* l
k bits of space. In contrast, a receiver implementing our scheme does not keep track of a usage table. On top of the storage needed for the TPK, however, the
receiver must buffer w*k*n bits of space for the window of w current hash values per chain. To prevent replay attacks, it also must set aside q*
⎡
lg(q)⎤
bits toremember the expended sequence numbers. Because PARM requires time synchronization between the sender and receiver, its receiver cannot validate packets until it obtains all previous packets, which can lead to buffer overload. Conversely, our scheme allows a receiver to immediately authenticate any packet it receives despite out-of-order or lost packets.