OCP Security Announces version 1.0 specs for Root of Trust

Two weeks ago, we released a blog, where we discussed the evolution of data center security, and how the OCP Security workgroup has been chartered to come up with a set of specifications. These specifications will help open compute systems meet the evolving hardware security requirements of the NIST SP 800-193 firmware resilience guidelines, and protect, detect and recover from firmware attacks. In this blog, we would like to share more details and point you at the set of OCP Security specs.


The OCP model for protecting a platform is based on the concept that every device must first have a Root of Trust (RoT) that is responsible for verifying the device firmware at boot, keeping it authentic during updates, and recovering it when a corruption occurs.


The following diagram illustrates the model, at a platform level:

In this diagram, the following components should be called out:

  • The Platform this is the server being protected.
  • The Device/Peripherals are various extension cards, such as NICs, HBAs, SSDs, etc.
  • Platform Firmware typically resides on a set of SPI Flash components and is loaded into the CPU and/or BMC of the system during boot.
  • Device Firmware, which typically resides on and executed on the device.

In this system, the OCP Security group has defined two RoT components:

  • The Platform Active RoT (PA RoT) is the “main” RoT for the platform. It is responsible for verifying the system firmware, and for verifying the integrity of the peripherals.
  • The Active Component RoT (AC RoT) resides on every peripheral, verifies the integrity of that specific peripheral, and should report back, in a process called attestation, to the platform to prove its integrity. The process for doing that is called peripheral attestation.

When a system boots, each component (each device, as well as each peripheral) must first boot securely, using the RoT to ensure authenticity of its firmware, by verifying the firmware’s cryptographic signatures, and matching that to a policy that is defined by the system owner for authorizing only valid firmware signers.


Then, the PA RoT is responsible for requiring all devices in the system to attest - to prove in an irrefutable way that the firmware it is running is indeed what is expected. This process basically collects firmware measurements from all the devices, in a secure protocol, matching them also with a unique identity that each device is required to have, and policies to define what measurements are acceptable.


Once a PA RoT has booted the platform successfully, and has attested all devices, the platform is considered to be secured.


It is worth noting that in a typical data center, the whole platform also usually needs to attest to some external management fabric before being allowed to access other critical resources on the network. This platform-level attestation is usually handled with a TPM on the motherboard, using protocols that are defined by the Trusted Computing Group (TCG). The OCP Security group embraces these protocols and does not aim at replacing them in any way.


With that model in mind, OCP is happy to announce the release of the first set of specifications:

  1. Secure Boot - covers the requirements needed in order to be able to verify firmware integrity during boot.
  2. Peripheral Attestation - covers the requirements for having a unique identity for every device, and the ability to securely communicate device measurements from the AC RoT to the PA RoT.
  3. Threats Scope - a document that explains the various threat vectors being defended against, and helps map each of them to relevant feature requirements in the specs. This document also has, in the appendix, a conformance checklist that vendors will be expected to provide to the OCP community.

Keeping firmware integrity is critically important, but security is not complete until the firmware itself is improved to minimize chances of vulnerabilities. To that end, OCP has partnered with the Cloud Security Industry Summit organization (CSIS), and together published a Secure Firmware Development Best Practices Document residing in the OCP Github, that outlines critical requirements for developing secure firmware, along with a checklist that any firmware developer should follow. We encourage the community to contribute to this document and make it a living piece of information that continuously incorporates new and improved best practices.


As part of the Open Compute initiative to help customers know what to expect from compliant systems, there will be a new system to get OSF compliance badges. Similarly, OCP Security has defined a three-level badge that vendors can claim compliance to. We expect the badge system to take effect during 2021.


We expect security badges to have the following levels:

  • Bronze - For platforms and devices that implement all secure boot and attestation mandatory features support, and have provided the necessary conformance statement based on the threats that they have addressed.
  • Silver - For platforms that, in addition to meeting the Bronze requirements, have also implemented platform recovery, and are willing to open parts of their solution to the community.
  • Gold - For platforms that have implemented all the silver requirements, have implemented the optional features in the OCP specifications, and are fully open sourcing their root-of-trust firmware for community scrutiny.

The badge system will be updated on a yearly basis, and OCP will look forward to seeing many OCP platforms going after the gold badge for 2021.


Many member companies have contributed to these specs, and we would like to use this opportunity to thank everyone for their contributions.


The OCP Security work is not complete. We are now working on the next round of specs, which will cover Secure Firmware Updates and Recovery, Platform Requirements, and more. You can expect these to be released in the coming months.


You are also invited to join the security sessions during Tech Week. Just go to the event agenda, and select the Security track sessions to see what’s happening.


You can always find all of our specs on our Wiki page. We welcome additional community contributions!