Designing Trustworthy Layered Attestations

Este artigo propõe e avalia um sistema de atestações confiáveis em camadas, baseado em princípios de isolamento e hardware amplamente disponível (como TPM e SEV-SNP), que permite verificar a integridade de sistemas complexos contra adversários definidos com uma sobrecarga de desempenho insignificante de cerca de 1,3%.

O essencial

Imagine que você precisa enviar um pacote valioso para um amigo em outro país. Você não conhece o amigo pessoalmente, então precisa ter certeza de que ele é confiável antes de enviar o pacote. Se você enviar para alguém desonesto, seu pacote pode ser roubado ou aberto.

Neste mundo digital, a "Atestação" (Attestation) é como um selo de garantia ou um relatório de saúde que um computador envia para provar: "Ei, eu sou honesto, meu sistema está limpo e pronto para receber seus dados sensíveis."

O problema é que hackers são espertos. Eles podem fingir que o sistema está limpo, escondendo vírus (como um rootkit) que enganam os verificadores. É como se um ladrão vestisse um uniforme de policial para entrar na sua casa.

Este artigo apresenta uma solução chamada "Atestação em Camadas". Em vez de confiar em apenas uma prova, eles criam várias camadas de verificação, como uma cebola ou um castelo medieval com várias muralhas.

Aqui está a explicação simples, usando analogias:

1. O Problema: O "Falso Amigo"

Imagine que você pede para um funcionário de um banco (o sistema) guardar seu dinheiro. Se esse funcionário for um impostor, ele pode fingir que está trabalhando, mas na verdade está roubando.

• A solução antiga: O banco olhava apenas para o rosto do funcionário (o software básico). Se o rosto parecia normal, deixavam entrar.
• O problema: Um impostor pode usar uma máscara perfeita.

2. A Solução: O "Castelo de Camadas"

Os autores propõem construir um sistema onde a confiança é construída de baixo para cima, como um castelo:

• A Fundação (Hardware): Tudo começa com uma peça de hardware inquebrável, chamada TPM (Módulo de Plataforma Confiável). Pense nele como a pedra fundamental do castelo que ninguém pode trocar sem que a gente saiba. Ela guarda as chaves secretas.
• As Muralhas (Sistema Operacional): Sobre a pedra, construímos o sistema operacional (como o Linux). Mas não é qualquer Linux; é um com "regras rígidas" (SELinux). Imagine que o sistema tem guardas de segurança que não deixam ninguém tocar em certas portas ou arquivos, a menos que tenha o crachá certo.
• Os Verificadores (Camadas Superiores): Por fim, temos os programas que fazem o trabalho (como o aplicativo que processa seus e-mails). Eles são verificados por quem está abaixo deles.

3. As 5 Regras de Ouro (Os "Maxims")

Os autores criaram 5 regras simples para garantir que esse castelo seja seguro:

1. Concentre-se no Essencial: Não tente verificar tudo o que o computador faz. Verifique apenas as partes críticas (como a porta da frente e o cofre). Se o resto do computador for bagunçado, mas o cofre estiver seguro, tudo bem.

   • Analogia: Você não precisa verificar se o jardineiro está cantando bem para confiar que o cofre está trancado.

2. Trabalhadores de Turno Curto: Para tarefas que lidam com dados perigosos, use programas que "nascem, fazem o trabalho e morrem" rapidamente.

   • Analogia: Em vez de ter um guarda que trabalha 24 horas (e pode ser corrompido com o tempo), você contrata um guarda para abrir a porta, deixar o pacote entrar e ir embora. Se o pacote estiver envenenado, ele só mata aquele guarda, não o próximo.

3. Não Guarde Segredos na Memória: Não deixe as chaves do cofre (chaves de assinatura) guardadas na memória do computador, pois um hacker pode roubá-las rapidamente.

   • Analogia: Não deixe a chave do cofre em cima da mesa. Mantenha-a dentro de um cofre de aço (o TPM) que só abre se as condições estiverem certas.

4. Prove a Origem: A prova de que o sistema está limpo deve vir de um lugar que o hacker não consegue falsificar.

   • Analogia: O relatório de saúde deve ser assinado por um médico que o hacker não consegue corromper. Se o relatório vier de um "médico" que o hacker controla, não vale nada.

5. Ordem de Verificação: Verifique a fundação antes de verificar o telhado.

   • Analogia: Se o alicerce do prédio está podre, não adianta verificar se a pintura do telhado está bonita. Você precisa garantir que o hardware e o sistema básico estão limpos antes de confiar nos programas que rodam neles.

4. O Resultado: Rápido e Seguro

Os autores testaram isso em um sistema real (um "filtro" que deixa passar mensagens seguras entre redes).

• Desempenho: O sistema ficou apenas 1,3% mais lento. É como se você colocasse um cinto de segurança no carro e ele gastasse apenas um pouquinho mais de gasolina.
• Segurança: Eles simularam ataques de hackers muito inteligentes. O sistema conseguiu detectar quase tudo, exceto se o hacker fosse capaz de mudar o hardware físico antes do computador ser ligado (o que é muito difícil).

5. O Futuro: Computadores "Confidenciais"

No final, eles mostram que essas mesmas regras funcionam até mesmo com tecnologias mais novas, como computadores que criptografam a memória (Confidential Computing). É como se eles dissessem: "Não importa qual tecnologia nova você use, se você seguir essas 5 regras de ouro, seu sistema será confiável."

Resumo Final:
Este artigo ensina como construir sistemas digitais que não apenas tentam impedir ataques, mas que provam que estão limpos, mesmo na presença de hackers inteligentes. Eles fazem isso criando uma cadeia de confiança, onde cada camada verifica a anterior, garantindo que o "selo de garantia" que chega até você seja verdadeiro.

Resumo técnico

Resumo Técnico: Designing Trustworthy Layered Attestations

1. O Problema

A attestação (prova de integridade) é o processo de fornecer evidências de que um sistema remoto é confiável para interações sensíveis. Embora amplamente utilizada em controle de acesso e ambientes de execução confiável (TEE), as abordagens atuais frequentemente falham devido a três limitações principais:

• Attestações Superficiais: Muitas soluções medem apenas componentes de nível de usuário, ignorando ameaças avançadas como rootkits que comprometem o kernel ou mecanismos de segurança do sistema operacional.
• Falta de Estruturação: Sistemas complexos têm muitos componentes, tornando difícil isolar quais partes são críticas para a confiança.
• Vulnerabilidade da Infraestrutura de Attestação: A própria infraestrutura que gera a prova de integridade pode ser comprometida por um adversário, criando um ciclo de confiança quebrado. Se o sistema operacional está corrompido, ele pode mentir sobre o estado do sistema.

O artigo argumenta que a confiança não pode ser estabelecida apenas por evidências de tempo de execução; é necessário um ciclo de confiança em camadas, combinando hardware (raiz de confiança) e software, estruturado para resistir a adversários definidos.

2. Metodologia

Os autores utilizam uma abordagem de raciocínio adversarial para projetar o sistema. Em vez de apenas listar mecanismos, eles definem um modelo de adversário realista e projetam o sistema para vencer esse adversário em um "jogo" de atestação.

• Caso de Estudo Principal: Uma Solução de Domínio Cruzado (CDS - Cross-Domain Solution), um sistema que filtra e reescreve mensagens entre redes com diferentes níveis de segurança (ex: de uma rede restrita para uma aberta).
• Tecnologias Utilizadas:
  • Hardware: Módulo de Plataforma Confiável (TPM) para armazenamento de chaves e registro de medidas (PCRs).
  • Sistema Operacional: Linux com SELinux (para isolamento de políticas de segurança) e IMA (Integrity Measurement Architecture, para medição de integridade de arquivos).
  • Ferramentas de Medição: LKIM (Linux Kernel Integrity Measurement) para reavaliação do estado do kernel em tempo de execução.
  • Orquestração: Linguagem Copland e toolkit Maestro para definir protocolos de atestação em camadas.
• Abordagem de Design: O sistema é decomposto em camadas (Boot, Kernel, Gerenciador de Attestação, Provedores de Serviço) com dependências acíclicas, garantindo que camadas inferiores sejam medidas antes das superiores.

3. Contribuições Principais

O artigo apresenta cinco contribuições fundamentais:

1. Modelo de Adversário Realista: Definição de um modelo de ameaça forte para sistemas Linux com SELinux e IMA. O adversário pode ter acesso root, modificar arquivos e reiniciar o sistema, mas não pode modificar o firmware (UEFI) ou o hardware, e não é capaz de realizar ataques de "disparo rápido" (corromper e reparar o kernel instantaneamente durante a janela de atestação).
2. Evidência Empírica e Formal: Demonstração de que os mecanismos propostos vencem o jogo de atestação, detectando corrupções ou impedindo que o sistema seja considerado confiável quando corrompido.
3. Cinco Máximas de Design: Um conjunto de princípios reutilizáveis derivados do processo de design:
   • Máxima 1: Restringir interações para que propriedades atestadas dependam apenas de partes limitadas e mensuráveis do sistema.
   • Máxima 2: Serviços de longa duração lidando com entradas não confiáveis precisam de reavaliação em tempo de execução; processos de curta duração evitam essa necessidade.
   • Máxima 3: A atestação deve ser independente de segredos que poderiam ser expostos por corrupções transitórias (para evitar falhas permanentes).
   • Máxima 4: Cada atestação deve mostrar traços de que originou de um software não corrompido rodando sob um boot confiável.
   • Máxima 5: Uma relação de dependência acíclica permite medir camadas inferiores antes das dependentes, limitando a janela de vulnerabilidade a corrupções muito recentes.
4. Aplicação em Variações: Demonstração de que as mesmas máximas são aplicáveis a outros contextos, como controle de documentos distribuídos e computação confidencial (AMD SEV-SNP).
5. Recomendações de Melhoria: Identificação de lacunas nas tecnologias atuais e propostas de melhorias no kernel Linux e SELinux para eliminar compromissos de segurança.

4. Resultados e Avaliação

• Implementação: O sistema foi totalmente implementado e testado em uma plataforma Fedora Linux com TPM (emulado) e SELinux.
• Desempenho: A sobrecarga de desempenho da atestação é negligenciável (cerca de 1,3%). A atestação completa do sistema leva em média 5,48 segundos, sendo que 92% desse tempo é gasto na medição do kernel (LKIM).
• Eficácia contra Ataques:
  • O sistema detectou com sucesso tentativas de substituição de binários, modificação de políticas de segurança e injeção de módulos de kernel maliciosos.
  • Ataques de replay foram mitigados pelo uso de nonces (números usados uma vez) gerados pelo avaliador.
  • Ataques de "adversário sintonizado em atestação" (que exploram ciclos de dependência entre LKIM e o kernel) foram excluídos do modelo atual, mas o artigo propõe soluções para isso.
• Análise Formal: Uma análise formal utilizando a linguagem Copland confirmou que, dentro do modelo de adversário definido, não há caminhos para o adversário enganar o avaliador sem ser detectado.

5. Significado e Recomendações Futuras

O trabalho é significativo por fornecer um roteiro prático para construir sistemas de atestação robustos, indo além da teoria para uma implementação funcional. Ele destaca que a confiança não é binária, mas um processo de composição de evidências em camadas.

O artigo identifica duas limitações atuais nas tecnologias padrão que forçaram compromissos no design e propõe recomendações para o futuro:

1. Virtualização para LKIM (Recomendação 1): O LKIM atual depende do kernel que está medindo. Recomenda-se executar o LKIM em uma Máquina Virtual separada (com acesso de leitura ao kernel alvo) para eliminar o ciclo de dependência e resistir a rootkits sofisticados.
2. Localidades TPM no Kernel (Recomendação 2): O kernel Linux atual não suporta nativamente o envio de comandos ao TPM com "localidades estendidas" (restrições de origem de comando). Recomenda-se adicionar suporte a isso no kernel e no SELinux para garantir que apenas processos específicos e autorizados possam solicitar assinaturas, protegendo a chave de assinatura contra corrupção transitória do kernel.

Conclusão:
O artigo demonstra que é possível projetar atestações em camadas confiáveis usando hardware e software amplamente disponíveis, desde que o sistema seja estruturado rigorosamente de acordo com princípios de segurança bem definidos. As "máximas" propostas servem como ferramentas mentais para engenheiros de segurança projetarem sistemas que resistam a adversários realistas, garantindo que a confiança seja baseada em evidências sólidas e não em suposições.