Conventional Security Services

Signing

When a TPM executes TPM_Sign, it does the same job as a cryptographic smart card that is signing data. Two signing algorithms are supported by first generation TPMs: one that accepts the output of an SHA-1 hash, and one that accepts DER encoded data.

TPM_Sign signs data using a key that is currently loaded into a TPM. The signing key must be one of two types, either TPM_KEY_SIGNING or TPM_KEY_LEGACY. A TPM will refuse to use a TPM identity key because they are used to prove that data originated in a TPM: using them for general purpose signing would enable a rogue to forge signed data structures that would appear to be generated by a TPM itself.

Evidence that target data was signed on a TPM can be provided by signing the target data using TPM_Sign, and then creating a “certificate” that shows the relationship between the signing key and the TPM. The process of key certification is described later in this chapter. These certificates describe the properties of a key and are signed by TPM identities. If a certified key is non-migratable, the recipient of a certificate is assured that the signing key was used on a TPM. On the other hand, if a certified TPM key is migratable, the TPM key's owner must be relied upon not to use it for signing outside a TPM.

Generating Random Data

The capability TPM_GetRandom fetches random data from a TPM (for use as symmetric keys or nonces in security protocols, for example). It is essential that random data produced by a TPM is derived from unpredictable data, and the method of production should be reflected in a TPM's endorsement certificate.

Random data is used by many security services. As well as providing random data for the host platform, a TPM also needs random data for its own security processes, and automatically fetches random data from its internal generator whenever it needs it (during authorization and for generating keys, for example).

The overriding requirement is that an attacker cannot guess the value of random data, so a better name would be “unpredictable” data. Random data should have the statistical properties of white noise, but this does not imply that a high level of entropy on its own is sufficient. Passing the current time value (hours and minutes) through a hash algorithm generates a digest value with a high level of entropy, for example, but using this for cryptographic purposes is inadvisable because the space that must be searched by a cryptanalyst is small (even though an SHA-1 digest is 20 bytes long). Once the cryptanalyst knows that the “random” data was generated from the current time value, he simply uses brute-force and tries all reasonable time values until the protected value is revealed. Unfortunately, generating large amounts of unpredictable data is often problematic. Software can gather small amounts of unpredictable data by noting whether files contain an even or odd number of bytes, or noting the time between key presses on a keyboard, for example. Even the baud rate of hardware generators is limited by the bandwidth (whether explicit or implicit) of filters.

TCPA, therefore, requires that a TPM's random data be generated in a two-step process. This method enables large amounts of acceptably “random” data to be produced from relatively small amounts of genuinely unpredictable data, gathered over the whole lifetime of a TPM. The first step is to provide as much unpredictable data as possible. This can either be inserted into a TPM, or generated inside the TPM. The second step is to pass the unpredictable data through a “mixing” function to produce the actual random data that is used by the TPM and the host platform. This internal, unpredictable state must be non-volatile, so further inputs of unpredictable data merely add to previous inputs over the lifetime of the TPM. Extra unpredictable data should be added as often as possible, certainly at least one bit of entropy per platform boot.

The capability TPM_StirRandom is provided to put additional unpredictable data into a TPM. Most platforms will never need to use this capability, however, because many TPMs will include an on-chip source of unpredictable data (the potentially-confusingly named “Random Number Generator”). It seems highly desirable that the tpm_distributed_validation field of a TPM's endorsement credential indicates whether the TPM has a built-in source of unpredictable data. Otherwise, random data from a TPM is highly dependent on proper use of TPM_StirRandom. If a TPM does not have an on-chip source of unpredictable data, tpm_distributed_validation should indicate whether TPM manufacturers have injected some unpredictable data into a TPM before the TPM left their control. Without this information, a challenger cannot determine whether or not to trust random data from the TPM, and hence whether or not to trust the TPM. If a TPM does not have an on-chip source of unpredictable data and a manufacturer has not injected unpredictable data into a TPM, a challenger should not trust random data from that TPM.

The random data produced by a TPM conforms to the Pseudo Random Noise Generator requirements of FIPS-140.

Discovering the Properties of the TPM

A TPM has three capabilities with “getCapability” in their title (TPM_GetCapability, TPM_GetCapabilitySigned, and TPM_GetCapabilityOwner). The first one indicates what the TPM is capable of doing, the second one is a signed version of the first one, and the third reports flags to the TPM owner.

There are varying opinions about the appropriateness of certain of these “getCapability” responses, depending on the degree to which people agree that a response indicates (directly or indirectly) what the TPM is capable of doing. It may be that some responses should be evoked using separate specialized commands. It is also arguable that the third capability should have a different title altogether, because it merely returns the values of some flags. Be that as it may, the “getCapability” commands are intended to provide non-identifying information about a TPM before using that TPM. The TCPA specification does not permit a TPM to return any information that identifies a specific TPM.

TPM_GetCapability requires no authorization to use, and the following static information can be requested to be returned:

• Whether the TPM provides a capability. Obviously, this is really only useful for finding out whether a TPM supports a particular optional capability.

• Whether the TPM supports a particular algorithm or protocol.

• The number of platform configuration registers and data integrity registers provided by the TPM.

• The identity of the manufacturer. This is done in a platform and manufacturer specific way [TCPA 2001c].

• The version of the TCPA specification that is implemented by the TPM.

It can also return the following dynamic information:

• The number of 2048-bit RSA keys that the TPM is currently capable of loading

• A list of all the handles of the TPM keys that are currently loaded into the TPM

• Whether the TPM has enough resources to load a particular type of key

TPM_GetCapabilitySigned is intended to be part of the response phase of a challenge/response protocol. The challenger should provide a nonce, and the capability returns the nonce, plus the same results as TPM_GetCapability, signed by a key. Naturally, authorization is required to use the TPM key that signs the result. Any type of TPM signing key, including a TPM identity, can be used.

TPM_GetCapabilityOwner requires authorization from the TPM owner, and returns the current state of both the TPM's non-volatile and volatile flags. A single command is used for the sake of simplicity. Some of the flags are private to the TPM owner and some are not, and many can be deduced from the operation of a TPM and the return codes that it produces. The state of the Activate flag, for example, can be read directly only by this command but can be deduced indirectly by whether (specific) commands return TCPA_DEACTIVATED.

Auditing the TPM

It is widely acknowledged that the audit functions provided by the v1.1 TCPA specification [TCPA 2001a] are broken, and are of little use.

The TPM audit mechanism is for auditing of the TPM, not auditing of the platform. During TPM audit, external software must create an audit log of TPM commands that are executed by the TPM. The TPM incorporates a summary of each audited TPM command into a PCR-like register called auditDigest, so that auditDigest is to normal platform configuration registers (PCRs) what the audit log is to the clear-text measurement log (see Chapters 6 and 12).

The weaknesses of the existing audit commands are that the values incorporated into auditDigest do not include the parameters of the audited TPM commands, and that auditDigest is discontinuous between boot cycles. It is also to be noted that TCPA v1.1 does not consider the auditing status of a TPM capability to be private information. This may be a weakness, because a rogue could find out what TPM capabilities can be used without being audited. Future versions of the specification will not give privacy to the TPM audit commands either.

Four capabilities are currently associated with auditing a TPM:

• There is a default list of capabilities that should be audited, and those that should not, but this list can be changed by the TPM owner using TPM_SetOrdinalAuditStatus.

• TPM_GetOrdinalAuditStatus returns with the indication of whether a target capability is audited or not.

• TPM_GetAuditEvent returns an indication of the last capability to be audited, its return code, plus the value of auditDigest.

• TPM_GetAuditEventSigned provides a signed version of TPM_GetAuditEvent. Any type of signing key, including a TPM identity, can be used.

Synchronizing a Host Platform with Its TPM

A TPM provides synchronization functions for the platform to use when the platform switches on and off, goes “to sleep,” wakes up, or otherwise loses synchronization with its TPM. Synchronization functions are necessary because a host platform provides the Root of Trust for Measurement (RTM), and the Trusted platform Support Service (TSS) for its TPM.

When a platform switches on, a TPM is initialized by a combination of (electrical) signal (TPM_Init) and software command (TPM_Startup). TPM_Init is an unambiguous indication of platform reset, and TPM_Startup provides qualifying information. Ideally, both the indication and qualifying information should be provided by a single command, and perhaps that will be the case in future versions of TPs. For now, a single command would require too much change to the architecture of PC platforms, so an atomic operation is simulated by making the TPM ignore commands except for TPM_Startup after receipt of the TPM_Init signal: TPM_Startup is one of only two commands that a TPM will accept after TPM_Init (the other being TPM_GetTestResult), and the only time that TPM_Startup will execute is immediately after TPM_Init.

In the TCPA specification, TPM_Init is described as a “physical presence” capability with no parameters. It need not be reported as a TPM capability, nor must it be audited. The electrical signal indicates to the TPM that the platform is about to execute its reset vector. TPM_Init clears any and all authorization sessions, but does not reset volatile flags or PCRs, nor does it alter any loaded keys. In conventional implementations, the TPM_Init indication is expected to be provided by an (electrical) input to the TPM derived from the platform's reset signal.

TPM_Startup tells the TPM whether the boot process is a cold start (TCPA_ST_CLEAR), a warm start (TCPA_ST_STATE), or whether the TPM is not required during this boot cycle (TCPA_ST_DEACTIVATED).

• When performing a cold start, the TPM is caused to “start from scratch”: clear all PCRs and the audit digest, initialize its volatile flags, and discard any keys that are volatile or have parents that are locked to PCRs.

• After a sleep state, the TPM is caused to “carry on where it left off”: reload all PCRs, the audit digest, volatile flags, and keys with the values they had before the sleep state.

• If the platform is configured to perform a secure boot (see Chapter 6) and the RTM detects that the platform is not following the correct boot sequence, the TPM must be caused to enter the Activate-OFF state. This makes the TPM do nothing until the next boot cycle.

TPM_Startup communicates critical information about the type of TPM initialization (listed above), and must therefore be produced by a trustworthy entity, most probably the RTM (which is implicitly trusted, and is by its very nature associated with the start of the boot process). It follows that the RTM must have reliable access to non-volatile memory that indicates the reason for a boot process. In a conventional PC architecture, the trustworthiness of a TP therefore depends critically upon the protection afforded to existing mechanisms that control sleep states and the like. This is another reason why it would be preferable for the Core Root of Trust for Measurement (CRTM) to be incorporated into a TPM. Users with especially critical applications may wish to use a PCR to record that a TPM has gone though a sleep state, or even the number of sleep states, and take special precautions if a platform has been asleep.

If a platform produces a TPM_Init signal after a sleep state, the TPM_Startup command associated with that signal must tell the TPM to continue where it left off. The TPM must reload existing values of PCR, audit digest, volatile flags and keys. If the TPM does not automatically or implicitly store those values before sleep states, the TPM must be told to cache those values before entering a sleep state. The platform can cause the TPM to cache those values using the command TPM_SaveState. Only the effects of TPM_SaveState, and not its exact operation, are defined in the TCPA specification. This is because the exact details depend on the type of TPM. A TPM that always stores its variables in non-volatile memory (obviously) needs to do nothing before entering a sleep state. On the other hand, a TPM that stores most of its variables in volatile memory needs to be told to cache the current values in internal non-volatile TPM memory. Care is required in case very frequent sleep states would cause non-volatile storage to exceed its lifetime limit for number of storage events (current non-volatile memory technology tends to support a limited number of write or erase cycles).

Of course, it is possible that unexpected events can cause the platform to lose synchronization with the TPM. Then the platform should issue the command TPM_Reset, which simply clears authorization sessions, but does not reset volatile flags or PCRs, nor alter any loaded keys.

Testing a TPM

An improperly working TPM is worse than no TPM or a broken TPM, because it can lull its users into a false sense of security. Therefore, a TPM function should not be used unless it has been tested and shown to be working properly.

TPMs can automatically determine whether TPM functions are operating properly by executing self-test routines. Because a TPM function cannot be used before it is tested, self-test time affects the time before a TPM is operational. Different functional blocks obviously require different tests, however, and it is entirely possible that some TPMs can do some tests in parallel, while others cannot. So self-test capabilities could be a differentiator between different types of TPM.

A TPM does limited self-testing of functions as, and when, they are used, and can be commanded to do any self-tests that have not yet been done in this boot period. At any time, and at multiple times, a TPM can be commanded to do a full self-test. Normally, a TPM will pass its self-tests and operate as normal. If a TPM fails a self-test, however, it tries to enter a failure mode, where it returns an error code in response to all commands except TPM_GetTestResult, which returns more details of the fault. The amount and nature of the extra information depends on the TPM manufacturer. Of course, the nature and extent of the fault determines whether a given TPM can actually enter the failure mode and respond to TPM_GetTestResult. Presumably, some faults will affect critical functions, and silence the TPM altogether.

TCPA provides the choice of either testing the set of all TPM functions at once, or testing TPM functions in two subsets. The first subset includes all those TPM functions that are used during platform boot, plus (optionally) any other TPM functions that can also be tested without causing total “first subset” test time to be greater than 20 ms. The second subset contains any TPM functions that are not in the first subset. If a TPM is commanded to execute a capability that uses a function in the second subset, but the second subset has not been tested, the TPM will automatically test the second subset before executing the capability.

The TCPA specification defines the first subset both in terms of the capabilities that operate during boot, and in terms of actual functions that must be tested. In order to be fully inclusive, the specification requires the first subset to contain any TPM functions that are used by:

• TPM_SHA1Start

• TPM_SHA1Update

• TPM_SHA1Complete

• TPM_SHA1CompleteExtend

• TPM_Extend

• TPM_Startup

• TPM_ContinueSelfTest

These functions include “random number generation,” the PCRs, the integrity of the endorsement key (assuming there is one), the integrity of the micro code that implements the TPM's protected capabilities, and tamper resistance markers (if there are any).

In “full-set” mode, the TPM will automatically do all self-tests immediately after initialization. In “partial self-test” mode, the TPM will automatically do the first subset immediately after initialization, and will do the second subset either on demand or immediately before any function in the second set is used.

The non-volatile flag TCPA_PERSISTENT_FLAGS.TPMpost (TPM Power On Self Test) determines whether a TPM does a “full-set” self-test or a partial self-test after boot. If the flag is TRUE, the TPM must do all self-tests immediately after initialization. Otherwise, the TPM will automatically do the first subset of self-tests immediately after initialization. TPMpost is locked if the flag TCPA_PERSISTENT_FLAGS.TPMpostLock is set to TRUE. Presumably, TPMpost will be set and locked before delivery to the end user. The method of setting TPMpost and TPMpostLock is left to individual manufacturers.

The original reason for the TPMpost flag was the FIPS security standard [FIPS 140-2], but it now appears to be obsolete. FIPS requires a security device to fully complete all its self-tests before it can be used. It was therefore originally believed that the TPM in a FIPS TP must do a full self test before the TPM can provide hash and EXTEND functions, and the platform can boot. TPMpost was necessary to enable selection of either FIPS or non-FIPS boot.

A non-FIPS TP can do a partial self test at boot and test the second subset of TPM functions in parallel with completion of OS initialization. This enables a non-FIPS TP to boot without noticeable additional delay, and test the second subset of TPM functions when it is probable that such tests will not affect the user experience. A FIPS platform, forced to do a full TPM self test before the TPM can be used, would have a much longer boot time. It was subsequently reported, however, that a FIPS evaluation will treat the partial TPM self-test before boot and consequent use of those tested TPM functions as legitimate platform initialisation. A FIPS TPM must still complete a full self test before it is used in the OS environment, so some TPM functions will be tested twice in a FIPS platform. The net effect, however, is that both FIPS and non-FIPS TPs should be able to boot without noticable additional delay, and TPMpost in its present form appears obsolete.

These specific TPM capabilities are used for self-test:

• TPM_CertifySelfTest. This provides signed evidence that a TPM has actually passed its self-tests. TPM_CertifySelfTest is the response part of a challenge/response protocol, and returns a signature over the string “Test Passed,” and a nonce that was submitted by a challenger. The signature can be done with any type of signing key, including a TPM identity key.

• TPM_ContinueSelfTest. This causes a TPM to test all TPM functions that have not been tested since boot. It is useful only during “partial self-test” mode, to force a TPM to do the second subset of tests. The TCPA specification does not indicate that the capability returns an error code if it is executed more than once per boot cycle. Presumably, therefore, it will always execute when called, but actually do real work only during the first call after TPM_Startup.

• TPM_SelfTestFull. This causes a TPM to tests all TPM functions and may take a noticeable time (a few hundred milliseconds) to complete.

• If there is a fault, TPM_GetTestResult returns extra information about the fault.

Upgrading a TPM in situ

The TCPA specification contains a definition of the security properties that any mechanism must have if it is used to upgrade a TPM in a platform in situ. The actual details of the upgrade process (TPM_FieldUpgrade) are left to individual manufacturers and it is entirely optional, so not every TPM will have it.

In fact, it may be that no first generation TPM will include TPM_FieldUpgrade. TPM_FieldUpgrade has the drawback that it necessarily must contain authorization from the TPM manufacturer. Manufacturers will presumably to be reluctant to store different authentication information in individual TPMs because of the huge organizational complexity involved, leaving the obvious choice of having a single private key that signs TPM_FieldUpgrade commands to all TPMs. That private key enables a “back-door” into all TPMs made by that manufacturer, and immediately becomes a magnet for any attacker. This vulnerability is not insurmountable—consider the similar situation affecting the private keys used in a public key infrastructure (PKI), for example—but may be sufficient incentive to discourage adoption of TPM_FieldUpgrade.

Manufacturers may also be reluctant to provide TPM_FieldUpgrade simply because TPM_FieldUpgrade is optional, and the market for TPs is unproven. TPM prices may need to be increased to pay for the support costs of any TPM_FieldUpgrade, and unless every manufacturer provides TPM_FieldUpgrade, such an increase might price the TPM out of the OEM market.

Be that as it may, if TPM_FieldUpgrade is provided, it must have the security and privacy properties described in the TCPA specification.

• Any command must be able to prove:

  - That it came from the TPM manufacturer (strictly, from the entity that signed the TPM's endorsement certificate), because otherwise the endorsement certificate might be rendered invalid.

  - That it has been approved by the TPM owner, because the TPM owner controls the TPM and should have the right of veto.

• Any TPM must be able to check that the command was intended for it, and not for another TPM.

• The cryptographic protection of the command must be good enough to discourage cryptanalysis during the lifetime of the information protected by a given type of TPM. Otherwise, any information protected by such TPMs is suspect. The action of the command must not touch private information that belongs to the TPM owner, or the owner of any key or data. The command must not require a TPM to hold a global secret, because global secrets are an attractive prize for any attacker. The command must not require a TPM to hold a unique identifier, because that might violate the privacy of the TPM owner and TPM users.

Calculating Integrity Metrics

The TPM exports a set of (SHA-1) hash functions to its host platform, primarily for use in calculating integrity metrics. These functions are necessary to reduce costs in a TP built around a Personal Computer.

A TPM already has hash functionality (because it uses digests for signatures and authorization). The export of that hash functionality increases the cost of a TPM and contradicts the TCPA philosophy that a TPM should be used for just the tasks that must be trusted, but there is a reason: a trusted PC must compute integrity digests during the early stages of PC platform boot (see Chapter 6), but the host CPU only has access to limited memory to execute instructions, which degrades performance. The required hash algorithm instructions could (of course) be put into firmware, but execution in the very early stages of a PC boot process would still be slow. It is therefore impractical for a PC to execute hash instructions on the host CPU during the early stages of platform boot. So a TPM exports its hash functions to the host.

A TPM is therefore required to provide a set of general-purpose hash capabilities. It also provides a specialist capability that concatenates hashing with incorporation of the resultant digest into a PCR:

• The capabilities TPM_SHA1Start and TPM_SHA1Update provide the means to start and continue feeding data into a normal SHA-1 hash process, but not the means to finish that process.

• The capability TPM_SHA1Complete provides the means to finish a normal SHA-1 hash process and return the resultant digest to the caller. It might be used during secure boot, for example, when calculated integrity metrics (digests) are compared with preloaded integrity metrics, either in a table or in the TPM's Data Integrity Register (DIR).

• If TPM_SHA1CompleteExtend is used instead of TPM_SHA1Complete, an SHA-1 hash process is finished and the resultant digest is incorporated into a PCR. This is (obviously) useful during normal TP operation, which requires calculation of integrity metrics (digests) and their incorporation into PCRs.

Connecting a TPM to Another Processor

TCPA provides a basic mechanism to permit a TPM to communicate in private with an intimately connected security processor.

An arbitrary processing environment cannot have direct access to the secrets inside a TPM, for obvious reasons. Even an arbitrary secure processor (such as a bulk encryption engine) cannot have access. TPs are designed for the lay public, and laymen are best advised to use security devices (such as the TPM) whose specification is in the public domain. Then the public can rely on the security and cryptographic community to act as proxies and assess those devices for them. An arbitrary secure processor may be perfectly safe, but unless its workings are in the public domain, how will the lay public know that it would properly respect a TPM's secrets? The TCPA specification therefore requires that even security processors be denied access to TPM secrets.

Even so, if a TPM is associated with another secure processor, it is advantageous to be able to share private data with that other processor. The other processor cannot have direct access to a TPM's secrets, but if the other processor is intimately connected to the TPM, it should be possible to redirect some TPM output to the other secure processor, without exposing that output to the main platform environment.

The TCPA specification provides a basic redirection mechanism for such purposes. If a TPM key is “redirected,” data resulting from a cryptographic operation performed by a TPM capability using that TPM key's private portion will be returned to an alternative TPM output, different from the standard TPM output. That alternative output could be an associated secure processor in intimate contact with the TPM, or connected to the TPM by secure means. Of course, redirection only makes sense if data is being returned to the caller instead of being used by the TPM. So redirection applies only when the private portion of a “redirected” TPM key is used by a TPM capability.

Using the TPM's redirection facility requires TPM keys to have been explicitly dedicated for redirection at creation, plus a capability (TPM_SetRedirection) that selects an alternative output. The capability TPM_SetRedirection sets the current alternative output by setting two TPM-manufacturer-defined parameters. Presumably, one parameter identifies a TPM output and the other configures that output.

To enable use with redirected outputs, TPM keys include a flag named TCPA_KEY_FLAGS.redirection that must be set when a TPM key is created. When the flag is FALSE, the result of a capability involving that key is used normally. When this flag is TRUE, the result of a capability involving that key must be passed to the current alternative output (not the normal TPM output) and must not be interpreted by the TPM. Only identity keys (TPM_KEY_IDENTITY) and “asymmetric authorization change” keys (TPM_KEY_AUTHCHANGE) can never be redirected, because they never return arbitrary data to a caller. Using redirected TPM bind keys (TPM_KEY_BIND), TPM legacy keys (TPM_KEY_LEGACY), and TPM signing keys (TPM_KEY_SIGNING), is straightforward, because such keys are only ever used to return data to the caller. Redirected TPM storage keys (TPM_KEY_STORAGE) can be used only for sealing data, because any unwrapped key would not be available to the TPM.

TPM_SetRedirection is an optional capability, and the same arguments that apply to TPM_FieldUpgrade (earlier in this chapter) also apply to TPM_SetRedirection. It may be that no first generation TPMs will support redirection.

Certifying Keys Hosted by a Trusted Platform

A TPM can sign a data structure that describes the properties of a key in its TP. We call such a signed data structure a TPM issued “certificate.” Such a certificate can be sent to a third party (to convince them to trust that key for some purpose), or can be used for audit purposes.

These certificates were originally devised by TCPA exclusively for the purpose of certifying that a non-migratable key belonged to a particular TPM. Those certificates were signed using TPM identities, because TPM identities can prove that they belong to a genuine TPM without proving that they belong to a specific TPM. Later, it was realized that any signing key could be used to sign a certificate, providing the recipient of the certificate trusts that signing key. It was also realized that migratable keys could be certified, provided that the recipient of the certificate trusts the owner of those migratable keys. The job of TPM identities is still to prove that data originated in a TPM however, so TCPA is still reluctant to use TPM identities to certify migratable keys. (Data that originated outside the TPM, and that is signed by a TPM identity, just might be used to forge a data structure that is otherwise generated exclusively by a TPM. It is better to fail-safe and refuse to use a TPM identity to sign such data.) The current situation is, therefore, that TPM signature and TPM legacy keys are permitted to sign any certificate, but that TPM identities are permitted to sign only certificates for non-migratable TPM keys.

Two TPM capabilities produce TPM key certificates. TPM_CertifyKey will produce a certificate for any TPM key loaded into the TPM. TPM_ChangeAuthAsymStart (see Chapter 4) produces a certificate to provide proof that a temporary TPM key really is a TPM_KEY_AUTHCHANGE key. The certificate is intended to be part of the response phase of a challenge/response protocol initiated by a third party (whether a person, organization or software component), and includes a nonce that should be provided by that third party. Apart from the nonce, the certificate contains a public description of a loaded TPM key, comprising:

• A digest of the public portion of this TPM key. The third party should, of course, compute a digest of the public key in question and verify that it matches this value. This proves that the certificate describes this specific public key, and not some other key.

• The version of the TCPA specification that defined the capability that produced the certificate, plus the version of the TPM that produced the certificate. This information enables a recipient to check whether the certificate should be believed. If it was produced according to a flawed version of the specification, or produced by a flawed version of a TPM, the recipient might choose to disbelieve the certificate, depending on the flaw.

• The ways in which the TPM can use this TPM key, defined in terms of the type of the key (authchange, bind, identity, legacy, signing, storage). This information enables a recipient to check whether this TPM key is suitable for the intended purpose. For example, the recipient of a certificate may use it to check that a given TPM key used in a specific application context is not a TPM legacy key because of the increased risk when a key is used for both signing and encryption. (See Chapter 7 for a description of most types of keys.)

• Whether this key is migratable, or can be used for redirection, or is volatile. Almost certainly, the most important of these properties is whether the key is migratable.

  - If migratable is FALSE, the key is guaranteed to exist in exactly one TP, and possession of the key has real significance: the key is properly protected, and is a precise form of proof or identification.

  - If migratable is TRUE, the key's owner can duplicate it at will, and even install it in platforms that are not TPs. If a third party trusts the owner of a migratable key to be sensible when duplicating his or her keys, the third party can believe that possession of the key has significance. Otherwise the third party cannot.

  - The volatile flag indicates whether the key can be automatically reloaded after TPM initialization. This flag is important to a cautious third party who wants a hard limit on the lifetime of the key in a TPM, perhaps because of concerns that a temporary authorization session might linger more than strictly necessary (for example). If this flag is TRUE, the key is guaranteed to flush from the TPM when the TPM is rebooted. If this flag is FALSE, removal of the key from the TPM is dependent on correct operation of ordinary software that controls the TPM.

  - As discussed earlier in this chapter, redirection simply means that data produced when using the key is sent to an alternate TPM output, rather than returned to the caller. Normally, the “redirection” flag will always be FALSE, indicating that output data will be returned to the caller.

• The circumstances in which authorization must be proven before this TPM key can be used. In the current TCPA specification, there are only two choices: authorization must always be proven, or authorization must never be proven. Presumably, most third parties that use these certificates will want authorization to always be required before a TPM key can be used. Otherwise, there is no control over use of the TPM key. Of course, neither of these options tells a third party anything about the quality of the authentication process that produced the authorization information, nor whether the authorization information is a well-known value (see Chapter 4).

• A data structure that summarizes those Platform Configuration Registers to which this key is locked. The third party can use this information to determine the platform software state that must exist before the TPM will use the key. A full interpretation requires additional information (outside the certificate) that describes the software and integrity metrics that produce those precise PCR values. (See Chapters 6 and 12 for more details on PCRs.) Checking this information is an automated process, but interpreting the information can be complicated. In many cases, therefore, the owner of the TPM key will simply provide the third party with an additional statement saying, “I guarantee that such-and-such PCRs mean that the TP is a safe environment for your intended purpose.” Then, the third party need simply check that the PCR values in that statement are the same as the PCR values in the certificate. (See a more detailed discussion in Chapter 12.)

• Other parameters describe the cryptographic properties of this key (in terms of the basic algorithm, its encryption schemes and signature schemes, size of key, and so on). The third party using this certificate should verify that the cryptographic strength of the key is acceptable for the intended purpose.

Removing an Owner from a TPM

The range of methods for removing a TPM owner from a TPM depends on choices made by the platform designers. The design space is over-constrained, so all that the TCPA primitives can do is permit specific platforms to be customized. At one extreme, if the current owner of a TPM is permanently inaccessible, or if the owner cannot give permission (because he or she has forgotten his or her authorization data, for example), it must be possible to remove the owner from a TPM without his or her permission. At the other extreme, only the TPM owner should be able to remove him or herself from the TPM.

TCPA gives the TPM owner the choice of retaining the privilege to remove him or herself from the TPM, or giving up that privilege. If the owner retains the privilege and wants to relinquish ownership of the TPM, the owner simply executes the TPM owner authorized command TPM_OwnerClear. It is not obvious why a TPM owner would want to give up that right, but if the owner does, he or she simply executes the TPM owner authorized command TPM_DisableOwnerClear. Then the owner can never use TPM_OwnerClear, and must rely entirely upon facilities chosen by the platform designers, which don't require TPM owner authorization.

The platform designer has the more difficult job of deciding whether to permit removal of a TPM owner without the owner's permission, and (if so) how to implement it. TPM_ForceClear is a “physical presence” capability that deletes the TPM owner, provided that the unauthorized capability TPM_DisableForceClear has not been used in the current boot cycle. This simple pair of capabilities enables a large variety of implementations, with different properties. The choice is a compromise between convenience, cost, and resistance to Denial-Of-Service (DoS) attack.

• If TPM_ForceClear is totally independent of software processes, it is impossible for rogue software to remove the TPM owner, but the platform is probably more expensive (more hardware) and/or less convenient (perhaps the platform's case must be opened to operate the control).

• If TPM_ForceClear is dependent on software processes, it is potentially vulnerable to local or remote subversion to some extent or another, depending on the method of implementation, but is probably cheaper to implement and more convenient to use.

• If it is necessary to retain the option of using TPM_ForceClear, but a DoS attack using that command is a major concern, the platform designer can obstruct attackers by forcing the platform to execute TPM_DisableForceClear as early as possible in the boot process (perhaps during BIOS execution in a PC). The drawback is that if it ever becomes necessary to remove the TPM owner without his or her permission, the boot process must first be changed so TPM_DisableForceClear is not submitted to the TPM. This probably involves considerable inconvenience.

In the situation where a DoS attack must be prevented at all costs, the platform must be designed without a TPM_ForceClear capability. In this situation, the TPM owner must always retain the privilege to remove him or herself from the TPM with TPM_OwnerClear, must never execute TPM_DisableOwnerClear, and must never lose his or her authorization information.

In a normal TP PC, the most likely implementation will permit a user to execute TPM_ForceClear during POST, and always execute TPM_DisableForceClear at the end of the POST period. Then, a local user can still remove the owner, but only by manipulating the platform's BIOS configuration. This method provides a good level of protection against remote DoS attack, and minimizes the cost of a platform.