Trust Architecture

La Clave es la Ruta: Por Qué Verimesh se Ejecuta en WireGuard

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 haya vivido 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.

Entonces en 2018 un único desarrollador, Jason Donenfeld, presentó WireGuard para su inclusión en el kernel de Linux, y Linus Torvalds, alguien que famosamente tiende a no andarse con rodeos, escribió que sólo podía «esperar» que se fusionara pronto, llamándolo «una obra de arte» junto a los «horrores que son OpenVPN e IPSec». Eso es un elogio muy alto. Se integró en la rama principal en 2020.

Así que cuando Palo Alto Networks, que vende los pesados aparatos de seguridad que WireGuard silenciosamente hace parecer excesivos, publica un explicador de Cyberpedia elogiando su pequeña base de código, criptografía fija y moderna, y velocidad, eso merece un momento de consideración.

La malla encriptada debajo de Verimesh se ejecuta en WireGuard, y hacemos una cosa en la parte superior que, por lo que 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 está aprobando

WireGuard no responde paquetes que no puede autenticar. Envía una sonda desde una clave desconocida y no obtienes nada: sin bandera, sin respuesta, ni siquiera un socket de escucha para identificar. 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 despliegue 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 realmente puede auditar. Y la auditabilidad a esa escala es en sí misma una propiedad de seguridad, una que no puedes añadir a posteriori 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 «degradémonos 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 junto. 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 criptográfico por clave vincula la clave pública de cada peer con los rangos IP que ese peer puede usar. Hacia afuera, la dirección de destino selecciona la clave del peer, que selecciona la clave de sesión; hacia adentro, un paquete desencriptado se acepta sólo si su origen está dentro del rango autorizado de ese peer. No hay una comprobación separada «quién eres» soldada junto a una comprobación «qué puedes enviar». La clave pública es la ruta. La identidad y la alcanzabilidad resultan ser el mismo hecho.

Una raíz, no dos

En casi todas las implementaciones de WireGuard que he visto, las claves viven una vida propia. Alguien ejecuta wg genkey, entrega 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 que la aplicación sobre ella confía. Dos raíces de confianza reconciliadas por una hoja de cálculo e buenas intenciones.

En Verimesh hay una raíz, y todo cuelga de ella. Cada organización tiene su propia identidad, construida en Gestión de Claves Descentralizada (DKMS) — la misma infraestructura de identidad en la que la capa de aplicación ya se ejecuta. Bajo esa identidad organizacional, cada conexión es establecida por un Iris Agent que posee su propia identidad agencial: un activo verificable, enraizado en el material DKMS de la organización, que representa un nodo en la malla en lugar de la institución como un todo. Las claves del túnel Curve25519 se derivan de esa identidad agencial — no de una cadena que alguien generó una vez con wg genkey y pegó en una configuración. No hay una tercera autoridad certificadora en el camino decidiendo qué túneles están permitidos; la organización emite sus propias identidades agenciales, bajo su propia raíz. Sin brecha entre quién eres en la capa de red y quién eres en la parte superior.

Esa capa intermedia no es ceremonia. Es lo que hace que la malla sea práctica. Una organización puede establecer más de un nodo — sitios separados, centros de datos separados, los dos extremos de un grupo clínico — cada uno con su propia identidad agencial bajo la misma raíz organizacional, cada uno de ellos verificablemente la misma institución. Y la red puede moverse en su propio reloj: cuando una clave de túnel necesita cambiar, rotas la identidad agencial de la que se deriva, sin tocar la identidad organizacional o las claves de aplicación superiores. El cable puede cambiar por debajo mientras la identidad de la institución permanece exactamente donde está.

Porque cada identidad agencial se remonta al material clave de la organización, cada túnel se puede verificar contra el registro del evento clave: puedes preguntar qué identidad estableció qué túnel y cuándo, y verificar la respuesta criptográficamente en lugar de confiar en la cuenta de su propio servidor. Cuando las claves rotan, rotan en paso con la pre-rotación DKMS (construida en KERI), así que la identidad del túnel sobrevive al ciclo de vida de la clave en lugar de romperse cuando una clave cambia. Y dado que todo es auto-hospedado, ningún intermediario se sienta en el medio siendo dueño del flujo de datos.

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

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

Soberano hasta el cable

La pila es Open Source de arriba a abajo. WireGuard está en el kernel; la capa DKMS encima es la nuestra, publicada bajo la AGPLv3. No hay un plano de control SaaS en el camino. Ningún tercero que pueda ser citado para 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 fontanería de red de otro no es realmente soberanía.

Lo que estamos intercambiando

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

Primero, es un túnel de capa 3. Lleva paquetes IP, no flujos, así que no obtienes el multiplexado de flujos nativo que un transporte basado en TLS o QUIC te entrega de forma gratuita. Cualquier cosa que necesite multiplexado lo construye encima del túnel. Para una malla que lleva intercambio autenticado entre instituciones, eso es posiblemente el lugar correcto, pero es una restricción real, no un problema sin importancia.

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

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 tiró tres décadas de opcionalidad acumulada e impactó desde cero. Este es el tipo de intercambio que hacemos con gusto.

La pregunta cuántica

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

La ruta más allá de la protección tiene un nombre: Rosenpass, un proyecto Open Source que ejecuta un verdadero intercambio de claves post-cuántico frente a esa ranura de clave precompartida. Es una ruta de integración para la malla, no algo que Verimesh envíe hoy.

Lo que es nuestro es lo que sucede a continuación. Porque las claves del túnel se derivan de una identidad DKMS, adoptar algoritmos post-cuánticos es una rotación rutinaria de esa identidad en el registro del evento clave existente — la capa de red moviéndose en su propio reloj de nuevo, esta vez a un algoritmo más fuerte. No una reemisión de certificado forzada y de una sola vez en toda una estructura. El transporte emitido por CA no consigue decir eso.

Una raíz, desde el cable hacia arriba

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

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

La buena fontanería es la que nunca tienes que pensar. Esa es la idea completa.

Seguir leyendo

Fundamentos digitales soberanos para la salud global
Perspectives
· ggreve

Fundamentos digitales soberanos para la salud global

La 3.ª Convocatoria Global de la Iniciativa Global sobre Salud Digital (GIDH) ha reunido a un conjunto diverso y distinguido de delegados: directores de ministerios, agencias de Naciones Unidas, organizaciones no gubernamentales e industria. Cada contribución comparte un hilo conductor que vertebra toda la conversación: los fundamentos digitales importan, y ningún país puede construirlos en […]

Leer más →
El consentimiento no es una casilla: el artículo 71 de EHDS lo convirtió en ley. Nosotros lo hicimos funcionar.
Trust Architecture

El consentimiento no es una casilla: el artículo 71 de EHDS lo convirtió en ley. Nosotros lo hicimos funcionar.

El artículo 71 de EHDS convirtió la exclusión en un derecho legal el año pasado. El expediente de acuerdos de 2026 mostró qué sucede cuando la arquitectura no puede honrarlo. DKMS es el primer fundamento estructuralmente sólido que puede — a través de límites institucionales, después de que los datos ya han sido divulgados, con el regulador observando.

Leer más →

Comunicación verificada — construida y desplegada, no solo descrita.

La infraestructura de confianza de Vereign está operativa en toda la sanidad suiza. Reserve una revisión arquitectónica de 30 minutos para definir qué significa la comunicación soberana para su organización.

Protección de datos suiza Conforme con el RGPD Open Source AGPLv3+ Alojamiento suizo