Passwords (Plaintext and HMAC) of the Object
Passwords are the most basic form of authentication used today, but they're far from the most secure. Nonetheless, because they're in use in so many devices, it was important that the TPM support them. (The TPM 1.2 did not support passwords in the clear—only proof of knowledge of the password using an HMAC. The TPM 2.0 supports both.) It's assumed that when a password is used, the device provides for a trusted path between the password entry and the TPM. If this doesn't exist, facilities are present in the TPM 2.0 architecture to allow for using a salted HMAC session to prove knowledge of a password without sending it in the clear, as seen in Chapter 13. When an object is loaded into a TPM, the TPM knows its associated password. Therefore, the policy doesn't need to include the password. Thus the same policy can be used with different entities that have different passwords.
Creating a simple assertion policy can be reduced to four steps:
1. Set the policy buffer to all zeroes, with the length equal to the size of the hash algorithm.
Figure 14-1. Initializing the Policy
2. Concatenate TPM_CC_PolicyAuthValue to this buffer.
Figure 14-2. Concatenation of the buffer with the policy data per the Specification
3. Substitute the value of TPM_CC_PolicyAuthValue from its value in part 2 of the specification.
Figure 14-3. Substituting the value of TPM_CC_PolicyAuthValue
4. Calculate the hash of this concatenation, and put the result in the buffer. This end result is the policy for a simple assertion.
Figure 14-4. Hashing the result provides a new value for the buffer
When this policy command is executed, the policy buffer of the session is set to this final value. In addition, a flag is set in the TPM's session specifying that when a command with an object in it that requires authorization is used, a password session must be provided with that command and the password provided must match that of the object.
Similarly, when a policy is created to use the HMAC assertion (TPM2_PolicyAuthValue), two things happen
1. The policy is extended with the value TPM_CC_PolicyAuthValue.
2. A flag is set in the TPM's session indicating that when objects requiring authorization are used, a separate HMAC session is required. The TPM checks the password HMAC against the object's authorization data and allows access if they match (see Chapter 13.)
If you're using a trial session to create the policy, you accomplish this by executing the command TPM2_PolicyAuthValue and passing it the handle of the trial session.
This inherently means that when you're using passwords, either in plaintext or as an HMAC, either the plaintext password or the HMAC must be included to authorize a command with a policy session. The fact that TPM_CC_PolicyAuthValue appears twice in the previous explanation isn't a typo: the repetition means the choice of password or HMAC isn't decided when the policy is created, but rather when the non-policy command is executed. It's up to the user of the entity, not the creator of the entity, to decide how they will prove their knowledge of the password to the TPM.
Passwords aren't the most secure means of authentication. A much more secure approach is to use a digital signature, often implemented with a smart card such as a United States Department of Defense (DoD) Common Access Card (CAC card) or United States Federal Personal Identity Verification (PIV) card.