Generating a challenge should verify TPMT_PUBLIC matches the digest
ericchiang opened this issue · 3 comments
Currently the server generates a challenge but doesn't actually verify that ActivationParameters.Public matches what's passed in ActivationParameters.AK.CreateAttestation.
go-attestation/attest/activation.go
Line 236 in 355135f
I can take this tomorrow.
From memory I think we check this (and everything else) in checkTPM20AKParameters() to keep the logic in one place + avoid having to consider timing invariants. Specifically:
- We check the digest of key creation data matches that in the attested structure
- We check the key referenced in the attested structure (the
AttestedCreationInfo.Name) matches the computed name of the attestation key being used (AK.Public) - We check the signature over the attestation data by verifying the signature using the key parameters of the AK.
At this stage, we should have established the authenticity of the triplet of creation data, AK, and attestation. Coupled with the check that the key in question is restricted to attestation, and the knowledge that the client can only return the encrypted challenge if they activate against the EK + AK they presented to Generate(), we transitively establish:
- The creation data, creation attestation, and AK refer to the same key, and the properties indicated are authentic
- The AK Name (aka its digest) in
Generate()matches the above, and is co-resident on the TPM with the EK - Given a key with restricted properties, and the TPM-generated magic header, the attested blobs was created by TPM
Reading this again, is this more around additionally verifying the blobs before we generate the challenge (as a nice correctness check), rather than something missing in the verification process?
Ah you're right. It's already done through checkAKParameters
go-attestation/attest/activation.go
Line 154 in 355135f
Nevermind, false alarm. Thanks!