Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

Example 5: A Policy for Flexible PCRs

In this example, an IT administrator wants to lock a full-disk-encrypting software key to a set of PCRs that represent (among other things) the BIOS firmware. But the admin realizes that the BIOS might need to be updated and so uses TPM2_PolicyAuthorize to provide flexibility as to what PCR values are used to release the hard-disk encryption keys.

The admin's key is created with only TPM2_PolicyAuthorize, but the admin authorizes a new policy that requires the PCRs to be equal to the initial PCR values. The admin then uses TPM2_VerifySignature to create a ticket that can be used to validate use of that new policy.

When the disk-encryption key is to be decrypted, the machine needs to do the following:

1. Start a new policy session.

2. Use TPM2_PolicyPCR to replicate the new policy in the TPM.

3. Use TPM2_PolicyAuthorize (with the public administrator key, the new policy, and the policy ticket) to cause the TPM to change the internal policy buffer of its session to the original PolicyAuthorize policy.

4. Use the satisfied policy session to release the disk-encryption key.

If the admin ever needs to change the PCR values that are validated, the admin can send the user a newly signed policy corresponding to the new PCR values, and the user can use that to create a new ticket to use after the PCRs have changed.

Example 6: A Policy for Group Admission

In this example, a group of people are given access to use a department key. But as people come and go from the department, some people's access is removed and other people's access is granted. Each member of the department has access to a private key that represents them. You can do this with a clever use of TPM2_PolicyNV, TPM2_PolicyAuthorize, and TPM2_PolicySigned.

First you create a NV index that has 64 bits (assuming there will never be more than 64 people in your department). Write authority is given only to the IT administrator, using the admin's private key. The admin writes it with all zeroes, noting the value of the index name. The admin then creates the department key with only a PolicyAuthorize policy, with the public key corresponding to the IT administrator of the department.

The IT administrator assigns each member of the group a bit in the NV space. To give a user the right to use the key, the admin creates and approves a policy that requires the corresponding bit of the NVRAM index to be a 1 (using PolicyNV) and that the appropriate user use their private key for authentication, using PolicySigned. When the admin wants to remove a user's ability to use the key, the admin changes the bit in the NVIndex that corresponds to that user to a 0. The admin then signs each of these new policies and gives them to the appropriate user.

When a user wants to use the key, they do the following:

1. Start a policy session.

2. Executed a PolicyNV command to verify the user is still in the department.

3. Execute a PolicySigned command to prove the user is the corresponding person.

4. Execute a PolicyAuthorize command to change the TPM's internal policy buffer to the PolicyAuthorize policy.

5. Use the key.

Example 7: A Policy for NV RAM between 1 and 100

As noted earlier, this is as simple as executing two commands: one to say the NV RAM value is greater than 1 and another to say it's less than 100. This only allows values 2, 3, 4, ...99.

< Prev   CONTENTS   Next >

Related topics