09 — Confidential Computing

Tecnologias para proteger *ados em uso*(inRAM), além de emtrâ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:

• *ypervisor malicioso*(cloud provider, host comprometido).
• *ysadmin curioso ou comprometido*
• *MA attacks*(PCILeech, Thunderbolt).
• *old boot*(com SME/TME).
• *emory bus snooping*(com on-die memory encryption).

Não protege contra:

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

2. TPM (Trusted Platform Module) 2.0

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

• *ardware RNG*(true RNG).
• *ryptographic primitives* RSA2048/3072, ECC P256384, AES-128256, SHA-1256384.
• *ecure storage* chaves nunca saem do chip (sealed).
• *latform Configuration Registers (PCRs)* registros que medem firmware/boot.
• *ttestation* prova ao verificador remoto que estado boot é íntegro.
• *V (Non-Volatile)* storage limitado de chaves/dados.
• *ierarchies* Endorsement (vendor key), Storage (user keys), Platform (firmware).

PCRs (Platform Configuration Registers)

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

*CG 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 *itLocker, dmcrypt + clevis, sdcryptenroll*para auto-unlock se boot íntegro.

Attestation

Cliente quer provar a server seu estado boot:

1. Server envia *once*
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 *K pubkey* verifica PCRs contra baseline.
5. Server valida *K ↔ 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: *endor Root CA → Intermediate CA → EK certificate* Verifier pode validar autenticidade do TPM.

TPM 1.2 vs 2.0

• *PM 1.2* SHA-1 only, RSA only, deprecated.
• *PM 2.0* SHA2/3, ECC, AES, multialgorithm, hierarchies. Padrão moderno.

dTPM vs fTPM

• *TPM (discrete)* chip separado (Infineon SLB 9670, Nuvoton NPCT75x). Mais difícil comprometer; EK cert chain fora controle do firmware.
• *TPM (firmware)* implementado dentro do PSP (AMD) ou MECSME (Intel). Conveniente, sem hardware extra. *ulnerabilidade* firmwarebug = TPMbug. CVE202310171018 (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

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

Componentes

• *K (Platform Key)* master, geralmente Microsoft.
• *EK (Key Exchange Keys)* assinadas pela PK.
• *b* hashes/certs de OS loaders permitidos.
• *bx* revogations.

Fluxo

1. UEFI valida bootloader (assinatura no db).
2. *icrosoft assina shim*para Linux: shim é trusted "kickthecan".
3. shim valida grub/systemd-boot via *OK (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

• *ootHole*(CVE202010713) — buffer overflow em GRUB2 config parsing; bypass Secure Boot.
• *oothole 2 / 3*— variants ao longo de 2021–2022.
• *lack Lotus*UEFI bootkit (2023) — bypassa Secure Boot via vulnerable EFI binaries.
• *ogoFAIL*(CVE2023...) — 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.

• *ntel Boot Guard* 3 modos (Verified, Measured, Verified+Measured).
• *MD 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

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

Limitações

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

Ataques

• *oreshadow / L1TF*(2018) — vaza memória de enclaves via L1 cache.
• *GAxe*(2020) — extrai chaves de attestation Intel.
• *rossTalk*(2020) — cross-core via shared resources.
• *�PIC Leak*(2022) — APIC SRAM vazamento.
• *ownfall*(2023) — Gather instruction vaza data.

Status

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

Cloud SGXbased services em desuso: Microsoft Confidential Inferencing pivot para CVMs (TDX/SEVSNP).

5. AMD SEV / SEVES / SEVSNP

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

Evolução

SEV-SNP detalhes

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

Attestation flow

1. VM boot. PSP (Platform Security Processor) gera *aunch 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.
   • *OSTDATA*(64 bytes do app).
   • Policy (SMT, debug, etc.).
   • *ssinatura com VCEK*(Versioned Chip Endorsement Key).
4. VCEK chain: *MD 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

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

Vulnerabilidades

• *acheWarp*(CVE202320592) — SEV-SNP cache invalidation bug.
• *eSee*(2024) — VMPL 0 escalation.
• AMD continua patching; firmware/microcode updates importantes.

6. Intel TDX (Trust Domain Extensions)

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

Conceitos

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

Attestation

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

Cloud

• *icrosoft Azure*— TDX VMs em pilot/ga 2024.
• *oogle Cloud*— TDX em pilot.
• *ntel 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.

• *ealm 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.

• *solation* hardware-backed (Nitro hypervisor).
• *em persistent storage*— só vsock interface to parent EC2.
• *ttestation* 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 *ão persiste*dados; deleta após processamento.
• Open source: server software publicado para audit (parcial).

10. FHE — Fully Homomorphic Encryption

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

• *ão exige hardware especial*
• *ento* ~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.

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

11. MPC — Multi-Party Computation

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

• Schemes: Yao garbled circuits, GMW, BGW, SPDZ.
• Frameworks: MPSPDZ, EMPtoolkit, 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.
• *IZK* Fiat-Shamir.
• *k-SNARKs* Groth16, PLONK, Halo, Halo2, Nova.
• *kSTARKs* transparent, FRIbased.
• *ulletproofs* log-size range proofs.

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

13. Side-channels que afetam confidential computing

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

*usto* 5–30% performance impact em workloads afetados.

14. Casos de uso reais

Cloud workload privacy

• *icrosoft Azure Confidential Computing* Office 365 isolation pilots, AI training com dados sensíveis.
• *oogle Cloud Confidential VMs* BigQuery confidential, AI Platform.
• *WS Nitro Enclaves* KMS, Stripe Issuing card processing, federated analytics.

Custodial wallets (cripto)

• *ireblocks* *nchorage* *oinbase Prime*— usam mix de SGX, HSM, MPC.
• Block produzido em enclave; private key nunca em plaintext fora.

CDN privacy

• *loudflare Workers Confidential*— partial, for specific use cases.

AI inference on private data

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

Healthcare / federated learning

• *wkin* *npher*— 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. *ergunte EVEO* CPU model, dTPM ou fTPM, SEV-SNP/TDX habilitado, Boot Guard.
2. *ínimo defensável* LUKS2 + dropbearinitramfs, IOMMU enforce, AESNI, monitoramento de PCR baseline via TPM.
3. *om* SME (AMD) ou TME (Intel) habilitado em BIOS — RAM cifrada transparentemente. Resolve cold boot e DMA snapshot.
4. *stado 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).
• SEVSNP attestation chain validation: `14koder-aplicada.md`.
• Sidechannel attacks completos: `11ataques.md`.
• FHEMPCZKP em PQC: 08-pos-quantica.md.
• Pessoas: Shai Halevi (FHE), Craig Gentry (FHE), Andrew Yao (Garbled Circuits), GoldwasserMicaliRackoff (ZK): 12-pessoas.md.