Trusted Platform Modules (TPMs)

• Trusted Platform Modules (TPMs) are standardized cryptoprocessors that provide a hardware-based root of trust for secure key storage, measured boot, and cryptographic operations.
• They offer essential cryptographic services including secure random number generation, remote attestation, and sealing, underpinning applications from disk encryption to cloud vTPMs.
• Recent research extends TPM roles to post-quantum cryptography, multi-device signing, and integration with TEEs, while addressing vulnerabilities like side-channel leaks and implementation flaws.

Trusted Platform Modules (TPMs) are standard cryptoprocessors designed to protect the integrity and security of computing platforms by anchoring cryptographic operations in a trusted component. Across the cited literature, a TPM is described as a secure hardware component that may appear as a discrete chip, a firmware component, or a software implementation; it protects encryption keys, supports secure cryptographic operations, and underpins services such as measured boot, sealing, attestation, and secure storage. TPM 2.0 is the dominant contemporary interface in this body of work, and its significance lies not only in classical platform trust but also in its reuse as a substrate for cloud vTPMs, confidential computing, mobile security, post-quantum extensions, and multi-device signature protocols (Fiolhais et al., 2023, Ziani et al., 2023).

1. Architectural role and core services

TPMs function as a root of trust because other security guarantees in the system depend on them. The literature consistently assigns them four canonical roles: secure boot, secure key storage and authentication, data encryption/decryption, and remote attestation. Standard TPM 2.0 is characterized as including a cryptographic processor, a secure random number generator, RSA/ECC and hashing engines, small non-volatile memory such as 64 kB, volatile memory for short-lived data, and dedicated circuitry to resist physical attacks. Because the TPM is intended to be independent of the main application processor and its software stack, it forms a trusted base even when the operating system is compromised (Fiolhais et al., 2023).

The same architectural description appears in software-stack research, where the TPM is treated as a standard cryptoprocessor protecting the integrity and security of modern computers. In that setting, TPMs are directly associated with secure disk-encryption key storage, including BitLocker and dm-crypt, and with the broader problem of establishing trust in platform state. The literature is explicit that the TPM boundary is meaningful only if the software that mediates access to it is also trustworthy; applications normally interact through a TPM Software Stack (TSS), not by issuing raw device transactions (Ziani et al., 2023).

Randomness generation is also part of the baseline service model. A TPM 1.2 benchmark study describes the TPM True Random Number Generator (TRNG) as a state machine that mixes unpredictable input data with the output of a one-way hash function, optionally harvesting internal entropy sources such as clock jitter or thermal noise. Empirically, the tested Infineon, Intel, Atmel, and Sinosun chips produced generally high-quality random data, but throughput differed dramatically: the fastest chip produced random data about 30 times faster than the slowest. That study also showed that conformance to the TCG interface did not imply identical internal designs, buffering strategies, or request-size behavior across vendors (Suciu et al., 2010).

2. Measurement, PCRs, sealing, and authorization semantics

A central TPM abstraction is the Platform Configuration Register (PCR), which stores integrity measurements of software and platform state. In the standard extend model, a protected verification value evolves as

$V \gets H(V \| m),$

where $V$ is the current register value and $m$ is a new measurement. This yields a linear chain of trust suitable for measured boot and attestation, but it also motivates later work on tree-formed verification data because a single PCR root does not preserve internal structure about subsystems or subtrees (Schmidt et al., 2010).

In trusted-boot and Dynamic Root of Trust for Measurement (DRTM) settings, PCRs become policy anchors rather than simple logs. One TPM-based authentication-proxy architecture uses PCR18 as the key DRTM measurement register and binds the measured launch chain of PAL, Flicker, and the Proxy Module into a single PCR state:

$$PCR18 \leftarrow H(H(PM)+H(H(Flicker)+H(H(PAL)+"0"))).$$

Secrets are sealed to those PCR values so that unsealing succeeds only when the platform re-enters the expected trusted state. The same system uses TPM Quote to sign PCR contents and a verifier nonce,

$$\text{Quote} = \text{sig}\{PCR,\ nonce\}_{AIKpriv},$$

thereby making attestation the gate that determines whether sensitive credentials may enter the protected execution path (Uzunay et al., 2015).

TPM 2.0 generalizes authorization beyond shared secrets through Enhanced Authorization (EA). Each object may carry an authValue and an authPolicy, and a policy session accumulates a policyDigest according to

$$policyDigest_{new} = \mathbf{H}(policyDigest_{old}\;||\;commandCode\;||\;commandArgs).$$

This model supports immediate assertions such as TPM2_PolicyNV(), deferred assertions such as TPM2_PolicyCommandCode(), combined assertions such as TPM2_PolicyPCR(), disjunction via TPM2_PolicyOR(), and external re-authorization via TPM2_PolicyAuthorize(). In the eID literature, these mechanisms are used to encode realistic policies for citizen credentials, including PIN/PUK checks, retry limits, platform-integrity checks, revocation, and command restriction to TPM2_Sign() (Nyman et al., 2014).

A further extension replaces linear measurement logs with tree-formed verification data. In that model, a PCR protects the root of a Merkle tree stored in the Stored Measurement Log (SML), and conceptually enhanced TPM commands can verify inner nodes, update them securely, and even quote them with PCR-like assurance. The main stated application is certification of SML subtrees so that remote attestation can express platform properties rather than only raw measurement digests (Schmidt et al., 2010).

3. Virtual TPMs, cloud deployment, and collaborative roots of trust

Virtual TPMs (vTPMs) arose because a single physical TPM does not scale naturally to many virtual machines. In cloud environments, vTPMs provide per-VM roots of trust for measurements, attestation, sealing, and key protection, but they also expand the trust boundary to include the hypervisor, the vTPM backend, and frequently the control plane. One line of work emphasizes that vTPMs are already widely used in commercial cloud platforms, yet current implementations may suffer from confidential-data leakage and high performance overhead when they remain tightly coupled to a slow, shared physical TPM (Wang et al., 2019).

The attempt to recover hardware-based assurance for vTPMs led to explicit binding schemes between virtual PCRs and hardware PCRs. One approach stores the root of a binary hash tree of virtual PCRs in a hardware PCR, yielding update and verification complexity $O(\log n)$. Another uses incremental hashing, yielding update complexity $O(1)$ but much more expensive verification. Both schemes preserve a hardware root of trust by ensuring that tampering with software-managed vPCRs is reflected in hardware-protected PCR state (Alsouri et al., 2013).

Cloud-hypervisor integration work shows the practical systems consequences of exposing TPM functionality in lightweight platforms. In Firecracker, a vTPM was integrated as a virtio device backed by swtpm, using Linux’s existing TPM architecture and IMA support in the guest. The measurements reported that pre-provisioned TPM pools are materially better than on-demand allocation: in the concurrent pooled setup, startup time increased by 17%, Firecracker’s own memory footprint rose by 4 KB, and the full addition including swtpm raised memory by 3760 KB. The security analysis located the main attack-surface increase in the swtpm userspace backend rather than in virtio device mediation itself (Veltman et al., 2023).

Recent confidential-computing work treats TPMs and TEEs as complementary rather than competing trust anchors. In CCxTrust, the TEE is the “black-box” root of trust for confidential execution, while the TPM is the “white-box” root of trust for measurement, reporting, and persistent storage. The platform implements independent Roots of Trust for Measurement for TEE and TPM, a collaborative Root of Trust for Report through composite attestation, and a TPM-only Root of Trust for Storage. The reported result is a 24% improvement in attestation efficiency for the composite protocol, with Confidential TPM performance showing a 16.47% reduction compared to standard TPM (Shang et al., 2024).

Cloud-failure analysis adds an important qualification: TPMs remain useful roots of trust, but their guarantees are often neutralized by surrounding cloud-native weaknesses such as hypervisor compromise, API abuse, IAM misconfiguration, and vTPM implementation flaws. This suggests that, in cloud settings, the TPM’s effective security is inseparable from the integrity of the broader orchestration and authorization stack (Shaikh et al., 23 Jul 2025).

4. Cryptographic evolution and protocol extensions

TPM research increasingly treats the module as a general cryptographic substrate rather than only a boot-time anchor. One major branch concerns post-quantum migration. A low-power implementation study extends TPM 2.0 with Kyber for key encapsulation, Dilithium for digital signatures, and a 3-round Random Oblivious Transfer protocol. The prototype was implemented on ARM Cortex-A7 and RISC-V U74 embedded processors. The reported results show that Kyber and Dilithium are faster than RSA in key creation, Kyber is on par with RSA for encryption/decryption, and Dilithium is on par with RSA and ECC for signature creation and verification. The same work states that lattice-based keys increase memory requirements by roughly one order of magnitude in the median case, but argues that required code could be backported to already available TPMs (Fiolhais et al., 2023).

Another branch uses TPMs inside multi-device signing systems. PiTPM treats TPM 2.0 as the practical hardware substrate for private-key protection while redesigning multi-signer Schnorr signing around a trusted Aggregator. Traditional Schnorr-style multi-signatures require interactive commitment exchange among all participants, which becomes $O(n^2)$ communication in TPM-backed multi-device deployments. PiTPM removes that commitment-phase interaction by storing per-signer randomness seeds in the Aggregator and deriving commitments deterministically from the message, a monotonic counter, and the ordered signer set. The resulting multi-signature is the constant-size tuple

$$\sigma = (R, c, s, \mathit{ctr}, S_{\text{ordered}}),$$

with verification by the standard Schnorr relation

$V$0

The paper reports signing latency rising from about 89.4 ms at $V$1 to 108.8 ms at $V$2, roughly a 15–18× improvement over interactive schemes at $V$3, a 94.5% reduction in wallet transaction coordination time from 52 seconds to 0.55 seconds on average, and 421 tx/s versus 21 tx/s in a 50-of-75 consortium-wallet threshold scenario (Abdulsalam et al., 10 Feb 2026).

TPM authorization itself is also used as a programmable cryptographic policy layer. In the eID setting, TPM 2.0 policies bind keys to platform integrity, PIN state, retry counters, and external approvals, allowing one PIN to authorize multiple keys via TPM2_PolicySecret() and enabling client-side expiration via TPM2_PolicyCounterTimer(). A plausible implication is that TPM 2.0’s most consequential shift is not any single algorithmic primitive, but the ability to express application-specific cryptographic policy inside the module boundary (Nyman et al., 2014).

5. Security failures, attack surfaces, and formal assurance

A recurrent theme in the literature is that TPM security depends as much on implementation discipline as on the abstract interface. Timing analysis of TPM 2.0 devices showed that some implementations leak secret information during elliptic-curve signing. In TPM-FAIL, Intel firmware TPM and an STMicroelectronics hardware TPM exhibited secret-dependent execution times correlated with nonce structure. The reported attacks recovered 256-bit private ECDSA and ECSchnorr keys; for Intel fTPM, recovery succeeded after about 1,300 observations and in less than two minutes, while for the STMicroelectronics hardware TPM the private ECDSA key was extracted after fewer than 40,000 observations. The same work demonstrated a remote attack against a StrongSwan IPsec VPN, recovering the server’s authentication key by timing 45,000 authentication handshakes over the network (Moghimi et al., 2019).

Firmware TPMs remove the exposed LPC/SPI bus that discrete TPMs present, but they inherit the security of the TEE that hosts them. faulTPM showed that compromising AMD’s Secure Processor yields a full TPM state compromise for AMD fTPMs. The consequence is stronger than a bus-sniffing attack: once the attacker extracts the internal secrets used to protect fTPM non-volatile state, sealed objects, PCR-bound secrets, passphrase/PIN-protected objects, and anti-hammering protections can all be bypassed. The paper demonstrates the first attack against Full Disk Encryption backed by an fTPM and argues that BitLocker’s TPM-only protector can be defeated by an attacker with 2–3 hours of physical access; with weak PINs, TPM+PIN protection may be less secure than TPM-less protection with a reasonable passphrase (Jacob et al., 2023).

The software layer above the TPM is itself a critical attack surface. A formal-verification case study on tpm2-tss verified functional properties and absence of runtime errors for a representative subset of 10 ESAPI functions using Frama-C/WP and ACSL. The reported effort involved 659 proof goals, with about 52% proved by SMT and about 47% by Qed. The study does not claim full-stack verification, but it demonstrates that linked lists, dynamic allocation workarounds, and marshaling logic in TPM middleware are security-relevant enough to justify deductive verification (Ziani et al., 2023).

Even basic TPM services exhibit implementation subtleties. In TRNG benchmarking, applications requesting more bytes than a chip’s actual maximum did not necessarily receive an error; instead, the returned header could indicate a smaller buffer than requested. If software failed to inspect that header, stale or nonrandom bytes could be misinterpreted as fresh randomness. This is not a cryptanalytic break, but it exemplifies the gap between abstract TPM semantics and concrete, vendor-specific device behavior (Suciu et al., 2010).

A common misconception is that certification alone implies robust side-channel or fault resistance. The timing-leakage results include a Common Criteria EAL 4+ certified TPM, and the fTPM attacks show that eliminating an exposed bus does not eliminate the need to analyze the TEE and firmware that implement the TPM abstraction. The literature therefore treats transparent evaluation, black-box testing, and formal analysis as complementary rather than interchangeable forms of assurance (Moghimi et al., 2019, Jacob et al., 2023).

6. Specialized deployments and current research directions

Mobile systems have motivated several nontraditional TPM designs. One implementation study uses a software TPM 2.0 protected by ARM TrustZone on Windows Phone 8.1 and builds a mobile-banking framework around attestation, sealing, and AIK-signed quotes. On a Nokia Lumia 830, the reported mean times were 0.896 ms for RNG, 1.05 ms for PCR Read, 1.06 ms for SHA-1 Data Hash, 0.4 ms for SHA-1 Key Sign, and 1.2 ms for Extend PCR. The same work is explicit that a software TPM in a TEE is useful but not equivalent to a hardware TPM, because the secure world remains a larger and more exposed TCB than a discrete device (Reineh et al., 2016).

A different mobile direction is simTPM, which implements a TPM 2.0–style module on the SIM card and integrates it into the ARM Trusted Firmware secure-boot chain. The motivation is that discrete TPMs are poorly matched to mobile space, cost, and power constraints, while TEE-based firmware TPMs become available only relatively late in boot. simTPM addresses the removable-module problem by binding the SIM-hosted TPM to the device root of trust through either a TEE proxy or a distance-bounding protocol. Benchmarks on a HiKey960 show competitive performance with reported TEE-based and hardware-based TPMs, including 257 ± 8.03 ms for ECC key generation, 24 ± 2.66 ms for PCR extend, and 15 ± 0.14 ms for random-number generation (Chakraborty et al., 2019).

In FPGA-SoC cloud settings, TPM 2.0 has been repurposed as a runtime control plane. A user-controllable FPGA-vTPM measures trusted boot into PCR0–PCR7, records IP deployment into PCR8, and records invocation input/output into PCR9 and PCR10. The design adds TPM 2.0-compatible commands Update_CMD, Deploy_CMD, and Invoke_CMD, allowing dynamic session-key updates, IP deployment, and IP invocation while preserving a standard 10-byte TPM command/response header. The prototype on a Xilinx Zynq UltraScale+ MPSoC reports low FPGA resource usage and command times such as about 109.5 ms for tpm2_getrandom, 169.4 ms for tpm2_pcrread, and 82.0 ms for tpm2_pcrextend (Mao et al., 18 May 2025).

TPMs are also being composed more tightly with TEEs. TALUS proposes a secure symbiosis between Intel SGX and a hardware TPM so that long-term secrets used in the SGX life cycle can be moved out of shared CPU-side hardware and into the coprocessor. Its design requirements are a secure communication channel, horizontal access control, and vertical access control, and its prototype uses locality and extended authorization policies to bind TPM objects to enclave identity. The reported overhead is substantial for one-time operations—624.16 ms for enclave creation with TPM assistance versus 97.75 ms for vanilla SGX—but the stated goal is confidentiality robustness against transient-execution attacks, not minimizing latency for every call (Chakraborty et al., 2023).

Firmware protection work provides a more local example of TPM use as a policy-bound key vault. SmmPack encrypts SMM module code sections with AES-128-CBC and seals the decryption key into TPM NV space using TPM2_StartAuthSession, TPM2_PolicyPCR, TPM2_PolicyGetDigest, TPM2_NV_DefineSpace, and TPM2_NV_Read, focusing on PCR0. The key is retrievable only in the intended early boot state; after the OS has booted, PCR changes prevent ordinary software retrieval. The measured whole overhead of SmmPackSmm was 0.23035 s, and the overall boot-time increase was about 0.36 s, or about 2.77% in the reported environment (Matsuo et al., 2024).

Taken together, these directions suggest that contemporary TPM research is less concerned with the TPM as an isolated peripheral than with the composition problem: how hardware-rooted measurement, authorization, storage, and attestation should interact with TEEs, cloud hypervisors, post-quantum algorithms, virtualized infrastructures, and application-specific policy engines. A plausible implication is that the enduring role of the TPM is not a fixed device form factor, but a persistent set of trust services—measurement, sealing, attestation, policy evaluation, and protected key use—that can be re-instantiated across heterogeneous platforms while preserving a verifiable root of trust.