Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

HMAC and Policy Sessions: Differences

HMAC and policy sessions differ primarily in how actions are authorized. Commands sent using HMAC sessions are successful only if the HMAC sent with the command is correct. In order to generate the correct HMAC, knowledge of a secret (authValue) that is shared between the caller and TPM is required. In other words, knowledge of the session key and authValue enable the calculation of the correct HMAC, effectively granting authorization to perform an action on the entity. An agent that doesn't know either the session key or the authValue can't calculate the correct HMAC, which causes the command to fail.

Policy sessions authorize actions based on the correct sequence of policy commands and, in many cases, conditions required by those commands. This is a very simple description of this rich and complicated type of authorization. The details are described in Chapter 14, but suffice it to say that policy sessions authorize actions using the following:

• A sequence of policy commands before the command whose action is being authorized. The presence of this sequence is proven by checking the policyDigest. Each policy command hash-extends policy command-specific data into the session's policyDigest. In the simplest case, a comparison between the session's policyDigest and that of the entity being accessed will determine whether the proper policy commands were performed beforehand.

• A set of conditions that must be met before and/or during the execution of the command whose action is being authorized.

If these conditions aren't met, the policy commands fail or the command being authorized fails. This is described in detail later.

Interestingly enough, policy sessions can still have an HMAC in their authorization areas, even though the most common use of policy sessions doesn't, according to Part 1 of the TPM 2.0 specification. This most common use assumes that the session is unbound and unsalted. But when an HMAC is used in the authorization area (whether because the session is bound and/or salted or the TPM2_PolicyAuthValue command is used), contrary to HMAC sessions, the HMAC is always calculated as if the session isn't bound to any entity. [1] In policy sessions, the bind entity's authValue is only used for session key creation and never for HMAC calculation. Applications using the TPM need to account for this during HMAC calculation.

To summarize, HMAC authorizations are more secure than password authorizations, and policy authorizations are the most complex and rich authorizations. HMAC authorizations use a properly calculated HMAC as the means to prove knowledge of the authorization secret(s). Policy authorizations require a set of policy commands and a specific set of conditions required by those policy commands in order to authorize an action. In both HMAC and policy authorizations, HMACs can be used to guarantee command and response integrity.

Now let's look at HMAC authorization in detail.

  • [1] This is an optimization: the session context space normally used for the bind value is used for policy-specific parameters.
 
< Prev   CONTENTS   Next >

Related topics