Concept of Protected Storage

The Protected Storage mechanism can protect both arbitrary data and keys. Arbitrary data is revealed by the TPM to a caller, whereas a TPM uses keys internally and never exports them. These are the main points of interest for users:

• Protected Storage allows private signature keys to be stored in a way that the TPM can use them without exposing them to the host platform. An appropriately designed TPM should be able to meet the European directive on digital signing.

• Bulk encryption keys or arbitrary authorization data can be stored in a way that requires cooperation of the TPM to reveal them to the host platform.

• Protected data can be stored in a way that either permits duplication of the data by TCPA features (under control of the owner of the data) or prevents duplication of the data by TCPA features.

• Protected data can be stored in a way that prevents use of the data unless the platform is in an expected state.

Other aspects of Protected Storage are simply the “means to an end” and mostly are of interest to the system designer who determines the features available to a user. The treatment of keys is more complicated than that of arbitrary data, because keys are used to protect both other keys and arbitrary data.

Cryptographic Protection

The TPM uses cryptographic functions to ensure that the TPM protected objects created by Protected Storage have the necessary properties of confidentiality and integrity. The cryptographic capabilities themselves are discussed in more detail in Chapter 9; here, we simply use them.

The first requirement is to provide confidentiality of TPM protected objects (in order to make them “opaque”). We mentioned in Chapter 2 that TCPA Protected Storage uses asymmetric cryptography, rather than symmetric cryptography. There are two reasons for this. The first is that asymmetric cryptography is already required to implement TPM identities. Using asymmetric cryptography for Protected Storage, therefore, reuses an existing functional block and minimizes the cost of a TPM. The second is that some plain text originates outside the TPM, and asymmetric cryptography permits encryption of that data outside the TPM without revealing the decryption secret. This may improve overall platform throughput because the TPM becomes less of a bottleneck. It also permits encryption to be done in another, perhaps safer, platform. (There is, of course, no security justification for encryption inside the TPM if the plain text data is already known to the entity doing the encryption and the encryption key is not secret.) The obvious drawbacks of using asymmetric cryptography, instead of symmetric cryptography, are the longer times to generate keys and perform encryption/decryption operations. A less obvious drawback is that the size of data in a TPM protected object is limited by the size of the asymmetric key used to encrypt it. Due to the mathematical operation at the heart of the encryption process, the size of an object that can be encrypted as a single block can't be bigger than the size of the encrypting key; it might even need to be smaller if it is necessary to format data before encryption to prevent attacks on keys. So the amount of data protected in a TPM protected object is limited. It is possible, of course, to chain individual blocks and store larger amounts of data distributed across blocks, but this has its own drawbacks: Efficiency is reduced by the extra data that is needed inside blocks to link them together, and extra time is needed to process the extra blocks. TCPA decided, therefore, to make all Protected Storage structures fit in a single block. It will be seen later in this chapter that this caused a particular style of Protected Storage data structures and operations.

The second requirement is to check integrity (detection, but not correction, of inappropriate alterations) of data objects. Integrity checks normally are done by verifying the self-consistency of data. It happens, however, that Protected Storage already has an implicit consistency check for decrypted data in the form of the authorization check. A TPM protected object already includes encrypted authorization data, to “compare” with the authorization data that is submitted to the TPM to prove sufficient privilege to use the TPM object. The probability of an authorization match after decryption of a corrupt TPM protected object is tiny, because authorization data is the size of an SHA-1 digest [ISO/IEC 10118]. It follows that an authorization match is an implicit and sufficient integrity test of a decrypted TPM object, and hence no explicit integrity mechanism is required.

Although no explicit integrity check is required for the TPM protected object, an integrity check is required for any associated plain text data. As will be discussed later, TPM protected objects are associated with plain text data; TPM protected key objects are associated with the public portion of that key and other descriptive information; and TPM protected data objects are associated with descriptive data. In order to enable an integrity test of plain text data associated with a TPM protected object, TPM protected objects contain a digest of the associated plain text data. If authorization for the TPM protected object is correct, the “plain text integrity digest” must be correct and can be used to verify the integrity of the plain text data.

A further integrity check, of sorts, is to verify that a plain text public key actually corresponds to a private key inside a TPM protected key object. This is pointless when dealing with non-migratable TPM keys, because these are always created on a trustworthy TPM: The “plain text integrity digest” check guarantees correspondence. It is necessary, however, when dealing with migratable keys, because the TPM could otherwise be fooled into using or certifying the wrong public key. (See Chapter 9 for details on TPM key certification.) Therefore, TCPA specifies that some sort of test must be done when dealing with migratable keys. A precise mathematical relationship exists between a private key and a public key, and the TCPA specification requires use of that relationship to verify the public-private key relationship. It is, of course, possible to do an encrypt/decrypt cycle and verify that the output data is the same as the input data. This is perfectly acceptable, but it's rather slow. For RSA keys, TCPA requires only that the modulus and one of the primes is held in the TPM protected key object (see “Asymmetric keys” later in this chapter) and recommends that, upon loading of such a key, the TPM should divide the supposed RSA modulus by the supposed RSA prime and check that there is no remainder. We recommend that the TPM also check that the result of that division is a prime number.

Migratable and Non-Migratable

As previously explained, migratable TPM objects (whether they are TPM key objects or TPM data objects) can potentially be replicated ad infinitum by its owner. The extent of duplication of migratable TPM objects is known only to the owner of that TPM object, so only entities that trust the TPM-object owner (a TPM-object owner is the entity that owns the usage authorization data for this particular TPM object) can trust the relationship of migratable TPM objects to a given TPM. Non-migratable TPM objects, in contrast, are locked to an individual TPM and never duplicated. (It can, however, be moved to another platform with the cooperation of the platform OEM or his agent. Detailed mechanisms to do this will be introduced in Chapter 9.) As a result, migratable TPM key objects are permitted to be created outside the TPM and merely protected by the TPM, or they can be created by the TPM. Non-migratable keys must be created by the TPM.

The essential architectural difference between migratable and non-migratable TPM keys is the source of their migration authorization information: The owner of a migratable TPM key creates the migration authorization information for that key, but the migration authorization information for non-migratable TPM keys is a secret known only to the TPM. Because TPM keys never leave a TPM as plain text and non-migratable TPM keys are created inside a TPM, this non-migratable migration authorization secret (called tpmProof) is sufficient to prevent use of a non-migratable TPM key except in the TPM that created it. A rogue cannot create bogus TPM objects that purport to be non-migratable, because the rogue does not know tpmProof.

The TPM itself has no use for arbitrary data, and it never creates any. In the strictest sense, therefore, TPM data objects are always migratable because they are always generated outside a TPM and used outside a TPM: TPM data objects can always be duplicated and revealed at the whim of their creator or by anyone who can capture that data after it has been revealed by a TPM. Arbitrary data can, however, in some senses, be considered non-migratable if its owner creates just one copy of the data and wraps it using a non-migratable key. The owner can still duplicate the plain text data, but using a TPM to wrap it with a non-migratable key prevents TCPA mechanisms from being used to duplicate that arbitrary data.

Object Hierarchy

A TPM object (whether a key or arbitrary data) stored outside a TPM is rendered as a TPM protected object, which can be stored anywhere it will not be lost or corrupted. The TPM protected object includes various secret attributes of the key or data it is protecting, and it is associated with various non-secret attributes that are stored as plain text. (These will be discussed later in this chapter.) Each TPM protected object is encrypted (also described as “wrapped” by the TCPA specification) by an encryption key. Usually that encryption key is itself stored outside the TPM as another TPM protected key object. It follows that the set of TPM protected objects form a tree, with each child TPM protected object wrapped by the encryption key in the parent TPM protected object. Only the encryption key at the root of the tree is actually stored permanently inside the TPM. The root, called a storage root key (SRK), is generated inside the TPM when the TPM owner takes ownership of the TPM, and is non-migratable.

Intermediate TPM object nodes in the tree contain encryption keys (referred to as storage keys) that are used to decrypt child nodes. It is a poor security practice to use the same key for both signing and encryption, so a TPM will refuse to use a signature key as a storage key, and vice versa. This means that a storage key could occur anywhere in the tree hierarchy, but a signature key will always be a leaf key. A TPM must also refuse to use a migratable storage key as the parent of a non-migratable TPM object. (This would otherwise enable migration of the supposedly non-migratable object.) On the other hand, a non-migratable node could be the parent of a migratable node, with no ill effects.

Arbitrary data must, of course, be held in a leaf TPM object node because the TPM never uses arbitrary data as a key (even though it could actually be a key used by the host's CPU, for example).

The time taken by a TPM to access the contents of a particular TPM protected object node obviously depends on its position in the tree relative to the root. Only the SRK is permanently available, because it is permanently stored as plain text inside the TPM. To obtain the contents of some arbitrary target TPM protected object, it is first necessary for management software outside the TPM to identify the path from the SRK to the target TPM object. Then the SRK is “loaded” into the TPM and used to decrypt the child TPM key object that is next in the path to the target. Next, the key from that child is used to decrypt the child TPM key object that is the next in the path to the target TPM object. And so the process continues. Ultimately, the target TPM object is unwrapped by the TPM and ready for use. If the TPM object is a key, it can be used to wrap a newly created key, unwrap another TPM object, or sign data (depending on the type of key). If the TPM object is arbitrary data (i.e., not a key as far as the TPM is concerned), the TPM exports the arbitrary data to the caller.

To ameliorate this delay in accessing a node, a TPM optionally has two “key session” capabilities. One of these (TPM_SaveKeyContext) causes the TPM to create an ephemeral TPM protected object that protects the plain text contents of a loaded TPM key object, and enables caching of those contents outside the TPM. These caches are encrypted using temporary keys known only to the TPM performing the cache, so that they can be used only by that individual TPM. Such temporary caching keys are discarded by the TPM when the platform reboots. Consequently, a cached “key session” can only be reloaded to its TPM during the same boot cycle during which it was cached. The second capability (TPM_LoadKeyContext) imports the ephemeral object back into the TPM and recovers the plain text contents. This means that while the first time to access the contents of a TPM key object is variable and may be relatively lengthy, subsequent times within the same boot cycle should be uniform and short. (Chapter 9 discusses the notion of platform reboot and associated TPM operations.)

A protected TPM object can also be bound to a sequence of integrity metrics, and hence it is bound to a particular computing environment within a platform. This is described later in this chapter.

Complications Caused by Algorithm Versions and Legacy Applications

Theoretically, only two types of keys (encryption and signing) are required. An encryption key should be permitted to use just encryption algorithms, and a signature key should be permitted to use just signature algorithms. Unfortunately, reality is much more complicated. The complexity arises from four complications:

TCPA aspires to use “best practice,” so it forces the use of RSAES-OAEP for wrapping of TPM key objects and TPM data objects using advanced TCPA properties (e.g., associating PCR values to TPM objects, using TPM authorization data, etc.). This is possible because no existing applications use TCPA properties.

Relatively few existing applications use RSAES-OAEP because it is a recently specified encryption scheme. Hence, it is reasonable to require applications using RSAES-OAEP with Protected Storage to have some awareness of TCPA. However, applications should not be forced to use the new range of TCPA properties and may wish to simply store and retrieve data via Protected Storage. TCPA, therefore, provides an option with minimal formatting demands on the data when it is protected using Protected Storage, requiring only that it starts with a four-byte TCPA-version number and a single-byte bind identifier. This enables a TPM to do a simple consistency check after decryption and before revealing the plain text data to the caller, but it rules out the use of advanced TCPA properties.

Existing applications cannot be expected to know anything about Protected Storage and cannot be expected to format arbitrary data according to the TCPA specification. So TCPA provides an option with no formatting demands on the arbitrary data. The TPM acts as a straightforward encryption/decryption engine and does no checking on decrypted data other than tests inherent in the decryption algorithm.

TCPA defines the following keys:

• Storage (TPM_KEY_STORAGE) keys, for TCPA-aware applications to wrap other keys and arbitrary data that use advanced TCPA features. The TPM must use the RSAES-OAEP encryption scheme with storage keys. TCPA specifies that a TPM storage key must be as strong as 2048-bit RSA.

• Signature (TPM_KEY_SIGNING) keys, for TCPA-aware applications, just for signing arbitrary data. The TPM must use the RSASSA-PKCS1-v1_5 signature scheme with signature keys.

• Identity (TPM_KEY_IDENTITY) keys, for TCPA-aware applications, for the purpose of proving that data originated inside a genuine TPM. Note that identity keys are always children of the SRK. This is to provide the fastest possible access to identity keys, even in pre-OS environments where other Protected Storage objects may be unavailable.

• Bind (TPM_KEY_BIND) keys, for modern applications that don't want to use advanced TCPA features. Bind keys can be defined for use with either the RSAES-PKCS1-v1_5 or the RSAES-OAEP encryption schemes, but they must use a small amount of TCPA formatting in arbitrary data to enable a consistency check.

• Legacy (TPM_KEY_LEGACY) keys, for applications that want to use the same key for both encryption and signing. If the application is truly a legacy application and uses the PKCS1-v1_5 versions of the RSA encryption scheme, no TCPA formatting need be applied to arbitrary data. If the application has been upgraded to use the RSAES-OAEP version of the RSA encryption scheme, TCPA requires it to apply a small amount of TCPA formatting to arbitrary data to enable a consistency check.

The net result is that TPM signature keys can sign data, TPM identity keys can sign data that is under the control of the TPM, TPM storage keys can wrap other keys and arbitrary data in a first format, TPM bind keys can wrap arbitrary data in a second format, TPM legacy keys can wrap arbitrary data in the second format and in a third format, and legacy keys can also do signing.

A further complication is that TCPA defines two versions of the RSASSA-PKCS1-v1_5 signing scheme that can be associated with TPM keys. One permits the caller to format the data to be signed by applying Distinguished Encoding Rules (DER) [ISO/IEC 8825-1] externally (defined as the TCPA_SS_RSASSAPKCS1v15_DER method by the TCPA specification). The other TCPA RSA signing method (defined as the TCPA_SS_RSASSAPKCS1v15_SHA-1 method by the TCPA specification) requires the input data to be signed to be the result of an SHA-1 hash operation. A TPM permits the DER version to be used with the TPM_Sign command and requires the non-DER version to be used for all other commands. This is simply because TCPA specifies the use of the SHA-1 hash algorithm to be used when the TPM itself generates the hash of the data it is signing (i.e., for TPM_Quote).

These rules about keys and their algorithms are enforced by the TPM and depend on tagging of keys inside the TPM protected key objects. That data structure is briefly described later in this chapter.

Figure 7-1 illustrates an example of a Protected Storage object hierarchy (including both TPM protected key objects and TPM protected data objects). The SRK is the root of the tree and is held permanently as plain text in a shielded location inside a TPM.

Sealing and Unsealing Keys and Data

When using Protected Storage to store arbitrary data or a key, even the SRK and identity keys, it is possible to state the future software environment that must exist before a TPM will permit that data or key to be used. This adds an extra dimension to access control—the ability to state the software environment in which a secret can be used. The desired software environment is expressed as values of platform configuration registers (PCRs), which store summaries of the software state of a platform.

The process is complicated by the need to minimize the work done by a TPM and the size of data that must be stored in a TPM protected object. As a result, the TPM does just the tasks that are security sensitive, leaving the rest of the process to be done by management software on the host platform (not specified by TCPA).

Sealing is the generic name given by TCPA to the process of locking a secret to a particular software configuration, such that a TPM will not unseal that secret unless the platform is in that particular software configuration. The actual text of the TCPA specification associates the word seal with the commands dealing with arbitrary data (TPM_Seal and TPM_Unseal), but this is just historical accident. Both TPM data objects and TPM key objects can be sealed to a particular software configuration.

These are advantages of sealing data and keys:

• Directly sealing arbitrary data prevents use of that data unless the platform is in a particular software state.

• Sealing TPM signature keys and legacy keys is obviously useful—a signature can't be performed unless the platform is in a particular software state.

• Sealing TPM storage keys, TPM bind keys, and TPM legacy keys is a simple way of sealing all the child TPM objects of those keys (including arbitrary data wrapped by bind keys and legacy keys).

• Sealing TPM identity keys and the SRK is also possible, although such use is not discussed in the TCPA specification.

Sealed TPM protected objects use three special fields (the actual data structures are described later in this chapter), one of which is a bitmap selecting and deselecting individual PCRs. The other two are digests over a specified combination of the bitmap and the values of the PCRs whose indices are selected by that bitmap (the definition of this combination is the TCPA_PCR_COMPOSITE structure in the TCPA specification). One digest, called digestAtCreation, records the values of these PCRs when the TPM object is created. The other digest, called digestAtRelease, records the target values of these PCRs that have to be matched when the TPM object is used by the TPM. A list of what these PCR values represent must be stored outside the TPM, as unprotected data, by the same software that manages the Protected Storage tree. Such a list may be required by an application that wants to interpret the software state to which a TPM object is sealed or the software state when a TPM object was created. When a TPM is asked to use a TPM object that was sealed to PCRs, the TPM uses the bitmap of PCRs in the TPM object to compute a digest over the corresponding PCR indices and their current values. If this digest matches digestAtRelease, the TPM permits the TPM object to be used. Otherwise, it does not.

digestAtCreation is for use by software that needs to know that an object was created in the correct software environment. Typically, this is when the OS or an application creates data for its future use, for example. When that software comes to use the TPM protected object, it often needs to know that this object was created in the correct software environment. Otherwise, it could have been created by rogue software to spoof the current software; hence, the current software needs to check digestAtCreation.

The details of the actual process are as follows:

• When creating a TPM protected object, the management software on the host platform presents the TPM with a list of indices of the target PCRs, and a digest over both that list and the target values for these PCRs (this is digestAtRelease). The TPM calculates a real-time digest over that list and the current values of these PCRs (this is digestAtCreation). The TPM stores the list, digestAtCreation, and digestAtRelease inside the TPM object, wraps the list with the chosen parent TPM key, and returns the resulting TPM protected object to the caller. Management software on the host platform gets a list of the current PCR values from the TPM (the ones used to create digestAtCreation) and stores that list with the TPM protected object and a list of the selected target PCRs. This TPM protected object can be held in any arbitrary (untrusted) storage medium.

• When unwrapping a secret from a TPM protected data object, or to use a TPM key from a TPM protected key object, the TPM computes a digest over the list of PCRs and current PCR values. If that digest is the same as digestAtRelease in the TPM object, the TPM returns the secret or agrees to use the key. Otherwise, it does not.

• After a sealed TPM protected object has been loaded or returned by the TPM, management software can verify the software state of the platform when this TPM object was created. The fact that the TPM performs the unwrap indicates that the digestAtCreation values, as stored in clear text inside the TPM protected object, are indeed the ones that were recorded by the TPM when the object was created. The management software must then use its record of the software state at creation and associated list of PCR indices and PCR values for this TPM object. The management software computes a digest over this list of PCR indices and PCR values. If that digest is the same as digestAtCreation inside the TPM protected object that has been unwrapped, the list of PCR values accurately represent the record of the software state when the object was created. Otherwise, it does not.

The conditions for use of a sealed TPM protected object are guaranteed by the TPM: The values of PCRs when the TPM object can be used are checked by the TPM against the current PCRs, before using the TPM object.

The authenticity of the PCR values when the secret was sealed depends on what created the sealed TPM object. If it was created by the TPM, its authenticity is guaranteed. Otherwise, its authenticity could be suspect. It follows that only arbitrary data or non-migratable keys that have been sealed by the TPM are guaranteed to contain an authentic “software state at creation” field. Trust in the “software state at creation” field of a migratable key depends on trust in the owner of the individual migratable key. The issue of trust in the “software state at creation” field of arbitrary data sealed outside the TPM does not arise, because TCPA does not specify a capability to unseal TPM protected data objects that were sealed outside the TPM.

The capabilities for sealing/unsealing arbitrary data and keys are different, because of their very different nature. The differences are highlighted here:

• Arbitrary data: The capabilities TPM_Seal and TPM_Unseal are used for arbitrary data that is wrapped using a non-migratable storage key. Note, however, that the name TPM_Seal/Unseal is misleading, because it can be used both with and without PCRs. A better name might perhaps be TPM_DataWrap/Unwrap.

• Keys: The capabilities TPM_CreateWrapKey and TSS_WrapKeyToPcr both seal keys to PCRs. Actually, TPM_CreateWrapKey creates new keys on the TPM, whether or not they are sealed to PCRs. TSS_WrapKeyToPcr is not a TPM capability; it is performed outside the TPM to wrap a key for use by the TPM and to seal it to PCRs. No explicit capability for unsealing a key is necessary or possible, because an unsealing operation for a TPM key is automatically performed by the TPM when the key is used: Each time a “sealed” key is used, the TPM verifies that the software state of the platform is acceptable for use of that key.

Note that sealing and unsealing of arbitrary data is an advanced TCPA feature and is not directly available when wrapping arbitrary data using bind keys and legacy keys. Storage keys must be used. Even so, all types of key and data can be sealed, either directly or indirectly:

• All types of keys can be sealed to PCRs, or not, as required. Remember, however, that the owner of migratable keys can duplicate them at will, either as plain text data or as TPM protected objects using TCPA defined mechanisms. Care is required to ensure that PCR values in one platform have the same meaning as the same PCR values in another platform. Non-migratable keys can't be duplicated, because they are created by a TPM and known only to that TPM. Hence, there is no doubt about the meaning of their PCR values.

• Arbitrary data wrapped with a bind or legacy key doesn't contain the extra data fields needed for sealing. Sealing of such arbitrary data must be done indirectly, by sealing the actual bind or legacy key used to wrap the data or by sealing a storage key that wraps the bind or legacy key. The bind or legacy key or the storage key can be either migratable or non-migratable, as desired. If the key is migratable, trust in the digestAtCreation depends on trust in the owner of the secret, and the meaning of PCR values depends on the individual platform. If the key is non-migratable, the digestAtCreation was created by a TPM and can be trusted, and no TCPA mechanism permits duplication of the arbitrary data. So there is no doubt about the meaning of the PCR values.

• If arbitrary data is stored by a TCPA-aware application, it can be directly sealed using any non-migratable storage key. This storage key does not itself need to be sealed. The TPM protected data object containing the arbitrary data will contain its own digests. The digestAtCreation field is created by the TPM for this object, so it can be trusted. The arbitrary data cannot be duplicated using TCPA mechanisms. (If the owner wants to duplicate the data, he can use plain text data recovered from the TPM protected data object. Hence, TCPA does not bother to provide a method of sealing arbitrary data in a TCPA-defined structure to a migratable storage key.)

There is a blot on the map of the sealing landscape. The TCPA specification gives no guidance on the process of altering a TPM protected object's digestAtRelease value when the software state of a platform is intentionally and permanently altered (during an OS upgrade, for example). Currently, there is only one obvious way of altering the digestAtRelease of a sealed TPM protected data object, and that is to expose the plain text data in the current “software state at release” environment and reseal the plain text data to the new “software state at release.” Worse, there currently appears to be no way of altering the digestAtRelease value of sealed TPM protected key objects, and it is probable that new TPM keys have to be generated. It remains to be seen what the impact of this lack of elegance will be on the overall acceptance of sealing.

Authorization

Two separate types of authorization are associated with objects in Protected Storage. One proves privilege to use the contents of the object. The other proves privilege to migrate the contents of the object (assuming it is capable of migration). Two separate values are used so that an entity can create a Protected Storage object and delegate the right to use the object but can retain the right to copy (migrate) the object, for example.

The TCPA specification mandates the size of authorization data, but it is silent on the method of production and strength of that data. Absolutely any method can be used to produce and store authorization data outside the TPM: It is a question of system design and will vary from situation to situation. Presumably, the owner of the authorization data will keep it secret or (at least) private (see the privacy discussion in Chapter 1). On the other hand, the copy of authorization data that is used by a TPM is always treated as a secret and protected as such: Both authorization fields for a TPM object are stored inside the TPM protected object.

The choice of authorization data belongs entirely to the user and the system designer. TCPA specifies an authorization size that is large enough for all normal purposes, but it also enables a host platform to use any type of authentication mechanism to recognize a user or entity. Authorization data are deliberately the same size as an SHA-1 digest: 20 bytes. It follows that a platform can, if so designed, create authorization data by applying an SHA-1 hash algorithm to the output of whatever authentication process was used to recognize the user or entity. Then the particular authentication process is the overall limit on the strength of authorization. An authorization value produced by hashing a four-character password is less secure than an authorization value produced by hashing a random number from a smart card, for example. Of course, the TPM has no way of knowing whether a 20-byte authorization value actually is the result of an SHA-1 digest. It could equally well be a four-character password followed by 16 bytes of zeros, for example.

The usage authorization field is used by generic TPM authorization functions that execute the TCPA authorization mechanisms. Individual Protected Storage capabilities use that generic authorization function to determine whether the caller has proven knowledge of the appropriate authorization data to use a given TPM object. During creation of new objects, the authorization field is also used to confidentially communicate the authorization information for the new object. Even if an object has been created so that it can be used by the TPM without the need for authorization, it still needs an authorization value to provide that confidentiality for child TPM objects. As explained previously, the authorization test implicitly performs an integrity check on the plain text data recovered from a TPM protected object. System designers may wish to encourage use of well-known values of authorization data, rather than just creating an object that does not require authorization. (The authorization protocol is described in more detail in Chapter 4.)

The migration authorization field is found in TPM key objects and is used by the generic authorization functions to determine whether the caller is authorized to migrate the TPM object. (Migration is described in more detail in Chapter 8.)