Policy authorization, also known as Extended Authorization (EA), is the Swiss army knife of TPM authorizations. With the right expertise, you can do just about any kind of authorization with it. This section and the following chapter, Chapter 14, aim to give you the knowledge required to use the incredible power of EA. In this section, we describe how EA works at a high level, the high-level policy authorization lifetime, and each of the steps in that lifetime: policy hash creation, entity creation or alteration, policy session creation, and policy session use. We will also explore the security properties of EA. As much as possible, this section doesn't describe individual policy commands; the next chapter describes those in detail.
How Does EA Work?
At a high level, EA enables very expressive policies. EA, like HMAC and password authorizations, is used to authorize actions on a TPM entity. Some examples of the controls that can be enforced before authorizing an action are:
• Requiring certain values in a specified set of PCR registers
• Requiring a certain locality
• Requiring a certain value or range of values in an NV index
• Requiring a password
• Requiring physical presence
• Requiring sequences of conditions
And there are many more. These can be combined in AND and OR combinations that result in an infinite number of policy variations. Policy authorizations allow considerable complexity and creativity in authorizations. Policy authorizations are the “mother of all complex authorizations.”
For a command to be authorized by a policy authorization, two things must be correct:
• Each policy command “asserts” that some condition(s) are true. If the specified conditions for each policy command aren't true, then the authorization fails. This failure can happen either:
• At the time of the policy command: This is an immediate assertion, and this failure occurs before ever getting to the command to be authorized. This failure means the policyDigest for the session isn't hash-extended
by the policy command. If the policy command is successful, the policyDigest is hash-extended with the proper values.
• At the time of the command being authorized: This is a
deferred assertion. In this case, the policyDigest is
hash-extended with data that indicates that the particular policy command was executed. Testing of the conditions is deferred until the time of the action being authorized.
■ Note some commands can be combined assertions, which means both immediate and deferred conditions must be valid for the assertion to pass.
• At authorization time:
• Any deferred conditions are checked. If any of these fail, the command isn't authorized.
• The entity's authPolicy is compared to the policy session's policyDigest. If they're equal, the command is authorized, and it executes. If they aren't equal, the authorization fails. Basically, if the authPolicy is equal to the policyDigest, this is proof that the required policy commands were executed, any immediate assertions generated by those commands passed, and that all this occurred in the correct sequence before the command being authorized.
Now you've seen two time-related terms: policy command time and authorization time. All the time intervals related to policy authorizations need to be defined precisely in order for you to understand policy authorizations.