Sota Confidential Computing

SOTA Confidential Computing & PETs

Purpose

Engineer and audit systems where the infrastructure itself is the adversary: the cloud operator, the hypervisor, the node admin, a co-tenant, or anyone with physical access to memory. Two tool families, one skill: hardware TEEs with remote attestation (trust silicon + verify it), and cryptographic PETs that compute on encrypted data (trust only math, pay orders of magnitude for it). The boundary with sota-sandboxing is direction: sandboxing protects the host from the workload; this skill protects the workload from the host. Both can apply to the same system.

Two modes. Pick one explicitly at the start of the task.

BUILD mode

Use when designing or implementing confidentiality-in-use for new or changed systems.

1. Name the adversary first (rules/01 §2, §7): operator, hypervisor, co-tenant, physical, or "the other party in a joint computation". If no adversary survives scrutiny, stop — TLS + at-rest encryption + KMS custody (sota-secrets-management) already covers you.
2. Pick the lowest sufficient rung of the escalation ladder (rules/01 §4): transport/at-rest → HSM/KMS → confidential VM → process enclave → PET. Write the rung and its rationale into the design doc.
3. Choose the TEE technology from the selection table (rules/02 §7) by workload shape (lift-and-shift VM, container, process, GPU inference) — using the latest stable platform generation; verify current provider support at design time.
4. Design attestation before deployment (rules/03): what evidence, who verifies (hosted vs self-hosted), what policy, and — decisive — what the attestation result gates (key release, secret injection, channel establishment). Attestation that gates nothing is decoration.
5. On Kubernetes, pick the layer deliberately (rules/04 §1, §6): confidential nodes (operator excluded, cluster admin not) vs confidential pods/CoCo (both excluded); route secrets through attest-then-release (KBS), not K8s Secrets; plan the degraded debugging story up front.
6. If hardware trust is unacceptable, triage PETs (rules/05): most "we need FHE" asks are a TEE or differential-privacy problem in disguise; when a PET is right, use standard parameter sets and vetted libraries (latest stable) only.
7. Document the honest limits (rules/01 §2, rules/02 §6, rules/04 §7): side channels, availability (never protected — the host can always kill you), and the TEE vendor in the TCB.

Deliverables: named adversary + chosen rung, TEE/PET selection with rationale, the attestation flow diagram (RATS roles) and what it gates, verification policy (debug-mode rejection, TCB handling, freshness), and the residual-risk list.

AUDIT mode

Use when reviewing systems that claim confidential computing, or that should.

Procedure: inventory data-in-use exposure (what runs where, who operates it) → check claims against the definition (rules/01 §1: attested, hardware-based TEE — or it isn't CC) → walk the attestation chain end to end (rules/03: does anything consume the result? debug mode rejected? TCB current? nonce fresh?) → on K8s, verify the layer matches the threat claim (rules/04) → for PETs, verify parameters/libraries/threat models (rules/05) → run every loaded rules file's audit checklist.

Severity conventions

• Critical — "confidential" claim with no attestation or attestation that gates nothing; debug-mode TEE accepted in prod; secrets delivered via a channel the excluded party controls (e.g. K8s Secrets to a CoCo pod); hand-rolled FHE/ZKP parameters or circuits.
• High — plain SEV/SEV-ES where SNP-class integrity is required; evidence verified without chain-to-vendor-root or TCB check; no re-attestation or reference-value rotation plan (TCB recovery will break prod); confidential nodes sold as protection against the cluster admin.
• Medium — stale/undocumented side-channel posture (SMT, ciphertext side channels); attestation results not monitored as security signals; missing in-guest storage encryption for confidential pods.
• Low — hygiene: undocumented residual risks, missing break-glass debug policy, PET performance assumptions unbenchmarked.

Finding format: file:line | rule | severity | effort | fix (canonical cross-domain format from the router).

Rules index

Top-10 non-negotiables

1. No attestation, no confidential computing. The claim requires a hardware-based, attested TEE (CCC definition); memory encryption alone is marketing (01).
2. Attestation must gate something — key release, secret injection, channel establishment. Dashboard-only attestation is a Critical finding (03).
3. Pick the lowest sufficient rung: don't deploy an enclave where a KMS suffices, or FHE where a confidential VM does (01,05).
4. Reject debug-mode TEEs in production, verify the evidence chain to the silicon vendor's root, and treat out-of-date TCB as a policy decision — never a silent accept (03).
5. Freshness is part of the proof: bind a nonce or channel key into evidence; re-attest on schedule and on TCB events (03).
6. SNP-class integrity or it doesn't count: plain SEV/SEV-ES memory encryption without integrity and runtime attestation is insufficient against a malicious hypervisor (02).
7. State the Nitro trust model honestly: isolation + attestation with the provider still in the TCB — different from SEV-SNP/TDX operator exclusion (02).
8. Confidential nodes ≠ confidential pods: nodes exclude the cloud operator but not the cluster admin; for pod-level claims, secrets flow attest-then-release (KBS), never K8s Secrets (04).
9. Side channels and availability are out of scope by design — document the posture (SMT, ciphertext side channels, host DoS) in every design doc instead of assuming them away (01,02,04).
10. PETs use vetted libraries (latest stable) and standard parameter sets only; hand-rolled FHE parameters or ZKP circuits without audit are Critical findings, and FHE alone gives confidentiality, not result integrity (05).