Combined Authorization Lifecycle
The typical steps in an authorization lifecycle are the following:
1. For HMAC or policy sessions, an authValue or authPolicy
must be determined before creating the entity:
a. If actions on the entity will be authorized using a policy session, precalculate the authPolicy policy hash.
b. If actions on the entity will be authorized using a password or HMAC session, determine what the shared secret will be.
2. Create the entity to be accessed using an authorization value (authValue) and/or policy hash (authPolicy), or change
the authValue value for an existing entity (changing the authPolicy for an entity is done by a different means and is described in the next chapter):
a. The entity's authValue will be used for either password authorizations or HMAC authorizations. For password authorizations, the authValue will be used as a clear-text password. For HMAC authorizations, the authValue will be used to generate session HMACs.
b. The entity's authPolicy is used to determine if the proper policy assertions have passed before the command to
be authorized. This policy hash must be precalculated before creating the entity; hence step 1a.
3. Calculate the HMAC. For policy sessions that don't use an HMAC, this step can be skipped.
4. In the case of an HMAC or policy authorization, start the HMAC or policy session.
5. Do an authorized action using the authorization. The authorization passes if:
a. The password sent during the command matches the entity's authValue.
b. The HMAC sent during the command matches the HMAC calculated by the TPM. Both of these HMACs are derived, in part, from the authValue of the entity.
c. The policyDigest of the policy session at Authorization Time matches the authPolicy of the entity. This policy hash derives from a variety of factors determined by the policy command(s) used to create the policyDigest. Also, any deferred assertions must pass for the authorization to be successful.
6. In the case of an HMAC session, calculate the expected response HMAC, and verify it against the one returned by the TPM.
These steps are represented in relative time order, but many other actions could occur between them. Also, a single policyDigest can be used to authorize multiple actions to multiple entities. Similarly, a single HMAC session can be used to authorize multiple actions to multiple entities. The exact mechanics of these steps vary with the authorization type, and these differences were described previously, but each of these steps must be performed for all authorizations with the following exceptions:
• Steps 3–4 aren't required for password authorizations.
• Step 6 isn't required for password or policy authorizations.
For more code examples of policy sessions, see the TestPolicy function in the TSS SAPI test code.
This concludes the discussion of authorizations and sessions. Congratulations on making it this far! If you understand this chapter, you're well on your way to becoming a TPM 2.0 master.
This chapter described the general concepts of authorizations and sessions and tried to clarify their differences. You looked at the command and response authorization areas, and lifecycles for password, HMAC, and policy authorizations. Then you saw an overall authorization lifecycle.
This may have felt like drinking from a fire hose, and that's because it was! This is one of the most difficult areas of the TPM to understand; good comprehension of this material will aid you immeasurably in understanding and using TPM 2.0 devices. The next chapter describes the most powerful of authorizations—policy authorizations—in detail, with a description of each of the policy authorization commands and use cases for them.