Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

If the Policy Is Flexible (Uses a Wild Card)

Satisfying a wild card policy is more complicated than creating one. For one thing, when the wild card policy is created, only the public key of the party who can authorize the eventually satisfied policy is identified. When one is used, an authorized policy must have been created, and a ticket proving that it's authorized must be produced. Then a user satisfies the approved policy and runs TPM2_PolicyAuthorize. The TPM checks that the policy buffer matches the approvedPolicy and that the approvedPolicy is indeed approved (by using the ticket), and if it is, changes the policy buffer to the flexible policy.

Preparing a policy to be used is then a two-step process. First, the authorizing party has to approve a policy by using their private key to sign Hash(approved Policy || wildCardName=policyRef). This is then sent to the user.

The user loads the public key of the authorizing party in their TPM and uses TPM2_VerifySignature against this signature, pointing to the handle of the public key. Upon verification, the TPM produces a ticket for this policy.

When the user wants to use this new approved policy, the user first satisfies the approved policy the way they ordinarily would and then gets the TPM to switch the approved policy to the flexible policy by calling TPM2_PolicyAuthorize, giving it as parameters the name of the session that has satisfied the approved policy, the approved policy, wildCardName, keyName, and the ticket. The TPM verifies that the ticket is correct and matches the approved policy in the session policy buffer. If so, it changes the session policy buffer to be the value of the flexible policy.

Thus creating a flexible policy is really a two part process. Recapitulating: First the policy itself is created:

• Start a Trial Session

• Load the administrator's public key

• Use TPM2_PolicyAuthorize pointing to the administrator's public key

• Get the Value of the policy from the TPM. We call this policy workSmartcardPolicy

• End the session

Then an authorized policy is created using the administrator's private key

• Create a policy

• Load the administrator's private key

• Use the administrator's private key to sign the policy

• Use the TPM on which the approved policy is to be used to verify the signature (this produces a ticket)

Satisfying the Approved Policy

Satisfying the approved policy is done just as though it were the only policy you had to worry about. It doesn't matter if the approved policy is simple, compound, or flexible. After it's satisfied, it's then transformed.

Transforming the Approved Policy in the Flexible Policy

Now that the TPM's buffer is equal to the approved policy, you can transform it into the flexible policy by executing TPM2_PolicyAuthorize, passing the current value of the session policy buffer, PolicyTicket, and AdministratorPublicKeyHandle. The TPM checks that the policy buffer matches the approved policy and that the approved policy is indeed approved (by using the ticket) and, if it is, changes the policy buffer to the flexible policy. At this point, commands can be executed on an object that requires this particular flexible policy.

Although flexible policies were introduced to the TPM in order to provide a solution to the brittleness of PCRs, they can be used to solve many more conundrums than that. They allow an administrator to decide after an object is created how the policy for that object can be satisfied. Because the name of an object (or NV index) is calculated from its policy, it isn't possible to change the policy of an NV index or a key. However, using a flexible policy, you can change the way a policy is satisfied after the fact.

Suppose a key is given a flexible policy when it's created, and later the administrator of the flexible policy wants to make it be the policy in Figure 14-6. The admin can accomplish this by signing the policy represented by Figure 14-6 and sending it to the user. Someone must do the preparatory step of creating a ticket by running

TPM2_VerifySignature, but after that the user only has to satisfy the policy given by Figure 14-6 and then run PolicyAuthorize to prove that the policy has been approved.

< Prev   CONTENTS   Next >

Related topics