This file type includes high-resolution graphics and schematics when applicable.
Secure boot is a critical component of any embedded system. It assures that firmware, the brains of all embedded systems, is as intended by the maker of the system. Moreover, secure boot assures the safe and predictable operation of embedded systems. Its value is easily seen in systems whose failure can lead to potentially catastrophic consequences. Examples of such vital systems include heat controllers of home furnaces and range ovens, engine-control modules in vehicles, traffic-light controllers, therapy delivery systems in implanted medical devices, and controllers of unmanned trains.
These systems can fail or operate unpredictably because of faults in the firmware running them. Such faults can emanate from various sources, ranging from environmental factors (like power surges leading to memory faults) to malicious code execution injected by a hacker. In all cases, secure boot provides a means to measure the integrity of the firmware before attempting to operate the system.
The need for secure boot has always been imposed where required. While secure boot as a subject might traditionally lurk in the background, its use has been enforced by regulations and standards governing the safe operation of critical systems. As such, systems deemed less critical, like a computer mouse or a handheld calculator, might have largely escaped the rigors of secure boot because their failure bore little consequence. However, the Internet of Things (IoT) is changing the definition of what constitutes a critical embedded system.
IoT Brings Secure Boot to the Forefront
The dichotomy between critical and non-critical systems is evolving. With the emergence of the IoT, all embedded systems are now critical systems—they no longer exist as islands with all features and faults contained within. While, the IoT provides great benefits in connecting embedded systems together, a direct consequence of this networking is the erasure of containment boundaries. Any connected embedded system is now a potential risk, and anyone in the world is a potential victim.
The possibility of damage incurred from injecting faults into the firmware of embedded systems has never been higher. The occurrence of natural system faults, like power surges and communications errors, has largely remained the same, so traditional secure boot methods continue to be effective in that regard. However, the occurrence of human-injected faults, especially of the malicious type, is growing rapidly in breadth and sophistication.
In the past, attackers needed to gain physical access to each individual system to insert malicious faults. Now, with the networking of systems, attackers can leverage an attack on one system to gain access to many other remote systems. This could lead to the malicious control of a large number of devices, access to critical systems, access to data stored in the cloud, or just notoriety through publicity stunts in data breaches. It underscores why secure-boot solutions must be resistant to attacks and fault injections.
Securing the Boot Process
Secure boot has two fundamental ingredients: the ability to measure the integrity of the firmware, and assurance of the integrity of the measurement process. These long-standing ingredients use cryptography to accomplish respective goals, evolving only in terms of the sophistication of the cryptographic algorithms and the secure hardware methods used to protect the measurement process integrity.
Measuring the firmware’s integrity involves use of cryptography to create fingerprints—a small piece of digital encoding that’s condensed and representative of the firmware, and thatcan be easily checked for changes. This cryptography is in a class of cryptographic algorithms called hash functions, which generate digests for the fingerprints. The commonly used 256-bit Secure Hash Algorithm, or SHA256, generates 256 digital bits for a digest. SHA256 is the latest in hash algorithms, and while neither the most compact nor elaborate, it strikes a good balance between security and efficient use of embedded-system resources like power, code space, and computing resources.
To set up and achieve secure boot, the embedded-system maker hashes the final operational firmware at the factory and installs both the firmware and digest in the embedded system. During operation in the field, a measuring piece of code in the embedded system hashes the operational firmware and compares the resulting digest to the factory-installed digest. A matching digest indicates that the integrity of the operational code is intact.
To assure the integrity of the process, it’s ideal to have the measuring piece of code in a non-mutable memory, such as read-only memory (ROM). Therefore, it won’t be susceptible to environmental fault vectors like power surges and other memory corruptors like inadvertent memory modifications. To respond to rapidly changing market needs, it’s common to use locked versions of non-volatile memory technologies like flash and EEPROM or dedicated execution environments (e.g., TrustZone technology) in lieu of ROM.
Protecting the Boot Process Against Attackers
The just-described secure-boot process would be sufficient in the absence of malicious fault injections, but alas, that’s not representative of the world we live in. To overcome this process, an attacker simply needs to create his or her own firmware with the corresponding hash digest and install both into the system. This undermines the integrity of the measuring; hence, the need arises for an authenticated measurement process.
Such a process entails the use of secret information, like a key, in conjunction with the generation of the firmware’s certification digest or simply a certificate (Fig. 1). The idea is that the adversary would require knowledge of the same secret information in order to generate a consistent firmware-signature pair to thwart the measuring system.
Given that the validation process of the operational code also needs access to the same secret information, the embedded system may fall victim to physical exploitation by the attacker to discover the secret information. Tremendous growth in sophistication of analysis tools and techniques for building advanced embedded systems also works in favor of the attacker, who can gain access to these tools directly, or else through services, to exploit the system.
Without loss of generality, it’s easy to envision the progression of this cat-and-mouse game between the embedded-system developer and the attacker. This game would continue if it weren’t for special types of integrated circuits called crypto elements (CEs).
CEs are specifically designed to resist attacks such as attempts to retrieve confidential content or tampering. Enforcing secure boot with CEs delivers the integrity needed in the authenticated firmware measurement and validation processes. They can be integrated into the controller or stand alone, providing system architects with flexibility to fit their implementation needs.
Symmetric- vs. Asymmetric-Key Cryptography
While the fundamental ingredients of secure boot, namely measurement and process, remain constant, their realization offers a choice of symmetric- or asymmetric-key cryptographic techniques to govern the overall boot validation process.
Symmetric-key cryptographic techniques use the same or derivatives of the same key in both the factory setup and field-validation stages of the secure-boot process. The SHA256-based authenticated boot process shown in Figs. 2 and 3 is an example of a symmetric-key boot process. This type of boot process has the advantage of speed, but can potentially suffer from difficulties in managing the secrecy of the boot key in a supply chain. As such, it’s most popular with closed ecosystems, where knowledge of keys must reside with a single entity.
Asymmetric-key cryptographic techniques (Fig. 4) use separate keys in the factory-setup and field-verification stages of the secure-boot process. The two keys have a relationship governed by a cryptographic algorithm approach such as elliptic curve cryptography (ECC). A special protocol for firmware signing and verification, known as the Elliptic Curve Digital Signature Algorithm (ECDSA), uses ECC.
An asymmetric-key process like ECDSA also works with SHA. In practice, SHA256 measures the operational firmware to create a digest that’s subsequently signed using the ECDSA protocol to complete the authenticated firmware process. The resulting signature is a certificate that’s attached with the operational firmware for installation into the embedded system (Fig. 5).
The asymmetry in the key structure allows for a private key, which must remain secret, to be used at the factory for setup; it also allows its mathematically correlated counterpart, called the public key, to be used in the field for the field-validation stage. The public key can be viewed by anyone without impact to the security of the boot process. For this reason, the asymmetric-key-based secure-boot process lends itself better to open ecosystems of several entities.
Secure Boot Made for Manufacturing
A secure-boot process that requires heavy costs in manufacturing logistics quickly leads to abandonment. An effective secure-boot process is therefore one that determines the integrity of the operational code and measurement process without adding significant time or cost to the manufacturing process.
While asymmetric- and symmetric-key boot processes are optimal in open and closed ecosystems, respectively, employing CEs makes it possible to use any process with either ecosystem while maintaining the confidentiality of the keys. However, the asymmetric-key method offers additional latitude to easily build in a mathematically rigorous process of upholding chain of trust in an open ecosystem of partners.
Secure Boot Enforces Security through Accountability
The secure-boot process for embedded systems has traditionally been driven through regulations and standards governing product safety. This model was very effective when embedded systems existed as islands of physically contained systems. But networking of systems through the emergence of the IoT eliminates fault containment, thereby creating motivation for attackers and greatly increasing the attention paid to secure boot. Remote accessibility of things means easier access to embedded systems—making anyone, anywhere in the world, a potential victim of system attacks.
While post-mortem analysis may reveal a culprit device that would hold the manufacturer accountable, the damage will have already been done. Motivated to limit their liabilities, product manufacturers are taking proactive measures to incorporate tamper-resistant secure-boot processes into their products, with crypto elements their ticket to security success.
