So far in this series, we have looked at how products can be compromised, and we’ve reviewed specific security threats. We’ve also described processes to ensure that products are secure, including the best practices for meeting solution requirements and product guarantees using secure trusted firmware. In this article, let’s learn what attestation measurements are and how they can be used to further secure a server platform.
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.
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.
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
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.