[security][research] Define attested confidential-execution privacy profile

[RobLe3]

Problem

IICP-CX protects task content from the directory, relay and network path, but the selected provider currently loads the CX private key, decrypts the request and sends plaintext to its inference backend. A node operator or compromised host can therefore inspect the prompt, response, KV cache and other inference state.

IICP needs to determine whether an optional attested confidential-execution profile can provide a stronger, accurately bounded property without changing ordinary IICP-CX or requiring every provider to use confidential hardware.

Current behavior

• Rust, Python and TypeScript generate or load persistent provider CX keys in the normal node process.
• The normal node process decrypts before invoking its handler or backend.
• response_encryption_v1 protects the response path but does not hide plaintext from the executor.
• The confidentiality specification correctly states that the selected executor sees plaintext and that Tier-1 static provider keys do not provide forward secrecy against later key compromise.
• Existing IICP “compliance attestation” is signed conformance evidence, not hardware remote attestation.
• Local-only routing is the strongest currently implemented option against remote-operator access.

Grounded report: Execution privacy and attested confidential execution.

Prior IICP research

The June 2026 privacy reports already identified the correct broad sequence: local execution now, TEE-attested remote execution as research, FHE later. This issue supersedes the informal CX-Provider-TEE proposal with a current source audit, RATS/EAT terminology, a precise key-binding requirement and explicit CPU/GPU trust boundaries.

Desired property

When explicitly required, the accepted threat model should prevent the node operator, host administrator and ordinary host software from extracting protected request, response, KV-cache and relevant inference state from outside the attested confidential boundary.

This is not anonymity, metadata privacy, availability, or proof that measured application logic is harmless.

Research question

What is the smallest backward-compatible IICP profile that lets a consumer verify fresh evidence binding an execution CX public key to an accepted confidential runtime before releasing an encrypted task?

Proposed direction

Evaluate an optional vendor-neutral profile:

1. advertise stable support and evidence-profile identifiers through existing capability/profile mechanisms;
2. obtain fresh evidence point-to-point using a consumer nonce;
3. generate an ephemeral CX execution key inside the confidential worker;
4. cryptographically bind nonce, key, runtime measurement, configuration and security/TCB state;
5. appraise evidence using RATS roles and a consumer-selected verifier/policy;
6. preserve ordinary IICP eligibility, route tickets and dispatch;
7. decrypt, tokenize, infer, hold KV cache and encrypt the response entirely inside the measured boundary;
8. fail closed with no implicit downgrade when execution privacy is required.

The current IICP-CX envelope may remain usable if the attested ephemeral key can replace the current static recipient key safely. That must be proven against replay and substitution rather than assumed.

External standards and platforms

Research should profile, not replace:

• IETF RATS architecture (RFC 9334);
• Entity Attestation Token (RFC 9711) and relevant COSE/CWT formats;
• AMD SEV-SNP and Intel TDX CPU confidential VMs;
• NVIDIA Hopper/Blackwell confidential GPUs with a protected CPU/GPU path and composite attestation;
• current vendor TCB, endorsement, reference-value and verifier requirements.

A GPU-only quote is not sufficient when CPU-side code handles plaintext. A decrypt proxy inside a TEE is also insufficient if it forwards plaintext to host-level Ollama, LM Studio, vLLM or llama.cpp.

Threat model and non-goals

The profile must state host/root/hypervisor, malicious operator, relay and network assumptions; firmware/verifier trust; rollback/debug state; denial of service; side channels; metadata; crash dumps; logs; plugins/tools and egress.

It does not claim protection from traffic analysis, message length/timing, host denial of service, all side channels, malicious accepted runtime code or a compromised hardware/verifier trust chain.

Privacy and compatibility

• Fresh quotes, hardware identifiers and short-lived keys do not belong in directory capability records.
• Prefer normalized attestation results and pseudonymous references where possible.
• Existing nodes and ordinary CX consumers continue unchanged.
• Unknown additive profile fields must follow current compatibility rules.
• There is no silent downgrade when the caller requires execution privacy.
• Directory claims locate candidates; they do not prove current confidential execution.

Acceptance criteria

Threat model and standards

• Define protected data, adversaries, metadata and residual risks.
• Map Attester, Verifier, Relying Party, Evidence, Attestation Results, endorsements and reference values to IICP.
• Select current evidence/result encodings and verifier trust models without inventing a universal vendor quote.
• Define nonce freshness, key binding, proof of possession, expiry, replay and downgrade rules.

Architecture

• Diagram the untrusted host shell and complete confidential-worker boundary.
• Prove where plaintext, tokenizer state, model runtime, KV cache, outputs and covered tool arguments exist.
• Determine whether the existing CX envelope and associated data can safely carry an attestation-bound ephemeral recipient key.
• Define key generation, lifetime, restart, rotation and optional sealing policy.
• Define measurement/reference-value and supply-chain requirements.
• Define stable capability advertisement versus fresh point-to-point evidence.

Feasibility

• Select one supported AMD SEV-SNP or Intel TDX CPU target and verifier path.
• Build a minimal non-production proof that binds a fresh nonce and ephemeral CX public key to accepted evidence.
• Demonstrate that the corresponding private key never leaves the protected environment.
• Reject bad signature, stale/wrong nonce, key substitution, changed measurement, debug/insecure state and unacceptable TCB.
• Demonstrate no silent fallback to ordinary CX.
• Decide whether a full Rust confidential-worker prototype is justified.

Accelerated and cryptographic paths

• Document the additional composite evidence and protected-link requirements for confidential GPU inference.
• Keep FHE, MPC/hybrid and private CIP as separate research dispositions based on current performance and threat assumptions.

Outcome

• Publish a pre-normative profile recommendation, defer decision or rejection.
• Create component implementation issues only after the feasibility gate passes.
• Require external security review and conformance evidence before any public implementation claim.

Current gate — 2026-08-15

The software-only binding vectors and IICP-CX composition proof are complete. The available project host cannot produce SEV-SNP evidence. The next admissible result must come from a representative confidential VM and demonstrate in-worker key generation, exact challenge binding and private-key non-export, followed by external security review. Closed architecture issues #45, #54 and #63 are completed inputs rather than active blockers.

Next milestone order

1. Produce one real AMD SEV-SNP report with the exact caller challenge bound into REPORT_DATA.
2. Generate the ephemeral CX private key inside the measured worker and demonstrate non-export to the untrusted host.
3. Appraise current firmware, TCB, measurement, debug state and verifier trust using the selected path.
4. Publish interoperable CBOR/COSE vectors and obtain external security review.
5. Only after those gates pass, decide whether component implementation issues are justified.

Do not open cross-SDK or directory implementation work from synthetic evidence alone.

Non-goals

• Implementing production protocol code in this issue.
• Treating filesystem permissions or an ordinary container as protection from the machine administrator.
• Placing only decryption inside a TEE while inference runs on the host.
• Replacing IICP-CX for ordinary workloads.
• Making confidential hardware mandatory.
• Describing confidential execution as anonymity.
• Folding FHE/MPC runtimes or CIP internals into IICP core.

Dependencies

Coordinates with #54 (layering), #55 (capability/profile registry), #56 (fail-closed policy), #58 (route correlation if proven necessary), #63 (operator identity remains distinct from workload evidence) and #45 (future standards security wording). No deployment or production security claim is authorized.

[RobLe3]

Advanced the pre-hardware feasibility gate on main.

New evidence:

• Added a deterministic, content-free synthetic attestation-result fixture with ten scenarios.
• The verifier passes the accepted path and rejects invalid signature, wrong nonce, expiry, execution-key substitution, changed measurement, debug mode, unacceptable TCB, incomplete protected boundary, and ordinary-CX downgrade.
• Selected AMD SEV-SNP on Linux as the first hardware target. The reviewed path is /dev/sev-guest + REPORT_DATA binding + VCEK/KDS appraisal, with VirTEE snpguest v0.9.2 (dc7c8003d823856ab2156f30813bf7e565486564) as the reference verifier.
• Updated the research report and index without creating SDK or directory implementation children.

Validation:

• Direct verifier: 10/10 scenarios passed.
• Python regression tests: 3/3 passed with cryptography available.
• Full tools discovery under the declared tools requirements: 67 tests passed, 3 execution-privacy crypto tests explicitly skipped because cryptography is an optional research dependency in that isolated environment.
• Spec release integrity remains valid at suite v1.10.13 with 111 pinned artifacts.
• Ruff check and formatting passed; Markdown prose lint found no issue in the new fixture README.

Evidence boundary: this is a synthetic relying-party proof, not SEV-SNP evidence, EAT/COSE interoperability, private-key containment, or a confidential worker. The hardware-backed proof, current firmware/TCB policy, measured worker, and private-key non-export evidence remain open. No production security claim or implementation child is justified yet.

[lauraaruon-cyber]

Hi! I noticed this issue and would love to help fix it. I'm currently analyzing the best approach and will open a PR soon.

[RobLe3]

Hi! I noticed this issue and would love to help fix it. I'm currently analyzing the best approach and will open a PR soon.

Thanks for the interest. Please note that this is currently a pre-normative research and specification issue. As stated in the non-goals, we are not accepting implementation PRs for this yet.

Before writing any code, could you outline your proposed approach to binding the ephemeral CX execution key to the SEV-SNP hardware quote?

[RobLe3]

The next pre-hardware feasibility slice is merged in IICP #139, merge 4c71764.

Delivered evidence:

• selected an EAT Claims-Set encoded as a CWT, protected by tagged COSE_Sign1 and carried as application/eat+cwt, with vendor evidence kept behind platform adapters;
• defined local and explicitly trusted remote verifier models; the directory, provider and untrusted host are not trust anchors;
• bound the EAT nonce, audience, opaque candidate reference, signed dispatch-ticket digest, X25519 cnf key, runtime measurement, debug/TCB state and protected boundary;
• selected a per-attestation, per-task key lifecycle with no sealing or host-readable persistence for the first hardware proof;
• expanded the deterministic fixture to 17 scenarios covering verifier trust, timing, replay, key/profile, measurement, boundary, candidate and ticket failures;
• added a software-only proof of possession and one IICP-CX request/encrypted-response exchange without changing the existing envelope;
• rejected an unrelated private key, task replay, response-context substitution and key reuse after retirement.

Validation:

• 17/17 deterministic vector scenarios passed;
• 7/7 focused software/negative tests passed;
• 73/73 tools tests passed with the research cryptography dependency;
• 22 conformance-runner tests passed and 4 environment-dependent tests skipped;
• specification release integrity passed at suite v1.10.13 with 111 pinned artifacts;
• hosted PR validation, Ruff and prose checks passed.

Decision: the software composition result supports a hardware experiment, but it does not yet justify a Rust confidential-worker implementation issue. The defining evidence is still missing: a measured SEV-SNP worker must generate and retain the key inside the confidential boundary, bind the exact challenge into REPORT_DATA, and show that the untrusted host cannot obtain the key or plaintext. Actual CBOR/COSE interoperability vectors and external security review also remain open. No SDK, directory, capability, deployment or public privacy claim changed.

[RobLe3]

External participation lanes are now consolidated in docs/external-evidence-participation.md. This prepares the fixed starting artifact, evidence class, privacy boundary and completion record for this issue without manufacturing an external result or changing any runtime/default. PR #146 passed both hosted gates and merged as f27cca0.

[RobLe3]

2026-08-14 feasibility revalidation

The project-controlled software evidence remains reproducible:

• all 17 binding vectors passed, including signature, nonce, replay, key-substitution, measurement, debug, TCB, boundary and downgrade rejection;
• generated vectors matched the committed fixture;
• the one-shot IICP-CX composition proof passed proof-of-possession, encrypted request/response handling and key retirement;
• all seven feasibility tests passed.

The available host is Darwin arm64 and has no /dev/sev-guest, so it cannot produce the missing AMD SEV-SNP report or private-key-containment evidence. No hardware, protocol or implementation claim has been added. The next admissible evidence remains a representative SEV-SNP confidential VM run with in-worker key generation, exact REPORT_DATA challenge binding and external review.