Persistence of Keys
A user calls the TPM2_EvictControl command to move a key from volatile to nonvolatile memory so it can remain loaded (persist) though power cycles. No key needs to be made persistent to be used. Typically, we expect that a small number of primary keys, perhaps one per hierarchy, will be made persistent to improve performance.
Keys in the endorsement, storage, and platform hierarchies, other than primary keys, can also be made persistent. A use case would be early in a boot cycle, when a key is needed before a disk is available. Another use case is a limited-resource platform such as an embedded controller, which may not have any external persistent storage.
No keys in the NULL hierarchy can be made persistent. All are voided at reboot.  Only a limited number of keys can be persistent, but the TPM can handle an unlimited number of keys. The application does this by using the TPM as a key cache.
For keys other than primary keys, the TPM serves as a key cache. That is, the TPM2_Create command creates a key, wraps (encrypts) it with the parent, and returns the wrapped key to the caller. The caller saves the key external to the TPM, perhaps on disk. To use the key, the user must first load it into the TPM under its parent using TPM2_Load. When finished, the caller can free memory using TPM2_FlushContext.
This is different from a primary key, which has no parent and remains in the TPM after it's created.
A typical hardware TPM may have five to ten key slots: memory areas where a key can be loaded. TPM management middleware is responsible for swapping keys in and out of the cache.
If you read Chapter 13, you may notice that the key handle isn't included in the TPM parameters that are authorized. Rather, the key's Name is used. The reason is the key cache
and swapping. A platform may have a large number of application keys on disk, perhaps identified by a user's handle. There are many more of these handles than key slots. When a user asks to use a key, the command includes the user's handle. However, when the middleware loads the key, it gets a different handle, related to the TPM key slot rather than the user's handle. The middleware must thus replace the user's handle with the TPM handle. If the authorization included the user's handle, the substitution would cause an authorization failure.
You may now ask, “If the handle can be replaced, then if I have two keys with the same authorization secret, how do I know that the middleware didn't use a different key than the one I wanted?” This was indeed a potential problem in TPM 1.2.
TPM solves this problem by using the key's Name, a digest of the key's public area, in the authorization. The middleware can replace the key handle (which was not authorized) but can't replace the Name (which was authorized).
The root keys (the parents) and the key cache (the children) form a tree of keys. The TPM provides for four of these trees, each with different controlling roles. The trees are called hierarchies.
-  Chapter 9 discussed the unique properties of the NULL hierarchy.
-  Wrapping is a common design pattern for hardware security modules. The wrapping key is an encryption key, sometimes called a key encrypting key or master key. The TCG calls it a storage key. The wrapping key and the wrapped key form a parent-child relationship.