Considerations in Creating Policies
In most cases, policies should be considered to represent roles when using TPM entities—and usually there are only a few possible roles.
End User Role
This represents the authentication that is satisfied for a user to use an entity. Using an entity means doing something like one of the following:
• Signing with a key
• Reading a NV location
• Writing an NV location
• Quoting with a key
• Creating keys
An administrator of an entity may do different things for different entities. For NVRAM, they may be given the responsibility of managing the limited resource of available NVRAM. This would include the following:
• For NV:
• Creating and destroying NV indexes
• For keys:
• Authorizing duplication
• Changing authorization with PolicyAuthorize
In the event that the user of a key leaves the company or is unable to use a key necessary to obtain some enterprise data, it's important that another person (for example, the user's manager) be able to use the key. This is an understudy role.
An office role consists of a combination (PolicyOr) of an enterprise administrator role and the user's role.
A home role consists of a combination of a user acting as an administrator and acting as an end user. It may also include using different roles for using an entity on different machines, because different forms of authentication may be available on different machines. (For example, one machine may have a biometric reader and another may not.)
Once the roles are defined, policies can be created for them. Once the policies are created, they can be reused whenever entities are created, obviating the need to re-create the policies each time.
Using a Policy to Authorize a Command
You've seen how to satisfy a number of simpler policies. In order to satisfy any policy so that an object that requires the policy can be used, the steps are always the same:
1. Start a policy session.
2. Satisfy the policy for that session (this can require multiple steps).
3. Execute the command.
4. End the session.
This is very similar to the way policies are created, but satisfying a policy often requires additional steps. In a high-level API, most of the grunt work of satisfying a policy is done for you; but if you're talking directly to the TPM, some details are required to achieve this.
Starting the Policy
Starting the PolicySession is easy, as shown in Chapter 13. It's done with the command TPM2_StartAuthSession. This command returns a bunch of stuff, including a session handle, here called myPolicySessionHandle; and a nonce, created by the TPM, here called nonceTPM. You need both of these variables to satisfy the policy.