4.1 Security analysis
The security strength of the proposed scheme is based on some security parameters, including the private ball size l, the private ball number t, the signature ball number k, and the number of messages that one key pair can be used to sign, r (as defined in Appendix A). We discuss these security parameters below.
Theorem 1. Security level is based on security parameters l, k, t, r. The parameter l decides the security strength against brute-force attack. The parameters k, t, r decide the security strength against chosen message attack. For defending chosen message attack, we provide k(logt−logk−logr) bits of security.
Proof:
Let f be a one-way function operating on l-bit strings, for a security parameter l.
And fl is the length of the one-way function output on input of length l. Attackers can do brute force attack against one way function by deriving private ball ri from the Merkle tree’s leaves leafi. The private ball ri and Merkle tree’s leaves leafi has one way relationship as . The suggested security parameter l is 80bits in HORS.
) ( i
i f r
leaf =
Because the sender will disclose the private balls with signatures, attackers may do a chosen message attack by collecting the private balls for forging the signature.
We assume that the attacker of obtains signatures on r messages of its choice (but the choice is independent of Hash), and then tries to forge a signature on an any new message m of its choice. We are interested in the probability that the adversary is able to do so without inverting the one-way function f. it is quite easy to see that this
probability is at most (rk/t)k for each invocation of Hash, i.e., the probability that after rk elements of T are fixed, k elements chosen at random are a subset of them. In other words, we get k(logt−logk−logr) bits of security. ◊
4.2 Selection of parameters
We discuss the system parameters in this section. These parameters influence security strength and performance of our scheme. In general, higher security strength brings lower performance and vice versa. Our strategy is to provide enough security strength as we need and we assume 64 bits security is enough. We take security parameters l=80 against brute-force attack and t =1024, k=16, r=4 to provide 64 bits security against chosen message attack.
First, we explain the meaning of parameters in the following; k: the number of balls in a signature; h: the cost of computing a hash function; d: the number of public balls as the public key; fl: the public ball size (bits); r: the number of signatures that one key pair can generate; l: the private ball size (bits); h1: the size of private ball’s identity. We discuss how the parameters influence the performance below.
Lemma 1. Given the parameters k, h, d, fl, r, l h1, the storage requirement, computation cost and communication overhead of system are related to tree height h.
Computation cost (of receiver): k *h
Communication overhead: d* fl +r*(kl+ flkh)
Storage requirement (of receiver): d* fl +kl+ flkh+rk*h1 Proof:
The communication overhead for the whole life of a keypair includes the public key size, which consists of d b-bit root, and r signature size, which each consists of k
private balls and k authentication path. The storage requirement equals the public key size, one signature size and rk private ball’s identity. Receiver need to compute the root using leaf and its authentication path. Verifying one private ball needs h hash computation. Receiver need to verify k private balls for one signature. So, the number of hash computation is equal to k *h. ◊
Lemma 2. Given t private balls and d public balls as public key, the tree height is related to public key size
d t TreeHeight=ln −ln Proof:
The height of tree is decided by the number of private balls and the number of public tree root. The number of leaves of a tree is t/d. The height of the binary tree with t/d leaves is lnt /d, equal to lnt−lnd. ◊
With the same amount of leaves, we construct several trees instead of one tree in order to amortize the height of tree over several trees. We do so due to a fact that the higher tree is, the lower public key size is but the more additional public balls should be sent. We want to find an optimal balance between public key size and signature size. The public key and signature will store in sensor node’s memory at the same time, so the sum of their size should be as small as possible. In that case, how many trees we should construct for the smallest storage requirement for sensor node? We discuss in Theorem 2.
Theorem 2. Given the parameters l, fl, k, t for enough security strength, we construct d trees in our scheme and the parameter d is decided by
.
Proof:
The number of trees we construct is decided by the lowest storage requirement.
We know that the storage requirement for sensor node is d* fl +kl+ flkh+rk*h1
We know that the higher tree is, the more additional nodes sent. Then, what if we increase the degree of Merkle tree for constructing a tree with low height? This is not a good idea due to theorem 3.
Theorem 3. Given t leaves, the 2-degree Merkle tree has the lowest upper bound of additional nodes needed to be sent.
Proof:
The upper bound of additional nodes we transmit in a signature is ,
which is equal to . Given t leaves, we desire .
Real time distribution of traffic data
A municipality wishes to collect traffic information from sensors distributed over the streets. The sensors need to authenticate the command from the base station (the municipality) and transmit sensed data through secure channel (with pair-wise keys shared between sensor nodes and base station) back to base station. The system requirements are as follows:
The data rate of the stream is about 10 Kbps, about 20 packets of 64 bytes each
are sent every second. The packet drop rate is at most 5% for some recipients, where the average length of burst drops is 5 packets. The verification latency should be less than 10 seconds.
Our proposed scheme helps the sensor nodes to authentication the command from the base station. We set the system parameters l=80, t=1024, k=16,r=4, flt=160 for 64 bits security which can be computed from theorem 1. This means the attackers need to perform 264 hash computations during a key-pair life to forge a signature. In BiBa [2], they provide 58 bits security for real time stock quotes application. So we consider 64 bits security is enough. In this case, the optimal public key size is 640 bytes which are 32 tree roots comes from theorem 2. The figure 4-1 shows the optimal public key size we choose due to the minimum storage requirement.
100 101 102 103 104
Figure 4-1.The optimal public key size
When we decide the optimal number of trees we should construct, we generate the key pair using key generation algorithm (figure 3-2). In this case, the key
generation is illustrated by figure 4-2.
Private key: 1024 80-bit random numbers Public key: 32 160-bit hash values
32 trees, each has t /d=32 leaves and height = lnt−lnd= 5
Figure 4-2. The key pair of our scheme
4.4 Comparison
μTESLA [18] is so far an efficient broadcast authentication protocol in wireless sensor networks. Therefore, we compare our scheme with it. When comparison with μTESLA, we have four advantages overμTESLA, which are listed below:
1. No time synchronization needed
In μ TESLA, sender and receivers must synchronize time first and use disclosure delay to achieve asymmetric property needed in broadcast authentication.
Our scheme use key pair including private key for signing messages and public key for verifying messages to achieve asymmetric property. We have no requirement for time synchronization, which is not always practical in large sensor network.
2. No receiver buffer needed
InμTESLA, the receivers have to buffer the packets until the corresponding MAC key disclose. Instead, the receivers need no buffer in our scheme.
3. Individual authenticate
Receivers can individual authenticate the received packets without waiting for another packets. In μTESLA, the receivers must wait the packet with disclosed MAC key.
4. Instant authenticate
Receivers can instant authenticate the received packets instantly in our scheme while receivers must wait for the packets with disclosed MAC key in InμTESLA.
We compare our scheme with other two efficient one time signature schemes, BiBa [2] and HORS [3], here. For a general case, we take the system parameters as following for the same security level, t=1024, k=16, r=10, h=5. The proposed scheme performed better than BiBa and HORS in three criterions, which are computation overhead, communication overhead and storage requirement.
BiBa HORS Proposed
Communication (bytes) 5250 5250 288
Storage (bytes) 5152 5152 192
Energy cost Large Large Little
Time synchronization Yes No No
Table 4-1.Comparison with other one time signature schemes