Pith. sign in

REVIEW 4 major objections 5 minor 30 references

HSM and TPM Failures in Cloud: A Real-World Taxonomy and Emerging Defenses

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper argues that cloud-hosted HSMs and TPMs are compromised through surrounding ecosystem weaknesses—misconfigured identity and access management, exposed APIs, and hypervisor-level attacks—rather than through broken cryptography.

desk verdict A readable practitioner survey of cloud key-management failures, but the central taxonomy claim overreaches the case evidence. read the letter →

arxiv 2507.17655 v2 pith:L7CPR53L submitted 2025-07-23 cs.CR cs.NIcs.SE

Shams Shaikh , Trima P. Fernandes e Fizardo This is my paper · ORCID
classification cs.CRcs.NIcs.SE
keywords HardwareSecurityModule(HSM)TrustedPlatform(TPM)ConfidentialComputingVirtualTPM(vTPM)Post-QuantumCryptographyMulti-PartyComputationIAMMisconfigurationCloud
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that cloud-hosted Hardware Security Modules (HSMs) and Trusted Platform Modules (TPMs) are being defeated not by broken cryptography but by the software and operational layers around them. It assembles publicly documented incidents—Capital One's IAM-based breach, Azure Cosmos DB's ChaosDB, CI/CD secret leaks, and the Heckler hypervisor attack—into a taxonomy whose failure modes are misconfiguration, API exploits, privilege escalation, and multi-tenancy risk. The recurring pattern, the authors claim, is that attackers reach key material or key-granting credentials through weak permissions, leaked tokens, and insecure management interfaces, never needing to break the hardware boundary. From this they derive a layered defensive agenda—confidential computing, post-quantum cryptography, multi-party computation, and enclave-wrapped vTPMs—and argue that cloud key security must be treated as a system property rather than a hardware purchase.

What carries the argument

The central object is the paper's four-category taxonomy of cloud HSM/TPM failure modes—misconfiguration, API exploits, privilege escalation, and multi-tenancy risk—together with the recurring attack-chain pattern SSRF → metadata service → temporary credentials → key-management API. That pattern does the argument's work: it shows the path to key compromise runs through the control plane, not through the cryptographic boundary. The paper also treats the HSM-versus-vTPM comparison as a mechanism for showing that abstraction layers (APIs, IAM, hypervisor) are where trust breaks.

What would settle it

Look for one publicly documented cloud incident in which an attacker extracted a private key directly from an HSM or TPM boundary without first obtaining credentials or abusing an API; if no such case exists, the claim that ecosystem weaknesses dominate rests on absence rather than on demonstrated hardware failures.

Watch

Extended reading notes

Core claim

The paper's central claim is that in cloud environments HSMs and TPMs fail as trust anchors because the trust model they assume—physical control and a small, well-defined interface—does not survive virtualization and managed-service abstraction. Its case studies show attackers obtaining temporary IAM credentials or internal management tokens and then using legitimate channels to reach key material; the Heckler study shows a malicious hypervisor injecting interrupts to break vTPM-protected workloads. From these cases the paper generalizes a taxonomy of four failure modes—misconfiguration, API exploits, privilege escalation, and multi-tenancy risk—and states that cloud-native threats operate at the API, orchestration, and multi-tenancy layers, not at the cryptographic boundary. It further claims to be the first synthesis of real-world cloud HSM/TPM failures into such a taxonomy, and concludes that effective security requires layered, context-aware defenses rather than reliance on hardware guarantees alone.

Load-bearing premise

The taxonomy assumes that the incidents it labels as HSM or TPM failures really are failures of those hardware modules, but two of its central examples were attacks on cloud permissions and management interfaces, not demonstrated breaks of the chips.

Editorial extensions

If this is right

  • Cloud architects should treat HSMs and TPMs as one layer of a larger trust chain; least-privilege IAM, API hardening, network isolation, and key rotation are as important as the hardware itself.
  • Virtual TPMs inherit the trust boundary of the hypervisor and TEE: if a malicious hypervisor can inject interrupts, hardware-rooted attestation and protection for vTPM workloads can be undone.
  • Moving toward confidential VMs, NIST-standardized post-quantum algorithms, and MPC-based key distribution addresses the identified ecosystem gaps but introduces new constraints such as side-channel risk, key-size overhead, and coordination complexity.
  • Because first-party and third-party integrations share the same control plane, zero-trust principles and continuous auditing should be applied even to trusted cloud services.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the case studies suggest the taxonomy is really about key-management ecosystem failures rather than hardware-module failures, and a more precise label would reserve 'HSM/TPM failure' for demonstrated compromise at the hardware boundary.
  • Editorial inference: a testable extension is to score a larger corpus of cloud incidents by whether evidence shows key extraction at the hardware boundary or only credential and API theft; the paper's claim predicts the latter dominates.
  • Editorial inference: the hybrid architecture could be prototyped as a reference design that chains vTPM attestation, a confidential VM runtime, MPC signing, and PQC key exchange, then adversarially tested from the API and IAM layer to see whether that layer remains the weakest link.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper surveys public cloud security incidents and argues that HSMs and TPMs, while cryptographically strong, are undermined by surrounding ecosystem weaknesses such as misconfigured IAM, exposed APIs, and CI/CD secrets. It proposes a taxonomy of failure modes, compares HSMs with TPMs/vTPMs, and evaluates confidential computing, post-quantum cryptography, MPC-based key management, and secure vTPMs as emerging defenses. The paper claims to be the first synthesis of documented, real-world cloud HSM/TPM failures into a coherent taxonomy grounded in modern threat models.

Significance. If the central claim were supported, the survey would be a useful reference for practitioners and researchers. The paper correctly distinguishes cryptographic primitives from the surrounding operational environment and includes relevant academic attacks (Heckler, SvTPM, PLATYPUS) alongside industry survey data. However, the primary case studies do not document HSM/TPM failures; they are IAM, API, and CI/CD compromises. The paper's actual contribution is a plausible argument that operational controls around hardware trust anchors matter more than the hardware itself. With a substantial reframing and additional verified case material, the manuscript could become a valuable practitioner-oriented survey; as written, the novelty claim is not supported by the evidence.

major comments (4)
  1. [§2.3.1, §2.3.2, §3.1] The central empirical cases are not HSM/TPM failures. The Capital One breach (§2.3.1) was an SSRF attack that retrieved temporary IAM credentials; the text itself says these credentials 'potentially' allowed KMS/CloudHSM operations, and no exfiltration of HSM key material is demonstrated. The ChaosDB vulnerability (§2.3.2) involved SSRF in the Jupyter notebook feature and extraction of primary keys via Cosmos DB management APIs, without attacking any hardware security boundary. The Wiz CI/CD case (§3.1) is about attackers using exposed secrets to impersonate workloads and access HSM-backed interfaces, not defeating an HSM. In all three cases, the paper explicitly states that cryptographic protections were bypassed 'indirectly' or rendered 'irrelevant.' These are ecosystem failures, not hardware failures, and therefore cannot ground the abstract's claim of a 'taxonomy of real-world cloud HSM and TPM failures.'
  2. [§1.1] The only incident presented as a direct HSM API exploit is an unnamed 2023 breach of a major cloud provider, described as exploiting API vulnerabilities to extract cryptographic keys. This case has no citation and is never analyzed in the rest of the paper. Because it is the single case that would directly support the central claim, omitting its source and detailed analysis is a critical gap. Either provide a verifiable reference and a full case study, or remove the claim and adjust the paper's scope.
  3. [§2.3.3, Figure 1] Figure 1 labels the attack chain as ChaosDB but includes the step 'Temporary IAM Credentials Retrieved,' which matches the Capital One metadata-service attack, not the ChaosDB chain (which obtained internal management tokens and certificates). This conflation obscures the distinct root causes of the two incidents and undermines the precision of the proposed taxonomy. The figure should be corrected to reflect the actual ChaosDB chain, or replaced with a generic cloud-credential-theft chain clearly separated from the case studies.
  4. [Table 1] The taxonomy in Table 1 is presented as if it were exhaustive for 'Common Cloud-Based HSM/TPM Failure Modes,' but the manuscript describes no systematic methodology for selecting or classifying incidents, and the four categories (misconfigurations, API exploits, privilege escalation, multi-tenancy risks) are generic cloud security failure modes rather than results derived from the case studies. The empirical support for this taxonomy is therefore not established; the table should be reframed as a set of observed risk categories in the surrounding ecosystem, not as a validated taxonomy of HSM/TPM failures.
minor comments (5)
  1. [Throughout] There are frequent spacing and typographical errors, for example 'A WS' (page 3), 'W AF' (page 3), 'V ulnerability' (page 4), and 'F ailure' and 'T able' (Table 1). These should be corrected in a careful copyedit.
  2. [§4.2] The text states that 'The NIST PQC project concluded its third round of standardization in 2024.' This is imprecise: NIST announced the selected algorithms in 2022, and the first standards were released in 2024. Please clarify the timeline.
  3. [§2.1, reference [5]] Reference [5] is a study on multi-tenant placement vulnerabilities, but it is used to support the general claim that traditional HSMs and TPMs were 'never designed to address' cloud challenges. A more directly relevant citation about cloud trust models and hardware root-of-trust limitations would be appropriate.
  4. [References] Many references are vendor blog posts and industry reports without access dates or DOIs; for example, references [6], [7], and [21] lack retrieval dates. For a survey with a taxonomy claim, primary sources and dated access information should be provided consistently.
  5. [§3.2] The description of Heckler correctly states that malicious hypervisors can inject interrupts into confidential VMs, but the paper then asserts this 'compromises vTPM-protected workloads' without evidence from the cited study that a vTPM was actually defeated. Please frame this as a plausible risk rather than an established vTPM failure.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: survey synthesizes external incidents and derives no result from its own inputs.

full rationale

This paper is a survey/taxonomy, not a derivation. It does not define outputs in terms of inputs, fit parameters, or invoke any self-authored prior work. The central claim—that ecosystem weaknesses (APIs, IAM, hypervisors) rather than cryptographic primitives dominate cloud HSM/TPM compromise—is an interpretive summary of externally reported incidents (Capital One, ChaosDB, Wiz CI/CD, Heckler, SvTPM). None of the load-bearing steps reduces to its own inputs by construction: the taxonomy categories are induced from the cited case studies, but the paper presents them as organization, not as a prediction or theorem. There are no author self-citations; refs [24] and [25] are independent external works. The reviewer should note two non-circular evidentiary weaknesses: (1) Section 1.1's 2023 cloud-HSM API breach is asserted without any citation, and (2) Sections 2.3.1–2.3.2 describe IAM/SSRF/API compromises that do not clearly demonstrate a broken HSM/TPM boundary. These affect correctness and evidential support, not circularity. Under the stated hard rules, no circular step can be quoted with an exhibited reduction, so the appropriate score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claim that documented failures cluster in ecosystem layers rests on a small set of secondary-source case studies and on asserted categories. The main unstated premises are representativeness of the chosen incidents, accuracy of vendor and news reports, exhaustiveness of the four failure categories in Table 1, and the truth of an uncited 2023 breach anecdote in Section 1.1.

assumptions (4)
  • domain assumption The selected incidents are representative of cloud HSM/TPM failures.
    The paper selects Capital One, ChaosDB, Wiz CI/CD cases, Heckler, and SvTPM without explicit inclusion criteria; the taxonomy's completeness depends on this selection.
  • domain assumption Secondary sources (vendor blogs, news, vendor reports) are accurate enough to support the taxonomy categories.
    Most case descriptions cite blog posts and threat-intelligence reports (e.g., [7], [8], [13]) rather than primary incident reports or audit logs.
  • ad hoc to paper The failure-mode categories in Table 1 are exhaustive for cloud HSM/TPM failures.
    No methodology or validation shows that misconfigurations, API exploits, privilege escalation, and multi-tenancy risks cover the full space of HSM/TPM failures; they are asserted in Table 1.
  • domain assumption The 2023 cloud HSM API breach described in Section 1.1 occurred as stated.
    No citation is given for this anecdote, and the case-study section later does not include it, so the claim rests entirely on the authors' assertion.

how reviews work

0 comments
Cite this review

Pith. "Pith review of HSM and TPM Failures in Cloud: A Real-World Taxonomy and Emerging Defenses." pith.science (2026). https://pith.science/paper/L7CPR53L

@misc{pith2026250717655,
  author       = {Pith},
  title        = {Pith review of: HSM and TPM Failures in Cloud: A Real-World Taxonomy and Emerging Defenses},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/L7CPR53L}},
  note         = {Machine review of arXiv:2507.17655}
}
read the original abstract

As cloud infrastructure becomes the backbone of modern organizations, the security of cryptographic key management, especially using Hardware Security Modules (HSMs) and Trusted Platform Modules (TPMs), faces unprecedented challenges. While these hardware-based solutions offer strong protection in isolated environments, their effectiveness is being undermined by cloud-native threats such as misconfigurations, compromised APIs, and lateral privilege escalations. This paper presents a comprehensive analysis of publicly disclosed attacks and breaches involving HSMs and TPMs in cloud environments, identifying recurring architectural and operational flaws. We propose a taxonomy of attack vectors based on real-world case studies and threat intelligence reports, highlighting the gaps between hardware trust anchors and dynamic cloud ecosystems. Furthermore, we evaluate emerging defensive paradigms: confidential computing, post-quantum cryptography, and decentralized key management systems (dKMS), assessing their potential to address these gaps. Our findings emphasize that securing cloud-based cryptographic trust requires a layered, context-aware approach that integrates both hardware and software safeguards. The study serves as a practical framework for cloud architects and security engineers to reassess key protection strategies in light of evolving threats. To our knowledge, this is the first work to synthesize documented, real-world cloud HSM and TPM failures into a coherent taxonomy grounded in modern threat models.

Figures

Figures reproduced from arXiv: 2507.17655 by the authors.

Figure 1
Figure 1. Attack Path in ChaosDB: From SSRF to Full Key Compromise [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Hybrid Cloud Cryptographic Architecture Integrating Confidential Computing, PQC, MPC, [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

30 extracted references · 30 canonical work pages

  1. [1]

    What is encryption key management? importance and best prac- tices

    LegitSecurity, “What is encryption key management? importance and best prac- tices.” https://www.legitsecurity.com/aspm-knowledge-base/encryption-key-management- best-practices, 2025

    work page 2025

  2. [2]

    The essential role of hardware security modules in public pki

    E. Consulting, “The essential role of hardware security modules in public pki.” https:// www.encryptionconsulting.com/the-essential-role-of-hsm-in-pki/ , 2025

    work page 2025

  3. [3]

    How hsms support secure multi-tenancy

    Utimaco, “How hsms support secure multi-tenancy.” https://www.utimaco.com/news/blog- posts/how-hsms-support-secure-multi-tenancy , 2023

    work page 2023

  4. [4]

    The role of cloud hsm in strengthening enterprise data security

    Fortanix, “The role of cloud hsm in strengthening enterprise data security.” https: //www.fortanix.com/blog/the-role-of-cloud-hsm-in-strengthening-enterprise-data- security, 2025

    work page 2025

  5. [5]

    A placement vulnerability study in {Multi- Tenant} public clouds,

    V. Varadarajan, Y. Zhang, T. Ristenpart, and M. Swift, “A placement vulnerability study in {Multi- Tenant} public clouds,” in 24th USENIX Security Symposium (USENIX Security 15), pp. 913–928, 2015

    work page 2015

  6. [6]

    New study finds 84% experienced an api security incident in past year

    Akamai, “New study finds 84% experienced an api security incident in past year.” https://www.akamai.com/newsroom/press-release/new-study-finds-84-of-security- professionals-experienced-an-api-security-incident-in-the-past-year , 2024

    work page 2024

  7. [7]

    Secret-based cloud supply chain attacks: Case study and lessons

    W. R. Team, “Secret-based cloud supply chain attacks: Case study and lessons.” https://www.wiz.io/blog/secret-based-cloud-supply-chain-attacks-case-study-and- lessons-for-security-teams , 2023

    work page 2023

  8. [8]

    Chaosdb explained: Azure’s cosmos db vulnerability walkthrough

    W. R. Team, “Chaosdb explained: Azure’s cosmos db vulnerability walkthrough.” https:// www.wiz.io/blog/chaosdb-explained-azures-cosmos-db-vulnerability-walkthrough , 2021

    work page 2021

Show all 30 references
  1. [9]

    Confidential computing overview

    Microsoft Azure, “Confidential computing overview.” https://azure.microsoft.com/en-us/ solutions/confidential-compute/, 2024

    2024

  2. [10]

    Post-quantum cryptography project

    NIST, “Post-quantum cryptography project.” https://csrc.nist.gov/projects/post-quantum- cryptography, 2024

    2024

  3. [11]

    Multi-party computation (mpc) wallets for secure key management

    Fireblocks, “Multi-party computation (mpc) wallets for secure key management.” https:// www.fireblocks.com/technology/secure-mpc-wallet/, 2023

    2023

  4. [12]

    Recent trends in applying tpm to cloud computing,

    S. Hosseinzadeh, B. Sequeiros, P. R. In´ acio, and V. Lepp¨ anen, “Recent trends in applying tpm to cloud computing,” Security and privacy, vol. 3, no. 1, p. e93, 2020

    2020

  5. [13]

    A technical analysis of the capital one hack

    CloudSploit, “A technical analysis of the capital one hack.” https://medium.com/cloudsploit/a- technical-analysis-of-the-capital-one-hack-a9b43d7c8aea , 2019. Accessed: 2025-06-30

    2019

  6. [14]

    What we can learn from the capital one hack

    B. Krebs, “What we can learn from the capital one hack.” https://krebsonsecurity.com/2019/ 08/what-we-can-learn-from-the-capital-one-hack/ , 2019. Accessed: 2025-06-30

    2019

  7. [15]

    Capital one hack highlights ssrf concerns for aws

    R. Wright and C. Kanaracus, “Capital one hack highlights ssrf concerns for aws.” https: //www.techtarget.com/searchsecurity/news/252467901/Capital-One-hack-highlights- SSRF-concerns-for-AWS , 2019. Accessed: 2025-06-30

    2019

  8. [16]

    A systematic analysis of the capital one data breach: Critical lessons learned,

    S. Khan, I. Kabanov, Y. Hua, and S. Madnick, “A systematic analysis of the capital one data breach: Critical lessons learned,” ACM Transactions on Privacy and Security, vol. 26, no. 1, pp. 1–29, 2022

    2022

  9. [17]

    Update on vulnerability in the azure cosmos db jupyter notebook fea- ture

    M. S. R. C. (MSRC), “Update on vulnerability in the azure cosmos db jupyter notebook fea- ture.” https://msrc.microsoft.com/blog/2021/08/update-on-vulnerability-in-the-azure- cosmos-db-jupyter-notebook-feature/ , 2021

    2021

  10. [18]

    Securing the cloud: Lessons from the azure cosmos db breach

    C. Kibet, “Securing the cloud: Lessons from the azure cosmos db breach.” https: //medium.com/@kibet cleo/securing-the-cloud-lessons-from-the-azure-cosmos-db- breach-fb77e450eefd, 2021. 10

    2021

  11. [19]

    State of cloud security 2021 report

    Sonatype, “State of cloud security 2021 report.” https://www.sonatype.com/hubfs/ State of Cloud Security 2021.pdf, 2021

    2021

  12. [20]

    2021 cloud security report

    C. Insiders, “2021 cloud security report.” https://cdn2.qualys.com/docs/mktg/2021-cloud- security-report.pdf, 2021

    2021

  13. [21]

    The state of cloud-native security 2024

    P. A. Networks, “The state of cloud-native security 2024.” https://www.paloaltonetworks.com/ resources/research/state-of-cloud-native-security-2024 , 2024

    2024

  14. [22]

    Top cloud security trends in 2025

    C. P. S. Technologies, “Top cloud security trends in 2025.” https://www.checkpoint.com/cyber- hub/cloud-security/what-is-code-security/top-cloud-security-trends-in-2025 , 2025

    2025

  15. [23]

    Google’s internal kms: Secrets at planet scale

    M. Lutaaya and V. Muthusamy, “Google’s internal kms: Secrets at planet scale.” https:// www.infoq.com/news/2019/11/google-internal-kms-scale/ , 2019

    2019

  16. [24]

    Heckler: breaking confidential vms with malicious interrupts,

    B. Schl¨ uter, S. Sridhara, M. Kuhne, A. Bertschi, and S. Shinde, “Heckler: breaking confidential vms with malicious interrupts,” in Proceedings of the 33rd USENIX Conference on Security Symposium, SEC ’24, (USA), USENIX Association, 2024

    2024

  17. [25]

    Svtpm: A secure and efficient virtual tpm,

    J. Wang, C. Fan, J. Wang, Y. Cheng, Y. Zhang, W. Zhang, P. Liu, and H. Hu, “Svtpm: A secure and efficient virtual tpm,” arXiv preprint arXiv:1905.08493, 2019

    1905 arXiv

  18. [26]

    Mole: Mitigation of side-channel attacks against sgx via dynamic data location escape,

    F. Lang, W. Wang, L. Meng, J. Lin, Q. Wang, and L. Lu, “Mole: Mitigation of side-channel attacks against sgx via dynamic data location escape,” in Proceedings of the 38th Annual Computer Security Applications Conference, ACSAC ’22, (New York, NY, USA), p. 978–988, Association ...

    2022

  19. [27]

    Secret and key management in azure confidential computing

    Microsoft Learn, “Secret and key management in azure confidential computing.” https:// learn.microsoft.com/en-us/azure/confidential-computing/secret-key-management , 2025

    2025

  20. [28]

    Confidential computing and related technologies: a critical review,

    M. U. Sardar and C. Fetzer, “Confidential computing and related technologies: a critical review,” Cybersecurity, vol. 6, no. 1, p. 10, 2023

    2023

  21. [29]

    Platypus: Software-based power side-channel attacks on x86,

    M. Lipp, A. Kogler, D. Oswald, M. Schwarz, C. Easdon, C. Canella, and D. Gruss, “Platypus: Software-based power side-channel attacks on x86,” in 2021 IEEE Symposium on Security and Privacy (SP), pp. 355–371, 2021

    2021

  22. [30]

    Revisiting secure multiparty computation (mpc) for agile enterprise key man- agement

    Blockdaemon Blog, “Revisiting secure multiparty computation (mpc) for agile enterprise key man- agement.” https://www.blockdaemon.com/blog/revisiting-secure-multiparty-computation- mpc-for-agile-enterprise-key-management , 2023. 11

    2023

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.