Proof of Cloud: Data Center Execution Assurance for Confidential VMs

Este artigo apresenta o Data Center Execution Assurance (DCEA), um mecanismo que gera uma "Prova de Nuvem" criptográfica ao vincular a atestação de Máquinas Virtuais Confidenciais (CVMs) a evidências de nível de plataforma, garantindo assim que a execução ocorre fisicamente dentro de um data center confiável e prevenindo ataques de proxy e relé.

O essencial

Imagine que você tem um cofre digital super seguro, um "Cofre Confidencial" (que os técnicos chamam de CVM ou Máquina Virtual Confidencial), onde você guarda seus segredos mais valiosos: dados de saúde, algoritmos de IA, ou dinheiro de criptomoedas.

Atualmente, quando você contrata um serviço na nuvem para usar esse cofre, o provedor diz: "Não se preocupe, seu cofre está seguro. Nós garantimos que o software dentro dele não foi adulterado". Eles mostram um certificado digital que diz: "Sim, o software é o original e não foi modificado".

O Problema: O "Onde" é o segredo

Aqui está o problema que o artigo Proof of Cloud (Prova da Nuvem) aponta: esse certificado diz o que está rodando, mas não diz onde está rodando.

Pense assim:
Imagine que você aluga um carro blindado para transportar ouro. O motorista te entrega um certificado dizendo: "Este é um carro blindado original, o motor é o certo e o vidro é à prova de balas".
Mas e se o motorista, em vez de usar o carro blindado na sua cidade, tiver roubado o carro, levado para um galpão abandonado no meio do mato (onde ele tem controle total) e estiver usando um vidro de plástico comum que parece vidro à prova de balas? O certificado do motor ainda estaria "válido", mas o seu ouro estaria vulnerável.

Na computação em nuvem, um provedor mal-intencionado (ou um hacker que controla o servidor) pode pegar uma máquina virtual legítima e rodá-la em um hardware que ele controla totalmente, fora do data center seguro. Como o certificado só verifica o software, você não consegue saber que o "carro blindado" foi trocado por um "caminhonete de papelão".

A Solução: O "Passaporte do Data Center"

Os autores do artigo criaram uma solução chamada DCEA (Garantia de Execução no Data Center). A ideia é criar uma "Prova de Nuvem".

Eles fazem isso conectando duas "certidões de nascimento" diferentes que precisam bater:

1. A Identidade do Software (O Cofre): O certificado que diz que o software dentro da máquina é legítimo (feito pelo fabricante do chip, como a Intel).
2. A Identidade do Chassis (O Prédio): Um "passaporte" do próprio servidor físico, gerado por um chip de segurança chamado TPM (Módulo de Plataforma Confiável) que está fixado na placa-mãe do servidor no data center.

A Analogia do Casamento

Imagine que você quer ter certeza de que dois noivos (o Software e o Servidor Físico) estão realmente casados e vivendo juntos na mesma casa.

• Sem a solução: Você pede ao noivo (Software) um certificado de casamento. Ele mostra um papel dizendo "Eu sou casado". Mas você não sabe se ele está casado com a pessoa certa ou se está fingindo.
• Com a solução DCEA: O sistema exige que o Software mostre o certificado de casamento E que o Servidor Físico mostre o registro de moradia. O sistema então verifica se os nomes nos dois documentos são idênticos e se a assinatura do "cartório" (o provedor de nuvem confiável) está nos dois.

Se o provedor tentar enganar você, pegando o software de um servidor seguro e rodando em um servidor inseguro, a "assinatura" do servidor físico não vai bater com a do software. O sistema grita: "Ei! O software diz que está no Data Center X, mas o servidor físico diz que está no Data Center Y (ou em um galpão ilegal)! Isso é uma fraude!"

Como eles provam que funciona?

Os autores não apenas inventaram a ideia; eles a construíram e testaram:

1. Matemática Pura: Eles usaram lógica matemática avançada para provar que, mesmo que o "mau" (o hacker que controla o sistema operacional do servidor) tente enganar o sistema, ele não consegue. É como provar que, não importa quantas vezes você tente misturar cartas de baralho, não consegue criar uma mão vencedora se as regras forem seguidas.
2. Teste Real: Eles implementaram isso em servidores reais da Google Cloud. O resultado? Funciona! E o custo (a lentidão que isso poderia causar) é tão pequeno que é imperceptível para o usuário comum.

Por que isso é importante para você?

• Para Bancos e Hospitais: Garante que seus dados sensíveis estão sendo processados em um local físico seguro, e não em um servidor alugado por um criminoso.
• Para Criptomoedas (DeFi): Em um mundo onde ninguém confia em ninguém, você precisa de uma prova matemática de que o código que gerencia seu dinheiro está rodando em um hardware honesto, e não em um servidor controlado por um golpista.
• Para a Privacidade: Permite que você verifique a origem da execução sem precisar confiar cegamente no provedor de nuvem.

Resumo Final

O artigo Proof of Cloud resolve um buraco na segurança digital: ele garante que o "onde" é tão importante quanto o "o que". Eles criaram um sistema que une a identidade do software à identidade física do servidor, impedindo que hackers troquem servidores seguros por inseguros sem que você perceba. É como ter um sistema de segurança que não apenas verifica se a porta está trancada, mas também garante que a casa onde a porta está localizada é, de fato, a sua casa e não uma casa falsa construída por um ladrão.

Resumo técnico

Título: Proof of Cloud: Garantia de Execução em Data Center para VMs Confidenciais

Autores: Filip Rezabek, Moe Mahhouk, Andrew Miller, Quintus Kilbourn, Georg Carle, Jonathan Passerat-Palmbach.
Afilições: Flashbots, Technical University of Munich, Imperial College London.

---

1. O Problema: A Lacuna de Proveniência do Ambiente

As Máquinas Virtuais Confidenciais (CVMs) utilizam Ambientes de Execução Confiáveis (TEEs), como Intel TDX e AMD SEV-SNP, para proteger dados em uso contra um sistema operacional host malicioso. No entanto, os mecanismos de atestação (attestation) atuais possuem uma falha crítica:

• O que é provado: Os atestados atuais certificam o que está rodando (o código, o microcódigo, o estado de lançamento medido).
• O que não é provado: Eles não certificam onde está rodando.

A Lacuna de Confiança:
Um operador de nuvem malicioso pode executar uma carga de trabalho em um hardware não autorizado ou em um local físico inseguro (fora do data center confiável), mas ainda assim gerar um atestado válido. Como os TEEs comerciais assumem que o ataque físico ativo (como interposição de barramento ou side-channels físicos) é impossível, eles não fornecem evidência criptográfica de que o processador reside em um data center confiável.

Isso permite ataques de proxy (relay): um atacante pode pegar um atestado válido de uma máquina em um data center seguro e "retransmiti-lo" ou combiná-lo com uma execução real em uma máquina insegura, enganando o verificador sobre a localização física da execução.

---

2. Metodologia: Data Center Execution Assurance (DCEA)

Os autores propõem o DCEA, um protocolo que gera uma "Prova de Nuvem" (Proof of Cloud) ao vincular criptograficamente a atestação da CVM à evidência de um módulo de plataforma confiável (TPM) no nível da infraestrutura.

Princípios Fundamentais:

O DCEA combina duas raízes de confiança independentes:

1. Fabricante do TEE: (Ex: Intel/AMD) que garante a integridade do hardware e do software do enclave.
2. Provedor de Infraestrutura: (Ex: Google Cloud, AWS) que garante a integridade física do chassis e do data center através do TPM.

Mecanismo de Ligação (Binding):

O protocolo cria um elo inquebrável entre o estado de execução da CVM e o estado de inicialização medido do host:

1. Medições Cruzadas: O DCEA cruza as medições de tempo de execução do TEE (como os registros RTMR no Intel TDX) com as medições de inicialização do vTPM (Trusted Platform Module virtual) ou dTPM (discreto).
2. Vinculação de Chaves: A chave de atestação (AK) do vTPM é "selada" (sealed) ao estado medido do host (via Intel TXT ou DRTM). Isso significa que a chave só pode ser usada se o software do host (BIOS, Hypervisor, OS) corresponder exatamente ao estado medido esperado.
3. Verificação In-Guest: A CVM verifica internamente se o atestado do vTPM corresponde ao seu próprio estado de execução. Se um atacante tentar relatar um atestado de uma máquina diferente (proxy), as medições (PCR/RTMR) não corresponderão, e a verificação falhará.

Cenários de Implementação:

• Cenário I (VM Gerenciada): O provedor gerencia o Hypervisor e o vTPM. A confiança é baseada na integridade operacional do provedor e na consistência das medições.
• Cenário II (Bare-Metal): O cliente tem controle sobre o Hypervisor e o OS, mas o hardware físico (chassis) está no data center do provedor. O DCEA utiliza um TPM discreto (dTPM) e Intel TXT para garantir que, mesmo com um stack de software host não confiável, a execução ocorre no chassis físico esperado.

---

3. Principais Contribuições (Key Contributions)

1. Formalização da Proveniência do Ambiente: O artigo define formalmente a "proveniência do ambiente" como um objetivo de segurança de primeira classe, identificando o ponto cego atual nos modelos de ameaça dos TEEs em relação à residência física da plataforma.
2. Design e Implementação do Protocolo DCEA: Desenvolvimento de um mecanismo de ligação in-guest que vincula relatórios de TEE a citações (quotes) de TPM de nível de plataforma, ancorando a carga de trabalho a um chassis físico específico.
3. Prova Formal de Segurança: Utilizando o modelo AGATE e o framework de Composição Universal (Universal Composability - UC), os autores provam que o DCEA emula um TEE ideal consciente da localização, mesmo na presença de um stack de software host malicioso. A prova demonstra resistência contra ataques de relay avançados, incluindo um novo ataque de "mix-and-match" (mistura e combinação).
4. Avaliação Prática: Implementação do DCEA em instâncias bare-metal Intel TDX no Google Cloud, utilizando Intel TXT. Os resultados mostram que o protocolo mitiga uma ampla gama de ataques (A1-A6) com uma sobrecarga de desempenho mínima, tornando-o viável para produção.

---

4. Resultados e Análise de Segurança

• Mitigação de Ataques de Proxy: O DCEA impede efetivamente que um atacante execute uma carga de trabalho em um local não confiável e apresente um atestado de um local confiável. A inconsistência entre as medições do TEE (RTMR) e do TPM (PCR) torna o ataque detectável.
• Resistência a Forgery (Falsificação): Como a chave de atestação do vTPM é selada ao estado medido do host, um atacante não pode simplesmente forjar um atestado sem possuir o hardware físico correto e o estado de software exato.
• Desempenho: A implementação prática demonstrou sobrecargas baixas, indicando que o DCEA é prático para cargas de trabalho sensíveis à privacidade, como DeFi (Finanças Descentralizadas) e processamento de genomas.
• Cenários de Ameaça: O modelo de ameaça assume que o provedor de nuvem pode ser um adversário de software (controlando o Hypervisor), mas não pode realizar ataques físicos ativos (como extração de chips) sem destruir sua reputação e receita futura. O DCEA transforma essa confiança econômica em uma garantia criptográfica verificável.

---

5. Significado e Impacto

O trabalho é significativo porque redefine o modelo de confiança para computação confidencial na nuvem:

• Mudança de Paradigma: Move a confiança de "confiar que o provedor não vai atacar fisicamente" para "verificar criptograficamente que a execução está no data center esperado".
• Aplicações Críticas: É essencial para cenários onde as partes não confiam umas nas outras, como DeFi, onde ativos de alto valor são protegidos por TEEs, mas os participantes precisam garantir que a execução não está sendo reléada para um servidor inseguro.
• Generalização: Embora o protótipo use Intel TDX, o conceito é aplicável a outras arquiteturas (como AMD SEV-SNP e ARM CCA) que possuem primitivas de atestação comparáveis.
• Privacidade: O artigo discute como manter a privacidade (não revelar a localização exata ou detalhes do provedor) usando Provas de Conhecimento Zero (ZKPs) para provar que a infraestrutura pertence a um conjunto aprovado de provedores, sem vazar metadados específicos.

Em resumo, o DCEA preenche a lacuna crítica entre a identidade do código e a localização física, permitindo que clientes externos verifiquem não apenas o que está sendo processado, mas onde isso está acontecendo, garantindo que dados sensíveis nunca saiam do ambiente físico de confiança esperado.