# Tradeoffs in Key Rotation Strategies for Industrial Internet of Things Devices and Firmware
## 2 Representative Architectures for Secure Boot
### Signed Certificate in the Immutable Bootloader (E)  
This approach is an extension to these prior approaches intended to improve ability to rotate keys. It still works with asymmetric key pairs with the private (signing) key in possession of the device maker. Instead of preconfiguring a fixed number of keys at manufacturing, it treats the public key as a dynamic artifact of the bootloader system. To enable verification of authenticity of the public key, it utilizes X.509 in having a Certificate Authority (Issuing CA and typically a third party) sign the public key. It requires the Issuing CA certificate and the Root CA certificate to be loaded into the primary bootloader at the time of manufacturing as immutable. The Issuing CA adds an additional root of trust. It essentially federates the trust so that secure boot is no longer solely dependent on the predetermined keys because a new key can now be validated based on a secondary, external root of trust--the Issuing CA. A firmware update package over the air (typically) contains the following elements: binary, firmware signature, firmware public certificate, secondary bootloader signature (when applicable), secondary bootloader public certificate (when applicable)  
At the time of the power cycle, the secure immutable bootloader verifies that the secondary bootloader (if applicable) and the firmware package are present. Upon success, crypto functions verify the authenticity of the bootloader public certificate using the immutable Issuing CA certificate. If the operation is successful, the secondary bootloader takes control, as outlined previously. The secondary bootloader continues in the same manner to verify the authenticity of the firmware public certificate and firmware package. Figure 3: UPTANE design. \begin{table}
\begin{tabular}{c c} \hline \hline
**Pros** & **Cons** \\ \hline Relatively fast boot time. & Requires trustworthy communication to \\ Allows key rotation. & separated repositories. \\ Addresses revocation via separate metadata & Currently tailored for automotive devices only. \\ and firmware measurement. & Supply chain weakness. \\  & Can be complex to set up. \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Major tradeoffs of UPTANE. If the verification is successful, the firmware update process commences. At any point in time, if any of these checks fail, it is treated as an integrity violation and process aborts. Figure 4 below illustrates how X.509 system is utilized, and the relationship between various elements of the system in a broader context. In cases where the firmware provider deems it necessary to rotate the bootloader or firmware signing keys, it can be achieved at the provider's key management system by rotating the private-public key pair (e.g., generating \(P_{2}\) and \(K_{2}\) in this context) and signing it using the Issuing CA to generate a new public certificate (\(C_{2}\) in this context). Separate key pairs can be generated to sign the secondary bootloader and firmware packages depending on the security. Further bootloader or firmware signing operations immediately utilize the new key \(K_{2}\). For the subsequent firmware update operation, the firmware package will contain a new version of the firmware binary, signature signed by \(K_{2}\), the \(P_{2}\), and optionally a new version of the secondary bootloader binary (optional), signature signed by \(K_{2}\), and \(P_{2}\). The firmware maker may choose to sign the firmware and bootloader with separate keys as well. As an extension and improvement to the prior approach, signing key rotation is physically independent of the device and can happen without having the limitation to stay within the preslotted number of keys at the time of manufacturing. This is possible because the secondary root of trust is the CA certificate which acts as an anchor to verify any public certificate that is signed by the certificate authority the CA certificate represents.