[doc] Manifest-Based Image Auth #1749
Conversation
swenson
requested review from
jhand2,
fdamato,
rusty1968,
bluegate010,
mhatrevi and
vsonims
as code owners
|
|
||
| The Caliptra-Endorsed Local Verifier could be required by the owner only or both the vendor and the owner. | ||
|
|
||
| The main difference between Caliptra-Endorsed Aggregated Measured Boot and Caliptra-Endorsed Local Verifier is if the SoC RoT is relying on the Measurement Manifest for SoC Secure Boot services as opposed as using it as an additional verification. |
There was a problem hiding this comment.
it is still not clear to me the difference between the 2 usage models.
- In case of "Caliptra-Endorsed Local Verifier" what is the remediation action SOC Manager should take in case of failure ? Assuming boot is not stopped.
Also being Calipta the RTM for the SOC, I would encourage Caliptra RT FW to attest to this failure in the DPE (How ???) Certificate.
There was a problem hiding this comment.
It's not 100% clear to me either. Maybe @mhatrevi can weigh in?
There was a problem hiding this comment.
Thanks Chris. I really would like to understand better the difference between usage models.
There was a problem hiding this comment.
Unresolving as I have the same question.
- The "Caliptra-Endorsed Aggregated Measured Boot" section states that one signed manifest includes measurements for a collection of different components.
- The "Caliptra-Endorsed Local Verifier" section first paragraph states that measurements of components are compared to a manifest.
Those sound like the same thing.
The main difference between Caliptra-Endorsed Aggregated Measured Boot and Caliptra-Endorsed Local Verifier is if the SoC RoT is relying on the Measurement Manifest for SoC Secure Boot services as opposed as using it as an additional verification.
So in both models the SoC is checking in with Caliptra whenever it boots code. In the second model the SoC is doing its own verification on top of that. If that's the case, it seems like we could just describe a single model of manifest flows. We can just say that this is a feature that SoCs can rely on, and they can optionally also do their own verification on top of that.
This adds sections describing the Manifest-Based Image Authorization system. I cleaned up a little bit of the manifest-based image auth commands and added some overview sections for what is new in the 1.1 and 1.2 runtime firmware to help keep things organized.
swenson
force-pushed
the
fw-spec-2.0-mba
branch
from
1b14a5d
to
95356ef
Compare
|
|
||
| ### Caliptra-Endorsed Local Verifier | ||
|
|
||
| A local verifier provides an authentication of SoC FW by matching SoC FW measurements with measurements from the Caliptra measurement manifest. In this case, the SoC RoT still has its own FW public-key chain that is verified by the SoC RoT, but in addition the SoC RoT introduces the Caliptra Measurement Manifest, which is endorsed by the Caliptra FW key pair. Caliptra provides approval or disapproval of the measurement of any FW back to the SoC RoT. This effectively provides a multi-factor authentication of SoC FW. |
There was a problem hiding this comment.
FW public-key chain
It's ambiguous whether this is a firmware signing key chain or a firmware attestation key chain. I presume this is the former.
|
|
||
| ### Caliptra-Endorsed Local Verifier | ||
|
|
||
| A local verifier provides an authentication of SoC FW by matching SoC FW measurements with measurements from the Caliptra measurement manifest. In this case, the SoC RoT still has its own FW public-key chain that is verified by the SoC RoT, but in addition the SoC RoT introduces the Caliptra Measurement Manifest, which is endorsed by the Caliptra FW key pair. Caliptra provides approval or disapproval of the measurement of any FW back to the SoC RoT. This effectively provides a multi-factor authentication of SoC FW. |
There was a problem hiding this comment.
Caliptra FW key pair
Caliptra FW signing key pair I presume, to disambiguate from DICE.
Is this the vendor signing key or owner signing key?
|
|
||
| ### Caliptra-Endorsed Local Verifier | ||
|
|
||
| A local verifier provides an authentication of SoC FW by matching SoC FW measurements with measurements from the Caliptra measurement manifest. In this case, the SoC RoT still has its own FW public-key chain that is verified by the SoC RoT, but in addition the SoC RoT introduces the Caliptra Measurement Manifest, which is endorsed by the Caliptra FW key pair. Caliptra provides approval or disapproval of the measurement of any FW back to the SoC RoT. This effectively provides a multi-factor authentication of SoC FW. |
There was a problem hiding this comment.
multi-factor authentication
Bike-shedding here but I feel like "joint authentication" might be a better term, to avoid connotations of human-driven multi-factor authentication flows.
|
|
||
| ### Caliptra-Endorsed Local Verifier | ||
|
|
||
| A local verifier provides an authentication of SoC FW by matching SoC FW measurements with measurements from the Caliptra measurement manifest. In this case, the SoC RoT still has its own FW public-key chain that is verified by the SoC RoT, but in addition the SoC RoT introduces the Caliptra Measurement Manifest, which is endorsed by the Caliptra FW key pair. Caliptra provides approval or disapproval of the measurement of any FW back to the SoC RoT. This effectively provides a multi-factor authentication of SoC FW. |
There was a problem hiding this comment.
A local verifier provides an authentication of SoC FW by matching SoC FW measurements with measurements from the Caliptra measurement manifest.
So what is a "local verifier"? Is it a piece of logic living inside Caliptra? Is it a role that is shared with the SoC?
|
|
||
| A local verifier provides an authentication of SoC FW by matching SoC FW measurements with measurements from the Caliptra measurement manifest. In this case, the SoC RoT still has its own FW public-key chain that is verified by the SoC RoT, but in addition the SoC RoT introduces the Caliptra Measurement Manifest, which is endorsed by the Caliptra FW key pair. Caliptra provides approval or disapproval of the measurement of any FW back to the SoC RoT. This effectively provides a multi-factor authentication of SoC FW. | ||
|
|
||
| The Caliptra-Endorsed Local Verifier could be required by the owner only or both the vendor and the owner. |
There was a problem hiding this comment.
What does it mean for a local verifier to be "required" by a vendor or owner? Is the functionality enabled or disabled based on whether it is required?
|
|
||
| The Caliptra-Endorsed Local Verifier could be required by the owner only or both the vendor and the owner. | ||
|
|
||
| The main difference between Caliptra-Endorsed Aggregated Measured Boot and Caliptra-Endorsed Local Verifier is if the SoC RoT is relying on the Measurement Manifest for SoC Secure Boot services as opposed as using it as an additional verification. |
There was a problem hiding this comment.
Unresolving as I have the same question.
- The "Caliptra-Endorsed Aggregated Measured Boot" section states that one signed manifest includes measurements for a collection of different components.
- The "Caliptra-Endorsed Local Verifier" section first paragraph states that measurements of components are compared to a manifest.
Those sound like the same thing.
The main difference between Caliptra-Endorsed Aggregated Measured Boot and Caliptra-Endorsed Local Verifier is if the SoC RoT is relying on the Measurement Manifest for SoC Secure Boot services as opposed as using it as an additional verification.
So in both models the SoC is checking in with Caliptra whenever it boots code. In the second model the SoC is doing its own verification on top of that. If that's the case, it seems like we could just describe a single model of manifest flows. We can just say that this is a feature that SoCs can rely on, and they can optionally also do their own verification on top of that.
This adds sections describing the Manifest-Based Image Authorization system.
I cleaned up a little bit of the manifest-based image auth commands and added some overview sections for what is new in the 1.1 and 1.2 runtime firmware to help keep things organized.
I've addressed most of the comments from #1745 that I could. I don't necessarily know all of the details, and not everything has been merged yet (e.g., #1705), but I've tried to sync everything up with the latest version of the docs and code.