# Tradeoffs in Key Rotation Strategies for Industrial Internet of Things Devices and Firmware
## 2 Representative Architectures for Secure Boot
### UPTANE Platform for Firmware Updates and Key Rotation (D)  
UPTANE (Update Protocol for Transportation Network and Electronics) is a framework designed for securing over-the-air updates in automotive vehicles but is general enough to be applied to IIOT examples that use inexpensive chips and limited bandwidth [16]. UPTANE combines several security philosophies to provide this security while still enabling the system to be agile. The major examples include the following [23]:  
Multiple keys/signatures--multiple independent entities sign the firmware increments.  
Metadata system--a cloud system that tracks the state of firmware, keys, signatures, etc., across repositories and devices.  
Separation of trust--the requirement for multiple keys, firmware increments, different signing of metadata, and firmware increments enables distributing trust as an inexpensive way to protect complex and scaled systems.  
Figure 3 shows an illustration of this process in which different images on different boards are signed with different keys, images of firmware increments are provided by both the image repo, and metadata are provided by the director repo. Rotation and revocation of keys are managed through this same process. In this case, the Director repo can act as a certificate authority of sorts by lending authority to image increments, even though in this case it does not control images or the individual keys for signing images.  
UPTANE works across a variety of platforms. One must have access to a secure time source. The IIOT device must have some form of secure boot implemented with access to the keys or certificates for exchange. The devices will need to be provisioned with the current set of metadata with appropriate timestamps. There will need to be signing keys unique to individual devices, and the Director repository inventory database will need public keys in addition to the provisioned devices. Finally, it will need some sort of repository mapping file to know what aspects of infrastructure will provide which information.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Pros** & **Cons** \\ \hline Relatively fast boot time. & \\ Allows key rotation. & May require manual intervention. \\ Can customize the bootloader. & Predefined keys to maintain \\ \hline \hline \end{tabular}
\end{table}
Table 4: Major tradeoffs of immutable bootloader with multiple presolotted keys.  
Considering the attributes in Table 1, this method benefits from an overall infrastructure that supports secure updates. The greatest benefit is that there is separation of trust, which means that we do not rely on a single root of trust--the IIOT services now monitor firmware measurements, which provide the ability to have remote devices with a weaker root of trust. It allows key rotation at every level--no longer limited to preslotted keys. It promotes the concept of firmware segmentation to more easily sign and update chunks of functionality without having to update the entire package. Memory protections, key access restrictions, revocation processes, etc., are built into the overall architecture through layers of controls that are not only on the device. The downside comes from the added development time required to not just develop, test, and release a device, but also connections to IIOT services and the development of the services. Table 5 gives a summary of pros and cons of this architecture.