Electronics Guide

Platform Hierarchy

The Platform Hierarchy is reserved for platform firmware and supports the operations that establish the platform's security foundation. Rooted in the Platform Primary Seed, it holds firmware-owned keys and backs the non-volatile indices that firmware controls. One common misconception deserves correction: the UEFI Secure Boot key database (PK, KEK, db, and dbx) does not reside in this hierarchy. Those keys live in authenticated UEFI variables. What the TPM contributes to a measured launch is the recording of firmware measurements into PCRs, not the storage of Secure Boot keys.

The platform hierarchy's authorization is deliberately short-lived. On every TPM Reset, platformAuth and platformPolicy revert to the Empty Buffer, giving early firmware unrestricted access. Firmware then sets platformAuth to a random value and discards it from memory, and it commonly clears phEnable with TPM2_HierarchyControl before handing control to the operating system. From that point neither the operating system nor an application can exercise the platform hierarchy until the next reset, so a compromised operating system cannot reach firmware-owned objects. The arrangement permits a legitimate firmware update to re-provision the hierarchy on the following boot while denying access during normal operation.

Storage Hierarchy

The Storage Hierarchy (also called the owner hierarchy) is controlled by the operating system or platform owner and used for general-purpose key storage and cryptographic operations. Its primary key, the Storage Root Key, is the parent for most disk encryption, secure storage, and application-level keys. The storage hierarchy authorization typically persists across boots, allowing consistent access to encrypted data, and its seed is left unchanged because changing it would invalidate every long-lived key derived from it.

Applications create keys as children of the storage primary key or of other keys in the storage hierarchy, building tree structures that organize keys by function or security policy. Each key can have its own authorization requirements, usage restrictions, and policy controls. The storage hierarchy supports both signing and encryption (decryption) keys, enabling a wide range of cryptographic applications while maintaining hardware protection of private key material.

Endorsement Hierarchy

The Endorsement Hierarchy contains the Endorsement Key (EK), a unique key pair embedded in each TPM during manufacturing. The EK serves as the TPM's identity and provides a foundation for attestation and certification. Unlike other hierarchies, the endorsement hierarchy is typically not used for general cryptographic operations but rather for establishing TPM authenticity and enabling privacy-preserving attestation protocols.

The endorsement hierarchy's primary role is to enable remote parties to verify that cryptographic operations are being performed by a genuine TPM rather than a software emulation. The EK public key is often certified by the TPM manufacturer, creating a chain of trust from the hardware vendor to specific TPM instances. This certification enables privacy-preserving protocols where a TPM can prove its authenticity without revealing its unique identity for every transaction.

Null Hierarchy

The Null Hierarchy provides temporary key storage for ephemeral operations that do not require persistence across reboots. Its seed is regenerated on every reboot, so an entire tree of primary, storage, and leaf keys built in this hierarchy is cryptographically erased when the TPM is reset or power-cycled. This makes it suitable for session keys, temporary signing operations, and other transient cryptographic needs. The null hierarchy requires no owner authorization, simplifying its use for applications that do not need long-term key storage.

This hierarchy is particularly useful for cryptographic protocols that require TPM-protected operations but do not need persistent keys. Examples include generating temporary signing keys for authentication sessions, creating ephemeral encryption keys for secure communication channels, or performing one-time cryptographic operations. The automatic cleanup of keys when the TPM resets prevents key accumulation and simplifies resource management.

Storage Root Key (SRK)

The Storage Root Key (SRK) is the primary key of the storage hierarchy and serves as the parent for most user and application keys. In TPM 2.0 it is a primary object derived from the Storage Primary Seed, typically an asymmetric key pair such as RSA 2048-bit or ECC P-256, and is commonly made persistent with TPM2_EvictControl so that it does not have to be regenerated after each reboot. The TCG TPM v2.0 Provisioning Guidance reserves handle 0x81000001 for the storage primary key and 0x81010001 for the endorsement key, and most provisioning tools follow those conventions. All storage keys and data blobs protected by the storage hierarchy ultimately depend on it for protection. (The term Storage Root Key originates with TPM 1.2; TPM 2.0 expresses the same role through a storage-hierarchy primary key.)

The SRK's public portion may be shared freely; it is used to import externally generated keys into the TPM and to wrap child keys. The SRK's private portion never leaves the TPM and is used to decrypt child keys when they are loaded for use. This design allows a large number of keys to be created as children of the SRK, with only the encrypted key blobs stored outside the TPM until needed.

Endorsement Key (EK)

The Endorsement Key is the primary key of the endorsement hierarchy and serves as the TPM's unique cryptographic identity. It is derived from the Endorsement Primary Seed using a standardized template rather than a vendor-specific one. The TCG EK Credential Profile defines a low range of templates covering RSA 2048 and ECC NIST P-256 and a high range covering stronger options such as RSA 3072 and ECC NIST P-384. Standardizing the template is what makes manufacturer certification useful: any verifier can regenerate the same EK public key from the same TPM and match it against the certificate the vendor issued.

The EK is typically a decryption-only key, preventing it from being used directly for signing operations that could compromise privacy. Instead, attestation protocols use the EK to establish secure channels through which other keys (like Attestation Identity Keys) can be certified without revealing the EK itself. This indirection enables privacy-preserving attestation where different operations cannot be correlated by observers monitoring EK usage.

EK certificates, when present, occupy NV indices reserved by the EK Credential Profile. The low range spans 0x01C00002 through 0x01C0000C, with 0x01C00002 holding the RSA 2048 certificate and 0x01C0000A the ECC NIST P-256 certificate; the high range begins at 0x01C00012. Some platforms omit the on-chip certificate and publish it instead through a vendor lookup service keyed by the EK public key. These certificates bind the EK to the TPM's manufacturer, model, and security certifications, so an application can validate the chain before trusting the device's attestations or cryptographic operations.

AIK Certification

AIK certification establishes trust in an attestation identity key through a privacy-preserving protocol involving the TPM, a Privacy CA (Certificate Authority), and the platform owner. The protocol proves that an AIK was created inside a genuine TPM with a manufacturer-certified EK, while preventing the Privacy CA from learning which specific EK corresponds to which AIK. This prevents both the CA and attestation verifiers from tracking individual TPMs.

The certification process typically involves the TPM generating an AIK and creating a certification request that binds the AIK to the EK through cryptographic means. The Privacy CA verifies the EK certificate, confirms the TPM's authenticity, and issues an AIK certificate without learning the direct relationship between the EK and AIK. This certificate can then be presented to verifiers along with signed attestation data, proving the attestation came from a genuine TPM without revealing the TPM's unique identity.

An alternative mechanism, Direct Anonymous Attestation (DAA), removes the trusted Privacy CA from the loop by means of a group signature scheme. A TPM proves membership of a group (genuine parts from a certified manufacturer) without revealing which member it is, and a verifier can optionally detect repeat visits through a basename-linked pseudonym while still learning nothing about the underlying identity. TPM 2.0 provides the elliptic-curve variant through the TPM_ALG_ECDAA signature scheme over a pairing-friendly Barreto-Naehrig curve, and the FIDO Alliance adopted the same construction for anonymous authenticator attestation. Deployment nevertheless remains limited: the great majority of enterprise and cloud attestation still uses credential activation against a manufacturer EK certificate, because that path requires no group issuer and no special verifier support.

AIK Usage and Management

Applications use AIKs to sign attestation evidence including PCR values, event logs, and other platform measurements. The AIK's signing-only restriction prevents it from being used for general-purpose cryptographic operations, limiting the correlation opportunities for observers. Applications may create multiple AIKs for different attestation contexts, such as separate AIKs for enterprise management, cloud service attestation, and local security operations.

AIK lifecycle management involves creating keys as needed, maintaining their certifications, and revoking or retiring keys that are no longer required. Unlike the EK, which is typically permanent, AIKs can be created and destroyed dynamically. This flexibility allows applications to implement privacy-enhancing techniques such as rotating AIKs periodically or using different AIKs for different verifiers to prevent long-term tracking.

Restricted Keys and Object Names

A third attribute, restricted, is what makes the hierarchy trustworthy, and it is worth defining precisely because so much of TPM practice depends on it. A restricted signing key will sign only data the TPM itself produced. Concretely, it refuses any externally supplied digest unless that digest arrives with a validation ticket, and TPM2_Hash withholds the ticket whenever the hashed data begins with the four-byte TPM_GENERATED_VALUE marker. Attestation structures begin with exactly that marker, so an attacker cannot hand a hand-crafted quote to a restricted key and obtain a signature that appears to come from the TPM's own measurement logic. Attestation keys are restricted signing keys for this reason.

A restricted decryption key is a storage key. It may unwrap only blobs in the TPM's own internal format, which is precisely the qualification a key needs in order to serve as a parent. An unrestricted decryption key can decrypt arbitrary ciphertext and therefore cannot be a parent, since an attacker who could submit a child blob to a general-purpose decryption key would read the child's private area directly.

Attributes are not advisory metadata that software could edit. Each object has a Name, formed as its name algorithm identifier followed by the digest of its public area, and the public area covers the algorithm, the attributes, and the authorization policy. Changing any of those changes the Name, and an authorization or policy that refers to an object by Name therefore cannot be redirected to a weaker substitute.

Signing Key Implementation

Signing keys in the TPM hierarchy are created with the sign attribute set, restricting them to signing operations only. These keys are used for authenticating platform state, signing firmware measurements, creating digital signatures for documents or transactions, and establishing secure sessions. The TPM enforces that signing keys cannot perform decryption, even if an attacker gains control of the platform's software.

Applications create signing keys as children of the SRK or other keys in the storage hierarchy, applying appropriate authorization policies that control when signatures can be generated. Signing keys may be restricted to specific PCR states, ensuring signatures are only created when the platform is in a known-good configuration. This PCR-binding prevents malware from using platform signing keys even if it can satisfy the key's authorization requirements.

Common signing key applications include code signing for secure boot verification, document signing for non-repudiation, authentication signatures for network protocols, and timestamp signing for audit trails. Each application may use different keys with policies tailored to its security requirements, with the TPM enforcing usage restrictions regardless of software behavior.

Encryption Key Implementation

Encryption keys are created with the decrypt attribute set, restricting them to encryption, decryption, and key wrapping operations. These keys protect data at rest, secure communications channels, and enable key transport protocols. The TPM's restriction prevents encryption keys from being coerced into signing operations, which could compromise security in protocols that assume key-type separation.

Storage encryption keys are typically bound to PCR values representing the platform's boot state, ensuring encrypted data can be decrypted only when the platform boots into an authorized configuration. This binding enables sealed storage where secrets remain protected even if the storage media is moved to another system or the platform boots from untrusted media. The TPM automatically refuses to decrypt when the current PCR values do not match the values specified when the data was sealed.

Key wrapping applications use TPM encryption keys to protect other cryptographic keys, either for secure storage or for transport to other systems. The TPM can wrap externally-generated keys, protecting them with hardware-backed encryption while allowing them to be stored in normal file systems. When needed, the wrapped keys are loaded into the TPM, which performs the unwrapping internally and makes the key available for cryptographic operations without exposing the key material to software.

Key Creation and Derivation

Child keys can be created through two mechanisms: random generation or deterministic derivation. Random generation creates unique key material using the TPM's hardware random number generator, producing keys that are statistically independent from their parents. These keys exist only in their encrypted form outside the TPM, with the plaintext key material existing only briefly during creation and when loaded for use.

Derivation creates keys deterministically from a special parent. TPM 2.0 defines a derivation parent, a keyed-hash object created with the derive attribute, and TPM2_CreateLoaded produces a child from that parent together with a label and a context value supplied by the caller. The result is a hierarchical deterministic key tree comparable to those used in cryptocurrency wallets. Because the same parent, label, and context always yield the same child, there is no encrypted blob to retain, which suits applications that need reproducible key hierarchies or that must minimize persistent storage.

The choice between the two depends on the application. Randomly generated children are independent of one another, so an attacker who learns the parent still needs each child's encrypted blob to recover that child. Derived children need no blob at all, which is convenient but means the parent secret plus a label is by itself sufficient to reconstruct every descendant. Neither arrangement supplies forward secrecy in the protocol sense: compromising a parent that remains in service exposes the children it protects, because protecting them is exactly what the parent does. Derived keys therefore suit reproducible, storage-constrained hierarchies, while randomly generated keys suit long-lived keys whose blobs can be managed, backed up, and destroyed individually.

Key Loading and Unloading

Before a child key can be used, it must be loaded into the TPM by presenting its encrypted blob along with the handle of its parent key, which must already be loaded. TPM2_Load takes the parent handle together with the child's public area and encrypted private area, validates the integrity value on the private area, decrypts it under the parent, and returns a transient object handle in the 0x80000000 range. Two related commands complete the picture: TPM2_LoadExternal loads a public key alone, which is sufficient for signature verification, and TPM2_Import re-wraps a blob prepared for one parent so that it becomes loadable under another. Several objects may be resident at once, subject to the TPM's working memory.

Transient key handles do not persist across TPM resets. Applications must reload keys after each boot or TPM reset, but reloading is quick because it only decrypts the key blob rather than generating new cryptographic material. A discrete TPM's working memory is small: the TPM_PT_HR_TRANSIENT_MIN capability property is commonly three on PC Client parts, with a comparable ceiling on concurrently loaded sessions, so applications load child keys on demand and unload them promptly.

When a handle is no longer needed, the application should release it with TPM2_FlushContext. The TPM performs no automatic eviction of its own: if no slot is free, it simply fails the command with TPM_RC_OBJECT_MEMORY. The appearance of unlimited capacity comes from a resource manager layered above the device, either the TSS TAB and Resource Manager component or the kernel-provided /dev/tpmrm0 interface on Linux, which virtualizes handles and swaps objects and sessions in and out with TPM2_ContextSave and TPM2_ContextLoad, commonly on a least-recently-used basis. Keys that must always be available, such as the storage primary key, are handled differently again: TPM2_EvictControl moves them into non-volatile storage, outside the transient pool entirely.

Password Authorization

Password authorization is the simplest mechanism, requiring a secret value (the authValue) when the key is used. The authValue is an arbitrary byte string no longer than the digest produced by the object's name algorithm, which is thirty-two bytes for SHA-256, so software normally hashes or otherwise derives a high-entropy value rather than passing a typed password through unchanged. How the value travels matters as much as its entropy: an HMAC session proves knowledge of the authValue without transmitting it, whereas a plain password session sends it in the clear across the bus and should be paired with parameter encryption on a discrete part. When a child key is created it may be assigned its own authValue independent of its parent, enabling fine-grained access control within the hierarchy.

The TPM implements dictionary attack protection, locking out further authorization attempts once a configured number of failures accumulates. TPM2_DictionaryAttackParameters sets three values: maxTries, the number of failures tolerated; recoveryTime, the interval after which one failure is forgiven; and lockoutRecovery, the delay imposed after a failed use of the lockout authorization itself. TPM2_DictionaryAttackLockReset clears the counter for an administrator who holds lockoutAuth. Objects created with the noDA attribute are exempt, which is appropriate for keys whose authorization is already high-entropy and inappropriate for anything protected by a user-chosen secret. Because the failure count and timer live in non-volatile memory, they survive reboots and power cycles, so an attacker cannot reset the lockout by cycling power.

Policy-Based Authorization

Policy-based authorization enables sophisticated access control by defining conditions that must hold before a key may be used. A policy is not a stored rule list that the TPM interprets. It is a digest. Each policy assertion the caller executes extends a running policyDigest inside a policy session, and the TPM permits the operation only when that digest equals the authPolicy recorded in the object's public area at creation. Because the object commits to a single digest and the digest is covered by the object's Name, a policy cannot be relaxed after the fact, and the TPM never has to store or parse the policy expression itself.

The available assertions cover a wide range of conditions. TPM2_PolicyPCR binds use to specific boot measurements. TPM2_PolicyCounterTimer compares against the TPM's own clock and reset counters, which supports time windows and expiry. TPM2_PolicyLocality confines a command to a privileged bus locality, the mechanism a measured launch uses to reserve certain operations to the CPU's secure entry path. TPM2_PolicyNV tests a non-volatile index, which is how a monotonic counter can cap the number of times a key is used. TPM2_PolicySigned and TPM2_PolicySecret delegate the decision to an external signing key or to another TPM entity. TPM2_PolicyCommandCode confines a key to a single command, and TPM2_PolicyAuthValue or TPM2_PolicyPassword folds a password requirement into a policy branch.

Assertions executed in sequence compose as a logical AND, since each one extends the same running digest. Alternatives are expressed with TPM2_PolicyOR, which accepts a session whose current digest matches any entry in a supplied list of up to eight branch digests and then replaces the running digest with the digest of the list. Nesting TPM2_PolicyOR nodes builds arbitrary policy trees, which is how a single key supports both a routine unlock path and a distinct recovery path.

Policy authorization provides flexibility beyond simple passwords while maintaining hardware enforcement. For example, a disk encryption key might require both a correct PCR value (proving secure boot) and a password, ensuring that even if an attacker steals the password, they cannot decrypt data without booting the authorized operating system. Conversely, emergency access might be enabled through an alternate policy branch requiring physical presence confirmation.

Enhanced Authorization

Enhanced authorization (EA) is the TPM 2.0 framework that makes the policy model above possible, and its most useful property is that a policy need not be final at creation time. TPM2_PolicyAuthorize solves the problem that a policyDigest is immutable once an object commits to it. Instead of committing to a concrete condition, the object commits to the public key of an authority; the authority later signs whichever policy digest is currently approved, and the TPM substitutes that approved digest into the session. An enterprise can therefore change the acceptable PCR set after a firmware update without recreating and redistributing every key that depends on it. TPM2_PolicySigned serves the adjacent case in which a remote authority approves an individual operation rather than a standing policy, and it can carry an expiry so that the approval is not replayable indefinitely.

Authorization sessions also supply parameter encryption, auditing, and binding. Parameter encryption protects the first command parameter and the first response parameter when those are sized buffers, which is enough to cover the sensitive material in commands such as TPM2_Create, TPM2_Unseal, and TPM2_GetRandom. The session must be salted or bound so that a session key exists to derive the encryption from; an unsalted, unbound session offers no confidentiality. This matters most for a discrete TPM, where an interposer on the LPC or SPI bus can passively observe traffic between the CPU and the chip, an attack that has been demonstrated repeatedly against unencrypted sealed-key traffic. Audit sessions accumulate a digest over the commands and responses issued, and TPM2_GetSessionAuditDigest signs that accumulation, yielding a tamper-evident record for monitoring and forensic use.

Internal Certification

TPM2_Certify produces an attestation structure signed by a TPM-resident key, proving that both the certified object and the signing key are loaded in the same TPM. The structure carries the certified object's Name, which as described above digests its public area and therefore commits to its algorithm, its attributes, and its authorization policy. A verifier who trusts the signing key thus learns not merely that a public key exists but that its private half is non-duplicable, restricted to signing, and usable only under a stated policy. Because the attestation begins with the TPM_GENERATED_VALUE marker and the signer is a restricted key, the structure cannot be forged by feeding a fabricated digest to the same key.

TPM2_CertifyCreation answers a different question: what was the platform doing when the key came into existence. TPM2_Create returns creation data and a creation ticket, and TPM2_CertifyCreation redeems that ticket to attest to the creation data, including the PCR values current at the moment of creation. This supports policies under which a key is trusted only if it was generated while the platform was in a known-good configuration. In either case the signature chain leads back through an attestation key to the EK and the manufacturer's certificate, which is where the hardware root of trust is anchored.

External Certification

External certification authorities may issue certificates for TPM-generated keys after verifying that the keys originated from a genuine TPM with appropriate security properties. This process typically involves the TPM providing attestation evidence including EK certificates, AIK certificates, and proof that the key was created under specific policies. The CA verifies this evidence before issuing a certificate that can be used in standard PKI environments.

This integration with existing certificate infrastructure enables TPM keys to be used in applications that expect X.509 certificates, such as TLS authentication, code signing, or email encryption. The certificate proves not just the key's identity but also that the private key is protected by hardware, potentially qualifying for higher assurance levels in security-critical applications.

Fixed (Non-Duplicable) Keys

A key created with the fixedTPM attribute is permanently bound to the TPM where it was generated and cannot be exported in any form usable by a different TPM or software environment. Primary keys are inherently fixed to one hierarchy on one TPM. Fixed keys provide the strongest protection against key extraction, making them suitable for long-term signing keys, device identity keys, and other applications where key mobility would compromise security.

The trade-off for this security is reduced flexibility: data encrypted with a fixed key cannot be recovered if the TPM fails or the platform is replaced. Applications using fixed keys must implement backup strategies that do not depend on key export, such as encrypting data to multiple keys or maintaining recovery mechanisms that do not require the original key.

Duplicable Keys

A key is duplicable only if it is created with both fixedTPM and fixedParent cleared. Duplication re-wraps the key for a new parent, typically the public key of a destination TPM, so that the key can be loaded under a different hierarchy or on a different device. This supports portability scenarios such as platform upgrades and disaster recovery. The duplication is authorized by the key's own policy (commonly a policy that requires a specific command and authorizing entity), and the key material is encrypted to the destination parent so that it remains protected in transit.

Policy controls determine where a duplicable key may travel. Designating a fixedTPM destination parent, such as a particular TPM's endorsement key, confines the key to that TPM and prevents further onward duplication; an inner-wrap symmetric key and an HMAC can additionally protect confidentiality and integrity during transfer. Because duplication produces a copy rather than a move, the original key may continue to exist at the source, which is why robust audit logging of duplication operations is important for governance.

Key Escrow and Backup Copies

Duplication enables key backup and sharing arrangements in which copies of a key exist simultaneously in multiple TPMs or storage locations. Applications use it to recover from hardware failure or to create key-escrow arrangements where a copy of an encryption key is securely held by a recovery agent. Duplicated copies remain protected by encryption to parent keys in their destination contexts, preserving hardware protection even when multiple copies exist. Organizations should track every copy through audit trails to satisfy compliance and governance requirements and to ensure complete decommissioning when the key is retired.

Encrypted Blob Backup

The simplest backup mechanism stores the encrypted key blobs returned by the TPM when keys are created. Since these blobs are encrypted with parent keys that remain in the TPM, backing up the blobs alone does not compromise security—an attacker would need access to the specific TPM to decrypt them. This approach works well for keys in the storage hierarchy where the parent keys can be reliably regenerated from the Primary Seed.

Applications should store encrypted key blobs redundantly, potentially in multiple locations or backup systems, while protecting them from unauthorized modification. Though the blobs are encrypted, their integrity is critical—tampering is detected but could result in permanent key loss if backups are also corrupted. Additional integrity protection through digital signatures or authenticated storage can provide defense against malicious modification.

Key Wrapping for Recovery

For keys that must be recoverable even if the original TPM fails, applications can create recovery wrapping keys that encrypt copies of important keys. The recovery wrapping key's public portion can be stored in multiple locations, while its private portion is held by trusted recovery agents or split among multiple parties using secret-sharing schemes. When recovery is needed, the recovery key's private portion can be reconstructed and used to decrypt the backed-up key material.

This approach enables disaster recovery while maintaining security through access controls on the recovery key. The recovery process should require multiple authorizations, audit logging, and potentially time delays to prevent unauthorized recovery operations. Organizations implement recovery procedures that balance accessibility (ensuring legitimate recovery is possible) against security (preventing unauthorized key extraction).

Policy-Based Recovery

Advanced backup strategies use TPM policy features to enable recovery under specific conditions. For example, a key might be duplicable only to TPMs that satisfy specific policy requirements, such as being enrolled in an organization's management system or possessing specific PCR values. This enables secure transfer to replacement hardware while preventing duplication to arbitrary systems.

Emergency recovery policies might allow key operations to proceed through alternate authorization paths when standard authorization cannot be satisfied. For instance, a disk encryption key normally requiring both password and correct PCR values might have an emergency policy allowing access with just physical presence confirmation and a recovery password. These alternate paths should be carefully designed to provide genuine emergency access without creating security vulnerabilities.

Performance Optimization

TPM cryptographic operations are significantly slower than software implementations, because a discrete TPM is a low-cost microcontroller whose design prioritizes security and tamper resistance over speed. An RSA-2048 signature on a discrete TPM commonly takes on the order of tens to a few hundred milliseconds, and key loading and session establishment add further latency. Applications should minimize TPM operations by caching loaded keys, batching operations where possible, and reserving TPM-protected keys for security-critical steps rather than bulk cryptography.

Session management significantly impacts performance. Creating and destroying sessions for each operation incurs substantial overhead, while reusing sessions amortizes setup costs across multiple operations. Applications should maintain session handles when performing multiple related operations, while being prepared to recreate sessions when needed (sessions do not survive TPM resets).

Key hierarchy depth affects loading time, as each level of the hierarchy adds a decryption operation. Shallow hierarchies with keys as direct children of the SRK load faster than deep trees. However, shallow hierarchies may sacrifice organizational benefits or policy inheritance, requiring careful trade-offs between structure and performance.

Storage Management

TPM non-volatile storage is extremely limited, typically providing only a few kilobytes for user-defined NV indices and persistent objects. The number of objects that can be made persistent, reported as TPM_PT_HR_PERSISTENT_MIN, is in the single digits on common PC Client parts, so applications must manage carefully which keys occupy NV. A common strategy keeps only the storage root key and a few frequently used parent keys persistent while loading child keys on demand; deterministic derivation can eliminate the need to store even the encrypted key blob for some keys.

Key blob storage outside the TPM should be organized to enable efficient retrieval while maintaining security metadata. Applications might store key blobs in file systems with names derived from key names or handles, in databases indexed by key attributes, or in credential stores that protect the blobs' integrity. The storage system should track parent-child relationships to enable proper loading sequences.

Error Handling and Recovery

TPM operations can fail for numerous reasons: authorization failures, resource exhaustion, policy violations, or communication errors. Applications must implement robust error handling that distinguishes between retryable errors (like resource exhaustion) and permanent failures (like authorization or policy violations). Dictionary attack lockouts require special handling, potentially involving user notification and waiting for the lockout period to expire.

Key loading failures might indicate blob corruption, hierarchy changes (different Primary Seed), or missing parent keys. Applications should maintain integrity checks on key blobs and potentially multiple backup copies. When keys cannot be loaded, the application must determine whether to attempt recovery, request user intervention, or fail securely by refusing operations that depend on the unavailable key.

Cross-Platform Considerations

TPM implementations vary across platforms, with different firmware versions, command support levels, and performance characteristics. Applications should detect TPM capabilities at runtime rather than assuming specific features, and provide fallback mechanisms for optional capabilities. TPM2_GetCapability reports the supported algorithms, the implemented commands, and the resource limits described earlier, and querying it is cheaper than discovering a limit by failing a command.

Platform differences extend beyond the TPM itself to include BIOS/UEFI interfaces, operating system drivers, and software libraries. Testing across multiple TPM vendors and platform types ensures applications handle variation correctly. Standards compliance (TCG specifications) provides baseline compatibility, but vendor-specific features and extensions require careful handling to maintain portability.

Key Lifecycle Management

Establish formal processes for key creation, usage, storage, backup, and destruction. Keys should be created with only the capabilities necessary for their purpose, using the most restrictive duplication settings that satisfy operational requirements. Fixed (fixedTPM) keys should be preferred when portability is not needed. Each key should have clearly defined authorization policies that reflect its intended usage context and security requirements.

Key destruction must ensure that both TPM-resident keys and encrypted blobs are properly removed. Simply deleting key blobs may not be sufficient if backups exist or if copies were created during duplication operations. Formal decommissioning procedures should account for all key copies and ensure complete removal when keys are no longer needed.

Authorization Design

Design authorization policies that provide defense in depth by combining multiple factors. Password-only authorization is vulnerable to theft or coercion; combining passwords with PCR bindings ensures both knowledge and platform state must be satisfied. For high-security applications, consider requiring physical presence confirmation or external authorization from secure management systems.

Avoid overly permissive authorization that reduces security to satisfy convenience. While it may be tempting to create keys with no authorization for ease of use, this defeats the TPM's protection when malware runs on the platform. Find balanced approaches like policy-based authorization that grants access under specific conditions while denying it in compromised states.

Monitoring and Auditing

Implement comprehensive logging of TPM operations including key creation, loading, usage, and management operations. Audit logs should capture both successful operations and failures, with particular attention to authorization failures that might indicate attacks. Protected audit logs created using TPM signing keys provide tamper-evident records that support forensic analysis and compliance verification.

Monitor for anomalous patterns such as excessive authorization failures (potential brute force attacks), unexpected key creation or loading (potential malware activity), or operations outside normal usage patterns. Automated monitoring systems can alert administrators to suspicious TPM activity, enabling rapid response to security incidents.

Disk Encryption

Full-disk encryption systems use TPM storage keys to protect disk encryption keys, binding the encrypted volume to specific hardware and boot configuration. The disk encryption key is created as a child of the SRK and bound to PCR values representing the expected secure boot state. The key is automatically available when the system boots normally but unavailable if the boot process is modified or if the disk is moved to another system.

Advanced disk encryption implementations use multiple authorization factors, requiring both correct PCR values and a user-provided password or PIN. This multi-factor approach protects against simple theft (password required) while also protecting against malware (correct boot state required). Recovery mechanisms typically involve keeping a copy of the disk encryption key wrapped by a recovery key, with the recovery key's private portion secured offline or in organizational key escrow systems.

Secure Boot and Attestation

Platform firmware measures each boot component and extends the resulting digests into PCRs. Measurement itself involves no key at all; it is a hash chain, and the keys enter only when the resulting state must be reported. An attestation key then signs a quote over the selected PCRs, and the quote travels to a remote verifier alongside the TCG event log that explains how those PCR values were reached. The verifier checks the AIK signature and evaluates the reported PCR values against known-good configurations, determining whether the platform booted into a trusted state.

Attestation enables conditional access to resources based on platform health. Enterprise networks might require valid attestation before granting access to sensitive data or services. Cloud providers use attestation to verify that virtual machines are running on genuine hardware with expected security properties. The hierarchical key structure enables these protocols to establish trust while preserving privacy through pseudonymous AIKs.

Credential Protection

Operating systems use TPM storage keys to protect user credentials, authentication tokens, and other security-critical data. Windows Hello for Business, for example, generates the user's authentication key pair inside the TPM and gates its use on a successful local gesture, so the private key cannot be exported even by kernel-level malware. The biometric template itself is not held in the TPM; it is stored encrypted on the local disk and never leaves the device, and the TPM's role is to protect the key that the gesture unlocks. Each user or application can have separate keys with appropriate authorization policies, providing isolation and access control.

Enterprise single sign-on systems store authentication tokens encrypted to TPM keys bound to both platform state and user passwords. This ensures tokens are only accessible on authorized devices in good security state, and only by authenticated users. The hierarchical structure allows organizational policies to be enforced through parent key policies that apply to all credential storage keys.

Code Signing and Certificate Management

Software development and deployment systems use TPM signing keys to create non-repudiable digital signatures on code, configuration data, or transactions. The TPM's hardware protection ensures signing keys cannot be extracted or duplicated without authorization, providing stronger assurance than software-protected keys. Signing keys can be bound to specific PCR states, ensuring signatures are only created from authorized build or deployment environments.

Certificate authorities solve a closely related problem with hardware security modules, which predate the TPM and pursue the same hierarchical discipline at higher throughput and higher assurance. A CA root key lives in tamper-responsive hardware, subordinate keys are issued beneath it, and the structure carries key rotation, delegation to subordinate CAs, and policy constraints on issuance. The contrast is instructive. A TPM is a low-cost part soldered to one machine and tied to that machine's boot state, whereas an HSM is a shared, high-throughput appliance with quorum-based administration; the hierarchy concept transfers cleanly, while the threat model and the operational controls do not.

Post-Quantum Cryptography

The RSA and elliptic-curve keys that populate today's hierarchies are exactly the primitives a cryptographically relevant quantum computer would break, and the TCG has already moved. Revision 1.85 of the TPM 2.0 Library Specification adds the two NIST-standardized post-quantum algorithms: ML-KEM, the key-encapsulation mechanism of FIPS 203, and ML-DSA, the signature scheme of FIPS 204. Both are admitted as primary key types, so an endorsement key may be an ML-KEM key and an attestation key may be an ML-DSA key. The same revision adds Curve25519 and Curve448 for compatibility with protocols that expect those curves.

Accommodating the new algorithms required new commands rather than merely new algorithm identifiers, which illustrates how deeply key type is woven into the TPM's command set. Key encapsulation is not encryption, so TPM2_Encapsulate and TPM2_Decapsulate were introduced to produce and consume a ciphertext and shared secret rather than to wrap a caller-supplied value. ML-DSA signs a whole message rather than a pre-computed digest, which does not fit the TPM's digest-and-ticket signing convention, so sequence commands were added to stream an arbitrary-length message through the TPM for signing or verification. Signature and ciphertext sizes also grow by an order of magnitude relative to ECC, with consequences for blob storage and for the bandwidth of a low-speed SPI or I2C interface.

Migration will be gradual for a structural reason peculiar to this technology. An endorsement key is fixed at manufacture and certified by the vendor, so a TPM shipped with only RSA and ECC endorsement keys cannot acquire a post-quantum identity in the field; quantum-safe attestation requires new silicon. Hybrid arrangements, in which a hierarchy carries both a classical and a post-quantum key and relying parties accept either, are the practical bridge, and the tree structure accommodates them naturally because a parent's algorithm need not match its children's.

Confidential Computing Integration

Confidential computing technologies, among them Intel TDX and SGX, AMD SEV-SNP, and the Arm Confidential Compute Architecture alongside the older TrustZone, increasingly interlock with TPM key hierarchies. The most consequential form this takes is the virtual TPM bound to a confidential virtual machine: the hypervisor cannot read the guest's memory, so the guest's vTPM instance and its hierarchy seeds are shielded from the host, and the vTPM's endorsement key is certified by the hardware attestation report rather than by a chip vendor. A tenant can then verify the platform through the silicon's own attestation and verify the guest's boot state through ordinary TPM quotes over the vTPM's PCRs.

Future systems may implement hierarchical trust models where TPM platform hierarchies establish boot-time trust, which is then extended into runtime TEE hierarchies that protect application execution. Keys could be created with policies requiring both correct boot measurements (TPM PCRs) and correct runtime measurements (TEE attestations), ensuring protection across the entire execution lifecycle.

Distributed and Federated Trust

Cloud and edge computing environments increasingly require trust relationships that span multiple platforms and organizations. TPM key hierarchies are evolving to support federated trust models where keys created on one platform can be certified and used on another while maintaining cryptographic proof of their properties. Cross-platform key certification enables scenarios like workload migration between cloud providers while maintaining security properties.

Threshold and multi-party cryptography may be integrated with TPM hierarchies, enabling keys that require cooperation between multiple TPMs for operations. This supports scenarios like multi-organization control over critical operations, where no single entity can unilaterally use a key. The hierarchical structure could extend across organizational boundaries while maintaining hardware protection at each node.