Incredibly complicated policies are possible but are unlikely to be used in real life. In order to explain the creation of policies, this chapter introduces an artificial distinction between different kinds of policies, which are described in detail:
• Simple assertion policy: Uses a single authentication to create a policy. Examples include passwords, smart cards, biometrics, time of day, and so on.
• Multi-assertion policy: Combines several assertions, such as requiring both a biometric and a password; or a smart card and a PIN; or a password, a smart card, a biometric, and a GPS location. Such as policy is equivalent to using a logical AND between different assertions.
• Compound policy: Introduces a logical OR, such as “Bill can authorize with a smart card OR Sally can authorize with her password.” Compound policies can be made from any other policies.
• Flexible policy: Uses a wild card or placeholder to be defined later. A policy can be created in which a specific term can be substituted with any other approved policy. It looks like a simple assertion, but any approved (simple or complicated) policy can be substituted for it.
As mentioned, a policy is a digest that represents the means of satisfying the policy.
A policy starts out as a buffer that is the size of the hash algorithm associated with an entity, but set to all zeroes. As parts of the policy are satisfied, this buffer is extended with values representing what has happened. Extending a buffer is done by concatenating the current value with new data and hashing the resulting array with the designated hash algorithm. Let's demonstrate this with the simplest of all polices: those than require only one type of authorization to be satisfied.
Simple Assertion Policies
A simple Extended Authorization (EA) policy: the simple assertion policy, which consists of a single authentication, can be one of the following types:
• Password or HMAC (policies that require proof of knowledge of an object's password)
• Digital signatures (smart cards)
• Attestation of an external machine (a particular biometric reader attests that a particular user has matched, or a particular GPS attests that the machine is in a particular location)
• Physical presence (an indication such as a switch that proves a user is physically present at the TPM. While this is in the
specification, it is not likely to be implemented, so we will ignore it in the following.)
• PCRs (state of the machine on which the TPM exists)
• Locality (the software layer that originated the TPM command)
• Internal state of the TPM (counter values, timer values, and so on)
Creating simple assertion policies can be done using the TPM itself, in three steps:
1. Create the trial session. This is as simple as executing the following command:
It's passed a parameter TPM_SE_TRIAL to tell the TPM to start a trial session, and a hash algorithm to use for calculating the policy. This returns (among other things) the handle of a trial session. It's referred to as myTrialSessionHandle.
2. Execute TPM2 policy commands that describe the policy (described shortly).
3. Ask the TPM for the value of the policy created with the command by executing
and passing it the handle of the trial session: myTrialSessionHandle).
4. End the session (or reset it if you want to use it again) by executing
again passing it the name of the trial session: myTrialSessionHandle.
Because steps 1, 3, and 4 are common to all simple assertions, they aren't repeated in the following; we merely describe the second step for each command.