Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

Digital Signatures (such as Smart Cards)

It wasn't generally possible to authenticate use of a TPM 1.2 entity using a private key.

In TPM 2.0, this has changed. It's now possible to require a digital signature as a form of access control. When a policy is formed using this assertion, the policy value is extended with three values: TPM_CC_PolicySigned, SHA256 [1](publicKey) and a policyRef.

(A policyRef is used to identify precisely how the signed assertion will be used. Often it will be left as an Empty Buffer, but if a person is asked to authorize an action remotely, that person may want to precisely identify what action is being authorized. If the policyRef is part of the policy, the authorizing party will have to sign that value when authorizing the action.)

This can be done using a trial session by using the TPM2_PolicySigned command; but before this can be done, the TPM must know the public key used to verify the signature. This is done by loading that public key into the TPM first. The easy way to do this is to use a TPM2_LoadExternal command and load the public key into the TPM_RH_NULL hierarchy. You do so with the command TPM2_LoadExternal, passing in the public key structure.

This returns a handle to the loaded public key, for now called aPublicHandle. Then you execute the command TPM2_PolicySigned, passing in the handle of the trial session and the handle of the loaded public key.

Satisfying this policy is trickier. Proving to the TPM that the user has the smart card with the private key that corresponds to this public key is a bit more involved. This is done by using the private key to sign a nonce produced by the TPM. You see this in detail at the end of this chapter.

Another assertion can be required: that the TPM resides in a machine that is healthy.

This is done with PCRs.

PCRs: State of the Machine

Platform Configuration Registers (PCRs) in a TPM are typically extended by preboot or postboot software to reflect the basic software running on a system. In the 1.2 design, only a few things could use this authorization. Further, because using PCRs to restrict use of TPM 1.2 keys is a brittle operation, the restriction made this feature difficult to use.

In the 2.0 design it's possible to require that PCRs contain particular values for authorizing any command or entity. The policy merely has to specify which PCRs are being referenced and the hash of their values. Additionally, TPM 2.0 includes multiple ways of handling the brittleness. Again, all policies begin as a variable of size equal to the hash algorithm and initialized to zero. To use the PCR assertion, the policy is extended with TPM_CC_PolicyPCR || PCRs selected || digest of the values to be in the PCRs selected.

If a trial session is being used to calculate this policy, the user first selects the PCRs they wish to have defined values and puts them into a TPML_PCR_SELECTION. The user then calculates the hash of the concatenation of the defined values, calling the result pcrDigest. Then the user executes the command TPM2_PolicyPCR, passing in again the handle of the trial session and the PCRs selected and the pcrDigest just calculated.

When a user wishes to use an entity locked to PCRs, they execute the TPM2_PolicyPCR command, passing it the list of PCRs selected and the expected value of pcrDigest. Internally the TPM calculates the digest of the then-current values of those PCRs, checks it against the passed in value, and, if they match, extends the session's digest with TPM_CC_PolicyPCR || PCRs selected || digest of the values currently in the PCRs selected.

This might leave a security hole—what if the PCR values change after the assertion is made? The TPM protects against this by recording its PCR-generation counter in the TPM session state as TPM_PolicyPCR is executed. Each time any PCR is extended, the TPM generation counter is incremented. When the policy session is used to authorize a command, the current state of the generation counter is matched against the recorded value. If they don't match, it indicates that one or more PCRs have changed, and the session is unable to authorize anything.

As added flexibility, the platform-specific specification can indicate that certain PCRs will not increment the TPM generation counter. Changes to those PCRs will not invalidate the session.

  • [1] SHA256 is used throughout this book as the hash algorithm for everything except PCRs. However, technically you can use any hash algorithm that matches that chosen when the policy is created.
 
< Prev   CONTENTS   Next >

Related topics