A Chave é a Rota: Por Que Verimesh Funciona com WireGuard

Muitos de nós passámos mais horas do que gostaríamos em admitir a ver pessoas a tentar estabelecer um túnel IPsec entre duas firewalls de fornecedores diferentes. Qualquer um que viveu as guerras de VPN dos anos 2000 recorda a sensação: um ficheiro de configuração com quarenta parâmetros, metade dos quais tinha de corresponder exactamente ao outro lado, e um registo de depuração que não lhe dizia nada quando não correspondiam.

Depois, em 2018, um único programador, Jason Donenfeld, submeteu WireGuard para inclusão no kernel Linux, e Linus Torvalds, alguém que famosamente tende a não andar com meias palavras, escreveu que só podia “esperar” que fosse aceite em breve, chamando-lhe “uma obra de arte” ao lado dos “horrores que são OpenVPN e IPSec.” Isso é muita louvor. Entrou no código principal em 2020.

Portanto, quando Palo Alto Networks, que vende as pesadas aplicações de segurança que WireGuard discretamente torna parecerem sobreconstruídas, publica uma explicação Cyberpedia elogiando a sua pequena base de código, criptografia fixa e moderna e velocidade, isso merece uma pausa.

A malha encriptada por baixo de Verimesh funciona em WireGuard, e fazemos uma coisa em cima disso que, tanto quanto eu saiba, ninguém mais faz: a chave do túnel deriva da mesma raiz que a identidade da aplicação.

O que Palo Alto está a apoiar

WireGuard não responde a pacotes que não consegue autenticar. Envie uma sonda de uma chave desconhecida e não obtém nada: sem banner, sem resposta, nem sequer uma tomada de escuta para identificar. Para uma varredura de portas a malha simplesmente não existe, e não pode atacar uma superfície que não consegue encontrar.

Depois há o tamanho. WireGuard tem aproximadamente 4.000 linhas de código. OpenVPN tem cerca de 100.000. IPsec, contando o seu conjunto de normas e implementações, é mais próximo de 400.000. Uma base de código que se consegue ler numa tarde é uma que um ser humano realmente consegue auditar. E auditabilidade nessa escala é ela própria uma propriedade de segurança, uma que não consegue retrofitar em algo duas ordens de magnitude maior.

A criptografia é fixa. Sem suites de cifra configuráveis, sem negociação de algoritmos, sem o passo “vamos fazer downgrade para aquilo que ambos suportamos”. Apenas Curve25519 para a troca de chaves, ChaCha20-Poly1305 para os dados, BLAKE2s para hash, Noise_IKpsk2 a manter tudo junto. Toda a família de ataques de downgrade não existe aqui, porque não há nada a negociar.

E WireGuard encaminha pela chave. A sua tabela de encaminhamento criptográfico de chaves vincula a chave pública de cada par aos intervalos IP que esse par pode usar. Na saída, o endereço de destino selecciona a chave do par, que selecciona a chave de sessão; na entrada, um pacote desencriptado é aceito apenas se a sua origem se enquadra dentro do intervalo autorizado desse par. Não há verificação separada “quem é você” aparafusada junto a uma verificação “o que pode enviar”. A chave pública é a rota. Identidade e alcançabilidade acabam por ser o mesmo facto.

Uma raiz, não duas

Em quase todas as implementações de WireGuard que vi, as chaves vivem uma vida própria. Alguém executa wg genkey, distribui a metade pública, arquiva a metade privada em algum lugar, e acaba com uma chave de rede que não tem nada a ver com a identidade em que a aplicação acima confia. Duas raízes de confiança reconciliadas por uma folha de cálculo e boas intenções.

Em Verimesh há uma raiz. As chaves do túnel Curve25519 de cada organização estão ancoradas no seu próprio material de Gestão de Chaves Descentralizada (DKMS). A mesma infraestrutura de identidade em que a camada da aplicação já funciona. Ninguém as emite. Não há autoridade de certificação no caminho a decidir quais os túneis permitidos, e nenhuma lacuna entre quem é ao nível da rede e quem é acima.

Como as chaves rastreiam até ao material de chave da organização, cada túnel pode ser verificado contra o registo de eventos de chave: pode perguntar qual a identidade que estabeleceu qual túnel e quando, e verificar a resposta criptograficamente em vez de confiar na própria conta do servidor. Quando as chaves rodam, rodam em passo com a pré-rotação de DKMS (construída em KERI), portanto a identidade do túnel sobrevive ao ciclo de vida da chave em vez de partir quando uma chave muda. E como tudo isto é auto-hospedado, nenhum intermediário fica no meio a possuir o fluxo de dados.

Então por que não usar apenas mTLS, que já vincula identidade no handshake de transporte?

Porque manter as camadas separadas é o ponto. WireGuard move pacotes autenticados e encriptados entre pares que mantêm a chave certa, e depois para. Não sabe o que é uma retirada de consentimento, que autorização uma mensagem carrega, ou se uma credencial foi revogada. Essa lógica pertence acima do fio, em DKMS. mTLS tende a puxar autorização para baixo do handshake de transporte até não conseguir mais auditar as duas separadamente. Mantemos as duas separadas de propósito, e construímos as duas na mesma raiz.

Soberano até ao fio

A pilha é Código Aberto do topo ao fundo. WireGuard está no kernel; a camada DKMS acima é nossa, publicada sob a AGPLv3. Nenhum plano de controlo SaaS fica no caminho. Nenhuma terceira parte que possa ser chamada aos tribunais pelas chaves, ninguém registando discretamente quem falou com quem. Para saúde suíça, onde os dados não podem sair do país e a confiança não pode sair da instituição, isto tem de ser mantido até ao transporte. Soberania que pára na camada de aplicação e aluga o seu encanamento de rede a outro não é realmente soberania.

O que estamos a permutar

Nenhuma arquitectura é livre, e as pessoas que executam estes sistemas conseguem sentir o cheiro quando finge o contrário. WireGuard pede três permutas, das quais somos transparentes:

Primeiro, é um túnel de camada 3. Carrega pacotes IP, não fluxos, portanto não obtém o multiplexing de fluxo nativo que um transporte baseado em TLS ou QUIC lhe oferece gratuitamente. Qualquer coisa que necessite de multiplexing constrói acima do túnel. Para uma malha que carrega troca autenticada entre instituições isso é argumentavelmente o lugar certo, mas é uma restrição real, não uma não-questão.

Segundo, a superfície de configuração do par cresce com a malha. WireGuard não envia nenhum plano de controlo que distribua e revogue pares centralmente; cada nó conhece os pares com que fala. Numa malha pequena e governada de hubs e nós isso é uma característica. Nada central a comprometer. À grande escala torna-se trabalho real, e administrar as chaves via DKMS é o que evita que entre em colapso no pesadelo da folha de cálculo anterior.

Terceiro, é mais novo que IPsec. Palo Alto coloca isto na lista de contras e isso faz sentido. Mas a coisa que torna WireGuard novo é a mesma coisa que o torna auditável: Donenfeld descartou três décadas de opcionalidade acumulada e começou de novo. Este é o tipo de permuta que fazemos com gosto.

A questão quântica

WireGuard tem uma camada opcional de chave pré-partilhada que mistura um segredo simétrico no handshake. Isso compra uma coisa: o tráfego capturado hoje não se torna legível depois mesmo que a troca de curva elíptica seja eventualmente quebrada. O ataque de armazenar-agora-desencriptar-depois deixa de funcionar. Isto não é o mesmo que segurança pós-quântica no sentido NIST, e estamos cientes disso. É uma cobertura eficaz.

A rota passada a cobertura tem um nome: Rosenpass, um projecto de Código Aberto que executa uma troca de chave genuinamente pós-quântica em frente do slot de chave pré-partilhada. É um caminho de integração para a malha, não algo que Verimesh envia hoje.

O que é nosso é o que acontece a seguir. Como as chaves do túnel derivam de DKMS, adoptar algoritmos pós-quânticos é uma rotação de chave de rotina no registo de eventos de chave existente. Não uma reemissão de certificado forçada e tudo-de-uma-vez numa propriedade inteira. Transporte emitido por CA não consegue dizer isso.

Uma raiz, do fio para cima

Uma malha onde a chave de rede e a identidade da aplicação crescem a partir do mesmo material DKMS fecha a costura onde a maioria dos ataques interessantes e praticamente todas as falhas de auditoria monótonas vivem: a lacuna entre quem a rede pensa que é e quem a aplicação pensa que é. WireGuard dá-nos um transporte simples o suficiente para confiar; DKMS dá-lhe a mesma identidade que tudo o mais em Verimesh já confia.

Este é o transporte por baixo do lançamento de Verimesh com HIN, por baixo de tudo na Arquitectura de Confiança, onde o caminho completo da chave para o túnel até à mensagem auditada é apresentado de ponta a ponta. O que funciona em cima é Verimesh em si.

Bom encanamento é o tipo em que nunca tem de pensar. Essa é a ideia toda.