A Chave É a Rota: Porque é que Verimesh Funciona com WireGuard

Muitos de nós já passámos mais horas do que gostaríamos de admitir a ver pessoas tentarem estabelecer um túnel IPsec entre duas firewalls de fornecedores diferentes. Quem viveu as guerras de VPN dos anos 2000 lembra-se bem do sentimento: um ficheiro de configuração com quarenta parâmetros, metade dos quais tinha de corresponder exactamente ao outro lado, e um registo de debug que não vos 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 é famoso por não andar à volta de assuntos, escreveu que só podia “esperar” que fosse integrado em breve, chamando-lhe “uma obra de arte” comparada com os “horrores que são OpenVPN e IPSec.” Isso é elogio de peso. Foi integrado no mainline em 2020.

Portanto, quando Palo Alto Networks, que vende os aparelhos de segurança de peso pesado que WireGuard discretamente torna desnecessariamente complexos, publica um explicador de Cyberpedia elogiando a sua base de código reduzida, criptografia fixa e moderna e velocidade, isso vale a pena notar.

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

O que Palo Alto está a endossar

WireGuard não responde a pacotes que não consegue autenticar. Enviem uma sonda de uma chave desconhecida e não recebem nada: sem banner, sem resposta, nem sequer um socket em escuta para identificar digitalmente. Para um port scan a malha simplesmente não existe, e não podem atacar uma superfície que não conseguem encontrar.

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

A criptografia é fixa. Nenhumas suites de cifras configuráveis, nenhuma negociação de algoritmos, nenhum passo de “vamos degradar para o que ambos conseguimos suportar”. Apenas Curve25519 para a troca de chaves, ChaCha20-Poly1305 para os dados, BLAKE2s para hash, Noise_IKpsk2 mantendo tudo coeso. 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 de chave criptográfica vincula a chave pública de cada par aos intervalos de IP que esse par pode utilizar. 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 é aceite apenas se a sua origem se encontra dentro do intervalo autorizado desse par. Não há uma verificação separada de “quem és tu” aparafusada ao lado de uma verificação de “o que podes enviar”. A chave pública é a rota. Identidade e alcançabilidade resultam ser o mesmo facto.

Uma raiz, não duas

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

Em Verimesh há uma raiz, e tudo pende dela. Cada organização tem a sua própria identidade, construída sobre Decentralized Key Management (DKMS) — a mesma infraestrutura de identidade que a camada de aplicação já executa. Sob essa identidade organizacional, cada conexão é estabelecida por um Iris Agent que possui a sua própria identidade agente: um activo 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 do túnel Curve25519 derivam dessa identidade agente — não de uma string que alguém gerou uma vez com wg genkey e colou num ficheiro de configuração. Não há nenhuma autoridade de certificação de terceiros no caminho a decidir quais túneis são permitidos; a organização emite as suas próprias identidades agente, sob a sua própria raiz. Nenhuma lacuna entre quem sois na camada de rede e quem sois acima disso.

Essa camada intermédia não é cerimónia. É o que torna a malha prática. Uma organização pode estabelecer mais de um nó — sítios separados, centros de dados separados, as duas extremidades de um grupo de clínicas — cada um com a sua própria identidade agente sob a mesma raiz organizacional, cada um deles verificavelmente a mesma instituição. E a rede pode mover-se ao seu próprio ritmo: quando uma chave de túnel precisa de mudar, rodais a identidade agente da qual deriva, sem tocar na identidade organizacional ou nas chaves de aplicação acima. O fio pode agitar-se por baixo enquanto a identidade da instituição fica exactamente onde estava.

Porque cada identidade agente rastreia de volta ao material de chave da organização, cada túnel pode ser verificado contra o registo de evento de chave: podeis perguntar qual identidade estabeleceu qual túnel e quando, e verificar a resposta criptograficamente em vez de confiar na própria conta de si mesma do servidor. Quando as chaves rodiam, rodiam em passo com pré-rotação 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 a coisa toda é auto-hospedada, nenhum intermediário fica no meio a possuir o fluxo de dados.

Porque não usar simplesmente mTLS, que já vincula identidade no handshake de transporte?

Porque manter as camadas separadas é o ponto. WireGuard move pacotes autenticados, encriptados entre pares que possuem a chave correcta, e depois pára. Não sabe o que é uma revogação de consentimento, qual 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 no handshake de transporte até já não conseguirdes auditar os dois separadamente. Mantemos-los separados de propósito, e construímos-los na mesma raiz.

Soberano até ao fio

A stack é Open Source de cima a baixo. WireGuard está no kernel; a camada DKMS acima é nossa, publicada sob AGPLv3. Nenhum plano de controlo SaaS fica no caminho. Nenhuma terceira parte que possa ser citada para os tribunais pelas chaves, ninguém a registar silenciosamente quem falou com quem. Para cuidados de saúde suíços, onde os dados não podem deixar o país e a confiança não pode deixar a instituição, isso tem de manter-se até ao transporte. Soberania que pára na camada de aplicação e aluga o seu encanamento de rede a outro qualquer não é realmente soberania.

O que estamos a negociar

Nenhuma arquitectura é gratuita, e as pessoas que executam estes sistemas conseguem sentir-lo quando fingis o contrário. WireGuard pede três negociações, que somos transparentes sobre:

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 vos oferece gratuitamente. Tudo o que precisa de multiplexing constrói-o acima do túnel. Para uma malha que carrega troca autenticada entre instituições é argumentavelmente o local correcto para isso, mas é uma restrição real, não um não-assunto.

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

Terceiro, é mais jovem que IPsec. Palo Alto coloca isto na lista de contras e isso 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 de novo. Este é o tipo de negociação que fazemos de bom grado.

A questão quântica

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

A rota para além do hedge tem um nome: Rosenpass, um projecto Open Source que executa uma troca de chave genuinamente pós-quântica em frente a esse slot de chave pré-partilhada. É um caminho de integração para a malha, não algo que Verimesh envie hoje.

O que é nosso é o que acontece a seguir. Porque as chaves do túnel derivam de uma identidade DKMS, adoptar algoritmos pós-quânticos é uma rotação de rotina dessa identidade no registo de evento de chave existente — a camada de rede movendo-se ao seu próprio ritmo novamente, desta vez para um algoritmo mais forte. Não uma reemissão de certificado forçada, de uma só vez através de uma propriedade inteira. Transporte emitido por CA não consegue dizer isso.

Uma raiz, desde o 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 vivem a maioria dos ataques interessantes e quase todas as falhas de audit aborrecidas: a lacuna entre quem a rede pensa que sois e quem a aplicação pensa que sois. 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 Arquitectura de Confiança, onde o caminho completo desde chave a túnel a mensagem auditada é exposto de ponta a ponta. O que funciona acima é Verimesh em si.

O bom encanamento é aquele em que nunca têm de pensar. Essa é a ideia toda.