TPM 2.0 has an ephemeral hierarchy called the NULL hierarchy, which is also referenced by a permanent handle: TPM_RH_NULL (0x40000007). This hierarchy is utilized when the TPM is being used as a cryptographic coprocessor, as described in Chapter 9. Its authorization value and policy are both always NULL.
Similar to the persistent hierarchies, the ephemeral hierarchy is permanent. It can't be deleted. However, unlike the persistent hierarchies, it's automatically cleared every time the TPM goes through a power cycle. See Chapter 9 for details.
Dictionary Attack Lockout Reset
Similar to the hierarchies is the dictionary attack lockout mechanism, which has the handle TPM_RH_LOCKOUT (0x4000000A). It also has both an authorization and a policy. Like the three persistent hierarchies, these authorizations can be changed at the will of the administrator of this hierarchy. It has no key or object hierarchy. Instead, this
mechanism is used to reset the dictionary attack lockout mechanism if it has triggered, or to clear the TPM_RH_OWNER hierarchy. It generally represents the IT administrator of the TPM storage hierarchy.
a tpM is configured to lock out a user for 24 hours after 5 password entry failures. Lock out means the user can't successfully authorize any entity that is ubject to this dictionary attack protection. the user convinces an it administrator this this wasn't an attack but rather was just a mistake. the administrator, using lockout authorization, resets the failure count so the user doesn't have to wait for the 24 our lockout period to expire.
Platform Configuration Registers (PCRs)
The TPM has a number of PCRs, which are accessed using their index. Depending on the platform-specific specification, they can have one or more algorithms. They also have an authentication value and a policy, chosen by the specification (generally NULL), which may be used to change the value stored in the PCR via a PCR extend. Reading the value stored in a PCR doesn't require authentication. The PC Client platform specifies a minimum of 24 PCRs. Only one bank (a set of PCRs with the same hash algorithm) is mandatory, programmable to either SHA-1 or SHA-256 at boot time.
Because it's a permanent entity, there is no command to create or delete a PCR; you can only change its attributes or the PCR value. Chapter 12 discusses these permanent entities in detail.
Vendor-specific reserved handles may be present in a TPM if a platform-specific specification decides to use them. Such handles are meant to be used by a vendor in the case of a catastrophic security failure of the firmware in the TPM, allowing the TPM to testify to the hash of the software stored in the TPM. At the date of this writing, no reserved handles are specified by any platform specification.
Password Authorization Session
There is one session that is permanent as well, called a password authorization session at handle TPM_RS_PW (0x40000009). A caller uses this handle for plaintext password (as opposed to HMAC) authorization.
Platform NV Enable
The TPM_RH_PLATFORM_NV handle (0x4000000D) controls the platform hierarchy NV enable. When it's clear (disabled), access to any NV index in the platform hierarchy is denied.
NV indexes can belong to either the platform or the storage hierarchy. The storage hierarchy enable controls NV indexes in the storage hierarchy. However, the platform enable doesn't control platform hierarchy NV indexes. That uses is a separate control: platform NV enable. Having two controls permits independent control of the platform hierarchy (for example, keys) and these platform NV indexes platform firmware can use the tpM as a convenient nV space for boot parameters. this space must remain readable even if the tpM platform hierarchy is disabled.
Next let's examine some entities that are similar to permanent entities: nonvolatile indexes, which are nonvolatile but not architecturally defined.