## Dynamic Key Sharing and Fuzzy Adaptive Route Selection
### Dynamic Authentication Key Sharing  
In PVFS, LBRS, SEF, FASIN, KIF, DEF, FASIN and IHA, the verification keys are disseminated to the intermediate verification nodes only once during the initialization phase and are assumed to never expire. The disadvantage of such a key sharing scheme is that it is static, and an adversary can compromise the intermediate verification nodes and gather the authentication keys stored on those nodes. To counter this problem and make the proposed scheme safer and capable of adaptively responding to the increasing attack, we propose that the nodes in the event reporting cluster dynamically update and share their authentication keys with the recently chosen intermediate verification nodes. We assume that every member node is preloaded with a key from the global key pool which serves as a seed-key for the one-way hash chain of generation keys. Let's say that a node \(n_{i}\) gets \(key_{m}^{n_{i}}\) during the key assignment stage. This key is used as a seed key to create a one-way hash chain of size, \(m\): \(key_{m-1}^{n_{i}},key_{m-2}^{n_{i}},\ldots,key_{1}^{n_{i}},\ key_{0}^{n_{i}}\), where \(key_{j}^{n_{i}}=\ f^{m-j}(key_{m}^{n_{i}})\), using a pseudo random one-way function \(f\). The keys will be used in reverse order of their creation. That is \(key_{0}^{n_{i}}\) will be the first authentication key to share with the intermediate verification node. Either all the keys can be created at once and stored at the node, or only seed key \(key_{m}^{n_{i}}\) can be stored and the other keys can be computed on demand. In practice, the hybrid method helps decrease the storage overhead due to the small re-computation effort [36]. The storage efficient mechanism in [36] only requires \(\log(m)\) storage and \(\log(m)\) computation to access a key in a one-way hash chain of size \(m\). Node \(n_{i}\)'s seed key is \(key_{m}^{n_{i}}\). The one-way hash chain created by node \(n_{i}\) is \(key_{m-1}^{n_{i}},\ key_{m-2}^{n_{i}},\ldots,key_{1}^{n_{i}},\ key_{0}^{n_{i}}\). A one-way hash chain is created recursively: \(key_{m-1}^{n_{i}}=\ f(key_{m}^{n_{i}})\). Therefore, node \(n_{i}\) creates any \(key_{j}^{n_{i}}\) in a one-way hash chain using \(f\):\(key_{j}^{n_{i}}=\ f^{m-j}(key_{m}^{n_{i}})\). By definition: \(f^{j}(k)=\ f^{j-1}(f(k))\). The size of the one-way hash chain is \(m\). Node \(n_{i}\) shares its keys with the verification nodes in this order: \(key_{0}^{n_{i}}\), \(key_{1}^{n_{i}},key_{1}^{n_{i}},\ldots,\ key_{m-1}^{n_{i}},key_{m}^{n_{i}}\). We assume that the length of each key chain is such that they last for the entire duration of the communication [37]. The size of the one-way hash chain can be calculated by estimating the network mission lifetime and the battery life of the sensor nodes under normal operation of the network [38]. Given the battery life of each sensor node \(b_{i}\), \(i=1,\ \ldots,n\), and a network mission lifetime of \(B\) for normal operation of the network, we can calculate the size of the one-way hash chain \(m_{i}\) for sensor node \(n_{i}\), or a single size \(m\) for all the hash chains. \[m_{i}=\frac{b_{i}}{l}\ ;i=1,\ldots,\ n.\]  
\[m=\frac{B}{l}\.\]  
Here, \(B=\frac{1}{n}\sum_{i=1}^{n}b_{i}\) and \(l\) is the cycle length, which depends on the frequency of fuzzy inferencing operations for the selection of intermediate verification nodes. Implementation of a one-way hash chain provides backward secrecy. That is, even if a \(key_{j}^{n_{i}}\) is shared by a node \(n_{i}\) with one of the intermediate verification nodes during session/cycle \(j\), and is revealed to an adversary, it does not compromise future secret authentication keys. As \(key_{m-1}^{n_{i}}=\ f(key_{m}^{n_{i}})\), it is computationally impossible for the adversary to calculate the previous forward key. The period of key dissemination is determined when the e-CH performs the verification node selection. Every verification node \(CH_{i}\) shares their separate symmetric key, \(k_{CH_{i}-BS}\), with the BS station to produce their verification signatures.