| # OpenPRoT Specification | |
| Version: v0.5 - Work in Progress | |
| ## Introduction | |
| The concept of a Platform Root of Trust (PRoT) is central to establishing a | |
| secure computing environment. A PRoT is a trusted component within a system that | |
| serves as the foundation for all security operations. It is responsible for | |
| ensuring that the system boots securely, verifying the integrity of the firmware | |
| and software, and performing critical cryptographic functions. By acting as a | |
| trust anchor, the PRoT provides a secure starting point from which the rest of | |
| the system's security measures can be built. This is particularly important in | |
| an era where cyber threats are becoming increasingly sophisticated, targeting | |
| the lower layers of the computing stack, such as firmware, to gain persistent | |
| access to systems. | |
| OpenPRoT is a project intended to enhance the security and transparency of PRoTs | |
| by defining and building an open source firmware stack that can be run on a | |
| variety of hardware implementations. Open source firmware offers several | |
| benefits that can enhance the effectiveness and trustworthiness of a PRoT. | |
| Firstly, open source firmware allows for greater transparency, as the source | |
| code is publicly available for review and audit. This transparency helps | |
| identify and mitigate vulnerabilities more quickly, as a global community of | |
| developers and security experts can scrutinize the code. It also reduces the | |
| risk of hidden backdoors or malicious code, which can be a concern with | |
| proprietary firmware. | |
| Moreover, an open source firmware stack can foster innovation and collaboration | |
| within the industry. By providing a common platform that is accessible to all, | |
| developers can contribute improvements, share best practices, and develop new | |
| security features that benefit the entire ecosystem. This collaborative approach | |
| can lead to more robust and resilient firmware solutions, as it leverages the | |
| collective expertise of a diverse community. Additionally, open source firmware | |
| can enhance interoperability and reduce vendor lock-in, giving organizations | |
| more flexibility in choosing hardware and software components that best meet | |
| their security needs. | |
| Incorporating an open source firmware stack into a PRoT not only strengthens the | |
| security posture of a system but also aligns with broader industry trends | |
| towards openness and collaboration. As organizations increasingly recognize the | |
| importance of securing the foundational layers of their computing environments, | |
| the combination of a PRoT with open source firmware represents a powerful | |
| strategy for building trust and resilience in the face of evolving cyber | |
| threats. | |
| ## Background | |
| Today's Platform Root of Trust (PRoT) solutions are often specifically designed | |
| for their target platform, relying on custom interfaces or protocols. This leads | |
| to slower time-to-market due to the integration effort required. Customers can | |
| become locked into a single solution, making it costly and time-consuming to | |
| change suppliers, which in turn introduces supply chain risks. | |
| The Open Platform Root-of-Trust (OpenPRoT) stack is an open and extensible | |
| standards-compliant root-of-trust firmware stack for use in root-of-trust | |
| elements. The project was initiated to create an OCP specification for a | |
| Platform Root of Trust software stack, along with an open-source implementation | |
| of that specification. The OpenPRoT stack provides base root-of-trust services | |
| in an open architecture that allows hardware vendors to provide both standard | |
| and value-added services. | |
| ## Goals | |
| The vision of the OpenPRoT project is to enable implementation consistency, | |
| transparency, openness, reusability, and interoperability. The primary goals of | |
| the project are to: | |
| * **Create an OCP specification** for a Platform Root of Trust (PRoT) firmware | |
| stack. | |
| * **Create an open-source implementation** of the specification. | |
| * **Target new and existing PRoT hardware implementations**, with a preference | |
| for Open Silicon. | |
| * **Enable optionality** for integrators through stable interfaces while | |
| maintaining a high security bar. | |
| * **Standardize PRoT hardware interfaces**, such as an add-in card connector | |
| on the DC-SCM board. | |
| * **Promote reusability** through collaboration with standards bodies and | |
| hardware RoT projects to create robust, modular firmware. | |
| ## Industry standards and specifications | |
| OpenPRoT is designed to be a standards-based and interoperable Platform Root of | |
| Trust (PRoT) solution. This ensures that OpenPRoT can be integrated into a wide | |
| range of platforms and that it leverages proven and well-defined security and | |
| management protocols. | |
| ### Distributed Management Task Force (DMTF) | |
| - **DSP0274**: Security Protocol and Data Model (SPDM) Version 1.3 or later | |
| - **DSP0277**: Secured Messages using SPDM over MCTP Binding | |
| - **DSP0236**: Management Component Transport Protocol (MCTP) Base Specification | |
| - **DSP0240**: Platform Level Data Model (PLDM) Base Specification | |
| - **DSP0248**: Platform Level Data Model (PLDM) for Platform Monitoring and Control Specification | |
| - **DSP0267**: Platform Level Data Model (PLDM) for Firmware Update Specification | |
| ### Trusted Computing Group (TCG) | |
| - **DICE Layering Architecture**: Device Identity Composition Engine | |
| - **DICE Attestation Architecture**: Certificate-based attestation | |
| - **DICE Protection Environment (DPE)**: Runtime attestation service | |
| - **TCG DICE Concise Evidence Binding for SPDM**: Evidence format specification | |
| ### National Institute of Standards and Technology (NIST) | |
| - **NIST SP 800-193**: Platform Firmware Resiliency Guidelines | |
| - **NIST FIPS 186-5**: Digital Signature Standard (DSS) | |
| - **NIST SP 800-90A**: Recommendation for Random Number Generation | |
| - **NIST SP 800-108**: Recommendation for Key Derivation Functions | |
| ## High Level Architecture | |
| The OpenPRoT architecture is designed to be a flexible and extensible platform | |
| Root of Trust (PRoT) solution. It is built upon a layered approach that | |
| abstracts hardware-specific implementations, providing standardized interfaces | |
| for higher-level applications. This architecture promotes reusability, | |
| interoperability, and a consistent security posture across different platforms. | |
| ### Block Diagram | |
| The following block diagram illustrates the high-level architecture of OpenPRoT. | |
| <img src="openprot_diagram.svg" alt="figure2" width="700"/> | |
| ### Architectural Layers | |
| The OpenPRoT architecture can be broken down into the following layers: | |
| 1. **Hardware Abstraction Layer (HAL):** At the lowest level, the | |
| [Driver Development Kit](./device_abstraction/README.md) (DDK) provides | |
| hardware abstractions. This layer is responsible for interfacing with the | |
| specific RoT silicon and platform hardware. | |
| 2. **Operating System:** Above the DDK sits the operating system, which | |
| provides the foundational services for the upper layers. | |
| 3. **Middleware:** This layer consists of standardized communication protocols | |
| that enable secure and reliable communication between different components | |
| of the system. Key protocols include: | |
| * [MCTP](./middleware/mctp.md) (Management Component Transport Protocol): | |
| Provides a transport layer that is compatible with various hardware | |
| interfaces. | |
| * [SPDM](./middleware/spdm.md) (Security Protocol and Data Model): Used | |
| for establishing secure channels and for attestation. | |
| * [PLDM](./middleware/pldm.md) (Platform Level Data Model): Provides | |
| interfaces for firmware updates and telemetry retrieval. | |
| 4. **Services:** This layer provides a minimal set of standardized services | |
| that align with the OpenPRoT specification. These services include: | |
| * **Lifecycle Services:** Manages the lifecycle state of the device, | |
| including secure debug enablement. | |
| * **Attestation:** Aggregates attestation reports from platform | |
| components. | |
| * [Firmware Update & Recovery](./services/fwupdate.md): Orchestrates the | |
| secure update and recovery of firmware for platform components. | |
| * **Telemetry:** Collects and extracts telemetry data. | |
| 5. **Applications:** At the highest level are the applications that implement | |
| the core logic of the PRoT. These applications have room for differentiation | |
| while being built upon standardized interfaces. Key applications include: | |
| * **Secure Boot:** Orchestrates the secure boot process for platform | |
| components. | |
| * **Policy Manager:** Manages the security policies of the platform. |