Clarify Scope 3 physical-attack review scope - #98
Conversation
Signed-off-by: Jasper Van Woudenberg <jasper@keysight.com>
| CVSS is not the primary rating for these findings. | ||
| * **Review activities:** The review should examine the threat model, persistent-secret hierarchy, provisioning and | ||
| lifecycle design, hardware design and RTL, relevant firmware and software, debug controls, sanitization, and | ||
| physical-attack countermeasures. The SRP must test fault-injection and side-channel-analysis countermeasures in |
There was a problem hiding this comment.
I am concerned about the simulation requirement here, as this would require the SRPs to posses knowledge of ASIC simulation environments, which are complex and vary a lot depending on the DV. Further it would require the SRP to possess the skills to simulate physical attack countermeasures, which for an ASIC is often in the analog domain. All of this is also contingent on the SRP having access to the simulation environment in the first place, which I would consider highly unlikely and lead to a scope 3 review being quite uncommon to pursue.
Overall SRPs should be bringing their security expertise to the review, and not be required to perform the detailed simulation, and instead be reviewing the DVs approach to this.
| provisioned, and the lifecycle phases in which a physical attacker can access it. The physical attack window for a | ||
| secret begins when that secret is generated or provisioned. | ||
| * **Manufacturing and supply chain:** After secret generation or provisioning and before entry into a trusted data | ||
| center, the threat model should allow for prolonged physical possession and access to laboratory equipment. Relevant |
There was a problem hiding this comment.
| center, the threat model should allow for prolonged physical possession and access to laboratory equipment. Relevant | |
| center, the threat model should assume an attacker has prolonged physical possession and access to laboratory equipment sufficient to develop reliable attacks. Relevant |
| center, the threat model should allow for prolonged physical possession and access to laboratory equipment. Relevant | ||
| attacks may include exposed debug interfaces, PCB probing or modification, interposers, bus sniffing or injection, | ||
| voltage or clock fault injection, and power or electromagnetic side-channel analysis. | ||
| * **Data center:** The threat model should allow for repeated physical-access windows of up to 30 minutes. Reviews |
There was a problem hiding this comment.
| * **Data center:** The threat model should allow for repeated physical-access windows of up to 30 minutes. Reviews | |
| * **Data center:** The threat model should allow for repeated physical-access windows of up to 30 minutes, enough time only to execute a pre-developed attack. Reviews |
| * 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. | ||
| * **Scope 3 - Resilience to physical attacks:** Scope 3 focuses on physical attacks against persistent secrets and the | ||
| controls that protect or use them. Persistent secrets are secret values that remain available across power cycles or |
There was a problem hiding this comment.
This significantly limits the focus to just the persistent secrets. This is probably sufficient when referencing side-channel attacks, but for fault injection I think we want to cast the net a little wider. Control flow is the common target of fault injection, and often subverts other crucial security features of importance (like secure boot). Implementing effective mitigations across a complex SoC (as opposed to an isolated TPM or security controller) is also particularly difficult, and pretty unheard-of in data center class devices. I would like to hear some input from the CSPs on what level of protection they realistically expect from the vendors in this regard.
| affect the entire device class. This does not require invasive physical testing unless it is included in the agreed | ||
| review scope. | ||
| * **Finding rating:** Scope 3 physical-attack findings must be rated using | ||
| [JIL Application of Attack Potential to Smartcards and Similar Devices, version 3.2.1](https://sogis.eu/documents/cc/domains/sc/JIL-Application-of-Attack-Potential-to-Smartcards-v3.2.1.pdf). |
There was a problem hiding this comment.
With this documentation change we will also want to make supporting changes to the corim schema and the python library. I suggest including jil-version (default to 3.2.1) and jil-attack-potential-exploitation but leaving jil-attack-potential-identification as optional (these are public so identification/discovery is assumed to be 0 anyway)
3 participants
Summary
This PR clarifies the threat model and review requirements for OCP S.A.F.E. Scope 3, per OCP global presentation https://www.youtube.com/watch?v=bTJbYiN7SI4 .
Scope 3 focuses on physical attacks against persistent secrets and the controls that protect or use them. The revised text defines the applicable lifecycle stages, attacker access, treatment of class secrets, required review activities, and finding-rating method.
Rationale
The existing Scope 3 section identifies glitch and side-channel resistance but does not define the protected assets, realistic physical-access assumptions, lifecycle boundaries, class-secret risk, or expected review evidence.
The added detail keeps Scope 3 practical for data-center products without turning S.A.F.E. into a prescriptive certification checklist. It also distinguishes mandatory simulation testing of physical-attack countermeasures from optional physical testing.
Review notes
The JIL method is referenced rather than reproduced so that S.A.F.E. does not maintain a separate or potentially divergent attack-potential definition.
Invasive and in-package attacks are included for class secrets because successful extraction may create a break-once, apply-across-the-class attack. Their inclusion in the threat model does not make invasive physical testing mandatory.