- Release Signoff Checklist
- Summary
- Motivation
- Proposal
- Design Details
- Drawbacks
- Alternatives
- Infrastructure Needed (optional)
- Enhancement issue in release milestone, which links to pull request in [keylime/enhancements]
- Core members have approved the issue with the label
implementable - Design details are appropriately documented
- Test plan is in place
- User-facing documentation has been created in [keylime/keylime-docs]
Issues:
Add support for EK certificates that are signed by intermediate certificates.
The current setup can only verify EK certificates that are signed by a certificate that
was added to the tpm_cert_store. The current setup does not support the verification of
a chain.
New intel chips (starting 11th core gen) are certified using the intel ODCA (On Die Certificate Authority). The certificate chain is as follows:
| tpm_cert_store | TPM | TPM | TPM |
|---|---|---|---|
| Root CA | Intermediate | Intermediate | EK |
| On Die CSME P_MCC 00001881 Issuing CA | CSME MCC ROM CA | CSME MCC SVN01 Kernel CA | CSME MCC PTT 01SVN |
This is also defined by the TCG EK specification (Chapter 2.2.1.5.2)
The current setup only allows to verify the EK cert against the tpm_cert_store.
As the EK certificate is signed by intermediate certificates, which are unique to device,
it is not possible to verify the EK certificate against the tpm_cert_store. The EK
must be verified against the EK Certificate Chain, till the top level certificate
from the chain can be verified against the tpm_cert_store.
Add support for intel firmware TPMs and possibly other TPMs that provide an EK certificate chain, or setups that also depend on a certificate chain that must work offline or without any other access to the chain.
- Verify EK certificates that are not signed directly by a root ca, but require the verification of a chain.
- Implementing a generic interface to provide the content of any NV-Index.
- keylime_agent: update
ekcertfield to use PEM format, so multiple certificates can be stored in the field and a marker exists that shows the start and end of each certificate. - keylime registrar, store
ekcertin database, as it is already done. - keylime tenant, verify chain in
ekcert. Use "top" certificate from chain to verifiy againsttpm_cert_store. In case of a single certificate the check of the chain is immediately finished as there is no certificate "above" and theekcertis the "top" certificate that will be verified against thetpm_cert_store.
Users will be able to use keylime with intel firmware TPMs (11th gen core and onwards), or any other TPM that stores an EK certificate that is signed by a chain that is stored in the TPM.
- Update existing database values for
ekcertto PEM format.
- If the feature can't be used, due to missing certificates in the TPM, the memory footprint will stay around the same.
First some words from TCG EK documentations:
TPM NV MAY contain all certificates of the EK Certificate Chain except the Root CA certificate. The
EK Certificate Chain MUST be stored as X.509 DER encoded certificates. If the chain consists of
more than one certificate, or if multiple chains exist, they MUST be stored in NV as a concatenated
sequence. The TPM manufacturer MAY provision certificate chains using the following list of indices:
0x01c00100 - 0x01c001ff
Revision 2 January 26, 2022 Published Page 15 of 60
The NV indices MUST be populated starting with index 0x01c00100 through index 0x01c001ff. There
is no requirement to store the certificates in any particular order whatsoever. If a concatenated
certificate chain does not fit in a single index, the chain MUST overflow to the next numerically larger
index in the list of NV Indices. If the storage space in a single index is insufficient to store the entire
certificate, the certificate MAY overflow into the next numerically larger index in the list of NV Indices.The feature requires changes in the rust-keylime agent and in the keylime servers registrar and tenant. The certificate chain must and can be only provided by the keylime-agent.
The keylime-agent must do the following:
- get all available NV-Index-Handles in the defined range (
0X01C00100 - 0X01C001FF) - read the chain from the NV-Index-Handles
- Theoretically the certificates can be in any order. This would require an option to make a sorting possible in the agent. As it does not make really sense to store the chain in an unsorted order i would postpone any implementation till this case really exists.
- Only a subset of the NV-Index-Handles may be required. This would require an option to filter/set the required handles. I would also wait for implementation till a real case exists for that.
- as the certificate chain is stored in DER format, first the certificates must be separated
- transform der DER certificates into PEM format.
- send the chain to the keylime server
The certificate chain should be transformed and sorted by the keylime-agent to keep the work away from the server and provide a generic server implementation that does not need to behave a certain way (sort/filter the chain) depending on the client.
The keylime registrar only needs to store the certificate chain in the database.
The keylime tenant must detect the presence of an EK Certificate Chain and verify the
EK Cert against the chain, and finally the top level certificate against the tpm_cert_store.
The flow can be kept mostly as it is in check_ek. In case of multiple certs in ekcert , the ek must be verified against the provided chain and in case of a success the ek will be replaced by the top level certificate from the chain. Afterwards the flow can be kept as it was.
See provided implementation: