## 7 Weak Authentication
Furthermore, since we do not have the energy required by SHA-1 with block lengths other than 160-bit, the results provided in Section 8.3.2 are used in our experiment. The TinyECC library is considered to provide ECDH key exchange functionality in Seltge++. Experimental evaluations published for TinyECC shows that the ECDH key established operation needs 50.82 mJ for the MicaZ platform [29]. Since MicaZ is the closest platform to Mica2, therefore 50.82 mJ is used for the energy evaluations of ECDH in this paper. The energy cost of transmitting one byte (\(E(Tx)\)) is also considered to be 59.2 \(\mu\)J [21]. Figure 11 shows that with an 88-bit block length of the hash function, the initialization phase of Seltge++ has less energy consumption than Seltge, while the data transmission phase of Seltge++ has more energy cost. Seltge's advantage in data the transmission phase is typically because of the energy consumed for the encryption employed in Seltge++. Figure 12 illustrates the overall advantage of Seltge's energy consumption over Seltge++'s energy cost when two protocols are run in the same conditions. However, considering the improved security provided by Seltge++, we believe that this extra cost is acceptable. Figure 12 also shows that the energy consumption growth of Seltge is exponential, and with hash block lengths equal and larger than 11 bytes, Seltge++ has the advantage over original Seltge in terms of energy cost. Consequently, it is suggested to use Seltge++ in situations where security must be very restricted, and therefore, hash functions with block lengths larger than 11 bytes are used. On the other hand, Seltge is better for regular situations where smaller block lengths are acceptable. As described in Section 8.4, Seltge does not support hash block sizes larger than 11 bytes, but Seltge++ does. Moreover, Seltge++'s overhead is higher than Seltge only when using hash block sizes smaller than 11 bytes (Figure 12c). In this range, none of these two schemes can provide a reasonable security level for mission-critical situations. When 11 bytes is selected for the hash block size used in both \begin{table}
\begin{tabular}{c c} \hline
**Protocol-Phase** & **Formula** \\ \hline Seltge-init & \(((2^{K}-1+2^{K})\times E(SHA1))+((O_{1}+NP0)\times B\times E(Tx))\) \\ Seltge-data & \((E(SHA1)\times\left\lceil\frac{ImageSize}{B-|SHA1|}\right\rceil)+(E(Tx)\times B \times\left\lceil\frac{ImageSize}{B-|SHA1|}\right\rceil)\) \\ Seltge++-init & \((I\times E(HMAC))+(I\times E(Tx)\times B)+E(ECDH)\) \\ Seltge++-data & Seltge-data \(+(\frac{ImageSize}{8}\times E(SkipJack))\) \\ \hline \end{tabular}
\end{table} 
Table 11: The formulas used for the energy cost calculation of Seltge and Seltge++. In other word, Seluge++ has an improved overhead rate compared to what Seluge provides with its less secure scheme. This improvement is effective on hash block sizes equal and larger than 11 bytes (Shown in Figure 12c). However, we believe that since Seluge++ is proposed for hostile environments, it is better to use it with block sizes equal to and larger than 11 bytes, because below this range, it has a higher overhead compared to Seluge. Seluge still remains the best scheme to be used in standard environments in which security need not to be very strict only, and only in terms of overhead. However, when it comes to security, Seluge++ still is better than Seluge, even while using hash block sizes smaller than 11 bytes. Albeit that Seluge++ will have more overhead when being used in this range of hash block sizes, it provides a more secure scheme; therefore, if this overhead is tolerable in-field, then it is suggested to use Seluge++ even in non-hostile environments. ## 9 Conclusion

Existing security models used in over-the-air dissemination of code updates in WSNs perform well in applications where the security requirement needs to be at its standard level, but suffers in applications where it needs to be at its maximum level.