A persistent entity is an object that the owner of a hierarchy has asked to remain resident in the TPM through power cycles. It differs from a permanent entity (which can never be deleted) in that the owner of the hierarchy to which a permanent entity belongs can evict it. A TPM has a limited amount of persistent memory, so you should be sparing in your use of persistent entities. There are, however, some valuable use cases.
a signing key is needed for Vpn access early in a boot cycle. at that time, the disk isn't available. the application transfers the key to tpM persistent storage, where it's immediately available for use in early boot cryptographic operations.
a primary storage key (the equivalent to a tpM 1.2 srK) is routinely used as the root of a key hierarchy. Key generation is often the most time-consuming cryptographic calculation. after creation, the key is moved to persistent storage to avoid the performance penalty of recalculating the key on every boot cycle.
an enterprise provisions a motherboard with a restricted signing key that is fixed to the tpM. the enterprise uses this key to identify the platform. if the motherboard fails and the tpM is thus replaced, this existing key can no longer be loaded. the it
department wishes to provision spare motherboards with new signing keys. Because a motherboard has no disk, the it department generates the key and moves it to tpM persistent storage. the signing key now travels with the motherboard when it replaces a failed one in a platform.
Usually, primary storage keys (such as an SRK), primary restricted signing keys (such as an attestation identity key [AIK]), and possibly endorsement keys (EK) are the only entities that remain persistent in a TPM. These are discussed in more detail in Chapter 10.
The Name of an entity is a TPM 2.0 concept, invented to solve a problem noticed with the TPM 1.2 specification. A paranoid security analyst (and all security analysts are paranoid) noticed that it might be possible for an attacker to intercept data as it was being sent to the TPM. The TPM design had protections against such an attack changing most data that was sent to the TPM. However, the TPM has very few resources, so it allowed a key manager to load and unload keys into the TPM as necessary. After keys were loaded, they were referred to by a handle, a shorthand for the location in memory where the key was loaded. Because the software might not realize that a key manager had been relocating keys in the TPM to free up space, the handle itself wasn't protected against manipulation, and middleware would patch the data that was sent to the TPM to point to the correct handle location.
Normally this wouldn't be a problem. But if someone decided to give the same password to more than one key, then it would be possible for one of those keys to be substituted for another by an attacker, and the attacker could then authorize the wrong key to be used in a command. You might think such an attack would be unlikely, but the people who wrote the TPM specification also tend to be paranoid and decided this was unacceptable behavior. Instead of just warning everyone not to use the same password for multiple keys, they decided to give every entity a unique Name, and that Name is used in the HMAC authorization calculation sent when executing a command that uses that entity. The handle may change, but the name doesn't.
The command parameter stream that is hashed and then HMACed implicitly includes the Name of each entity referred to by handle, even though the command parameters may not include the Name. An attacker can change the handle but can't change the corresponding Name value after it's authorized through the HMAC calculation.
The Name is the entity's unique identifier. Permanent entities (PCRs and hierarchy handles) have handles that never change, so their Name is simply their handle. Other entities (NV indexes and loaded objects) have a calculated name that is essentially a hash of the entity's public data. Both the TPM and caller independently calculate the Name value for use during authorization.
For security, it's extremely important that the Name is calculated and stored when the entity is created. A naïve implementation might offer to help by providing a “handle to Name” function that reads the TPM handle and uses the resulting public area to generate the Name. This would defeat the entire purpose of using the Name in the HMAC calculation, because the result is the Name of the entity currently at the handle, not the Name the authorizer expected.
Following are some examples of how the Name is used.
a key owner uses an nV bit-field index in the key's policy, with a set bit 3 revoking the key for a key user. the revoked user / attacker deletes the nV index and re-creates it with the same policy. When the key owner wants to set bit 5, they use the handle-to-name function to calculate the name. the key owner uses the result for authorization, and sets bit 5. however, bit 3 is now clear because the tpM initializes bit fields to all bits clear.
if the key owner had properly stored the name and used it for authorization, the authorization would fail. this would happen because, when the attacker re-created the index, the “written” bit in the public area attributes would go from set to clear, changing the name on the tpM.
The Name of an NV index is a digest of its public area. An attacker can delete and redefine an index, but unless the public area (the index value, its attributes, and its policy) is the same, the Name will change and the authorization will not verify.
the user defines an ordinary index intended to hold a secret. the index policy is such that only the user can read the secret. Before the secret is written, an attacker deletes the index and redefines it with a different policy, such that the attacker can also read the secret. the attack fails because the policy change causes the name to change. When the user tries to write the secret, the authorization fails because the original name was used to calculate the command parameter hash.
The Name of a transient or persistent entity is also a digest of its public area.
The public area varies with the type of entity.
the user loads a key and receives back a handle for the loaded key. the user authorizes the key with an hMaC of the command parameters, which implicitly includes the name. Unknown to the user, a resource manager had unloaded the key, and now loads it. Keep in mind, however, that the handle changes. the resource manager replaces the user's handle with the new handle value. the authorization still verifies, because the calculation didn't include the handle (which changed), only the name (which didn't).
the user loads a key and receives a handle. the user authorizes that key with an hMaC. however, an attacker replaces the key on the tpM with their own key, and the attacker's key has the same handle. the attack fails because the attacker's key has a different name, so the hMaC authorization fails.
The TPM has several types of entities: items that can be referred to by a handle. Permanent entities have a handle that is fixed by the TPM specification. The handle value can't change; nor can such an entity be created or deleted. Its data can be either persistent or volatile. Nonvolatile indexes can be created or deleted at a user-specified handle, and they persist through TPM power cycles. Objects — entities that are attached to a hierarchy — may have a private area and can be volatile or made persistent. When the object is made persistent, it's called a persistent entity.
An entity's Name is its unique identifier. It's used in authorization calculations rather than the entity's handle because the handle may change over time as a resource manager loads and flushes entities.
This chapter has summarized the entity types and provides a road map to the chapters that follow. The details come next, with chapters on hierarchies (permanent entities), keys (objects), NV indexes (persistent entities), PCRs (permanent entities), and sessions (nonpersistent entities).