By Joe Byrne, Senior Strategic Marketing Manager, NXP
& Ravi Malhotra, Senior Software Product Marketing Manager, NXP
Most of us implicitly assume firmware—the software preloaded on a system—is secure. After all, it came from the manufacturer, ready to run before we even turn the system on for the first time. We worry instead mostly about operating-system and application-software security. However, firmware—and not just the firmware implementing complete stacks but also platform firmware providing boot services and system management—is vulnerable to exploitation. As Wired wrote, “…subverting the firmware gives the attackers God-like control of the system in a way that is stealthy and persistent even through software updates.”
Wired was referring to news that spies at the NSA had hacked hard-drive firmware, succinctly summarizing firmware’s vulnerability: “The attack works because firmware was never designed with security in mind. Hard disk makers don’t cryptographically sign the firmware they install on drives the way software vendors do. Nor do hard-drive disk designs have authentication built in to check for signed firmware. This makes it possible for someone to change the firmware.” Once the NSA had control of the firmware, it could execute other code.
The press reported another example in early 2017: A company downloaded a compromised firmware update from a supplier of servers to its data centers. The exploited firmware conceivably could have exfiltrated proprietary technology from the company’s design lab. In response to this risk, the company returned some servers to its supplier and sent over lawyers and engineers to review its security practices.
But it doesn’t need to be this way.
Firmware for NXP processors can be secured, protecting it at three opportunities:
- System boot
- Firmware update
System Boot. A central principle of NXP’s approach to security is that the root of trust resides in hardware. A secure boot process requires a tiny boot loader residing securely in silicon to validate the first level of code that resides outside the silicon, which is the firmware. While this may seem straightforward, the keys used to authenticate the firmware must be securely stored. There’s no point to installing the world’s best safe if you scrawl the combination on the door. The keys must not be readable by any external firmware and must be revocable in case any vulnerability is found in an earlier version of the firmware to prevent a roll-back attack. In addition, entry points to the system are closed during the secure boot process. Entry points include PCIe, network, and JTAG (debug) ports. Yet another form of attack is an attempt to clone the firmware from a compromised system and make it boot on another system. Ensuring that all devices have unique identifiers and locking firmware to each specific device can help thwart such cloning. Internal boot loaders, secure and revocable keys, disabled I/O and unique identifiers are all elements of the secure-boot implementation in NXP’s QorIQ Trust Architecture.
Update. In the above server case, the hacked firmware may have been loaded during an update. We’re told time and again to keep software, including firmware, up to date to remediate security vulnerabilities, but both the update process and the new firmware must be secured. The firmware updater mechanism must run in a secure environment—either on a separate on-board board-management controller (BMC) in the case of servers or within the Trusted Execution Environment in the case of embedded systems. This provisioning software must cryptographically authenticate the source of the update and securely download it using the Transport-Layer Security (TLS) standard. This software must then validate the firmware using the keys stored securely in the system alongside those used for secure boot. NXP provides a secure provisioning tool that helps with this process. The tool also helps ensure that the right firmware was programmed when the system was manufactured.
Runtime. The simplest way for an attacker to modify firmware is to replace it with a hacked image where it is stored, such as in flash memory or on a disk drive. Fortunately, this tampering can be easily detected by storing the firmware in an encrypted format and decrypting it prior to booting or loading it. Knowing this, clever hackers modify the firmware during run time when it is stored unencrypted in main memory. Thwarting runtime tampering requires more sophisticated defenses. One such defense is a runtime integrity checker (RTIC). The RTIC in NXP’s QorIQ® processors can run code in the background that cryptographically validates the firmware in memory, further exemplifying the principle that the root of trust resides in hardware. Battery-based backup and antitamper pins provide an additional layer of security against attackers who can gain physical access to the embedded system and try to open the lid. If they succeed, they will find the secrets stored inside the silicon zeroed out and the silicon itself left in an unusable state to prevent any further tampering.
The compromised hard-drive and server firmware could have been better secured. NXP provides multiple mechanisms for securing firmware, keeping hacked code off the system from the day it’s manufactured to the day it is retired. Moreover, the same security mechanisms can also help protect system and application software. The risk to system suppliers and their customers is too great for these mechanisms to go unused.
We know security technology can be frustrating. Before you pick up the hammer, talk to us. To learn more or to discuss a security audit please click here.