TrustMee: Self-Verifying Remote Attestation Evidence

1. Declaração do Problema

A attestation remota é crítica para estabelecer confiança em Máquinas Virtuais Confidenciais (cVMs) e Ambientes de Execução Confiáveis (TEEs). No entanto, os mecanismos de verificação atuais sofrem de limitações significativas:

• Complexidade Específica de Plataforma: Os verificadores devem implementar lógica criptográfica específica de hardware e bibliotecas de análise para cada TEE suportado (por exemplo, Intel SGX, Intel TDX, AMD SEV-SNP).
• Base de Computação Confiável (TCB) Aumentada: Os verificadores dependem de plugins nativos ou drivers escritos em linguagens inseguras quanto à memória (como C/C++ com OpenSSL) para analisar certificados e evidências. Isso introduz bugs e vulnerabilidades (por exemplo, execução remota de código) no próprio verificador.
• Manutenção e Escalabilidade: Adicionar suporte a um novo TEE exige atualizar a base de código do verificador, recompilar e reimplantar. Isso cria um problema de "ovo e galinha" onde os verificadores são incentivados a suportar menos plataformas para minimizar riscos de segurança e custos de manutenção.
• Fragilidade: Um bug em um plugin de verificador para um TEE pode comprometer todo o serviço de verificação, permitindo potencialmente que um atacante se passe por outras plataformas.

2. Metodologia: Arquitetura TrustMee

Os autores propõem o TrustMee, um verificador de attestation agnóstico à plataforma que transfere o ônus da lógica de verificação específica da plataforma do verificador para o atestador.

Conceito Central: Evidência Auto-Verificável

Em vez de codificar a lógica de verificação, o TEE atestador agrupa sua lógica de verificação específica como um componente WebAssembly (Wasm) junto com a evidência de attestation.

• O Atestador: Gera a evidência de attestation padrão e um componente Wasm correspondente que implementa a lógica para analisar e validar esse formato específico de evidência.
• O Verificador (TrustMee):
  1. Recebe a evidência e o componente Wasm.
  2. Mede o componente Wasm (verificando seu hash/assinatura contra um repositório de confiança).
  3. Executa o componente dentro de um runtime WebAssembly em ambiente isolado (Wasmtime).
  4. O componente analisa a evidência, verifica endossamentos e produz um conjunto padronizado de afirmações (claims).
  5. O host do TrustMee (código agnóstico à plataforma) aplica a política de avaliação a essas afirmações e assina o resultado no formato padrão Entity Attestation Token (EAT).

Componentes Técnicos Chave

• Modelo de Componentes WebAssembly: Utiliza o Tipo de Interface Wasm (WIT) para definir uma interface estrita e agnóstica à linguagem entre o host e o componente. Isso garante que, independentemente do TEE, o verificador interaja com o componente através de uma API uniforme (função evaluate).
• Isolamento (Sandboxing): O componente Wasm é executado em um ambiente isolado com acesso restrito (por exemplo, ciclos de CPU limitados via "medição de combustível", acesso controlado à rede e sistema de arquivos isolado). Isso impede que um componente malicioso ou com bugs cause travamento no verificador ou acesse dados sensíveis do host.
• Modelo de Confiança:
  • O verificador confia no runtime Wasm e no motor de políticas.
  • A lógica específica da plataforma é não confiável, mas isolada.
  • O verificador verifica o signatário do componente Wasm (geralmente o fornecedor do TEE) e o hash do componente contra valores de referência.
  • Se um componente não estiver assinado ou for de um signatário desconhecido, ele é executado sob políticas padrão estritas (sem rede, CPU limitada).

3. Principais Contribuições

1. Arquitetura TrustMee: Um design inovador para attestation remota auto-verificável onde o atestador fornece o código de verificação. Isso elimina a necessidade de os verificadores manterem drivers específicos de plataforma.
2. Implementação: Um protótipo funcional integrado ao framework Trustee (parte do projeto Confidential Containers). Inclui componentes de verificação Wasm para AMD SEV-SNP, Intel TDX e Intel SGX.
3. Padronização: O sistema produz resultados no formato padrão EAT Attestation Result (EAR), garantindo compatibilidade com partes confiáveis existentes.
4. Análise de Segurança: Demonstra que isolar a lógica de análise específica da plataforma no Wasm reduz significativamente a TCB do verificador e mitiga riscos associados a bibliotecas inseguras quanto à memória.
5. Avaliação de Desempenho: Quantifica a sobrecarga da abordagem Wasm em comparação com drivers nativos.

4. Resultados e Avaliação

Os autores avaliaram o TrustMee contra os drivers nativos do Trustee para AMD SNP, Intel TDX e Intel SGX.

• Compatibilidade: Verificou com sucesso evidências de três arquiteturas de TEE distintas usando um único host de verificador não modificado. Adicionar um novo TEE agora exige apenas distribuir um novo componente Wasm, sem atualizar o verificador.
• Segurança:
  • O sandbox Wasm isola com sucesso as operações de análise e criptografia.
  • Componentes maliciosos não podem comprometer o verificador ou se passar por outras plataformas sem serem detectados pelo motor de políticas (via verificações de signatário/hash).
  • Ataques de Negação de Serviço (DoS) são mitigados por meio de medição de combustível e restrições de rede.
• Desempenho (Latência):
  • Início Frio: A verificação inicial (incluindo download e compilação do componente) apresenta maior latência devido à sobrecarga de rede e compilação.
  • Início Quente: Uma vez que o componente é armazenado em cache, a sobrecarga é gerenciável.
    • AMD SNP: A verificação nativa Wasm foi ~3,67x mais lenta que os drivers nativos C/Rust, principalmente devido à falta de criptografia acelerada por hardware nos runtimes Wasm atuais. No entanto, o uso de criptografia baseada no host (chamando funções criptográficas nativas a partir do Wasm) reduziu essa sobrecarga para ~1,47x.
    • Intel TDX/SGX: O verificador baseado em Wasm usando uma biblioteca puramente Rust (dcap-qvl) foi na verdade mais rápido que o driver nativo Trustee usando a biblioteca proprietária DCAP da Intel. Quando comparado a um driver nativo também usando dcap-qvl, a sobrecarga do Wasm foi de ~3,17x, mas a latência absoluta permaneceu baixa (abaixo de 50ms na maioria dos casos).
  • Tamanho da Solicitação: As solicitações do TrustMee são frequentemente menores (redução de até 37%) que as solicitações nativas porque usam codificação CBOR em vez de JSON codificado em base64, compensando o tamanho do identificador do componente.

5. Significado e Impacto Futuro

• Desacoplamento da Verificação do Hardware: O TrustMee rompe o acoplamento estreito entre o verificador e o fornecedor do TEE. Isso permite que provedores de nuvem e verificadores suportem novos TEEs instantaneamente, sem alterações de código.
• Redução da Superfície de Ataque: Ao mover a lógica de análise e criptografia propensa a erros para um ambiente isolado, a TCB do verificador é reduzida à lógica central e ao runtime Wasm, diminuindo significativamente o risco de vulnerabilidades de execução remota de código.
• Escalabilidade: O modelo transfere o ônus da manutenção para os fornecedores de TEE (que já mantêm bibliotecas de verificação) em vez dos operadores do verificador.
• Extensibilidade: A arquitetura suporta attestation composta (verificando camadas de aplicação sobre camadas de hardware) e pode ser adaptada a outros frameworks como o Veraison.

Conclusão: O TrustMee demonstra que a attestation remota pode ser tornada agnóstica à plataforma sem sacrificar segurança ou desempenho. Ao aproveitar o WebAssembly para agrupar a lógica de verificação com a evidência, ele resolve os gargalos de integração e manutenção dos ecossistemas heterogêneos de TEE atuais.