Clarify Scope 3 physical-attack review scope

[jasperkeysight]

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.

[evan-a-a]

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.

[jasperkeysight]

The reasoning here is that's it's infeasible to reason sufficiently about side channel and fault issues from RTL alone, and since scope 3 includes these attacks, that pulls in simulation.

I think it's reasonable for qualified SRPs to work with DVs to get the simulation environment working, or to scrutinize existing simulation evidence of SCA/FI resistance. Having said that, this is highly specialized evaluation work where even a small misconfiguration can lead to false negatives. Should scope 3 capabilities be separate in lab approval?

[evan-a-a]

Yes, that is why we typically approach it with physical testing. In the case we are discussing here, where the DV has built a custom ASIC, I think the most reasonable approach is to review the implemented countermeasures, the simulation approach, and the simulation outputs. Requiring the SRP to run the simulation as is worded here seems unecessary. And I do agree that for this type of testing, there should be additional vetting of the SRP.

Additionally, for other types of products that receive scope 3 evaluations (ex. firmware on a COTS chip) simulation doesn't really apply; The countermeasures are fully software based and do not require simulation to verify. It's ok if we want to make scope 3 only applicable to custom ASICs, but that seems a bit limiting. I think this is the persistent problem with scope 3 being poorly defined at the moment.

[rob-tetrel]

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.

[jasperkeysight]

The intention is indeed to limit the relevant assets to the persistent secrets, and when a device is outside of the datacenter, non-persistent data is by definition no longer available.

So, that leaves FI within the datacenter. Extrapolating from '30 minutes access', this would limit the attacker to mod-chip type fault injection hardware, as opposed to carrying in a bulky laser setup.

Though there are certainly complex SoCs that have FI countermeasures, e.g. https://www.intel.com/content/www/us/en/security/security-practices/blogs/fault-injection-attacks.html, my concern would be adoption. I.e. let's first get the industry moving on persistent secrets.

[rob-tetrel]

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)