Protecting the Storage Platform Through Measurement and Attestation: Part 4

Trust Establishment with Secure Boot 

Until now we have been talking about the sequences for establishing trust.  There are two main types of approaches for establishing trust with secure boot.  One approach is designed for a system of components that has no inherent hardware root-of-trust security. To establish trust in this situation, Microchip produces security chips that can be placed in between flash and the SOC (see Figure 1).  These security chips put the SOC in boot hold-off mode during reset, until the SOC code signature has been validated. Subsequent trust steps can be taken by executing verified code to test additional code executables that are resident in the external SPI flash memory.  

Figure 1
 

The second approach for establishing trust is to build security chip functionality directly into a system’s individual parts. This is the approach Microchip takes with its Adaptec storage products. They provide all the same security features of the Microchip security chips, while eliminating the need for adding any external security devices.  

Figure 2

In the embedded trust scenario described in the prior section, the code was verified and that the part booted correctly. The software is now running, but it is not clear what version it might be. To solve this problem, attestation provides the methods to determine and prove what firmware is running and how the hardware is configured. 

Importance of Attestation 

Figure 3

Microchip has many products with embedded security such as storage controllers, Switchtec PCI switches, and UBM controllers (on the left).  

We also have many security devices available, as well (on the right.) 

For more information, visit www.microchip.com. 

In this attestation example, private part-specific signing keys are used to authenticate the measurements that are sent to the platform. Random values, called nonces, are sent by the platform attester to the device. They are incorporated into the measurements to inject a bit of randomness into the response measurements to prevent replay attacks. The attester validates the measurements for that particular attestation session using the part’s unique public certificate and key.  

With an attestation process in place, the system designer can now look at additional measures. In the next article in this series, we will talk about these additional measures 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. 

Sources of Additional Information 

There are numerous security projects underway as those working in this area have been quite prolific. The below should not be considered an exhaustive list but a good place to begin investigation into security for compute. In particular, the Open Compute Security Project is an excellent forum for those interested in designing platform security.  

Attestation can be used to measure the hardware and firmware and detect if any changes have occurred that impact the trustworthiness of the platform. This makes it possible to detect problems such as old, back-dated firmware versions with security holes, firmware meant for another platform, non-secured parts, and/or hardware tampering. 

For security reasons, measurements are taken early in startup and stored in the write-once registry of the part. The write-once registry is the source for measurement conveyance. Each device, when queried, provides the attestation value which can be compared for validation purposes to another set of attestation values stored in the platform-level measurement database. Figure 3 shows how this works. 

Part 1: Understanding the Changes in the Security Landscape

Part 2: Threat Modeling for the New Age of Protection

Part 3: Understanding How Secure Trusted Firmware Translates into Solution Requirements and Product Guarantees

Part 5: Additional Measures for Protecting the Storage Platform