Chris Coulson
5a80137aa4
This updates systemd-tpm2-setup to create and persist an endorsement key if there isn't one already. For each supported EK template profile, it will read the EK certificate from its NV index if there is one. When there is an EK certificate present, a primary key is created using the corresponding template. If the resulting EKpub matches the public key in the certificate, the created EK is persisted and the process is complete. The low-range templates and the high-range RSA 2048/3072 and ECC NIST P256/P384 storage templates are supported, as detailed in section 5.3 of the "TCG EK Credential Profile For TPM Family 2.0" spec v2.7. High-range templates are preferred because these permit EK usage without requiring knowledge of the authorization value for the endorsement hierarchy, meaning that, like with the SRK, it is possible to restrict the usage of the endorsement hierarchy whilst still permitting use of the persistent EK. The EK is always persisted at handle 0x81010001. This handle is reserved in Table 2 of the "TCG TPM v2.0 Provisioning Guidance" spec v1.0r1.0, although this is only a recommendation. This handle is within the block of handles reserved for endorsement primary keys in the "Registry of Reserved TPM 2.0 Handles and Localities" spec v1.2r1.00. Section 2.3.2 of this specification also makes a suggestion that there should be a relationship between the EK certificate NV index and a corresponding persistent EK handle by using handles at the same offsets within their respective ranges. However, this contradicts the provisioning guidance spec which reserves 0x81010001 when there isn't a certificate at 0x01c00001. For simplicity, I've chosen to use a single handle for the EK regardless of which profile it is created with. The "TCG EK Credential Profile For TPM Family 2.0" spec also provides a way for endorsement keys to be certified with non-standard templates by storing the template in a NV index. This is also supported. The EK creation is not executed with tpm2-setup --early, as there's no need for it to be created so early, unlike with the SRK. I also haven't stored EKpub in /var/lib/systemd like with the SRKpub, as I'm not sure there will be a use case for this yet. A follow-up PR may be needed to add some internal helpers to make use of the persisted EK, as use of low-range EKs requires a policy session. High-range EKs can be used with a HMAC session because they have the userWithAuth attribute set and we are creating them with an empty authorization value. https://trustedcomputinggroup.org/resource/http-trustedcomputinggroup-org-wp-content-uploads-tcg-ek-credential-profile/ https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/ https://trustedcomputinggroup.org/resource/registry/
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release