# Secure LoRa Firmware Update with Adaptive Data Rate Techniques +
## 4 Discussion  
### Security Assessment  
A malicious actor could try to steal the embedded firmware to access data or the proprietary embedded algorithms stored on the device, or they might attempt to load malicious firmware. The firmware, encrypted with AES by a herd specific key \(K_{h}\), is exposed when it is broadcast over the air using LoRa by the base station, and when it resides on the device. Therefore, the attacker would only be able to collect the encrypted firmware image if they are able to track the ADR process to determine the base-station-to-device communication settings. An alternative attack is to spoof the base station by impersonating a device in need of a firmware update, and then collecting the encrypted firmware image. However, the protocol requires the initial exchange of messages to be signed with a device-specific key \(K_{c}\); therefore, this attack would fail without the key because the base station would refuse to send the firmware update.  
When the device receives the firmware image, it stores it in external memory. Storing an encrypted image consumes additional power since it must be decrypted to verify the message integrity. Moreover, the stored image is decrypted again before committing it to flash. An alternative is to decrypt the image during reception, and then store it unencrypted. The drawback here is that this enables a malicious actor to access the unencrypted image if they obtain access to the device. Note that the dual decryption operations are not required if the firmware update is stored in internal flash, but this is only possible if the firmware image meets the criteria from Equation (4). In the event that a device from the herd is stolen, it would be prudent to update \(K_{h}\) for the entire herd in case the device is compromised using invasive techniques.  
The second major security concern is loading malicious firmware onto the device. The malicious firmware could be as simple as code that disables the device causing a permanent DoS attack, or the malicious code could broadcast the wrong location so the system is unaware that cattle are being stolen. As a countermeasure, a MAC is appended to messages from the base station during the initial exchange which prevents unauthorized  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Setting** & **Start OCV** & **Stop OCV** & \
\begin{tabular}{c} **Measured** \\ **Energy** \\ \end{tabular} &
\begin{tabular}{c} **Expected** \\ **Energy** \\ \end{tabular} \\ \hline
7 & 4.19 V & 4.09 V & 266.63 J & 200.2 J \\ \hline
8 & 4.09 V & 92.3 V & 430.7 J & 389 J \\ \hline
9 & 4.18 V & 3.96 V & 709.06 J & 684.5 J \\ \hline
10 & 4.18 V & 3.82 V & 1166.14 J & 1350 J \\ \hline
11 & 4.17 V & 3.29 V & 2669.2 J & 2664 J \\ \hline \hline \end{tabular}
\end{table}
Table 4: The energy consumed doing a firmware update at each Long Range (LoRa) setting.  
Figure 12: This shows the packet structures for exchanging the firmware image.  
attempts to upload firmware to the device, unless \(K_{c}\) becomes compromised. In the event that a malicious actor waits until after the initialization occurs to begin attempting to transfer a malicious image, the transfer would be unsuccessful because it would also need to be signed using \(K_{c}\). Note that using \(K_{c}\) to sign the update prevents multiple devices from being updated at the same time since \(K_{c}\) is unique to each cattle. The code transfer cannot be signed with \(K_{h}\) because this leaves the system open to replay attacks where the adversary could load old firmware versions onto the device without knowing \(K_{h}\). A summary of this analysis is provided in Table 5.