State of the External Device (GPS, Fingerprint Reader, and So On)
Perhaps one of the most interesting new assertions in the TPM design is the ability to use an assertion that is dependent on the state of an external device. The device is represented by a public/private key pair. The state of the device may be anything the device can use its private key to sign (together with a nonce from the TPM). If the device is a biometric, it may be as simple as “Bob just authenticated himself to me.” If it's a GPS unit, it may be “My current position is Baltimore.” If it's a time service, it may be “The current time is business hours.” The assertion identifies both the public key that represents the external device and the value expected. The TPM does nothing more than compare the signature and the identified information with what it's expecting. It doesn't perform calculations on the resulting information, so the device making the representation needs to decide if its input matches the thing it's signing.
This provides flexibility for a biometric: if Bob has registered several fingerprints with the matcher, the TPM doesn't need to know which one was signed with—just that the match corresponds to “Bob.” A GPS coordinate need not be exact—just in a specified area. The assertion need not specify an exact time, but rather an identifier for the range of times that are acceptable. However, the flexibility isn't entirely general. This doesn't say “Some fingerprint reader attests that Bob has authenticated to the device”; it says “This particular fingerprint reader (as demonstrated by a signature) attests that Bob has authenticated to the device.” This allows the creator of the policy to determine which biometric (or other devices) it trusts to not be easily spoofed.
Once this policy is satisfied, there are no further checks, so it's possible for an assertion to no longer be satisfied when the TPM actually executes the command.
Creating the policy is done by starting with a variable of size equal to the hash algorithm and initialized to zero. This is then extended with TPM_CC_PolicySigned || SHA256(publicKey) || stateOfRemoteDevice, where stateOfRemoteDevice consists of two parts: the size of the description followed by the description.
If you're using a trial session to create this policy, you execute the command TPM2_PolicySigned. Again, you must pass the handle of the trial session, the handle of the public key that corresponds to the private key of the device, and the state of the remote device that it will sign when the policy is satisfied. For example, if the remote device is a fingerprint reader, the device may sign “Sally correctly authenticated.”
Sometimes the object's creator doesn't really know under what circumstances they want a key to be used. Perhaps the key will be used in case of an emergency, and the creator doesn't know who will use the key or how. This is a use case for a wild card policy.