Protecting the Storage Platform Through Measurement and Attestation | Part 3: Understanding How Secure Trusted Firmware Translates into Solution Requirements and Product Guarantees
From a customer standpoint, these are concerns we hear the most:
Gray market product infiltration into the data center
Loss of information/IP
Altered products (hardware and firmware)
Continuous secure operations
Ability to recover from exploits
Verification of running systems
Data security (encryption)
Denial of service attacks (system shutdown)
Above we mentioned gray market and altered products getting into data centers, such as hard drives and adapter cards. Quite often, unless something goes wrong and the manufacturer is contacted, a user doesn’t realize they’re not running an official certified device. Larger data center customers or OEMS are especially concerned about security, such as hardware root of trust for ASICs, continuous firmware monitoring and verification. Other concerns include:
Hardware root of trust for ASICs
Firmware recovery and restoration
Continuous firmware monitoring and verification
Encrypting firmware
Reduction in attack surfaces
Product hardening
Intrusion detection (PCI, Driver, UART, etc.)
Secure manufacturing (authorized products)
Ownership and personalization
Customers would like the ability to go into their data centers, scan all the devices in their system and know the exact version of firmware that it's running. And they want proof that it's the true version, not having been compromised. Attestation is a process that takes measurements of both the hardware and firmware. Measurements must be signed by a device specific certificate to ensure authenticity, exported out of that trust zone, and then a trustee must verify the content.
Market Demands
From a market demand perspective, companies are continuing to talk about security. We’re moving from a general discussion around security to the standardization of specifications and implementation solutions, such as the Open Compute Project (OCP) Security Project, PCI Special Interest Group (SIG) Proposals and the DMTF’s new Security Task Force within its Platform Management Components Intercommunication (PMCI) working group.
From the time a decision is made, to the time the ASIC is ready, it could be close to three years. Here at Microchip, we’ve been making educated predictions about what the market is going to need from a security perspective and then embodying it in in silicon. The next generation of Microchip storage products will have embedded security. Separate from the storage components, Microchip also offers a broad portfolio of security parts for applications where security is not a feature of an ASIC implementation.
The point is, embedded security is already on the path to implementation for industry designs.
Security is About Trust
Customers want re-assurance that their information is held securely, and that the firmware running on that platform is trusted. That trust starts in the foundry and is carried out through manufacturing, on to integration - all the way to the customer site and ultimately to the system user.
Secure Boot in Action
Secure boot embeds information in the ASIC, such as the embedded public signing keys, the code to create security hashes and the code to provide decryption of a privately signed signature block. The set of embedded items can be used to validate external code stores prior to execution, establishing a chain of trust emanating from the hardware root of trust.
Step 1: The first set of code created is very small, very tight, highly protected and unmodifiable. The immutable, authenticated code lives in the ASIC. The ASIC with the secure code runs and reads the flash that has the signature adjacent to it, computes the hash of that code and then compares it to the decrypted version of the signature that was adjacent to the code. If the signatures and code match the external store then the code is executed.
Steps 2 - 4: The validated first executable will then move on to validate the next flash executable in succession using the same process as boot ROM. This slowly builds the root of trust model for all stages of executables that are found in flash.
Microchip ASICs contain industry approved hardware engines which aid in the performance of the cryptographic operations making for efficient operation and industry acceptance.
Digital Signatures
Early in the blog, the topic of digital signatures was broached, but possibly left unexplained. Digital signatures are used to authenticate firmware by verifying the signature during the firmware boot process. The process starts when developers create code and send it to a signing service. The signing service then computes a SHA Hash and the output is encrypted with a secured private key (key vault), yielding what is called the signature block.
Signature blocks are then stored in flash adjacent to the firmware image that the chips are running. Signature blocks can only be created by the holder of the private key, and then validated by the public key held in silicon. The ASIC reads the firmware at startup, computes the same SHA Hash again. The signature block stored in flash is decrypted with the public key and compared. If the computed and decrypted values match, the code will run. The process is repeated at every stage of code execution.
In the fourth part of the series, we’ll explore what attestation measurements are and how they translate and prove what firmware is running on the platform.
Part 1: Understanding the Changes in the Security Landscape
Part 2: Threat Modeling for the New Age of Protection
Part 5: Additional Measures for Protecting the Storage Platform