-
Bug
-
Resolution: Unresolved
-
Major
-
rhel-9.6, rhel-10.0
-
Yes
-
Moderate
-
ZStream
-
1
-
rhel-security-special-projects
-
1
-
False
-
False
-
-
No
-
SECENGSP Cycle 24
-
Regression Exception
-
None
-
None
-
Release Note Not Required
-
Unspecified
-
Unspecified
-
Unspecified
-
-
All
-
None
What were you trying to do that didn't work?
Previous versions of Keylime had a workaround to support malformed EK certificates by using an alternative EK verification script.
Now the registrar will re-encode the malformed EK certificate using pyasn1 library before adding it to the database, which effectively corrupts the certificate and makes the signature invalid. Then, when the tenant recovers the EK certificate to verify from the registrar database, the signature is already invalid, making the workaround to use a custom EK certificate verification script (set through the `ek_check_script` option in the tenant configuration) ineffective.
What is the impact of this issue to you?
It is no longer possible to use a custom script to verify the EK certificate, meaning that any TPM with malformed certificates cannot be used in Keylime. Many Nuvoton TPMs contain malformed EK certificates that cannot be updated.
Please provide the package NVR for which the bug is seen:
keylime-7.12.1-6.el10
How reproducible is this bug?:
Always
Steps to reproduce
- Register a Keylime Agent running on a machine with a TPM that contains a malformed certificate
- Try to enroll the registered Agent to the Verifier and confirm that it fails to verify the EK certificate due to malformed certificate
- Set a custom EK certificate verification script using the `ek_check_script` option in the tenant configuration to verify the EK certificate using OpenSSL (which tolerates malformed certificates)
- Try to enroll the registered Agent to the Verifier
Expected results
The tenant uses the custom script to verify the certificate and it is successful
Actual results
The tenant uses the custom script to verify the certificate, but the verification fails because the certificate was corrupted by the registrar during registration (by re-encoding using pyasn1).