Engineer and audit systems where the infrastructure itself is the adversary:\nthe cloud operator, the hypervisor, the node admin, a co-tenant, or anyone\nwith physical access to memory. Two tool families, one skill: hardware TEEs\nwith remote attestation (trust silicon + verify it), and cryptographic PETs\nthat compute on encrypted data (trust only math, pay orders of magnitude for\nit). The boundary with sota-sandboxing is direction: sandboxing protects the\nhost from the workload; this skill protects the workload from the host. Both\ncan apply to the same system.
Two modes. Pick one explicitly at the start of the task.
\nUse when designing or implementing confidentiality-in-use for new or changed\nsystems.
\nrules/01 §2, §7): operator, hypervisor,\nco-tenant, physical, or \"the other party in a joint computation\". If no\nadversary survives scrutiny, stop — TLS + at-rest encryption + KMS custody\n(sota-secrets-management) already covers you.rules/01\n§4): transport/at-rest → HSM/KMS → confidential VM → process enclave →\nPET. Write the rung and its rationale into the design doc.rules/02 §7) by\nworkload shape (lift-and-shift VM, container, process, GPU inference) —\nusing the latest stable platform generation; verify current provider\nsupport at design time.rules/03): what evidence, who\nverifies (hosted vs self-hosted), what policy, and — decisive — what the\nattestation result gates (key release, secret injection, channel\nestablishment). Attestation that gates nothing is decoration.rules/04 §1, §6):\nconfidential nodes (operator excluded, cluster admin not) vs confidential\npods/CoCo (both excluded); route secrets through attest-then-release (KBS),\nnot K8s Secrets; plan the degraded debugging story up front.rules/05): most \"we\nneed FHE\" asks are a TEE or differential-privacy problem in disguise;\nwhen a PET is right, use standard parameter sets and vetted libraries\n(latest stable) only.rules/01 §2, rules/02 §6, rules/04\n§7): side channels, availability (never protected — the host can always\nkill you), and the TEE vendor in the TCB.Deliverables: named adversary + chosen rung, TEE/PET selection with\nrationale, the attestation flow diagram (RATS roles) and what it gates,\nverification policy (debug-mode rejection, TCB handling, freshness), and the\nresidual-risk list.
\nUse when reviewing systems that claim confidential computing, or that should.
\nProcedure: inventory data-in-use exposure (what runs where, who operates it)\n→ check claims against the definition (rules/01 §1: attested, hardware-based\nTEE — or it isn't CC) → walk the attestation chain end to end (rules/03:\ndoes anything consume the result? debug mode rejected? TCB current? nonce\nfresh?) → on K8s, verify the layer matches the threat claim (rules/04) →\nfor PETs, verify parameters/libraries/threat models (rules/05) → run every\nloaded rules file's audit checklist.
Severity conventions
\nFinding format: file:line | rule | severity | effort | fix (canonical\ncross-domain format from the router).
| File | \nRead this when... | \n
|---|---|
rules/01-threat-model-and-selection.md | \ndeciding 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. | \n
rules/02-tee-technologies.md | \nchoosing 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. | \n
rules/03-remote-attestation.md | \ndesigning 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. | \n
rules/04-confidential-kubernetes.md | \nrunning 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. | \n
rules/05-pets-coed.md | \ncomputing 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. | \n
01).03).01,05).03).03).02).02).04).01,02,04).05).