# 01 — Threat Model & Selection: When Confidential Computing Is the Answer

Scope: the decision layer of confidential computing (CC) — what a hardware TEE
actually defends against, what it never will, and how to decide whether a workload
needs one at all. Read this before any implementation file. This file does NOT own
TEE hardware specifics (rules/02), attestation protocol and verification (rules/03),
confidential Kubernetes (rules/04), or cryptographic PETs like FHE/MPC (rules/05).
Protecting the *host from the workload* is sota-sandboxing rules/01; key custody and
HSM/KMS design is sota-secrets-management rules/02; application-layer vulnerabilities
remain sota-code-security regardless of what hardware the app runs on.

---

## 1. Definition discipline

**R1.1 — Use the Confidential Computing Consortium definition, verbatim.**
Confidential computing is *the protection of data in use by performing computation in
a hardware-based, attested Trusted Execution Environment*. All three properties are
load-bearing: **hardware-based** (isolation enforced below the host OS/hypervisor),
**attested** (a remote party can cryptographically verify what is running and where
before trusting it), **TEE** (confidentiality *and* integrity for code and data in
use). The CCC amended the definition at the end of 2022 specifically to make
attestation explicit — a TEE you cannot attest is a trust claim you cannot check.

**R1.2 — Memory encryption alone is NOT confidential computing.**
- Intel **TME / TME-MK**: transparent full-memory encryption with SoC-held keys,
  enabled in firmware, invisible to software. No attestation, no per-workload trust
  boundary, no integrity protection. It mitigates cold-boot/bus-probing of DRAM and
  nothing else — a malicious hypervisor reads guest memory through the CPU exactly
  as before.
- **AMD SEV without SNP** (plain SEV, SEV-ES): encrypts guest memory but provides no
  memory *integrity* — a malicious hypervisor can remap and replay pages — and on
  clouds typically offers only boot-time launch attestation rather than
  guest-requestable runtime evidence. AMD SEV-SNP exists precisely to add the
  integrity and on-demand attestation-report guarantees that make "the hypervisor is
  my adversary" a defensible claim.

Rule: when the threat model includes the host/hypervisor, the floor is the
SEV-SNP/TDX class (or an equivalent attested, integrity-protected TEE). A design doc
that says "memory is encrypted, therefore confidential" is a finding (High).

**R1.3 — Attestation is what turns encrypted memory into a trust decision.**
Encryption without attestation protects data from an adversary who *isn't asked for
permission*; it does nothing against an operator who simply launches your workload
in a fake or downgraded environment. The trust chain is: hardware root of trust →
signed evidence about platform + workload measurement → verifier appraisal →
relying party decision (roles per the RATS architecture, RFC 9334). Every guarantee
in this file is conditional on that chain being *verified before secrets flow* —
mechanics in rules/03.

**R1.4 — Platform reality check (verify at use time).** AMD SEV-SNP and Intel TDX
confidential VMs are generally available on major clouds (per the Azure and Google
Cloud confidential-VM documentation; region, machine-series, and GPU support vary —
verify current availability in the provider docs). Arm CCA (Realms/RME) silicon and
software stacks are maturing, but broad public-cloud instance availability still
lags the x86 offerings (needs verification at time of use). Process-level enclaves
and GPU TEEs are rules/02 territory.

---

## 2. What CC protects against — and what it never will

In-scope vs out-of-scope below follows the CCC's own threat-vector scoping
(*A Technical Analysis of Confidential Computing*); treat deviations from it in a
vendor pitch as marketing.

### 2.1 Adversaries a properly attested TEE removes

| Adversary | How CC blocks it |
|---|---|
| **Infrastructure operator / cloud insider** | Memory encrypted with SoC-held keys; admin tooling, host debuggers, memory dumps see ciphertext |
| **Hypervisor / host OS compromise** | Hardware denies host reads/writes of TEE memory; SNP/TDX-class integrity blocks remap/replay tampering |
| **Co-tenants** (escalating through the host) | Same boundary — a tenant who owns the hypervisor still sits outside the TEE |
| **Basic physical memory attacks** | Cold boot, DRAM bus probing/interposers, DMA from devices outside the TEE hit ciphertext |
| **Impersonation of the environment** | Attestation lets the relying party refuse to release data/keys to a non-genuine or downgraded platform |

### 2.2 Threats CC explicitly does NOT address

| Non-covered threat | Why | Who owns it |
|---|---|---|
| **Bugs in the workload itself** | Attestation proves *which* code runs, not that it is *good* code; an SQLi or RCE inside the TEE executes with the TEE's trust | sota-code-security |
| **Malicious/backdoored code you attest** | Measurement of a trojan is a perfectly valid measurement; garbage in, attested garbage out | supply-chain controls, sota-devsecops |
| **Side channels** | Out of CCC scope: mitigations are split across CPU vendor, firmware, OS, and *your code* (constant-time crypto, no secret-dependent memory access). TEEs have a real history of demonstrated microarchitectural and ciphertext side-channel attacks — budget for "bounded honesty", not perfection | vendor patches + rules/02 + workload discipline |
| **Sophisticated physical attacks** | Long-term/invasive hardware access (decapping, microprobing) is out of scope | facility security, threat acceptance |
| **The TEE vendor** | The CPU vendor's silicon, microcode, and signing keys are *in* your TCB — CC moves trust from the cloud operator to the chip maker, it does not eliminate trust | vendor selection, rules/02 |
| **Availability** | The host can refuse to schedule, pause, or destroy the TEE at will; CC guarantees confidentiality/integrity, never uptime | sota-architecture resilience patterns |

**R2.1 — Name the residual TCB in the design doc.** Every CC design must state what
remains trusted: CPU vendor hardware + firmware, the attestation verification
service, the guest firmware/kernel image you measure, and every line of workload
code. "Zero trust infrastructure" with an unstated multi-million-line guest image
in the TCB is a finding (Medium).

**R2.2 — XSS in a TEE is still XSS.** Any claim that CC "secures the application"
is a category error. CC changes *who can spy on a correct program*; it does not make
an incorrect program correct. Findings that an app-layer control was skipped
"because we run confidential" are High.

---

## 3. The inverse-of-sandboxing framing

**R3.1 — State the direction of protection explicitly.**

| | Sandboxing (sota-sandboxing) | Confidential computing (this skill) |
|---|---|---|
| Protects | the **host/platform** | the **workload and its data** |
| From | the **workload** (untrusted code/input) | the **host** (operator, hypervisor, co-tenants, physical access) |
| Trust stance | workload untrusted, infrastructure trusted | workload trusted (attested), infrastructure untrusted |
| Failure of interest | escape *out* | inspection/tampering *in* |

**R3.2 — The two compose; neither substitutes for the other.** A confidential VM
running an AI agent still needs a sandbox *inside* the TEE for the code the agent
executes (boundary choice per sota-sandboxing rules/01); a perfectly sandboxed
workload on hostile infrastructure still leaks everything to the operator. When a
system both executes untrusted code and processes data the infrastructure must not
see, apply both skills to the same system and document each boundary's direction.
A review that finds a TEE used *as* the sandbox for untrusted code — with nothing
protecting the TEE contents from that code — is a finding (High).

---

## 4. The escalation ladder — pick the lowest rung that satisfies the threat model

Each rung *adds* one guarantee over the previous, at a real cost. Escalating a rung
without naming the adversary the previous rung leaves unaddressed is
architecture-by-vibes.

| Rung | Mechanism | Added guarantee | Cost / operational burden |
|---|---|---|---|
| 0 | **TLS in transit + encryption at rest** | data protected outside running systems | baseline; effectively free — always required, never sufficient against a live host adversary |
| 1 | **HSM/KMS key custody** (sota-secrets-management rules/02) | *keys* never exposed to app hosts; crypto operations isolated and audited | per-op latency/cost; key ceremony and quorum ops; protects keys, NOT the plaintext data your app decrypts into RAM |
| 2 | **Confidential VM** (SEV-SNP/TDX class) | whole-VM memory confidentiality+integrity vs host, remote attestation; lift-and-shift, no code change | small perf overhead; attestation pipeline to build and operate (rules/03); guest image is in the TCB; feature gaps vs normal VMs (e.g. live-migration/backup limits per provider docs) |
| 3 | **Process-level enclave** (SGX-class, or library-OS on CVM tech) | TCB shrinks from "guest OS + app" to "app (+ runtime)"; host *OS* also untrusted | code partitioning or library-OS constraints; smaller ecosystem; higher dev effort; side-channel discipline falls more heavily on your code (rules/02) |
| 4 | **Cryptographic PETs** (FHE, MPC, ZKP — rules/05) | no hardware trust at all; math replaces the chip vendor in the TCB | orders-of-magnitude compute overhead, narrow operation sets, specialist skills; today viable for targeted sub-computations, not general workloads |

**R4.1 — Justify the rung by adversary, in writing.** The design doc must contain a
sentence of the form: "Rung N−1 fails against ⟨adversary⟩ because ⟨mechanism gap⟩;
rung N closes it by ⟨guarantee⟩." If nobody can write that sentence, stay at the
lower rung. (Findings: unjustified rung — Medium; unjustified rung with waived
compensating controls — High.)

**R4.2 — Rungs stack, they don't replace.** A confidential VM still terminates TLS,
still fetches keys from a KMS — ideally gated on attestation ("secure key release"),
which is the canonical rung-1+rung-2 composition (rules/03).

---

## 5. Drivers that legitimately demand CC

1. **Regulated multi-party data collaboration** — parties compute over pooled data
   none of them may show the others or the infrastructure host (fraud consortia,
   clinical studies). Attestation gives every party the same verifiable claim about
   the code that touches their data.
2. **IP-sensitive models/weights on rented infrastructure** — model weights or
   proprietary algorithms deployed to a cloud, partner site, or customer premises
   where the operator must not be able to exfiltrate them.
3. **Sovereignty / jurisdictional requirements** — demonstrating that a foreign or
   third-party operator is *technically* unable to read data in use, not merely
   contractually forbidden.
4. **Untrusted edge hardware** — devices in physically accessible or third-party
   locations (retail, telco, industrial) where DRAM extraction and host tampering
   are realistic.
5. **Compliance-scope reduction arguments** — "the cloud operator is outside our
   compliance/audit scope because it cannot access data in use." This can be a real
   driver, but its force is decided by *your assessor*, not by the vendor's
   whitepaper. Rule: obtain the auditor's/regulator's written position on how CC
   affects scope *before* architecting around the assumption; an unvalidated
   scope-reduction assumption driving the design is a finding (High).

Counter-driver: if the honest answer to "who is the adversary?" is only "external
attackers and our own bugs," CC adds cost without adding a defense — rungs 0–1 plus
sota-code-security already cover that adversary.

---

## 6. Anti-patterns (instant findings)

- **Checkbox CC — attestation never verified.** Confidential VMs deployed, no
  verifier, no appraisal policy, secrets provisioned to any VM that asks. This is
  paying for encrypted RAM while trusting the operator exactly as before. (Critical)
- **Attest-nothing "confidential" deployments.** Marketing "confidential" on plain
  memory encryption (TME-only hosts, SEV without SNP) or on TEEs whose evidence is
  never consumed by any relying party. (High)
- **Secrets delivered before/independent of attestation.** Keys baked into the
  image, injected by the (untrusted!) host at boot, or released on network identity
  alone — the TEE protects data from the host while the key arrived *through* the
  host. Key release must be attestation-gated (rules/03). (Critical)
- **CC as an app-security substitute.** Skipping input validation, authz, or patching
  "because it runs in a TEE" (see R2.2). (High)
- **Double-paying for isolation nobody threat-modeled.** Enclave-in-CVM-in-dedicated-
  host stacks with no written adversary model per layer; or CC applied to a workload
  whose data the operator legitimately processes elsewhere in plaintext anyway
  (the confidentiality claim is void, the bill is not). (Medium)
- **Ignoring the availability gap.** SLA/DR designs that assume the TEE also protects
  uptime; the host can kill it at will (§2.2). (Medium)
- **Sandboxing/CC direction confusion.** Untrusted code run *inside* the TEE with the
  TEE's secrets, on the theory that "it's isolated" (see R3.2). (High)

---

## 7. Decision table: adversary → minimum mechanism

| Adversary you must defeat | Minimum mechanism (lowest sufficient rung) |
|---|---|
| Network eavesdropper | TLS (rung 0) — sota-network-security |
| Stolen disk / decommissioned hardware | Encryption at rest (rung 0) |
| App-host compromise stealing *keys* | HSM/KMS custody, keys non-exportable (rung 1) |
| Cloud operator / insider reading data **in use** | Confidential VM, attested, SNP/TDX class (rung 2) |
| Malicious **hypervisor** (read *and* tamper) | Rung 2 with memory integrity — SNP/TDX class, not plain SEV |
| Compromised **guest OS** also untrusted | Process-level enclave / minimized-TCB design (rung 3) |
| Physical DRAM attack on edge hardware (cold boot/DMA) | Rung 2 hardware, plus measured boot; sophisticated invasive attacks remain out of scope |
| Co-tenant on shared infrastructure | Rung 2 for host-mediated attacks; side channels additionally need scheduling/SMT posture (sota-sandboxing rules/01, rules/02 here) |
| **TEE vendor itself** / no hardware trust acceptable | Cryptographic PETs (rung 4, rules/05) — or split trust across vendors/parties |
| Your own buggy or malicious workload | No rung helps — sota-code-security, sota-sandboxing, supply-chain controls |

---

## Audit checklist

- [ ] Does every "confidential computing" claim rest on a hardware-based, **attested**
      TEE (CCC definition) — not on memory encryption alone (TME-only, SEV without
      SNP)? Grep design docs for `TME`, `SEV` without `SNP`, "memory encryption"
      used as a synonym for confidential.
- [ ] Is attestation evidence actually **verified by a relying party before secrets
      or data flow** (RFC 9334 roles assigned), rather than merely available?
      (Depth: rules/03.)
- [ ] Does the design doc name the adversary per R4.1 and justify the chosen rung as
      the lowest sufficient one — with each layer of any stacked isolation mapped to
      a threat?
- [ ] Is the residual TCB written down (CPU vendor, firmware, guest image, verifier,
      workload code) and is someone accountable for patching each element?
- [ ] Are out-of-scope threats explicitly handled elsewhere: workload vulnerabilities
      (sota-code-security), side channels (vendor patches + workload discipline),
      availability/DoS (resilience design), sophisticated physical attacks (accepted
      or mitigated)?
- [ ] Where the system also runs untrusted code or parses untrusted input, is there a
      sandbox boundary *inside or alongside* the TEE with its direction of protection
      documented (sota-sandboxing rules/01)?
- [ ] Are keys released only against successful attestation (no keys in images, no
      host-injected secrets)? Grep deployment code for cloud-init/user-data secret
      injection into "confidential" VMs.
- [ ] If compliance-scope reduction is a driver, is there a written assessor/regulator
      position confirming the treatment — not just vendor collateral?
- [ ] Have platform capability claims (SNP/TDX instance availability, GPU TEE support,
      Arm CCA status, provider feature limits like live migration/backup) been
      re-verified against current provider documentation rather than copied from
      older docs?
- [ ] Is there any workload paying for CC whose threat model no one can state
      (anti-pattern §6) — or any workload whose stated threat model demands CC but
      runs without it?

# 02 — TEE Technologies: Landscape & Selection

Scope: the map of trusted-execution technologies — what each one actually guarantees,
what it does not, and how to choose between them for a given workload shape and threat
model. Threat-model taxonomy and the decision to use confidential computing at all is
rules/01; remote-attestation verification and TCB recovery depth is rules/03; running
TEEs on Kubernetes is rules/04; cryptographic alternatives (FHE/MPC/PETs) are rules/05.
General isolation-boundary ranking and Wasm-as-a-sandbox are sota-sandboxing rules/01;
this file owns only the *confidentiality-against-the-operator* layer that sandboxes do
not provide.

---

## 1. VM-level TEEs — confidential VMs (the current mainstream)

Lift-and-shift confidentiality: the whole guest VM is the TEE. The hypervisor and host
operator are outside the trust boundary. This is the default choice in 2026 — all three
major clouds ship confidential-VM offerings on this model (verify current SKU/region
support at each provider's docs).

### 1.1 AMD SEV-SNP — and why the ladder below it is insufficient

AMD shipped three generations under the "SEV" name. They are **not** interchangeable,
and the name alone in a design doc is a red flag:

| Generation | Adds | Missing | Verdict |
|---|---|---|---|
| **SEV** | Per-VM memory encryption (AES, key in the AMD-SP) | Register-state protection, memory *integrity*, runtime attestation | Insufficient: malicious hypervisor reads VMEXIT register state, replays/remaps ciphertext |
| **SEV-ES** | Encrypted CPU register state on VMEXIT | Memory integrity, runtime attestation | Insufficient: ciphertext block moves/replay and page remapping still possible |
| **SEV-SNP** | Memory **integrity** (Reverse Map Table: anti-replay, anti-remap, anti-alias — "a VM always sees the data it last wrote"), interrupt-injection protections, **remote attestation** — any relying party can request a signed report at any time | Ciphertext side channels remain (§6) | The floor for confidential computing on AMD |

Per AMD's SEV-SNP whitepaper and SNP-attestation guide: SEV/SEV-ES attestation was
*launch-time only* (guest-owner-only); SEV-SNP replaced it with runtime remote
attestation carrying measurement, guest policy, chip ID, and TCB version — the input
rules/03 depends on.

**R1.1 — "SEV" without "-SNP" is a finding (High).** Plain SEV and SEV-ES provide
encryption without integrity or runtime attestation; published attacks (unencrypted
VM state, ciphertext remapping) defeat their operator-exclusion claim. Require SEV-SNP
(introduced with 3rd Gen AMD EPYC) and verify the platform actually enables it —
`dmesg | grep -i sev` in the guest must show `SEV-SNP`, not just `SEV`.

**R1.2 — Encryption ≠ integrity ≠ attestation; a CC claim needs all three.** Apply
this test to every technology in this file: (a) is guest memory confidential against
the host? (b) can the host tamper/replay/remap without detection? (c) can a remote
party cryptographically verify what is running? A "confidential" offering missing any
leg is a hardened VM, not a TEE.

### 1.2 Intel TDX — teach the layering, not the acronym

TDX is built **on top of** a memory-encryption substrate that is *not itself*
confidential computing. Per Intel's TDX whitepaper and the Intel architecture
memory-protections documentation:

| Layer | What it is | What it is NOT |
|---|---|---|
| **TME** | Total Memory Encryption: one transparent key for all of DRAM | No per-tenant separation; protects against cold-boot/physical DRAM reads only |
| **TME-MK** (a.k.a. MKTME) | Multi-key TME: per-KeyID AES-XTS keys, assignable per VM/domain | No isolation from the hypervisor (VMM assigns keys and can map pages), no integrity, no attestation |
| **TDX** | Trust Domains: SEAM-mode TDX module + VMX, private KeyIDs reserved from the TME-MK pool, memory-integrity protection (MAC), CPU-state isolation from the VMM, remote attestation (via SGX-based quoting infrastructure) | Not available on parts that only ship TME/TME-MK |

**R1.3 — "The platform has memory encryption" is not a CC claim (finding: High if
marketed as one).** TME/TME-MK alone leaves the hypervisor fully in the TCB. Only a
TD (TDX guest) with verified attestation excludes the operator. The same logic marks
plain SEV (R1.1) and any "encrypted RAM" marketing on other platforms.

**R1.4 — TDX availability is a platform property — verify, don't assume.** TDX
shipped in Xeon Scalable parts and is GA as confidential-VM offerings at major clouds
(e.g. Azure DC/ECesv6-class on 5th Gen Xeon; GCP C3). Verify the current SKU, region,
and TDX-module version at the provider's docs at design time (latest stable).

### 1.3 ARM CCA — real architecture, trailing hardware

Arm CCA introduces *Realms* via the Realm Management Extension (RME), an optional
Armv9-A architectural feature: realm VMs isolated from the Normal-world hypervisor,
with attestation, managed by the (open-source, TF-A) RMM firmware. Linux kernel guest
support is upstream (see the kernel's arm64 Arm CCA documentation).

**R1.5 — Treat ARM CCA as "verify availability before you architect on it."** As of
mid-2026 there is no generally available CCA cloud instance; development targets Arm
Fixed Virtual Platforms (simulators), and the first announced CCA-capable cloud
silicon (e.g. Azure's Cobalt 200, announced November 2025) is in provider-internal
production with customer availability "planned" — verify current status at the
provider before committing. Designs targeting Arm today should plan the attestation
abstraction (rules/03) so CCA can slot in, not assume it exists.

---

## 2. Process-level enclaves — Intel SGX

The enclave is a protected region *inside* an untrusted process; the OS, hypervisor,
and everything else on the machine is outside the TCB. Smallest attack surface of any
option here — and the highest engineering cost.

**R2.1 — Know SGX's split status before recommending it.** Per Intel's own support
documentation: SGX is deprecated/removed on client Core CPUs (11th/12th Gen onward)
but explicitly continues on Xeon server parts, with no announced deprecation plans.
SGX is a server technology now. Historic EPC (Enclave Page Cache) limits of ~128–256MB
with brutal paging penalties are largely lifted on modern Xeon (e.g. Intel documents
up to 64GB EPC on Xeon D-1700/2700-class parts; verify per SKU), with ECDSA/DCAP
attestation replacing the retired EPID service.

**R2.2 — Unmodified apps go in via a LibOS; verify the LibOS is alive.**
- **Gramine** (formerly Graphene; a Linux Foundation project): the most established
  LibOS for unmodified Linux applications in SGX, but mainline activity has stalled —
  last release v1.9 (June 2025), and no commits or merged PRs on the main branch for
  over a year as of mid-2026. Apply the liveness check below before adopting.
- **Occlum**: maintained but noticeably less active (v0.31.0, March 2025; sparse
  commits since) — re-verify project health before adopting.
- Anything else: check the repository yourself (last release, last non-bot commit,
  open-issue triage) before betting a security boundary on it. A dead LibOS is
  unpatched TCB (finding: High).

**R2.3 — When process-level beats VM-level.** Choose SGX over a confidential VM when:
- the secret is small and the code touching it is small (keys, signing, matching
  logic): the TCB is your enclave code + LibOS, not an entire guest kernel + distro;
- you need *finer granularity than a VM* — enclave per key, per tenant, per function;
- the host itself is semi-trusted and you only need to carve out the crown jewels.

Costs you accept: porting/manifest work (even with a LibOS: syscall gaps, fork/exec
limits), EPC sizing per SKU, and the richest side-channel attack literature of any
TEE (§6) — SGX's fine-grained OS-adversary model is exactly what single-stepping
attacks exploit. A whole-app-in-enclave design usually indicates the wrong tool:
that is a confidential VM with extra steps and a bigger porting bill.

---

## 3. AWS Nitro Enclaves — a different trust model (state it honestly)

Nitro Enclaves are hardened, highly constrained VMs carved out of an EC2 parent
instance. Per AWS's own documentation: isolation of enclave vCPUs and memory is
provided by the **Nitro Hypervisor** ("the same Nitro Hypervisor technology that
provides CPU and memory isolation for EC2 instances"); the enclave has **no persistent
storage, no interactive access, no external networking** — only a local vsock to the
parent; attestation is provided by the **Nitro Security Module (NSM)**, producing
CBOR/COSE attestation documents signed by the AWS Nitro PKI, with first-class KMS
integration (key policies conditioned on enclave measurements).

**R3.1 — Do not describe Nitro Enclaves as SEV/TDX-class operator exclusion (finding:
High in any design doc that does).** There is no hardware memory encryption excluding
the infrastructure operator: the Nitro hypervisor — AWS's software/firmware — *is* the
isolation and attestation root of trust, so **AWS remains in the TCB**. AWS's security
claim is design/operational ("no mechanism for operator access"), independently
assessed in NCC Group's public 2023 Nitro System review — a strong claim, but a
different *kind* of claim than "the CPU vendor's silicon excludes the cloud operator."
If the threat model is "protect data from the cloud provider itself," Nitro Enclaves
do not address it; SEV-SNP/TDX instances do (with verified attestation, rules/03).

**R3.2 — Where Nitro Enclaves excel:** removing *your own* operators, the parent
instance's root user, and co-resident software from the TCB of a small critical
workload (key custody, PII tokenization) — with a mature attestation-to-KMS release
flow and no porting to a new ISA. Note the model is processor-agnostic (Intel, AMD,
Graviton parents). For "protect from everyone except AWS," they are often the
lowest-friction option on AWS; combine with SEV-SNP-enabled parent instances where
supported if you also want memory encryption in the stack.

---

## 4. Confidential accelerators — GPU TEEs for AI workloads

CPU-only TEEs are useless for the dominant confidential-AI use case (model weights
and prompts on GPUs) unless the accelerator extends the boundary.

**R4.1 — NVIDIA confidential computing exists on Hopper (H100) and Blackwell
datacenter GPUs — and only there (verify SKU support for anything else).** Per
NVIDIA's Hopper confidential-computing whitepaper and product documentation:
- H100 (first confidential GPU): CC mode pairs the GPU with a CPU TEE (SEV-SNP or TDX
  confidential VM); CPU↔GPU PCIe transfers go through encrypted bounce buffers
  (AES-GCM-256 in the DMA engine); on-package HBM is inside the boundary; the GPU
  produces its own **attestation** (verified via NVIDIA's attestation services/tools —
  verify current verifier tooling at NVIDIA's docs), which must be checked *in
  addition to* the CPU TEE's report (rules/03).
- Blackwell: first TEE-I/O-capable GPU; adds inline protection over NVLink and
  near-parity performance in CC mode per NVIDIA's published materials.

**R4.2 — A "confidential AI" design must name the full boundary (finding: High if
the GPU is hand-waved).** Required in the design doc: CPU TEE technology, GPU CC mode
on/off, who verifies the GPU attestation, and whether multi-GPU interconnect traffic
(NVLink) is protected on the deployed generation. "The VM is confidential" while
weights sit in an unattested GPU across an unencrypted bus is confidential theater.

---

## 5. Wasm and TEEs

Wasm runtimes as portable sandboxes — protecting the *host from the workload* — are
sota-sandboxing rules/01 territory, and Wasm alone provides zero confidentiality
against the operator. The inverted combination (Wasm module *inside* a TEE for
portability across enclave technologies) was pioneered by **Enarx**.

**R5.1 — Do not recommend Enarx as a maintained dependency (finding: Medium if a
design relies on it).** Verified against the project repository (mid-2026): last
release v0.7.1 (January 2023); subsequent commit activity is essentially automated
dependency bumps. Treat it as dormant — an important design reference, not a
supported platform. The pattern survives elsewhere (Wasm runtimes running inside
confidential VMs/containers); if a current project claims this space, apply the R2.2
liveness check before adopting.

---

## 6. Side channels and physical attacks — the honest framing

TEEs raise attacker cost; they do not make co-resident adversaries disappear. Vendors
respond to microarchitectural breaks with microcode/firmware fixes surfaced as TCB
version bumps — which is why attestation policy must track TCB levels and why TCB
recovery is a first-class operational flow (rules/03).

Attack classes to carry in every TEE threat model:

| Class | Example (verified literature) | Affects | Posture |
|---|---|---|---|
| Transient execution / speculative | Spectre-class lineage; vendor advisories per microcode cycle | All | Patched via TCB recovery; attestation must reject stale TCBs (rules/03) |
| Ciphertext side channels | CipherLeaks (USENIX Security '21) and generalized follow-up (IEEE S&P '22): deterministic XEX/XTS encryption means repeated plaintext at a fixed address yields identical ciphertext a malicious hypervisor can monitor (e.g. VMSA register state) — broke constant-time OpenSSL RSA/ECDSA; AMD bulletin AMD-SB-3021 | SEV-SNP | Software mitigations (register masking, ciphertext-hiding guidance per AMD); constant-time code alone is NOT sufficient — document residual risk |
| Interrupt / single-stepping | SGX-Step framework: attacker-controlled timer interrupts step an enclave one instruction at a time; Intel's AEX-Notify ISA mitigation (USENIX Security '23); interrupt-*counting* variants against AEX-Notify published since (2025) — the arms race is live | SGX primarily; analogues studied on VM TEEs | Assume a privileged host can observe execution granularity; avoid secret-dependent control flow, verify AEX-Notify enabled |
| SMT co-residency | Sibling-thread contention leaks | All shared-CPU | Cloud CVMs: provider-controlled (document what the provider states); own hardware: disable SMT or core-schedule per tenant, same rule as sota-sandboxing rules/01 R2.2 |
| Physical (bus interposition, chip attacks) | DRAM interposers, voltage glitching literature | All | Memory encryption raises cost substantially; a determined physical attacker with lab time is outside most cloud threat models — say so explicitly rather than claiming immunity |

**R6.1 — Side-channel posture is documented, never assumed away (finding: Medium for
absence, High for a false "TEEs stop side channels" claim).** Every CC design doc
carries a short section: which classes apply, which are mitigated by current TCB,
which are accepted residual risk, and the trigger for re-evaluation (vendor advisory
→ TCB bump → attestation policy update, rules/03).

**R6.2 — Secrets-handling code inside a TEE still follows constant-time discipline
*plus* TEE-specific guidance.** On SEV-SNP, constant-time is provably insufficient
against ciphertext side channels without the vendor-recommended mitigations; on SGX,
secret-dependent branches are readable via single-stepping. The TEE is the container,
not the crypto review.

---

## 7. Selection table

Workload shape × threat model → technology. Everything here is "(latest stable,
verify current platform support)" — SKUs, regions, and TCB baselines move.

| Workload shape | Threat: exclude cloud/infra operator | Threat: exclude co-tenant + own ops only |
|---|---|---|
| Lift-and-shift VM / whole container stack | SEV-SNP or TDX confidential VM (verify SNP not plain SEV, R1.1; verify TD not just TME-MK, R1.3) | Ordinary hardened VM + sota-sandboxing controls may suffice — do not pay the CC tax without the threat (rules/01) |
| Containers on Kubernetes | Confidential VMs as nodes, or CoCo-style pod-level CVMs — rules/04 | Standard K8s isolation (sota-kubernetes, sota-sandboxing) |
| Small critical function (key custody, signing, tokenization) | SGX enclave (Gramine for unmodified code) on Xeon, or per-function confidential VM | AWS-only: Nitro Enclaves (R3.1 trust model accepted and written down) |
| GPU inference / training on sensitive models or data | SEV-SNP/TDX CVM **plus** GPU CC mode on Hopper/Blackwell-class parts, both attestations verified (R4.2) | GPU CC mode still valuable against co-resident software; document what is and isn't in the boundary |
| Arm-based deployment | ARM CCA when actually available on your target platform (R1.5) — until then, no operator-exclusion story on Arm cloud silicon; re-scope or change ISA | Standard Arm virtualization + sandboxing |
| Portable across TEE vendors | Design to the attestation abstraction (rules/03) and a VM-shaped workload; avoid enclave-ABI lock-in | n/a |

**R7.1 — The technology choice is an output of rules/01, not of vendor preference.**
An audit asks, in order: (1) what operator/tenant is being excluded? (2) does the
chosen technology's trust model actually exclude them (R1.2, R3.1)? (3) is the
attestation of that technology verified by a relying party (rules/03)? A "yes" on
(1) with a mismatch on (2) is the defining Critical finding of this domain — e.g.
"protect from the cloud provider" implemented on Nitro Enclaves, plain SEV, or
TME-MK-only silicon.

---

## Audit checklist

- [ ] Every "SEV" reference specifies SEV-**SNP**; no design relies on plain SEV or
      SEV-ES for operator exclusion (grep design docs and IaC for `sev` without
      `snp`; check guest `dmesg` for `SEV-SNP`).
- [ ] No claim treats memory encryption alone (TME, TME-MK, "encrypted RAM") as
      confidential computing; TDX/TD attestation present where Intel is the platform.
- [ ] Any ARM CCA dependency carries a dated availability verification for the
      actual target platform, not an assumption.
- [ ] SGX designs: target is Xeon (not client CPUs); EPC sizing checked against the
      actual SKU; the LibOS's maintenance status verified within the last quarter
      (last release + non-bot commits).
- [ ] Nitro Enclaves designs state explicitly that the Nitro hypervisor/AWS is in the
      TCB, and the documented threat model does not require excluding the cloud
      operator (grep for "Nitro" near "memory encryption" — that pairing is usually
      the R3.1 misclaim).
- [ ] Confidential-AI designs name the GPU generation, CC mode status, interconnect
      protection, and GPU attestation verifier — not just the CPU TEE.
- [ ] No dependency on dormant Wasm-TEE projects (Enarx-class) without a documented
      fork/maintenance plan; project liveness checked, not assumed.
- [ ] A side-channel posture section exists: applicable classes (ciphertext,
      single-stepping, transient execution, SMT), current mitigations, accepted
      residual risk, and the advisory→TCB-bump→policy-update trigger.
- [ ] Secrets code inside TEEs reviewed for TEE-specific leakage (ciphertext side
      channels on SEV-SNP; secret-dependent control flow on SGX), not just generic
      constant-time rules.
- [ ] The technology matches the rules/01 threat model: the excluded party is
      actually outside the chosen technology's TCB, and its attestation is verified
      per rules/03.

# 03 — Remote Attestation: Verify Before You Trust

Scope: the attestation architecture (RATS roles, evidence flow, verification policy),
the attest-then-release pattern, verifier selection, measurement/reference-value
management, attested channels, and re-attestation. This file does NOT own: choosing
the TEE technology that produces the evidence (rules/02), threat-model fit (rules/01),
wiring attestation into Kubernetes pod lifecycles (rules/04), the secret store the
released keys live in (sota-secrets-management rules/02), or build-time provenance
(sota-devsecops rules/02). Remote attestation is the mechanism that makes a TEE
trustworthy to anyone outside it; a TEE without verified attestation is encrypted
memory plus a pinky promise.

---

## 1. The RATS architecture (RFC 9334) — the map for every vendor diagram

Every attestation product, however branded, decomposes into the RFC 9334 roles.
Classify a vendor's boxes into these roles first; gaps and conflations become
findings.

| Role | Does what | Trust consequence if compromised |
|---|---|---|
| **Attester** | Produces Evidence about itself (the TEE + its attestation agent) | Assumed hostile until verified — that is the point |
| **Verifier** | Appraises Evidence against Endorsements, Reference Values, and appraisal policy; emits Attestation Results | Total: a lying Verifier can vouch for anything |
| **Relying Party** | Consumes Attestation Results to make an authorization decision (release a key, admit a node, open a channel) | Total for the resources it gates |
| **Endorser** | Vouches for the Attester's capabilities — in practice the silicon vendor's certificate infrastructure (e.g. Intel PCS, AMD KDS) | Forged endorsements = fake hardware passes |
| **Reference Value Provider** | Supplies known-good values (measurements, minimum TCB versions) the Verifier compares Evidence against | Attacker-supplied "known-good" = attacker code passes |

Conceptual messages — keep these four distinct in designs and reviews:

- **Evidence** — claims the Attester signs about itself (measurements, TCB versions,
  policy flags). Raw, platform-specific, verified by nobody yet.
- **Endorsements** — the manufacturer's signed statements that this signing key
  belongs to genuine hardware (the certificate chain to the silicon vendor root).
- **Reference Values** — what the measurements *should* be.
- **Attestation Results** — the Verifier's verdict, signed by the Verifier, in a
  Verifier-neutral format (increasingly an Entity Attestation Token, RFC 9711 —
  a JWT/CWT with attestation claims).

**Two topologies (RFC 9334):**

- **Passport model** — Attester sends Evidence to the Verifier, gets an Attestation
  Result back, presents that result to Relying Parties. Scales to many Relying
  Parties; the result is a bearer-ish credential, so its validity window and
  audience matter.
- **Background-check model** — Attester hands Evidence to the Relying Party, which
  forwards it to a Verifier and acts on the returned result. The Relying Party
  never appraises Evidence itself; freshness is naturally per-transaction.

**Mapping real products onto the roles** (verify current scope at each vendor's docs):

| Product | RATS role(s) |
|---|---|
| Guest attestation agent / TEE quoting infrastructure | Attester |
| Intel Trust Authority (SaaS; attests SGX, TDX, TPM/vTPM, NVIDIA GPU workloads; formerly Project Amber) | Hosted Verifier issuing signed tokens — passport model |
| Microsoft Azure Attestation (attests SGX, VBS enclaves, TPMs; used for SEV-SNP/TDX confidential-VM guest attestation) | Hosted Verifier with customer-configurable appraisal policy |
| Confidential Containers **Trustee**: Attestation Service (AS) | Self-hosted Verifier |
| Trustee: Key Broker Service (KBS) | Relying Party + secret-release gate (background-check: KBS forwards Evidence to the AS) |
| Trustee: Reference Value Provider Service (RVPS) | Reference Value Provider |
| Veraison (open-source verifier components; started at Arm, now a Confidential Computing Consortium project) | Verifier building blocks |
| Intel PCS / AMD KDS (VCEK ← ASK ← ARK chain) | Endorser |
| Your KMS/secret store releasing keys on a valid result | Relying Party |

**R1.1 — Never let the Attester's host pick the Verifier or the Reference Values.**
The untrusted host operator must not control appraisal inputs. Verifier identity and
policy are pinned by the *workload owner* (baked into the workload or its config,
which is itself measured).

**R1.2 — Attestation Results are credentials: check signature, audience, expiry,
and replay window** like any token (token-validation depth: sota-code-security).

---

## 2. Attest-then-release — the only pattern that counts

The purpose of attestation is to gate something. The canonical enforcement point is
**key release**: the workload's data keys, API credentials, or disk-encryption keys
exist only in a broker (KBS, cloud KMS with attestation-conditioned release policy,
HSM-backed service) and are released ONLY after Evidence verifies against policy.
Storage/rotation of those secrets is sota-secrets-management rules/01–02; this rule
owns the *condition* on release.

```
BAD  (dashboard attestation):
  TEE boots → agent posts attestation to a monitoring endpoint → green tile
  on a dashboard → workload reads its secrets from a mounted file anyway.
  The attestation gates NOTHING. Disable the TEE and the system still works.

GOOD (attest-then-release):
  TEE boots with no secrets → agent obtains Evidence (nonce from broker bound
  into report data) → Verifier appraises → broker checks the Attestation
  Result against release policy → decrypts/releases the workload key into the
  attested channel → workload can now serve. No valid attestation = no key
  = workload provably cannot operate on protected data.
```

**R2.1 — Design test: turn attestation off; if the workload still functions with
production data, attestation gates nothing.** Finding severity: Critical. This is
the single most common confidential-computing deployment failure.

**R2.2 — Release keys *into* the attested identity, not near it.** Encrypt the
released secret to a public key that appears in the Evidence's report data (§3), or
deliver it over an attested channel (§6). Releasing a plaintext key over ordinary
TLS to "the pod that attested a moment ago" lets the host operator race or proxy
the release.

**R2.3 — Everything downstream of release is inside the trust boundary.** If the
released key is then written to a host-visible volume or env var, the TEE bought
nothing. Key handling inside the workload: sota-secrets-management rules/03.

**R2.4 — Fail closed.** Verifier unreachable / policy mismatch / TCB stale ⇒ no
key, workload does not start degraded. Availability mitigations are §4 (verifier
HA), never "skip attestation on timeout" (Critical).

---

## 3. What Evidence must contain — and the hard verification rules

Conceptually, every platform's Evidence carries four things (byte layouts differ —
SGX/TDX quotes, SEV-SNP attestation reports, Arm CCA realm tokens, TPM quotes):

1. **Measurement(s)** of what launched: enclave code identity (e.g. SGX MRENCLAVE /
   signer MRSIGNER) or, for VM-shaped TEEs, launch measurement of firmware +
   kernel/initrd/cmdline, extended at runtime via measurement registers/event logs.
2. **Platform TCB identity**: CPU/firmware security version numbers (SVNs),
   microcode level, platform provisioning identity.
3. **Policy/attribute flags**: debug mode, SMT allowance, migration allowance.
4. **Report data**: a caller-supplied field (64 bytes on SGX/TDX/SEV-SNP) the TEE
   signs verbatim — the hook for nonces and key binding.

Hard rules for any Verifier policy (hosted or self-written):

**R3.1 — Reject debug-mode TEEs in production. Always.** Debug attributes
(SGX ATTRIBUTES.DEBUG, TDX TD debug attribute, SEV-SNP guest policy DEBUG bit)
permit the host to inspect or single-step the TEE — Evidence signs the flag
precisely so you can refuse it. A policy that ignores the debug flag is Critical;
a dev-cluster exception must be a *different* policy on a *different* key set.

**R3.2 — Bind freshness into report data.** The Relying Party/Verifier issues an
unpredictable nonce; the Attester puts it (or a hash of nonce ‖ ephemeral public
key) in report data. Verifier checks the echo. Without this, yesterday's Evidence
from a since-compromised or since-deleted TEE replays forever. RFC 9334 allows
nonces, epoch IDs, or trusted timestamps — pick one deliberately; "none" is High.

**R3.3 — Verify the FULL certificate chain to the silicon vendor's root** (e.g.
SEV-SNP: VCEK → ASK → ARK, roots fetched from AMD KDS; SGX/TDX: PCK chain to the
Intel root via PCS), including revocation data. Pin the vendor root out-of-band —
never trust a root delivered alongside the Evidence by the host. Chain checked
only to an intermediate supplied by the platform under test: Critical.

**R3.4 — TCB status is a policy decision, not a boolean.** Intel-style appraisal
yields graded statuses (`UpToDate`, `SWHardeningNeeded`, `ConfigurationNeeded`,
`OutOfDate`, `Revoked`, and combinations); AMD binds the VCEK to the reported TCB
version. Policy must enumerate what each grade means for *this* workload:

| TCB status class | Default posture |
|---|---|
| Up to date | Release |
| Hardening/configuration needed | Release + alert + tracked remediation deadline |
| Out of date | Deny for new secrets; time-boxed grace for running fleet during TCB recovery (§5) |
| Revoked | Deny, revoke previously released keys, page (security incident) |

Silently accepting `OutOfDate`/`Revoked` because "the demo broke": Critical.

**R3.5 — Verify measurements against expected values, not against "signature
valid".** A genuine TEE running attacker code produces perfectly signed Evidence.
Signature validity authenticates the *platform*; reference values authenticate the
*workload*. Policies that stop at "quote verifies" are High.

---

## 4. Choosing a Verifier: hosted vs self-hosted

| Dimension | Hosted service (e.g. Intel Trust Authority, Azure Attestation) | Self-hosted (e.g. Trustee AS, Veraison-based) |
|---|---|---|
| Endorsement plumbing (vendor cert caching, TCB info) | Managed for you | You operate collateral caching/refresh |
| Trust | Verifier operator can vouch falsely — you trust the vendor/cloud with the verdict | Verdict stays in your trust domain; you must trust your own code + ops |
| Cloud-operator independence | Attesting a cloud TEE via the *same* cloud's verifier weakens the "protect from the cloud operator" story — acceptable only if that's not your threat (rules/01) | Independent of the infrastructure operator |
| Policy expressiveness | Vendor's policy language, per-tenant policies | Arbitrary; you own correctness of appraisal logic |
| Availability coupling | Attestation (and thus key release, boot, scale-up) depends on an external endpoint — model outage = cannot start workloads | You own HA; run the verifier redundantly, *outside* the fleet it attests |
| Air-gapped / sovereignty | Usually excluded | The only option; plan offline endorsement/reference-value sync |
| Audit | Verify what evidence the service actually checked (some publish audit/"faithful verification" artifacts) | Full transcript available |

**R4.1 — Whoever runs the Verifier can impersonate every attested workload's
trustworthiness.** Choose it with the same care as a root CA; log every verdict.

**R4.2 — Never run the Verifier/KBS on infrastructure the attestation is supposed
to distrust** (e.g. Trustee KBS as an ordinary pod on the same untrusted cluster
whose nodes it attests — the host operator can substitute its results). Run it in
a separately trusted domain, or itself inside an independently attested TEE. (High)

**R4.3 — Verifier availability is a tier-0 dependency.** Fresh nodes cannot join
and restarts cannot fetch keys during a verifier outage. HA-deploy it, monitor it,
and rehearse outage: the correct behavior is "cannot start new", never "start
unverified".

---

## 5. Measurements, reference values, and TCB recovery

**R5.1 — Two valid strategies for reference values; pick per workload:**
- **Golden-value pinning**: exact expected measurement(s), rotated on every
  release. Strongest; operationally heavy — every kernel/initrd/enclave rebuild
  is a reference-value update, and a missed update is an outage (key release
  fails closed).
- **Policy-based verification**: appraise structured claims (signer identity +
  minimum SVN + attribute constraints) instead of one hash — e.g. "signed by our
  release key, version ≥ N, debug off". Survives rebuilds; only as strong as the
  signing discipline behind it.

**R5.2 — Reference values must come from the build system, not from a "known-good"
deployment.** Measuring a running instance and pinning that hash launders whatever
was running into policy. Reproducible builds (sota-devsecops rules/02, rules/04)
let CI compute the expected measurement from source and publish it, signed, to the
Reference Value Provider (Trustee's RVPS; CoRIM is the emerging IETF interchange
format for reference values — still an Internet-Draft, verify status at the IETF
datatracker before standardizing on it).

**R5.3 — Build attestation and runtime attestation are complementary; you need
BOTH.** SLSA provenance proves how an artifact was *built* (sota-devsecops
rules/02); remote attestation proves what is *running now* on trustworthy
hardware. Provenance without RA can't see what the host actually launched; RA
without provenance verifies a measurement nobody can trace to reviewed source.
The reference-value pipeline is the join point.

**R5.4 — Plan TCB recovery before the first security event forces it.** Vendor
microcode/firmware updates raise SVNs and change TCB grades; platform-side updates
can change launch measurements. On a TCB recovery event, un-updated machines drop
to `OutOfDate` (or worse). Have, in advance: (a) a rehearsed fleet update +
re-attestation path; (b) reference-value/policy rotation with dual-validity
windows so old+new coexist during rollout; (c) an explicit, time-boxed,
risk-signed grace policy for degraded grades (R3.4); (d) monitoring for grace
expiry. Discovering this process during an embargoed CVE weekend is the
predictable failure mode. No documented TCB-recovery plan: High.

---

## 6. Attested channels (RA-TLS)

Attestation must be cryptographically bound to the channel that subsequently
carries secrets, or a machine-in-the-middle can splice a verified TEE's identity
onto its own connection.

**R6.1 — Bind the channel key into the Evidence.** Pattern: the TEE generates an
ephemeral TLS keypair *inside* the enclave/TD, puts the public key's hash in
report data, and presents Evidence with (or embedded in) its certificate; the peer
verifies Evidence and that the TLS key matches report data. Attestation and
channel are now the same identity. Trustee's KBS protocol (RCAR) achieves the same
binding at the application layer: the response key is attested, and secrets are
encrypted to it.

**R6.2 — Attestation over one channel + secrets over another = splice risk.**
Any design where the verified key and the delivery channel key are unrelated is
High.

**R6.3 — Standardization is in progress — say so in your design docs.** The IETF
has chartered the SEAT (Secure Evidence and Attestation Transport) working group
to standardize attestation in (D)TLS 1.3 (successor to the individual
draft-fossati-tls-attestation line), but as of mid-2026 no standard is published —
treat every RA-TLS implementation as a project-specific profile (TEE SDKs and confidential-container/K8s stacks ship
their own; verify each project's current mechanism at its docs). Interop between
two vendors' "RA-TLS" is not implied. Plain-TLS trust anchors and PKI hygiene:
sota-network-security.

---

## 7. Freshness, revocation, and monitoring

**R7.1 — Attestation is point-in-time.** It proves state at Evidence-generation;
it does not detect later runtime compromise *inside* the TEE. Re-attest on:
restart (always), key rotation / lease renewal (make releases leased, not
perpetual — align with sota-secrets-management rules/01 dynamic-secret TTLs),
policy or reference-value change, TCB recovery events, and a fixed schedule.
"Attested once at deploy, trusted for the pod's lifetime (weeks)" is Medium-High
depending on data sensitivity.

**R7.2 — Wire attestation verdicts into detection** (sota-detection-engineering
rules/01, rules/04). Alert on: any appraisal failure in prod (someone or something
launched a non-conforming image — treat as a security signal, not an ops blip),
debug-flagged Evidence, TCB-grade downgrades, Evidence from unknown platforms,
verifier policy changes, and grace-window expiry. Log full appraisal transcripts
(evidence hash, policy version, verdict, TCB grade) for forensics.

**R7.3 — Revocation must propagate to already-released secrets.** When a
measurement is retired (vuln in the image) or a platform is revoked, rotating
the reference values only stops *future* releases; previously released keys must
be rotated/revoked too. This is why leases (R7.1) beat one-shot release.

---

## Audit checklist

The first four questions catch the failure that voids everything else: attestation
that gates nothing.

- [ ] Does anything actually *consume* the Attestation Result? Trace one secret
      end-to-end: named broker/KMS releases it only on a valid, fresh result
      (grep for the release policy; a dashboard/metrics sink is not a consumer).
- [ ] Kill test documented: with attestation disabled or the verifier down, does
      the workload provably fail to obtain production secrets (fail closed)?
- [ ] Are secrets absent from the image, host env, and mounted volumes before
      attestation succeeds? (grep manifests for env/volume-injected prod secrets
      alongside "attestation" — coexistence is the tell.)
- [ ] Is the released secret bound to the attested identity (encrypted to a key in
      report data, or delivered over an RA-bound channel), not sent over ordinary
      TLS to whoever asked?
- [ ] Every deployment box mapped to a RATS role (Attester / Verifier / Relying
      Party / Endorser / RVP), with topology (passport vs background-check) named
      and result-token audience/expiry/replay handling stated?
- [ ] Does verification policy explicitly reject debug-mode Evidence in prod?
      (grep policy for the platform's debug attribute; absence of any debug check
      is the finding.)
- [ ] Fresh nonce or channel-key hash bound into report data and checked by the
      Verifier (grep for report_data / REPORT_DATA / runtime-data handling)?
- [ ] Certificate chain verified to a pinned silicon-vendor root with revocation,
      roots obtained out-of-band from the vendor (not from the attested host)?
- [ ] TCB status handled as graded policy (each grade → release/alert/deny with
      deadlines), never a silent boolean accept?
- [ ] Measurements compared to reference values sourced from the build pipeline
      (reproducible builds / signed by CI), not fingerprinted from a running
      instance; SLSA provenance and runtime attestation both present and joined?
- [ ] Verifier trust and placement justified: not operated by the party being
      distrusted, HA-deployed, every verdict logged?
- [ ] Written TCB-recovery runbook: fleet re-attestation path, dual-validity
      reference-value rotation, time-boxed signed grace windows, expiry alerts?
- [ ] Re-attestation triggers defined (restart, lease renewal, policy change,
      schedule) and secret releases leased rather than perpetual?
- [ ] Attestation failures, debug-flag sightings, and TCB downgrades alert into
      the SOC as security signals, with appraisal transcripts retained?

# 04 — Confidential Kubernetes: Nodes, Pods & Confidential Containers

Scope: running confidential workloads on Kubernetes — the confidential-node vs
confidential-pod layers, the Confidential Containers (CoCo) stack (Kata TEE pods,
Trustee/KBS, agent policy, peer pods), and what changes operationally (secrets,
debugging, storage, image supply chain). This file owns only the *confidential*
layer. Control-plane/etcd/RBAC/admission/GitOps hardening is sota-kubernetes;
pod `securityContext`, seccomp and sandbox-boundary selection is sota-sandboxing
rules/01–03; TEE hardware depth is rules/02; attestation protocol depth is
rules/03; workload/threat selection is rules/01.

---

## 1. Two layers, two threat models

Kubernetes offers two distinct confidential layers. Naming them precisely is the
first audit question, because they protect against *different* adversaries.

| | Confidential **nodes** | Confidential **pods** (CoCo) |
|---|---|---|
| What it is | Whole worker node runs inside a confidential VM (SEV-SNP/TDX guest) | Each pod runs in its own TEE microVM (Kata) with a guest-side agent |
| Protects against | Cloud/infrastructure operator reading node memory; hypervisor-level snooping | All of the left column, **plus** the node OS, kubelet, node root, and the cluster admin |
| Does NOT protect against | K8s control plane, cluster admin, node root, kubelet, anything with `pods/exec` or hostPath — they are all *inside* the TEE | The pod's own code and its dependencies; side channels; availability (host can always kill the pod) |
| Trust boundary | Cloud provider excluded; cluster operator fully trusted | Cloud provider AND cluster operator excluded from the TCB |
| Attestation subject | The node VM (boot chain, firmware) | The pod's guest image, kata-agent config, agent policy, workload identity |
| Deployment friction | Near zero — a node-pool flag; workloads unchanged | Significant — RuntimeClass, guest image pull, KBS infrastructure, policy authoring, degraded debugging |

**R4.1 — Match the layer to the adversary from rules/01.** If the threat model
excludes only the *cloud provider* (data-in-use compliance, untrusted
infrastructure), confidential nodes suffice and cost almost nothing to adopt. If
it excludes the *cluster operator or platform team* (multi-party computation,
SaaS processing customer secrets, regulated data your own admins must not see),
only confidential pods deliver that — a confidential node changes nothing about
what `kubectl exec`, kubelet, or a node-root attacker can read. Selling
confidential nodes as protection from the cluster admin is a **Critical**
finding (false security claim).

**R4.2 — Confidential nodes do not attest your workload.** Node attestation
proves the *node VM* booted expected firmware/images; it says nothing about
which pods run there or what they do. Workload-bound attestation (rules/03)
requires pod-level TEEs where the evidence covers the guest image and policy.

**R4.3 — Layers compose.** CoCo pods on confidential-VM *hosts* is not
redundant: node-level encryption covers the non-CoCo system pods and kubelet
state, pod-level TEEs cover the sensitive workloads. But compose deliberately —
each layer adds attestation surface and failure modes.

---

## 2. Confidential nodes (managed offerings)

Provider GA states move fast; **re-verify
GA status at the provider's documentation before committing to a design.**

- **GKE Confidential GKE Nodes** — GA. Original GA on AMD SEV; AMD SEV-SNP and
  Intel TDX support is GA since GKE 1.32.2 on Standard clusters (Autopilot
  followed later, 1.35.2+), per Google's "Encrypt workload data in-use with
  Confidential GKE Nodes" docs. Enable per cluster or per node pool; machine
  series constrain which technology you get (e.g. N2D for SEV-SNP, C3 for TDX).
- **AKS confidential VM node pools** — GA on AMD SEV-SNP confidential VM sizes
  (DCasv5/ECasv5 families), per Microsoft's "Confidential VM node pools support
  on AKS" docs. Node pools of CVMs join a standard AKS cluster; guest
  attestation of the node is available.
- Other clouds/regions expose confidential-VM instance types that managed or
  self-managed node groups can use — treat "does the managed control plane
  support it" and "does the instance type exist in my region" as two separate
  verifications.

**R4.4 — Enable attestation-gated scheduling where the platform offers it, or
document that node attestation is unverified.** A confidential node whose
attestation nobody checks provides encryption-in-use but no *evidence*; that
downgrade must be a recorded decision, not an accident. (Medium)

**R4.5 — Confidential nodes change ~nothing else.** K8s Secrets, CSI volumes,
observability, `kubectl exec` all work unchanged — because the control plane is
still fully trusted. That convenience is precisely the limitation.

---

## 3. Confidential pods: the CoCo stack

**Confidential Containers (CoCo)** is a CNCF project (Sandbox maturity at the
time of writing — verify current level at cncf.io/projects before citing it in
a design review) that encapsulates each Kubernetes pod in its own TEE:

```
untrusted host (node)                      TEE guest (per pod)
┌─────────────────────────┐   ttRPC   ┌────────────────────────────┐
│ kubelet → containerd    │──────────▶│ kata-agent  ── OPA policy  │
│  └ kata shim (runtime)  │  (policy- │  ├ image-rs: pull, verify  │
│ CSI / CNI plugins       │  filtered)│  │  signatures, decrypt    │
│ sees: ciphertext pages, │           │  ├ confidential-data-hub   │
│ encrypted images, API   │           │  └ attestation-agent ──────┼──▶ Trustee
│ calls it may not issue  │           │        (evidence)          │    (KBS+AS)
└─────────────────────────┘           └────────────────────────────┘
```

Components (all under github.com/confidential-containers and the Kata
Containers project, which lives under the OpenInfra Foundation):

- **Kata Containers TEE runtime** — the pod runs in a microVM whose memory the
  host cannot read (SEV-SNP/TDX guest; see rules/02). A `RuntimeClass` (e.g.
  `kata-qemu-snp`, `kata-qemu-tdx`, platform-specific names) selects it per pod.
- **Guest image pull** — images are pulled and unpacked *inside the guest* by
  `image-rs`; a host-side snapshotter diverts the pull so the node never holds
  plaintext layers. This is load-bearing: host-side pull would hand the
  operator every byte of the image. Consequences: no node-level layer cache
  (pull cost per pod), and pod memory/disk must be sized for image contents.
- **Attestation-agent + Trustee** — the guest collects TEE evidence and sends
  it to **Trustee** (CoCo's trust-side components): the **Attestation Service
  (AS)** appraises evidence against reference values and policy; the **Key
  Broker Service (KBS)** is the relying party that releases secrets —
  image-decryption keys, sealed-secret unwrap keys, workload credentials —
  *only after* appraisal passes (the RCAR "background check" flow). This is
  the attest-then-release pattern of rules/03 applied to Kubernetes.
- **Confidential Data Hub (CDH)** — in-guest broker exposing sealed-secret
  unsealing and key-release APIs to the workload.
- **Peer pods / cloud-api-adaptor** — where you cannot run a TEE VM *on* the
  node (clouds without SEV-SNP/TDX bare-metal or child-VM support), the
  cloud-api-adaptor creates the pod VM as a sibling confidential VM via the
  cloud API instead of nesting it. Same CoCo control flow, different VM
  placement; network path and per-pod cost differ materially — verify current
  provider support in the cloud-api-adaptor repo.

**R4.6 — Nested virtualization is generally unavailable for SEV-SNP/TDX guests;
plan for bare metal or peer pods.** Classic nesting requires the host VMM to
read guest state, which is exactly what these TEEs prevent. On-prem CoCo means
Kata on bare-metal SEV-SNP/TDX hosts; in clouds it means either bare-metal
instances, a provider-specific child-VM mechanism (e.g. the SEV-SNP child VMs
of Azure's DCas_cc_v5-class sizes — though the AKS preview built on them is
retired, §6), or peer pods. A design that assumes
"CoCo on ordinary cloud VMs" is a **High** finding (it will not attest, or not
run).

### Agent policy: containing the untrusted host's API

The host talks to the pod only through the kata-agent's ttRPC API — so that API
*is* the attack surface the cluster admin retains. The **Kata agent policy**
mechanism (documented in the Kata Containers repo, "How to use the Kata Agent
Policy") closes it:

- A Rego policy document is attached to the pod; the kata-agent evaluates
  **every incoming API request** against it with an in-guest OPA engine and
  rejects anything not allowed ("blocked by policy").
- Locked-down policies deny `ExecProcess`, `ReadStream`/`WriteStream` (logs,
  stdio) and restrict container creation to the exact images, commands, mounts
  and env vars expected — so the host cannot inject a shell, exec a debug
  process, or read output.
- The policy digest is bound into the attestation evidence (e.g. on AKS the
  SHA-256 of the generated policy is the workload measurement used for secure
  key release; generic CoCo binds it via the init-data mechanism — verify the
  binding path for your platform). Trustee policy can then refuse keys to any
  pod running a weakened policy.

**R4.7 — A CoCo pod without a restrictive agent policy is not confidential from
the cluster admin.** Default-open agent APIs let the host exec into the guest —
the entire point of the layer evaporates. Generate the policy from the pod
manifest (e.g. `az confcom katapolicygen`-style tooling or CoCo's policy
tooling), pin image references by digest inside it, and verify the KBS refuses
release when the policy digest differs. Missing/permissive policy on a pod
claimed confidential: **Critical**.

---

## 4. What changes operationally

### Secrets

**R4.8 — Secrets come from the KBS after attestation, never from plain K8s
Secrets.** A K8s `Secret` lives in etcd, is readable by the control plane and
anyone with RBAC `get secrets`, and is delivered by the kubelet — three parties
your threat model just excluded. Patterns that work:

- Fetch at startup from the KBS (via CDH/attestation-agent) — the key exists
  only in TEE memory.
- **CoCo sealed secrets** — ciphertext stored as an ordinary K8s Secret,
  unsealed *inside the guest* via a KBS-released key; the control plane carries
  only ciphertext.

BAD: `envFrom: secretRef` on a confidential pod (control plane and host see
plaintext; on AKS, env vars from Secrets are additionally frozen into the
policy at deploy time). GOOD: sealed secret or in-guest KBS fetch. Plaintext K8s
Secret feeding a confidential pod's sensitive data: **High**.

### Observability and debugging

**R4.9 — Plan for deliberately degraded debugging before the first incident.**
With a locked-down agent policy there is no `kubectl exec`, no `kubectl logs`,
no ephemeral debug containers — by design. Required up front:

- A **debug variant** of the workload (policy allowing exec/logs) that the KBS
  distinguishes: debug-policy pods must receive *non-production* keys or none.
- A **break-glass procedure**: who may deploy the debug policy, where (never
  against production data), and how it is logged. Break-glass process depth is
  sota-identity-access.
- **In-guest telemetry egress**: the workload ships its own logs/metrics/traces
  to a collector over TLS, with the pipeline treating them as sensitive
  (rules/01 data-egress decisions; pipeline design is sota-observability).
  Anything the host can read (termination logs, stdio) is not available or not
  trustworthy.

No documented break-glass/debug plan for a production CoCo estate: **Medium**;
production KBS releasing prod keys to debug-policy pods: **Critical**.

### Storage

**R4.10 — Any volume mounted by the host is visible to the host.** CSI-provided
block/file volumes, hostPath, and even Secret/ConfigMap volumes traverse the
untrusted node. Rules:

- Sensitive data at rest → encrypt **in-guest** (e.g. dm-crypt/LUKS or
  application-layer encryption inside the pod) with keys released by the KBS
  after attestation. Cloud-managed disk encryption does NOT help here — its
  keys are held by the very infrastructure you distrust.
- Guest-internal ephemeral storage is memory-backed in typical CoCo
  configurations: heavy writes (including chatty logging to the container fs)
  consume pod memory and can OOM the pod — size limits accordingly (documented
  behavior on AKS CoCo).
- ConfigMap/Secret volume content and env vars may be pinned in the agent
  policy at deploy time; treat post-deploy mutation as unsupported.

---

## 5. Image supply chain interplay

**R4.11 — Move image trust decisions inside the guest.** CoCo supports
**encrypted container images** (decryption key released by the KBS only after
attestation — the registry and the node see only ciphertext) and **signature
verification inside the guest** (image-rs validates signatures against policy
before unpacking). Signing, provenance and registry hygiene are sota-devsecops;
this file adds: for a confidential workload, verification must happen *in the
TEE*, because a host-side check is a claim by the party you distrust.

**R4.12 — Admission control still applies; it just cannot see inside the TEE.**
Kyverno/Gatekeeper/ValidatingAdmissionPolicy (sota-kubernetes) still validate
the pod *spec* — RuntimeClass, annotations, image references, namespace policy
— and should enforce "pods in this namespace must use the confidential
RuntimeClass and carry a policy annotation". What admission cannot verify is
what executes inside the guest; that assurance comes from attestation + agent
policy + KBS policy. Do not let an admission-passed manifest be read as "the
workload is attested" — those are different verifiers with different evidence.

---

## 6. Choosing a deployment shape

| Requirement | Shape | Status caveat |
|---|---|---|
| Hide node memory from cloud operator, trust cluster admins | Confidential node pools (GKE Confidential GKE Nodes, AKS CVM node pools) | GA on both (verify region/machine-series support) |
| Pod-level TEE, managed, on Azure | AKS Confidential Containers (Kata + SEV-SNP child VMs) is **retired** — the preview never reached GA; Microsoft announced a March 2026 sunset with the runtime class removed. Confidential Containers on ACI (serverless, SEV-SNP, policy + secure key release) is the remaining managed option | Do not build on the retired AKS preview; verify current Azure offerings |
| Pod-level TEE on GKE | Not a managed GKE feature at time of writing (GKE's managed offering is node-level); self-managed CoCo on confidential/bare-metal nodes | Verify current GKE offerings |
| Pod-level TEE, self-managed / on-prem | CoCo operator + Kata on bare-metal SEV-SNP/TDX hosts, self-hosted Trustee | You own reference values, KBS HA, guest-image lifecycle |
| Pod-level TEE on a cloud without nesting/bare metal | CoCo peer pods (cloud-api-adaptor) on the provider's confidential VMs | Verify provider support matrix in the cloud-api-adaptor repo |
| Entire cluster (incl. control plane) shielded from the infrastructure provider | Confidential-cluster distributions that run every node in attested CVMs (e.g. Constellation, described in the Kubernetes blog "Confidential Kubernetes") | Cluster admin is still trusted — this is the node layer, cluster-wide |

**R4.13 — Preview features do not carry production confidentiality claims.**
If the platform labels the confidential feature preview/beta, the design doc
must say so and name the fallback. Compliance evidence built on a preview
feature without recorded risk acceptance: **High**.

---

## 7. Honest limitations (state these in every design doc)

- **Availability is never protected.** The host schedules, throttles, pauses,
  and kills TEE pods at will; it controls the network and the clock visible to
  the guest. Confidential computing protects confidentiality and integrity of
  memory — a malicious host can always DoS you. Any design that assumes the
  TEE guarantees liveness or timely execution is wrong (High).
- **Side channels are out of scope of the hardware guarantee.** Architectural
  side channels, controlled-channel/single-stepping attacks, and
  ciphertext-side-channel classes against SEV-SNP have published research;
  mitigations are firmware/kernel-version-dependent (rules/02). Cross-tenant
  co-residency of a TEE with attacker-controlled workloads remains a risk to
  document, not to dismiss.
- **The TCB moved, it didn't vanish.** You now trust the CPU vendor, its
  firmware/microcode supply chain, the guest kernel + kata-agent + image
  stack, your policy tooling, and Trustee. Track guest-image and CoCo-stack
  CVEs like any other base image (sota-devsecops).
- **Maturity.** CoCo is a CNCF Sandbox project at time of writing; managed
  pod-level Kubernetes offerings have been preview-labeled or retired (AKS's
  preview sunset in March 2026 without reaching GA); APIs (init-data, policy formats)
  are still evolving. Pin versions, read release notes at
  confidentialcontainers.org, and re-verify this file's status claims —
  they are the fastest-moving facts in this skill.
- **Performance/limits.** Pod startup is slower (VM boot + in-guest pull);
  memory overhead per pod is VM-sized; some K8s features (exec/logs, resource
  requests semantics, termination logs, protocol support) are restricted —
  check the platform's documented limitations list before porting a workload.

---

## Audit checklist

- [ ] Does the design state which adversary each confidential layer excludes —
      and is "protects from cluster admin" claimed only for pod-level TEEs,
      never for confidential nodes? (grep design docs for `confidential node`
      near `cluster admin`)
- [ ] Is the GA/preview status of every managed confidential feature verified
      against current vendor docs and recorded, with preview use risk-accepted?
- [ ] Do confidential pods declare a TEE RuntimeClass, and does admission
      policy enforce it for the sensitive namespaces? (`grep -r
      runtimeClassName` manifests; check Kyverno/VAP rules)
- [ ] Is a restrictive Kata agent policy attached to every confidential pod,
      generated from the manifest, denying exec/log APIs, with its digest bound
      into attestation and checked by KBS policy?
- [ ] Do secrets reach confidential pods only via attest-then-release (KBS
      fetch or sealed secrets) — no plaintext K8s Secret feeds sensitive data?
      (`grep -r "secretKeyRef\|envFrom" manifests` for confidential workloads)
- [ ] Are images for confidential pods pulled inside the guest, signature-
      verified in-guest, and (where confidentiality requires) encrypted with
      KBS-held keys?
- [ ] Is host-visible storage treated as untrusted — in-guest encryption with
      attestation-released keys for any sensitive persistent volume, and no
      hostPath into confidential pods? (`grep -r hostPath` manifests)
- [ ] Does a written debug/break-glass plan exist — debug-policy pods, KBS
      refusing production keys to them, logged approval path?
- [ ] Is in-guest telemetry egress in place (the team is not depending on
      `kubectl logs`/termination logs for a locked-down pod)?
- [ ] Are Trustee (KBS/AS) availability, reference-value updates, and policy
      change control owned and documented (rules/03 for appraisal depth)?
- [ ] Does the design doc contain the limitations block — no availability
      guarantee, side-channel posture, moved-not-removed TCB, maturity
      caveats?
- [ ] Are bare-metal/child-VM/peer-pod placement constraints verified for the
      target environment (no silent assumption that TEE VMs nest on ordinary
      cloud instances)?

# 05 — PETs & Computing on Encrypted Data (FHE, MPC, ZKP, PSI)

Scope: cryptographic privacy-enhancing technologies that compute on encrypted or
secret-shared data with **no hardware trust anchor** — FHE, MPC/threshold schemes,
ZKPs, and the PSI/OPRF primitives behind the deployments that actually shipped.
Umbrella term: **COED** (computing on encrypted data). This file owns the
choose/deploy/audit rules for these tools and the honest cost model. It does NOT
own: TEE selection and the isolation ladder (rules/01–02), attestation (rules/03),
confidential K8s (rules/04), differential privacy and data-minimization
(sota-privacy-compliance rules/02), federated learning / DP-SGD
(sota-ml-engineering rules/07), or classical crypto — AEAD, TLS, key management
(sota-code-security rules/04 + sota-secrets-management rules/01).

---

## 1. Positioning: trust math instead of silicon — and pay for it

**R5.1 — Know what you are buying.** A TEE (rules/02) removes the host operator
from the TCB but keeps the silicon vendor, the microcode, and the attestation PKI
in it. COED removes *all* of them: confidentiality rests only on a hardness
assumption (typically lattice problems for FHE, standard assumptions for
MPC/ZKP). The price is orders of magnitude: FHE runs roughly **1,000×–1,000,000×
slower than plaintext** depending on workload — DARPA's DPRIVE program, which
funded FHE hardware accelerators, used the ~million-times figure as its baseline.
MPC pays in network rounds and bandwidth instead of CPU; ZKP pays at proving time.

**R5.2 — Decision-first triage: most "we need FHE" asks are not FHE problems.**
Before any COED design, force the requirement through this ladder:

| The actual requirement | Correct tool |
|---|---|
| "Cloud/host operator must not see the data" | TEE (rules/01 ladder) — same guarantee vs. that adversary, ~native speed |
| "Analytics output must not identify individuals" | Differential privacy / aggregation → sota-privacy-compliance rules/02 |
| "We must not hold this data at all" | Data minimization / pseudonymization → sota-privacy-compliance rules/02 |
| "Server must answer a query without learning the query" | PIR / PSI / OPRF (§5) — the one COED shape that ships at scale |
| "Two orgs must compute jointly, neither may see the other's inputs, and neither will accept a TEE vendor in the TCB" | MPC (§3) |
| "Prove a property of hidden data to a verifier" | ZKP (§4) |
| "Untrusted server computes an arbitrary function on data it may never see, no hardware trust allowed" | FHE (§2) — the narrow residual case |

A design doc that reaches for FHE without recording why a TEE or DP fails the
threat model is a **Medium** finding; if it also promises general-purpose
throughput, **High**.

**R5.3 — Real deployments illustrate the triage.** Signal's private contact
discovery runs in SGX enclaves — Signal's engineering blog explicitly lists
PSI-class approaches among the options that didn't work at their scale. When a
privacy-maximalist product picks the TEE, treat that as calibration for your own
cost-benefit, not as an anomaly.

---

## 2. FHE — fully homomorphic encryption

### 2.1 Scheme families: pick by workload shape, not by fashion

| Family | Computes | Use for | Notes |
|---|---|---|---|
| **BGV / BFV** | Exact modular-integer arithmetic (SIMD-batched) | Counting, exact aggregates, PIR lookups, database-style workloads | Apple's stack uses BFV (post-quantum 128-bit parameter sets) |
| **CKKS** | *Approximate* fixed-point/real arithmetic | ML inference, statistics, signal processing where small error is acceptable | Approximation error is a security surface — see R5.7 |
| **TFHE / CGGI (FHEW-family)** | Boolean gates and programmable lookup tables, fast bootstrapping per gate | Comparisons, branching, non-polynomial functions, small-integer logic | Complements the arithmetic families; scheme-switching combines them |

Choosing CKKS for exact money arithmetic or BFV for a comparison-heavy circuit
is a design error (Medium): the workaround circuits eat the performance budget.

### 2.2 Standardization status (verify at time of use — this moves)

- **ISO/IEC 28033** (JTC 1/SC 27) is standardizing exactly these families:
  Part 1 general, Part 2 BGV/BFV, Part 3 CKKS, Part 4 lookup-table (TFHE-style)
  evaluation, Part 5 scheme switching. As of mid-2026, Parts 1–4 are at **DIS**
  stage (Part 2 DIS voting closed April 2026) and Part 5 is a Working Draft —
  i.e., **not yet published**; publication was expected around end of 2026.
  Verify current stage at iso.org before citing it as "standardized".
- **ISO/IEC 18033-6:2019** already covers *partially* homomorphic mechanisms
  (ElGamal/Paillier-style) — sufficient for additive-only aggregation designs.
- **NIST** has no FHE competition; the **PEC (Privacy-Enhancing Cryptography)
  project** tracks FHE/MPC/ZKP/PSI and runs workshops (MPTS 2026 included a
  threshold-FHE session). Track csrc.nist.gov/projects/pec for status.
- The community **Homomorphic Encryption Security Standard**
  (HomomorphicEncryption.org) publishes the lattice-parameter tables that
  mainstream libraries encode as named security levels.

### 2.3 Libraries

Use an actively maintained, audited library (latest stable; verify maintenance
and open security issues before adopting): e.g. **OpenFHE** (C++; BGV, BFV,
CKKS, FHEW/TFHE variants, threshold FHE, proxy re-encryption) or **TFHE-rs**
(Rust; TFHE with programmable bootstrapping). Check the license before
committing: some FHE libraries ship under restricted licenses — TFHE-rs is
BSD-3-Clause-Clear and its maintainer states commercial use requires a separate
patent license — a procurement/legal gate, not just an engineering one.
Microsoft **SEAL** and Apple **swift-homomorphic-encryption** are the vendors'
own production libraries (§2.4). Writing your own scheme implementation is a
**Critical** finding outside a research context.

### 2.4 Honest performance reality

Production FHE successes are **narrow, private-lookup/PSI-shaped features**,
not general compute:

- **Apple Live Caller ID Lookup** (iOS 18): the phone sends a BFV-encrypted
  query; the server answers a spam/identity lookup via PIR without learning the
  number (open-sourced as swift-homomorphic-encryption).
- **Microsoft Edge Password Monitor**: SEAL-based HE plus an OPRF checks saved
  credentials against a breach corpus without revealing them to the server.

Common shape: tiny client-side ciphertexts, a server-side keyword/PIR lookup, a
tiny response — no deep multiplicative circuits, no encrypted training. Budget
rule: prototype with your real data sizes and measure ciphertext expansion
(often 10–1000×) and latency before committing; "we'll optimize later" is not a
plan at 4–6 orders of magnitude.

### 2.5 FHE security notes (audit anchors)

**R5.5 — Parameters ARE the security level.** Ring dimension, modulus chain,
and noise parameters jointly determine both correctness and the lattice security
level. Use the library's named standard parameter sets (128-bit+); any
hand-rolled parameter selection without a lattice-estimator analysis signed off
by a cryptographer is a **Critical** finding. Grep for custom
`ring_dim`/`poly_modulus_degree`/modulus values that differ from library presets.

**R5.6 — FHE gives confidentiality, not integrity.** Ciphertexts are malleable
*by design*; a malicious server can compute the wrong function or garbage and
the client cannot tell. If result correctness matters (payments, model outputs
acted on automatically), FHE alone is insufficient: add a verifiability layer —
ZKP over the evaluation, redundant evaluation across independent parties, or
run the evaluator inside an attested TEE (rules/02–03). An FHE design that
silently assumes an honest-but-curious server must state that assumption in the
threat model; omitting it is a **High** finding.

**R5.7 — CKKS decryption-sharing leakage (IND-CPA-D).** Li–Micciancio
(Eurocrypt 2021) showed that sharing CKKS *decrypted* results with anyone who
can also see ciphertexts leaks the noise and enables key recovery — the
IND-CPA-D model. Countermeasure is noise flooding with **worst-case** noise
estimates; Guo et al. (USENIX Security 2024) broke non-worst-case flooding with
practical key-recovery attacks. Rule: if any party other than the secret-key
holder ever observes CKKS decryptions (including "just approximate statistics"),
you need the library's IND-CPA-D-hardened decryption mode (OpenFHE documents
one) — absent that, **High**.

---

## 3. MPC and threshold cryptography

**R5.8 — Two protocol families, different cost profiles.** Conceptually:
*secret-sharing* protocols (Shamir/SPDZ-style) split every value across parties
and pay per multiplication in communication rounds — good for arithmetic on big
data among few well-connected parties; *garbled-circuit* protocols (Yao-style)
have constant rounds — good for high-latency links and boolean logic. Libraries
implement the choice; you choose the deployment topology and the trust model.

**R5.9 — The security model must be stated, not implied.**
- **Semi-honest** (honest-but-curious): parties follow the protocol but try to
  learn from transcripts. Cheap; adequate only when parties are contractually
  bound and misbehavior would be detectable/attributable out-of-band.
- **Malicious**: parties may deviate arbitrarily. Substantially more expensive;
  required when a compromised party is in the threat model.
Any MPC deployment doc that does not name its model is a **High** finding;
claiming "cryptographically private" while running semi-honest against
untrusted counterparties is **Critical**.

**R5.10 — Collusion assumptions are the whole game.** An n-of-m threshold means
security evaporates the moment `n` parties collude or are compromised by the
same actor. Parties must be *genuinely* independent: different operators,
different clouds/jurisdictions, different admin credentials. Three "parties"
that are three pods in one Kubernetes cluster under one ops team is one party
with extra steps (**Critical**). Document who operates each party and why they
won't collude; revisit at every org change.

**R5.11 — What actually deploys.** Threshold signing/custody (splitting a
signing key so no single host ever holds it — standard in digital-asset custody
and increasingly for CA/root keys), PSI (§5), and federated/private analytics
(e.g. Google's open-sourced Private Join and Compute for joint aggregate
statistics). **NIST IR 8214C — "NIST First Call for Multi-Party Threshold
Schemes" — was published in final form in January 2026**; it collects reference
material across threshold signing, PKE, key generation, threshold-FHE, and
ZKPoK (submission previews run through 2026). Track it for which
constructions gain reference status before standardizing internally.

---

## 4. ZKP — zero-knowledge proofs

**R5.12 — What ZKP adds.** Verifiable computation and credentials *without
revealing the witness*: prove "this result came from running program P on data I
won't show you", "I am over 18 / hold a valid credential", "this batch of
transactions is valid". ZKP proves integrity of a hidden computation — the
complement of FHE (confidential computation with no integrity, R5.6).

**R5.13 — SNARK vs STARK, conceptually.** SNARKs: tiny proofs and cheap
verification; older systems (Groth16-style) need a **per-circuit trusted
setup**, newer universal-setup systems need one ceremony total; pairing-based
constructions are *not* post-quantum. STARKs: no trusted setup (transparent),
hash-based and thus plausibly post-quantum, but larger proofs and costlier
verification. Choose on: who verifies (on-chain gas vs. a server), whether a
setup ceremony is operationally acceptable, and PQ posture requirements.

**R5.14 — Circuits are security-critical code; soundness bugs are silent
catastrophes.** A circuit that under-constrains one variable lets a prover
"prove" false statements — with no crash, no log line. Canonical case: the
BCTV14 proving-system flaw behind Zcash's original Sprout pool (discovered
March 2018, disclosed February 2019) would have allowed **undetectable
counterfeiting**. Treat circuits like consensus code:
- independent audit before production (**High** if missing);
- adversarial tests: attempt to prove *false* statements, not just verify true
  ones — a test suite with only honest-path tests is a **Medium** finding;
- formal/static circuit analyzers where the toolchain has them;
- use standard proof systems via maintained libraries and DSLs (latest stable;
  the ecosystem — Circom, Noir, halo2, gnark, arkworks-class tooling — moves
  fast, verify maintenance). Hand-rolled proof systems: **Critical**.

**R5.15 — Trusted-setup ceremonies are production infrastructure.** If your
system needs one: multi-party ceremony where one honest participant suffices,
transcript published, toxic waste destruction documented. Reusing another
project's setup requires verifying the circuit/parameters actually match.
An unceremonied or undocumented setup is **High**.

---

## 5. PSI / OPRF — the workhorses that actually ship

**R5.16 — Recognize the PSI/OPRF shape and use it before reaching for FHE/MPC
generality.** "Does my item appear in your set, without either side revealing
their set" covers most deployed COED: password-breach checking (Google's
Password Checkup blinds hashed credentials with an elliptic-curve OPRF —
secp224r1 exponent blinding — so Google never sees the credential and the
client never sees the corpus; Edge Password Monitor combines an OPRF with HE),
private compliance/deny-list lookups, ad-conversion measurement
(Private Join and Compute). These protocols are mature, fast enough for
production, and far simpler to audit than general FHE/MPC.

**R5.17 — PSI still leaks by design: size and intersection.** Standard PSI
reveals set sizes and which elements matched (to at least one party). If the
*cardinality* or the *match events* are themselves sensitive, you need PSI
variants (PSI-CA, PSI with associated data, unbalanced PSI) — pick the variant
against a written leakage budget, and rate-limit queries: an online PSI oracle
queried adaptively enumerates the other side's set element by element
(**High** if unthrottled).

---

## 6. Selection table and hybrids

| Goal | Reach for | Trust residue | Cost |
|---|---|---|---|
| Hide data from the compute host | **TEE** (rules/01–02) | Silicon vendor + attestation PKI | ~native |
| Same, but hardware vendors excluded from TCB | **FHE** | Lattice hardness + library correctness | 10³–10⁶× |
| Joint compute, no party sees others' inputs | **MPC** | Non-collusion of ≥ threshold parties | Network-bound, 10–1000× |
| Prove a claim without revealing the witness | **ZKP** | Circuit soundness (+ setup ceremony if SNARK) | Prover-side heavy |
| Membership lookup without revealing query/set | **PSI/OPRF** | Protocol assumptions + leakage budget | Near-production speed |
| Publishable aggregate outputs | **DP** → sota-privacy-compliance rules/02 | Epsilon budget honesty | ~native |

Hybrids worth knowing (each layer keeps its own threat model, per the
independent-layers principle in sota-sandboxing rules/01):
- **TEE + MPC**: parties each run in attested enclaves; MPC covers "we distrust
  each other", TEE covers "we distrust each host" at near-native speed.
- **FHE + ZKP**: FHE for input confidentiality, ZKP that the server evaluated
  the agreed function — patches R5.6's integrity hole.
- **TEE as FHE integrity anchor**: run the FHE evaluator inside an attested
  enclave; cheaper than ZK-verified FHE, reintroduces silicon trust for
  *integrity only* (confidentiality still rests on the math).
- **MPC/threshold for key custody of everything else**: threshold-protect the
  TEE sealing keys or the FHE secret key so no single admin can decrypt.

---

## 7. Anti-patterns (instant findings)

- Hand-rolled FHE parameters or a homemade scheme/proof system. (**Critical**)
- MPC "parties" operated by one organization/cluster/admin domain. (**Critical**)
- CKKS decryptions shared beyond the key holder without IND-CPA-D-hardened
  noise flooding. (**High**)
- FHE result trusted for integrity with no ZKP/TEE/redundancy and no recorded
  honest-server assumption. (**High**)
- MPC deployment with unstated adversary model, or semi-honest sold as
  "malicious-secure". (**High** / **Critical**)
- ZK circuit in production without independent audit or false-statement tests. (**High**)
- Unthrottled online PSI endpoint (adaptive set enumeration). (**High**)
- FHE chosen where the threat model is satisfied by a TEE or DP; no comparison
  recorded. (**Medium**)
- Citing ISO/IEC 28033 as a published standard without checking its current
  stage. (**Low**)

---

## Audit checklist

- [ ] Requirement triaged through §1 R5.2: is there a written rationale for why
      a TEE (rules/01) or DP (sota-privacy-compliance rules/02) does not satisfy
      the threat model before any FHE/MPC build?
- [ ] FHE scheme family matches workload shape (BGV/BFV exact, CKKS approximate,
      TFHE boolean/lookup) — no exact-arithmetic-on-CKKS or comparison-heavy BFV?
- [ ] All FHE parameters come from library standard/named parameter sets at
      ≥128-bit? (grep for custom `poly_modulus_degree`, `ring_dim`, modulus
      chains diverging from presets)
- [ ] Library actively maintained, latest stable, license/patent terms cleared
      (e.g. BSD-3-Clause-Clear commercial restrictions)?
- [ ] If CKKS decryptions are ever shared: IND-CPA-D-hardened decryption
      (worst-case noise flooding) enabled?
- [ ] Result-integrity story explicit: ZKP/TEE/redundant evaluation, or a
      documented honest-but-curious server assumption?
- [ ] Measured (not estimated) latency and ciphertext expansion on production
      data sizes before commitment?
- [ ] MPC: adversary model (semi-honest vs malicious) stated in the design doc
      and matched to counterparty trust?
- [ ] MPC: party operators enumerated with genuinely independent admin domains;
      collusion analysis dated and revisited on org changes?
- [ ] ZKP: standard proof system via a maintained library — no hand-rolled
      crypto? Circuit independently audited? Test suite attempts to prove FALSE
      statements?
- [ ] SNARK trusted setup: multi-party ceremony documented, transcript
      published, parameters verified to match the circuit in use?
- [ ] PSI: leakage budget written (set sizes, match events); online endpoints
      rate-limited against adaptive enumeration?
- [ ] Standards claims current: ISO/IEC 28033 stage, NIST PEC / IR 8214C
      threshold-call status re-verified, not copied from stale docs?
- [ ] DP, consent, and minimization questions routed to sota-privacy-compliance;
      DP-SGD/federated learning to sota-ml-engineering rules/07; classical
      crypto to sota-code-security rules/04?