Create a Cerberus Attestation Spec. #27
Conversation
|
Hey Chris, this is great to see! I'm not sure I'll be able to consume the whole document by the time the next meeting comes around, but I look forward to reading it in full. =) |
There was a problem hiding this comment.
Hi Chris, I've gone through and left comments where I think we can do some work to clarify. Overall, I think the spec looks in great shape already. There are places where I might have organized it differently myself but those can be dealt with after the spec is merged.
| PMRs, but it is mandatory for every device to at least support PMR0. Beyond | ||
| that, there is a lot of flexibility regarding how they are used. What is | ||
| documented here are considered 'best practices' for different classes of | ||
| Cerberus device. |
There was a problem hiding this comment.
I think a reference to how measurement components are extracted via the Get Attestation Data command would be useful. Could you add a link to the section below that describes that?
| PMR3 and PMR4 are provided to offer similar functionality as a TPM. A | ||
| processor could extend its own data into the PMRs managed by Cerberus. The | ||
| state of these PMRs could then be used as part of attestation claims. |
There was a problem hiding this comment.
Let me make sure I follow... a processor can write its own data to a PMR using the Update PMR command, which must occur in an encrypted session. This would then be included in, say, the authorization section of an unsealing request.
What's the specific security benefit of this? The authz section is supposed to allow the third party to ask the RoT to verify the machine's state wrt a specific expectation, so it seems that anything the processor incorporates isn't "trusted" in this sense, so it would not allow meaningfully constraining the policy. I suspect I'm missing something so clarification is appreciated.
| for attestation requests. If a valid cache exists that matches the current | ||
| digests, any number of these requests may be skipped. | ||
| 3. Verify that the root CA is trusted. How this trust is established depends on | ||
| the requestor. Another Cerberus device will use information in the CFM to |
There was a problem hiding this comment.
I think "another" isn't the right word here. Do you mean another device not involved in this procedure, or do you mean another possible implementation of trust anchors?
|
|
||
| `Message Unseal` can also attest to the state of device PMRs, but without | ||
| necessarily getting the PMR values from the device directly. This flow works if | ||
| the Attestor has some secret or other artifact that is required for the system |
There was a problem hiding this comment.
I might have missed where we define "attestor", but we should clarify that this is a third party separate from the processor and the RoT.
| 2. Determine the set of expected PMR values for the device. | ||
| 3. Generate a random seed. | ||
| - If the Seal/Unseal will use ECDH, this seed is the ECDH shared secret using | ||
| a random ECC keypair and the Cerberus ECC public key. |
There was a problem hiding this comment.
Which public key? Is it the one in the end entity cert being used?
RoT/Protocol/Cerberus_Attestation.md
Outdated
| | `8` | `pmr_data_count` | Number of PMR entries whose measured data should beck checked during attestation. | | ||
| | `8` | `allowable_pfm_count` | Number of PFM IDs to check during attestation. | <!-- PFM count probably only needs to be 4 bits. We might want to leave CFM as 8 bits for future flexibility. --> | ||
| | `8` | `allowable_cfm_count` | Number of CFM IDs to check during attestation. | | ||
| | `8` | `allowable_pcd_count` | Presence of a PCD ID check during attestation. | <!-- Why do we need this? Would presence of the element achieve this? And if we really do, why not just a flag? --> |
There was a problem hiding this comment.
Can you elaborate on what this is supposed to achieve? The description and the comment aren't quite clear.
| - Passive | ||
| - Active | ||
|
|
||
| ## Component Firmware Manifest |
There was a problem hiding this comment.
There's a lot of opens for the CFM. Are they worth working through in one of the weeklies?
| modifications to the flow. | ||
|
|
||
| 1. The unused regions of flash will not be blank checked. | ||
| 2. Any signed images that do not assert the `PFM.FirmwareVersion.MustValidate` |
There was a problem hiding this comment.
Presumably this should be PFM.FrmwareVersion.validate to refer to the field?
RoT/Protocol/Cerberus_Attestation.md
Outdated
| | <- | | ||
| ``` | ||
|
|
||
| If the CFM entry contains multiple PMR digest entries, the |
There was a problem hiding this comment.
Is this in addition to or separately from the challenge?
RoT/Protocol/Cerberus_Attestation.md
Outdated
| | `00000b` | `_` | Padding for the unused HashType bits. This must be 0. | | ||
| | `Manifest.HashType` | `hash_type` | The type of hash used to generate the PMR digest. | | ||
| | `8` | `digest_count` | Number of allowable digests for this PMR. | | ||
| | `hash_type(digest_count)` | `pmr_digest` | Expected digest for the PMR. | |
There was a problem hiding this comment.
Presumably this the actual value currently stored in the PMR, insofar as the PMR is built by repeated hashing?
|
Here is an updated version of the spec after significant internal reviews and updates. I do still need to come back and address all the comments here, and see how many have been addressed with the updates that have been posted. |
- Add details about discovering the device type using SPDM - Additional RoT configuration for flash management behavior
…different versions of FW.
…irements. Revert table formatting changes that were done by mistake.
This is the initial draft of the attestation spec. There are still several opens in the document that we have yet to close internally, but overall it has a lot of content that can be reviewed even though it is not ready to release as-is.