Passwords of a Different Object
A new (and very useful) assertion policy in TPM 2.0 is an assertion that the user knows the password of an entity different from the one being used. Although this might seem odd at first, it's particularly useful because of the difference in the behavior of NVRAM entities versus key objects. When the password of a key object is changed with TPM2_ChangeAuth, what is really happening is that a new copy of the key is being created that has a new password. There is no guarantee that the old copy is discarded. This is because key objects normally reside in files outside the TPM, and the TPM therefore can't guarantee that the old copy of the key file has been erased. However, NV entities reside entirely in the TPM: if their password is changed, it really is changed. The old copy can no longer be used.
This means if a key is created and a policy is created for it that requires the user to prove knowledge of an NV entity's password, it's possible to change the password necessary to use the key without worrying that the old password can still be used to authorize the key. In this case, changing the password of the NV entity effectively changes the password of the key. TPM 2.0 allows you to make authorization of a key dependent on knowing an NVRAM entity's password.
This further provides opportunities to manage the passwords of a large number of entities. Suppose you create a policy that points to a particular NV index's password, and then you associate that policy with a large number of keys. You can effectively change the password of all those keys by changing the password of the one NV index.
The TPM2_PolicySecret command requires you to pass in the name of the object whose password is required to satisfy the policy. It's perhaps not obvious, but when creating the policy for an object, you can't pass in the name of the object being created. This is because the name of the object depends on the policy, and if the policy depends on the name of the object, a vicious circle is created. This explains why the TPM2_PolicyAuthValue command is also needed. It provides a way of pointing to the authorization of the object being authorized.
To calculate the policy in a trial session, you execute the command TPM2_PolicySecret and pass it the handle of the trial session, as well as the handle of the object whose authorization will be used. Doing so extends the session policy buffer with TPM_CC_PolicySecret || authObject→Name || policyRef. The variable of note that is passed to the command is, of course, a handle for the object whose authorization will be used. As explained regarding names, although the handle of that object is passed to the TPM when executing TPM_CC_PolicySecret, the TPM internally uses the Name of the object in extending the session policy buffer. This prevents a change in the handle from causing a security exposure.
Technically, you need to include an authorization session for the handle of the object being authorized when executing this command. Although the specification indicates that it doesn't need to be satisfied in a trial session, most implementations require it. Therefore you must also include a correct password or HMAC session when executing this command. If you instead calculate the policy without using the TPM, this requirement isn't necessary.