# Tradeoffs in Key Rotation Strategies for Industrial Internet of Things Devices and Firmware
## 2 Representative Architectures for Secure Boot
### Immutable Bootloader with Preslotted Multiple Public Keys (C)  
Some chip vendors provide a fixed number (slots) of public keys that are configured within the immutable bootloader [21]. These preslotted keys are injected at the time of manufacturing of the device into the immutable storage (or at least the hashes of the public keys are immutable) and are unchanged throughout the life of the hardware product. Also, when hardware constraints prevent storage of public keys (e.g., ECC or RSA keys which \begin{table}
\begin{tabular}{c c} \hline
**Pros** & **Cons** \\ \hline Quick development time to market. & No key rotation. \\ Optimized boot for the architecture. & \\ \hline \end{tabular}
\end{table} 
Table 2: Major tradeoffs of minimal immutable bootloader as a baseline. \begin{table}
\begin{tabular}{c c} \hline
**Pros** & **Cons** \\ \hline \hline \multicolumn{2}{c}{Cannot rotate firmware signing key.} \\ Still has rapid boot sequence. & \multicolumn{1}{c}{Cannot rotate bootloader signing key.} \\ Can customize the bootloader. & \\ \hline \end{tabular}
\end{table} 
Table 3: Major tradeoffs of immutable bootloader with secondary bootloader. are relatively longer), the hash values of the public keys are configured. Every such public key, when generated, will have a corresponding private key. These are potential signing keys that will be used to sign the firmware components. These private keys are maintained by the device maker. In most cases, a secondary bootloader exists on the device, and a separate set of signing keys set is maintained by the device maker. Figure 2 depicts this configuration arrangement. As there are a fixed number of key pairs created, generally for an entire product line, it becomes critically important to protect these private keys throughout the life of the product. The approach, although significantly better than (A) or (B), is still limited to the preslotted number of keys. Any eventual compromise of the key management system significantly weakens the firmware's authenticity and integrity. When a firmware package update is invoked, the public key slot must be identified for use for the firmware update operation (e.g., \(P_{1}\) to \(P_{n}\)). One of the strategies to achieve this is an incrementing counter maintained in a secured storage or execution area accessible to the bootloader. An incoming firmware package can have a reference to the sequence number of the public key corresponding to the private key that was used to sign the firmware or bootloader. Alternatively, such a public key itself can be incorporated along with the firmware. Such a key can be compared against the set of keys that are already present on the hardware. If none match, it will be treated as an integrity violation, and the process aborts. For space-constrained devices where hash values of the public keys are stored, firmware delivery must provide the public key associated and the bootloader can then derive a hash of the public key to match against the present hash values in the immutable storage. If none match, that is an integrity violation. At the time of the power cycle, the secure immutable bootloader verifies that it has a valid public key to use. Any mismatch there should fail the firmware upgrade process to prevent any further damage. Subsequently, it also verifies the secondary bootloader (if applicable), and that the firmware package is valid. This is performed by way of typical hash-matching based on the chosen public key. Upon successful loading of a bootloader or firmware, if a newer public key (never used before) has been used, the device must be able to determine invalid keys and have a process of revocation of keys. As most of the devices will be space-constrained, it is not possible to maintain a certificate revocation list; therefore, the revocation must be performed in a logical way. One of the ways manufacturers have achieved this is by treating on-device public keys as a sequential array.