Remote Timing Attacks on TPMs, AKA TPM-Fail

TPM-Fail: Timing Side-Channel Attacks on Trusted Platform Module Implementations

**Overview**

Daniel Morimi, PhD student at Ruhr University Bochum, presents TPM-Fail, a remote timing side-channel attack that extracts cryptographic keys from Trusted Platform Module implementations, including Intel's fTPM (firmware TPM on Intel Management Engine), and certified solutions from STMicroelectronics, Infineon, and Nuvoton. While traditional cryptanalysis looks for algorithmic flaws (e.g., PlayStation 3's ECDSA nonce reuse vulnerability), side-channel cryptanalysis exploits signals leaked during cryptographic operations—timing, power consumption, electromagnetic emissions, and cache behavior. TPM-Fail demonstrates that timing measurements alone, without physical access, can recover private keys from TPMs despite Common Criteria EAL4+ certification claims. The attack leverages the fact that TPM devices use low-cost microprocessors running 100+ times slower than CPUs, making execution-time variations measurable and exploitable. Intel's fTPM, implemented in firmware on Intel's Converged Security Management Engine (CSME), proves particularly vulnerable despite running on modern Intel processors. The research reveals a critical gap: devices certified as "side-channel resistant" by Trusted Computing Group standards remain vulnerable to practical remote timing attacks. The implications are severe for organizations using TPMs for key storage, firmware attestation, and cryptographic operations—all security guarantees can be bypassed through remote timing analysis.

**Technical Details**

Cryptanalysis Fundamentals:

1. **Traditional Cryptanalysis Approach**: - Examines cryptographic algorithm at input/output level - Seeks design flaws enabling key recovery - Example: PlayStation 3 ECDSA implementation reused nonce k for multiple signatures - ECDSA signature equation produces k value from two different signatures (with different nonces) - Reusing k simplified equation to single unknown variable (private key d) - Result: private key directly computable from two signatures with reused nonce

2. **Side-Channel Cryptanalysis Overview**: - Exploits signals leaked during algorithm execution (not algorithm design itself) - Timing channels: execution time varies with data values - Power consumption channels: power draw correlates with operations - Electromagnetic emission: leaked EM radiation encodes processed data - Cache timing attacks: cache hits/misses leak memory access patterns - Advantage: bypasses cryptographically-sound algorithms - Challenge: attack threat models vary (physical access, local, remote)

Trusted Platform Modules (TPMs):

3. **TPM Purpose and Deployment**: - Hardware-based root of trust for systems vulnerable to software compromise - Counters malware/rootkits compromising operating system - Protects against CPU-level attacks (Meltdown, Spectre) - Secure cryptographic element storing sensitive keys - Standard set of functionality defined by Trusted Computing Group (TCG)

4. **TPM Functions and Capabilities**: - Secure key storage: cryptographic keys stored isolated from OS/hypervisor - Digital signature operations: supports RSA and ECDSA signing - Remote attestation: proves device running correct firmware to remote parties - Endorsement Key (EK): root cryptographic key used for device identification/attestation - User Keys: application-specific keys for signing/decryption

5. **TPM Standard Evolution**: - TPM 1.2: supported RSA-based cryptography - TPM 2.0 (since 2010): added elliptic curve support (ECDSA, ECDAA) - ECC schemes more efficient than RSA; more popular in modern deployments - TCG specifies standard cryptographic operations but not implementation details

6. **TPM Security Assurance Requirements**: - TCG expects TPM manufacturers to meet Common Criteria certification - Target assurance level: EAL4+ (Evaluation Assurance Level 4 and higher) - EAL4+ certification claim: evaluated against side-channel attacks - Listed manufacturers: STMicroelectronics, Infineon, Nuvoton, others - Certified devices published on TCG website with evaluation date and profile

Side-Channel Evaluation Gaps:

7. **Common Criteria Evaluation Limitations**: - Common Criteria testing occurs at evaluation date; implementations may drift - Evaluation covers specific threat model but not all possible attacks - EAL4+ claims "side-channel resistance" but evaluation scope limited - Evaluated devices claimed resilience to: SPA (Simple Power Analysis), DPA (Differential Power Analysis), timing attacks, physical probing - However: evaluation often conducted under limited attack conditions

8. **Timing Attack Feasibility on TPMs**: - TPM devices use low-cost microprocessors (embedded processors) - Microprocessor clock speed ~100+ times slower than CPU (MHz vs. GHz) - Slower execution makes timing variations more pronounced and measurable - Timing measurements don't require physical access (can be done remotely) - CPU cycle counting provides accurate timing without specialized equipment - Attackers can measure operation timing through side channels (network timing, local process timing)

Intel fTPM (Firmware TPM):

9. **Intel fTPM Architecture**: - Implemented in firmware on Intel CSME (Converged Security Management Engine) - CSME: dedicated security microcontroller integrated on same die as CPU - Runs independently from main CPU/OS - Handles security-critical operations (key storage, cryptographic operations) - Firmware-based implementation runs on CSME's processor

10. **Intel fTPM Vulnerability**: - Despite modern Intel CPU implementation, fTPM uses cryptographic algorithms with timing vulnerabilities - ECDSA signature operation execution time correlates with private key bits - Signature generation time varies based on nonce and key values - Attackers can recover key bits from timing variations - Vulnerability exists despite running on modern Intel processor (not a processing speed issue)

11. **Certification vs. Actual Implementation**: - Intel fTPM certified by TCG - Datasheet claims resistance against side-channel attacks - Common Criteria evaluation document specifies mitigation of timing attacks - Yet practical implementation vulnerable to timing analysis - Gap between certification claims and actual implementation security

Practical Timing Attack Against TPMs:

12. **Attack Methodology**: - Measure execution time of TPM signing operations - Collect multiple timing samples from signing same message with same key - Statistical analysis reveals key-dependent timing variations - Build timing profile: how execution time correlates with key bits - Use profile to recover key bits through differential analysis

13. **ECDSA Timing Vulnerability Mechanism**: - ECDSA signature generation: S = k^-1 (H(m) + d*r) mod n - k: ephemeral nonce (random per signature, should be secret) - d: private key (constant across all signatures) - r, s: signature output - Modular inverse computation (k^-1) timing depends on k value - Scalar multiplication (d*r) timing depends on d value - Attacker measures total signing time, performs statistical analysis

14. **Key Recovery Process**: - For each key bit position, measure signing time across many samples - Use statistical tests (t-test, chi-squared) to detect key-dependent timing leaks - Build differential timing profile: timing difference between signing with bit=0 vs. bit=1 - Brute-force key bits guided by timing profile - Recover full key or significant key material enabling signature forgery

15. **Remote Attack Feasibility**: - TPM operations can be triggered from software (OS system calls) - Timing measurements possible through kernel-level access - Measurements also possible through side channels (network traffic timing) - Attack doesn't require physical access or specialized equipment - Attack potentially remotely executable through service interface

Impact and Implications:

16. **Scope of Vulnerable TPMs**: - Intel fTPM confirmed vulnerable - STMicroelectronics hardware TPM evaluated (vulnerable) - Infineon TPM confirmed vulnerable - Nuvoton TPM confirmed vulnerable - Affects systems using TPM for key storage/attestation globally

17. **Broken Security Guarantees**: - Endorsement Keys (device root keys) can be extracted - Compromised EK allows device impersonation in attestation protocols - User keys stored in TPM become accessible - Integrity guarantees provided by TPM-backed signing defeated

18. **Threat Model Impact**: - Organizations relying on TPM for firmware integrity validation - Remote attestation protocols assuming TPM key security - Disk encryption systems using TPM for key protection - Enterprise systems using TPM for credential storage - All vulnerable to key extraction through timing attacks

**Defense & Takeaways**

Mitigating timing side-channel attacks on TPM implementations: (1) **Implement constant-time cryptographic operations**—ensure operation execution time independent of secret values; critical for all cryptographic primitives (ECDSA, RSA, key derivation); (2) **Use cryptographic libraries with timing protection**—avoid custom implementations; libraries like libsodium, OpenSSL with constant-time options, or formally-verified crypto reduce timing leaks; (3) **Add random delays (blinding)**—inject random noise into operation timing to reduce signal-to-noise ratio; timing variations must be larger than added noise to enable attack; (4) **Mask key bits**—perform operations on masked (XORed) key values; attacker must recover both key and mask to extract information; requires additional security analysis; (5) **Randomize operation order**—execute cryptographic steps in randomized order when semantically equivalent; prevents attacker from aligning timing samples; (6) **TPM firmware updates**—vendors should patch vulnerable firmware implementations; critical for fTPM devices; (7) **Hardware-based countermeasures**—implement dedicated circuits for constant-time operations; hardware can provide better isolation than firmware; (8) **Side-channel testing before deployment**—organizations procuring TPMs should test for timing vulnerabilities independent of Common Criteria; don't rely solely on certification; (9) **Re-evaluate Common Criteria standards**—TCG should require mandatory side-channel testing against remote timing attacks; current EAL4+ insufficient; (10) **Assume TPM keys compromised in threat modeling**—organizations shouldn't design security systems with single point of failure at TPM level; use multiple layers of cryptography; (11) **Rotate attestation keys regularly**—if EK extracted, compromise is limited by key rotation frequency; implement short-lived attestation keys; (12) **Monitor for attestation anomalies**—if attestation protocol assumes EK secrecy, monitor for unexpected attestation patterns suggesting key compromise; (13) **Use attestation with additional factors**—combine TPM-based attestation with other verification methods (physical audit, behavioral analysis); don't rely solely on cryptographic proof; (14) **Isolate TPM operations from timing-observable code**—prevent timing side channels through shared resources; separate TPM processor reduces observable timing; (15) **Formal verification of cryptographic implementations**—use proof assistants to verify constant-time properties; human review insufficient for timing security. The core lesson: certification and claims of "side-channel resistance" should not substitute for rigorous empirical testing. Common Criteria evaluation represents a point-in-time assessment under specific threat models; it is not a guarantee of security against all possible attacks. TPM manufacturers have economic incentives to claim security but limited incentive to disclose vulnerabilities. Organizations depending on TPM security should treat it as one security layer among many, not as a complete root of trust. The technical insight: timing variations in cryptographic operations are nearly inevitable in practical implementations due to CPU branch prediction, caching, and memory access patterns. Eliminating these variations requires discipline in implementation, careful algorithm choice, and often acceptance of performance penalties. The research demonstrates that defenders cannot rely on certifications alone; empirical testing of actual implementations against side-channel attacks is essential before deployment.