Merge pull request #89 from opencomputeproject/solid

Integrate SOLID

Author: ericeilertson

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
 

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",
                         }                        
                       }
                     }

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
 }
 

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,93 +167,15 @@ 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
 public [GitHub](https://github.com/opencomputeproject/OCP-Security-SAFE) repositories after the review (and remediation and re-testing)
 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).