## 7 Weak Authentication
consumption throughout the complete dissemination of the code update using the following calculation (core voltage = 3.0 V, time = 3.6 \(\mu\)S, current = 8 mA (extracted from Table 8)):

\[J=V\times C(Coulomb)=V\times(I\times t)=\] \[3.0(V)\times(8\times 10^{-3})\times(3.6\times 10^{-6})=86.4(\mu J)\]

#### 8.3.2 SHA-1

The results of the simulation of 160-bit SHA-1 algorithm implementation in the assembly language and tested in ATMEL Studio are shown in Table 10. Therefore, the energy consumption of this algorithm can be calculated as below:

\[t=\frac{29,193}{16,000,000}=1.82(ms)\] \[J=3.0(V)\times(8\times 10^{-3})\times(1.82\times 10^{-3})=43.68( \mu J)\]

### Overhead Improvement and Stronger Security

We use the term stronger security, because hash algorithms with any block length can be used in Seluge++, and the security of Seluge++ will highly depend on the used hash algorithm. Seluge++ has replaced the Merkle hash tree with a new mechanism described in Section 6.4. The following analysis is done to show that the replaced mechanism is better, both in the initial overhead and the maximum provided block length support for the hash algorithm. The usage of a Merkle hash tree incurs some overhead on the number of packets to be disseminated over the network. Because of the reminding behavior of the Merkle hash tree and its relative Equation (1) in Section 2 and also because the maximum authentication path (AP) length in a Merkle Tree is equal to \(l\) in \(2^{l}\)[51], it can be identified that each hash packet needs to be sent with \(K\) more hash values located in its AP. Therefore, to send all the hash packets in page 0, which are identified using \(M\), it is necessary to send a number of \(H\) hash values equal to the result of Equation (5) below:

\[H=K\times M \tag{5}\]

To find out how many overhead packets (\(O_{1}\)) are implied in their mechanism, it is required to multiply the value of H by the number of bytes used by the hash algorithm (\(|H(. )|\)) and divide the results by the payload size of each packet (\(B\)). Therefore, the total implied overhead packets will be calculated using Equation (6):

\[O_{1}=\frac{K\times M\times|H(.)|}{B} \tag{6}\]

Since (\(M=2^{K}\)), Equation (6) can be rewritten as below:

\[O_{1}=\frac{K\times 2^{K}\times|H(.)|}{B} \tag{7}\] \begin{table}
\begin{tabular}{c c c} \hline \hline
**Platform** & **CPU Clocks** & **Read-Only Memory (ROM) Size (Bytes)** \\ \hline Assembly in ATMEL Studio & 29,193 & 4,286 bytes \\ \hline \hline \end{tabular}
\end{table} 
Table 10: Performance analysis of SHA-1. On the other hand, the mechanism employed by Seltge++ first merges all the hash values of page 1 to create the packets of page 0. The number of packets in page 0 (\(NP0\)) in absence of the required bytes for MAC can be calculated using Equation (8):

\[NP0=\left\lceil\frac{NPPP\times|H(.)|}{B}\right\rceil \tag{8}\]

Each packet in page 0 needs to be merged with a number of MAC bytes for authentication and integrity check purposes. The number of packets in page 0 in the presence of the required bytes for MAC (denoted as \(I\)) can be calculated using Equation (2) in Section 6.3. This will create the initial overhead of Seltge++ and can be calculated using Equation (9):

\[O_{2}=I-NP0=\left\lceil\frac{NPPP\times|H(.)|}{B-|MAC_{SK}(.)|}\right\rceil-NP0 \tag{9}\]

Having Equations (7) and (9), it can be easily identified that Equation (9) has a great advantage over Equation (5), because it is a linear equation, while in the other side Equation (5), it has an exponential increase with am increment value of \(K\). Considering the above facts, two major differences will be identified between Seltge and Seltge++. In the case of Seltge, the increase in the hash strengthening will have an exponential increase in the number of overhead packets (\(O_{1}\)), while in Seltge++, it will be a linear increment (Figure 9). Furthermore, as discussed in Section 3, an analysis on the original Seltge shows that it does not support hash values having more than 11 bytes in their output.