Hoje eu gostaria de falar sobre os resultados de minha pesquisa de sete anos no campo da transmissão de voz através da rede Tor. É geralmente aceito que a comunicação de voz através do Tor é quase impossível:
- os protocolos de transporte existentes para telefonia funcionam sobre o UDP, e o Tor fornece apenas conexões TCP;
- O Tor roteia pacotes através de vários nós, criptografando os dados, o que causa latência significativa e torna a telefonia duplex impossível ou extremamente desconfortável.
Mas é mesmo assim?
Em 2012, pensei pela primeira vez na possibilidade fundamental de implementar comunicações telefônicas anônimas usando os anonimizadores Tor e i2p. A reação da comunidade foi claramente negativa, incluindo o próprio Phil Zimmermann, autor do famoso PGPFone, com base no qual o primeiro Torfon trabalhou. Mas eu era teimoso, testei novas idéias, testei e aprimorei os truques encontrados, visando principalmente reduzir a latência a um nível aceitável. Outros pesquisadores também trabalharam nessa direção, e suas publicações me deram novas idéias e a base para trabalhos futuros. Os aspectos positivos foram a aceleração significativa da rede global da Internet e da rede Tor em particular, bem como o desmame gradual dos usuários da PSTN em favor da comunicação GSM com sua latência significativa inerente. Finalmente, um conceito adequado foi desenvolvido e foi a vez de implementar o plano.
Em 2013, Roger Dingledine em correspondência pessoal criticou severamente o projeto pela falta de plataforma cruzada (na época, o PGPFone era usado como base em uma plataforma Windows) e por sua arquitetura não modular. No contexto dessas críticas, foram lançadas as bases para a implementação moderna do Torfon, levando em consideração muitas tentativas e erros, bem como as tendências modernas da criptografia.
Hoje, o Torfon consiste em quatro módulos de software que interagem entre si usando pacotes de 36 bytes com campos estritamente fixos. Este é um módulo de transporte que fornece trabalho com soquetes, um módulo de criptografia e som, um módulo de armazenamento (executa operações com uma chave privada e contém um catálogo de endereços criptografado) e um módulo de interface com o usuário. Eles podem ser executados na mesma plataforma de hardware (em um ou em diferentes fluxos) ou em várias plataformas isoladas usando um protocolo serial padrão (UART de hardware, USB CSD ou Bluetooth SPP) como interface. Essa arquitetura permite que o desenvolvedor determine um compromisso entre segurança e facilidade de implementação. As opções estão disponíveis desde um aplicativo Windows independente até uma implementação de hardware na forma de uma placa única com Linux for Tor e um módulo de transporte em conjunto com um microcontrolador Cortex M4 isolado que criptografa, processa e reproduz totalmente o áudio, armazena chave e contatos privados e é implementada uma interface gráfica do usuário.
O código fonte dos módulos é escrito em C e é completamente multiplataforma, com exceção do trabalho de baixo nível com áudio, que é transferido para arquivos separados, específicos para Windows (Wave), Linux (Alsa), Android (OpenSL) e bare metal (ADC / DAC + DMA para o microcontrolador )
Ao escolher um codec e uma fila de áudio, os recursos da rede Tor foram levados em consideração: atrasos espontâneos frequentes e periódicos, uma ligeira diminuição na latência de pacotes em um determinado intervalo de comprimento, a capacidade de criar cadeias duplicadas com diferentes caminhos de roteamento durante uma chamada, etc. O projeto intermediário OnionPhone incluiu 17 dos codecs de áudio com baixa taxa de bits mais comuns. Após testes cuidadosos, a opção mais adequada foi selecionada: AMR com uma taxa de bits mínima de 4750 bps e um VAD de alta velocidade. Assim, levando em consideração as pausas naturais entre as palavras e a natureza dúplex da comunicação, a taxa de bits média total em cada direção é de cerca de 2000 a 3000 bps., O que torna possível usar o GPRS mesmo em condições de baixa cobertura GSM e perda maciça de pacotes GSM.
Um eficiente algoritmo NPP7 foi desenvolvido como um supressor de ruído, desenvolvido para combater o intenso ruído de áudio e faz parte do codec MELPe, o atual padrão de comunicações militares STANAG-4591. O algoritmo de cancelamento de eco foi selecionado no projeto WebRTC como a solução aberta mais eficaz disponível.
A funcionalidade geral do Torfon foi desenvolvida levando em consideração possíveis casos de uso e modelos de ameaças existentes que já eram usados contra mensageiros instantâneos populares.
Modos de operação básicos:
- Chamadas de voz anônima para o serviço oculto do Tor (no endereço da cebola). Essas chamadas são protegidas o máximo possível, mas há algum atraso, o que pode causar algum desconforto para usuários desacostumados.
- Alternando para uma conexão direta UDP (com passe NAT) após configurar uma conexão Tor. As chaves de criptografia de sessão negociadas no Tor fornecem uma privacidade forte, mas o anonimato é perdido (os usuários revelam seus endereços IP entre si).
- Chamadas diretas para o endereço IP especificado (ou nome de domínio) e o número da porta TCP. Para receber essas chamadas, você precisa de um endereço IP “branco” (roteável) no dispositivo (muitas operadoras de celular oferecem isso como um serviço pago) ou um encaminhamento da porta TCP usada em um roteador local (por exemplo, em uma rede WiFi doméstica). É possível fazer chamadas diretas em uma rede local isolada (por exemplo, uma rede WiFi local criada usando um poderoso ponto de acesso instalado no centro da área de serviço). Nesse caso, o Torfon não requer interação com a Internet: o projeto não possui seu próprio servidor, que é um ponto potencial de falha, ataque e coleta de metadados. Assim, a Torfon pode trabalhar com sucesso, mesmo com o isolamento completo do segmento de rede ou de todo o Runet no nível do estado.
Hoje, muitas vezes a questão da confiança no Tor é levantada tanto em termos de manutenção do anonimato quanto em termos de confidencialidade dos dados transmitidos. O conhecido messenger TorChat não usou sua criptografia e autenticação, confiando completamente nos serviços fornecidos pelo Tor. Pessoalmente, confio em Tor, pelo menos em termos de privacidade e perfeito segredo para trás. Infelizmente, essa posição é ofuscada pela descoberta de vulnerabilidades globais SPECTER / MELTDOWN, bem como pela massa de vulnerabilidades de dia zero para todos os sistemas operacionais conhecidos que são praticamente usados como ferramentas de trabalho no arsenal de qualquer serviço especial. Portanto, não pude seguir o caminho do TorChat e adicionei minha própria camada de criptografia e autenticação ao Torfon, usando os protocolos mais modernos e primitivas criptográficas comprovadamente fortes.
O conceito baseia-se na capacidade de fazer chamadas entre assinantes desconhecidos e depois trocar automaticamente suas chaves públicas por autenticação mútua nas sessões de comunicação subsequentes. Essa abordagem fornece uma certa negação em relação à presença de uma chave comprometida na lista de seus contatos: qualquer assinante, conhecendo seu endereço de cebola, pode fazer uma ligação anônima e encaminhar imediatamente qualquer contato do seu catálogo de endereços. Este contato será adicionado automaticamente ao seu catálogo de endereços. No entanto, esse recurso pode ser desativado nas configurações, mas quem sabe se você o tinha ativado antes?
É dada especial atenção à proteção dos identificadores de assinantes. Portanto, o chamador sabe para quem está ligando e deve informar seu ID (chave). Mas apenas ele e mais ninguém! Além disso, se a conexão for interceptada, inclusive por um invasor ativo, e depois todas as chaves privadas dos participantes forem divulgadas, não há como estabelecer (ou selecionar na lista de conhecidos) os identificadores dos participantes em cada amostra ou sessão interceptada no passado. Em outras palavras, a proteção do ID da chamada e dos assinantes chamados com perfeito sigilo reverso (PFS). Isso foi conseguido modificando o protocolo Triple-DH (triplo Diffie-Hellman, também usado em Signal) adicionando um protocolo SPEKE paralelo, que fornece divulgação zero com relação a autenticadores explícitos trocados entre as partes durante a troca inicial de chaves.
O protocolo usado no Torfon possui a propriedade Deniability, quando, após uma sessão de comunicação concluída, a parte maliciosa não pode convencer o juiz de que o contato realmente ocorreu. A negação direta também é fornecida quando a parte maliciosa concorda previamente com o juiz que ele conduzirá a sessão e, após a conclusão da sessão, tenta provar que ela ocorreu. Negação total (Negação total, quando a parte maliciosa entra em contato com o juiz durante uma sessão de comunicação) compete com uma propriedade tão importante quanto a KCI - estabilidade (a incapacidade de se apresentar a outro assinante cuja chave privada é conhecida). Com base em realidades práticas, a preferência foi a favor da estabilidade da KCI, como uma propriedade mais prática, especialmente em condições de relações não jurídicas.
Dos recursos adicionais para autenticar um ao outro no primeiro contato (para garantir a autenticidade da troca de chaves), dois protocolos são implementados:
- Comparação de uma impressão digital curta de um segredo compartilhado (SAS, semelhante ao protocolo ZRTP). Para bloquear o ataque curto de impressão digital durante o processo MitM, é usada a confirmação no procedimento Diffie-Hellman. Além disso, a impressão digital do segredo compartilhado é automaticamente incluída no nome do contato aceito nesta sessão. Assim, ao trocar contatos durante uma sessão, o início do nome do novo contato deve ser o mesmo para os dois participantes, o que pode ser verificado posteriormente, por exemplo, pessoalmente. A propósito, o contato recebido deve ser renomeado para permitir que Torfon se represente (seu ID) a esse contato.
- Comparação de um segredo previamente acordado (palavras, frases). Na OTR, o protocolo socialista-milionário desempenha uma função semelhante. A turfa usa o mesmo protocolo SPEKE em termos de propriedades (com divulgação zero).
Caso ambos os participantes da sessão tenham contatos (chaves públicas) um do outro, se a autenticação for bem-sucedida e o Tor (chamada para o endereço de cebola) for usado, a parte receptora fará uma contra-chamada usando o endereço de cebola da parte que está chamando em seu catálogo de endereços. Depois que a conexão é estabelecida, a autenticação mútua é realizada no segundo canal, confirmando o endereço do chamador. Um procedimento semelhante é usado pelo TorChat para autenticar bate-papos, usando o endereço de cebola do contato como um ID.
A conexão Parallel Tor consiste em outras cadeias, as quais são vantajosamente usadas para compensar atrasos espontâneos: os pacotes de voz são enviados aos dois canais ao mesmo tempo, o pacote recebido anteriormente é usado. Além disso, as estatísticas de atrasos nos dois canais são mantidas e, se um deles for muito mais lento, é reconectado periodicamente durante uma conversa. Isso reduz a latência geral da chamada autenticada em comparação com uma chamada de um assinante desconhecido.
Como mostra a triste prática, hoje é muito importante ensinar o aplicativo a se defender contra possíveis bloqueios. Felizmente, o Torfon não possui seu próprio servidor ou nuvem, usando o Tor. Portanto, bloquear o Torfon só é possível bloqueando o Tor. Mas hoje também é uma realidade e, neste caso, haverá apenas a possibilidade de fazer chamadas diretamente para o endereço IP e a porta TCP. No cenário mais pessimista, o big brother tentará ensinar os sistemas DPI (análise profunda de pacotes) a detectar o tráfego entre dois Torfons em uma rede p2p controlada. Portanto, medidas adicionais foram tomadas para maximizar a ocultação desse tráfego. Primeiro, a porta de escuta TCP pode ser selecionada manualmente e, na verdade, faz parte do endereço do assinante. Em segundo lugar, absolutamente todos os pacotes (incluindo áudio) durante uma sessão de comunicação (sessão TCP) não possuem características distintivas (campos, comprimentos constantes ou incrementais, etc.) e parecem dados aleatórios de tamanho aleatório para um observador externo . Em terceiro lugar, para realizar uma amostra ativa do protocolo, é necessária uma "Prova de trabalho" como proteção contra a verificação maciça de endereços e portas para a detecção de Peat.
De fato, a conexão é feita por duas conexões TCP consecutivas. Durante a primeira conexão, as partes trocam chaves de sessão primárias na forma de pontos na curva elíptica X25519, executando o protocolo Diffie-Hellman usual. Como o formato Montgomery da representação de pontos não é um número aleatório, a representação Elligator2, complementada por bytes aleatórios, é usada. Após remover o segredo compartilhado, a primeira sessão é interrompida e, após um período aleatório (vários segundos), a segunda sessão é estabelecida, todos os dados são criptografados com uma chave derivada do segredo compartilhado. Novas chaves de sessão são geradas e o protocolo Diffie-Hellman é executado novamente, agora com um comentário. Chaves simétricas para criptografia e descriptografia são derivadas do segredo obtido. O protocolo triplo Diffie-Hellman é executado em paralelo com o protocolo SPEKE para proteger o identificador de chamadas e a autenticação. Na ausência de chaves no catálogo de endereços (contato desconhecido) ou qualquer discrepância, todas as mensagens são substituídas por bytes aleatórios. O protocolo não é interrompido para impedir o vazamento de informações de identidade dos participantes.
Para a implementação desses protocolos, são utilizados códigos-fonte C cuidadosamente verificados de primitivas criptográficas, retirados de bibliotecas criptográficas conhecidas. Para verificação no estágio de desenvolvimento, vetores de teste conhecidos foram usados e, após cada inicialização do aplicativo, é realizada uma verificação adicional de uma implementação específica do código executável (resultado da compilação).
Para a camada de ofuscação, o algoritmo simétrico Serpent-128 foi selecionado, operando no modo de criptografia OCB autenticado. Para a camada básica da criptografia simétrica, são utilizadas a transformação Keccak-800 como uma função Shake-128 e um contador de pacotes CTR unidirecional. O mesmo primitivo é usado como Hash, MAC e PKDF. O algoritmo ChaCha20 é usado para criptografar o catálogo de endereços e o gerador de números pseudo-aleatórios. O gerador é residente no início de cada sessão, para o acúmulo de entropia nos sistemas operacionais multitarefa, o algoritmo Havege é usado e, no microcontrolador, o bit menos significativo do resultado da ADC, que mede o ruído do divisor resistivo. A entropia é acumulada na quantidade necessária, estimada usando o teste de frequência de grupo.
As principais primitivas criptográficas (matemática elementar para X25519, Keccak800, ChaCha20) usam implementações de assembler otimizadas por compilador para plataformas de microcontroladores (Cortex M1 e M4), cuidadosamente testadas para o tempo de execução constante e com vazamento minimizado pelos canais laterais de radiação eletromagnética e flutuações no consumo de corrente. Devo dizer imediatamente - esses códigos assembler foram recebidos de profissionais mundialmente famosos, eu apenas os transportei do GNU ASM para o ambiente Keil, que é mais familiar para a construção de projetos incorporados.
Bem, o que no final?
Se você leu esse lugar e não morreu de tédio, significa que esse projeto pode realmente ser útil para você. Nesse caso, mediante solicitação por correio, tenho o prazer de fornecer assemblies de teste (arquivos executáveis vinculados estaticamente, sem necessidade de instalação), bem como o código fonte da interface gráfica para Windows, Linux e Android nos respectivos ambientes de desenvolvimento. O núcleo do projeto é baseado na biblioteca torfone de plataforma cruzada, disponível na pesquisa do github. Lá, você também pode encontrar links diretos para a versão alfa do aplicativo Android e um breve guia de instalação e uso, que ajudará todos a avaliar a latência da telefonia na rede Tor.
A interface gráfica é implementada separadamente para cada plataforma e não é uma opção (até agora, isso é apenas um teste alfa). O aplicativo de teste para todas as versões do Windows (a partir do antigo Windows 98) foi executado no antigo mas poderoso Borland C ++ Builder 6. No Linux, o aplicativo GUI foi desenvolvido usando os esquecidos gráficos do Wide Studio for X11 separadamente para as arquiteturas i386 e ARM. O primeiro deve funcionar em desktops de 32 e 64 bits; o segundo - em computadores de placa única de baixo custo: RPi, Orange, Nano etc. Para o Android, um arquivo apk é compilado no Embarcadero RAD Studio 10.2. Isso está longe de ser a melhor opção e ainda não sabe como criar um serviço em primeiro plano, mas, no entanto, funciona de maneira estável em segundo plano, com a otimização do uso da bateria desativada. Além disso, o ambiente Android suporta backup automático de arquivos de configuração, chaves e catálogo de endereços (em formato criptografado) para armazenamento e recuperação externos ao reinstalar o Torfon ou transferi-lo para outro dispositivo. No momento em que escrevo, o trabalho está em andamento em um projeto no ambiente Keil uVision, que inclui transporte, módulos de criptografia, uma interface gráfica e de áudio baseada no Arduino - um monitor 320 * 240 TFT + Touch compatível. O NanoPi Neo com o servidor Debian instalado e a placa Nucleo STM32F446RE conectada através de um UART físico serão usados como uma plataforma de hardware aberta.
Nos planos de longo prazo - migrar para o iOS, embora eu mal entenda como isso pode ser combinado com garantias básicas de segurança.E em conclusão.Muitas vezes me fazem as mesmas perguntas: como posso gerenciar usuários sem um servidor central? Como lançar atualizações, anúncios? E, o mais importante, por que preciso de tudo isso se não houver valor comercial nisso?. , . – . , . «», , , . . . , , . ( ), . . : – , – , , .