Impact
A security issue was found in the Keylime agent and registrar code that invalidates the cryptographic chain of trust from the Endorsement Key certificate to agent attestations.
It was discovered that the “ek_tpm” used by the Credential Protection protocol to encrypt a challenge, was never verified as containing the same public key present in “ek” or “ekcert”. This means that it would be possible for an attacker to generate a new key in system memory (unprotected), and send that as “ek_tpm” together with a valid (but unrelated) “ek” and “ekcert” from any random TPM, and the registrar would just assume that the verified key is correct.
It was also discovered that there is no check carried out between the "pub_aik" and aik_name. This would mean that an attacker would be able to generate a random key in system memory, and send that to the registrar as the “pub_aik”, but providing the “aik_name” of an object that is on an actual, trusted TPM. Additionally there were no checks on the object attributes of the Attestation Key, which means that even if an attacker sends the name of a key that is on a valid TPM, it might be a key where the key material was provided from outside the TPM.
Patches
Users should upgrade to release 6.0.0
Credit
Many thanks to Patrick Uiterwijk / @puiterwijk for reporting the issue and providing a fix.
For more information
If you have any questions or comments about this advisory:
Impact
A security issue was found in the Keylime agent and registrar code that invalidates the cryptographic chain of trust from the Endorsement Key certificate to agent attestations.
It was discovered that the “ek_tpm” used by the Credential Protection protocol to encrypt a challenge, was never verified as containing the same public key present in “ek” or “ekcert”. This means that it would be possible for an attacker to generate a new key in system memory (unprotected), and send that as “ek_tpm” together with a valid (but unrelated) “ek” and “ekcert” from any random TPM, and the registrar would just assume that the verified key is correct.
It was also discovered that there is no check carried out between the "pub_aik" and aik_name. This would mean that an attacker would be able to generate a random key in system memory, and send that to the registrar as the “pub_aik”, but providing the “aik_name” of an object that is on an actual, trusted TPM. Additionally there were no checks on the object attributes of the Attestation Key, which means that even if an attacker sends the name of a key that is on a valid TPM, it might be a key where the key material was provided from outside the TPM.
Patches
Users should upgrade to release 6.0.0
Credit
Many thanks to Patrick Uiterwijk / @puiterwijk for reporting the issue and providing a fix.
For more information
If you have any questions or comments about this advisory: