Building Secure Firmware
Armoring the Foundation of the Platform
1st ed.
To my lovely wife, Wenjun Zeng. Thank you for your constant encouragement and unconditional support!
—Jiewen Yao
To my parents; to my wife, Jan; and to my daughters, Ally and Zoe. Your support and love are rays of sunshine that warm my days.
—Vincent Zimmer
When Saudi Aramco was attacked in August 2012 by the Shamoon computer virus, it was a wake-up call to the entire industry. Saudi Aramco is one of the largest companies in the world and holds the second largest amount of crude oil reserves. A shutdown of Saudi Aramco for a prolonged amount of time would have had a devastating impact on the oil economy, and this could have plunged the world into an economic recession.
The Shamoon virus was by today’s standards a relatively simple virus. It overwrote the master boot record on the hard disk with garbage, rendering the system unbootable. While the infestation was effective – reportedly more than 30,000 systems got impacted – the much-feared secondary effect of the global oil supply chain hiccup didn’t materialize. That was in part because the hard disk is an “easy” to service component and Aramco was able to replace the hard disks in time to avoid any serious impact.
However, this attack made folks in the industry and intelligence communities around the world wonder: What would have happened if Shamoon went after a non-serviceable component, like the flash chips where the system firmware is stored? This is much harder to repair on-site, and it would have required the systems to be shipped back to the manufacturer. This would have taken a lot more time, and in that case a global oil supply shortage could not have been avoided, potentially even triggering a global recession.
BIOS update authentication: The firmware needs to be signed by the proper authority.
Integrity protection: The firmware cannot be modified, either unintended or maliciously.
Non-bypassibility: There is no way to bypass the authenticated firmware update mechanism.
This specification was followed up in 2018 by another NIST publication, Platform Firmware Resiliency Guidelines (NIST SP800-193). This specification extended the previous one by focusing on recovery. Its central tenet was simple: providing protection against unauthorized firmware updates is not enough. The firmware is a complex piece of software, and it will, probabilistically, contain bugs that can be exploited by an attacker. How do you quickly and seamlessly recover if this happens?
Before you consider this problem to be a PC-only threat, think again. With the proliferation of IoT devices in homes and factories, and SCADA devices to control the national grid, firmware security has become a key part of the world’s critical infrastructure protection. Just imagine the harm a malicious attacker could do by taking over the firmware of pipeline controllers in a gas line in Siberia, Russia, during the winter. You’ll be hard-pressed to send someone out there to fix the problem.
The Saudi Aramco attack and its resulting NIST secure firmware recommendations solidified the importance of firmware security in the industry. Those recommendations built on years of academic and industrial research in this area. I was personally involved in some of these efforts, ranging from IBM’s physical secure coprocessor (IBM 47xx) projects and TCPA/TCG frameworks to secure hypervisor research and working with other industry partners on the foundations of NIST SP800-147.
The authors Jiewen Yao and Vincent Zimmer have bundled together into this book their combined years of experience in developing secure firmware and building resilient systems. Every computer, big or small, starts with firmware, and if that’s compromised, all is lost, so following the authors’ guidance is as relevant today as it was in 2012.
—Leendert van Doorn
Redmond, WA, USA
Currently, we already have books to separately introduce the topics of firmware and security. The purpose of this book is to link these areas together and provide the best practices in the security development of firmware.
The whole book consists of four parts:
Part I: Overview
Chapter 1 includes a brief overview of the firmware in a system.
Chapter 2 describes a proactive development lifecycle for the firmware. We will introduce a general threat model for the firmware and use a real example to demonstrate how to do threat model analysis.
Part II: Security Architecture
Chapter 3 describes the first aspect of the firmware resiliency – protection.
Chapter 4 describes the second aspect of the firmware resiliency – detection.
Chapter 5 describes the third aspect of the firmware resiliency – recovery.
Chapter 6 extends the resiliency concept from the firmware to the operating system (OS).
Chapter 7 introduces the trusted boot concept, besides the firmware resiliency in Chapters 3, 4, and 5.
Chapter 8 focuses on the security aspects of the device firmware, including secure device communication and device attack prevention.
Chapter 9 discusses S3 resume – a special boot path in the system firmware.
Chapter 10 presents the access control technology in the firmware, including boot access control, device access control, feature configuration control, and so on.
Chapter 11 examines the confidentiality, integrity, and availability of the firmware configuration data.
Chapter 12 provides a brief introduction for the security model and maps the Clark-Wilson model to existing firmware features.
Chapter 13 explains the virtual firmware, which may include a new threat model.
Part III: Security Development
Chapter 14 introduces the general secure coding practices for firmware.
Chapter 15 discusses the compiler defensive technologies which may be used in the firmware.
Chapter 16 describes the possible firmware kernel hardening technologies.
Chapter 17 compares different trusted execution environments (TEEs), including system management mode (SMM) and ARM TrustZone.
Chapter 18 shows the silicon secure configuration, such as flash lock and system configuration lock.
Chapter 19 explains the cryptography usage in the firmware space, including an introduction for post-quantum cryptography.
Chapter 20 introduces the Rust language – a type-safe language choice for firmware development.
Part IV: Security Test
Chapter 21 discusses the security unit test, including fuzzing and symbolic execution.
Chapter 22 describes the security validation and penetration test plan.
Chapter 23 recaps the mitigation strategies – eliminate the vulnerability, break the exploitation, contain the damage, and reduce the attack window – and focuses on how to maintain the firmware in the lifecycle.
Whom Is This Book For?
- 1)
Computer system architecture, such as X86, ARM, PCI bus, and so on
- 2)
Operating systems or embedded systems
- 3)
Programming language – C language
- 4)
Firmware design and development experience, such as EDK II, coreboot, ARM Trusted Firmware, and so on
In 1988, the Morris worm was released from the lab onto the Internet. It was the first time that a computer virus had gained significant mainstream media attention. People started to realize that a software flaw was vital, which changed the perception of security on the Internet. Ten years later, in 1999, the Chen Ing-hau (CIH) virus brought another big impact because the Basic Input/Output System (BIOS) flash chip was attacked and the impacted system could not boot at all. A technician was required to reprogram the BIOS. This was probably the first wave of firmware security. The firmware developers started to invent the idea of locking the flash region in response to CIH.
The second big wave was around 2009. Invisible Things Lab released a series of BIOS attacks and presented in the Black Hat conference. These attacks included the REMAP base address register (BAR) attack , Bitmap (BMP) file attack , system management mode (SMM) callout, SMM cache poisoning, and Authenticated Code Module (ACM) hijack. The firmware developers realized that locking the flash and system management RAM (SMRAM) was far from enough. Similar to the software development process, the firmware development domain also needs to apply the security development lifecycle (SDL) .
The third wave of firmware security commenced in 2014, where more and more firmware attacks appeared in different hacking conferences. This next wave of attacks included exploits against the capsule image, setup variable, SMM communication, memory mapped input/output (MMIO) BAR in SMM, Speed Racer, Direct Memory Access (DMA) , S3 boot script, and Unified Extensible Firmware Interface (UEFI) secure boot policy – lots of firmware features became the attack point. It is just like the old saying, “If there is a will, there is a way.” The firmware engineers started to invent new technologies and processes to harden the firmware design and development.
The war of defense and attack never ends. Today, firmware security has become more and more important. The National Institute of Standards and Technology (NIST) published the documents SP800-193 – Platform Firmware Resiliency Guidelines and SP800-155 – BIOS Integrity Measurement Guidelines. The Trusted Computing Group (TCG) created the Cyber Resilient (CyRes) workgroup to focus on three principles of resilience (protecting, detecting, and recovering), the Device Identifier Composition Engine (DICE) workgroup to explore the security principles for the Internet of Things (IoT) ecosystem, and the Attestation workgroup to provide a framework for attestation. The Distributed Management Task Force (DMTF) created the Secure Protocol and Data Model (SPDM) for device firmware authentication and measurement, as well as key exchange. The Internet Engineering Task Force (IETF) created the Software Updates for Internet of Things (suit) working group to define a firmware update solution for small IoT devices and Remote Attestation Procedures (rats) working group to standardize the formats and procedures for the assertions about the system components. The cloud companies invented different platform Root-of-Trust (RoT) techniques , such as Microsoft Cerberus, Google Titan, and Amazon Nitro. The device vendor started building the device root-of-trust to report the device certificate. In this fourth wave, every firmware engineer needs to understand the aspects of firmware security – from industry standards, architecture, design, and implementation up to the final stages of test and validation.
We would like to acknowledge our technical reviewer and Apress editors. We would also like to acknowledge the many engineers and collaborators with whom we have worked in the industry, standards groups, and open source communities.
is a principal engineer in the Intel Architecture, Graphics, and Software Group. He has been engaged as a firmware developer for over 15 years. He is a member of the UEFI Security Sub-Team (USST) and the Trusted Computing Group (TCG) PC Client sub-working group. He has presented at industry events such as the Intel Developer Forum, UEFI Plugfest, and RSA Conference. He worked with coauthor Vincent Zimmer to publish 30 “A Tour Beyond BIOS” technical papers for tianocore.org and firmware.intel.com. He holds 40 US patents.
is a senior principal engineer in the Intel Architecture, Graphics, and Software Group. He has been engaged as a firmware developer for over 25 years and leads the UEFI Security Sub-Team. He has presented at industry events such as the Open Source Firmware Conference, LinuxFest Northwest, Intel Developer Forum, UEFI Plugfest, Open Compute Project Summit, Black Hat Las Vegas, BSides Seattle, ToorCon, and CanSecWest. In addition to collaborating with Jiewen Yao on many whitepapers, he has coauthored several books on firmware, papers, and over 400 issued US patents.
is the CTO and head of the Office of Security and Trust for Insyde Software. With over 30 years of BIOS experience, he has served on the UEFI board of directors and chaired the UEFI Security Sub-Team (USST). He is an active member of his local CS2AI chapter near his home in Folsom, California.