# Tradeoffs in Key Rotation Strategies for Industrial Internet of Things Devices and Firmware
## 3 Discussion and Analysis of Tradeoffs  
In this section, we compare the various representative architectures across the criteria listed in Table 1. In the water sector and other sectors, the low cost of IIOT devices is critical. This frequently means constraints on power, memory, and resources. While boot time is important, it is often not as critical. Establishing strong key management can be very difficult for new developers and large organizations alike. There is a tradeoff between the ability to perform quick boot and the ability to rotate signing keys throughout the long lifetimes of IIOT products. Chip vendors are frequently settling on architecture (C) and, as such, are not providing supporting utilities that enable rapid development of a certificate-based secure boot that would enable regular key rotations in a secure way. Figure 5 provides a high-level summary of the tradeoffs among the various architectures. These architectures are labeled by the letters in parentheses of each subsection in Section 1. The scale for each feature in Table 1 is a subjective scale from 1 to 5 to provide a visual of the tradeoffs, where 5 is the best possible outcome that we have seen as practitioners in the field. Note that there is a major tradeoff that must be made between boot time, development time, and device resilience that favors the simple architectures like those described in (A), (B), and (C), and the chip-vendor-independent, and that allows for multiple simultaneous versions, and frequency of rotation associated with the more complex architectures of (D) and (E). It is worth noting that architectures (A) and (B) are quite common now in the firmware development utilities that come from chip vendors and system-on-chip (SOC) utilities. An increasing number of vendors are providing architecture (C), which is decreasing development time. Architecture (C) hits a sweet spot in that with little additional development effort, one can significantly improve the ability to rotate keys at all levels while still maximizing device resilience, boot time, memory use, etc. The implementation of architectures (D) and (E) still require the IIOT device developer to place significant time, innovation, and effort into building out the infrastructure, including crypto function utilities. However, as more chip and SOC vendors provide these capabilities in their default bootloaders and utilities, it could decrease the development time, further shifting the trade space and making key rotation on resource-constrained IIOT devices more feasible. \begin{table}
\begin{tabular}{c c} \hline \hline
**Pros** & **Cons** \\ \hline Unlimited key rotations. & Relatively slower boot times. \\ Relatively more secure. & Requires extra effort to address certificate revocation. \\ Relative longer development times. \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Major tradeoffs of signed certificate in immutable bootloader. The cons listed for architecture (E) could be overcome through a community effort to develop the basic concepts and reusable utilities for developing bootloaders, firmware, and builds. Moreover, a simple solution to certificate revocation could be a single-byte increment that disables the use of past keys (which will need to be the topic of a future whitepaper). We recommend that the community migrate to the more prevalent use of certificate-based secure boot for even low-energy, low-resource, and inexpensive devices for IIOT. With this general model, it is worth exploring some concepts, for example, crypto agility. [PERSON] [22] says that post-quantum risks are already here for long-lifetime equipment like IIOT because nation-states are implementing \"harvest now, decrypt later\" strategies by gathering products and keys that can be exploited after the computational capabilities are available. NIST [24] discussed this in depth with various approved post-quantum algorithms, but those are not yet available from chip vendors as a part of their utilities.