Why Extended Authorization?
EA in the TPM was created to solve the basic problem of manageability of TPM entity authorization. It makes it easier to learn how to use a TPM by having all TPM entities be authorized the same way, and it also allows a user to define authorization policies that can solve the following problems:
• Allow for multiple varieties of authentication (passwords, biometrics, and so on).
• Allow for multifactor authentication (requiring more than one type of authentication).
• Allow for creation of policies without the use of a TPM. Policies don't contain any secrets, so they can be created entirely in software. That doesn't mean secrets aren't needed to satisfy a policy.
• Allow attestation of the policy associated with an entity. It should be possible to prove what authorization is necessary in order to use an entity.
• Allow for multiple people or roles to satisfy a policy.
• Allow restriction of the capabilities of a particular role for an object to particular actions or users.
• Fix the PCR brittleness problem. In TPM 1.2, once an entity was locked to a set of PCRs that measured particular configurations, if the configurations ever had to be changed, the entity could no longer be used.
• Create a means to change how a policy behaves, providing flexibility.
Multiple Varieties of Authentication
Today, many different kinds of techniques and devices are used for authentication. Passwords are the oldest (and perhaps weakest) form of authentication. Biometrics such as fingerprints, iris scans, facial recognition, penned signatures, and even cardiac rhythm are used for authentication. Digital signatures and HMACs are forms of cryptographic authentication used in tokens or keys. Time clocks in banks use the time of day as a form of authentication and don't allow a vault to be opened except during business hours.
The TPM was designed so that objects can use almost any kind of authentication conceivable, although many forms require additional hardware. A policy can consist of a single type of authentication or multiple varieties.
Multifactor authentication is one of the most important forms of security and is popular today. It requires more than one means of authentication in order to provide authorization to execute a command. Those authentications may take many forms— smart cards, passwords, biometrics, and so on. The basic idea is that it's harder to defeat multiple authentication formats than it is to defeat a single one. Different forms of authentication have different strengths and weaknesses. For example, passwords can be easily supplied remotely—fingerprints less so, especially if the design is done correctly.
The TPM 2.0 design allows for many different forms of authentication and provides facilities to add even more using external hardware. Each mechanism that can be used for authentication is called an assertion. Assertions include the following:
• Smart cards providing digital signatures
• Physical presence
• State of the machine (Platform Configuration Register [PCR])
• State of the TPM (counters, time)
• State of external hardware (who has authenticated to a fingerprint reader, where a GPS is located, and so on)
A policy can require that any number of assertions be true in order to satisfy it. The innovation behind EA in the TPM is that it represents in a single hash value a complex policy consisting of many assertions.
How Extended Authorization Works
A policy is a hash that represents a set of authentications that together describe how to satisfy the policy. When an entity (for example, a key) is created, a policy may be associated with it. To use that entity, the user convinces the TPM that the policy has been satisfied.
This is done in three steps:
1. A policy session is created. When a policy session with the TPM is started, the TPM creates a session policy buffer for that session. (The size of the session policy buffer is the size of the hash algorithm chosen when the session was started, and it's initialized to all zeroes.)
2. The user provides one or more authentications to the TPM session, using TPM2_PolicyXXX commands. These change the value in that session policy buffer. They also may set flags in the session that represent checks that must be done when a command is executed.
3. When the entity is used in a command, the TPM compares the policy associated with the entity with the value in the session policy buffer. If they aren't the same, the command will not execute. (At this point, any session flags associated with policy authorizations are also checked. If they aren't also satisfied, this command isn't executed.)
Policies don't contain any secrets. As a result, all policies can be created purely in software outside a TPM. However, the TPM must be able to reproduce policies (in a session's policy digest) in order to use them. Because the TPM has this ability, it makes sense for the TPM to allow the user to use this facility to produce policies. This is done by using a trial session. A trial session can't be used to satisfy a policy, but it can be used to calculate one.
Policy sessions used to satisfy policies can be somewhat more complicated than the creation of a policy. Some policy commands are checked immediately and update a policy buffer stored in the session. Others set flags or variables in the session that must be checked when the session is used to authorize a command. Table 14-1 shows which policy commands require such checks.
Table 14-1. Policy Commands that Set Flags