09 — Confidential Computing

Technologies to protect data in use (in-RAM), beyond in-transit (TLS) and at-rest (LUKS). The trust anchor moves away from the hardware operator and goes to the CPU vendor's silicon.

1. Threat model

Confidential Computing protects against:

• Malicious hypervisor (cloud provider, compromised host).
• Curious or compromised sysadmin.
• DMA attacks (PCILeech, Thunderbolt).
• Cold boot (with SME/TME).
• Memory bus snooping (with on-die memory encryption).

It does not protect against:

• Bugs in the enclave / VM itself (it can leak voluntarily).
• CPU vendor compromise (AMD/Intel root of trust).
• Side-channel from the same CPU (Spectre, Foreshadow, ÆPIC, Downfall).

2. TPM (Trusted Platform Module) 2.0

TCG (Trusted Computing Group) standard. ISO/IEC 11889. A dedicated chip or firmware (fTPM) that provides:

• Hardware RNG (true RNG).
• Cryptographic primitives: RSA-20483072, ECC P-256384, AES-128256, SHA-1256/384.
• Secure storage: keys never leave the chip (sealed).
• Platform Configuration Registers (PCRs): registers that measure firmware/boot.
• Attestation: proves to a remote verifier that the boot state is intact.
• NV (Non-Volatile): limited storage of keys/data.
• Hierarchies: Endorsement (vendor key), Storage (user keys), Platform (firmware).

PCRs (Platform Configuration Registers)

24 registers (PCR 0–23). Each PCR can only be extended, not written:

TCG PC Client mapping (classic):

Sealing

Encrypt a secret to specific PCR values. Decrypt only works if the PCRs match:

sealed_blob = TPM_Seal(secret, policy={PCR0=h0, PCR7=h7})
TPM_Unseal(sealed_blob) → secret  // only if current PCR0=h0 AND PCR7=h7

Used in BitLocker, dm-crypt + clevis, sd-cryptenroll for auto-unlock if boot is intact.

Attestation

A client wants to prove its boot state to a server:

1. Server sends a nonce.
2. Client: tpm2_quote -c ak -l sha256:0,1,2,3,4,5,7 -q nonce.
3. TPM signs (Quote = PCRs + nonce + attestation key).
4. Server validates the sig with the AK pubkey, verifies the PCRs against a baseline.
5. Server validates the AK ↔ EK chain: the AK was created in a TPM with an EK certified by the vendor.

EK (Endorsement Key) certificate

Vendors (Infineon, Nuvoton/NPCT, ST) issue a certificate per TPM at manufacture. Chain: Vendor Root CA → Intermediate CA → EK certificate. The verifier can validate the authenticity of the TPM.

TPM 1.2 vs 2.0

• TPM 1.2: SHA-1 only, RSA only, deprecated.
• TPM 2.0: SHA-2/3, ECC, AES, multi-algorithm, hierarchies. The modern standard.

dTPM vs fTPM

• dTPM (discrete): separate chip (Infineon SLB 9670, Nuvoton NPCT75x). Harder to compromise; EK cert chain outside firmware control.
• fTPM (firmware): implemented inside the PSP (AMD) or MECSME (Intel). Convenient, no extra hardware. Vulnerability: firmware-bug = TPM-bug. CVE-2023-10171018 (TPM 2.0 spec bug). In 2023 an AMD fTPM bug caused stutter on Windows.

TPM and LUKS2

sudo systemd-cryptenroll /dev/nvme0n1p3 --tpm2-device=auto --tpm2-pcrs=0+7

PCR 0 = firmware, PCR 7 = secure boot policy. Intact boot → automatic unlock. Tampered firmware → tpm refuses to unseal.

3. Secure Boot

UEFI Specification (Microsoft-driven; the Linux Foundation has shim).

Components

• PK (Platform Key): master, usually Microsoft.
• KEK (Key Exchange Keys): signed by the PK.
• db: hashes/certs of allowed OS loaders.
• dbx: revocations.

Flow

1. UEFI validates the bootloader (signature in db).
2. Microsoft signs shim for Linux: shim is a trusted "kick-the-can".
3. shim validates grub/systemd-boot via the MOK (Machine Owner Key) that the owner added.
4. grub validates the kernel + initramfs (signed kernel image; signed cmdline).
5. The kernel measures into the PCRs (IMA).

Result: a chain of trust from firmware to userspace.

Attacks

• BootHole (CVE-2020-10713) — buffer overflow in GRUB2 config parsing; bypasses Secure Boot.
• Boothole 2 / 3 — variants throughout 2021–2022.
• Black Lotus UEFI bootkit (2023) — bypasses Secure Boot via vulnerable EFI binaries.
• LogoFAIL (CVE-2023-...) — image parsing bugs in vendor bootkit logos.

Boot Guard / PSB (Platform Secure Boot)

OEM mechanism: fuses in the CPU contain the hash of an OEM key (Dell, HPE, Supermicro). UEFI validates the BIOS code before executing it.

• Intel Boot Guard: 3 modes (Verified, Measured, Verified+Measured).
• AMD PSB: Platform Secure Boot. fuse of OEM key hash.

"Enforce" mode → blocks a modified BIOS. "Audit" mode → logs and continues (compromised).

4. Intel SGX (Software Guard Extensions)

Introduced in Skylake (2015). Enclaves within the same OS as untrusted applications.

Concept

• Enclave: a protected memory region, encrypted by the MEE (Memory Encryption Engine).
• Executes signed code.
• The OS/hypervisor cannot read the enclave's memory.
• Remote attestation via the Intel Attestation Service (IAS) or DCAP.

Limitations

• EPC (Enclave Page Cache): 128 MB total on the chip; more than that = expensive paging.
• No syscalls: the enclave makes an OCALL outward.
• Side-channel attacks: SGX leaked in every class of attack found in 2018–2022.

Attacks

• Foreshadow / L1TF (2018) — leaks enclave memory via the L1 cache.
• SGAxe (2020) — extracts Intel attestation keys.
• CrossTalk (2020) — cross-core via shared resources.
• ÆPIC Leak (2022) — APIC SRAM leak.
• Downfall (2023) — the Gather instruction leaks data.

Status

Intel discontinued SGX on consumer chips (12th gen Alder Lake+, 2021). Kept on Xeon (server) but the community has largely abandoned it in favor of TDX.

Cloud SGX-based services in decline: Microsoft Confidential Inferencing pivoted to CVMs (TDX/SEV-SNP).

5. AMD SEV / SEV-ES / SEV-SNP

SEV = Secure Encrypted Virtualization. The VM's memory is encrypted with a key the hypervisor does not know. Available on EPYC since Naples (1st gen, 2017).

Evolution

SEV-SNP details

• VMPL (Virtual Machine Privilege Levels): 4 levels within the VM (0 = paravisor, 3 = guest).
• RMP (Reverse Map Table): hardware table that maps physical → guest; prevents the hypervisor remap-attack.
• Migration agent: live migration between SEV-SNP hosts.

Attestation flow

1. VM boots. The PSP (Platform Security Processor) generates a launch measurement (hash of the initial vCPU state: OVMF + kernel + cmdline + initramfs).
2. An app inside the VM requests a report:

   sudo snpguest report report.bin request-data.bin

3. The report contains:
   • Launch measurement.
   • Microcode version, TCB version.
   • HOSTDATA (64 bytes from the app).
   • Policy (SMT, debug, etc.).
   • Signature with VCEK (Versioned Chip Endorsement Key).
4. VCEK chain: AMD Root Key (ARK) → AMD SEV Key (ASK) → VCEK (per chip, per TCB version).
5. The verifier validates the chain, compares the measurement with the expected baseline.

VCEK

A key derived from fuses at manufacture + TCB version (firmware version). AMD publishes ARKASK at `kdsintf.amd.comvcekv1Milan/cert_chain`. The verifier can fetch it.

Libraries

• virtee/snpguest (Rust CLI).
• virtee/sev (Rust crate).
• confidential-containers project (CNCF).

Cloud availability

• Azure Confidential VMs (DCasv5/ECasv5) — SEV-SNP, GA 2022.
• Google Cloud Confidential VMs (C3D) — SEV-SNP in production.
• AWS — uses its own Nitro Enclaves (different architecture, below).

Vulnerabilities

• CacheWarp (CVE-2023-20592) — SEV-SNP cache invalidation bug.
• WeSee (2024) — VMPL 0 escalation.
• AMD keeps patching; firmware/microcode updates are important.

6. Intel TDX (Trust Domain Extensions)

Intel's response to SEV-SNP. Sapphire Rapids+ (4th gen Xeon Scalable, 2023).

Concepts

• TD (Trust Domain): an isolated VM with encrypted memory and integrity.
• TDX module: trusted software signed by Intel; runs in SEAM (Secure Arbitration Mode), below the hypervisor.
• MKTME (Multi-Key Total Memory Encryption): hardware encryption.
• Quote: an attestation report signed by an Intel key via an SGX-style flow.

Attestation

1. TD boots, generates the MRTD (Measurement Register for TD).
2. App requests a quote via TDREPORT.
3. The Quoting Enclave (SGX-based) signs with DCAP.
4. The verifier validates the chain via the Intel Provisioning Certification Service (PCS).

Cloud

• Microsoft Azure — TDX VMs in pilot/ga 2024.
• Google Cloud — TDX in pilot.
• Intel TDX Linux/QEMU stack mature.

vs SEV-SNP

Good redundancy: use different architectures on critical workloads.

7. ARM CCA (Confidential Compute Architecture)

ARMv9-A (Realm Management Extension, 2021). Specifies ARM Realms — isolated confidential VMs.

• Realm Management Monitor (RMM): signed, manages Realms.
• Available in hardware: AWS Graviton 3 (partial), future ones.

Slow adoption, but relevant for mobile / edge confidential computing.

8. AWS Nitro Enclaves

AWS's own architecture (not SGX/SEV). Runs on any EC2 Nitro instance.

• Isolation: hardware-backed (Nitro hypervisor).
• No persistent storage — only a vsock interface to the parent EC2.
• Attestation: goes through Nitro KMS (key bound to the attestation document).
• Limited: good for key/secret processing, not for full apps.

9. Apple Secure Enclave / Private Cloud Compute (PCC)

Secure Enclave (SE)

• Dedicated ARM core in the SoC (A7+, M1+).
• Storage for Touch ID/Face ID, App keys, SEP (Secure Enclave Processor).
• iOS Data Protection: encryption keys derived from passcode + UID burnt into the chip.

Private Cloud Compute (2024)

Apple's confidential cloud for Apple Intelligence:

• Custom Apple Silicon servers.
• Measured and attested boot chain.
• Clients (iPhone) verify the attestation before sending data.
• The server does not persist data; deletes it after processing.
• Open source: server software published for audit (partial).

10. FHE — Fully Homomorphic Encryption

Compute over encrypted data without decrypting. See 08-post-quantum.md §15. Summary here:

• Requires no special hardware.
• Slow: ~10⁴–10⁶× plaintext.
• Schemes: BFV, BGV, CKKS, TFHE, FHEW.
• Libraries: OpenFHE, Microsoft SEAL, Concrete (Zama), HElib.
• Applications: privacy-preserving ML inference, encrypted database queries, federated analytics.

Hybrid with confidential computing: TEE for speed + FHE for cases without a TEE.

11. MPC — Multi-Party Computation

Compute a function over distributed inputs without revealing them. See 08-post-quantum.md §16.

• Schemes: Yao garbled circuits, GMW, BGW, SPDZ.
• Frameworks: MP-SPDZ, EMP-toolkit, MOTION.
• Applications: threshold signing (custodial wallets), federated learning aggregation, private set intersection.

12. ZKP — Zero-Knowledge Proofs

See 08-post-quantum.md §17 and 10-cryptocurrency.md.

Variants:

• Σ-protocols: Schnorr.
• NIZK: Fiat-Shamir.
• zk-SNARKs: Groth16, PLONK, Halo, Halo2, Nova.
• zk-STARKs: transparent, FRI-based.
• Bulletproofs: log-size range proofs.

Confidential computing adjacent: prove computation correctness without re-running it.

13. Side-channels that affect confidential computing

Mitigations: microcode updates, kernel mitigations (KPTI, retpolines, IBRS, IBPB, SSBD), disable SMT on sensitive workloads, disable specific instructions (gather), software constant-time.

Cost: 5–30% performance impact on affected workloads.

14. Real use cases

Cloud workload privacy

• Microsoft Azure Confidential Computing: Office 365 isolation pilots, AI training with sensitive data.
• Google Cloud Confidential VMs: BigQuery confidential, AI Platform.
• AWS Nitro Enclaves: KMS, Stripe Issuing card processing, federated analytics.

Custodial wallets (crypto)

• Fireblocks, Anchorage, Coinbase Prime — use a mix of SGX, HSM, MPC.
• The block is produced in an enclave; the private key is never in plaintext outside.

CDN privacy

• Cloudflare Workers Confidential — partial, for specific use cases.

AI inference on private data

• Apple Private Cloud Compute — for Apple Intelligence requests that exceed the local SE.
• Microsoft Confidential Inferencing — Azure OpenAI confidential mode.

Healthcare / federated learning

• Owkin, Inpher — federated learning for medical data with TEE/FHE.

15. For EVEO (Brazilian bare metal hosting)

As discussed in the conversation: for maximum defense on rented bare-metal:

1. Ask EVEO: CPU model, dTPM or fTPM, SEV-SNP/TDX enabled, Boot Guard.
2. Defensible minimum: LUKS2 + dropbear-initramfs, IOMMU enforce, AES-NI, monitoring of the PCR baseline via TPM.
3. Good: SME (AMD) or TME (Intel) enabled in BIOS — RAM encrypted transparently. Solves cold boot and DMA snapshot.
4. State of the art: SEV-SNP/TDX. Workload in a confidential VM, attestation against s.k.lin or another node of yours before receiving the VM's LUKS key. Even the host's root cannot read the VM's memory.

Spec recommended for the Stack backlog: services/foundation/attestation — verify the AMD VCEK chain on rented VMs.

16. Cross-reference

• TPM and Secure Boot: 13-incidents.md (BootHole, Black Lotus, LogoFAIL).
• SEV-SNP attestation chain validation: 14-koder-applied.md.
• Full side-channel attacks: 11-attacks.md.
• FHEMPCZKP in PQC: 08-post-quantum.md.
• People: Shai Halevi (FHE), Craig Gentry (FHE), Andrew Yao (Garbled Circuits), GoldwasserMicaliRackoff (ZK): 12-people.md.