Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

Enhanced Authorization (New in 2.0)

The TPM 1.2 specification accrued a number of new facilities over the years. This resulted in a very complicated specification with respect to means and management of authentication. The TPM was managed using either physical presence or owner authorization. Use of the EK was gated by owner authorization. Keys had two authorizations: one for use of the key and one to make duplicates of the key (called migration in the TPM 1.2 specification). Additionally, keys could be locked to localities and values stored in PCRs.

Similarly, the NVRAM in TPM 1.2 could be locked to PCRs and particular localities, and to two different authorizations—one for reading and one for writing. But the only way the two authorizations could differ was if one of them were the owner authorization.

Certified migratable keys had the same authorizations as other keys; but to complete the migration, a migration authority had to sign an authorization, and that authorization had to be checked by the TPM. This process also required owner authorization.

Making things even more complicated, the use of certain owner-authorized commands and keys could be delegated to a secondary password. However, the owner of the primary authorization knew those passwords, and delegation used precious NVRAM in the TPM. Even worse, the technique was difficult to understand and, as a result, was never employed to our knowledge.

The 2.0 specification has a completely different take, called enhanced authorization

(EA). It uses the following kinds of authorizations:

Password (in the clear): This was missing in TPM 1.2. In some environments, such as when BIOS has control of a TPM before the OS has launched, the added security obtained by using a hash message authentication code (HMAC) doesn't warrant the extra software cost and complexity of using an HMAC authorization to use the TPM's services.

HMAC key (as in 1.2): In some cases, particularly when the OS that is being used as an interface to talk with the TPM isn't trusted but the software talking to the TPM is trusted, the added cost and complexity of using an HMAC for authorization is warranted. An example is when a TPM is used on a remote system.

Signature (for example, via a smart card): When an IT employee needs to perform maintenance on a TPM, a smart card is a good way to prevent abuse of an IT organization's privileges. The smart card can be retrieved when an employee leaves a position, and it can't be exposed as easily as a password.

Signature with additional data: The extra data could be, for example, a fingerprint identified via a particular fingerprint reader. This is a particularly useful new feature in EA. For example, a biometric reader can report that a particular person has matched their biometric, or a GPS can report that a machine is in a particular region. This eliminates the TPM having to match fingerprints or understand what GPS coordinates mean.

PCR values as a proxy for the state of the system, at least as it booted: One use of this is to prevent the release of a full-disk encryption key if the system-management module software has been compromised. [1]

Locality as a proxy for where a particular command came from: So far this has only been used to indicate whether a command originated from the CPU in response to a special request, as implemented by Intel TXT and AMD in AMD-v. Flicker, [2] a free software application from Carnegie Mellon University, used this approach to provide a small, secure OS that can be triggered when secure operations need to be performed.

Time: Policies can limit the use of a key to certain times. This is like a bank's time lock, which allows the vault to be opened only during business hours.

Internal counter values: An object can be used only when an internal counter is between certain values. This approach is useful to set up a key that can only be used a certain number of times.

Value in an NV index: Use of a key is restricted to when certain bits are set to 1 or 0. This is useful for revoking access to a key.

NV index: Authorization is based on whether the NV index has been written.

Physical presence: This approach requires proof that the user is physically in possession of the platform.

This list isn't complete, but it gives examples of how the new policy authorization scheme can be used. Additionally, you can create more complicated policies by combining these forms of authorization with logical AND or OR operations such as these:

• Mary identifies herself with an HMAC key and a smart card associated with a public key.

• Joe identifies himself with a fingerprint authentication via a particular reader identified by the public key.

• This key can be used by Mary OR Joe.

Policies can be created that are either simple or complex, and all objects or entities of the TPM (including the TPM's hierarchies) can have policies associated with them. EA has enormously extended the possible uses of the TPM, particularly in managing authorizations; yet the net result has been to reduce the amount of code necessary to create a TPM, eliminate the NVRAM that was used for delegation, and eliminate all the previously existing special cases (thus lowering the learning curve for using a TPM).

Clever policy designs can allow virtually any restriction on key use that you can envision, although some (such as restricting use of a document to only one kind of document processor) would be exceptionally difficult, if possible at all. [3] The new EA allows a number of new scenarios, including the following:

IEEE Security & Privacy 1, no. 3 (2003): 60–62.

• Multifactor authentication of resources

• Multiuser authentication of resources

• Resources used only n times

• Resources used only for certain periods of time

• Revocation of use of resources

• Restricting ways resources can be used by different people

  • [1] Yuriy Bulygin, Andrew Furtak, and Oleksandr Bazhaniuk, “A Tale of One Software Bypass of Windows 8 Secure Boot” (presentation, Black Hat 2013), briefings.html#Bulygin.
  • [2]
  • [3] E.W. Felten, “Understanding Trusted Computing: Will Its Benefits Outweigh Its Drawbacks?”
< Prev   CONTENTS   Next >

Related topics