-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Are policy Digests Dangerous -- why does TPM not encrypt them? #3179
Comments
Resultant policy hashes are public information, ie they're part of the public portion of the object on the TPM. Knowing the policy hash doesn't imply knowledge of satisfying the policy nor imply knowledge of how the policy was created (the series of commands needed to create the policy). It should always be assumed an attacker knows how to call the correct policy commands. For instance, take into consideration a Disk Encryption Key protected by PolicyPCR. An attacker could start an auth session, call policy PCR and unseal the key IFF the attack doesn't affect the measured PCR state, if it does the unseal would fail. No consider that attack, but it's PolicyPCR and PolicySecret OWNER would require the attacker to satisfy both the PCR state and the owner password to unseal the key.
Huh? A primary object is really no different than any other object, it can have a policy hash. The only difference is a primary object is derived from the hierarchy seed and the input public template in which it was created.
With what key? What would the initial key be? I think most of these questions are around missing some key points on policies:
tpm2 startauthsession -g sha384 -S session.ctx
tpm2 policysecret -Ssession.ctx -c owner -L policy.dat
tpm2 createprimary -gsha384 -L policy.dat -c primary.ctx Note that when creating objects the objects name-alg must be the same as the policy alg. |
Been doing work with TPM policies lately and I have quickly realized that for my TPM they are saved as SHA256 hashes in the clear. sha256 is no longer considered a secure algorithm, as Suite B is deprecated and in the government sector, we must use the CNSA suite. I have been reading up on this, but can attackers use these hashes to break into the TPM? as in, something like a brute force where they run through policies until they create a collision with a specific hash?
why does the TPM not encrypt these hashes like it does with primary objects? if these hashes are only relevant to the TPM, why not just encrypt it?
The text was updated successfully, but these errors were encountered: