Sota Confidential Computing

---
name: sota-confidential-computing
description: >-
  State-of-the-art confidential computing and cryptographic PETs (2026) for
  BUILDING and AUDITING systems that protect workloads and data in use from
  the infrastructure they run on — the inverse of sandboxing. Covers TEE
  selection (AMD SEV-SNP, Intel TDX, ARM CCA realms, SGX enclaves, AWS Nitro
  Enclaves, NVIDIA confidential GPUs), memory encryption vs attested isolation
  (TME/TME-MK/MKTME), remote attestation (RATS RFC 9334, evidence appraisal,
  attest-then-release, RA-TLS, TCB recovery), confidential VMs/nodes/pods on
  Kubernetes (Confidential Containers/CoCo, Kata, Trustee KBS), and computing
  on encrypted data without hardware trust — FHE, MPC/threshold, ZKP,
  PSI/OPRF. Trigger keywords: confidential computing, TEE, enclave, SEV-SNP,
  TDX, ARM CCA, SGX, Nitro Enclaves, confidential VM, remote attestation,
  attestation report, KBS, CoCo, Kata, Trustee, MKTME, confidential GPU, FHE,
  homomorphic encryption, MPC, ZKP, zero-knowledge, PSI, data in use, COED.
---

# 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

| File | Read this when... |
|---|---|
| `rules/01-threat-model-and-selection.md` | deciding whether confidential computing is warranted at all: the CCC definition test (memory encryption alone ≠ CC), what CC does/never protects against, inverse-of-sandboxing framing, the five-rung escalation ladder, legitimate drivers, anti-patterns, adversary→mechanism decision table. Read first in every engagement. |
| `rules/02-tee-technologies.md` | choosing or judging TEE hardware: SEV→SEV-ES→SEV-SNP insufficiency ladder, TDX on TME/TME-MK (encryption vs integrity vs attestation test), ARM CCA status, SGX enclaves + LibOS reality, Nitro Enclaves' different trust model, NVIDIA confidential GPUs for AI, Wasm-in-TEE, side-channel/physical-attack posture, workload-shape selection table. |
| `rules/03-remote-attestation.md` | designing or auditing the trust mechanism: RATS (RFC 9334) roles mapped to real products, attest-then-release as the enforcement pattern, evidence hard rules (debug mode, cert chain, TCB status, nonce freshness), hosted vs self-hosted verifiers, reference-value management and TCB recovery, RA-TLS, re-attestation and monitoring. |
| `rules/04-confidential-kubernetes.md` | running confidential workloads on K8s: confidential nodes vs confidential pods (two threat models), the CoCo stack (Kata, guest pull, Trustee KBS, peer-pods, agent policy), operational changes (secrets via KBS, degraded debugging, in-guest storage encryption), image supply-chain interplay, deployment-shape choice, honest limitations. |
| `rules/05-pets-coed.md` | computing on encrypted data without hardware trust: decision-first triage, FHE scheme families (BGV/BFV, CKKS, TFHE) + standardization anchors (ISO/IEC 28033, NIST PEC) + honest performance reality, MPC/threshold and collusion assumptions, ZKP engineering risks (circuits as security-critical code), PSI/OPRF workhorses, TEE-vs-PET-vs-DP selection table and hybrids. |

---

## 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`).