From cf6f0d6a574eaabe3355368145fb8c46e0a9c1e9 Mon Sep 17 00:00:00 2001 From: Nick Hummel Date: Tue, 12 May 2026 14:47:37 +0200 Subject: [PATCH 1/3] Integrate SOLID --- ...E-CoRIM-Extension-Profile-Specification.md | 169 +---------- .../examples/ocp-safe-sfr-fw-example.diag | 3 +- .../corim_profile/ocp-safe-sfr-profile.cddl | 1 + Documentation/framework.md | 94 +----- Documentation/review_areas.md | 192 ------------- Documentation/review_scope.md | 271 ++++++++++++++++++ Documentation/srp_approval_process.md | 2 +- README.md | 2 +- 8 files changed, 286 insertions(+), 448 deletions(-) delete mode 100644 Documentation/review_areas.md create mode 100644 Documentation/review_scope.md diff --git a/Documentation/corim_profile/OCP-SAFE-CoRIM-Extension-Profile-Specification.md b/Documentation/corim_profile/OCP-SAFE-CoRIM-Extension-Profile-Specification.md index e9f53da..f1d33de 100644 --- a/Documentation/corim_profile/OCP-SAFE-CoRIM-Extension-Profile-Specification.md +++ b/Documentation/corim_profile/OCP-SAFE-CoRIM-Extension-Profile-Specification.md @@ -140,6 +140,7 @@ ocp-safe-sfr-map = { &(scope-number: 3) => integer ? &(fw-identifiers: 4) => [ + fw-identifier ] ? &(issues: 5) => [ + issue-entry ] + ? &(solid-version: 6) => tstr * $$ocp-safe-sfr-map-ext } ``` @@ -162,7 +163,8 @@ ocp-safe-sfr-map = { | Field | Key | Type | Description | |-------|-----|------|-------------| | fw-identifiers | 4 | array | Array of firmware identifier objects | -| issues | 6 | array | Array of security issues identified during review | +| issues | 5 | array | Array of security issues identified during review | +| solid-version | 6 | tstr | Version of the SOLID requirements checked against | ### Firmware Identifiers @@ -307,172 +309,11 @@ To ensure broad interoperability: ### Profile CDDL -```cddl -; Auditor CoRIM – Corim which embeds the SFR fields -; OCP SAFE SFR CoRIM Profile OID: 1.3.6.1.4.1.42623.1.1 - -$$measurement-values-map-extension //= ( - &(ocp-safe-sfr: -1) => ocp-safe-sfr-map ; Private extension for OCP SAFE SFR -) - -ocp-safe-sfr-map = { - &(review-framework-version: 0) => tstr - &(report-version: 1) => tstr - &(completion-date: 2) => time - &(scope-number: 3) => integer - ? &(fw-identifiers: 4) => [ + fw-identifier ] - ? &(issues: 5) => [ + issue-entry ] - * $$ocp-safe-sfr-map-ext -} - -issue-entry = { - &(title: 0) => tstr - &(description: 1) => tstr - &(assessment: 2) => $assessment - ?&(cwe: 3) => tstr - ?&(cve: 4) => tstr - * $$ocp-safe-issue-entry-ext -} - -$assessment /= cvss - -cvss = { - &(score: 0) => tstr - &(vector: 1) => tstr - &(version: 2) => tstr -} - -fw-identifier = non-empty<{ - ? &(fw-version: 0) => version-map - ? &(fw-file-digests: 1) => digests-type - ? &(repo-tag: 2) => tstr - ? &(src-manifest: 3) => src-manifest -}> - -manifest-entry = { - &(filename: 0) => tstr - &(file-hash: 1) => digests-type -} - -src-manifest = { - &(manifest-digest: 0) => digests-type - &(manifest: 1) => [ + manifest-entry ] -} -``` +[This file](./ocp-safe-sfr-profile.cddl) contains the formal definition. ### Example CoRIM with SFR Extension -The following example demonstrates a complete CoRIM structure containing OCP S.A.F.E. SFR security review findings: - -```cbor-diag -/ tagged-corim-map / 501({ - / corim.id (0) / - 0: "acme-trap-audit-2025-08-03", - / corim.profile (3) / - 3: 111(h'060A2B0601040182F4170101'), / OID 1.3.6.1.4.1.42623.1.1 for OCP SAFE SFR profile / - / corim.entities (5) / - 5: [ - / audit-entity / { - / entity-name (0) / 0: "My Pentest Corporation", - / role (2) / 2: [ 1 ] / manifest-creator / - } - ], - / corim.tags / 1 : [ - / concise-mid-tag / 506( << - / concise-mid-tag / { - / comid.tag-identity / 1 : { - / comid.tag-id / 0 : "acme-trap-review-comid-001" - }, - / comid.triples / 4 : { - / conditional-endorsement-triples / 10 : [ - [ / conditional-endorsement-triple-record / - [ / conditions array / - [ / *** stateful-environment-record *** / - / environment-map / { - / comid.class / 0 : { - / comid.vendor / 1 : "ACME Inc.", - / comid.model / 2 : "ACME RoadRunner Trap" - } - }, - [ / claims-list / - / *** measurement-map *** / { - / comid.mval / 1 : { - / comid.digests / 2 : [ [ - / hash-alg-id / -43, / sha384 / - / hash-value / h'52047e070cddf496a7f77bf6a47792797e8ee90a149bb7555d08c5f93c5ca7ea46a63a7c99edaa1659e8afadfb9c6114' - ], - [ - / hash-alg-id / -44, / sha512 / - / hash-value / h'12a5b961a5eb7e548ed436fe7b5848d428bff908cb6ffcb47ec3ac1e2a43e0b8d1ff047d387fb0a940dc7b8b0014acf344364c43ab4de624dcd15f98bee552a5' - ] - ] - } - } - ] - ] - ], /*** end stateful-environment-records ***/ - [ /*** endorsements ***/ - [ /*** endorsed-triple-record ***/ - / environment-map / { - / class / 0 : { - / vendor / 1 : "ACME Inc.", - / model / 2 : "ACME RoadRunner Trap" - } - }, - [ / endorsement #1/ - / measurement-map / { - / comid.mval / 1 : { / measurement-values-map / - / ocp-safe-sfr / -1 : { - / 0: review-framework-version / 0: "1.1", - / 1: report-version / 1: "1.2", - / 2: completion-date / 2: 1(1687651200), - / 3: scope-number / 3: 1, - / 4: fw-identifiers / 4: [ - /fw-identifier / { - / 0: fw-version / 0: { - / 0: version / 0: "1.2.3", - / 1: version-scheme / 1: "semver" - } - } - ], - / 5: issues / 6: [ - / issue-entry / { - / 0: title / 0: "Memory corruption when reading record from SPI flash", - / 1: description / 1: "Due to insufficient input validation in the firmware, a local attacker who tampers with a configuration structure in SPI flash, can cause stack-based memory corruption.", - / 2: assessment / 2: { - / 0: cvss-score / 0: "7.9", - / 1: cvss-vector / 1: "AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:L", - / 2: cvss-version / 2: "3.1" - }, - / 3: cwe / 3: "CWE-111" - }, - / issue-entry / { - / 0: title / 0: "Debug commands enable arbitrary memory read/write", - / 1: description / 1: "The firmware exposes debug command handlers that enable host-side drivers to read and write arbitrary regions of the device's SRAM.", - / 2: assessment / 2: { - / 0: cvss-score / 0: "8.7", - / 1: cvss-vector / 1: "AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L", - / 2: cvss-version / 2: "3.1" - }, - / 3: cwe / 3: "CWE-222", - / 4: cve / 4: "CVE-2014-10000" - } - ] - } - } - } - ] - ] - ] - ] - ] - } - } - >> ) - ] - } -) -``` +[This example file](./examples/ocp-safe-sfr-fw-example.diag) demonstrates a complete CoRIM structure containing OCP S.A.F.E. SFR security review findings. ## References diff --git a/Documentation/corim_profile/examples/ocp-safe-sfr-fw-example.diag b/Documentation/corim_profile/examples/ocp-safe-sfr-fw-example.diag index 8b8e006..21c33cc 100755 --- a/Documentation/corim_profile/examples/ocp-safe-sfr-fw-example.diag +++ b/Documentation/corim_profile/examples/ocp-safe-sfr-fw-example.diag @@ -90,7 +90,8 @@ / 3: cwe / 3: "CWE-222", / 4: cve / 4: "CVE-2014-10000" } - ] + ], + / 6: solid-version / 6: "1.0", } } } diff --git a/Documentation/corim_profile/ocp-safe-sfr-profile.cddl b/Documentation/corim_profile/ocp-safe-sfr-profile.cddl index e440ac9..6d9b766 100755 --- a/Documentation/corim_profile/ocp-safe-sfr-profile.cddl +++ b/Documentation/corim_profile/ocp-safe-sfr-profile.cddl @@ -12,6 +12,7 @@ ocp-safe-sfr-map = { &(scope-number: 3) => integer ? &(fw-identifiers: 4) => [ + fw-identifier ] ? &(issues: 5) => [ + issue-entry ] + ? &(solid-version: 6) => tstr * $$ocp-safe-sfr-map-ext } diff --git a/Documentation/framework.md b/Documentation/framework.md index f9f47b3..c9ee417 100644 --- a/Documentation/framework.md +++ b/Documentation/framework.md @@ -142,7 +142,7 @@ The conditions under which these reviews take place, are of two main types: At a high level, the process flows through the following sequence of steps: 1. DV selects an SRP from the list of [approved providers](./security_review_providers.md). -2. DV and SRP prepare a scope for the security review according to the [Security Review Scope](#security-review-scope) information provided below and in the supplementary [review areas](./review_areas.md). +2. DV and SRP prepare a scope specific to the security review according to the general [Review Scope](./review_scope.md). 3. SRP performs the security review. 4. DV addresses any findings from the SRP. 5. SRP reviews the changes and issues the final reports. @@ -167,84 +167,6 @@ The key objectives of this framework are: * Through iterative refinement of review areas, testing scopes, and reporting requirements, progressively advance the security posture of hardware and firmware components across the supply chain. -## Security Review Scope - -The following sections describe at a high level the areas that should be in scope for any security audit performed under -this framework. -They are intended as starting points for DVs and SRPs when undertaking a device or firmware security assessment. Under -the framework, it is required for every production version of device firmware to have undergone the assessment. A more -detailed -description of the scopes is provided in the [review areas](./review_areas.md) document. - -* **Threat Model** \ - The SRP should assess the DV’s documented threat models and perform a gap analysis, ensuring they are adequately - covered by the observed hardware and firmware implementation. If the DV cannot provide a threat model, then the SRP - should create one as part of the assessment scope. The threat model document should include the following details, and - be aligned with the in-scope and out-of-scope threats described by - the [Common Security Threats](https://www.opencompute.org/documents/common-security-threats-notes-1-pdf) - document: - * **Security Objectives**: The high-level security objectives or key - risks exposed by the firmware. Examples of such objectives may include the strict requirement that the secure boot - or firmware anti-rollback features must not be subverted or bypassed by an attacker. - * **Adversarial Model**: A listing of all threat actors along with their - motivation and capabilities. Examples may include a simple opportunistic hardware adversary, or advanced - persistent threats that are able to keep the device under antagonistic conditions for an extended duration. - * **Attack Surface Enumeration**: A listing of all remote, local and - physical attack surfaces exposed by the device. Examples may include mailbox or IPC interfaces exposed via MMIO, a - command shell exposed via a serial interface, inter-chip buses which transmit sensitive data, or external - non-volatile storage media. - * **Critical Assets**: A listing of all security-impacting assets within - the firmware, and the corresponding Confidentiality, Integrity and Availability requirements for each. Examples of - critical assets may include secret keys, the fuse configuration, or any configuration data residing in external flash. - -The SAFE program defines 3 security review scopes. These scopes increase with complexity of attacks in the threat model. -It is expected that devices will have reviews done with different review scopes. For example, a CPU may have a scope 3 -review of the root of trust due to the need for glitch protection when using a long-term device private key. This CPU -may use a scope 2 review for the application cores. - -* **Scope 1 Code and Architecture Assessment** - * **Source Code Review** \ - The SRP should perform a whitebox security review of the device’s ROM and mutable firmware source code for - identification of vulnerabilities and lapses in industry best practices. Issues uncovered during the review should - be fixed by the DV and subsequently verified as fixed by the SRP. The review scope should include: - * Analysis of the firmware loading and verification procedures to ensure that a secure boot implementation is - present and cannot be circumvented. All critical assets that impact the device’s security must be - cryptographically signed. The - OCP [Secure Boot](https://www.opencompute.org/documents/secure-boot-2-pdf) - document should be used for guidance. - * Discovery of hard-coded credentials, seeds, private keys, or symmetric secrets. - * Identifying temporal and spatial memory safety issues that arise due to improper input validation or race - conditions that may occur along the attack surfaces that were identified in the threat model. - * Discovery of remnant debug handlers on production builds - * Analysis of the cryptographic constructions employed by the firmware when protecting the confidentiality or - integrity of any critical assets. - * Improper handling of cryptographic material, e.g. keys, counters, nonces, seeds. - * Trust-boundary violations between privilege levels or across components, such as confused deputy problems or - insufficient privilege separation between a firmware’s user and supervisor modes. - * Identify outdated third-party libraries which are associated with publicly known CVEs. - * Evaluation of exploit mitigation technologies such as: Address space randomization, stack canaries, data - execution prevention, NULL page mapping, guard pages, and so on. - * **Sensitive Functionality Review** \ - The SRP should review the firmware source code and should describe the presence and scope of all - security-sensitive or commonly “restricted” functionality. This review can be used by consumers to measure risk - and to configure deployment or isolation controls. The review scope should include: - * TCG DICE implementation. - * SPDM implementation. - * Remote firmware update, manageability, or command and control functionality. - * Manufacturing, debug, diagnostics, testing and logging capabilities. - * Unauthenticated APIs. - * Safe generation and handling of all cryptographic material. - * Encryption capability controls (disk encryption, erase, rotation). - * Secure boot key rotation capabilities. -* **Scope 2 - Focusing on Trust boundaries:** Includes all of the areas of Scope 1 above, with deeper review focus of the following areas: - * Trusted execution environment assessment - * Handling of trust boundaries - * Attestation and non-repudiation across boundaries - * Authenticated and encrypted IO, e.g., PCIe-IDE, TDISP, or vendor proprietary -* **Scope 3 - Resilience to physical attacks** - * Critical components and operations are designed to securely handle glitch attacks in a documented way - * Crypto blocks are designed to be resistant to side channel analysis. - ## OCP Report Deliverables This framework stipulates that the following be delivered to the OCP SAFE program for publication in the appropriate @@ -252,8 +174,8 @@ public [GitHub](https://github.com/opencomputeproject/OCP-Security-SAFE) reposit has concluded: * **Scope Document** \ - DV and SRP should jointly negotiate the scope of the review, based on the - [review areas](#security-review-scope). As alluded to above, the areas are neither exhaustive nor complete, therefore + DV and SRP should jointly negotiate the scope of the review, based on the general + [Review Scope](./review_scope.md). As alluded to above, the areas are neither exhaustive nor complete, therefore the DV is encouraged to socialize the Scope with the OCP Security WG, either through its regular calls, or on its mailing list. The scope itself can be any number of documents, as long as the concatenation of them is provided to the OCP Security WG. Aside from level of assessment effort, no part of the DV/SRP statement of work, NDAs, etc. needs to be published. @@ -262,7 +184,7 @@ has concluded: in the signed SFR (after remediation and retesting). This document will summarize the audit scope, and uniquely identify the vendor, device and firmware version by means of a firmware hash. This report will enumerate all vulnerabilities with a CVSS score and a brief summary. The short-form report specification can be found in - [Appendix B](#appendix-b-machine-readable-short-form-report-format). To claim OCP SAFE endorsement for a + [here](./corim_profile/ocp-safe-sfr-profile.cddl). To claim OCP SAFE endorsement for a product-firmware combination this report must be published to the OCP GitHub repository. This signed SFR is delivered to the DV for publication. * **GitHub Pull Request Submission**\ @@ -278,8 +200,7 @@ has concluded: the submission may choose to additionally include the human-readable SFR documents. * **SRP Public Key Pull Request Path**\ The public signing key of each SRP is published to the location SRP_certificates/$SRP. These are to be published and maintained by - the SRP, and may be revoked by the TAC (see [Disqualification](#Disqualification) above). - + the SRP, and may be revoked by the TAC (see [SRP Approval Process](./srp_approval_process.md)). In addition to the short-form report, the SRP should deliver to the DV a detailed report. This report will likely be protected by NDA and will not be published. The DV should address the findings in the report. The DV is encouraged to @@ -313,8 +234,3 @@ Several SRP sample reports can be found in [Appendix A](#appendix-a-example-repo and other [public reports](https://www.nccgroup.com/us/research-blog/?category=18157#hub) * NCC's first review of [Caliptra](https://chipsalliance.github.io/Caliptra/) can be found [here](https://github.com/chipsalliance/Caliptra/blob/main/doc/NCC_Group_Microsoft_MSFT283_Report_2023-10-13_v1.2.pdf) - -# Appendix B: Machine Readable Short-Form Report Format - -A reference implementation of the library to produce and verify short form reports is available -in [this repo](https://github.com/opencomputeproject/OCP-Security-SAFE). diff --git a/Documentation/review_areas.md b/Documentation/review_areas.md deleted file mode 100644 index 56881f4..0000000 --- a/Documentation/review_areas.md +++ /dev/null @@ -1,192 +0,0 @@ -# Assessment Scope - -This section provides guidance for the areas expected to be assessed by an SRP. The list is purposefully vague because -the OCP Workgroup believes that high quality, timely assessments are best achieved by letting the SRPs focus on the -architectural and implementation areas that are commonly known to have gaps or deficiencies in the scenario under -review. - -### Documentation - -#### Build Standards (Based on CC v3.1) - -1. Version identification -2. Vulnerability management and publication -3. Configuration management and protection -4. Build repeatability and consistency -5. Behavior and implementation align with design -6. Tool chain security features -7. HW security features -8. Development standards - -#### SDL - -1. Threat model -2. Static analysis configuration and practices -3. Fuzzing tools, configuration and coverage -4. Management of third party dependencies -5. Build configuration - -#### Security Implementation Details (HDL and LDL) - -1. Secure boot design and specific configuration -2. Update process design and specific configuration -3. Recovery design and specific configuration -4. Telemetry design and specific configuration -5. Cryptographic design and specific configuration -6. Attestation design and specific configuration -7. Debugging design and specific configuration -8. Debugging protection design -9. Authorisation/Authentication design and specific configuration/management - -#### Security Compliance and Compliance - -1. Security Certifications for DUT -2. Security Certifications for third parties libraries -3. Full memory map for volatile and non-volatile memory -4. Life cycle management for memory including secure erasure and update - -#### Evidence - -1. Cryptographic test vector evidence -2. Entropy source(s) analysis and evidence -3. Certifications and methods linking to dependencies (e.g. ACME Crypto library v1.2 is certified on public register to - FIPS 140-3) -4. Fuzzing results - -#### Security Information Details (both documented and DV internal) - -1. Debugging implementation -2. Logical and physical interfaces -3. Services running on DUT -4. All API's implemented on DUT - -### - -### Code Review - -#### Booting and general - -1. Secure Boot -2. Immutable Hardware Root of Trust (Integrity, revocation, anti-rollback, key manifests) -3. Firmware secret sanitization -4. Firmware test/debug functionality sanitization -5. Secure updates -6. Firmware development best practice - 1. Input validation - 2. Backdoors - 3. Typical development errors - 4. Use of deprecated or insecure functions - 5. Memory safe programming - 6. Dependencies -7. Secure erasure -8. Exploit mitigation -9. Configuration hardening -10. Secure boot must be attack resistant - -#### Attestation - -1. Attestation support for persistent storage -2. Attestation enforcement for security configuration -3. Cryptographic tamper detectable logs -4. Securely implemented runtime attestation mechanism -5. HW ROT support/enforce quoting attestation claims at boot -6. HW ROT support/enforce quoting attestation claims at runtime -7. Enforcement of measurements for firmware/software loaded into DUT -8. Enforcement of measurements for security configuration loaded into DUT -9. Support for attestation challenges - -#### Update - -1. Support only secure firmware update -2. Attestation claims must use asymmetric cryptographic mechanisms -3. Updates in progress must be validated prior to committing to persistent storage -4. Attack and exploit resistant - -#### End of Life / De-provisioning / Ability to securely re-provision - -1. Secrets and storage must support secure erasure and reset -2. HW ROT key store must support secure erasure -3. Debug interfaces can only be re-enabled on entire secure erasure of DUT or with appropriate cryptographic - challenge/response mechanism - -#### Cryptography - -1. Cryptographic algorithms must be industry standards or appropriate technical justification -2. Implemented Cryptography certification (e.g. FIPS 140-3) -3. Implemented Cryptography configuration (CNSA) -4. Unsecured persistent event/log storage sanitization -5. Unique or replaceable symmetric keys per device -6. Assets at rest must be appropriately cryptographically protected -7. Assets in memory must be appropriately protected/isolated -8. Keys and other critical security parameters are zeroed when no longer in use -9. Secure support for re-provisioning of all cryptographic material - -#### Auditing & Telemetry - -1. Secure logging and telemetry -2. Configurable logging to support security events -3. Cryptographic tamper detectable logs - -#### Debug - -1. Debugging mode must be disabled by default -2. Debug and test code should not be present in production DUT -3. Debug interfaces can only be re-enabled on entire secure erasure of DUT or with appropriate cryptographic - challenge/response mechanism -4. If debugging functionality can be re-enabled, it must not provide any sensitive information -5. If enabled, debug should be disabled automatically on idle timeout or reboot -6. If re-enabled, debug interfaces and functionality must not compromise DUT security posture, secrets or claims - -#### Secure management - -1. Cryptographically appropriate authentication required for management functions -2. Management functions must operate under the principle of least privilege -3. Cryptographically appropriate transport layer for management functions, e.g. TLS - -#### Dependencies - -1. Third party software/firmware components including version specifics recorded in SBOM -2. Configuration specifics for third party dependencies recorded in SBOM -3. Third party dependencies up to date -4. Third party dependencies version pinned and in change control - -#### Hardening - -1. Interfaces must enforce authentication and authorization specific to the interface -2. Security sensitive operations restricted to trusted interfaces -3. Ability to disable all functionality, API’s, services not required for deployment - -#### Trusted Execution Environment - -1. DV implemented TEE's must generally conform to standards evolving in the Confidential Computing Consortium. -2. Trusted execution environment has physical and logical safeguards to provide isolation from other processing entities -3. IO from the TEE follows industry standards such as IDE or TDISP. If a proprietary protocol is used, e.g. XGMI, - NVLINK, it must provide similar authentication, integrity, and isolation guarantees - -#### Root of Trust - -1. HW ROT shall be both through design and implementation appropriately isolated and protected from application and - control processes. -2. The HW ROT shall measure and endorse boot and runtime code -3. If the HW ROT supports bulk cryptographic engines, the HW ROT must support secure key transport to and from the bulk - cryptographic engine -4. The HW ROT shall be appropriately attack and tamper resistant -5. The HW ROT shall implement cryptographically secure tamper resistant logs -6. The HW ROT shall be appropriately cryptographically bound to DUT - -#### Identity - -1. DUT shall implement TCG DICE -2. DUT Identity must be non-repudiable -3. DUT identity must include DUT version -4. DUT version must be reproducible from SBOM - -#### Volatile and non-volatile storage - -1. Encrypted memory or storage uses industry standard crypto e.g., AES-XTS -2. Encryption keys must be generated to appropriate length and entropy to comply with FIPS/CNSA standards -3. Encryption keys must not be stored/cache in associated volatile or non-volatile storage -4. Wrapped keys, typically used for storage or transport, must have a mechanism to detect modification or replay -5. Encryption mechanisms are resistant to side channel attacks -6. The separate [storage sanitization requirements](storage_sanitization.md) must be met. - diff --git a/Documentation/review_scope.md b/Documentation/review_scope.md new file mode 100644 index 0000000..e1daa21 --- /dev/null +++ b/Documentation/review_scope.md @@ -0,0 +1,271 @@ +# Review Scope + +The review scope is guided by to important aspects: + +1. What security characteristics should the product fulfill? +2. What are important areas to look at as part of a review? + +The first point is provided by [OCP S.O.L.I.D.](https://github.com/opencomputeproject/OCP-Security-SOLID), which defines requirements per product type. S.A.F.E. reviews must check if S.O.L.I.D. requirements are met. It is mandatory for these gaps to be listed in long-form reports starting from 2026-10-01. At some point in the future it will also become mandatory to list them in short-form reports as issues. + +The second point is the definition of review areas below. Note that the review areas are purposefully vague because the OCP believes that high quality, timely assessments are best achieved by letting the review providers focus on the architectural and implementation areas that are commonly known to have gaps or deficiencies in the scenario under review. + +## High-level review areas + +This section describes at a high level the areas that should be in scope for any security audit performed under this framework. +It is intended as starting point for vendors and review providers when undertaking a device or firmware security assessment. Under +the framework, it is required for every production version of device firmware to have undergone the assessment. + +* **Threat Model** \ + The review provider should assess the vendor's documented threat models and perform a gap analysis, ensuring they are adequately + covered by the observed hardware and firmware implementation. If the vendor cannot provide a threat model, then the review provider + should create one as part of the assessment scope. The threat model document should include the following details, and + be aligned with the in-scope and out-of-scope threats described by + the [Common Security Threats](https://www.opencompute.org/documents/common-security-threats-notes-1-pdf) + document: + * **Security Objectives**: The high-level security objectives or key + risks exposed by the firmware. Examples of such objectives may include the strict requirement that the secure boot + or firmware anti-rollback features must not be subverted or bypassed by an attacker. + * **Adversarial Model**: A listing of all threat actors along with their + motivation and capabilities. Examples may include a simple opportunistic hardware adversary, or advanced + persistent threats that are able to keep the device under antagonistic conditions for an extended duration. + * **Attack Surface Enumeration**: A listing of all remote, local and + physical attack surfaces exposed by the device. Examples may include mailbox or IPC interfaces exposed via MMIO, a + command shell exposed via a serial interface, inter-chip buses which transmit sensitive data, or external + non-volatile storage media. + * **Critical Assets**: A listing of all security-impacting assets within + the firmware, and the corresponding Confidentiality, Integrity and Availability requirements for each. Examples of + critical assets may include secret keys, the fuse configuration, or any configuration data residing in external flash. + +The SAFE program defines 3 security review scopes. These scopes increase with complexity of attacks in the threat model. +It is expected that devices will have reviews done with different review scopes. For example, a CPU may have a scope 3 +review of the root of trust due to the need for glitch protection when using a long-term device private key. This CPU +may use a scope 2 review for the application cores. + +* **Scope 1 Code and Architecture Assessment** + * **Source Code Review** \ + The review provider should perform a whitebox security review of the device’s ROM and mutable firmware source code for + identification of vulnerabilities and lapses in industry best practices. Issues uncovered during the review should + be fixed by the vendor and subsequently verified as fixed by the review provider. The review scope should include: + * Analysis of the firmware loading and verification procedures to ensure that a secure boot implementation is + present and cannot be circumvented. All critical assets that impact the device’s security must be + cryptographically signed. The + OCP [Secure Boot](https://www.opencompute.org/documents/secure-boot-2-pdf) + document should be used for guidance. + * Discovery of hard-coded credentials, seeds, private keys, or symmetric secrets. + * Identifying temporal and spatial memory safety issues that arise due to improper input validation or race + conditions that may occur along the attack surfaces that were identified in the threat model. + * Discovery of remnant debug handlers on production builds + * Analysis of the cryptographic constructions employed by the firmware when protecting the confidentiality or + integrity of any critical assets. + * Improper handling of cryptographic material, e.g. keys, counters, nonces, seeds. + * Trust-boundary violations between privilege levels or across components, such as confused deputy problems or + insufficient privilege separation between a firmware’s user and supervisor modes. + * Identify outdated third-party libraries which are associated with publicly known CVEs. + * Evaluation of exploit mitigation technologies such as: Address space randomization, stack canaries, data + execution prevention, NULL page mapping, guard pages, and so on. + * **Sensitive Functionality Review** \ + The review provider should review the firmware source code and should describe the presence and scope of all + security-sensitive or commonly “restricted” functionality. This review can be used by consumers to measure risk + and to configure deployment or isolation controls. The review scope should include: + * TCG DICE implementation. + * SPDM implementation. + * Remote firmware update, manageability, or command and control functionality. + * Manufacturing, debug, diagnostics, testing and logging capabilities. + * Unauthenticated APIs. + * Safe generation and handling of all cryptographic material. + * Encryption capability controls (disk encryption, erase, rotation). + * Secure boot key rotation capabilities. +* **Scope 2 - Focusing on Trust boundaries:** Includes all of the areas of Scope 1 above, with deeper review focus of the following areas: + * Trusted execution environment assessment + * Handling of trust boundaries + * Attestation and non-repudiation across boundaries + * Authenticated and encrypted IO, e.g., PCIe-IDE, TDISP, or vendor proprietary +* **Scope 3 - Resilience to physical attacks** + * Critical components and operations are designed to securely handle glitch attacks in a documented way + * Crypto blocks are designed to be resistant to side channel analysis. + +## Concrete review areas + +### Documentation + +#### Build Standards (Based on CC v3.1) + +1. Version identification +2. Vulnerability management and publication +3. Configuration management and protection +4. Build repeatability and consistency +5. Behavior and implementation align with design +6. Tool chain security features +7. HW security features +8. Development standards + +#### SDL + +1. Threat model +2. Static analysis configuration and practices +3. Fuzzing tools, configuration and coverage +4. Management of third party dependencies +5. Build configuration + +#### Security Implementation Details (HDL and LDL) + +1. Secure boot design and specific configuration +2. Update process design and specific configuration +3. Recovery design and specific configuration +4. Telemetry design and specific configuration +5. Cryptographic design and specific configuration +6. Attestation design and specific configuration +7. Debugging design and specific configuration +8. Debugging protection design +9. Authorisation/Authentication design and specific configuration/management + +#### Security Compliance and Compliance + +1. Security Certifications for DUT +2. Security Certifications for third parties libraries +3. Full memory map for volatile and non-volatile memory +4. Life cycle management for memory including secure erasure and update + +#### Evidence + +1. Cryptographic test vector evidence +2. Entropy source(s) analysis and evidence +3. Certifications and methods linking to dependencies (e.g. ACME Crypto library v1.2 is certified on public register to + FIPS 140-3) +4. Fuzzing results + +#### Security Information Details (both documented and vendor-internal) + +1. Debugging implementation +2. Logical and physical interfaces +3. Services running on DUT +4. All API's implemented on DUT + +### Code Review + +#### Booting and general + +1. Secure Boot +2. Immutable Hardware Root of Trust (Integrity, revocation, anti-rollback, key manifests) +3. Firmware secret sanitization +4. Firmware test/debug functionality sanitization +5. Secure updates +6. Firmware development best practice + 1. Input validation + 2. Backdoors + 3. Typical development errors + 4. Use of deprecated or insecure functions + 5. Memory safe programming + 6. Dependencies +7. Secure erasure +8. Exploit mitigation +9. Configuration hardening +10. Secure boot must be attack resistant + +#### Attestation + +1. Attestation support for persistent storage +2. Attestation enforcement for security configuration +3. Cryptographic tamper detectable logs +4. Securely implemented runtime attestation mechanism +5. HW ROT support/enforce quoting attestation claims at boot +6. HW ROT support/enforce quoting attestation claims at runtime +7. Enforcement of measurements for firmware/software loaded into DUT +8. Enforcement of measurements for security configuration loaded into DUT +9. Support for attestation challenges + +#### Update + +1. Support only secure firmware update +2. Attestation claims must use asymmetric cryptographic mechanisms +3. Updates in progress must be validated prior to committing to persistent storage +4. Attack and exploit resistant + +#### End of Life / De-provisioning / Ability to securely re-provision + +1. Secrets and storage must support secure erasure and reset +2. HW ROT key store must support secure erasure +3. Debug interfaces can only be re-enabled on entire secure erasure of DUT or with appropriate cryptographic + challenge/response mechanism + +#### Cryptography + +1. Cryptographic algorithms must be industry standards or appropriate technical justification +2. Implemented Cryptography certification (e.g. FIPS 140-3) +3. Implemented Cryptography configuration (CNSA) +4. Unsecured persistent event/log storage sanitization +5. Unique or replaceable symmetric keys per device +6. Assets at rest must be appropriately cryptographically protected +7. Assets in memory must be appropriately protected/isolated +8. Keys and other critical security parameters are zeroed when no longer in use +9. Secure support for re-provisioning of all cryptographic material + +#### Auditing & Telemetry + +1. Secure logging and telemetry +2. Configurable logging to support security events +3. Cryptographic tamper detectable logs + +#### Debug + +1. Debugging mode must be disabled by default +2. Debug and test code should not be present in production DUT +3. Debug interfaces can only be re-enabled on entire secure erasure of DUT or with appropriate cryptographic + challenge/response mechanism +4. If debugging functionality can be re-enabled, it must not provide any sensitive information +5. If enabled, debug should be disabled automatically on idle timeout or reboot +6. If re-enabled, debug interfaces and functionality must not compromise DUT security posture, secrets or claims + +#### Secure management + +1. Cryptographically appropriate authentication required for management functions +2. Management functions must operate under the principle of least privilege +3. Cryptographically appropriate transport layer for management functions, e.g. TLS + +#### Dependencies + +1. Third party software/firmware components including version specifics recorded in SBOM +2. Configuration specifics for third party dependencies recorded in SBOM +3. Third party dependencies up to date +4. Third party dependencies version pinned and in change control + +#### Hardening + +1. Interfaces must enforce authentication and authorization specific to the interface +2. Security sensitive operations restricted to trusted interfaces +3. Ability to disable all functionality, API’s, services not required for deployment + +#### Trusted Execution Environment + +1. Vendor implemented TEE's must generally conform to standards evolving in the Confidential Computing Consortium. +2. Trusted execution environment has physical and logical safeguards to provide isolation from other processing entities +3. IO from the TEE follows industry standards such as IDE or TDISP. If a proprietary protocol is used, e.g. XGMI, + NVLINK, it must provide similar authentication, integrity, and isolation guarantees + +#### Root of Trust + +1. HW ROT shall be both through design and implementation appropriately isolated and protected from application and + control processes. +2. The HW ROT shall measure and endorse boot and runtime code +3. If the HW ROT supports bulk cryptographic engines, the HW ROT must support secure key transport to and from the bulk + cryptographic engine +4. The HW ROT shall be appropriately attack and tamper resistant +5. The HW ROT shall implement cryptographically secure tamper resistant logs +6. The HW ROT shall be appropriately cryptographically bound to DUT + +#### Identity + +1. DUT shall implement TCG DICE +2. DUT Identity must be non-repudiable +3. DUT identity must include DUT version +4. DUT version must be reproducible from SBOM + +#### Volatile and non-volatile storage + +1. Encrypted memory or storage uses industry standard crypto e.g., AES-XTS +2. Encryption keys must be generated to appropriate length and entropy to comply with FIPS/CNSA standards +3. Encryption keys must not be stored/cache in associated volatile or non-volatile storage +4. Wrapped keys, typically used for storage or transport, must have a mechanism to detect modification or replay +5. Encryption mechanisms are resistant to side channel attacks +6. The separate [storage sanitization requirements](storage_sanitization.md) must be met. + diff --git a/Documentation/srp_approval_process.md b/Documentation/srp_approval_process.md index bf44eb6..48ef3c4 100644 --- a/Documentation/srp_approval_process.md +++ b/Documentation/srp_approval_process.md @@ -75,7 +75,7 @@ We encourage product vendors and consumers of reports to provide feedback on sec ### Technical expertise -We need to see evidence that you are capable of performing reviews covering the scopes outlined [here](review_areas.md). The more evidence you can provide the better. This is the most important part of considering your application. We understand that it is difficult to provide evidence due to NDAs. However, without sufficient evidence we have no way to judge whether you are capable of performing reviews to a high standard and will therefore not admit you to the program. +We need to see evidence that you are capable of performing reviews covering the scopes outlined [here](./review_scope.md). The more evidence you can provide the better. This is the most important part of considering your application. We understand that it is difficult to provide evidence due to NDAs. However, without sufficient evidence we have no way to judge whether you are capable of performing reviews to a high standard and will therefore not admit you to the program. These items can be suitable evidence, but we are open to anything you think might be helpful: diff --git a/README.md b/README.md index 95669e2..51c8df6 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@ S.A.F.E. stands for Security Appraisal Framework and Enablement, do not read too The [Framework](./Documentation/framework.md) page describes the objectives in more detail and explains how to engage with the program. -The [Review Areas](./Documentation/review_areas.md) page describes the areas that are to be reviewed as part of a S.A.F.E review. +The [Review Scope](./Documentation/review_scope.md) page defines what a review must look at. The [SRP Approval & Dismissal](./Documentation/srp_approval_process.md) page shows how to become an approved S.A.F.E. review provider. From 3a04bed5fed65a16f339ed7bbb29935f848fa7e9 Mon Sep 17 00:00:00 2001 From: Nick Hummel Date: Tue, 19 May 2026 16:37:04 +0200 Subject: [PATCH 2/3] Update python scripts with SOLID --- shortform_report-main/OcpReportLib.py | 4 ++++ shortform_report-main/example_dual_format_generation.py | 1 + shortform_report-main/example_gen_sign_verify.py | 1 + 3 files changed, 6 insertions(+) diff --git a/shortform_report-main/OcpReportLib.py b/shortform_report-main/OcpReportLib.py index d471082..5ac368e 100644 --- a/shortform_report-main/OcpReportLib.py +++ b/shortform_report-main/OcpReportLib.py @@ -200,6 +200,7 @@ def add_audit( date: str, report_ver: str, scope_number: int, + solid_ver: str, cvss_ver: str = "3.1", ) -> None: """Add metadata that describes the scope of the security review. @@ -211,6 +212,7 @@ def add_audit( YYYY-MM-DD format. report_ver: Version of the report created by the SRP. scope: The OCP scope number of the audit, 1, 2, or 3. + solid_ver: OCP SOLID version the audit checks against. cvss_ver: Version of CVSS used to calculate scores for each issue. Defaults to "3.1". """ @@ -220,6 +222,7 @@ def add_audit( self.report["audit"]["completion_date"] = f"{date}".strip() self.report["audit"]["report_version"] = f"{report_ver}".strip() self.report["audit"]["scope_number"] = scope_number + self.report["audit"]["solid_ver"] = solid_ver self.report["audit"]["cvss_version"] = f"{cvss_ver}".strip() self.report["audit"]["issues"] = [] @@ -378,6 +381,7 @@ def _convert_to_corim_structure(self) -> Dict[str, Any]: 2: completion_timestamp, # completion-date 3: self.report["audit"]["scope_number"], # scope-number 4: fw_identifiers, # fw-identifiers + 6: self.report["audit"]["solid_ver"], # solid-version } if corim_issues: diff --git a/shortform_report-main/example_dual_format_generation.py b/shortform_report-main/example_dual_format_generation.py index 9f583bb..9707d96 100644 --- a/shortform_report-main/example_dual_format_generation.py +++ b/shortform_report-main/example_dual_format_generation.py @@ -67,6 +67,7 @@ def main(): "2023-06-25", # Test completion date "1.2", # Report version 1, # The OCP SAFE scope level + "1.0", # The OCP SOLID version ) # Add security issues diff --git a/shortform_report-main/example_gen_sign_verify.py b/shortform_report-main/example_gen_sign_verify.py index f5c0ec6..83c7fa4 100644 --- a/shortform_report-main/example_gen_sign_verify.py +++ b/shortform_report-main/example_gen_sign_verify.py @@ -88,6 +88,7 @@ "2023-06-25", # Test completion date "1.2", # Report version 1, # The OCP SAFE scope level + "1.0", # The OCP SOLID version ) # Add issue details. From aedd01cedeeb7e9c59c3fd6d1eb8040e71428700 Mon Sep 17 00:00:00 2001 From: Nick Hummel Date: Tue, 19 May 2026 16:44:37 +0200 Subject: [PATCH 3/3] Make SOLID version optional in python --- shortform_report-main/OcpReportLib.py | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/shortform_report-main/OcpReportLib.py b/shortform_report-main/OcpReportLib.py index 5ac368e..81355bf 100644 --- a/shortform_report-main/OcpReportLib.py +++ b/shortform_report-main/OcpReportLib.py @@ -200,7 +200,7 @@ def add_audit( date: str, report_ver: str, scope_number: int, - solid_ver: str, + solid_ver: str = None, cvss_ver: str = "3.1", ) -> None: """Add metadata that describes the scope of the security review. @@ -381,12 +381,14 @@ def _convert_to_corim_structure(self) -> Dict[str, Any]: 2: completion_timestamp, # completion-date 3: self.report["audit"]["scope_number"], # scope-number 4: fw_identifiers, # fw-identifiers - 6: self.report["audit"]["solid_ver"], # solid-version } if corim_issues: sfr_map[5] = corim_issues # issues + if self.report["audit"]["solid_ver"]: + sfr_map[6] = self.report["audit"]["solid_ver"] # solid-version + return sfr_map def _build_class_map(self) -> dict: