Example 1: Smart card and Password
If you wish to require that both a smart card that signs with a key, whose public part is S, and a password be used in a policy, you create a policy by first extending
TPM_CC_PolicySigned || SHA256(publicKey) || 0x0000 = 0x0000060 || SHA256(S)
into a buffer of all zeroes. You then extend a requirement for proving knowledge of a password by extending
into the result.
If you wish to also require that the command be executed in locality 4, you extend
TPM_CC_PolicyLocality || locality4
Extending a new requirement is equivalent to a logical AND.
Using a trial session, you first load the public key into the TPM and then execute the three commands used in each of the simple assertion policies: TPM2_PolicySigned, TPM2_PolicyAuthValue, and TPM2_PolicyLocality.
Example 2: A Policy for a Key Used Only for Signing with a Password
In this example, Bob creates a key that requires a key only be used for signing, and only if a password is presented for the key. Start with a policy of all zeroes, and first extend it with
TPM_CC_PolicyCommandCode || TPM_CC_Sign = 0x0000016C || 0x0000015D
Then extend it again with
Example 3: A PC state, a Password, and a Fingerprint
In this example, Bob creates a key which requires that PCR1 be equal to an approvedPCRdigest, a password, and a fingerprint. When crafting a policy that involves a PCR digest, it's generally good practice to start with that term first. This is because if it fails, there is no need to bother the user with a password and a fingerprint.
You use the TPM to create this policy value as follows:
1. Start a trial session.
2. Use TPM2_PolicyPCR to lock the policy to approvedPCRdigest.
3. Use TPM2_PolicyAuthValue (to require a password at execution).
4. Load the publicKey of the fingerprint reader.
5. Use TPM2_PolicySigned pointing to the public key and stateOfRemoteDevice (which is “Bob's finger”).
6. Get the value of the policy from the TPM.
7. End the session.
Example 4: A Policy Good for One Boot Cycle
In this example, the IT administrator gives permission (for example, to a technician) for a previously created key to be used only during this boot cycle. First the administrator creates a key that has a policy controlled by a wild card. When the administrator wants to allow the technician to use the key, the admin reads the current boot counter value from the PC using TPM2_GetCapability and authorizes a policy for the key that states that the value of the boot counter must be its current value. The admin does this using their private key to sign this new policy, called newPolicy. If the key is in his own TPM, he can use the command TPM2_Sign to sign it. The admin sends this policy and signature to the technician.
The technician loads the public key into the TPM, using TPM2_LoadExternal, and then uses the TPM2_VerifySignature command to verify the signature of the new policy. This command returns a ticket to the technician.
The technician uses the key by starting a policy session and then executing TPM2_PolicyCounterTimer with an offset pointing to the boot counter. This satisfies the newPolicy. The technician then executes TPM2_PolicyAuthorize, feeding it the newPolicy and the ticket, and points to the admin's public key. The TPM verifies that the ticket is valid for the newPolicy, using the admin's public key, and then substitutes the current policy buffer with the wildCardPolicy. At this point, the technician can use the key during this boot cycle.
When the PC is rebooted, the boot counter is incremented. If the technician tries to use the policy again, they can never satisfy newPolicy, so they can't use the key.
-  In this case you don't assign a PolicyReference to this signature, so the last appended value is 0x0000, which is 2 bytes of 0, which means the value of the PolicyReference of the signature is EmptyBuffer.