{"id":"05be2082-81b3-42f6-b6e9-ffc1aa696b4f","arxiv_id":"2412.03550","paper_version":2,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Argos shows that an integrity-only hypervisor enclave signing a final transcript with a discrete TPM can make FHE evaluation verifiable against malicious servers, with reported single-digit percent overhead when the 196ms TPM attestation is batched.","lead":"Argos adds verifiability to fully homomorphic encryption using a commodity PC's TPM and virtualization hardware, instead of expensive cryptographic proofs. The design keeps all secrets off the CPU, so microarchitectural side channels have nothing to steal, and achieves overheads of a few percent when attestation is batched.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"TPM quote is an unauthenticated signing oracle: a malicious OS can extend a PCR with a fake transcript hash and obtain a quote that passes all client checks, so attestation soundness does not follow as written.","rationale":"The central claim is maliciously-secure verifiable FHE with negligible overhead, and its proof reduces to soundness of the Argos attestation scheme. The most load-bearing condition is that a TPM quote over PCRs proves that the security monitor executed the transcript. But TPM quote signatures do not authenticate the caller, and PCRs are extendable by any software with TPM device access. The paper itself describes the TPM as a 'signing oracle' (Section 4.2), which is precisely why the gap is dangerous: an oracle will sign whatever PCR values it is asked to sign. Unless the security monitor traps every TPM command from the untrusted OS -- a mechanism never described in the paper -- a malicious OS can forge a valid-looking attested transcript for an arbitrary output. This is not merely the reader's 'bug-free TCB' concern; even a bug-free security monitor and a correctly functioning TPM are insufficient under the stated threat model. The concern is concrete and testable with the open-source prototype. The other issues noted by the reader (amortization of the 196 ms TPM signature, omitted PIR/PSI security proofs, missing error bars) are secondary or could be addressed conditionally, but this one attacks the soundness of the core construction. Therefore the verdict should move from CONDITIONAL to REJECT as written; a revision that specifies, implements, and verifies TPM command access control could change that assessment.","tokens_in":38024,"tokens_out":9713,"duration_ms":109513,"concrete_test":"Run the released Argos prototype with an unmodified Linux kernel as the untrusted OS. From a root shell, use tpm2-tools to (1) extend the transcript PCR (e.g., PCR 17) with sha256 of a fake transcript hash and (2) issue tpm2_quote over PCRs that include the DRoT boot measurements and PCR 17. Feed the resulting quote, along with the fake output and the correct client input/binary reference, into the Argos client verification routine. If verification succeeds, the attestation transcript is not bound to the security monitor and the claimed malicious security is falsified. If the security monitor is expected to trap TPM accesses, first demonstrate that TPM commands issued from the OS are blocked; the paper should document and implement this mechanism.","verdict_should_be":"REJECT","load_bearing_attack":"Section 5.4 and Section 8.1 bind attestation to a TPM quote over PCRs containing the security-monitor measurement and a transcript hash. This is only meaningful if the party that extends the transcript PCR is the security monitor. In TPM 2.0, TPM2_Extend and TPM2_Quote are unauthenticated commands: the TPM does not attest to which software invoked them. The Section 2 threat model explicitly allows a malicious OS. That OS can read the public client inputs and the public enclave binary, compute the transcript hash for a forged output, extend the designated PCR with that hash, and request a quote. The quote will still contain the honest DRoT measurements of the security monitor from boot, so the client-side checks in Section 5.4 -- genuine TPM key, correct security-monitor measurement, matching transcript hash -- all pass. Consequently, the soundness claim in Section 5.5 ('soundness reduces to the soundness of the TPM signature scheme') does not hold unless the design also prevents the OS from directly invoking the TPM signing oracle. The paper never states or justifies such a mechanism, and Appendix A undercuts it: 'the TPM is merely a subordinate to the RoT and the software in the chain of trust, as it needs to be instructed and fed inputs to extend its internal measurements.' A malicious OS is exactly such software. This is a design-level gap in the attestation proof system, independent of TCB bugs or hardware misbehavior.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"Argos is an enclave platform purpose-built to add verifiability and malicious security to FHE without cryptographic proof systems. The core idea is to run FHE evaluation inside an integrity-only hypervisor-based enclave, keep all attestation secrets in a discrete TPM outside the CPU, and replace per-message attestation with a single TPM quote over a transcript accumulated by the security monitor (binary hash, inputs, outputs, and, for PIR/PSI, a database commitment). Because no secret ever enters the CPU or memory hierarchy, the paper argues that microarchitectural side channels and transient-execution attacks are eliminated by construction. The paper formalizes circuit-level vFHE (correctness, completeness, soundness, IND-CCA1-style security), gives a construction and proof sketch, extends the formalism to authenticated PIR and PSI, and reports a Tyche-based prototype evaluated with the SEAL library, measuring roughly 0-8% overhead over semi-honest baselines on commodity hardware.","tokens_in":38218,"tokens_out":24914,"duration_ms":228194,"significance":"If the security claims hold, this is an important result for applied FHE: it offers a practical route from semi-honest to malicious security at single-digit-percent overhead instead of the 4-7 orders of magnitude of cryptographic proofs, on commodity hardware and with an open-source prototype (a Tyche fork; repository given in Section 4.3). The design insight is genuinely useful: for integrity-only FHE workloads, the confidentiality problem, and with it the microarchitectural side-channel problem, largely disappears because the only secret is the signing key, which is confined to a microarchitecturally isolated coprocessor. The paper is honest about its TCB assumptions (bug-free 18KLOC monitor and application, functionally correct hardware, constant-time TPM), and the formal template for circuit-level vFHE extends prior work by Viand et al. The fixed-cost batching argument and the PIR/PSI case studies address real deployment bottlenecks. The main risk is that the attestation soundness argument is incomplete as written, leaving the central claim unproven until the TPM access-control mechanism is specified.","major_comments":[{"comment":"The stress-test concern about the TPM being an unauthenticated signing oracle is well-founded and load-bearing for the paper's central soundness claim. Section 8.1 describes attestation as the security monitor loading the transcript hash into a PCR and requesting a TPM quote, and Section 5.5 concludes that soundness 'reduces to the soundness of the TPM signature scheme.' However, TPM2_Extend and TPM2_Quote authenticate only the PCR/key authorization values, not the identity of the calling software, and Section 2's threat model grants the adversary control of the OS. A malicious OS can compute the transcript hash for a forged output, extend the transcript PCR itself, and request a quote from the same TPM signing key; the quote still contains the genuine DRoT measurement of the security monitor from boot, so the client-side checks in Section 5.4 (genuine TPM key, correct security-monitor measurement, matching transcript hash) all pass. The paper never states any mechanism that gives the security monitor exclusive access to the TPM command interface (for example, EPT-based exclusion of the TPM MMIO region from all guest domains, or PCR/authorization values known only to the monitor), and Appendix A is explicit that the TPM 'needs to be instructed and fed inputs to extend its internal measurements'; under the threat model a malicious OS is exactly such software. The authors should specify and implement an access-control mechanism that makes the security monitor the only possible caller of Extend and Quote on the relevant PCRs, or redesign the attestation protocol (and the formal soundness definition in Appendix C.2) to be sound against a TPM signing oracle that any software can invoke. As written, the Section 5.5 reduction does not go through.","section":"§5.4, §5.5, §8.1, Appendix A"},{"comment":"The IND-CCA1 reduction in Appendix D has a flaw in its simulation of the decryption oracle. In step (2), B runs Π.Verify(cy, cx, πy) using 'the latest cx it stored.' A CCA1 adversary can interleave Enc and Dec queries: it may query Enc(x1), Enc(x2), and then Dec(cy, πy) for a transcript bound to x1, in which case B verifies against the wrong ciphertext and can return ⊥ on a transcript that the real oracle would accept (or accept one it would reject), letting A distinguish the simulated game from the real one. The reduction to the IND-CPA security of the underlying FHE scheme therefore does not go through as written. The fix is local (B should maintain a table of (x, cx) pairs and select the entry matching the input hash contained in the transcript), but the proof as printed must be corrected.","section":"Appendix D"},{"comment":"The contribution list claims that Argos 'can be used to build fully malicious and authenticated PSI and PIR schemes,' and Section 7.1 refers to 'a detailed security argument' in Appendix E. In fact, Appendix E states 'We leave out the detailed proofs' and Appendix F states 'We omit these proofs in the interest of space.' The authenticated-PIR and authenticated-PSI constructions are described only at the level of 'this fits our formalism by extending h(·)' and 'adapting the vFHE properties is straightforward.' Since application-level malicious security (selective-failure defenses, database commitment binding, server privacy of PSI) is a headline contribution of the paper, the appendices need to supply the actual arguments, or Sections 7.1-7.2 and the contribution list need to be weakened to sketch-level claims.","section":"§7.1, §7.2, Appendices E, F"}],"minor_comments":[{"comment":"The performance tables report single-point averages over 10 runs with no variance or significance measures. Since the headline claims are single-digit percentages (Table 4: +0%, +6%, +2%; Tables 5-6: 1-8% ranges), the reader cannot tell whether the reported overheads are distinguishable from machine noise; please add standard deviations or per-run distributions.","section":"§9.1, §9.4"},{"comment":"The reported transcript size of 1,407 bits appears inconsistent with the sentence stating that the transcript 'contains the signature and the TPM public key along with the TPM certificates endorsed by the manufacturer,' since a single X.509 TPM certificate is typically several kilobytes. Please clarify whether the 1,407-bit figure is only the hash/measurement portion, with certificates provisioned or cached separately.","section":"§9.3"},{"comment":"The client-verification description never states explicitly that the client recomputes the hashes of the received output ciphertext(s) and compares them against the attested transcript before decrypting; this binding check is essential and should be stated as part of the verification procedure rather than left implicit.","section":"§5.4"},{"comment":"Section 5.4 refers the reader to Section 9.7 for how a reference measurement of the security monitor is obtained, but Section 9.7 does not discuss this. The trust anchor for the monitor's reference hash (reproducible builds, a publishing authority, or a secure distribution channel) needs an explicit statement.","section":"§5.4, §9.7"},{"comment":"In the attestation-soundness definitions and in the hybrid steps, verification is written as Π.Verify_sk (and the H0-H1 and H1-H2 steps swap the hybrid indices); verification under the secret key would defeat the whole game, and the index swaps make the hybrid argument hard to follow. These appear typographical but should be fixed.","section":"Appendix C.2, Appendix D"},{"comment":"The paper does not specify which PCR indices are used for the security-monitor measurements and the transcript hash, nor which TPM localities and authorization policies apply to those PCRs; specifying these details would also clarify the access-control discussion needed for the soundness concern.","section":"§8.1"}],"recommendation":"major_revision","confidential_remarks":"The main obstacle is the attestation soundness gap: the manuscript must describe concretely how the malicious OS is prevented from invoking the TPM's Extend and Quote commands, and the released prototype must be shown to enforce that (e.g., by checking that guest domains cannot access the TPM MMIO range). The authors' own Appendix A wording ('the TPM is merely a subordinate... it needs to be instructed and fed inputs') strengthens this concern rather than resolving it. I would also request the missing PIR/PSI proofs or a downgrade of the corresponding claims, and variance data for the headline overhead numbers. The novel integrity-only framing is attractive and the evaluation is useful; the issues are repairable within the scope of the paper, which is why I recommend major revision rather than rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe Argos paper has a real idea and a real bug. The idea: for FHE workloads the CPU never holds secrets, so an integrity-only enclave with all attestation secrets in a discrete TPM is sufficient; this buys side-channel resistance and drops overhead to a few percent. The prototype is built, measured, and open-sourced. That part is genuinely good.\n\nThe bug: the attestation scheme does not actually prevent the malicious OS from invoking the TPM itself. Section 5.4 has the security monitor load a transcript hash into a PCR and ask for a TPM quote, but TPM2_Extend and TPM2_Quote are unauthenticated commands. The OS—which is explicitly untrusted in the threat model—can read the public binary, compute a fake transcript hash, extend the appropriate PCR, and obtain a quote that includes the honest boot-time measurements of the security monitor. All client checks in Section 5.4 pass. Appendix A even says the TPM \"needs to be instructed and fed inputs\" by software; the OS is exactly such software. Unless the security monitor virtualizes and strictly controls all TPM access, soundness does not follow from the TPM signature alone. The paper never describes that access control. This is a hole in the main security argument, not a minor caveat.\n\nThe other soft spots are the ones already flagged in the paper: the authenticated PIR and PSI security arguments are deferred to appendices that explicitly omit the proofs; the benchmarks are averages of 10 runs without error bars; and the whole TCB is assumed bug-free. These are in line with a workshop-paper level of rigor.\n\nI would not build on this as-is until the TPM oracle problem is fixed. But the paper deserves peer review: it identifies a practically important direction, and the fix may be simple (e.g., route all TPM commands through the security monitor and trap or block OS TPM access). A serious referee should push on exactly this point.\n\nRecommendation: send to review, but flag the attestation soundness issue clearly. If the authors close that gap, this becomes a solid systems paper.","headline":"Good systems idea and open-source prototype, but the attestation scheme has a design-level hole: the malicious OS can directly invoke the TPM signing oracle and forge a valid-looking transcript.","tokens_in":38846,"tokens_out":3185,"would_cite":false,"duration_ms":29892,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper's central claim is that an integrity-only enclave, with the attestation key sealed in a discrete TPM, turns semi-honest fully homomorphic encryption into maliciously-secure verifiable FHE on commodity hardware at roughly 3%…","keywords":["fully homomorphic encryption","trusted execution environment","microarchitectural side channels","transient execution attacks","verifiable computation","malicious security","private information retrieval","private set intersection"],"falsifier":"A concrete falsifier would be a software-only attack in which a malicious OS, with no physical access, obtains a valid TPM signature over a transcript that does not correspond to the enclave binary and inputs actually executed, or causes the client's Verify to accept and decrypt a ciphertext that is not the result of $E.\\mathrm{Eval}$ of the agreed circuit on the client's ciphertext; any such demonstration would break the claimed soundness.","tokens_in":37760,"feed_emoji":"🔐","tokens_out":9538,"duration_ms":83316,"temperature":0.7,"pith_summary":"Fully homomorphic encryption lets a server compute on encrypted data, but standard FHE schemes assume the server is honest-but-curious: a malicious server can supply malformed ciphertexts, recover keys, or run the wrong function, and cryptographic proofs that fix this are four to seven orders of magnitude slower than FHE itself. Argos claims that commodity trusted hardware—a hypervisor-based security monitor plus a discrete TPM—can add verifiability to FHE against malicious servers at roughly 3% overhead for FHE evaluation and under 8% for complex protocols like private information retrieval and private set intersection. The key move is to build an integrity-only enclave that enforces program and data integrity but not confidentiality, because in FHE all data stays encrypted; the only secret is the attestation key, which is kept in a microarchitecturally isolated TPM so no software attacker can ever share CPU state with it. Attestation then becomes a single TPM signature over a transcript of the enclave binary, inputs, and outputs, made at the end of the computation, turning a semi-honest FHE scheme into a maliciously-secure verifiable one. If this holds, verifiable FHE can move beyond the semi-honest setting without paying the cost of cryptographic proof systems.","feed_headline":"FHE becomes verifiable against malicious servers at 3% overhead","feed_subtitle":"Hiding the attestation key inside a discrete TPM eliminates side channels for verifiable FHE","key_machinery":"The central object is the attested transcript: a hash chain built by the security monitor that records the dynamic-root-of-trust measurement of the security monitor, the measurement of the enclave binary and initial registers, and the hashes of every client input and output, which is extended in the security monitor and then signed once by the discrete TPM at the end of the computation. This turns remote attestation into a fixed-cost proof system $(\\Pi.\\mathrm{Gen}, \\Pi.\\mathrm{Prove}, \\Pi.\\mathrm{Verify})$ with completeness and soundness properties; the vFHE construction wraps $E.\\mathrm{Eval}$ in $\\Pi.\\mathrm{Prove}$, so that Verify must pass before the client calls $E.\\mathrm{Dec}$. The supporting mechanism that makes the transcript safe is microarchitectural isolation of the TPM: side channels are read-only and need shared resources, and since the attestation key never leaves the TPM, no attacker-controlled program in the CPU can ever share cache lines, TLBs, or branch-predictor state with the secret's use.","core_discovery":"Argos's central claim is that an integrity-only enclave platform can realize maliciously-secure, verifiable fully homomorphic encryption (vFHE) on commodity hardware, with no dedicated extensions and without cryptographic proofs. Because all application data in FHE remains encrypted end to end, the enclave needs no confidentiality: the only secret in the system is the private key used for remote attestation. Argos stores that key in a discrete TPM, whose simple microarchitecture and physical separation from the CPU make it microarchitecturally isolated, so no software attacker can mount a cache, TLB, branch-predictor, or transient-execution side channel against it. The attestation protocol is a transcript-based proof system: the security monitor records the measurement of the enclave binary and initial state together with hashes of all client inputs and outputs, and asks the TPM to sign the resulting transcript once, after the computation is finished. The paper formalizes this as a tuple $(\\Pi.\\mathrm{Gen}, \\Pi.\\mathrm{Prove}, \\Pi.\\mathrm{Verify})$ with completeness and soundness, and constructs circuit-level vFHE by wrapping $E.\\mathrm{Eval}$ inside $\\Pi.\\mathrm{Prove}$; soundness of the vFHE scheme reduces to the soundness of the TPM signature, the correctness of the dynamic root of trust and hardware isolation, and the assumption that the security monitor and application are bug-free. On a prototype built from a small micro-hypervisor security monitor and a standard BFV-based FHE library, Argos reports 3% average overhead for FHE evaluation and under 8% for authenticated PIR and PSI, while being 80 times faster than a prior SGX-based FHE-in-TEE approach.","pith_inferences":["If the integrity-only pattern is sound, it should generalize to any delegated computation whose inputs are entirely encrypted and whose evaluator holds no secret inputs, giving malicious security at hardware cost instead of proof cost.","The discrete TPM is the linchpin; replacing it with a formally verified secure element or a post-quantum signature algorithm would address the two most plausible long-term failure modes of the construction.","For latency-critical single-query workloads the roughly 196 ms TPM signing time will dominate, so the reported 3% to 8% averages likely only hold when attestation is batched over many queries."],"forward_implications":["Semi-honest FHE evaluations can be upgraded to circuit-level malicious security with about 3% average overhead and negligible communication cost, removing the need for 4 to 7 orders of magnitude of cryptographic proof overhead.","Because the TPM signature is a per-batch fixed cost, batching independent FHE evaluations amortizes attestation further, making the discrete TPM's roughly 196 ms signing time negligible for throughput workloads.","Adding a well-formedness check on the server's database and a commitment to it in the transcript gives FHE-based PIR and PSI schemes integrity (authenticated PIR and authenticated PSI) at under 8% overhead with no large offline communication.","The approach requires only commodity virtualization extensions and a discrete TPM available since roughly 2008, so its security properties do not depend on proprietary enclave hardware."],"supporting_citations":[{"why":"Supplies the micro-hypervisor security monitor that Argos forks and modifies, providing the isolation and attestation primitives.","marker":"[30]"},{"why":"Defines the vFHE formalism Argos builds on and provides the SGX-based FHE-in-TEE baseline and cryptographic-proof overhead numbers it compares against.","marker":"[131]"},{"why":"Introduces the hypervisor-based TEE architecture with a small security monitor that Argos rehabilitates for the integrity-only setting.","marker":"[93]"},{"why":"Demonstrated discrete TPM plus dynamic root of trust keeping keys off the CPU at high cost; Argos's transcript protocol is the performance fix for that approach.","marker":"[94]"},{"why":"Documents timing side channels against TPMs, motivating the constant-time cryptography assumption for the TPM in Argos's threat model.","marker":"[98]"},{"why":"Surveys 43 TEE side-channel attacks, providing the evidence that motivates exiling all secrets from the CPU to a physically separate chip.","marker":"[85]"},{"why":"Provides the FHE-based PIR implementation used as the baseline and adapted in the authenticated-PIR evaluation.","marker":"[4]"},{"why":"Provides the FHE-based PSI implementation used as the baseline and adapted in the authenticated-PSI evaluation.","marker":"[42]"}],"fun_headline_variants":["Verifiable FHE at 3% overhead using only a discrete TPM","Side-channel-free verifiable FHE via TPM, no crypto proofs","FHE verification on commodity CPUs: TPM does it with 3% overhead","Argos: verifiable FHE with a secure TPM, no costly proofs","Trusted hardware verifies FHE without exposing any secrets"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The security argument assumes the roughly 18,000-line security monitor and the enclave application are bug-free, and that the discrete TPM, dynamic root of trust, nested page tables, and IOMMU behave exactly as specified; if any one of these gives way, a malicious server could influence what the TPM signs and forge a valid-looking transcript.","fun_headline_variants_meta":{"raw":{"variants":["Verifiable FHE at 3% overhead using only a discrete TPM","Side-channel-free verifiable FHE via TPM, no crypto proofs","FHE verification on commodity CPUs: TPM does it with 3% overhead","Argos: verifiable FHE with a secure TPM, no costly proofs","Trusted hardware verifies FHE without exposing any secrets"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000598,"raw_usage":{"total_tokens":2950,"prompt_tokens":1252,"completion_tokens":1698,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":868,"completion_tokens_details":{"reasoning_tokens":1600}},"tokens_in":868,"tokens_out":1698,"duration_ms":12158,"temperature":1.0,"reasoning_tokens":1600,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T22:17:03.871775+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A concrete falsifier would be a software-only attack in which a malicious OS, with no physical access, obtains a valid TPM signature over a transcript that does not correspond to the enclave binary and inputs actually executed, or causes the client's Verify to accept and decrypt a ciphertext that is not the result of $E.\\mathrm{Eval}$ of the agreed circuit on the client's ciphertext; any such demonstration would break the claimed soundness.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces the hypervisor-based TEE architecture with a small security monitor that Argos rehabilitates for the integrity-only setting."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents timing side channels against TPMs, motivating the constant-time cryptography assumption for the TPM in Argos's threat model."}],"review_version":1}