# Tradeoffs in Key Rotation Strategies for Industrial Internet of Things Devices and Firmware
## 1 Introduction
### Definition and Theory of Key Rotation  
The key words used in this paper (e.g., key rotation, private key, public key, public key certificate, asymmetric-key cryptography) are consistent with definitions in the NIST Glossary. Key rotation is the process of regularly and systematically replacing new keys for the existing cryptographic keys used for various purposes such as signing and secure boot, authentication, or encryption. The purpose of the key rotation is to enhance security by minimizing the impact of compromised keys and reducing the window of opportunity for attackers. As such, it makes key compromise more difficult and reduces the impact of a potential/successful compromise. This paper focuses on the rotation of keys used for signing firmware and for secure boot in devices that are resource constrained on memory and processor. Throughout this paper, we will refer to the private key as the asymmetric key used to sign the firmware segment (which might be the bootloader, the entire firmware image, or a specific set of functionality that constitutes a piece of firmware function); this private key is intended to be kept secret by the firmware maker, and its compromise results in the potential ability to sign the firmware (as long as the forger knows the algorithm, method of appending the signature, encoding, etc.). Each private key has a paired public key that can go onto the device in two forms: as a raw public key or as a certificate. We will use the term raw public key when the key itself is stored in device memory and is used to validate the firmware segment. We will use the term certificate when the public key is stored as part of a package (i.e., certificate) that contains the public key, some metadata about the key, and a signature from a key-issuing authority.  
Figure 1 shows a generic concept of how code signing works for secure boot. A private-public key pair is generated in a key vault. The public key is exported and loaded into the bootloader. The firmware is hashed, and the generated hash is signed by the private key. The signed hash is appended to the firmware as the firmware signature. These artifacts are loaded onto the IIOT device. The bootloader is then able to use the public key to validate the authenticity and integrity of the firmware.  
For key rotation to work in this context, one must generate a new private-public key pair, export the new public key, and obtain the new firmware signed by the new private key (for the new secure boot process) and signed by the old private key (to be recognized by the chain of trust by the device in operations). For key rotation to be successful, it must replace both the public key on the device and the firmware signature without violating security principles. One example of such a violation is allowing full simultaneous replacement of both public key and firmware signature without any linked chain of trust, i.e., old private key, which would allow arbitrary replacement of the firmware. Another example of such a violation is allowing the use of past keys, which would allow the reuse of compromised keys.  
We make a clear distinction between key rotation and certificate rotation. Key rotation discussed in this document replaces key materials with newly generated ones as a preventive measure against cryptoanalysis of keys. Certificate rotation (not addressed in this paper) creates a new certificate for the existing key material and is used in conjunction with short-living certificates to ensure fine temporal granularity of the permitted use of keys. Certificate rotation is out of the scope of this paper. Key management, which is an organization function of how crypto keys are generated and governed according to NIST SP 800-57, is out of the scope of this paper.