Extended Authorization (EA) Policies
TPM 2.0 has unified the way that all entities controlled by the TPM may be authorized. Earlier chapters have discussed authorization data used for passwords and HMAC authorization. This chapter goes into detail about one of the most useful new forms of authorization in the TPM, starting with a description of why this feature was added to the TPM and then describing in broad brushstrokes the multifaceted approach that was taken.
This new approach for authorization has many capabilities. As a result, if a user wants to restrict an entity so it can be used only under specific circumstances, it's possible to do so. The sum total of restrictions on the use of an entity is called a policy. Extended authorization (EA) policies can become complex very quickly. Therefore this chapter's approach is incremental, first describing very simple policies and gradually adding complexity. This is done by examining how to build the following:
• Simple assertions
• Command-based assertions
• Multifactor authentication
• Multiuser/compound authorization
• Flexible policies that can be changed on the fly
Throughout this chapter, you see examples of practical policies like those used in most cases. It turns out that building policies is different than using them, so you learn how a user satisfies a policy; at that point it should become clear why policies are secure.
Finally, you consider some policies that can be used to solve certain special cases. This section may spur your creativity—you'll see that there are many more ways of using policies than you've thought of.
Let's begin by comparing EA policies to using passwords for authentication.
Policies and Passwords
All entities in the TPM can be authorized in two basic ways. The first is based on a password associated with the entity when it's created. The other is with a policy that is likewise associated with the entity when it's created. A policy is a means of authorizing a command that can consist of almost any approach to authorization that someone can think of. Some entities (hierarchies and dictionary attack reset handles) are created by the TPM and thus have default passwords and policies. The TPM-assigned name of these entities is fixed, not dependent on the policy that is used to authorize them. Such entities' policies can be changed.
All other entities—NVRAM indexes and keys—have their name calculated in part from the policy that is assigned when they're created. As a result, although their password can be changed, they have policies that are immutable. As you'll see, some policies can be made flexible so they can be easily managed in spite of this immutability.
Anything that can be done directly with a password can also be done with a policy, but the reverse isn't true. Some things (like duplicating a key) can only be authorized using a policy command. (However, making things more complicated, you can still use a password to authorize duplicating a key, by using a policy that describes a password authorization.)
A policy can be fine-tuned—everything is possible, from setting a policy to be the NULL policy that can never be satisfied, to having different authentication requirements for individual commands or for different users when applied to an entity. Thus EA is able to solve many issues that application developers need to deal with.