Updated SOC Integration Requirements - chipsalliance#291

docs/CaliptraIntegrationSpecification.md

@@ -599,18 +599,26 @@ The following table describes SoC integration requirements.
 | Deobfuscation Key | Rotation of the deobfuscation key (if not driven through PUF) between silicon steppings of a given product (for example, A0 vs. B0 vs. PRQ stepping) is dependent on company-specific policies. | Statement of conformance | Required by UDS and Field Entropy threat model |
 | Deobfuscation Key | SoC backend flows should not insert deobfuscation key flops into the scan chain. | Synthesis report | Required by UDS and Field Entropy threat model |
 | Deobfuscation Key | For defense in depth, it is strongly recommended that debofuscation key flops are not on the scan chain. <br> Remove the following signals from the scan chain: <br> cptra_scan_mode_Latched_d <br> cptra_scan_mode_Latched_f <br> field_storage.internal_obf_key | Statement of conformance | Caliptra HW threat model |
+| Obfuscation Key | SOC shall ensure that obfuscation key is available (and wires are stable) before Caliptra reset is de-asserted. | Statement of conformance | Functionality and Security |
+| Obfuscation Key | SOC shall implement protections for obfuscation key generation logic and protect against debug/sw/scandump visibility.<br>1. Any flops outside of Caliptra that store obfuscation key or parts of the key should be excluded from scandump.<br>2. SOC shall ensure that the obfuscation key is sent only to Caliptra through HW wires, and it is not visible anywhere outside of Caliptra. | Statement of conformance | Required for Caliptra threat model |
 | DFT | Before scan is enabled (separate signal that SoC implements on scan insertion), SoC shall set Caliptra's scan_mode indication to '1 to allow secrets/assets to be flushed. | Statement of conformance | Required by Caliptra threat model |
 | DFT | Caliptra’s TAP should be a TAP endpoint. | Statement of conformance | Functional requirement |
 | Mailbox | SoC shall provide an access path between the mailbox and the application CPU complex on SoCs with such complexes (for example, Host CPUs and Smart NICs). See the [Sender Protocol](#sender-protocol) section for details about error conditions. | Statement of conformance | Required for Project Kirkland and TDISP TSM |
 | Fuses | SoC shall burn non-field fuses during manufacturing. Required vs. optional fuses are listed in the architectural specification. | Test on silicon | Required for UDS threat model |
 | Fuses | SoC shall expose an interface for burning field fuses. Protection of this interface is the SoC vendor’s responsibility. | Test on silicon | Required for Field Entropy |
 | Fuses | SoC shall write fuse registers and fuse done via immutable logic or ROM code. | Statement of conformance | Required for Caliptra threat model |
+| Fuses | SOC shall expose an API for programming Field Entropy as described in the architecture documentation. SOC shall ensure that Field Entropy can only be programmed via this API and shall explicitly prohibit burning of discrete Field entropy bits and re-burning of already burned Field Entropy entries. | Test on silicon | Required for Field Entropy |
+| Fuses | SOC shall ensure that any debug read paths for fuses are disabled in PRODUCTION lifecycle state.| Test on silicon | Required for Field Entropy |
+| Fuses | SOC shall ensure that UDS_SEED and Field Entropy supplied to Caliptra come directly from OTP fuses and there are no debug paths to inject new values.| Statement of conformance | Required for Caliptra Threat Model |
+| Fuses | SOC shall add integrity checks for Caliptra fuses as per SOC policy. | Statement of conformance | Reliability |
+| Fuses | SOC should apply shielding/obfuscation measures to protect fuse macro. | Statement of conformance | Required for Caliptra Threat Model |
+| Fuses | SoCs that intend to undergo FIPS 140-3 zeroization shall expose zeroization API as described in zeroization requirements in architecture specification. SoC shall apply appropriate authentication for this API to protect against denial of service and side channel attacks. | Test on Silicon | FIPS 140-3 certification |
 | Security State | SoC shall drive security state wires in accordance with the SoC's security state. | Statement of conformance | Required for Caliptra threat model |
 | Security State | If SoC is under debug, then SoC shall drive debug security state to Caliptra. | Statement of conformance | Required for Caliptra threat model |
 | Resets and Clocks | SoC shall start input clock before caliptra_pwrgood assertion. | Statement of conformance | Functional |
 | Resets and Clocks | SoC reset logic shall assume reset assertions are asynchronous and deassertions are synchronous. | Statement of conformance | Functional |
-| Resets and Clocks | SoC shall ensure Caliptra's powergood is the SoC's own powergood.  | Statement of conformance | Required for Caliptra threat model |
-| TRNG | SoC shall either provision Caliptra with a dedicated TRNG or shared TRNG.   | Statement of conformance | Required for Caliptra threat model and Functional |
+| Resets and Clocks | SoC shall ensure Caliptra's powergood is tied to SOC’s own powergood or any other reset which triggers SOC’s cold boot flow. | Statement of conformance | Required for Caliptra threat model |
+| TRNG | SoC shall either provision Caliptra with a dedicated TRNG or shared TRNG. It is highly recommended to use dedicated ITRNG | Statement of conformance | Required for Caliptra threat model and Functional |
 | TRNG | SoC shall provision the Caliptra embedded TRNG with an entropy source if that is used (vs. SoC-shared TRNG API support). | Statement of conformance | Functional |
 | TRNG | If the TRNG is shared, then upon TRNG_REQ, SoC shall use immutable logic or code to program Caliptra's TRNG registers. | Statement of conformance | Required for Caliptra threat model and Functional |
 | SRAMs | SoC shall ensure timing convergence with 1-cycle read path for SRAMs. | Synthesis report | Functional |
@@ -637,6 +645,11 @@ The following table describes SoC integration requirements.
 | FUSE PAUSER programming rules | 1 PAUSER attribute register is implemented at SoC interface: CPTRA_FUSE_VALID_PAUSER. | | |
 | FUSE PAUSER programming rules | CPTRA_FUSE_PAUSER_LOCK locks the programmable valid pauser register, and marks the programmed value as valid. | | |
 | FUSE PAUSER programming rules | Integrators can choose to harden the valid pauser for fuse access by setting the integration parameter, CPTRA_FUSE_VALID_PAUSER, to the desired value in RTL, and by setting CPTRA_SET_FUSE_PAUSER_INTEG to 1. | | |
+| Manufacturing | SoC shall provision an IDevID certificate with fields conforming to requirements in [architecture document](https:/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#provisioning-idevid-during-manufacturing). | Statement of conformance | Functionality |
+| Manufacturing | SOC shall implement protections for obfuscation key generation logic and protect against debug/sw/scandump visibility.<br>1. Any flops outside of Caliptra that store obfuscation key or parts of the key should be excluded from scandump.<br>2. SOC shall ensure that the obfuscation key is sent only to Caliptra through HW wires, and it is not visible anywhere outside of Caliptra. | Statement of conformance | Required for Caliptra Threat Model |
+| Chain of Trust | SoC shall ensure all mutable code and configuration measurements are stashed into Caliptra. A statement of conformance would list what is considered mutable code and configuration vs what is not. It would also describe the start of the boot sequence of the SoC and how Caliptra is incorporated into it. | Statement of conformance | Required for Caliptra Threat Model | 
+| Chain of Trust | SoC shall limit the mutable code and configuration that persists across the Caliptra powergood reset. A statement of conformance would list what does persist and why it is appropriate to do so. | Statement of conformance | Required for Caliptra Threat Model | 
+| Implementation | SoC shall apply size only constraints on cells tagged with u__size_only__ string and shall ensure that these are not optimized in synthesis and PNR | Statement of conformance | Required for Caliptra Threat Model |
 | GLS FEV | GLS FEV must be run to make sure netlist and RTL match and none of the countermeasures are optimized away. See the following table for example warnings from synthesis runs to resolve through FEV | GLS simulations pass | Functional requirement |
 
 *Table 18: Caliptra synthesis warnings for FEV evaluation*