main-with-ancient-kernel
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Yu Watanabe
|
15bd45d113 | man: fix typos and grammar in various man pages | ||
 Chris Coulson
|
768b6f21ec |
report: Add a TPM2 signing backend
This adds an initial TPM2 implementation of the io.systemd.Report.Signer interface, which returns a set of signed TPM attestations that also includes the supplied report digest. The returned report consists of multiple components: - A signed PCR quote generated with TPM2_Quote. - Signed NvPCR attestations generated with TPM2_NV_Certify. - A signed audit session attestation generated with TPM2_GetSessionAuditDigest. Each signed report component includes the JSON encoded TPMS_ATTEST attestation structure and corresponding signature, in both PEM encoded form and as a JSON encoded TPMT_SIGNATURE structure. NvPCR report components also include the readable name of the NvPCR, the NV index public area as the JSON encoded TPMS_NV_PUBLIC structure, and some additional authenticated data that is digested and supplied as the qualifying data to the TPM2_NV_Certify command. This authenticated data includes the NvPCR name and priority. The report digest that is supplied via varlink is supplied as the qualifying data to the audit session attestation. The returned report also includes the event log which is retrieved from pcrlock's varlink interface, and the public area of the signing key in both PEM encoded form and as a JSON encoded TPMT_PUBLIC structure. The audit session attestation is always the last component. The preceding components are all executed with the audit session, and the signer requires the audit session to remain exclusive whilst generating the report. What this does is provide evidence to a verifier that the overall report is a single, consistent snapshot of the system (ie, no other TPM commands executed whilst generating the report) because the audit session attestation contains a field that indicates that the session was exclusive at the time it was attested. The set of attested PCRs and NvPCRs are currently hardcoded. It includes all firmware PCRs with the exception of PCR6, and all other PCRs with the exception of the IMA one (which isn't useful on its own without the IMA log). All defined NvPCRs are included. A verifier can verify the signed attestation components individually by verifying their signatures against the supplied attestation data, using the supplied public key. For the PCR report component, a verifier can replay the measurements in the log in order to reconstruct the PCR values, and then use this and the PCR selection from the attestation in order to calculate the PCR digest, and then check that this matches the one in the attestation. For the NvPCR report components, a verifier checks that the NV index name in the attestation matches one that is anchored in PCR9 to be sure that the attestation is for a valid NvPCR. A verifier can then replay the measurements in the log to ensure that the resulting NvPCR value matches the one supplied in the attestation. The authenticated data is a JSON blob containing the NvPCR name and priority. A verifier can digest this and ensure it matches the qualifying data in the attestation. The audit session attestation includes the audit session digest and whether the audit session was still exclusive when the attestation was generated. A verifier should confirm exclusivity. The digest includes a record of all TPM commands executed with the audit session, as each command results in it being extended with the command parameter hash and the result parameter hash. A verifier should replay the preceding report components to compute an expected audit digest and make sure that this digest matches the one in the attestation in order to be sure that the overall report represents a single, consistent snapshot. The other report components provide sufficient information for a verifier to reconstruct the cpHash and rpHash. When reconstructing the cpHash for the PCR and NvPCR components, the signing scheme is the NULL scheme (they use the attestation key's signing scheme). The required signing key public area is supplied in the report. The supplied qualifying data is in the extra data field of the attestation. The PCR selection is also required to reconstruct the cpHash for the PCR component. The PCR selection is available in the attestation. The name of the NV index is also required to reconstruct the cpHash for the NvPCR components. The name is available in the attestation. The rpHash for each component can be reconstructed from the supplied attestation blob and signature. In the future, we might want to add more report component types. Eg, we could add report components for ordinary NV indexes. Using the audit session means that we could also add additional components that the TPM can't attest directly, such as the values of interesting TPM properties (as the TPM2_GetCapability calls will appear in the audit session digest). The attestation signing key is stored as a JSON file in the report signer's state directory. Different types of keys are supported: - Ordinary keys that are protected by an existing persistent TPM key such as the SRK or EK. - Persistent TPM keys. - Primary keys, which are recreated using a template on use. When an ordinary or primary key is used, the report signer saves the object context in its runtime directory. This context is used on future invocations. This has the benefit that where a primary key is used, it doesn't need to be recreated on each use. When an ordinary key is used, we don't need to run TPM2_Load, which requires authorization with the parent key, on each This authorization currently requires a policy session for low-range EKs. Regardless of the key type, it must be a restricted signing key. If no key exists, an ordinary key is generated automatically. The attestation key can also have an associated credential which is attached to the signed report. The credential can be issued by a CA or some other party during onboarding, and is presented to a verifier as proof that the attestation key is authentic. It is considered an opaque blob in order to not require it to be a specific format, such as a X.509 certificate. I've called this a "voucher" though because "cred" or "credential" has other meanings in systemd. As a follow-up to this, I plan to add a varlink interface for creating attestation keys that can be used for report signing. |