Are policy Digests Dangerous -- why does TPM not encrypt them?

[stickybits123]

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?

[williamcroberts]

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?

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.

why does the TPM not encrypt these hashes like it does with primary objects?

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.

if these hashes are only relevant to the TPM, why not just encrypt it?

With what key? What would the initial key be?

I think most of these questions are around missing some key points on policies:

1. How to create the policy hash should never be assumed secret
2. How to satisfy the policy should be considered the safe guard and policies should be built to get the properties one wants for protecting the resource its protecting.
3. All the hash algorithms can be adjusted with parameters. If you don't want sha256, specify sha384, etc. The commands all have options for tweaking these.

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.