Electronics Guide

Platform Hierarchy

The Platform Hierarchy is controlled by platform firmware and used for operations that establish the platform's security foundation. This hierarchy is typically managed by BIOS/UEFI firmware and contains keys used for secure boot, firmware measurements, and platform configuration. The platform hierarchy authorization can change between boots, allowing firmware updates while preventing unauthorized modifications during normal operation.

Keys in the platform hierarchy are used to seal secrets that should only be accessible when the platform boots with specific firmware configurations. This enables secure storage of encryption keys, passwords, and other sensitive data that must remain protected even if the operating system is compromised. The platform hierarchy provides the hardware root of trust for platform integrity measurement and attestation.

Storage Hierarchy

The Storage Hierarchy is controlled by the operating system or platform owner and used for general-purpose key storage and cryptographic operations. This hierarchy contains the Storage Root Key (SRK) and derivative keys used for disk encryption, secure storage, and application-level cryptography. The storage hierarchy authorization typically persists across boots, allowing consistent access to encrypted data.

Applications create keys as children of the SRK or 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 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 don't require persistence across reboots. Keys in this hierarchy are lost when the TPM is reset or power-cycled, making it suitable for session keys, temporary signing operations, and other transient cryptographic needs. The null hierarchy requires no authorization, simplifying its use for applications that don't need long-term key storage.

This hierarchy is particularly useful for cryptographic protocols that require TPM-protected operations but don't 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 is the primary key of the storage hierarchy and serves as the parent for most user and application keys. The SRK is typically an asymmetric encryption key pair (usually RSA 2048-bit or ECC P-256) that remains permanently loaded in the TPM. All storage keys and data blobs protected by the storage hierarchy ultimately depend on the SRK for protection.

The SRK's public key is typically well-known and may be shared freely, as it's used to import externally-generated keys into the TPM or verify that keys were created by a specific TPM. The SRK's private key never leaves the TPM and is used to decrypt child keys when they need to be loaded for use. This design allows unlimited 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. The EK is typically generated during manufacturing or first initialization using a manufacturer-specific template that ensures consistency across TPM instances. The EK public key may be certified by the TPM manufacturer, creating a verifiable chain of trust to the hardware vendor.

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, are typically stored in the TPM's non-volatile memory or in a platform-accessible location. These certificates bind the EK public key to information about the TPM's manufacturer, model, and security certifications. Applications can verify EK certificates to confirm they're communicating with a genuine hardware TPM before trusting its 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.

Modern TPM 2.0 implementations often use alternative certification mechanisms including Direct Anonymous Attestation (DAA), which eliminates the need for a trusted Privacy CA by using group signature schemes. DAA allows TPMs to prove group membership (genuine TPM from a certified manufacturer) without revealing individual identity, enabling privacy-preserving attestation without relying on third-party certification authorities.

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.

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 only be decrypted 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 don't 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 the parent key and a derivation value, enabling hierarchical deterministic key trees similar to those used in cryptocurrency wallets. Derived keys can be recreated by providing the same parent key and derivation inputs, eliminating the need to store even the encrypted key blob. This approach is useful for applications that need reproducible key hierarchies or want to minimize storage requirements.

The choice between random and derived keys depends on the application's requirements. Random keys provide perfect forward secrecy, as losing a parent key doesn't compromise already-distributed child key material. Derived keys enable key recovery and reproducibility but require careful management of derivation paths and protection of the derivation inputs that serve as key handles.

Key Loading and Unloading

Before a child key can be used, it must be loaded into the TPM by presenting its encrypted blob to the TPM along with the handle of its parent key (which must already be loaded). The TPM validates the blob's integrity, uses the parent key to decrypt the child key, and makes the child key available under a session handle. Multiple keys can be loaded simultaneously, subject to the TPM's memory limitations.

Key handles are session-specific and do not persist across TPM resets. Applications must reload keys after each boot or TPM reset, but the reloading process is quick as it only involves decrypting the key blob rather than generating new cryptographic material. The TPM's limited memory typically accommodates 3-10 loaded keys simultaneously, depending on key types and sizes.

When key handles are no longer needed, applications should explicitly unload them to free resources for other keys. The TPM also implements eviction policies that automatically unload keys when memory is needed, typically using least-recently-used algorithms. Critical keys like the SRK may be marked as persistent, preventing automatic eviction and ensuring they remain available without reloading.

Password Authorization

Password authorization is the simplest authorization mechanism, requiring a secret value (authValue) to be provided when using a key. The authValue is typically a cryptographic hash rather than a user-memorable password, providing high entropy protection against brute force attacks. When a child key is created, it can be assigned its own authValue independent of its parent, enabling fine-grained access control within the key hierarchy.

The TPM implements dictionary attack protection for password-guessing attempts, automatically locking out further authorization attempts after a configured number of failures. This lockout prevents attackers from exhaustively trying passwords even if they have complete control over the platform's software. The lockout timer and failure count are maintained in the TPM's non-volatile memory, surviving reboots and power cycles.

Policy-Based Authorization

Policy-based authorization enables sophisticated access control by defining conditions that must be satisfied before a key can be used. Policies can require specific PCR values (platform state), physical presence confirmation, signed authorization from external entities, or combinations of multiple factors. The policy is specified when the key is created and enforced by the TPM during all subsequent key usage.

Common policy types include PCR policies that bind key usage to specific boot configurations, time-based policies that restrict operations to specific time windows, locality policies that require operations to originate from specific platform components, and counters that limit the number of times a key can be used. Complex policies can combine multiple requirements using logical AND, OR, and threshold operators.

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

TPM 2.0 introduces enhanced authorization (EA) that enables dynamic policy evaluation and authorization delegation. EA allows policies to include externally-signed authorizations, enabling scenarios where a remote authority can approve individual TPM operations. This capability supports enterprise key management where operations require approval from a central server without giving the server direct access to key material.

Authorization sessions provide additional security features including parameter encryption, audit trails, and session binding. Parameter encryption protects authorization values and command parameters from observation on the platform bus, preventing passive eavesdropping attacks. Audit trails create cryptographically-protected logs of TPM operations, supporting security monitoring and forensic analysis.

Internal Certification

The TPM's Certify command creates certificates signed by a TPM-resident key, proving that both the certified key and the certifying key exist in the same TPM. The certificate includes the certified key's public key, its name (a cryptographic hash of its public area and attributes), and relevant policy information. Applications use internal certification to prove to remote parties that specific key relationships exist, such as proving that a signing key is properly authorized under specific policies.

Certification data includes creation information such as the PCR values that were current when the key was created, providing proof of the platform state at key creation time. This enables scenarios where keys are only trusted if created while the platform was in a known-good configuration. The certification signature chain ultimately leads back to the EK or a manufacturer-certified key, establishing hardware-rooted trust.

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.

Non-Migratable Keys

Non-migratable keys are created with the fixedTPM attribute, permanently binding them to the TPM where they were created. These keys cannot be exported in any form that would allow them to be used in a different TPM or software environment. Non-migratable keys provide the strongest protection against key extraction, making them suitable for long-term signing keys, platform identity keys, and other applications where key mobility would compromise security.

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

Migratable Keys

Migratable keys can be exported from one TPM and imported into another, enabling key portability for scenarios like platform upgrades or disaster recovery. The migration process requires authorization from both the source TPM (to export the key) and destination TPM (to accept it). The key is encrypted during migration using the destination TPM's migration key, ensuring it remains protected during transport.

Migration policies can restrict which TPMs may receive a migrated key, either through explicit whitelisting of destination EKs or through policy requirements that destination TPMs must satisfy. This controlled migration enables business continuity while preventing unrestricted key distribution. Applications use migratable keys for data encryption where recovery from TPM failure is essential, while still maintaining hardware protection during normal operation.

Key Duplication

Key duplication creates copies of keys that can exist simultaneously in multiple TPMs or storage locations. Unlike migration, which moves a key from one location to another, duplication enables key backup and sharing scenarios. Duplication requires explicit authorization through key policies, preventing unauthorized copying while enabling legitimate backup and recovery operations.

Duplicated keys remain protected by encryption to parent keys in their destination contexts, maintaining security properties even when copies exist. Applications use key duplication for backup purposes, enabling recovery from hardware failures, or for creating key escrow arrangements where a copy of an encryption key is securely held by a recovery agent. The duplication process creates audit trails that track key copies, supporting compliance and governance requirements.

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 doesn't 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 migration 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 due to the secure hardware design prioritizing security over speed. RSA-2048 signature generation might take 100-500 milliseconds, while key loading and session establishment add additional latency. Applications should minimize TPM operations by caching loaded keys, batching operations where possible, and using TPM-protected keys only for critical operations.

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 don't 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 keys and data. Most TPMs support only 3-7 persistent key handles, requiring applications to carefully manage which keys remain loaded. Strategies include keeping only the SRK and frequently-used parent keys persistent while loading child keys on demand, or using deterministic derivation to eliminate the need to store even encrypted key blobs.

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. The TPM's GetCapability command reveals supported algorithms, available resources, and implemented commands.

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 minimal privileges necessary for their purpose, using the weakest migration capabilities that satisfy operational requirements. Non-migratable keys should be preferred when portability isn't 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 uses keys in the platform hierarchy to measure boot components and extend measurements into PCRs. These measurements create a cryptographic log of the boot process that can be signed by AIKs and presented to remote verifiers. 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 example, stores biometric template data and authentication keys in TPM-protected storage, ensuring these sensitive credentials cannot be stolen even by kernel-level malware. 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 use HSMs with TPM-like hierarchical key management for issuing certificates, with the CA root key protected by hardware and intermediate keys derived for specific purposes. The hierarchical structure supports key rotation, delegation to subordinate CAs, and policy-based constraints on certificate issuance, all enforced through hardware-protected cryptographic relationships.

Post-Quantum Cryptography

As quantum computers advance, current asymmetric cryptography used in TPM hierarchies (RSA, ECC) will become vulnerable. The TPM specification is evolving to support post-quantum algorithms that resist quantum attacks. Future TPMs will likely support quantum-resistant key types as parents and children in hierarchies, enabling migration to quantum-safe cryptography while maintaining compatibility with existing systems during transition periods.

Hybrid approaches may combine classical and post-quantum algorithms, with keys protected by both types to ensure security against both current and future threats. The hierarchical structure naturally supports such hybrids, with parent keys using one algorithm family and children using another, or keys protected by multiple parents using different cryptographic approaches.

Confidential Computing Integration

Emerging confidential computing technologies like Intel SGX, AMD SEV, and ARM TrustZone increasingly integrate with TPM key hierarchies to provide end-to-end protection. Keys managed by the TPM can be provisioned into trusted execution environments, combining TPM-based attestation with runtime memory encryption. This integration enables applications to verify platform boot state through TPM attestation and verify runtime execution through TEE attestation, creating comprehensive trust chains.

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.