The Name of a TPM entity uniquely (and cryptographically) defines the entity and is used for authorization. For an NV index, it's a hash of the public area, which includes the index (the handle), the attributes (including whether it has been written), the policy, and the size.
TPM2_PolicyNV permits an NV index value to be used in a policy. The policy can be based on a range of logical and arithmetic operations on the index. If the policy were based merely on the NV index value, it would offer little security: an attacker could delete the index and replace it with one with different access controls. For that reason, TPM2_PolicyNV uses the Name.
An example might help. Suppose you create an NV bit-field index that you intend to use for key revocation. The policy for the key includes a TPM2_PolicyNV term that can only be satisfied if the NV bit 0 is clear. The policy for the NV index says only the owner of a private key can write the index (TPM2_PolicySigned). To revoke the key, the owner signs a nonce to satisfy the NV policy and then sets bit 0 (TPM2_NV_SetBits).
Now suppose an attacker tries to remove the key revocation. They can't clear bit 0, because a bit-field index bit can only be set, never cleared. So, the attacker tries something more promising: they delete the index and re-create it with exactly the same Name. This fails because TPM2_PolicySigned fails on an index that has not yet been written. The attacker can't write the index because it can't satisfy the NV index policy TPM2_PolicySigned term.
The attacker makes one final attempt. They delete the index and re-create it with a policy that they can satisfy. They then write the index so that bit 0 is clear and use that index to authorize the key's policy using TPM2_PolicyNV. Because bit 0 is clear, it appears that the policy should succeed. However, the attacker had to change the policy, which causes the Name to change. When the new Name is used in TPM2_PolicyNV, the key's policy evaluation fails.
In summary, the “delete and re-create an index” attack fails because of two TPM features:
• An NV index can't be used in a policy until it has been written.
• The NV index in a policy uses the entire Name (public area), not just the index handle.
the user desires to create an index that they can write exactly once and that can then be read by anyone. an example is provisioning the tpM with a certificate.
the index has two OR terms. the first policy term is satisfied when the index has not been written and the owner supplies the correct password; it permits only the NV write command. the second term is satisfied once the index has been written; it permits only the NV read command.
Another subtle point is that the Name changes when the index is written, because the index public area includes the written attribute.
a policy secret permits authorization for a set of objects to be linked to a single secret. For example, a set of keys can have identical policies that authorize the key if an NV index-authorization password is known. the policy would use the NV index Name after it has been written.
■ Note TPM2_PolicySecret ties authorization to the NV password. TPM2_PolicyNV ties autho-
rization to the NV data.
If the Name didn't change when the index was written, an attacker could delete the index and create a new one with the same Name but their own secret and thus gain access to keys tied to the secret. The attack doesn't work, because the attacker's index has not been written and thus has a different Name than the one required in the key's policy.
It's assumed here that the NV index policy (part of the Name) prevents the attacker from writing the index. For example, the NV write policy might require authentication with a public key (TPM2_PolicySigned).
■ Note Observe that the data value written to NV doesn't matter and serves only to prove that the index creator can write the index. the key policy is tied to the NV password, not the NV data.
The previous use case demonstrates an interesting property. You can create an NV index with a Name that no one else can reproduce. If the Name includes having written set, and the policy is such that only you can write the index, then only you can create that Name. This ensures that a policy points to your NV index, not one that an attacker created.
Further, the same NV index with the same Name can be created on multiple TPMs.
In the previous use case, the authorization for a set of keys was tied to an NV index password. a user can duplicate a set of keys to another tpM. then the user can create an NV index with the same Name on that tpM so that the key's policy can be satisfied on the new tpM.