{"id":"b737686c-27d2-4de5-aab2-992164ea51ec","arxiv_id":"2506.14964","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"TEE attestation should include a hardware-bound platform identifier (PPID) so users can verify which cloud provider's infrastructure hosts a confidential VM.","lead":"This paper argues that confidential cloud computing's attestation reports do not tell users which cloud provider physically hosts their virtual machine. The authors suggest using a hardware CPU identifier, the PPID, to bind attestations to a specific provider and discuss the standardization work this would require.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The PPID-based binding does not identify the provider: the provider-maintained PPID list is an unauthenticated trust anchor, so the original blind-trust gap remains.","rationale":"The reader's weakest_assumption identifies the same concern: without a governance mechanism for the provider-maintained PPID list, the attestation binding offers no real assurance. I agree with that assessment, and it is the single most load-bearing point in the paper. The paper's observation that current CVM attestations do not identify the physical operator is coherent and supported by vendor threat-model statements, so the contribution remains useful as a workshop position paper. However, the proposed PPID-based fix does not actually close the gap unless the CPU-to-provider mapping is independently certifiable, and no such mechanism is specified. This does not make the paper's observation wrong, and it does not warrant rejection; it does mean the central proposal should be treated as a discussion point rather than a validated solution. The existing CONDITIONAL verdict is therefore appropriate, and no adjustment is needed.","tokens_in":4799,"tokens_out":3079,"duration_ms":33009,"concrete_test":"Take a real Intel DCAP attestation quote from a CVM and follow the Section 3 flow: extract the platform ID/PPID, consult a provider-published hardware identifier list, and verify the binding without relying on the provider's own statement. If the only authenticable assertion is the provider's self-published list, with no independent certification authority and no signed manifest with a public audit log, then the scheme does not reduce blind trust. Concretely, attempt to verify a quote on a cloud VM against a list both with and without trusting the provider's web endpoint; if both paths succeed identically, the PPID extension adds no verifiable operator binding.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3 proposes that 'the cloud provider must keep a list of its publicly available hardware identifiers so the users can then validate the provided PPID.' This list is the decisive trust anchor. Nothing in the paper specifies who attests to the list, how a user verifies that a given PPID actually belongs to a physically protected data center operated by the claimed provider, or what prevents a provider from publishing any PPID it controls. The paper explicitly concedes that 'the trust in the cloud provider does not increase.' That concession undercuts the gap-narrowing claim: PPID is a hardware-unique identifier, but the CPU-to-operator mapping is an unauthenticated provider assertion. A user who verifies a PPID against the provider's list has still trusted the provider to tell the truth about its own infrastructure. Remote attestation would prove 'this code runs on CPU with PPID X' but not 'this CPU is hosted by provider P in a trusted data center.' The problem the paper identifies, blind trust in whoever answers the API, is therefore not solved; it is moved one step sideways into trust in the list maintainer. This is load-bearing for the central claim that attestation 'should be extended to bind the CVM with the provider.'","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":5007,"tokens_out":10688,"duration_ms":90555,"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":[{"comment":"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).","section":"Section 3 (PPID allowlist)"},{"comment":"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":"Sections 1 and 3 (cross-vendor identifiers)"},{"comment":"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.","section":"Section 3 (ZK proof and protocol details)"}],"minor_comments":[{"comment":"There is a typo: 'first16 Bof user data' should be 'first 16 B of user data.'","section":"Section 3"},{"comment":"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":"Section 2"},{"comment":"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.","section":"Section 1"},{"comment":"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.","section":"Figure 1"},{"comment":"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.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a workshop position paper, and its contribution is a timely observation rather than a validated mechanism. The main substantive issue is the under-specified governance of the PPID allowlist; I believe this can be fixed by adding a discussion of trust anchors and certification. Note that several key references are self-published (Flashbots forum, GitHub), which may be a concern for a journal readership. If the paper is revised for a workshop format, these may be acceptable, but for a journal, the authors should strengthen the evidence base."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThis 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.\n\nThe 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.\n\nThe 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.\n\nWhat 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.\n\nFor 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.\n\nI 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.","headline":"A useful position paper on the attestation-to-provider gap; the PPID fix is honest about shifting trust, not removing it.","tokens_in":5538,"tokens_out":3358,"would_cite":false,"duration_ms":28504,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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).","keywords":["confidential virtual machines","trusted execution environments","remote attestation","Protected Platform Identifier (PPID)","threat model","cloud provider trust","data-in-use protection","attestation standardization"],"falsifier":"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.","tokens_in":4560,"feed_emoji":"☁️","tokens_out":7705,"duration_ms":79211,"temperature":0.7,"pith_summary":"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.","feed_headline":"TEE attestation must name the cloud provider, not just the chip","feed_subtitle":"Without a hardware link to the operator, users cannot assess physical-attack risk in confidential VMs.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Prior proposal that relies on PPID to derive keys from CVMs on the same machine; this paper builds directly on it.","marker":"[12]"},{"why":"DCAP quoting library API that describes the PPID-based platform identifier in attestation quotes.","marker":"[5]"},{"why":"SEV-SNP firmware ABI that defines the CPU_ID used for the equivalent identifier on AMD CPUs.","marker":"[2]"},{"why":"Existing zero-knowledge instantiation for DCAP attestations that the paper proposes to extend for privacy-preserving PPID verification.","marker":"[15]"},{"why":"A hardware-integrity certification approach that certifies physical location, referenced as an alternative to PPID lists.","marker":"[3]"},{"why":"Documents the SEV-SNP threat model excluding memory integrity and side channels, motivating the need for provider-level trust.","marker":"[10]"},{"why":"Provides TDX attestation background used to frame the software-attestation scope the paper aims to extend.","marker":"[8]"}],"fun_headline_variants":["TEE attestation should include the provider, not just the chip","Closing the TEE gap: attestation must name the hardware host","Without provider binding, CVM users can't assess physical risk","PPID could link confidential VMs to the cloud provider they trust","Attestation needs to prove which cloud hosts your confidential VM"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["TEE attestation should include the provider, not just the chip","Closing the TEE gap: attestation must name the hardware host","Without provider binding, CVM users can't assess physical risk","PPID could link confidential VMs to the cloud provider they trust","Attestation needs to prove which cloud hosts your confidential VM"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000605,"raw_usage":{"total_tokens":2810,"prompt_tokens":920,"completion_tokens":1890,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":536,"completion_tokens_details":{"reasoning_tokens":1815}},"tokens_in":536,"tokens_out":1890,"duration_ms":12683,"temperature":1.0,"reasoning_tokens":1815,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T00:10:01.816365+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Prior proposal that relies on PPID to derive keys from CVMs on the same machine; this paper builds directly on it."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"DCAP quoting library API that describes the PPID-based platform identifier in attestation quotes."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"SEV-SNP firmware ABI that defines the CPU_ID used for the equivalent identifier on AMD CPUs."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Existing zero-knowledge instantiation for DCAP attestations that the paper proposes to extend for privacy-preserving PPID verification."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"A hardware-integrity certification approach that certifies physical location, referenced as an alternative to PPID lists."}],"review_version":1}