Protecting the Storage Platform Through Measurement and Attestation: Part 5│Additional Measures for Protecting the Storage Platform
In previous installments, this series of articles has explored a variety of ways to protect the storage platform, including using attestation measurements. As we conclude this series, we look at other measures that should be considered, including creating a system of trust, ensuring that all component manufacturing is verified, securing all firmware updates, and implementing cryptographic obscurity and a secure debug mode.
System of Trust
Assume the system shown in Figure 1 to the right is a server. It contains the CPU complex, BMC, onboard flash, and a trusted security processor.
In some cases, there are non-modifiable golden images contained within the security chip that will bootstrap a system if it detects abnormalities with the external firmware. The golden image might only be enough to get the system up and running so it can be flashed again to a known good state. If there is enough storage space, the entire SPI flash can be restored.
This security processor not only assumes the interposer role but often has the additional role of communicating to all the devices in the system and validating the attestation values. This ensures that everything running in the system downstream is also trusted via a known set of attestation values.
Many in the industry would really like to see verified manufacturing of components. Figure 2 provides an example of how this can be accomplished.
To defend against these risks, every chip must be uniquely identified and certified, and be provided with a signed certificate as it is made. The provider guarantees it made the part, it is authentic, and it is traceable. This ensures that misplaced parts can later be revoked.
We believe certificates could be generated on a part-specific basis, using a secret generated within the chip. An alternative method is certificate injection but this often leads to error, interception, and other sorts of security problems. Ideally, the certificate request is generated within the part, the public certificate is signed, and then stored back with the part.
Customers can re-sign a part with their own certificate authority if desired. The process of re-signing is often referred to as transfer of ownership. At Microchip, we provide utilities enabling transfer of ownership from a Microchip device with Microchip keys to another company device with its own certificates and key materials.
Companies that inject company-specific key material take complete control of the signing and authorizing process for hardware and firmware. The downside of this approach is that the company also must manage firmware sources, binary code building, and signature processing with a protected Key Management infrastructure. Standing up such an infrastructure can be an extremely complex task.
Secure Firmware Update
A well-known specification released in May 2019 describes a good way to manage firmware on a chip: NIST document SP800-193. Below is one of the flows derived out of the specification document. SP800-193 covers additional content, and the diagram is not intended to document the entirety of the specification. As shown in Figure 3, the image is first decompressed into a non-persistent area to ensure it is lost in a re-start if it doesn’t clear the validation process. Validation tests are executed by running trusted firmware. If the downloaded firmware validates, the image is then moved to a persistent area.
Once the image is moved to flash and the full secure boot process is completed, the image in area one is now copied to area two of the SPI Flash.
After the programming step is completed, the secure firmware-management process detects whether a public key should be revoked in the ASIC. As a reminder, public keys are used to validate images and match a given private signing key for firmware. Revocation may occur under a variety of circumstances but should be infrequent.
Cryptographic Obscurity
The encryption of data related to a hardware component prevents inspection of details that could lead to compromise. A firmware-based encryption key could help in the transmission of firmware through various distribution channels. A unique ASIC encryption key would allow all the data flows on the right side of Figure 4, below, to be protected from inspection or migration. All data stored off-chip would be tied to the specific ASIC in use and could not be reused nor made useful.
Secure Debug Mode
Debug sessions are a necessity in the compute industry despite the best efforts of all involved. The inherent problem with debug mode is that it can be an open door to individuals with malicious intent. Debug enables invasive inspection, debug firmware loading and alteration of operation state.
Secure debug starts with the concept of closing down the entry points for debug such as JTAG or a UART. Entering into debug mode requires a controlled authorization process specific to the part in question. Part-specific information is collected and an authorization token using the information is returned to the part to activate debug. Once activated, ports can be opened and debug firmware can be loaded. The authorization tokens and the debug builds are restricted to a single part and a given debug session and cannot be reused. The process is illustrated in Figure 5.
We also have many security devices available, as well (on the right.)
For more information, visit us at www.microchip.com.
Sources of Additional Information
As in my last installment, I am including links to the right for additional information about security for compute.
Part 1: Understanding the Changes in the Security Landscape