A Chave É a Rota: Por Que Verimesh Funciona em WireGuard

Muitos de nós gastámos mais horas do que gostaríamos de admitir a ver pessoas tentarem ativar um túnel IPsec entre duas firewalls de fornecedores diferentes. Quem viveu as guerras de VPN dos anos 2000 lembra-se da sensação: um ficheiro de configuração com quarenta parâmetros, metade dos quais tinha de corresponder exatamente ao outro lado, e um registo de depuração que não 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 conhecido por não andar com rodeios, escreveu que podia “apenas esperar” que fosse integrado em breve, chamando-lhe “uma obra de arte” em comparação com os “horrores que são OpenVPN e IPSec”. Isto é um grande elogio. Entrou no ramo principal em 2020.

Assim, quando a Palo Alto Networks, que vende os pesados equipamentos de segurança que WireGuard discretamente torna parecerem construídos em excesso, publica um explicador de Cyberpedia elogiando a sua pequena base de código, criptografia fixa e moderna e velocidade, isso merece um momento de atenção.

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

O que a Palo Alto está a endossar

WireGuard não responde a pacotes que não consegue autenticar. Se enviar uma sonda a partir de uma chave desconhecida, não obtém nada: sem apresentação, sem resposta, nem sequer um soquete aberto para identificar. Para uma varredura de portas, a malha simplesmente não está lá, e não pode atacar uma superfície que não consegue encontrar.

Depois existe o tamanho. WireGuard tem aproximadamente 4.000 linhas de código. OpenVPN tem cerca de 100.000. IPsec, contando a sua extensão de normas e implementações, é mais próximo de 400.000. Uma base de código que consegue ler numa tarde é uma que um ser humano pode realmente auditar. E a capacidade de auditoria nessa escala é em si uma propriedade de segurança, uma que não consegue adicionar retroativamente a algo duas ordens de magnitude maior.

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

E WireGuard encaminha por chave. A sua tabela de encaminhamento criptográfico por chave vincula a chave pública de cada par aos intervalos de IP que esse par pode usar. No caminho de saída, o endereço de destino seleciona a chave do par, que seleciona a chave de sessão; no caminho de entrada, um pacote desencriptado é aceite apenas se a sua origem se encontra dentro do intervalo autorizado desse par. Não existe um “quem és tu” separado ligado ao lado de um “o que podes enviar” separado. A chave pública é a rota. Identidade e capacidade de acesso revelam-se 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 que a aplicação acima dela confia. Duas raízes de confiança reconciliadas por uma folha de cálculo e boas intenções.

Em Verimesh existe uma raiz, e tudo está dependente dela. Cada organização tem a sua própria identidade, construída na Gestão Descentralizada de Chaves (DKMS) — a mesma infraestrutura de identidade que a camada de aplicação já executa. Sob essa identidade organizacional, cada ligação é ativada por um Agente Iris que possui a sua própria identidade de agente: um ativo verificável, enraizado no material DKMS da organização, que representa um nó na malha em vez da instituição como um todo. As chaves de túnel Curve25519 derivam dessa identidade de agente — não de uma cadeia que alguém gerou uma vez com wg genkey e colou numa configuração. Não existe uma autoridade de certificação de terceiros no caminho decidindo quais os túneis permitidos; a organização emite as suas próprias identidades de agente, sob a sua própria raiz. Sem lacuna entre quem é na camada de rede e quem é acima dela.

Essa camada intermédia não é cerimónia. É o que torna a malha prática. Uma organização pode ativar mais do que um nó — locais separados, centros de dados separados, os dois extremos de um grupo de clínicas — cada um com a sua própria identidade de agente sob a mesma raiz organizacional, cada um deles verificavelmente a mesma instituição. E a rede pode mover-se no seu próprio relógio: quando uma chave de túnel precisa mudar, rodeia a identidade de agente de que deriva, sem tocar na identidade organizacional ou nas chaves de aplicação acima dela. A rede pode mudar por baixo enquanto a identidade da instituição fica exatamente onde está.

Porque cada identidade de agente remonta ao material de chave da organização, cada túnel pode ser verificado contra o registo de eventos de chave: pode perguntar que identidade ativou que túnel e quando, e verificar a resposta criptograficamente em vez de confiar na conta da própria instituição. Quando as chaves rodarem, rodam em sincronismo com pré-rotação DKMS (construída em KERI), assim a identidade de túnel sobrevive ao ciclo de vida da chave em vez de quebrar quando uma chave muda. E como tudo isto é auto-hospedado, nenhum intermediário fica no meio possuindo o fluxo de dados.

Então por que não usar mTLS, que já vincula identidade ao aperto de mão de transporte?

Porque manter as camadas separadas é o ponto. WireGuard move pacotes autenticados, encriptados entre pares que detêm a chave correta, 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 da rede, em DKMS. mTLS tende a puxar autorização para baixo no aperto de mão de transporte até que já não consegue auditar os dois separadamente. Mantemos os dois separados de propósito, e construímo-los na mesma raiz.

Soberano até à rede

A pilha é Open Source de cima a baixo. WireGuard está no kernel; a camada DKMS acima dela é nossa, publicada sob AGPLv3. Nenhum plano de controlo SaaS fica no caminho. Nenhuma terceira parte que possa ser citada para as chaves, ninguém registando discretamente quem falou com quem. Para a 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 manter-se até ao transporte. Soberania que para na camada de aplicação e renta a sua tubagem de rede a outra pessoa não é realmente soberania.

O que estamos a trocar

Nenhuma arquitetura é gratuita, e as pessoas que executam estes sistemas conseguem senti-lo quando fingem o contrário. WireGuard pede três trocas, sobre as quais somos transparentes:

Primeiro, é um túnel de camada 3. Carrega pacotes IP, não fluxos, pelo que não obtém a multiplexação de fluxo nativa que um transporte baseado em TLS ou QUIC lhe oferece gratuitamente. Tudo o que precisa de multiplexing constrói-a acima do túnel. Para uma malha que transporta troca autenticada entre instituições isso é argumentavelmente o lugar correto, mas é uma restrição real, não um não-problema.

Segundo, a superfície de configuração de pares cresce com a malha. WireGuard não tem um plano de controlo que distribua e revogue pares centralmente; cada nó conhece os pares com que fala. Numa malha pequena e governada de centros e nós isso é uma característica. Nada central para comprometer. Em larga escala torna-se trabalho real, e administrar as chaves via DKMS é o que a impede de colapsar no pesadelo da folha de cálculo anterior.

Terceiro, é mais jovem que IPsec. Palo Alto coloca isto na lista de contras e faz sentido. Mas a coisa que torna WireGuard jovem é a mesma coisa que a torna auditável: Donenfeld deitou fora três décadas de opcionalidade acumulada e começou do zero. Este é o tipo de troca que fazemos com prazer.

A questão quântica

WireGuard tem uma camada de chave pré-partilhada opcional que mistura um segredo simétrico no aperto de mão. Isso obtém uma coisa: 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 conscientes disso. É um amortecimento eficaz.

A rota passada o amortecimento tem um nome: Rosenpass, um projeto Open Source que executa uma troca de chaves genuinamente pós-quântica na frente dessa ranhura de chave pré-partilhada. É um caminho de integração para a malha, não algo que Verimesh distribui hoje.

O que é nosso é o que acontece a seguir. Porque as chaves de túnel derivam de uma identidade DKMS, adotar algoritmos pós-quântica é uma rotação rotineira dessa identidade no registo de eventos de chave existente — a camada de rede movendo-se no seu próprio relógio novamente, desta vez para um algoritmo mais forte. Não uma reemissão de certificado forçada, tudo de uma vez, em toda uma propriedade. O transporte emitido por AC não consegue dizer isso.

Uma raiz, da rede para cima

Uma malha onde a chave de rede e a identidade de aplicação crescem a partir do mesmo material DKMS fecha a costura onde a maioria dos ataques interessantes e quase todos os falsos de auditoria 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 resto em Verimesh já confia.

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

Boa tubagem é aquela que nunca tem de pensar. Essa é a ideia toda.