# Tradeoffs in Key Rotation Strategies for Industrial Internet of Things Devices and Firmware
## 1 Introduction  
IIOT is becoming increasingly valuable to operations because they cost less and can be updated with features tailored to precise user needs. Risks from IIOT connections are generally known [1]; however, much of the discussion is focused on secure communication and cloud configurations [2]. As practitioners, we have experienced difficulties in finding specific guidance on device security topics, such as secure boot, provisioning sequences, key rotation, and others, even though the device is a highly exposed component of the IIOT system. This is an extension to a practitioner's paper presented at IEEE Sec Dev Conference [3]. While the original paper [3] was limited to two pages and provided only a very brief overview of several secure boot architectures and their impact on key rotation, this paper provides detailed descriptions of the architectures, criteria for architecture evaluation, and an analysis of the architectural alternatives. It also provides a more detailed discussion of theoretical foundations and recommendations for the community.  
It is important to note the key differences of Industrial Internet of Things (IIOT) from Internet of Things (IOT). IIOT application and requirements [4, 5] are more frequently directly associated with the control of physical entities, such as pumps, motors, drives, etc. IIOT are more likely to involve real-time data processing [6], stringent security requirements due to potential safety outcomes [6], and operations in dynamic environments [7]. In addition to these, the heterogeneity of devices in IIOT systems further complicates the implementation of uniform security measures such as key rotation [8].  
There are several decision points in the design of IIOT that impact the security of the system [9]. One is determining how to establish root of trust and chain of trust for securing device firmware [10]. These concepts span hardware and firmware and constitute \"secureboot\" [11; 12]. Consider the following procedures associated with secure boot. When the system resets, the root of trust, which may reside in a hardware-based secure enclave or may be based on the immutable structure of the reset function, initiates the boot process, and verifies the integrity of the first bootloader. If the bootloader's digital signature matches the expected signature, it is considered authentic and trusted. The bootloader then proceeds to authenticate and to execute the next component in the chain, repeating the process until the system is fully booted. This chain of trust is typically enabled using cryptographic algorithms (e.g., ECDSA or RSA). For example, a private key is used by the firmware developer to sign the firmware. The chain of trust in the secure boot process then uses a raw public key, a preshared key, or a certificate that is embedded with the bootloader to verify that the firmware is authentic and untampered. Many IIOT devices are cheap, low-energy, low-resource, and, as such, rely on inventive techniques to perform secure boot with minimal memory and processing requirements (this paper is mainly referring to OS-less devices, or those running RTOS for resource-constrained systems, such as Zephyr, BreezeOS, or FreeRTOS).