Trusted Platform Module (TPM)

The TPM contains a true Random Number Generator (RNG) that harvests entropy from thermal noise and other analog sources to create non-deterministic keys. Unlike software-based pseudo-random generators, this hardware entropy source prevents key predictability. The TPM generates RSA (2048-bit) and ECC (NIST P-256, P-384) key pairs internally, ensuring the private key material is generated within the tamper-resistant silicon and never exposed in plaintext to the host operating system, applications, or external memory buses.

The TPM organizes keys into a cryptographically shielded hierarchy rooted in a unique, immutable Endorsement Key (EK) burned into the silicon during manufacturing. This hierarchy includes:

• Endorsement Key (EK): A unique, factory-provisioned RSA/ECC key pair that establishes the TPM's identity.
• Storage Root Key (SRK): The master wrapping key generated when a user takes ownership of the TPM, forming the root of the user-managed key tree.
• Attestation Identity Keys (AIKs): Privacy-preserving aliases derived from the EK, used for anonymous platform authentication. All private keys are wrapped and stored externally, encrypted by the key immediately above them in the hierarchy, ensuring they can only be decrypted by the specific TPM that created them.

PCRs are shielded memory locations within the TPM that store integrity measurements of the platform's boot chain. They are not writable directly; instead, they use a cryptographic extend operation: PCR_New = Hash(PCR_Old || New_Measurement). This append-only log ensures that once a measurement is recorded, the historical sequence cannot be erased or reordered. Standard PCR banks support multiple hash algorithms simultaneously (SHA-1 and SHA-256), and specific registers are allocated for:

• PCR 0-7: BIOS/UEFI firmware measurements
• PCR 8-15: Bootloader and OS kernel measurements
• PCR 16-23: Application-specific measurements This tamper-evident log is the foundation for measured boot and remote attestation.

Remote attestation is the cryptographic process by which a TPM proves the software state of its host platform to a remote verifier. The protocol works as follows:

1. The verifier sends a challenge (nonce) to the attesting platform.
2. The TPM signs a Quote—a data structure containing the current PCR values and the verifier's nonce—using a private Attestation Identity Key (AIK).
3. The verifier validates the signature against the AIK's public key and compares the PCR values against a known-good configuration database. This proves that a specific, untampered software stack is running on a genuine TPM-equipped platform, establishing a hardware-anchored trust relationship before secrets or workloads are provisioned.

The TPM provides two mechanisms for protecting data at rest using its internal keys:

• Binding: Encrypts data using a TPM-wrapped public key (typically the SRK's descendant). The resulting ciphertext can only be decrypted by the specific TPM that holds the corresponding private key, effectively binding the data to that physical chip.
• Sealing: Extends binding by cryptographically associating the decryption of a blob with a specific platform state. Data is sealed to a set of PCR values; the TPM will only release the decryption key if the current PCR state matches the specified values. This ensures that secrets (like disk encryption keys) are only accessible when the platform has booted a trusted software configuration. Example: A BitLocker volume master key is sealed to PCRs 7 and 11, ensuring it unlocks only if the Secure Boot policy and bootloader are unmodified.

The TPM includes a limited amount of Non-Volatile (NV) RAM for storing persistent data and implements monotonic counters—hardware counters that can only increment. These capabilities enable:

• Anti-rollback protection: A counter value is incremented with each firmware update. Sealed secrets can be tied to a minimum counter value, preventing an attacker from rolling back firmware to a vulnerable version to unseal data.
• Usage counting: Tracking the number of times a sealed secret has been accessed or a specific operation has been performed.
• Persistent authorization policies: Storing small policy digests or authorization values that survive power cycles. NV indices can be configured with fine-grained access controls, including PCR-bound read/write policies and authorization requirements.