# Tradeoffs in Key Rotation Strategies for Industrial Internet of Things Devices and Firmware
## 1 Introduction
### Desired Attributes of Key Rotation  
Different architectures for secure boot in embedded systems that support key rotation vary in their tradeoffs concerning device resilience, memory use, security of key rotation, and boot time. The most effective architecture for enabling key rotation in secure boot for embedded systems is contingent on specific application requirements and constraints.  
Figure 1: Generic concept of public key on device to validate firmware signature.  
[PERSON] et al. [6] described hardware roots of trust like hardware security modules (HSMs) and trusted platform modules (TPMs) to provide robust security features including encryption and key management, but they also increase memory use, development time, and device cost. They also described homomorphic and searchable encryption mechanisms for secure data handling in embedded systems, though they described that additional research is necessary to improve scalability and performance [6]. [PERSON] [18] described redesign of microcontrollers to enhance boot time, reduce power consumption, and enhance device resilience. Table 1 summarizes the desired attributes of a key rotation system (labeled for ease of reference in final analysis).  
This paper describes various experiences focused on the implementation of key rotation for IIOT devices. The objective is to both educate on some lessons learned and also to initiate a discussion across the community on the use of certificates for key rotation on low-energy and low-resource IIOT devices. The ability to rotate keys provides a level of adaptability for IIOT devices that will enable the preservation of customer trust and the continued and expanded use of IIOT.  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Attribute** & **Explanation** & **Impacts** \\ \hline \multirow{3}{*}{Product development time} & Implementing key rotation should not make & \\  & the creation and production of IIOT & Dev Time \\  & more complex. & \\  & While adding layers for key rotation we should & \\  & not make the product unusable by increasing & \\  & boot time by an order of magnitude. & \\  & Ideally, we want to be able to rotate any key & \\ Ability to rotate all keys & materials that are susceptible to & \\  & potential compromise. & \\  & More frequent key rotation means a smaller & \\  & window for compromise, but more complexity, & \\  & bandwidth, and operational resources. Some of & \\  & the resource-constrained devices considered in & \\  & this document are battery-powered and & \\  & increased utilization decreases lifetime. & \\  & The mechanism for key generation and & \\  & distribution also matters, but this paper is & \\  & primarily focused on the device architecture & \\  & for rotation & \\  & Protected limited-access storage of private key & \\  & by the developer, immutable or verifiable & \\  & storage of public key on device. & \\  & We need key rotation architectural principles & \\  & that can apply across a large variety of chips & \\  & microprocessor platform & \\  & The method must ensure that previous valid & \\  & keys are revoked and unusable in the device & \\  & revoked keys & but do not have memory or processor & \\  & capability for revocation lists. & \\  & IIOT devices are not continuously connected & \\  & and frequently have different wake-up and & \\  & bandwidth usage schemes. As such, the & \\  & methods must ensure that device operations & \\  & are resilient to expired keys and that the & \\  & system enables multiple versions during & \\  & rotation timeframes. & \\  & Like above, we must ensure that the device & \\  & works under a variety of scenarios that might & \\  & degrade, but not eliminate security. & \\ \hline \hline \end{tabular}
\end{table}
Table 1: Attributes and impacts of compare key rotation capabilities of boot architectures.