Firmware is vulnerable to exploitation, but firmware for NXP processors can be secured, protecting all three opportunities: system boot, firmware update and runtime.
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
- Runtime
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 onboard 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
runtime 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.
By Joe Byrne, Senior Strategic Marketing Manager, NXP
and Ravi Malhotra, Senior Software Product Marketing Manager, NXP
