Recommendation vs. Requirements language#606
Recommendation vs. Requirements language#606jameson-tetrel wants to merge 5 commits intochipsalliance:mainfrom
Conversation
… that should be requirements
jameson-tetrel
requested review from
Bryankel,
andreslagarcavilla,
jhprabhu and
nvpachou
as code owners
JohnTraverAmd
added
the
Trademark
| * Production Process Security | ||
| * Flaw Remediation Process | ||
|
|
||
| **By default, recommmendations, like requirements, MUST be followed unless there is sufficent, documented, and approved justification otherwise.** |
There was a problem hiding this comment.
Consider moving this to the Key Words section above.
| * **Evaluation Methodology:** Manufacturers MUST detail the security measures employed during the handling of the UDS seed, including access controls, secure storage practices, and sanitization procedures. | ||
| * **Checklist Item:** | ||
| * **Requirement**: Field Entropy SHOULD be generated on die, and not be exposed outside the die. | ||
| * **Recommendation**: Field Entropy SHOULD be generated on die, and not be exposed outside the die. |
There was a problem hiding this comment.
in light of the wording around recommendations above: what is the consequence to a trademark application of using external entropy? If this isn't something that would block a trademark grant, it should be removed.
There was a problem hiding this comment.
I think this should be relaxed. The UDS is still the underlying entropy, some Owners of Caliptra may want to provide the field entropy from their own enviornment.
| * **Requirement:** SOC firmware that interacts with Caliptra as the privileged PA\_USER MUST be measured, and those measurements MUST be submitted to Caliptra. Other SOC firmware SHOULD be measured. Configuration data that modifies the security properties of firmware MUST also be measured. | ||
| * **Requirement:** Measurements of firmware and configuration MUST be submitted to Caliptra before execution of the firmware, or usage of the configuration data. Measurements MUST be submitted to Caliptra by the same entity that collected the measurement (e.g. SOC FMC cannot pass measurements to SOC FW for submission to the Caliptra mailbox). | ||
| * **Requirement:** Measurements of firmware and configuration MUST be submitted to Caliptra before execution of the firmware, or usage of the configuration data. Measurements MUST be submitted to Caliptra by the same entity that collected the measurement (e.g. SOC FMC cannot pass measurements to SOC FW for submission to the Caliptra mailbox). | ||
| * **Recommendation:** SOC firmware that interacts with Caliptra as the privileged PA\_USER MUST be measured, and those measurements MUST be submitted to Caliptra. Other SOC firmware SHOULD be measured. Configuration data that modifies the security properties of firmware MUST also be measured. |
There was a problem hiding this comment.
Should the last sentence move to a new requirement?
There was a problem hiding this comment.
Measurements of firmware and configuration MUST be submitted to Caliptra before execution of the firmware
This change is incorrect. For non-RTM firmware there is no such ordering requirement.
What issues with the original version is this trying to address?
There was a problem hiding this comment.
@syncsrc-nv Fixed the intent here - just separation of shoulds and shalls.
Regarding ordering requirement, are you saying that it's sufficient for the (trusted) measuring entity to submit the measurement to caliptra, and when the (possibly untrusted) firmware executes need not be mandated in these requirements?
There was a problem hiding this comment.
Correct. For FW images that run on processors external to the RTM, execution prior to submission of measurements to Caliptra doesn't impact the chain of trust. If the RTM does not measure & submit correctly we are, definitionally, broken. Submitting measurements earlier does not detect or mitigate a broken RTM, and imposing a strict requirement that external FW must wait for Caliptra can be problematic for devices with agressive boot time requirements.
Splitting out the original version into individual requirements (with comments):
- SOC firmware that interacts with Caliptra as the privileged PA_USER MUST be measured, and those measurements MUST be submitted to Caliptra. (aka: the RTM must be measured, IMO this should not allow exceptions)
- Other SOC firmware SHOULD be measured. (I don't think we want to litigate what counts as FW that must be measured into Caliptra. Who defines the TCB that must be measured? Where does that end? If at least the privileged user is measured, then what Caliptra reports will be accurate)
- Configuration data that modifies the security properties of firmware MUST also be measured. (should change this to "properties of measured firmware" to avoid misinterpretation but otherwise this seems self-explanatory)
- Measurements MUST be submitted to Caliptra by the same entity that collected the measurement (this results in a mandate to submit-before-execute for RTM FW)
- Measurements of firmware and configuration MUST be submitted to Caliptra before execution of the firmware, or usage of the configuration data. (this is too strict, needs to be changed)
Suggested replacement wording:
- Measurements of firmware and configuration MUST be collected before execution of the firmware, or usage of the configuration data (needed in conjunction with the submission requirement to ensure correct ordering, but does not constrain the time at which non-RTM FW can begin execution)
|
|
||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). | ||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT" in this document are to be interpreted as requirements. | ||
| The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as recommendations. |
There was a problem hiding this comment.
Informally, it seems like "SHOULD"/"SHOULD NOT" are being treated as required-unless-waived, while the others "RECOMMENDED", "MAY", "OPTIONAL" are truly up to integrator discretion, and I think they're used that way in a few places throughout the specs.
This will need some more discussion.
…ion. It is likely that some of these will be rolled back to true recommendations, subject to discussion.
| * **Checklist Item:** | ||
| * **Recommendation**: Field Entropy SHOULD be generated on die, and not be exposed outside the die. | ||
| * **Evaluation Methodology**: Manufacturers SHOULD detail the generation process for, and document exposure of field entropy. | ||
| * **Requirement*:** Field Entropy MUST be generated on die, and not be exposed outside the die. |
There was a problem hiding this comment.
This seems like it should be a SHOULD? If the FE is generated on-die it must not be exposed externally, but I don't think there can be a mandate that FE can only be generated on-die.
| * **Requirement:** Signature generation operations using the firmware authentication key MUST be logged. | ||
| * **Recommendation:** Firmware authentication keys SHOULD be created and stored in a Hardware Security Module (HSM). | ||
| * **Recommendation:** Firmware authentication keys SHOULD require multi-party authentication to perform signing operations. | ||
| * **Requirement*:** Firmware authentication keys MUST be created and stored in a Hardware Security Module (HSM). |
There was a problem hiding this comment.
The other MUST requirements in this section are sufficient to ensure proper key storage, this was intended as a true recommendation and should remain a SHOULD.
| * **Recommendation:** Firmware authentication keys SHOULD be created and stored in a Hardware Security Module (HSM). | ||
| * **Recommendation:** Firmware authentication keys SHOULD require multi-party authentication to perform signing operations. | ||
| * **Requirement*:** Firmware authentication keys MUST be created and stored in a Hardware Security Module (HSM). | ||
| * **Requirement*:** Firmware authentication keys MUST require multi-party authentication to perform signing operations. |
There was a problem hiding this comment.
This also needs to remain a SHOULD, as it could preclude some automated workflows if strictly enforced.
| * **Checklist Item:** | ||
| * **Recommendation:** The integrity of each fuse SHOULD be maintained throughout the lifespan of the device to prevent degradation or tampering that could affect security. | ||
| * **Evaluation Methodology:** Manufacturers SHOULD describe the techniques used to ensure fuse integrity, such as redundancy, error correction codes (ECC), or other protective measures. | ||
| * **Requirement*:** The integrity of each fuse MUST be maintained throughout the lifespan of the device to prevent degradation or tampering that could affect security. |
There was a problem hiding this comment.
This is a SHOULD. It is not Caliptra's place to mandate device reliability targets. If there are specific fuses Caliptra needs integrity protection over, the Caliptra spec should be specifying multi-bit encodings.
| * **Checklist Item:** | ||
| * **Recommendation:** Authorization mechanisms SHOULD be implemented for in-field programmable fuses to prevent unauthorized updates that could lead to denial-of-service or other attacks. | ||
| * **Evaluation Methodology:** Manufacturers SHOULD document the authorization processes required to program fuses in the field, including cryptographic protections or authentication steps. | ||
| * **Requirement*:** Authorization mechanisms MUST be implemented for in-field programmable fuses to prevent unauthorized updates that could lead to denial-of-service or other attacks. |
There was a problem hiding this comment.
Another place where it's not clear Caliptra should be setting product requirements. Unless failure here impacts Caliptra's ability to function securely, this probably ought to remain a SHOULD
| * **Requirement:** Measurements of all firmware and configuration MUST be *collected* before execution of the firmware or usage of the configuration data. | ||
| * **Requirement:** Measurements MUST be submitted to Caliptra by the same entity that collected the measurement (e.g. SOC FMC cannot pass measurements to SOC FW for submission to the Caliptra mailbox). | ||
| * **Recommendation:** Other SOC firmware SHOULD be measured. | ||
| * **Requirement*:** Other SOC firmware MUST be measured. |
| * **Checklist Item:** | ||
| * **Recommendation:** The product SHOULD undergo thorough testing and verification during development, focusing on both functional correctness and security aspects. This includes testing of specific features and security mechanisms. | ||
| * **Evaluation Methodology:** Manufacturers SHOULD present test plans, results, and security analyses covering critical functionalities such as: | ||
| * **Requirement*:** The product MUST undergo thorough testing and verification during development, focusing on both functional correctness and security aspects. This includes testing of specific features and security mechanisms. |
There was a problem hiding this comment.
This ought to remain SHOULD, this is another product requirement that Caliptra has no business mandating. I had actually thought this requirement had been removed entirely.
4 participants
Still requires review of any recommendations that should be requirements
Addresses #594