Migración de VPN post-cuántica: VPN IPsec, TLS y acceso remoto

Respuesta rápida: La migración a VPN post-cuánticas tiene dos puntos de partida distintos, según lo que admita su dispositivo actualmente. RFC 8784 permite combinar una clave precompartida post-cuántica con la derivación de claves IKEv2 sin necesidad de un nuevo algoritmo de intercambio de claves, un primer paso sencillo que ya está disponible en muchos firewalls de última generación. RFC 9370, basado en el Intercambio Intermedio de RFC 9242, añade un auténtico intercambio de claves híbrido post-cuántico a IKEv2. Las VPN de acceso remoto basadas en TLS heredan el mismo intercambio de claves híbrido (X25519MLKEM768) que ya se implementa en navegadores y CDN. La principal limitación en ambos casos es el firmware: considere la versión específica del producto de su dispositivo como una dependencia estricta y valide la interoperabilidad con la combinación exacta de pares que utilice, no solo con la hoja de ruta general del proveedor.

La migración a VPN recibe menos atención que la migración a TLS en la mayoría de los planes de PQC, lo cual es un error dado el gran volumen de tráfico sensible y de larga duración que circula por túneles VPN IPsec y TLS. A diferencia de un servidor web, un dispositivo VPN no suele ser algo que se pueda actualizar mediante una nueva compilación; se trata de una dependencia de firmware rígida, a menudo controlada por un calendario de lanzamiento del proveedor que usted no controla, y que se ubica en ambos extremos de un túnel que también debe interoperar. Esta guía abarca los protocolos, la cuestión de la preparación del dispositivo y un enfoque de implementación por fases.

Puntos Clave

• RFC 8784 (claves precompartidas post-cuánticas) es el primer paso que requiere menos esfuerzo para las VPN IKEv2, ya que no necesita un nuevo algoritmo de intercambio de claves, solo una clave precompartida integrada en la derivación existente.
• El RFC 9370, basado en el Intercambio Intermedio del RFC 9242, añade un auténtico intercambio de claves post-cuántico híbrido a IKEv2, combinando un intercambio clásico con uno o más KEM post-cuánticos.
• Las VPN de acceso remoto basadas en TLS heredan la compatibilidad con el intercambio de claves híbridas de la pila TLS subyacente, siguiendo el mismo patrón de implementación X25519MLKEM768 que el tráfico del navegador y de la CDN.
• La versión del firmware y del producto son requisitos indispensables para los dispositivos VPN, no una opción de configuración; los anuncios de soporte del proveedor y la preparación real para la implementación son dos cuestiones distintas.
• Las directrices de CISA sobre la preparación para la computación cuántica consideran la colaboración con los proveedores y la validación de la interoperabilidad como partes fundamentales de la hoja de ruta de migración, no como algo secundario.

Intercambio de claves IPsec: dos caminos, diferente esfuerzo.

IKEv2 tiene dos vías distintas de estandarización para lograr resistencia post-cuántica, y no son mutuamente excluyentes.

RFC 8784, claves precompartidas post-cuánticas, incorpora una clave precompartida simétrica, distribuida fuera de banda, a la derivación de claves IKEv2 junto con el intercambio clásico existente. No requiere un nuevo algoritmo asimétrico ni cambios significativos en la negociación IKEv2, razón por la cual suele ser la primera funcionalidad que implementan los dispositivos y la vía más rápida para lograr cierta resistencia cuántica en infraestructuras que ya la soportan.

RFC 9370, Intercambios de claves múltiples en IKEv2, es la respuesta más completa: extiende el protocolo para transportar uno o más intercambios de claves adicionales, típicamente un KEM post-cuántico como ML-KEM, junto con el intercambio clásico, utilizando un enfoque de derivación de clave en cascada. Debido a que el intercambio IKE_SA_INIT original no podía fragmentar material de clave grande, RFC 9242 introdujo por primera vez un "Intercambio Intermedio" específicamente para que RFC 9370 pudiera transportar el material de clave post-cuántico más grande después del handshake inicial, donde la fragmentación está disponible. Este es el camino que produce un intercambio de claves híbrido genuino, no solo un secreto precompartido adicional.

VPN TLS: Heredan el mismo intercambio de claves híbrido

Las VPN de acceso remoto basadas en TLS se encuentran en la misma pila TLS 1.3 que cualquier otro servicio que termine en TLS, lo que significa que heredan el intercambio de claves post-cuántico híbrido de la misma manera que un servidor web: a través de la compatibilidad de la biblioteca TLS subyacente con el grupo X25519MLKEM768, que se trata en profundidad en nuestra guía de implementación de X25519MLKEM768 . Los mecanismos de negociación, los riesgos de compatibilidad y el enfoque de prueba de esa guía se aplican directamente a una puerta de enlace VPN TLS, con una salvedad: el software cliente VPN, no solo los navegadores, debe ser compatible con el grupo híbrido, y los ciclos de actualización del cliente para el software VPN suelen ser más lentos que los ciclos de actualización automática del navegador.

Preparación del dispositivo: El soporte del proveedor no garantiza la preparación para la implementación.

Que un proveedor anuncie compatibilidad con tecnologías post-cuánticas en su hoja de ruta o comunicado de prensa no significa que dicha compatibilidad esté disponible, probada y sea estable en la versión específica del producto que se ejecuta en su entorno. Considere el firmware y la versión del producto como una dependencia estricta y explícita en su plan de migración: identifique la versión mínima exacta que admite el método de intercambio de claves que pretende utilizar, compárela con la versión actualmente implementada y presupueste el ciclo de actualización como parte del cronograma de migración, en lugar de asumir que se realiza automáticamente.

La validación de la interoperabilidad es tan importante como la compatibilidad de versiones. No se garantiza que la compatibilidad con IKEv2 post-cuántico de dos proveedores diferentes, o incluso de dos líneas de productos distintas del mismo proveedor, funcione correctamente desde el primer día. Valide la combinación exacta de pares que utiliza, desde el cliente hasta el concentrador y desde cada sitio, en lugar de asumir que el cumplimiento de estándares generales garantiza la interoperabilidad.

Compatibilidad del cliente

El software cliente VPN de acceso remoto presenta sus propios problemas de compatibilidad, independientemente de la puerta de enlace o el concentrador. Una puerta de enlace VPN que admita el intercambio de claves híbrido no sirve de nada si la aplicación cliente que se conecta a ella, ya sea un cliente VPN dedicado o un portal VPN TLS basado en navegador, no lo admite. Es fundamental realizar un inventario de las versiones del software cliente en todos los equipos remotos con el mismo rigor que el firmware de la puerta de enlace, ya que una flota mixta de clientes actualizados y obsoletos es la situación inicial más común en la mayoría de las implementaciones empresariales, no una migración limpia.

Un enfoque de implementación por fases

1. Línea de base e inventario: Antes de modificar cualquier configuración, confirme la versión actual del firmware o software de cada puerta de enlace VPN, concentrador y cliente, así como su capacidad post-cuántica documentada.
2. Modernice primero la base clásica: Garantizar que ya se cuente con criptografía clásica robusta y versiones de protocolo actuales; la capacidad post-cuántica se basa en una plataforma moderna, no en una heredada.
3. Comience con el RFC 8784, si está disponible: Las claves precompartidas post-cuánticas ofrecen una protección significativa contra la técnica de "cosecha ahora, descifrado después" con un riesgo mínimo para el protocolo, lo que supone un primer paso razonable mientras se desarrolla un soporte más amplio para el intercambio de claves híbridas.
4. Prueba piloto de intercambio de claves híbridas RFC 9370 en un túnel no crítico: Validar la interoperabilidad en la combinación exacta de pares antes de abordar el tráfico de producción.
5. Decida explícitamente sobre el comportamiento de reserva clásico: Determinar si se debe permitir que un par que no puede negociar el intercambio de claves post-cuánticas se conecte con criptografía exclusivamente clásica o si se le debe rechazar directamente, y documentar esa decisión en lugar de dejarla como un valor predeterminado implícito.
6. Registrar y supervisar los algoritmos negociados: Se realiza un seguimiento del método de intercambio de claves que cada túnel negocia realmente en producción, de modo que una posible reversión silenciosa al método clásico se muestre como una métrica, y no como una sorpresa durante una auditoría.

Lo que realmente recomendamos

Comience con claves precompartidas RFC 8784 en una infraestructura que ya las admita, ya que ofrece una protección real contra el robo de datos y el descifrado posterior con el menor riesgo de implementación de todas las opciones actuales. Cree su inventario de firmware y versiones de cliente antes de comprometerse con un cronograma de implementación de intercambio de claves híbrido, y considere los anuncios de la hoja de ruta del proveedor como información para la planificación, no como una fecha de implementación. Pruebe primero el intercambio de claves híbrido RFC 9370 en un túnel único y no crítico, y valide la combinación exacta de pares en lugar de confiar en el cumplimiento de estándares generales.

Cómo puede ayudar la consultoría de cifrado

El despliegue por fases descrito anteriormente depende por completo de un inventario preciso del firmware de las puertas de enlace VPN, las versiones del software cliente y las configuraciones de túnel en todo su entorno. Esta es precisamente la clase de brecha de detección que paraliza la mayoría de los planes de migración antes de que comiencen. CBOM Secure crea y mantiene dicho inventario, asignando a cada punto final VPN su versión actual y su capacidad post-cuántica para que el plan de migración parta de datos reales.

Cuando las operaciones de clave ML-KEM requieren hardware validado por FIPS, HSM-as-a-Service admite el intercambio híbrido RFC 9370 sin un ciclo de adquisición de hardware independiente para cada puerta de enlace. Nuestros servicios de asesoramiento PQC secuencian el ciclo de actualización de firmware, la validación de interoperabilidad y el despliegue por fases descritos anteriormente en función de su combinación específica de dispositivos y topología de túnel, de modo que la planificación del proveedor se traduce en un plan de migración real y probado, en lugar de una mera suposición.

El firmware es el verdadero cronograma de migración.

La migración a VPN post-cuánticas es menos una cuestión de algoritmos que de firmware e interoperabilidad. El RFC 8784 ofrece un primer paso que requiere muy poco esfuerzo, el RFC 9370 ofrece la solución híbrida completa, y las VPN TLS heredan las mismas protecciones que ya recibe el tráfico web. Lo que realmente marca el ritmo de la migración es si la versión específica de su dispositivo, en ambos extremos de cada túnel, admite e interopera correctamente con el método elegido. Por eso, los pasos de inventario y validación de la interoperabilidad son más importantes que la selección del protocolo en sí.

Preguntas frecuentes

¿Cuál es la forma más rápida de agregar protección post-cuántica a una VPN IKEv2 existente?

RFC 8784, claves precompartidas post-cuánticas. No requiere un nuevo algoritmo de intercambio de claves, solo una clave precompartida integrada en la derivación IKEv2 existente, y ya está disponible en muchos dispositivos de última generación.

¿Cuál es la diferencia entre RFC 8784 y RFC 9370?

RFC 8784 incorpora una clave precompartida simétrica a la derivación de claves existente de IKEv2 sin necesidad de un nuevo algoritmo. RFC 9370 añade un intercambio de claves poscuántico híbrido genuino, que combina el intercambio clásico con uno o más KEM poscuánticos como ML-KEM, y requiere que el Intercambio Intermedio de RFC 9242 contenga el material de clave de mayor tamaño.

¿Las VPN de acceso remoto basadas en TLS necesitan un trabajo posterior a la computación cuántica independiente del de las VPN IPsec?

Heredan el intercambio de claves híbridas de la pila TLS 1.3 subyacente, siguiendo el mismo patrón X25519MLKEM768 que cualquier servicio TLS, pero el software cliente VPN necesita específicamente ser compatible con el grupo híbrido, y los ciclos de actualización del cliente suelen ser más lentos que los ciclos de actualización del navegador, por lo que esto requiere su propia comprobación de compatibilidad.

¿El soporte del proveedor para las funciones VPN post-cuánticas equivale a estar listo para su implementación?

No. El anuncio de la hoja de ruta del proveedor es un dato de planificación, no una fecha de implementación. Confirme que la versión específica del firmware o del producto que se ejecuta en su entorno sea compatible con el método de intercambio de claves que piensa utilizar y que haya sido validada para dicho método antes de establecer un cronograma de implementación.

¿Debería permitirse la conexión de pares que solo utilizan tecnología clásica una vez que se implemente el intercambio de claves post-cuántico?

Debería ser una decisión explícita y documentada, no una opción predeterminada. Determine y documente si un interlocutor que no puede negociar el intercambio de claves post-cuánticas debe seguir pudiendo conectarse con criptografía clásica o si debe ser rechazado, y registre los algoritmos negociados en producción para que el comportamiento real sea visible.