# Energy-Aware Security Adaptation for Low-Power IoT Applications
## 4 Dynamic Security and Energy Adaptation
### Controller Logic  
The verification of the preference threshold defined at the application level is the first step considered by the controller logic algorithm. Depending on this value, an appropriate calculation flow is taken using the impact percentage. Next, the energy remaining in the device's battery is verified, and an attenuation is applied to the previous calculation.  
The battery percentage is divided into three intervals in the controller's logic: [100%, 75%], [75%, 25%] and [25%, 0%]. These intervals are chosen to reflect three representative phases in the typical discharge curve of an alkaline battery, as discussed in [17]. Since one of the goals of our proposal is to extend the lifetime of sensing devices by promoting energy savings, the three considered intervals allow the algorithm to react differently in such situations, with respect to the security profile chosen. In particular, this means that the algorithm, depending on the battery level at each moment, can reduce the security scheme to be suggested in three attenuation levels: least attenuation, medium attenuation and heavy attenuation, respectively.  
In our implementation and evaluation, we considered two versions of the algorithm. The first version, identified subsequently as _Logic_, is illustrated by Algorithm 1. In the other version, identified subsequently as _Delta Logic_, we modify the algorithm by adding, between lines 10 and 11, an instruction to store a given number of previously transmitted security assessments (detection of an attack by an IDS module in the network) in a buffer. In this version, when a new security assessment is received from the IDS, it is stored in a buffer, and the algorithm considers instead the highest recorded assessment present in that buffer to perform the necessary calculations. This version of the algorithm arises from the need to absorb temporary anomalies that may exist in the security assessment performed by the IDS, thus allowing to filter false positives and smooth the behavior of the controller when appropriate. We proceed to discuss our initial approach to evaluate the behavior of the described algorithm.  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Level**} & \multicolumn{3}{c}{**Security Scheme**} & \multirow{2}{*}{**Energy Saving**} & \multirow{2}{*}{**Security Level**} \\ \cline{2-2} \cline{4-5}  & **Confidentiality** & & & \\ \hline
1 & - & - & Very Strong & Weak \\ \hline
2 & - & SHA256 & Strong & Moderate \\ \hline
3 & AES128 & - & Strong & Moderate \\ \hline
4 & AES128 & SHA256 & Moderate & Strong \\ \hline
5 & AES256 & SHA512 & Weak & Very Strong \\ \hline \hline \end{tabular}
\end{table}
Table 1: Security profiles considered for the proposed architecture.  
Again, we note that this is configurable for the application at hand, given that, in practice, different attacks may represent different risks and have different impacts to different applications.  
In fact, a particular type of external attack can have a different impact depending on the purpose of each LoRaWAN application, and one motivation of our strategy is to ensure that the proposed architecture is as inclusive as possible of LoRaWAN applications with different requirements and goals.