## 7 Weak Authentication
The key difference is that, for the offline chain that is used as weak authentication only for authentication packets, as far as we are preserving confidentiality and unauthorized entities are unable to understand the content of the transmitted bytes, we suggest updating the hash chain values each time a new update code is disseminated. Therefore, there will be a periodic change, and this will make it difficult for attackers to perform sequential collision attacks against this weak authentication during the lifetime of the network. As seen in Algorithm 2, the node will generate \(N_{1}\) and will send it to the server in a secure manner. Therefore, this value is only shared between BS and the node. Using this number as a commitment, a temporary hash chain with I values will be created using Algorithm 3. Algorithm 2 (lines 22 and 33) are places that Algorithm 3 can effectively generate a hash chain. This dynamically generated chain will be used in the weak authentication of packets in the HV and DV Methods. ```
1:Get \(N_{1}\) from input
2:\(X_{1}\Leftarrow H^{160}(N_{1})\)
3:Store \(X\) in RAM or EEPROM. 4:for\(i=2\) to \(I\)do
5:\(X_{i}\Leftarrow H^{160}(X)\)
6:Store \(X_{i}\) in RAM or EEPROM. 7:endfor
```
**Algorithm 3** Temporary hash chain generation of a message-specific puzzle. \begin{table}
\begin{tabular}{c c c c c c c c c c} \hline
**Name** & **Privacy/** & **Authentication** & **Integrity** & **DS** & **Wormhole** & **Replay attack** & **Battery-Drain** & **Overhead** & **Maximum hash** & **Comments** \\  & **Confidentiality** & & **Resilience** & **Attack Resilience** & **Resilience** & **Attack Resilience** & **Attack Resilience** & **Block Size** & \\ \hline \hline \multirow{2}{*}{
\begin{tabular}{c} Sclueg \\ Schuge++ \\ \end{tabular} } & \(\times\) & ✓ & ✓ & A & ✓ & ✓ & ✗ & VH & 11 & Limited Support for Hash Algorithms \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Sclueg and Seltge++ comparison in terms of security support. DoS, denial of service. ## 8 Analysis

In summary, in terms of security, Seluge++ has made a significant improvement compared to the original Seluge. The general advantages of Seluge++ over the original Seluge in terms of security support are shown in Table 5. As shown in Table 5, confidentiality in Seluge++ is preserved using symmetric encryption, while Seluge does not preserve privacy at all. The method that Seluge is using to prevent DoS attacks is not sufficient for mission-critical situations; therefore, Seluge++ improvements using immediate verification at the packet level makes it robust against DoS attacks. battery-drain attacks are now impossible in Seluge++ by the benefiting of the message-specific puzzle. This is while Seluge is vulnerable to battery-drain attacks. Another improvement in Seluge++ is that it supports any block size for the underlying hash function, which results in having a more secure scheme. Seluge could only have a hash function with a maximum of 11 bytes for the block size, which results in Seluge being vulnerable to collision attacks against its underlying hash function. To show that Seluge++ is maintaining a reasonable balance between the provided security level and energy consumption and performance, five different analyses have been done on Seluge++. These include _security analysis_, _compatibility with SMR_, _performance evaluation_, _energy cost evaluation_ and a measurement to show _overhead improvement_ and the provided security strengthening of _supported hash block length_. In the following, we present these analyses. ### Security Analysis

#### 8.1.1 Casper/FDR2 Approach

To prove the authentication claims of Seluge++, a security model checker is employed that is similar to [32]. FDR (Failures-Divergence Refinement) is a model checker for state automata based on concurrency theory and on CSP (Communicating Sequential Processes) [32,33], and it is mainly used to check the security properties of systems.