Military Embedded Systems

Designing and implementing secure boot for military-grade systems

Story

August 07, 2023

Military-grade systems require a high level of security to protect sensitive information and operations from unauthorized access, modification, or disruption. One of the critical components for securing such systems is secure boot, which ensures that only trusted firmware and software can be loaded during system startup and accepted when receiving new updates.

Secure boot is a security feature that verifies the authenticity and integrity of firmware and software before loading them into the system memory during the boot process. The mechanism ensures that only trusted firmware and software are executed and mitigates attacks that aim to modify or replace firmware or software with malicious code. Secure boot uses digital signatures and cryptographic hashes to verify the authenticity and integrity of firmware and software.

The primary purpose of a secure boot mechanism is to guard against several types of attacks, including rootkits, bootkits, and other malware that target firmware and software. These attacks can compromise the system’s security, potentially causing data breaches, denial of service, and other damaging consequences. Secure boot ensures that the system starts in a secure state, making it difficult for attackers to compromise the system’s integrity or confidentiality.

Standard recommendations for secure boot

The IETF SUIT [Internet Engineering Task Force Software Updates for Internet of Things] specification for secure boot has been standardized in RFC9019, and it provides a comprehensive approach to designing secure bootloaders and firmware updates. The specification defines a format for firmware images that includes metadata, digital signatures, and cryptographic hashes; this metadata includes information about the firmware, device, and manufacturer, as well as the hash (verification) and the cryptographic signature of the software, enabling the system to verify the authenticity and integrity of the firmware.

One of the key recommendations from RFC9019 is the use of a secure bootloader that verifies the authenticity and integrity of the firmware image before loading it into memory. The secure bootloader checks the digital signature and cryptographic hash of the firmware image, ensuring that it has not been tampered with or modified.

RFC9019 also recommends the use of a trust anchor or a root of trust (RoT) to store the cryptographic material used for secure boot. A trust anchor may consist of any software or hardware-based mechanism that ensures that the public key used for the verification of the firmware authenticity cannot be modified by an attacker.

Selecting a root of trust

A RoT is a specific type of trust anchor that provides a secure environment for generating, storing, and managing cryptographic keys. The RoT ensures that these keys are not compromised or tampered with, and it is typically implemented in hardware to provide a high level of security. The RoT is the foundation of the system’s security, and it is used to establish trust in the system’s firmware, software, and other components.

In the context of secure boot, a RoT can be implemented using several different technologies, such as hardware security modules (HSM) or trusted platform modules (TPM). Executing the cryptographic operations with the assistance of a dedicated hardware component is the most secure option, because it guarantees that the keys are never exposed to the software components, thereby reducing the attack surface for the secure boot module.

Compatibility with the embedded system is an important consideration when selecting a trust anchor or RoT. The RoT must be compatible with the hardware and firmware of the system, ensuring that it can be integrated seamlessly into the boot process. The RoT should also support the required cryptographic algorithms and protocols, ensuring that it can provide a high level of security for the system. Hardware-based solutions can be more expensive than the software-based counterparts. While for less critical systems a software-­based solution may be sufficient and more cost-effective, the cost of implementing a hardware-based solution is justified for military-grade systems that require a higher level of security.

Retrofitting older systems

Retrofitting older systems with secure boot can be difficult and expensive, as it may require both hardware and software upgrades. The cost and feasibility depend on several factors.

One of the main challenges of retrofitting older systems with secure boot is that many legacy systems were not designed with security in mind. This means that the system architecture may not support the necessary security features required for secure boot, such as a FIPS-compliant (a longstanding data-security standard) cryptographic module, or hardware-based RoT or HSM. In some cases it may be necessary to redesign the system boot process to include secure boot stages, which can be a time-consuming and expensive process.

Another obstacle found in retrofitting older systems with secure boot is the availability of existing bootloaders. Many legacy systems use custom bootloaders that do not support secure boot; in these cases, it may be necessary to modify the bootloader(s) to support secure boot. The bootloader must be able to communicate with the trust anchor or RoT and perform the necessary integrity and authenticity verifications during the boot process.

Integrating cryptographic modules to provide the required integrity and authen­ticity verifications at startup is also an option to consider when retrofitting older systems. The system must be able to store and manage cryptographic keys securely, ensuring that they are not compromised or tampered with. In addition, the cryptographic modules must be able to perform the necessary cryptographic operations efficiently to minimize the impact on system performance, which – in the case of secure boot – is likely to affect startup times.

Despite these challenges, retrofitting older systems with secure boot is often necessary to ensure the security of critical systems. In many cases, the cost and feasibility of retrofitting a system with secure boot can be reduced by using existing software-based solutions, such as secure boot software that can be installed on existing hardware or integrated in existing legacy bootloaders. However, for military-grade systems or systems that require a higher level of security, a hardware-based solution is often necessary, which can increase the cost and complexity of the retrofitting process. (Figure 1.)

[Figure 1 ǀ A data wall provides real-time worldwide information for the 175th Cyberspace Operations Group of the Maryland Air National Guard. U.S. Air Force photo by J.M. Eddins Jr.]

FIPS cryptography as a necessity for military-grade systems

Among its recommendations, RFC9019 stresses the use of FIPS-compliant cryptography for the algorithm used by secure boot. This is particularly important for military-grade systems. FIPS – the acronym used for Federal Information Processing Standard – is a set of standards developed by the National Institute of Standards and Technology (NIST) ex­press­ly to ensure the security of sensitive government information. FIPS-compliant cryptography is designed to be strong and secure, and it has been rigorously tested and validated to ensure that it meets the highest security standards.

While FIPS 140-2 is currently the most widely recognized standard for cryptography, NIST has recently developed a new standard, FIPS 140-3, which updates and will eventually replace FIPS 140-2, introducing new requirements for the validation of cryptographic algorithms and modules. FIPS 140-2 and FIPS 140-3 provide frameworks for the validation of cryptographic modules, which are sets of hardware, software, and/or firmware that implements cryptographic functions, such as encryption and decryption.

The widely adopted FIPS 140-2 standard defines the requirements for the design and testing of cryptographic modules, specifying four levels of security based on the level of protection required for the information being secured. It’s a rigorous process that involves extensive testing of the cryptographic module to ensure that it meets the security requirements specified in the standard. The process includes testing of the cryptographic algorithms used by the module, as well as testing of the physical and logical security mechanisms used to protect the module from tampering or attack.

For military-grade systems, the use of FIPS-compliant cryptography is essential to ensure the security of sensitive information and critical software components. Military systems are typically targeted by sophisticated attackers, and the use of strong cryptography is necessary to protect against attacks that could compromise the integrity, confidentiality, or availability of the system.

In a broader scope, the use of FIPS-grade cryptography can also help to ensure interoperability and compatibility with other systems and components that use standard algorithms to ensure the security of sensitive information and critical systems. The importance of FIPS-certified implementations extends as well in the secure boot domain, due to its critical role in the general security of the entire system that can be mitigated by the adoption of the best-in-class cryptographic countermeasures, recommended by the standards.

Daniele Lacamera is a free and open source software technologist, currently based in Italy. His main areas of expertise are embedded systems and TCP/IP communication. He has 20-plus academic publications in the field of transport-layer optimization and is the author of the book “Embedded Systems Architecture.” Daniele joined wolfSSL as embedded software engineer in 2018, contributing to the development and the integration of wolfSSL on embedded operating systems and custom transport mechanisms. He is the main contributor to wolfBoot, the universal secure bootloader for embedded systems.

WolfSSL      https://www.wolfssl.com/

Featured Companies

wolfSSL

10016 Edmonds Way Suite C-300
Edmonds, WA 98020