Desligaram a Internet Completamente: Chat Offline via Bluetooth e Wi-Fi Direct, e Por Que Não Prometemos Mesh para a Cidade Inteira

Bloqueios são uma coisa. Eles são contornados: VLESS, Reality, proxies, já se escreveu muito sobre isso, inclusive aqui. Mas existe um cenário mais severo. A internet simplesmente não existe. Não é um "YouTube não abre", mas sim a rede móvel foi zerada, o Wi-Fi é inútil porque o uplink foi cortado. Isso é ativado pontualmente: um protesto, uma praça, um bairro, às vezes um país inteiro por algumas horas.

A pergunta é simples: dois telefones ainda podem trocar uma mensagem nessa situação? Sem torres, sem internet, sem servidor. A resposta é: sim, mas a resposta honesta é mais longa e cheia de "mas". Nós (uma equipe de três pessoas, criamos o messenger RCQ) desenvolvemos um modo para isso chamado Radio. Abaixo, o que ele realmente faz, o que não faz, e quais armadilhas encontramos no caminho.

Primeiro, sobre honestidade: "mesh urbano" quase não existe No gênero "messenger sem internet", é comum prometer mesh: telefones formam uma rede, mensagens saltam de dispositivo em dispositivo e chegam ao destinatário do outro lado da cidade, mesmo que centenas de metros os separem. Soa bonito. Em telefones comuns, isso na maioria das vezes não funciona.

As razões são práticas. Um smartphone tem dois rádios de curto alcance: Bluetooth e Wi-Fi. O alcance do Bluetooth é de metros, na melhor das hipóteses dezenas de metros em linha de visão. O Wi-Fi Direct alcança mais longe, mas ainda é uma conexão direta ponto a ponto, não mágica. Para criar um verdadeiro mesh multi-hop, é preciso que em cada telefone intermediário rode um serviço que receba o tráfego alheio, o retransmita adiante, faça isso em segundo plano, sem esgotar a bateria, e sem falhar quando há centenas de dispositivos semelhantes ao redor. Os sistemas operacionais sufocam o trabalho em segundo plano com rádio intencionalmente, em prol da bateria. A história do Bridgefy, que foi vendido a manifestantes como mesh, e depois pesquisadores mostraram que havia grandes problemas com a criptografia e o próprio modelo mesh, é um bom monumento a essas promessas.

Por isso, decidimos desde o início: não mentir. RCQ Radio não é "mesh para a cidade inteira". É comunicação com quem está fisicamente próximo. Um hop, comunicação de rádio direta, raio pequeno. Dentro desses limites, funciona honestamente. Fora deles, não prometemos nada.

Dois camadas: beacon e tubo Uma implementação ingênua faz tudo em um rádio e esbarra no alcance, na banda ou na bateria. Nós dividimos a tarefa em duas camadas.

A primeira camada é a presença, "quem está perto". Aqui funciona o Bluetooth Low Energy (BLE). O telefone envia constantemente um pequeno beacon e escuta os alheios. BLE é ideal para isso: baixo consumo de energia, não requer conexão. No Android, não usamos Google Nearby, mas trabalhamos diretamente com o rádio, via BluetoothLeAdvertiser e BluetoothLeScanner. A contrapartida da economia é o tamanho: na publicidade legacy do BLE cabem cerca de 24 bytes de dados úteis. Neles, é preciso empacotar um prefixo mágico, versão, flags (chat em grupo ou pessoal, se há senha), um identificador curto de sessão e um nome truncado. O nome completo chega após a conexão, em um quadro separado.

A segunda camada são os próprios dados. Aqui é necessária banda, não economia, por isso ativamos o Wi-Fi Direct. No Android, é o WifiP2pManager: um dispositivo se torna o proprietário do grupo, levanta um socket TCP (temos a porta 8989, quadros com prefixo de comprimento, teto de 512 KB por quadro), os outros se conectam a ele. A descoberta dentro do grupo é feita via DNS-SD com registro TXT, que contém o identificador da sessão. No iOS, não manipulamos esses primitivos manualmente, mas usamos o Apple MultipeerConnectivity (MCSession, tipo de serviço rcq-radio), que gerencia a combinação de Wi-Fi e Bluetooth internamente.

A divisão é simples: BLE responde à pergunta "quem está por perto", Wi-Fi Direct e MultipeerConnectivity carregam a carga útil.

Topologia: estrela, não teia Este é o fato técnico mais importante, e o destacamos diretamente. A topologia do Radio é uma estrela com um centro, não uma teia multi-hop.

Quando você cria uma sala ou convida alguém para um chat pessoal, seu telefone se torna o centro: proprietário do grupo Wi-Fi Direct no Android ou host da sessão no iOS. Todos os outros se conectam diretamente a ele. O centro recebe um quadro de um participante e o envia para os outros conectados a ele. Tudo. Sem TTL, sem flood, sem retransmissão "adiante na cadeia". Um dispositivo que não está conectado diretamente ao centro não participa da conversa. As salas são pequenas (no iOS, o teto é de 8 participantes).

O raio é o raio de comunicação direta: metros para Bluetooth, até cem metros em linha de visão para Wi-Fi Direct. Isso é suficiente para um andar, um pátio, um vagão, uma pequena praça. Não é suficiente para alcançar um bairro. E não fingimos que é.

Poderíamos tentar montar um multi-hop nós mesmos, sobre esses mesmos rádios. Consciente e deliberadamente não o fizemos, e não apenas por causa da bateria e das restrições de segundo plano do SO. O multi-hop tem um custo, sobre o qual a publicidade de mesh silencia: o nó intermediário é o telefone de um estranho, através do qual seu tráfego passa. Ele o retransmite, vê o fato da retransmissão, pode retê-lo ou substituí-lo, torna-se um ponto para spam e para deanonymization de quem está perto de quem. Para fazer isso com segurança, é necessária toda uma modelagem de confiança em retransmissores desconhecidos, e em telefones comuns isso rapidamente se torna ficção. Um hop honesto, onde você vê a quem exatamente se conectou, nos parece mais verdadeiro do que uma bela teia na qual não se pode confiar.

Criptografia sem servidor No modo normal, o RCQ criptografa a correspondência via libsignal com forward secrecy. Mas o libsignal, por design, depende de um servidor: lá estão os pacotes prekey, através deles os dispositivos fazem a troca inicial. No offline, não há servidor. Portanto, para o Radio, é necessário um caminho separado, e ele existe.

Chat pessoal: ambos os dispositivos geram um par de chaves efêmeras Curve25519, trocam chaves públicas abertamente (no iOS, isso viaja no contexto de convite do MultipeerConnectivity), calculam um segredo compartilhado via ECDH, o processam através de HKDF-SHA256 com a string de informação rcq-radio-1to1 para separação de domínio. Na saída, uma chave AES de 32 bytes.

Salas: uma sala aberta gera a chave como SHA256 do identificador da sala, quem viu a string, entrou. Uma sala com senha gera a chave via PBKDF2-SHA256, 100 mil iterações, o salt é o identificador da sala (cerca de 200 ms no iPhone 12). A verificação da senha é honesta e implícita: até que o primeiro quadro do host seja descriptografado, você "entrou, mas em mudo". Descriptografou, significa que a chave coincidiu, você está na sala. Não descriptografou, significa que a senha está errada, você é expulso.

A própria mensagem é selada em AES-GCM: nonce de 12 bytes de uso único para cada mensagem, tag de autenticação de 128 bits. Em ambas as plataformas, o mesmo esquema (rcq-radio-1to1, os mesmos parâmetros de sala), embora os transportes sejam diferentes.

Duas consequências importantes. Primeira: UIN, sua identidade na rede RCQ, não sai no ar de forma alguma. No ar de rádio, você é visto como um identificador de sessão efêmero de quatro bytes e um nome-rótulo anônimo. Segunda: nada é armazenado em disco. Mensagens do Radio vivem apenas na memória RAM da sessão, não são gravadas no banco de dados principal, a conexão é interrompida e a correspondência não existe em lugar nenhum. Isso é intencional: uma conversa offline não deixa rastros.

Armadilhas no caminho 24 bytes é muito pouco. A primeira versão da embalagem do beacon não cabia no orçamento da publicidade legacy do BLE, e parte dos dispositivos simplesmente não a mostrava. Tivemos que cortar tudo ao mínimo e aceitar que no beacon vai um pedaço do nome, e o nome completo é enviado após a conexão.

Wi-Fi Direct é um diálogo com o usuário. A formação de um grupo no Android requer consentimento através de um diálogo do sistema, e as negociações sobre quem será o proprietário do grupo não são instantâneas. No iOS, uma dor separada foi com os convites do MultipeerConnectivity. Se o convite "pendurava" (o usuário deslizava a tela sem clicar em "aceitar" ou "recusar"), o lado iniciador ficava no estado .connecting até um timeout de 30 segundos, e depois "desaparecia". É exatamente esse sintoma que os testadores nos traziam. Corrigimos isso fazendo com que qualquer convite não tratado explicitamente seja agora auto-recusado, para que o transporte não fique pendurado.

Emulador é inútil. O emulador não tem rádio BLE, nem Wi-Fi Direct, nem MultipeerConnectivity. Cobrimos a camada criptográfica com testes unitários (simetria ECDH, seal/open round-trip, determinismo das chaves da sala, rejeição por senha funcionam no dispositivo). Mas todo o transporte é verificado apenas assim: você pega dois telefones reais e caminha com eles pelo corredor, verificando a que distância a conexão se rompe.

Plataformas não se dão bem entre si. O Radio para Android é construído sobre BLE bruto mais WifiP2pManager, o Radio para iOS sobre MultipeerConnectivity. São pilhas diferentes que não se conectam entre si no nível do transporte. Portanto, por enquanto, o Radio funciona dentro da mesma plataforma: Android com Android, iOS com iOS. Uma ponte multiplataforma é uma tarefa grande e separada, e não vamos prometê-la agora.

Como bônus, pelo mesmo tubo de Wi-Fi Direct funciona áudio push-to-talk (PCM bruto, 16 kHz, quadros de 40 ms), um walkie-talkie em sua forma pura. A banda da rede local permite isso.

O que isso NÃO resolve A seção sem a qual o artigo seria propaganda. Isso não é um contorno de bloqueios à distância. Se você e o interlocutor estão em partes diferentes da cidade, o Radio não ajudará, ele precisa de comunicação de rádio direta. Para "a internet existe, mas tudo está bloqueado", temos outro mecanismo (VLESS e Reality dentro do aplicativo), isso é sobre outra coisa. Isso não é um mesh multi-hop. A mensagem não viaja através de telefones alheios. Um hop, e ponto final. Metadados de presença são visíveis. Qualquer pessoa com um scanner BLE por perto verá que algum dispositivo RCQ está emitindo um beacon, e um rótulo-nome anônimo. O conteúdo é criptografado com AES-GCM, mas o próprio fato de "alguém está aqui no ar" não pode ser escondido pelo rádio. Bateria. Escaneamento BLE constante mais um grupo Wi-Fi Direct ativo aquecem o telefone e consomem a carga. Este é um modo "quando necessário", não "sempre ligado". Não temos auditoria. Descrevemos o esquema honestamente, mas não passamos por verificação independente de terceiros. O cliente iOS é aberto sob AGPL-3.0, o código pode ser lido. Quando é realmente útil Não "sempre em vez da internet", mas em lacunas específicas. Uma praça ou bairro onde a rede foi zerada, e as pessoas estão próximas. Um andar de um prédio, um porão, um bunker onde nenhuma torre alcança. Um avião, um trem, uma caminhada em local remoto. Um festival onde a torre está sobrecarregada e não responde. Onde quer que as pessoas estejam fisicamente próximas, e a infraestrutura não exista.

Dentro desses limites, dois telefones RCQ ainda conversarão: em chat pessoal ou sala, com criptografia, sem servidor e sem rastros no disco. Fora desses limites, não prometemos nada a vocês, e achamos que dizer isso honestamente é mais importante do que desenhar a palavra "mesh" na caixa.

O cliente Android já está em produção, o modo Radio está nele. O iOS está passando pelo TestFlight. Links e código fonte do iOS (AGPL-3.0) em rcq.app.