Resumo Técnico: OmniSphinx: Redes de Mistura Ativas
Declaração do Problema
As redes de mistura (mix networks) são uma ferramenta crítica para a comunicação anônima, protegendo tanto o conteúdo da mensagem quanto os metadados (ex: relações remetente-destinatário). No entanto, as redes de mistura existentes sofrem de rigidez: elas dependem de formatos de pacotes específicos e fixos (ex: Sphinx, PolySphinx, EROR). Esses formatos são mutuamente incompatíveis, exigindo implantações de software e infraestrutura separadas. Essa fragmentação força os operadores a escolherem um único formato, limitando a funcionalidade do usuário (ex: tráfego de multicast) e impedindo que a rede se adapte a novos formatos sem atualizações coordenadas de infraestrutura.
Embora conceitos de "redes ativas" — onde os nós executam código incorporado nos pacotes — tenham sido propostos para adicionar flexibilidade, eles foram historicamente rejeitados devido às penalidades de desempenho e à falta de casos de uso convincentes. Os autores postulam que as redes de mistura, que já incorrem em latência significativa devido à criptografia e ao embaralhamento (shuffling), representam um caso de uso viável onde o overhead do processamento ativo pode ser aceitável em troca da capacidade de emular diversos formatos dentro de uma única implantação.
Metodologia
Os autores propõem o OmniSphinx, um novo formato de mistura ativa que integra ideias de redes ativas ao protocolo Sphinx estabelecido.
Design Central
O OmniSphinx estrutura os pacotes em um cabeçalho e um corpo (payload). Ao contrário dos formatos tradicionais, onde a lógica de processamento de pacotes é codificada diretamente no protocolo, o OmniSphinx incorpora um programa de mistura para cada nó no caminho diretamente no cabeçalho do pacote.
- Conjunto de Instruções: O sistema utiliza um conjunto de instruções baseado em registradores, customizado para as operações exigidas pelos formatos de mistura existentes (ex: derivação de chave, criptografia/descriptografia, verificação de MAC, preenchimento (padding) e encaminhamento). Este conjunto equilibra flexibilidade com overhead, evitando a ineficiência de código de máquina de baixo nível, permanecendo mais adaptável do que abstrações de alto nível.
- Processamento de Pacotes: Ao receber um pacote, um nó de mistura realiza três estágios:
- Pré-processamento: Deriva o segredo compartilhado via Diffie-Hellman e desembrulha a criptografia onion para revelar o programa de mistura para o salto (hop) atual.
- Execução do Programa: O nó executa as instruções incorporadas. O programa tem acesso ao cabeçalho, ao corpo e ao segredo compartilhado. Uma instrução dedicada
Forward enfileira o pacote resultante.
- Pós-processamento: O nó garante que o pacote de saída atenda aos requisitos de tamanho por meio de preenchimento determinístico.
Análise de Segurança e Privacidade
Os autores abordam três desafios primários: flexibilidade, privacidade e desempenho.
- Garantias de Privacidade: O artigo argumenta que, para programas de mistura arbitrários, as provas de privacidade padrão (Desvinculabilidade de Camada e Indistinguibilidade de Cauda) não se sustentam automaticamente porque o comportamento do nó não é mais fixo. Para resolver isso, os autores:
- Provam que o OmniSphinx satisfaz versões adaptadas de Desvinculabilidade de Camada de Instrução (ILU) e Indistinguibilidade de Cauda de Instrução (ITI) ao usar uma instrução
Forward simples, baseando-se na suposição Gap Diffie-Hellman (GDH).
- Introduzem a Análise de Fluxo de Informação ao contexto da comunicação anônima. Este método classifica os dados como "benignos" ou "malignos" e rastreia dependências através do grafo de instruções. Um programa de mistura é considerado seguro se nenhuma informação maligna (ex: o segredo compartilhado ou dados de pacotes anteriores) fluir para a instrução
Forward.
- Segurança do Nó: O conjunto de instruções é restrito para evitar que usuários maliciosos exfiltrem segredos, controlem o nó (ex: participação em botnets) ou causem negação de serviço (DoS). O tempo de execução e a memória são limitados, e o conjunto carece de acesso à rede arbitrária.
Principais Contribuições
- Protocolo OmniSphinx: Um novo formato de mistura que permite aos remetentes incorporar lógica de processamento customizada, permitindo que uma única instância de rede emule múltiplos formatos existentes e futuros.
- Arquitetura de Conjunto de Instruções: Um conjunto de instruções definido, capaz de emular formatos de mistura relevantes (especificamente demonstrado para Sphinx e PolySphinx) enquanto mantém a eficiência.
- Análise de Fluxo de Informação: A aplicação da análise de fluxo de informação para verificar a privacidade de programas de mistura arbitrários, garantindo que o processamento dinâmico não vaze metadados.
- Avaliação Empírica: Um benchmark abrangente de overhead de largura de banda e computação comparado a formatos nativos.
Resultados
Os autores implementaram o OmniSphinx em Java e avaliaram seu desempenho contra o Sphinx nativo, AE-Sphinx, EROR, MultiSphinx e PolySphinx.
- Overhead de Largura de Banda:
- Emular o Sphinx (o formato mais compacto) aumenta o tamanho do cabeçalho em 33% (de 205 B para 273 B).
- Emular outros formatos acarreta overheads relativos maiores (ex: +127% para AE-Sphinx, +139% para MultiSphinx), principalmente porque o OmniSphinx deve incluir o programa de mistura e um MAC adicional no cabeçalho, enquanto os formatos nativos frequentemente reutilizam MACs para integridade do corpo.
- Em um cenário de pior caso (emulando todos os formatos com um payload de 2 KiB), o tamanho do pacote aumenta aproximadamente 61%.
- Overhead Computacional:
- Criação de Pacote: O desempenho é idêntico ao Sphinx nativo (~1,12 ms), pois ambos são tratados por implementações Java nativas.
- Processamento de Pacote: O processamento do OmniSphinx é mais lento em aproximadamente 90 µs em comparação ao Sphinx nativo (283 µs vs. 198 µs para nós intermediários).
- Custos de Instrução: Instruções simples de movimentação de bytes levam
1,5 µs. Operações criptográficas (MAC, Hash, Criptografia/Descriptografia) levam de 2 a 3 vezes mais tempo, enquanto operações de chave pública (Exponenciação) são as mais lentas (153 µs).
- Capacidade de Emulação: Os autores demonstraram com sucesso que o OmniSphinx pode emular a funcionalidade total do Sphinx e do PolySphinx (incluindo replicação e comunicação em grupo) usando o conjunto de instruções definido.
Significância e Alegações
O artigo afirma que o OmniSphinx demonstra a viabilidade da rede ativa dentro das restrições específicas de redes de mistura. Embora a emulação introduza um overhead mensurável tanto em largura de banda quanto em computação, os autores argumentam que esses custos são razoáveis para casos de uso típicos, como comunicação de e-mail, onde a latência da rede e os custos criptográficos existentes já dominam.
A principal significância reside na mudança de implantações de formato único e rígido para uma infraestrutura flexível e unificada. Isso permite:
- Melhor Utilização de Recursos: Uma única instância de rede de mistura pode atender clientes com diversos requisitos (ex: unicast padrão vs. multicast) sem a necessidade de redes separadas.
- Conjuntos de Anonimato Ampliados: Usuários podem escolher de um conjunto mais amplo e diverso de nós e operadores que suportam suas necessidades específicas de formato.
- Preparação para o Futuro (Future-Proofing): Novos formatos de mistura podem ser implementados e implantados via atualizações de software no conjunto de instruções ou na lógica do cliente, sem a necessidade de mudanças coordenadas de infraestrutura em todos os operadores.
Os autores concluem que, embora o OmniSphinx não seja um substituto direto (drop-in replacement) para formatos nativos devido ao overhead, ele oferece um compromisso atraente para operadores e usuários que buscam flexibilidade e extensibilidade em sistemas de comunicação anônima.