Addressing Note on Attestation of System Components#89
Conversation
fdamato
force-pushed
the
fadamato/attestation_of_system_components_updates
branch
from
e479229 to
b21693f
Compare
fdamato
left a comment
fdamato
left a comment
There was a problem hiding this comment.
This is just a first pass. I added few comments on the notes
| @@ -417,7 +417,7 @@ This protocol is highly dependent on the specific technology of the platform, bu | |||
|
|
|||
| - *Platforms **MUST** be capable of interrogating attester devices that do not communicate their capabilities before being taken out of reset, e.g., by interrogating them later in the boot cycle or by having them pre-configured as such, in the platform reference manifest.* | |||
|
|
|||
| - *Platforms **MAY** use the message formats for GET\_CAPABILITIES and NEGOTIATE\_ALGORITHMS as described in* [Security Protocol and Data Model (SPDM) Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.0.0.pdf) or *Device Capabilities* *as described in [Project Cerberus Firmware Challenge Specification](https://github.com/opencomputeproject/Project_Olympus/blob/master/Project_Cerberus/Project%20Cerberus%20Challenge%20Protocol.pdf) .* *Where necessary, bridge components may be responsible for translating from the native bus protocol into the GET\_CAPABILITIES/ NEGOTIATE\_ALGORITHMS message formats.* | |||
| - *Platforms **MAY** use the message formats for GET\_CAPABILITIES and NEGOTIATE\_ALGORITHMS as described in* [Security Protocol and Data Model (SPDM) Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.0.0.pdf). | |||
|
|
|||
| ***NOTE from Bryan Kelly: "Replace Cerberus with GET_EAT"*** | |||
There was a problem hiding this comment.
Addressed below:
Attester devices MUST provide attestation evidence using one of the following methods:
- GET_EAT command returning an Entity Attestation Token (EAT) conforming to the OCP EAT Profile, OR
- GET_MEASUREMENTS command with the EAT located at SPDM Measurement Block 0xFD
| guidelines in this section. The OCP SPDM Profile requires support for the following | ||
| algorithms: | ||
|
|
||
| ***NOTE from Jeremy O'Donoghue: "I would prefer to see the requirements on interoperability moved to the verifier - it generally has lower security requirements than RoT and a more performance compute environment. For example: attester must support TPM_ALG_ECDSA_NIST_P384, TPM_ALG_SHA384, AES-256-GCM, TPM_ALG_MLDSA_65 (assuming that's what TCG eventually calls the algorithm). Verifier MAY support other algorithms."*** |
There was a problem hiding this comment.
Addressed below. Attesters have only to support
Tier 1: Mandatory Baseline Algorithms
There was a problem hiding this comment.
GET_MEASUREMENTS at slot 0xFD can also return a EAT, using a SPDM 1st class command. I left support for both GET_MEASUREMENTS and GET_EAT, if that works
| | MEAS_FRESH_CAP | 0 (may return cached measurements) | | ||
| | CHUNK_CAP | Supports CHUNK_SEND/CHUNK_GET | | ||
| | MEAS_CAP | Supports MEASUREMENTS and should support signed MEASUREMENTS (SPDM MEAS_CAP = 10b). | | ||
| | MEAS_FRESH_CAP | 0 (may return cached measurements) or 1 if EAT freshness is required | |
There was a problem hiding this comment.
I think we still want 0 here. 1 means: "The Responder shall support recomputing all MEASUREMENTS without requiring a Reset". Even if EAT freshness is needed, 1 is an anti-pattern. the measurements should not be recomputed.
There was a problem hiding this comment.
I agree...I`ll remove 1
Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>
fdamato
force-pushed
the
fadamato/attestation_of_system_components_updates
branch
from
b21693f to
b927ecb
Compare
| ### IETF EAT Binding for SPDM | ||
| To ensure interoperability and quantum readiness, this specification defines mandatory | ||
| baseline algorithms that all compliant devices must support. | ||
|
|
There was a problem hiding this comment.
move OCP Crypto Requirement in separate document, and refer to that one
There was a problem hiding this comment.
concern is that there might be some devices (or geos) not able to implement, for example, ML-DSA-87
There was a problem hiding this comment.
Suggestion, to point to the OCP EAT Profile (Defined Algorithms) and remove normative from here...
| | MEAS_FRESH_CAP | 0 (may return cached measurements) | | ||
| | CHUNK_CAP | Supports CHUNK_SEND/CHUNK_GET | | ||
| | CHUNK_CAP | Supports CHUNK_SEND/CHUNK_GET (required for large certificates and EATs) | |
There was a problem hiding this comment.
This should be conditional on the underlying transport capabilities. For example, PCIe DOE supports chunking of higher layer messages.
3 participants
No description provided.