Making the system impeccable: A brief discussion on the importance of adding encryption components to the secure boot process of IoT devices

Secure boot is a critical component of any embedded system. This process ensures that the system firmware, the brain of any embedded system, is consistent with the system manufacturer's design intent. Secure boot ensures that the operation of an embedded system is safe and predictable. Its value is obvious in systems where failure could have catastrophic consequences. Examples of such critical systems include thermal controllers for home stoves and integrated ovens, engine control modules in cars, traffic light controllers, therapy delivery systems in implanted medical devices, and controllers for driverless trains. These systems may fail or operate unpredictably due to faults in the firmware that runs them. Such failures can occur for a variety of reasons, from environmental factors such as memory failures caused by power surges to the execution of malicious code injected by hackers. In all cases, the integrity of the firmware can be tested through the secure boot process before attempting to run the system.

Secure boot has always been performed only when it is needed. Although secure boot as a topic may not be mentioned often, there have always been corresponding regulations and standards to enforce secure boot in many critical systems to ensure the safe operation of these systems. Therefore, most systems that are considered less important, such as computer mice or handheld calculators, skip the rigorous secure boot process directly because the consequences of their failure are generally minor; however, what constitutes a critical embedded system? This definition is quietly changing due to the emergence and popularity of the Internet of Things (IoT).

The difference between critical and non-critical systems is shrinking. With the advent of IoT, it can be said that every embedded system is now a critical system. Embedded systems are no longer isolated islands where all performance and failures are confined. While IoT provides great benefits by connecting embedded systems together, a direct consequence of this networking is the elimination of containment boundaries. Now, any embedded system connected to the network can be a potential risk, and anyone in the world can be a potential victim.

The potential for damage caused by injecting faults into the firmware of embedded systems has never been greater. Natural system failures, such as power surges and communication errors, are still largely the same as they were before, so traditional secure boot processes are still effective. However, the occurrence of artificially injected faults, especially malicious ones, is rapidly increasing in both variety and sophistication. In the past, an attacker would need to gain physical access to each individual system to insert a malicious fault. Now, because systems are networked, an attacker can easily gain access to many other remote systems by compromising just one system. This can lead to malicious control of a large number of devices, malicious access to critical systems and data stored in the cloud, or infamous data breaches caused by hackers showing off their skills. This is why it is necessary to ensure that secure boot solutions must be able to resist attacks and fault injection.

Secure boot consists of two basic elements: the ability to detect the integrity of the firmware and the assurance of the integrity of the detection process. These long-standing elements are well understood and use cryptographic techniques to achieve their respective goals, evolving only in the sophistication of the cryptographic algorithms and the secure hardware methods used to ensure the integrity of the detection process.

Testing the integrity of firmware involves using cryptography to create a fingerprint, a small, compressed digital code that represents the firmware and allows changes to be easily detected. This cryptography belongs to a class of cryptographic algorithms that produce a digest of the fingerprint, called a hash function. The commonly used 256-bit Secure Hash Algorithm, or SHA256 for short, produces a digest that is 256 bits long. SHA256 is the latest hash algorithm, and while it is neither the most compact nor the most sophisticated, it strikes a good balance between security and efficient use of embedded system resources , such as power, code space, and computing resources .

To set up and implement secure boot, embedded system manufacturers hash the final operating firmware during the factory manufacturing process and install both the firmware and the digest in the embedded system. During actual operation, a piece of detection code in the embedded system hashes the operating firmware and compares the resulting digest with the digest installed at the factory. If the digests match exactly, the integrity of the operating code has not been compromised.

To ensure the integrity of the detection process, it is ideal to place the detection code in a non-volatile memory type such as ROM (read-only memory) to make it less susceptible to environmental failure vectors such as power surges and other storage corruption conditions such as inadvertent memory modifications. In response to rapidly changing market requirements, we often use locked versions of non-volatile memory technologies such as Flash and EEPROM, or dedicated execution environments such as TrustZone® technology that replaces ROM.

The secure boot process described above is sufficient in the absence of malicious fault injection, however, this is not typical in the real world we live in. An attacker can defeat the secure boot process by simply creating their own firmware and the corresponding hash digest and installing both into the system. This undermines the integrity of the detection, so we need to have a verification detection process.

This verification detection process requires the use of secret information such as a key and generates an authenticated digest of the firmware or simply a certificate (Figure 1). This is designed so that an adversary who wants to thwart the detection system needs to know the same secret information to generate a consistent firmware-signature pair. Considering that the verification process of the operational code also requires access to the same secret information, embedded systems are likely to be disassembled by attackers in an attempt to find the secret information. The substantial increase in the complexity of the analysis tools and techniques required to build advanced embedded systems has also provided attackers with unexpected assistance, allowing them to access these tools directly or through related services to achieve their goals of exploiting the system.

Figure 1: Best-practice generic boot process, including factory preparation and field verification of signed operational firmware

It’s easy to imagine how this cat-and-mouse game between embedded system developers and attackers would play out, except for the emergence of a special type of integrated circuit called a cryptographic element (CE).

A cryptographic element (CE) is an integrated circuit designed to resist attacks such as attempts to retrieve confidential content or tampering. Performing a secure boot operation with a CE provides the integrity required to verify the firmware detection and authentication process. The CE can be integrated into the controller or a standalone component, providing system architects with the flexibility they need to meet their deployment needs.

While the fundamental elements of secure boot—detection and process—remain unchanged, we can choose to implement these two elements using either symmetric or asymmetric key cryptography to control the entire boot verification process.

Symmetric key cryptography uses the same key or a derivative of the same key in both the factory setup and field verification phases of the secure boot process. As shown in Figures 2 and 3, the verified boot process based on the SHA256 algorithm is an example of a symmetric key boot process. Symmetric key-based boot processes have the advantage of speed, but may encounter difficulties in ensuring the confidentiality of the boot key in the supply chain. Therefore, closed ecosystems are the most popular because only one entity holds the key.

Figure 2: Factory settings with symmetric key security for secure boot

Figure 3: Symmetric key stream verification process

Asymmetric key cryptography (Figure 4) uses separate keys during the factory setup and field verification phases of the secure boot process. The relationship between the two keys is controlled by cryptographic algorithms such as elliptic curve cryptography (ECC). ECC is used in a special protocol called the Elliptic Curve Digital Signature Algorithm (ECDSA), which is often used for firmware signing and verification.

Figure 4: Secure boot setup in an open partner ecosystem. Typically, original equipment manufacturers (OEMs) have multiple partners who supply subsystems that make up an embedded system or alternative resources for a system.

Using an asymmetric key process such as ECDSA, which also works with the secure hash algorithm SHA. In practice, SHA256 is used to detect the operating firmware to create a digest, which is then signed using the ECDSA protocol to complete the entire verification firmware process. The resulting signature is a certificate that is attached to the operating firmware and can be installed into the embedded system (Figure 5).

Figure 5: Field verification process of asymmetric key stream

The asymmetric key structure requires a private key and a public key. The former must be kept secret and is only used for factory settings, while the mathematical counterpart of the latter is only used during the field verification phase. The public key can be viewed by anyone without affecting the security of the boot process. Therefore, the secure boot process based on asymmetric keys is more suitable for an open ecosystem composed of multiple entities.

If a secure boot process requires high production logistics costs, it will quickly be abandoned by the market. Therefore, an effective secure boot process should be able to determine the integrity of the operating code and detection process without significantly increasing the time or cost of the production process.

While the best choices for open and closed ecosystems are asymmetric and symmetric key boot processes, respectively, the use of cryptographic elements can break this limitation, allowing either boot process to be used in either ecosystem while maintaining the confidentiality of the keys. However, the asymmetric key approach provides more freedom, allowing designers to easily create a mathematically rigorous process for maintaining a chain of trust in an open partner ecosystem.

The secure boot process for embedded systems has always been driven by regulations and standards governing product security. This model worked well when embedded systems were physically isolated, isolated islands. However, with the advent of IoT, where systems are connected to the Internet of Things, the elimination of fault containment boundaries has greatly encouraged attackers and increased the focus on secure boot. The remote accessibility of things means that embedded systems are more easily accessible, making anyone, anywhere in the world a potential victim of system attacks. Although post-mortem analysis may reveal which device is the culprit and which manufacturer should be held accountable, the damage has already been done. To limit liability, product manufacturers are taking proactive steps to integrate tamper-resistant secure boot processes into their products and add cryptographic elements to successfully ensure secure boot.