## 6 Design of Seltape++
### Transmission Process  
After a code update is available, the base station (server) will start to send advertisement packets until a node requests the update code. Since the session key is needed prior to the propagation phase in order to encrypt data before the hash calculation of packets in the Data Verification Method, the ECDH key agreement process will be the next step that the node and BS will take. The node, after receiving an advertisement packet, will choose its sender and ask for a signature packet. Then, the BS will load \(T\) (elliptic curve domain parameters) and will select a random number \(1<d_{S}<n-1\) and a random 160-bit number (\(N_{0}\)); then, the BS will calculate \(Q_{S}=d_{S}G\). The server will sign a packet containing \(V_{n}\) (to keep freshness), \(I,N_{0}\) and \(Q_{S}\) with his \(GK_{Pri}\) and will send this to the node. \[Sign_{GK_{Pri}}(\{V_{n},I,N_{0},Q_{S}\})\]  
The node will receive that packet and will decrypt its content using \(GK_{pub}\), which is configured in nodes _a priori_. The value of \(I,N_{0}\) and \(Q_{S}\) will temporarily be kept in the RAM storage of node. Before the node takes any other action, it will compare the value of \(V_{n}\) with the value in the earlier disseminated code; if the new value is less or equal to the old value, this means that a reply attack is ongoing. The node will stop the current process and will notify the BS about this attack and will also halt the Seluge++ mechanism for a pre-configured amount of time to prevent resource exhaustion. Otherwise, if the new value of \(V_{n}\) is greater than the old value, the node will continue. In this phase, the node needs to do the rest of the ECDH key agreement procedure by selecting a random number of \(1<d_{N}<n-1\), calculate \(Q_{N}=d_{N}G,SK=H^{80}(d_{N}Q_{S})\) and a random 160-bit number (\(N_{1}\)), where \(SK\) will behave as the session key mentioned in Section 5. In this stage, the node can free the memory used for storing large numbers, like \(G\) and \(P\). Then, the node will create packet data in the following format and will send it to the BS:  
\[\{Q_{N},\ Enc^{80}_{SK}(N_{1}),\ MAC^{160}_{SK}(Q_{N}\oplus N_{0})\}\]  
Upon receiving the previous packet, the BS will first calculate \(SK=H^{80}(d_{S}Q_{N})\) and then checks if the generated session key (\(SK\)) is authentic or not using Equation (3). If it is a valid session key, then it will run a calculation (Equation (4)) to extract \(N_{1}\). If the generated session key is found to be bogus, then it means an attacker is trying to send forged packets to the BS; since the BS is assumed to be powerful, it is very unlikely for an attacker to perform a DoS attack by sending many reply packets from a malicious node. \[\{\underbrace{Q_{N}},\ Enc^{80}_{SK}(N_{1}),\underbrace{MAC^{160}_{SK}(Q_{N} \oplus N_{0})}_{\oplus N_{0}\Rightarrow MAC^{160}_{SK}(Q_{N}\oplus N_{0})} \xrightarrow[\overline{\gamma}]{} \tag{3}\]  
\[Dec^{80}_{SK}(Enc^{80}_{SK}(N_{1}))=N_{1} \tag{4}\]  
Now, the BS has the session key; therefore, it can start the preparation of the code update packets. As specified in the design of Seluge++, the BS will fragment code updates in compliance with Figure 6, and then, the default behavior of the original Seluge will be applied on the generation of hash packets. The key difference is that in the design of Seluge++, to preserve confidentiality, we have proposed touse a temporary session key to encrypt data packets to prevent malicious nodes from understating the behavior of the network by disassembling the code update. In most of the proposed secure dissemination protocols, data encryption has been omitted, because the authors have mostly assumed that in a network, the code update does not need to be protected against a sniffer's willingness to disassemble data.