Skip to main content
gilb3rt's user avatar
gilb3rt's user avatar
gilb3rt's user avatar
gilb3rt
  • Member for 10 months
  • Last seen more than a month ago
comment
How to bind TPM2.0 AK to the "AK name" used in tpm2_makecredential, and how is trust established in AIK?
@saurabh, regarding trust in the AK you can reject the AK for whatever reason you want. I gave a procedure to have a certain level of trust in the AK which is what the questioner wanted. If you want more trust in the AK, then you have to state your specific use case and what type of trust you're trying to achieve. If the questioner does that, we can tweak the answer. However, I really think that would be worthy of a separate question rather than muddying this one.
comment
How to bind TPM2.0 AK to the "AK name" used in tpm2_makecredential, and how is trust established in AIK?
@saurabh, that statement is in the context of the spec I cited, "TPM 2.0 Keys for Device Identity and Attestation". If you perform the procedure I cite, then it gives you the guarantees I quote. The CA has to validate the EK cert chain and then do a Proof-of-Possession challenge-response to prove the TPM has the EK private portion. That's how the EK is validated within that context. So it's not just the ActivateCredential call, and neither can you blindly call ActivateCredential. However, if you do the procedure in the spec cited, it does let you validate the EK via the two parts.
comment
How to bind TPM2.0 AK to the "AK name" used in tpm2_makecredential, and how is trust established in AIK?
@saurabh, I never claimed ActivateCredential validated the EK directly. Please quote the specific wording that's unclear that makes you think I did so I can clarify my answer.
answered
Loading…
awarded
comment
PCR 7 in TPM 2.0 has always the same value
The main thing to remember is that every boot, TPM PCRs get reset to default and then built up again by BIOS and other software extending events into them using the formula you mention. So, all else being equal, one boot doesn't influence another (thought PCR[4] does measure boot attempts).
comment
PCR 7 in TPM 2.0 has always the same value
That's how it's supposed to work. If you change nothing else that's measured into PCR[7] except whether Secure Boot is enabled or disabled, then you'll have two PCR[7] values, one corresponding to enabled (S1), one to disabled (S2). You'll only get a new state if you change something else. What security property or behavior are you trying to obtain by knowing whether UEFI Secure Boot was on, turned off, and then turned back on? If you configured UEFI Secure Boot properly, then you ideally wouldn't care whether someone had turned it off. The disk only auto-unlocks if it's on.
Loading…
Loading…
awarded
awarded
Loading…