Anonimato & OPSEC
Roteamento anônimo e privado para constelações de satélites: novo estudo adapta Loopix para redes LEO
Pesquisadores propõem uma arquitetura de roteamento anônimo para constelações de satélites LEO, combinando Loopix, FEC multipath, Private Information Retrieval e atrasos adaptativos.
Um novo paper publicado no arXiv, intitulado “Reliable and Private Anonymous Routing for Satellite Constellations”, propõe uma arquitetura de comunicação anônima e confiável para constelações de satélites de baixa órbita, conhecidas como LEO — Low Earth Orbit. O trabalho é assinado por Nilesh Vyas, Fabien Geyer e Svetoslav Duhovnikov, da Airbus Central R&T, e foi publicado em 12 de fevereiro de 2026.
A proposta parte de um problema real: redes de satélites LEO são dinâmicas, compartilhadas e cada vez mais usadas em cenários civis, comerciais, governamentais e militares. Mesmo quando o conteúdo das mensagens está criptografado, os metadados continuam sendo sensíveis. Quem fala com quem, quando, por qual rota e com qual frequência pode revelar padrões operacionais, localização, cadeia de comando ou atividade de uma organização.
Por que satélites LEO criam um problema diferente
Em uma rede terrestre tradicional, os nós normalmente são estáveis: roteadores, datacenters, links e caminhos não mudam a cada poucos minutos. Em constelações LEO, a situação é diferente. Os satélites se movem em alta velocidade, os links entre satélites aparecem e desaparecem, e as rotas precisam ser recalculadas com frequência.
O paper descreve três desafios principais:
- Instabilidade de caminho: rotas válidas podem quebrar antes da mensagem chegar
- Vazamento no plano de roteamento: clientes precisam consultar rotas frequentemente, e essas consultas revelam intenção de comunicação
- Viés topológico: certos satélites, especialmente em regiões polares ou pontos centrais da constelação, concentram tráfego
Esses três fatores afetam diretamente o anonimato. Uma rota quebrada força reconexão. Uma reconexão gera nova consulta. Uma consulta pode revelar interesse de comunicação. E se certos nós concentram tráfego, eles viram alvos melhores para vigilância ou comprometimento.
Segundo o resumo do arXiv, o trabalho propõe uma evolução da mixnet Loopix para lidar com topologias voláteis, usando três contribuições principais: transmissão multipath com códigos de apagamento, descoberta privada de rotas via PIR e atrasos adaptativos baseados em centralidade.
Base técnica: o que é Loopix
O estudo usa o Loopix como base. Loopix é uma rede de anonimato de baixa latência baseada em mixnet. Diferente de onion routing tradicional, ela trabalha com mensagens, atrasos probabilísticos, tráfego de cobertura e mistura de pacotes para dificultar a correlação entre entrada e saída.
O paper original do Loopix, apresentado na USENIX Security 2017, descreve o sistema como uma rede de anonimato de baixa latência que oferece anonimato de remetente e destinatário, usando Poisson mixing, tráfego de cobertura e mensagens de loop para resistir a análise de tráfego.
A ideia básica é:
mensagem entra no mix → recebe atraso aleatório → sai misturada com outras mensagens → adversário perde correlação temporal diretaO problema é que o Loopix original assume uma rede relativamente estável. Em satélites LEO, isso não é verdade. Uma rota pode deixar de existir durante a própria comunicação.
A arquitetura proposta
A arquitetura proposta combina quatro ideias principais:
- Loopix como camada de anonimato baseada em mixnet
- FEC multipath com Reed-Solomon para tolerar perda de caminho
- PIR com criptografia homomórfica para consultar rotas sem revelar qual rota foi consultada
- Atrasos adaptativos baseados em centralidade ou latitude para reduzir viés topológico
Fluxo simplificado:
usuário → provider → divide mensagem em partes → aplica FEC → escolhe múltiplas rotas privadas → envia por caminhos diferentes → receiver provider reconstrói a mensagem
Na página 4 do PDF, a Figura 1 mostra esse conceito: um usuário envia dados para um provider, que divide e encaminha os pedaços por caminhos diferentes dentro da rede de mix nodes; o provider do destinatário reconstrói a mensagem no final.
FEC multipath: confiabilidade contra rotas quebradas
A primeira grande contribuição é usar Forward Error Correction, especificamente códigos de apagamento do tipo Reed-Solomon, para combater perda de pacotes causada por links instáveis.
Em vez de enviar uma mensagem por uma única rota, o sistema faz:
mensagem original → k pedaços de dados → n pedaços totais com paridade → envio por n caminhos diferentesSe o destinatário receber qualquer conjunto suficiente de k pedaços, consegue reconstruir a mensagem original. Isso permite tolerar a perda de alguns caminhos.
Exemplo conceitual:
n = 3, k = 2
envia 3 partes por 3 rotas diferentes
qualquer 2 partes recebidas bastam para reconstruir a mensagemNo experimento do paper, sem FEC, uma probabilidade de perda de link de apenas 1,5% pode gerar perda de mensagem próxima de 40%. Com FEC, especialmente no esquema n = 2, k = 1, a entrega fica quase perfeita mesmo com instabilidade significativa. A Figura 7, na página 10, mostra essa diferença entre envio sem FEC e envio com FEC.
Benefício secundário: mais anonimato
O FEC também tem um efeito positivo sobre anonimato. Como uma mensagem lógica é dividida e enviada por múltiplos caminhos, o tráfego fica menos óbvio para correlação.
O paper mostra, na Figura 8, que transmissões multipath com FEC alcançam maior entropia média para o mesmo atraso fim a fim quando comparadas ao envio de um único pacote.
Em termos simples:
uma mensagem por uma rota → mais fácil correlacionar
uma mensagem dividida por rotas independentes → mais ruído para o adversárioIsso não torna a comunicação invencível, mas melhora o trade-off entre confiabilidade e privacidade.
PIR: consulta de rotas sem revelar interesse de comunicação
A segunda grande contribuição é proteger o processo de descoberta de rotas.
Em uma rede LEO, o cliente precisa consultar uma base de rotas para saber por onde enviar a mensagem. O problema: se o servidor de rotas vê qual rota o cliente pediu, ele aprende algo sensível.
Exemplo:
cliente consulta rota A → B
diretório observa consulta
diretório infere possível comunicação entre A e BPara resolver isso, o paper usa Private Information Retrieval, ou PIR, baseado em criptografia homomórfica. O cliente consegue consultar uma entrada específica da base de rotas sem revelar ao servidor qual entrada foi consultada.
Fluxo simplificado:
cliente sabe o índice da rota desejada
cliente envia consulta criptografada
servidor processa a base sem saber o índice
servidor retorna resposta criptografada
cliente descriptografa e obtém a rotaO paper usa o esquema homomórfico BFV e menciona implementação com Microsoft SealPIR / SEAL. A base simulada contém 191.577 caminhos gerados a partir de uma constelação OneWeb-like de 631 satélites.
O arXiv também resume que o trabalho integra um protocolo PIR computacionalmente eficiente durante a descoberta de rotas, mitigando vazamento de metadados no diretório de rotas.
Resultado do PIR: viável na prática?
O paper testa diferentes arquiteturas de PIR. A mais simples, sem batching, é inviável: mesmo com 64 cores, uma consulta curta ainda leva dezenas de segundos. Já as versões otimizadas com batching, packing e paralelismo ficam muito mais práticas.
Na Tabela I, na página 8, os autores mostram que:
- O baseline não batched é lento demais
- O single-server batched reduz a latência para cerca de 339 ms com 64 cores
- O single-server com packing otimizado chega perto de 193 ms
- A arquitetura paralela com 27 servidores chega a 173 ms em 32 cores para uma consulta
- O cenário multi-query processa 100 consultas em 8,77 s, cerca de 87,7 ms por consulta amortizada
A Figura 6, na página 9, resume essa análise de escalabilidade.

Topologia LEO e pontos de concentração
A terceira contribuição trata do viés topológico. Constelações LEO não distribuem tráfego de forma perfeitamente uniforme. Dependendo da órbita e da geometria da rede, certos satélites aparecem com maior frequência em caminhos.
No caso avaliado, o paper usa uma constelação inspirada na OneWeb. A base usa efemérides publicadas pelo CelesTrak em 30 de abril de 2024 e considera 631 satélites.
O CelesTrak mantém conjuntos de elementos orbitais para satélites OneWeb, usados por ferramentas e pesquisadores para rastreamento e simulação orbital.
Nas Figuras 4 e 5, na página 7, o paper mostra que satélites próximos aos polos tendem a ter maior centralidade, funcionando como pontos mais importantes na rede.


Isso cria um problema:
nós mais centrais → mais tráfego → melhor alvo para adversário → maior risco de correlaçãoAtrasos adaptativos: misturar mais onde importa mais
Para lidar com essa concentração, os autores avaliam atrasos adaptativos nos mix nodes. Em vez de todos os nós aplicarem o mesmo atraso, o sistema ajusta o atraso conforme a posição ou importância topológica do satélite.
Duas estratégias são avaliadas:
- Atraso baseado em centralidade
- Atraso baseado em latitude
A ideia é concentrar mais “esforço de mistura” nos pontos em que o tráfego tende a se concentrar. As Figuras 11 e 12, na página 11, mostram que estratégias baseadas em centralidade e latitude oferecem melhor trade-off entre entropia e latência do que atrasos uniformes.


Escolha de caminhos: curto nem sempre é melhor
O paper também compara duas estratégias de escolha de rota:
- menor caminho, priorizando baixa latência
- caminho aleatório, priorizando diversidade e anonimato
A Figura 13 mostra o trade-off: rotas mais curtas reduzem latência, mas geram menor entropia. Rotas aleatórias aumentam o conjunto de anonimato, mas custam mais atraso.

Em linguagem prática:
menor caminho → melhor performance, menor privacidade
caminho aleatório → maior privacidade, mais latênciaEssa é uma escolha de política. Em comunicações críticas, pode fazer sentido aceitar mais latência para reduzir previsibilidade.
Mistura exponencial vence stop-and-go
O estudo compara estratégias de mixagem de pacotes. A estratégia exponential mixing, também associada ao Poisson mixing usado pelo Loopix, teve melhor resultado do que stop-and-go mixing.
Na Figura 16, página 12, a mistura exponencial alcança maior entropia média para o mesmo atraso fim a fim.

Isso reforça a escolha arquitetural de usar Loopix como base, já que Loopix foi desenhado justamente em torno de atrasos independentes e tráfego de cobertura. O paper original do Loopix afirma que o sistema usa Poisson mixing e cover traffic para resistir a análise de tráfego, inclusive contra adversário global passivo.
Resiliência contra nós comprometidos
O estudo também avalia o impacto de comprometimento de nós.
O resultado é esperado, mas importante:
- Se o adversário compromete nós aleatórios, a perda de anonimato é gradual
- Se o adversário compromete os nós mais importantes, a perda é muito mais rápida
A Figura 15, página 12, mostra que um ataque direcionado contra nós de alta entropia ou alta importância degrada a privacidade mais rapidamente do que corrupção aleatória. Segundo o texto do paper, comprometer cerca de 20% dos nós mais críticos pode causar perda de entropia próxima de 30%.

Onde essa arquitetura faria sentido
O paper é especialmente relevante para redes compartilhadas e de uso misto, como:
- constelações LEO comerciais
- redes governamentais sobre infraestrutura comercial
- comunicações militares em infraestrutura compartilhada
- operações diplomáticas ou humanitárias
- backbones não terrestres com múltiplos tenants
- ambientes onde metadados são tão sensíveis quanto conteúdo
A proposta é interessante porque tenta permitir que tráfego sensível seja misturado ao tráfego público de alto volume da constelação. Em tese, isso reduz a necessidade de gerar tráfego de cobertura artificial, usando o próprio fluxo normal da rede como “ruído” operacional.
Limitações do estudo
Apesar dos resultados fortes, o estudo tem limitações importantes.
Primeiro, a avaliação assume principalmente um adversário global passivo com comprometimento estático de nós. Ataques ativos, como jamming direcionado, flooding de links ou manipulação adaptativa da topologia, ficam fora do escopo principal.
Segundo, o sistema depende de snapshots de topologia. Os autores sugerem como trabalho futuro integrar algoritmos preditivos baseados na mecânica orbital dos satélites, o que poderia selecionar rotas com maior chance de permanecerem válidas e reduzir overhead de FEC.
Terceiro, a arquitetura PIR ainda precisa ser otimizada para constelações muito maiores, com 10.000 ou mais satélites. O paper menciona como trabalho futuro avaliar protocolos como OnionPIR, SpiralPIR, SimplePIR e FrodoPIR.
Conclusão
O paper “Reliable and Private Anonymous Routing for Satellite Constellations” apresenta uma arquitetura sólida para um problema que tende a crescer: como proteger metadados em redes LEO compartilhadas, dinâmicas e potencialmente usadas por atores civis, comerciais e estatais.
A proposta combina Loopix, FEC multipath, PIR com criptografia homomórfica e atrasos adaptativos para lidar com três riscos centrais: rotas instáveis, vazamento na descoberta de rotas e concentração topológica de tráfego. Os resultados mostram que o FEC pode praticamente eliminar perda de mensagens em cenários de instabilidade, que o PIR pode operar com latência prática em uma base de 191.577 rotas, e que atrasos baseados em centralidade melhoram o trade-off entre anonimato e latência.
A principal mensagem técnica é clara: em redes de satélite, anonimato não é apenas criptografar pacotes. É preciso proteger a rota, a consulta de rota, o padrão de falhas, o timing, os pontos de concentração e a própria previsibilidade orbital da rede.
Fontes consultadas- Paper enviado: Reliable and Private Anonymous Routing for Satellite Constellations, Nilesh Vyas, Fabien Geyer e Svetoslav Duhovnikov.
- arXiv — Reliable and Private Anonymous Routing for Satellite Constellations.
- arXiv PDF — versão do artigo.
- USENIX Security — The Loopix Anonymity System.
- arXiv — The Loopix Anonymity System.
- CelesTrak — dados orbitais OneWeb.
- eoPortal — visão geral técnica da constelação OneWeb.