09 — Confidential Computing

Tecnologias para proteger dados em uso (in-RAM), além de em-trânsito (TLS) e em-repouso (LUKS). Trust anchor sai do operador do hardware e vai para o silicon do CPU vendor.

1. Modelo de ameaça

Confidential Computing protege contra:

• Hypervisor malicioso (cloud provider, host comprometido).
• Sysadmin curioso ou comprometido.
• DMA attacks (PCILeech, Thunderbolt).
• Cold boot (com SME/TME).
• Memory bus snooping (com on-die memory encryption).

Não protege contra:

• Bugs no enclave / VM dela mesma (pode vazar voluntariamente).
• CPU vendor compromise (AMD/Intel raiz de confiança).
• Side-channel from same CPU (Spectre, Foreshadow, ÆPIC, Downfall).

2. TPM (Trusted Platform Module) 2.0

TCG (Trusted Computing Group) standard. ISO/IEC 11889. Chip dedicado ou firmware (fTPM) que provê:

• Hardware RNG (true RNG).
• Cryptographic primitives: RSA-20483072, ECC P-256384, AES-128256, SHA-1256/384.
• Secure storage: chaves nunca saem do chip (sealed).
• Platform Configuration Registers (PCRs): registros que medem firmware/boot.
• Attestation: prova ao verificador remoto que estado boot é íntegro.
• NV (Non-Volatile): storage limitado de chaves/dados.
• Hierarchies: Endorsement (vendor key), Storage (user keys), Platform (firmware).

PCRs (Platform Configuration Registers)

24 registers (PCR 0–23). Cada PCR só pode ser estendido, não escrito: $\(\text{PCR}_i \leftarrow H(\text{PCR}_i \\\| \text{measurement})\)$

TCG PC Client mapping (clássico):

Sealing

Encrypt secret to specific PCR values. Decrypt só funciona se PCR matches:

sealed_blob = TPM_Seal(secret, policy={PCR0=h0, PCR7=h7})
TPM_Unseal(sealed_blob) → secret  // só se current PCR0=h0 AND PCR7=h7

Usado em BitLocker, dm-crypt + clevis, sd-cryptenroll para auto-unlock se boot íntegro.

Attestation

Cliente quer provar a server seu estado boot:

1. Server envia nonce.
2. Cliente: tpm2_quote -c ak -l sha256:0,1,2,3,4,5,7 -q nonce.
3. TPM assina (Quote = PCRs + nonce + attestation key).
4. Server valida sig com AK pubkey, verifica PCRs contra baseline.
5. Server valida AK ↔ EK chain: AK foi criada num TPM com EK certificado pelo vendor.

EK (Endorsement Key) certificate

Vendors (Infineon, Nuvoton/NPCT, ST) emitem certificate por TPM em manufactura. Cadeia: Vendor Root CA → Intermediate CA → EK certificate. Verifier pode validar autenticidade do 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. Padrão moderno.

dTPM vs fTPM

• dTPM (discrete): chip separado (Infineon SLB 9670, Nuvoton NPCT75x). Mais difícil comprometer; EK cert chain fora controle do firmware.
• fTPM (firmware): implementado dentro do PSP (AMD) ou MECSME (Intel). Conveniente, sem hardware extra. Vulnerabilidade: firmware-bug = TPM-bug. CVE-2023-10171018 (TPM 2.0 spec bug). 2023 AMD fTPM bug causava stutter no Windows.

TPM e LUKS2

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

PCR 0 = firmware, PCR 7 = secure boot policy. Boot íntegro → unlock automático. Firmware adulterado → tpm refuses unseal.

3. Secure Boot

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

Componentes

• PK (Platform Key): master, geralmente Microsoft.
• KEK (Key Exchange Keys): assinadas pela PK.
• db: hashes/certs de OS loaders permitidos.
• dbx: revogations.

Fluxo

1. UEFI valida bootloader (assinatura no db).
2. Microsoft assina shim para Linux: shim é trusted "kick-the-can".
3. shim valida grub/systemd-boot via MOK (Machine Owner Key) que owner adicionou.
4. grub valida kernel + initramfs (signed kernel image; cmdline assinado).
5. kernel mede para PCRs (IMA).

Resultado: chain of trust from firmware to userspace.

Ataques

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

Boot Guard / PSB (Platform Secure Boot)

Mecanismo OEM: fuses no CPU contêm hash de chave do OEM (Dell, HPE, Supermicro). UEFI valida BIOS code antes de executar.

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

Modo "enforce" → bloqueia BIOS modificado. Modo "audit" → loga e segue (compromised).

4. Intel SGX (Software Guard Extensions)

Introduzido em Skylake (2015). Enclaves dentro do mesmo OS que aplicativos não-trustados.

Conceito

• Enclave: região protegida da memória, criptografada por MEE (Memory Encryption Engine).
• Executa código assinado.
• OS/hypervisor não pode ler memória da enclave.
• Atestação remota via Intel Attestation Service (IAS) ou DCAP.

Limitações

• EPC (Enclave Page Cache): 128 MB total no chip; mais que isso = paging caro.
• Sem syscalls: enclave faz OCALL para fora.
• Side-channel attacks: SGX vazou em toda classe de ataque encontrada em 2018–2022.

Ataques

• Foreshadow / L1TF (2018) — vaza memória de enclaves via L1 cache.
• SGAxe (2020) — extrai chaves de attestation Intel.
• CrossTalk (2020) — cross-core via shared resources.
• ÆPIC Leak (2022) — APIC SRAM vazamento.
• Downfall (2023) — Gather instruction vaza data.

Status

Intel descontinuou SGX em consumer chips (12th gen Alder Lake+, 2021). Mantém em Xeon (server) mas comunidade abandonou amplamente para favor de TDX.

Cloud SGX-based services em desuso: Microsoft Confidential Inferencing pivot para CVMs (TDX/SEV-SNP).

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

SEV = Secure Encrypted Virtualization. Memória da VM cifrada com chave que o hypervisor não conhece. Disponível em EPYC desde Naples (1st gen, 2017).

Evolução

SEV-SNP detalhes

• VMPL (Virtual Machine Privilege Levels): 4 níveis dentro VM (0 = paravisor, 3 = guest).
• RMP (Reverse Map Table): hardware table que mapeia physical → guest; impede hypervisor remap-attack.
• Migration agent: live migration entre hosts SEV-SNP.

Attestation flow

1. VM boot. PSP (Platform Security Processor) gera launch measurement (hash do vCPU state inicial: OVMF + kernel + cmdline + initramfs).
2. App dentro VM solicita report:

   sudo snpguest report report.bin request-data.bin

3. Report contém:
   • Launch measurement.
   • Microcode version, TCB version.
   • HOSTDATA (64 bytes do app).
   • Policy (SMT, debug, etc.).
   • Assinatura com VCEK (Versioned Chip Endorsement Key).
4. VCEK chain: AMD Root Key (ARK) → AMD SEV Key (ASK) → VCEK (per chip, per TCB version).
5. Verifier valida cadeia, compara measurement com baseline esperado.

VCEK

Chave derivada de fuses na manufactura + TCB version (firmware version). AMD publica ARKASK em `kdsintf.amd.comvcekv1Milan/cert_chain`. Verifier pode buscar.

Bibliotecas

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

Cloud disponibilidade

• Azure Confidential VMs (DCasv5/ECasv5) — SEV-SNP, GA 2022.
• Google Cloud Confidential VMs (C3D) — SEV-SNP em produção.
• AWS — usa próprio Nitro Enclaves (architectura diferente, abaixo).

Vulnerabilidades

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

6. Intel TDX (Trust Domain Extensions)

Resposta Intel ao SEV-SNP. Sapphire Rapids+ (4th gen Xeon Scalable, 2023).

Conceitos

• TD (Trust Domain): VM isolada com memória cifrada e integridade.
• TDX module: software trusted assinado pela Intel; roda em SEAM (Secure Arbitration Mode), abaixo do hypervisor.
• MKTME (Multi-Key Total Memory Encryption): hardware encryption.
• Quote: attestation report assinado por chave da Intel via SGX-style flow.

Attestation

1. TD boot, gera MRTD (Measurement Register for TD).
2. App pede quote via TDREPORT.
3. Quoting Enclave (SGX-based) assina com DCAP.
4. Verifier valida chain via Intel Provisioning Certification Service (PCS).

Cloud

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

vs SEV-SNP

Boa redundância: usar arquiteturas diferentes em cargas críticas.

7. ARM CCA (Confidential Compute Architecture)

ARMv9-A (Realm Management Extension, 2021). Específica ARM Realms — VMs confidenciais isoladas.

• Realm Management Monitor (RMM): assinada, gerencia Realms.
• Disponível em hardware: AWS Graviton 3 (parcial), futures.

Adoção lenta, mas relevante pra mobile / edge confidential computing.

8. AWS Nitro Enclaves

Architecture própria AWS (não SGX/SEV). Roda em qualquer EC2 Nitro instance.

• Isolation: hardware-backed (Nitro hypervisor).
• Sem persistent storage — só vsock interface to parent EC2.
• Attestation: vai pelo Nitro KMS (key bound to attestation document).
• Limitada: bom pra processamento de chave/segredo, não pra apps cheias.

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

Secure Enclave (SE)

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

Private Cloud Compute (2024)

Apple's confidential cloud for Apple Intelligence:

• Custom Apple Silicon servers.
• Boot chain mensurada e atestada.
• Clientes (iPhone) verificam attestation antes de enviar dados.
• Server não persiste dados; deleta após processamento.
• Open source: server software publicado para audit (parcial).

10. FHE — Fully Homomorphic Encryption

Compute sobre dados cifrados sem decifrar. Ver 08-pos-quantica.md §15. Resumo aqui:

• Não exige hardware especial.
• Lento: ~10⁴–10⁶× plaintext.
• Schemes: BFV, BGV, CKKS, TFHE, FHEW.
• Bibliotecas: OpenFHE, Microsoft SEAL, Concrete (Zama), HElib.
• Aplicações: privacy-preserving ML inference, encrypted database queries, federated analytics.

Híbrido com confidential computing: TEE para velocidade + FHE para casos sem TEE.

11. MPC — Multi-Party Computation

Compute função sobre inputs distribuídos sem revelar. Ver 08-pos-quantica.md §16.

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

12. ZKP — Zero-Knowledge Proofs

Ver 08-pos-quantica.md §17 e 10-criptomoeda.md.

Variantes:

• Σ-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.

13. Side-channels que afetam confidential computing

Mitigações: microcode updates, kernel mitigations (KPTI, retpolines, IBRS, IBPB, SSBD), disable SMT em workloads sensíveis, disable specific instructions (gather), software constant-time.

Custo: 5–30% performance impact em workloads afetados.

14. Casos de uso reais

Cloud workload privacy

• Microsoft Azure Confidential Computing: Office 365 isolation pilots, AI training com dados sensíveis.
• Google Cloud Confidential VMs: BigQuery confidential, AI Platform.
• AWS Nitro Enclaves: KMS, Stripe Issuing card processing, federated analytics.

Custodial wallets (cripto)

• Fireblocks, Anchorage, Coinbase Prime — usam mix de SGX, HSM, MPC.
• Block produzido em enclave; private key nunca em plaintext fora.

CDN privacy

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

AI inference on private data

• Apple Private Cloud Compute — para Apple Intelligence requests que excedem SE local.
• Microsoft Confidential Inferencing — Azure OpenAI confidential mode.

Healthcare / federated learning

• Owkin, Inpher — federated learning para dados médicos com TEE/FHE.

15. Para EVEO (bare metal hosting brasileiro)

Como discutido na conversa: pra defesa máxima em bare-metal alugado:

1. Pergunte EVEO: CPU model, dTPM ou fTPM, SEV-SNP/TDX habilitado, Boot Guard.
2. Mínimo defensável: LUKS2 + dropbear-initramfs, IOMMU enforce, AES-NI, monitoramento de PCR baseline via TPM.
3. Bom: SME (AMD) ou TME (Intel) habilitado em BIOS — RAM cifrada transparentemente. Resolve cold boot e DMA snapshot.
4. Estado da arte: SEV-SNP/TDX. Workload em VM confidencial, attestation contra s.k.lin ou outro nó seu antes de receber chave LUKS da VM. Mesmo o root do host não consegue ler memória da VM.

Spec recomendada para backlog Stack: services/foundation/attestation — verificar VCEK chain AMD em VMs alugadas.

16. Referência cruzada

• TPM e Secure Boot: 13-incidentes.md (BootHole, Black Lotus, LogoFAIL).
• SEV-SNP attestation chain validation: 14-koder-aplicada.md.
• Side-channel attacks completos: 11-ataques.md.
• FHEMPCZKP em PQC: 08-pos-quantica.md.
• Pessoas: Shai Halevi (FHE), Craig Gentry (FHE), Andrew Yao (Garbled Circuits), GoldwasserMicaliRackoff (ZK): 12-pessoas.md.