Fingerprinting All AI Cluster I/O Without Mutually Trusted Processors

Resumo Técnico: Identificação de Todo o I/O de Clusters de IA Sem Processadores Mutuamente Confiáveis

Declaração do Problema
À medida que os acordos internacionais sobre o desenvolvimento e a implantação da inteligência artificial (IA) se tornam cada vez mais prováveis, surge uma necessidade crítica de infraestrutura de verificação capaz de confirmar que os centros de dados de IA não estão executando cargas de trabalho não declaradas. O desafio central abordado por este artigo é o Subobjetivo 2A da agenda de verificação de IA (Baker et al., 2025): permitir que um "Provador" (o operador do centro de dados) prove criptograficamente a um "Verificador" (um auditor) que nenhuma computação não divulgada foi realizada dentro de um cluster.

O obstáculo técnico específico é a potencial exfiltração furtiva de resultados de cargas de trabalho não declaradas. Mesmo que um centro de dados afirme estar executando apenas tarefas autorizadas, um ator malicioso poderia esconder os resultados de computações não autorizadas no tráfego que sai das instalações. Isso pode ser alcançado através de:

1. Esteganografia: Esconder dados em cabeçalhos de protocolo (ex: bytes de preenchimento, números de porta, números de sequência) ou dentro dos payloads de texto simples de pacotes de rede.
2. Canais Laterais (Side-Channels): Codificar informações no tempo de transmissão de pacotes (intervalos entre pacotes) ou em propriedades analógicas do sinal óptico.
3. Não Determinismo: Explorar o não determinismo inerente às saídas de inferência de Grandes Modelos de Linguagem (LLMs) para codificar bits ocultos.

Soluções existentes frequentemente dependem de Ambientes de Execução Confiáveis (TEEs) ou componentes de hardware que exigem confiança mútua entre o Provador e o Verificador. No entanto, estabelecer confiança em um único componente de hardware é difícil devido a vulnerabilidades na cadeia de suprimentos (ex: IPs maliciosos, Trojans ao nível de dopante) que não podem ser corrigidas após a implantação.

Metodologia: O Dispositivo de Gateway Seguro (SeGaDev)
Os autores propõem um "Dispositivo de Gateway Seguro" (SeGaDev) colocado no limite da rede norte-sul de um centro de dados de IA (entre o ponto de terminação TLS e a estrutura de roteamento interna). O dispositivo captura todo o tráfego de entrada e saída, sanitiza-o para remover canais furtivos e gera hashes criptográficos para verificação posterior.

A arquitetura é projetada para funcionar sem qualquer processador mutuamente confiável por ambas as partes. Em vez disso, ela se baseia na observabilidade baseada na física e em protocolos criptográficos:

1. Posicionamento e Observação Passiva:

   • O SeGaDev intercepta o tráfego em texto simples após a terminação da criptografia.
   • Divisores Ópticos Passivos (usando Fused Biconical Taper ou Planar Lightwave Circuit) são usados nos links que transportam dados para o Verificador. Isso permite que o Provador observe independentemente os hashes sendo enviados ao Verificador sem poder interferir na perna de monitoramento do Verificador. A confiança é fundamentada na física da divisão de feixe, em vez da integridade do hardware.

2. Sanitização (Warden Ativo):

   • O dispositivo emprega um Warden Ativo para limpar os graus de liberdade esteganográficos dos cabeçalhos de protocolo de rede.
   • Protocolo de Cara ou Coroa (Coin-Flip): Para evitar que qualquer uma das partes controle os valores aleatórios usados para sobrescrever campos de cabeçalho (ex: portas de origem efêmeras, Números de Sequência Inicial TCP), o Provador e o Verificador contribuem para a geração de números aleatórios compartilhados via um protocolo de commit-reveal. Os valores pseudorandom resultantes são usados para sobrescrever os campos de cabeçalho, eliminando a capacidade de codificar dados neles.
   • Re-temporização (Re-timing): O dispositivo armazena os pacotes em buffer e os libera em um cronograma fixo na taxa máxima do link. Isso elimina canais laterais de tempo (ex: modulação de intervalos entre pacotes) e modulação de sinal analógico.

3. Hashing e Compromisso:

   • Após a sanitização, o dispositivo computa hashes criptográficos (ex: SHA-256) sobre os dados do payload (camada de aplicação).
   • Esses hashes, juntamente com carimbos de data/hora (timestamps), são transmitidos ao Verificador através de um link de fibra dedicado.
   • O Provador retém os dados originais em texto simples e o mapeamento de qual dado corresponde a qual hash.

4. Fluxo de Verificação:

   • O Verificador pode desafiar o Provador retroativamente solicitando a pré-imagem dos dados para hashes específicos.
   • O Provador submete os dados em texto simples a uma instalação de verificação segura e mutuamente confiável (fora do escopo do próprio SeGaDev) para repetir a computação e confirmar se o hash coincide.

Principais Contribuições

• Arquitetura para Verificabilidade Mútua: Um design detalhado para um mecanismo de verificação que remove a necessidade de processadores mutuamente confiáveis, aproveitando divisores ópticos passivos e protocolos de coin-flip para garantir que nenhuma das partes possa adulterar a evidência ou o processo de monitoramento.
• Eliminação de Canais Furtivos: Uma metodologia específica para apagar canais esteganográficos em cabeçalhos de protocolo Ethernet e canais laterais de tempo usando uma arquitetura de Warden Ativo adaptada para centros de dados de alta velocidade.
• Avaliação de Viabilidade: Uma análise dos requisitos de armazenamento e largura de banda para uma implantação em larga escala (ex: 100.000 GPUs), estimando que os custos são gerenciáveis em relação à escala dos modernos centros de dados de IA.

Resultos e Análise de Viabilidade
O artigo fornece uma avaliação teórica e arquitetural em vez de resultados experimentais empíricos de uma implantação em escala total. As principais descobertas incluem:

• Canais Furtivos Residuais: Mesmo após a sanitização, os autores identificam três canais potenciais remanescentes:

  1. Modulação de Tempo: Mitigada por contagem de quadros fixos e ordenação canônica, reduzindo a capacidade para eventos de ciclo de vida de conexão.
  2. Esteganografia em Saídas de ML: Identificada como o risco residual mais significativo. O não determinismo na inferência de LLM poderia permitir a exfiltração de ~0,1 bits de dados ocultos por token. Para um cluster de 200k GPUs, isso poderia teoricamente permitir a exfiltração de ~40 Mbit/s. Os autores sugerem que isso pode ser mitigado impondo inferência determinística (via sincronização de sementes e controle de hardware) ou adicionando ruído para limpar a entropia induzida pelo hardware.
  3. Canais de Falha: Codificação de dados no tempo ou ocorrência de "falhas de hardware". Isso é estimado como um canal de baixa largura de banda (~1 kbit/dia), mas pode ser monitorado analisando as taxas de falha contra os dados com hash.

• Requisitos de Armazenamento: Para um hipotético cluster de 100k GPUs transmitindo 200M de tokens/segundo, os autores estimam um requisito anual de armazenamento de pior caso de ~1.260 PB para dados em texto simples e ~200 PB para hashes. Eles observam que este é um limite superior pessimista (assumindo 1 token por pacote JSON) e que o lote padrão (batching) e a compressão reduziriam isso significativamente. O custo é estimado como sendo inferior a 1% do custo total do centro de dados.

• Implementação de Hardware: Os componentes (FPGAs, divisores ópticos, processadores de hash) são comercialmente disponíveis e usados em ambientes de alto risco, como regulação financeira (ex: MiFID II) e redes militares. Os autores estimam que a lista de materiais (BOM) para um dispositivo de demonstração é baixa comparada aos custos de engenharia.

Significância e Alegações
O artigo afirma fornecer uma solução prática e retroajustável (retrofit-able) para verificar a conformidade da IA no nível de rede sem depender da integridade de componentes de hardware específicos. Ao deslocar a raiz da confiança para a observabilidade física (divisores ópticos) e compromissos criptográficos, ele aborda o gargalo da "confiança" na verificação internacional de IA.

Os autores enfatizam que, embora o SeGaDev previna a exfiltração de resultados de cargas de trabalho não declaradas, ele não impede a execução de tais cargas de trabalho internamente. Portanto, ele é um componente crítico de um pipeline de verificação mais amplo que deve ser combinado com outras medidas (ex: taps de rede de backend, contabilidade de utilização de computação) para assegurar totalmente a infraestrutura de IA. O trabalho serve como um design fundamental para a verificação de "Nível 2" (captura de evidências brutas de computação) na hierarquia mais ampla de verificação de IA.