Narrowing the Gap between TEEs Threat Model and Deployment Strategies

Andrew Miller; Filip Rezabek; Frieder Erdmann; Jonathan Passerat-Palmbach; Moe Mahhouk

REVIEW 3 major objections 5 minor 20 references

Narrowing the Gap between TEEs Threat Model and Deployment Strategies

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read This paper argues that confidential-virtual-machine attestation should be extended to bind the workload to the cloud provider hosting it, using the CPU's Protected Platform Identifier (PPID).

desk verdict A useful position paper on the attestation-to-provider gap; the PPID fix is honest about shifting trust, not removing it. read the letter →

arxiv 2506.14964 v1 pith:WRT5BWJG submitted 2025-06-17 cs.CR

Filip Rezabek , Jonathan Passerat-Palmbach , Moe Mahhouk , Frieder Erdmann , Andrew Miller This is my paper · ORCID

classification cs.CR

keywords confidentialvirtualmachinestrustedexecutionenvironmentsremoteattestationProtectedPlatformIdentifier(PPID)threatmodelcloudprovidertrustdata-in-useprotectionstandardization

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 remote attestation for confidential virtual machines (CVMs) is misaligned with real deployments: it proves which software runs inside a trusted execution environment, but says nothing about which cloud provider hosts the hardware. That gap matters because TEE threat models explicitly exclude physical attacks such as probing or fault injection, so users must rely on the physical security of the data center. The paper proposes extending attestation to bind the CVM to the hosting provider, for example by including the CPU's Protected Platform Identifier (PPID) in the attestation report and having providers publish their PPID lists. It then flags that this requires standardization across different TEE designs and that the threat model should eventually be extended to cover physical access.

What carries the argument

The Protected Platform Identifier (PPID), a unique identifier baked into each Intel CPU and derived from the CPU's UUID (with CPU_ID on AMD), appears in DCAP attestation quotes in encrypted form using Intel's provisioning service key. The paper's proposal makes this identifier the link between an attestation report and the physical machine, so a provider-published list of PPIDs lets users verify the operator. The same PPID is shared by all CVMs on the same hardware, which is why the paper pairs it with zero-knowledge proofs for privacy-preserving verification.

What would settle it

Take an attestation quote from a CPU that is not in the cloud provider's published PPID list and check whether a verifier that uses that list accepts it; if it does, or if the quote can be modified to carry a listed PPID, then the proposed PPID binding does not actually establish the provider's identity.

Watch

Extended reading notes

Core claim

The central claim is that the attestation report of a confidential VM should do more than authenticate the software stack: it should also link the workload to the specific hardware and therefore to the cloud provider operating that hardware. The PPID, a unique per-CPU identifier included in Intel DCAP quotes (and CPU_ID in AMD systems), provides a concrete mechanism: if the provider publishes a list of its PPIDs, a user can verify that the CVM runs inside that provider's infrastructure. The paper presents this as closing the gap between the TEE threat model, which excludes physical and side-channel attacks, and deployment strategies in which users still have to trust the provider's physical security. It also notes that different CVMs on the same hardware share one PPID, and suggests zero-knowledge proofs to protect privacy while proving membership in a particular cloud.

Load-bearing premise

The proposal assumes that a cloud provider's published list of PPIDs is truthful and cannot be republished or forged by a malicious operator, since the paper does not specify who certifies that a given PPID actually belongs to that provider's data center.

Editorial extensions

If this is right

Cloud providers would be able to attest not just the software stack but also their own physical infrastructure, letting users verify that a CVM runs in a data center the provider controls.
Attestation verification would carry information relevant to physical-attack risk, since the user can now check the operator rather than guess.
Standardizing PPID-based binding across different TEE architectures would affect live migration, which the paper notes must be handled by re-attestation because the PPID is hardware-dependent.
Zero-knowledge proofs over DCAP attestations could prove membership in a provider's hardware pool without revealing which exact machine is used, preserving privacy.

Reading between the lines

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

The proposal implicitly turns cloud providers' self-published hardware registries into trust anchors; a natural next step is defining who certifies and audits those lists, since without governance the binding only shifts the trust anchor.
The same binding logic could extend to confidential containers or confidential Kubernetes nodes, where operator identity matters even more because nodes may be spread across multiple providers.
A concrete community experiment would be to instrument a DCAP quote verifier to surface the PPID and check whether public cloud instances expose stable PPIDs across reboots; if PPIDs change or are masked, the proposal needs a fallback mechanism.
The binding could be cross-checked with network-level location clues, such as latency bounds or provider IP ranges, to reduce reliance on the provider's word about which data center hosts the attestation.

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.

Desk Editor's Note

read the letter

Colleague,

This is a workshop paper, and it reads like one: a short, readable position statement with no implementation, no measurements, and no formal result. The core observation is correct and worth stating: Intel TDX and AMD SEV-SNP attestations prove that code runs on a particular CPU, but say nothing about which cloud provider physically operates that CPU, and the vendor threat models explicitly punt on physical attacks. That mismatch between what attestations certify and what deployments actually rely on is real, and the paper gives a clean description of it.

The PPID proposal is the natural thing to float, and the authors are honest about its limits. They even write that 'the trust in the cloud provider does not increase.' That sentence cuts against the intro's claim that the proposal 'closes the gap.' The stress-test note is right: the provider-maintained PPID list is an unauthenticated trust anchor. A user verifying a PPID against the provider's list is still trusting the provider to tell the truth about its own infrastructure. The problem moves one level sideways rather than being solved. This is not fatal for a discussion paper, but it should be stated as exactly what it is.

The paper also mentions zero-knowledge DCAP attestations as a privacy-preserving mechanism, but that is a pointer to existing work rather than a contribution. Cross-vendor coverage is hand-waved: Intel's PPID is discussed, AMD's CPU_ID is mentioned, and ARM is listed as a challenge, but there is no analysis of whether these identifiers have the same properties or availability.

What the paper does well is frame the design space and explicitly identify the open questions -- standardization, paravisor reproducibility, and the governance of the PPID list. It cites prior work including its own LooseSEAL post and Automata's DCAP repository, which is appropriate for a position paper.

For readers working on confidential computing deployment, it is a useful conversation starter. For a serious technical venue, it would need at least a prototype or a governance mechanism. On balance, I would send it to peer review if the venue is a workshop or position-paper track; it deserves referee attention to check the claims, but it is not a full research contribution.

I would not cite it in the next year as a technical result, but I might bring it to a reading group as a discussion prompt.

Referee Report

3 major / 5 minor

Summary. The paper observes a mismatch between the threat model of confidential VMs (which excludes physical attacks) and the trust assumptions of cloud deployment, where users must rely on the operator for physical security. It argues that TEE attestation should link a CVM to the cloud provider operating its hardware, proposes using Intel's Protected Platform Identifier (PPID) as a candidate mechanism, and introduces two discussion points: standardizing provider-bound attestation across vendors and extending TEE threat models to physical attacks. The paper is a short position paper with no prototype; it surveys attestation flows for bare-metal and paravirtualized CVMs and sketches open challenges.

Significance. If developed further, the main idea would address a real, under-explored problem: today's remote attestation certifies the software stack and CPU but not the physical environment, so users of confidential VMs cannot verify which operator hosts their workload. The paper usefully highlights that paravirtualized deployments (e.g., OpenHCL, COCONUT) add attestation components that must be reproducible, and it correctly notes the industry's fragmentation. However, the proposed PPID binding is only sketched, and the paper provides no implementation, formal analysis, or concrete protocol, so its current value is primarily as a discussion seed for the community.

major comments (3)

[Section 3 (PPID allowlist)] The central proposal relies on a cloud-provider-maintained list of hardware identifiers, but the paper does not specify how this list is authenticated, certified, or bound to the provider's identity. Without a mechanism that prevents an operator from publishing arbitrary PPIDs, a user who validates a quote against the list has only learned that a CPU is on the provider's self-declared inventory; this does not establish that the CPU is physically located in a trusted data center. The paper's own concession that 'the trust in the cloud provider does not increase' (Section 3) is symptomatic: the binding is circular because the provider is both the party being validated and the party issuing the allowlist. This is load-bearing for the paper's claim that PPID narrows the gap between TEE threat models and deployment trust, and it needs to be addressed with a governance design (e.g., signed lists, independent certification, or a public ledger).
[Sections 1 and 3 (cross-vendor identifiers)] DP1 asks for 'unification/standardization of PPID & deployments,' but the paper offers no evidence that AMD's CPU_ID or ARM CCA platform identifiers are structurally equivalent to Intel's PPID for this purpose. It is not established that these identifiers are fused at manufacturing, exposed in attestation reports (possibly in encrypted form), and resistant to cloning or migration in the same way. Since the whole solution depends on a uniform hardware identifier being available across TDX, SEV-SNP, and CCA, this load-bearing assumption must be justified with technical details or explicitly framed as an open question rather than as a proposed standard.
[Section 3 (ZK proof and protocol details)] The paper mentions using a zero-knowledge proof to show that a node runs in a particular cloud 'without disclosing which' CPU, citing repository [15]. However, it does not describe the statement being proved, the inputs (e.g., the Platform ID from a DCAP quote versus the provider's PPID list), or the verification flow. Given that the Platform ID is described as 'the encrypted PPID or derived from it,' it is unclear how a verifier can compare it against a provider allowlist without either revealing or decrypting the PPID. A concrete protocol sketch is necessary to make the proposal plausible; as written, the ZK step is only a citation.

minor comments (5)

[Section 3] There is a typo: 'first16 Bof user data' should be 'first 16 B of user data.'
[Section 2] The sentence 'Of note, VMPL0 is the highest privilege level, and VTL0 is the lowest, hinting at other implementation approaches' is unclear; it should explain how the privilege-level mappings differ between TDX and SEV-SNP and why that matters for attestation.
[Section 1] The phrase 'This closes the gap' is optimistic in view of the paper's later admission that trust in the provider does not increase; consider rephrasing to 'narrows' to avoid an internal contradiction.
[Figure 1] The caption says 'The provider controls the grey dotted boxes,' but the figure in the manuscript does not appear to show shading; ensure the figure rendering matches the caption.
[References] Key claims about LooseSEAL [12] and the ZK instantiation [15] are based on non-archival self-published sources (a forum post and a GitHub repository); for a formal report, consider adding independent references or describing the mechanisms directly in the text.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper offers a position/proposal, not a derivation, and its self-citations are background rather than load-bearing.

full rationale

The paper is a workshop position paper. Its central claim is an architectural observation: TEE attestations authenticate code/platform but do not bind a CVM to the cloud provider operating the infrastructure, so users must trust the provider for physical security. The proposed extension (bind attestation to PPID and maintain a provider list of PPIDs) is presented as a suggestion and explicitly concedes that 'the trust in the cloud provider does not increase' (Section 3). No equation is fitted, no quantity is predicted from fitted parameters, and no result is derived from its own conclusion. The cited items that overlap with the authors (Flashbots collective posts [7], [12], and Ekiden [4]) are background material; the PPID mechanism itself is described from Intel/AMD attestation documentation and is not contingent on those citations. The limitation that the PPID-to-provider mapping relies on the provider's own list is a real correctness/trust concern, but it is not a circularity: the paper does not claim the list removes provider trust, and it does not use the desired conclusion as an input to its argument. Under the specified criteria, this is a no-circularity finding.

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

The central claim rests on a small set of domain assumptions taken from vendor threat models and on two ad-hoc assumptions about the deployment environment: that a hardware-bound identifier is exposed in attestation quotes and that providers publish trustworthy allowlists. No free parameters are fitted because the paper contains no experiments or derivations. No new entities are invented: the PPID is an existing Intel identifier and CPU_ID is an existing AMD concept.

assumptions (5)

domain assumption VM-based TEEs do not defend against physical attacks such as probing and fault injection; physical security is left to the infrastructure operator.
Motivates the entire paper. Stated in Section 1 and 2 with references to AMD and Intel threat models; if this were false, the proposed attestation extension would be unnecessary.
domain assumption Intel attestation quotes include a PPID that is encrypted with Intel's PCS public key and cannot be altered by the platform operator.
Section 3 describes the PPID and its encryption. The paper does not verify this claim beyond citing Intel DCAP documentation.
ad hoc to paper AMD SEV-SNP and ARM CCA platforms expose an identifier equivalent to Intel's PPID in a form usable for provider binding.
Section 3 mentions AMD CPU_ID but gives no details and does not discuss ARM CCA; the proposal assumes this is available.
ad hoc to paper Cloud providers will publish and maintain correct PPID allowlists and users can query them.
Section 3 states the provider must keep such a list, but no trust anchor or maintenance process is specified.
domain assumption Zero-knowledge proof systems for DCAP attestations exist and can be extended to keep the PPID private while proving provider membership.
Section 3 cites the Automata DCAP attestation repository; no proof or implementation is given in this paper.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Narrowing the Gap between TEEs Threat Model and Deployment Strategies." pith.science (2026). https://pith.science/paper/WRT5BWJG

@misc{pith2026250614964,
  author       = {Pith},
  title        = {Pith review of: Narrowing the Gap between TEEs Threat Model and Deployment Strategies},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WRT5BWJG}},
  note         = {Machine review of arXiv:2506.14964}
}

read the original abstract

Confidential Virtual Machines (CVMs) provide isolation guarantees for data in use, but their threat model does not include physical level protection and side-channel attacks. Therefore, current deployments rely on trusted cloud providers to host the CVMs' underlying infrastructure. However, TEE attestations do not provide information about the operator hosting a CVM. Without knowing whether a Trusted Execution Environment (TEE) runs within a provider's infrastructure, a user cannot accurately assess the risks of physical attacks. We observe a misalignment in the threat model where the workloads are protected against other tenants but do not offer end-to-end security assurances to external users without relying on cloud providers. The attestation should be extended to bind the CVM with the provider. A possible solution can rely on the Protected Platform Identifier (PPID), a unique CPU identifier. However, the implementation details of various TEE manufacturers, attestation flows, and providers vary. This makes verification of attestations, ease of migration, and building applications without relying on a trusted party challenging, highlighting a key limitation that must be addressed for the adoption of CVMs. We discuss two points focusing on hardening and extensions of TEEs' attestation.

Figures

Figures reproduced from arXiv: 2506.14964 by the authors.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

20 extracted references · 14 canonical work pages

[15]

Automata Network. 2025. Automata DCAP Attestation. https://github.com/ automata-network/automata-dcap-attestation Accessed: 2025-04-03

work page 2025
[1]

2022.GitHub - AMDESE/AMDSEV: AMD Secure Encrypted Virtualization

AMD. 2022.GitHub - AMDESE/AMDSEV: AMD Secure Encrypted Virtualization. (Accessed on 10/15/2023)

work page 2022
[2]

AMD. 2025. SEV Secure Nested Paging Firmware ABI Specifica- tion. https://www.amd.com/content/dam/amd/en/documents/epyc-technical- docs/specifications/56860.pdf [Online; accessed 14. Feb. 2025]

work page 2025
[3]

Apple Inc. [n. d.]. Hardware Integrity in Private Cloud Compute. https://security. apple.com/documentation/private-cloud-compute/hardwareintegrity. Accessed: 2025-04-01

work page 2025
[4]

Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah Johnson, Ari Juels, Andrew Miller, and Dawn Song. 2019. Ekiden: A Platform for Confidentiality-Preserving, Trustworthy, and Performant Smart Contracts. In2019 IEEE European Symposium on Security and Privacy (EuroS&P). 185–200. doi:10.1109/EuroSP.2019.00023

arXiv 2019
[5]

Intel. 2024. Intel TDX DCAP: Quote Generation Library and Quote Verification Library. https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_ TDX_DCAP_Quoting_Library_API.pdf [Online; accessed 14. Feb. 2025]

work page 2024
[6]

2024.intel/tdx-module

Intel. 2024.intel/tdx-module. (Accessed on 05/10/2024)

work page 2024
[7]

Quintus Kilbourn. 2024. Zero Trust Execution Environments - TEE - Trusted Execution Environment / Trustless TEEs - The Flashbots Collective. https: //collective.flashbots.net/t/zero-trust-execution-environments/3966 [Online; accessed 15. Feb. 2025]

work page 2024

Show all 20 references

[8]

Dmitrii Kuvaiskii, Dimitrios Stavrakakis, Kailun Qin, Cedric Xing, Pramod Bhato- tia, and Mona Vij. 2024. Gramine-TDX: A Lightweight OS Kernel for Confidential VMs. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Com- munications Security(Salt Lake City, UT,...

2024
[9]

Fang, Chia che Tsai, and Raluca Ada Popa

Dayeol Lee, Dongha Jung, Ian T. Fang, Chia che Tsai, and Raluca Ada Popa
[10]

Mengyuan Li, Luca Wilke, Jan Wichelmann, Thomas Eisenbarth, Radu Teodor- escu, and Yinqian Zhang. 2022. A Systematic Look at Ciphertext Side Channels on AMD SEV-SNP. In2022 IEEE Symposium on Security and Privacy (SP). 337–351. doi:10.1109/SP46214.2022.9833768

2022
[11]

Rujia Li, Qin Wang, Qi Wang, David Galindo, and Mark Ryan. 2022. SoK: TEE- assisted Confidential Smart Contract. arXiv:2203.08548 [cs.CR] https://arxiv. org/abs/2203.08548

2022 arXiv
[12]

Moe Mahhouk. 2024. Loose SEAL: Enabling Crash-Tolerant TDX Applications by Utilizing SGX Sealing Provider Sidecar - TEE - Trusted Execution Environment - The Flashbots Collective. https://collective.flashbots.net/t/loose-seal- enabling-crash-tolerant-tdx-applications-by-utiliz...

2024
[13]

Microsoft. 2025. openvmm. https://github.com/microsoft/openvmm [Online; accessed 14. Feb. 2025]

2025
[14]

Ménétrey, C

J. Ménétrey, C. Göttel, M. Pasin, P. Felber, and V. Schiavoni. 2022. An Ex- ploratory Study of Attestation Mechanisms for Trusted Execution Environments. arXiv:2204.06790 [cs.CR]

2022 arXiv
[16]

Caroline Perezvargas. 2023. Confidential VMs on Azure. https://techcommunity. microsoft.com/blog/windowsosplatform/confidential-vms-on-azure/3836282

2023
[17]

Karanjai Rabimba, Lei Xu, Lin Chen, Fengwei Zhang, Zhimin Gao, and Weidong Shi. 2021. Lessons Learned from Blockchain Applications of Trusted Execution Environments and Implications for Future Research. InWorkshop on Hardware and Architectural Support for Security and Privacy....

2021 doi
[18]

M. U. Sardar, S. Musaev, and C. Fetzer. 2021. Demystifying Attestation in Intel Trust Domain Extensions via Formal Verification.IEEE Access9 (2021), 83067– 83079. doi:10.1109/ACCESS.2021.3087421

2021
[19]

SUSE. 2025. svsm. https://github.com/coconut-svsm/svsm [Online; accessed 14. Feb. 2025]. Accepted to the 8th Edition of the System Software for Trusted Execution (SysTEX) ’25 Workshop, co-located with EuroS&P ’25

2025
[2020]

In29th USENIX Security Symposium (USENIX Security 20)

An Off-Chip Attack on Hardware Enclaves via the Memory Bus. In29th USENIX Security Symposium (USENIX Security 20). USENIX Association, 487–504. https://www.usenix.org/conference/usenixsecurity20/presentation/lee-dayeol

Pith tools

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

[1] [15]

Automata Network. 2025. Automata DCAP Attestation. https://github.com/ automata-network/automata-dcap-attestation Accessed: 2025-04-03

work page 2025

[2] [1]

2022.GitHub - AMDESE/AMDSEV: AMD Secure Encrypted Virtualization

AMD. 2022.GitHub - AMDESE/AMDSEV: AMD Secure Encrypted Virtualization. (Accessed on 10/15/2023)

work page 2022

[3] [2]

AMD. 2025. SEV Secure Nested Paging Firmware ABI Specifica- tion. https://www.amd.com/content/dam/amd/en/documents/epyc-technical- docs/specifications/56860.pdf [Online; accessed 14. Feb. 2025]

work page 2025

[4] [3]

Apple Inc. [n. d.]. Hardware Integrity in Private Cloud Compute. https://security. apple.com/documentation/private-cloud-compute/hardwareintegrity. Accessed: 2025-04-01

work page 2025

[5] [4]

Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah Johnson, Ari Juels, Andrew Miller, and Dawn Song. 2019. Ekiden: A Platform for Confidentiality-Preserving, Trustworthy, and Performant Smart Contracts. In2019 IEEE European Symposium on Security and Privacy (EuroS&P). 185–200. doi:10.1109/EuroSP.2019.00023

arXiv 2019

[6] [5]

Intel. 2024. Intel TDX DCAP: Quote Generation Library and Quote Verification Library. https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_ TDX_DCAP_Quoting_Library_API.pdf [Online; accessed 14. Feb. 2025]

work page 2024

[7] [6]

2024.intel/tdx-module

Intel. 2024.intel/tdx-module. (Accessed on 05/10/2024)

work page 2024

[8] [7]

Quintus Kilbourn. 2024. Zero Trust Execution Environments - TEE - Trusted Execution Environment / Trustless TEEs - The Flashbots Collective. https: //collective.flashbots.net/t/zero-trust-execution-environments/3966 [Online; accessed 15. Feb. 2025]

work page 2024