La clave es la ruta: por qué Verimesh se ejecuta en WireGuard

Muchos de nosotros hemos pasado más horas de las que nos gustaría admitir viendo a personas intentar establecer un túnel IPsec entre dos firewalls de diferentes proveedores. Cualquiera que vivió las guerras de VPN de los años 2000 recuerda la sensación: un archivo de configuración con cuarenta parámetros, la mitad de los cuales tenían que coincidir exactamente con el otro lado, y un registro de depuración que no te decía nada cuando no lo hacían.

Luego, en 2018, un único desarrollador, Jason Donenfeld, presentó WireGuard para su inclusión en el kernel de Linux, y Linus Torvalds, alguien que es famoso por no andarse con rodeos, escribió que solo podía «esperar» que se fusionara pronto, llamándolo «una obra de arte» comparado con los «horrores que son OpenVPN e IPSec». Ese es un gran elogio. Llegó a la rama principal en 2020.

Entonces, cuando Palo Alto Networks, que vende los aparatos de seguridad de gran envergadura que WireGuard silenciosamente hace que parezcan sobredimensionados, publica un explicador de Cyberpedia elogiando su pequeña base de código, criptografía fija moderna y velocidad, vale la pena detenerse un momento.

La malla cifrada debajo de Verimesh se ejecuta en WireGuard, y hacemos una cosa en la parte superior que, hasta donde sé, nadie más hace: la clave del túnel se deriva de la misma raíz que la identidad de la aplicación.

Lo que Palo Alto respalda

WireGuard no responde a paquetes que no puede autenticar. Envía un sondeo desde una clave desconocida y no obtienes nada: sin pancarta, sin respuesta, ni siquiera un socket de escucha para obtener datos. Para un escaneo de puertos, la malla simplemente no está allí, y no puedes atacar una superficie que no puedes encontrar.

Luego está el tamaño de esto. WireGuard tiene aproximadamente 4.000 líneas de código. OpenVPN tiene alrededor de 100.000. IPsec, contando su expansión de estándares e implementaciones, está más cerca de 400.000. Una base de código que puedes leer en una tarde es una que un ser humano puede auditar realmente. Y la capacidad de auditoría en esa escala es en sí misma una propiedad de seguridad, una que no puedes retrofit en algo dos órdenes de magnitud más grande.

La criptografía es fija. Sin suites de cifrado configurables, sin negociación de algoritmos, sin el paso «reduzcamos a lo que ambos soportamos». Solo Curve25519 para el intercambio de claves, ChaCha20-Poly1305 para los datos, BLAKE2s para hash, Noise_IKpsk2 manteniéndolo todo unido. Toda la familia de ataques de degradación no existe aquí, porque no hay nada que negociar.

Y WireGuard enruta por clave. Su tabla de enrutamiento de criptoclaves vincula la clave pública de cada par a los rangos IP que ese par puede usar. En salida, la dirección de destino selecciona la clave del par, que selecciona la clave de sesión; en entrada, un paquete descifrado se acepta solo si su origen cae dentro del rango autorizado de ese par. No hay una comprobación separada de «quién eres» acoplada junto a una comprobación «qué puedes enviar». La clave pública es la ruta. La identidad y la accesibilidad resultan ser el mismo hecho.

Una raíz, no dos

En casi todas las implementaciones de WireGuard que he visto, las claves tienen vida propia. Alguien ejecuta wg genkey, distribuye la mitad pública, archiva la mitad privada en algún lugar, y termina con una clave de red que no tiene nada que ver con la identidad en la que la aplicación confía. Dos raíces de confianza reconciliadas por una hoja de cálculo e intenciones honorables.

En Verimesh hay una raíz. Las claves del túnel Curve25519 de cada organización están ancladas en su propio material de Gestión Descentralizada de Claves (DKMS). La misma infraestructura de identidad en la que la capa de aplicación ya se ejecuta. Nadie las emite. No hay una autoridad certificadora en el camino decidiendo cuáles túneles están permitidos, y no hay brecha entre quién eres en la capa de red y quién eres arriba.

Porque las claves remontan al material de clave propio de la organización, cada túnel puede verificarse contra el registro de eventos de clave: puedes preguntar qué identidad abrió qué túnel y cuándo, y verificar la respuesta criptográficamente en lugar de confiar en la propia cuenta del servidor sobre sí mismo. Cuando las claves rotan, rotan en sincronía con DKMS pre-rotación (construido en KERI), por lo que la identidad del túnel sobrevive al ciclo de vida de la clave en lugar de romperse cuando una clave cambia. Y como todo está auto-hospedado, ningún intermediario se sienta en el medio poseyendo el flujo de datos.

Entonces, ¿por qué no simplemente usar mTLS, que ya vincula la identidad en el apretón de manos de transporte?

Porque mantener las capas separadas es el punto. WireGuard mueve paquetes autenticados y cifrados entre pares que tienen la clave correcta, y luego se detiene. No sabe qué es un retiro de consentimiento, qué autorización lleva un mensaje, o si una credencial ha sido revocada. Esa lógica pertenece arriba de la línea, en DKMS. mTLS tiende a extraer la autorización hacia el apretón de manos de transporte hasta que ya no puedas auditar los dos por separado. Las mantenemos separadas a propósito, y las construimos en la misma raíz.

Soberano hasta la línea

La pila es Código Abierto de arriba a abajo. WireGuard está en el kernel; la capa DKMS arriba es nuestro, publicado bajo la AGPLv3. Ningún plano de control SaaS se sienta en el camino. Ningún tercero que pueda ser citado para testificar por las claves, nadie registrando silenciosamente quién habló con quién. Para la salud suiza, donde los datos no pueden salir del país y la confianza no puede salir de la institución, eso tiene que mantenerse hasta el transporte. La soberanía que se detiene en la capa de aplicación y alquila su tubería de red de otra persona no es realmente soberanía.

Lo que estamos intercambiando

Ninguna arquitectura es gratuita, y las personas que ejecutan estos sistemas pueden olerlo cuando finges lo contrario. WireGuard pide tres intercambios, sobre los cuales somos transparentes:

Primero, es un túnel de capa 3. Transporta paquetes IP, no flujos, por lo que no obtienes el multiplexado de flujos nativo que un transporte basado en TLS o QUIC te entrega gratis. Cualquier cosa que necesite multiplexado lo construye arriba del túnel. Para una malla que porta intercambio autenticado entre instituciones, se podría argumentar que es el lugar correcto, pero es una restricción real, no un problema menor.

Segundo, la superficie de configuración de pares crece con la malla. WireGuard no envía un plano de control que distribuya y revoque pares centralmente; cada nodo conoce los pares con los que habla. En una malla pequeña y gobernada de concentradores y nodos eso es una característica. Nada central que comprometer. A gran escala se convierte en trabajo real, y administrar las claves vía DKMS es lo que evita que se colapse en la pesadilla de hoja de cálculo de antes.

Tercero, es más joven que IPsec. Palo Alto pone esto en la lista de contras y eso tiene sentido. Pero lo que hace que WireGuard sea joven es lo mismo que lo hace auditable: Donenfeld descartó tres décadas de opcionalidad acumulada y comenzó de nuevo. Este es el tipo de intercambio que hacemos con gusto.

La cuestión cuántica

WireGuard tiene una capa de clave pública opcional que mezcla un secreto simétrico en el apretón de manos. Eso compra una cosa: el tráfico capturado hoy no se vuelve legible más tarde incluso si el intercambio de curva elíptica finalmente se rompe. El ataque almacenar-ahora-descifrar-después deja de funcionar. Esto no es lo mismo que la seguridad post-cuántica en el sentido de NIST, y somos conscientes de eso. Es una cobertura efectiva.

La ruta pasada la cobertura tiene un nombre: Rosenpass, un proyecto de Código Abierto que ejecuta un auténtico intercambio de claves post-cuántico frente a esa ranura de clave pública. Es una ruta de integración para la malla, no algo que Verimesh envíe hoy.

Lo que es nuestro es lo que sucede después. Porque las claves del túnel se derivan de DKMS, adoptar algoritmos post-cuánticos es una rotación de clave rutinaria en el registro de eventos de clave existente. No una reemisión de certificado forzada y de una sola vez en toda una infraestructura. El transporte emitido por CA no puede decir eso.

Una raíz, desde la línea hacia arriba

Una malla donde la clave de red y la identidad de aplicación crecen del mismo material DKMS cierra la grieta donde viven la mayoría de los ataques interesantes y casi todos los aburridos fracasos de auditoría: la brecha entre quién piensa que eres en la red y quién piensa que eres en la aplicación. WireGuard nos da un transporte lo suficientemente simple para confiar en él; DKMS le da la misma identidad en la que todo lo demás en Verimesh ya confía.

Este es el transporte debajo del despliegue de Verimesh con HIN, debajo de todo en la Arquitectura de Confianza, donde la ruta completa desde clave a túnel a mensaje auditado está establecida de extremo a extremo. Lo que se ejecuta en la parte superior es Verimesh mismo.

La buena tubería es la clase en la que nunca tienes que pensar. Esa es la idea completa.