Preparación para la era poscuántica: el enfoque de Nexusguard sobre la preparación para la Criptografía Poscuántica (PQC)

La seguridad de una conexión cifrada depende de algo más que de la solidez de su algoritmo de cifrado. También depende de cómo las partes que se comunican establecen las claves que protegen su intercambio. A medida que avanza la computación cuántica, esta distinción está pasando de las discusiones especializadas en criptografía a la planificación general de la ciberseguridad. Las organizaciones responsables de información confidencial, servicios críticos e infraestructura de larga duración necesitan comprender cada vez más qué partes de su entorno criptográfico pueden requerir una modernización, y cómo realizar esa transición sin interrumpir las operaciones.

‍

En Nexusguard, prepararse para la era poscuántica es parte de nuestra estrategia continua de modernización de la infraestructura. Hemos introducido soporte para el intercambio de claves híbrido poscuántico bajo TLS 1.3, incluido X25519MLKEM768, que combina el X25519 clásico con el estándar ML-KEM-768 del NIST. Nuestro equipo de ingeniería ha validado con éxito esta capacidad en un entorno de producción, lo que marca un paso práctico hacia una mayor agilidad criptográfica. 

‍

Por qué la criptografía poscuántica es importante ahora

Gran parte de la seguridad de Internet actual se basa en algoritmos de clave pública como RSA y la criptografía de curva elíptica para autenticar sistemas y establecer secretos compartidos. Estos mecanismos siguen siendo ampliamente utilizados, pero una computadora cuántica con capacidad criptográfica suficiente podría socavar los problemas matemáticos de los que dependen. Nadie puede determinar con certeza una fecha en la que esa amenaza se vuelva real. Sin embargo, para la información que debe permanecer confidencial durante muchos años, esperar a que exista tal computadora puede ser demasiado tarde.

‍

La preocupación suele describirse como "recopilar ahora, descifrar después": un adversario registra el tráfico cifrado hoy con la esperanza de descifrarlo en el futuro. El riesgo no es uniforme. Su importancia depende de la sensibilidad y la vida útil de los datos, el protocolo utilizado y si el establecimiento de la clave correspondiente podría llegar a romperse. Por lo tanto, las agencias gubernamentales, las instituciones financieras y los operadores de infraestructura crítica tienen buenas razones para inventariar sus dependencias criptográficas y priorizar los sistemas cuyos requisitos de seguridad se extienden mucho hacia el futuro.

‍

El Instituto Nacional de Estándares y Tecnología (NIST) de EE. UU. publicó FIPS 203 en 2024, estandarizando el Mecanismo de Encapsulación de Claves Basado en Redes de Módulos (ML-KEM). ML-KEM ofrece a los implementadores un bloque de construcción poscuántico estandarizado para establecer secretos compartidos. Sin embargo, los estándares son solo un punto de partida: la preparación operativa también requiere implementaciones interoperables, una configuración sólida, gestión del ciclo de vida y evidencia de conexiones reales.

‍

Qué cambia realmente el TLS híbrido poscuántico

El intercambio de claves híbrido poscuántico combina un mecanismo convencional de establecimiento de claves con un mecanismo poscuántico en un único intercambio negociado. Un ejemplo es X25519MLKEM768, que combina el mecanismo clásico X25519, ampliamente implementado, con ML-KEM-768. El secreto compartido resultante se basa en ambos componentes, lo que proporciona una ruta de transición diseñada para mantener la seguridad si al menos uno de los componentes sigue siendo seguro bajo los supuestos de la construcción. El despliegue híbrido también permite a las organizaciones adquirir experiencia práctica con la criptografía poscuántica antes de pasar a cambios criptográficos más extensos.

‍

Fundamentalmente, X25519MLKEM768 es un grupo de intercambio de claves con nombre de TLS, no un conjunto de cifrado. En TLS 1.3, el grupo de intercambio de claves establece el material de clave, mientras que un conjunto de cifrado como TLS_AES_256_GCM_SHA384 especifica el cifrado simétrico y las funciones criptográficas asociadas. Esta distinción es importante al evaluar las afirmaciones de los proveedores: admitir TLS 1.3, o simplemente ofrecer un conjunto de cifrado AES sólido, no prueba por sí solo que un servicio negocie un intercambio de claves híbrido poscuántico.

‍

Tampoco el intercambio de claves híbrido hace que toda la conexión TLS sea segura frente a la computación cuántica. Los certificados de servidor y las firmas digitales pueden seguir dependiendo de algoritmos clásicos. La afirmación precisa es más limitada pero importante: un cliente y un servidor compatibles pueden utilizar el establecimiento de claves híbrido poscuántico para una conexión TLS específica. Esa capacidad debe verificarse en el punto de terminación TLS real en lugar de inferirse de la presencia de una biblioteca criptográfica.

‍

Por qué la preparación para el despliegue es más que una casilla de verificación de software

Una plataforma de seguridad de producción puede contener múltiples puntos de terminación TLS, interfaces de gestión, API, proxies y conexiones internas. Habilitar un grupo híbrido en un receptor no extiende automáticamente esa protección a todas las conexiones adyacentes. Del mismo modo, una prueba de laboratorio exitosa no es prueba de un despliegue en producción. Una validación sólida establece qué nombre de host o punto final se probó, qué versión de TLS se negoció, qué grupo de intercambio de claves se seleccionó y si la validación del certificado fue exitosa.

‍

La compatibilidad es otra consideración operativa. No todos los clientes admiten el intercambio de claves híbrido hoy en día, por lo que una transición gradual puede permitir que los clientes compatibles negocien X25519MLKEM768 mientras se mantienen los grupos clásicos aprobados para los clientes que aún no se han actualizado. Esta es una política de interoperabilidad práctica, no una declaración de que cada conexión utiliza automáticamente PQC. Los equipos de seguridad deben distinguir entre que un punto final sea capaz de realizar una negociación híbrida, que un cliente capaz la seleccione por defecto y que una política la requiera para cada conexión.

‍

El enfoque de Nexusguard: validar, desplegar, verificar

Nexusguard está introduciendo el intercambio de claves híbrido poscuántico como parte de una modernización continua de su infraestructura de seguridad. Nuestro equipo de ingeniería ya ha validado un protocolo de enlace TLS 1.3 exitoso que negocia X25519MLKEM768 en un entorno de producción actualizado. Esa evidencia es más significativa que una lista de características: demuestra que un punto final real desplegado puede completar el intercambio híbrido solicitado con un cliente compatible.

Estado del despliegue

Nexusguard está desplegando progresivamente capacidades de intercambio de claves híbrido poscuántico en las partes aplicables de su infraestructura global. El despliegue se está implementando en fases para respaldar la estabilidad operativa, la continuidad del servicio y la compatibilidad con los entornos de cliente existentes. Actualmente, se prevé que la finalización se produzca en las próximas semanas. Una vez que un punto final aplicable se actualiza y configura, los clientes TLS 1.3 compatibles pueden negociar PQC híbrido sin que los clientes tengan que seleccionar una política criptográfica en el Portal de Administración. La disponibilidad y el comportamiento negociado deben verificarse en el punto final específico.

‍

Somos deliberadamente específicos sobre lo que significa este hito. Se refiere al intercambio de claves híbrido para conexiones TLS compatibles; no implica que todas las rutas de tráfico, enlaces de gestión interna, firmas digitales o funciones de mitigación de DDoS se hayan vuelto seguras frente a la computación cuántica. Esa distinción ayuda a los clientes a realizar evaluaciones de seguridad informadas y proporciona a nuestros equipos de ingeniería una base medible para ampliar la cobertura.

‍

El lugar de la criptografía poscuántica (PQC) en una estrategia de resiliencia más amplia

La protección contra DDoS y la criptografía poscuántica abordan riesgos diferentes. La mitigación de DDoS está diseñada para preservar la disponibilidad del servicio ante tráfico malicioso, mientras que el intercambio de claves híbrido poscuántico refuerza el establecimiento de secretos para ciertas conexiones cifradas. Un servicio de protección contra DDoS puede ser eficaz para mitigar ataques aunque sus interfaces administrativas aún requieran una modernización criptográfica. Por el contrario, un punto final TLS compatible con la tecnología poscuántica no se vuelve resistente a ataques volumétricos simplemente porque su protocolo de enlace haya cambiado.

No obstante, estas capacidades pertenecen a la misma conversación operativa, ya que la infraestructura de seguridad se encuentra en rutas de comunicación críticas y debe permanecer accesible y confiable. Las organizaciones que revisan su arquitectura deben examinar la resiliencia de su plano de gestión junto con las defensas de red y de capa de aplicación. Para obtener más contexto, consulte los artículos de Nexusguard: “Protección DDoS para SASE / Resiliencia de confianza cero” y “Integración de WAF y mitigación de DDoS: una alianza poderosa contra las ciberamenazas.”

‍

Una lista de verificación práctica de preparación para la PQC destinada a equipos de seguridad

Comience con un inventario criptográfico: identifique los servicios, aplicaciones, API, interfaces de gestión y dependencias de terceros que dependen de la criptografía de clave pública. Clasifíquelos según su exposición, la sensibilidad de los datos y el tiempo de confidencialidad. Luego, examine dónde termina el TLS y si la compilación de software y la política vigentes pueden negociar grupos híbridos aprobados. Un número de versión por sí solo no sustituye a una prueba de protocolo de enlace exitosa.

‍

A continuación, valide la experiencia de los clientes reales, incluidos navegadores, integraciones de API y agentes automatizados. Registre la versión de TLS y el grupo de intercambio de claves negociados, verifique la confianza del certificado y pruebe el comportamiento de respaldo cuando la compatibilidad clásica siga siendo necesaria. Finalmente, trate el despliegue como un cambio operativo: establezca una secuencia de implementación, supervisión, procedimientos de reversión y un proceso para volver a verificar los puntos finales después de las actualizaciones. Estas medidas convierten una discusión sobre estándares en un programa de seguridad manejable.

‍

La visión a largo plazo: agilidad criptográfica

La transición poscuántica no terminará con una única actualización de TLS. Los algoritmos criptográficos, las guías de implementación, el soporte al cliente y los ecosistemas de certificados seguirán evolucionando. 

‍

Por lo tanto, las organizaciones necesitan agilidad criptográfica: la capacidad de descubrir dónde se utiliza la criptografía, actualizar políticas y componentes, y verificar los resultados sin tener que rediseñar servicios completos. El intercambio de claves híbrido es un hito útil en ese camino, especialmente cuando se acompaña de pruebas disciplinadas y una divulgación honesta de su alcance.

‍

El trabajo de Nexusguard refleja ese enfoque. Al introducir y validar el establecimiento de claves híbrido poscuántico en entornos de producción compatibles, estamos sentando una base práctica para la futura modernización criptográfica, al tiempo que seguimos priorizando la disponibilidad y la estabilidad de los servicios de los que dependen nuestros clientes hoy en día.

‍

Preguntas frecuentes

¿Qué es la criptografía poscuántica (PQC)?

La PQC se refiere a algoritmos criptográficos diseñados para resistir ataques tanto de computadoras convencionales como cuánticas. Es especialmente relevante para la criptografía de clave pública, donde las futuras capacidades cuánticas podrían amenazar los mecanismos de establecimiento de claves y firmas ampliamente utilizados. El estándar ML-KEM del NIST es un componente fundamental para el establecimiento de claves poscuánticas.

‍

¿Qué es el intercambio de claves híbrido poscuántico?

El intercambio de claves híbrido combina un mecanismo clásico y uno poscuántico para establecer un secreto compartido. Proporciona una ruta de migración práctica porque los sistemas compatibles pueden introducir un componente poscuántico mientras conservan uno clásico bien conocido. Su protección se limita al intercambio y la construcción que se utilizan, no a todas las funciones de seguridad del servicio.

‍

¿Qué es X25519MLKEM768?

X25519MLKEM768 es un grupo de intercambio de claves TLS híbrido que combina el clásico X25519 con ML-KEM-768, un algoritmo estandarizado en NIST FIPS 203. Cuando una conexión TLS 1.3 negocia este grupo, utiliza ambos mecanismos para el establecimiento de claves. No se trata, por sí mismo, de un conjunto de cifrado TLS ni de una firma de certificado poscuántica.

‍

¿TLS 1.3 significa automáticamente que un sitio web utiliza PQC?

No. TLS 1.3 puede implementarse utilizando únicamente el intercambio de claves clásico. Para verificar el PQC híbrido en una conexión específica, inspeccione el grupo de intercambio de claves negociado (por ejemplo, X25519MLKEM768) utilizando un navegador compatible o un cliente de diagnóstico TLS. Las capacidades del software del servidor y el protocolo de enlace realmente negociado son hechos distintos.

‍

¿Nexusguard es compatible con PQC híbrido?

Sí. Nexusguard es compatible con el intercambio de claves poscuántico híbrido bajo TLS 1.3, incluido X25519MLKEM768. Esta capacidad ha sido validada con éxito en un entorno de producción y forma parte de nuestro compromiso continuo con la modernización criptográfica. La negociación real depende de las capacidades y configuraciones del cliente que se conecta y del punto de conexión del servicio correspondiente.

‍

¿Tendrán los clientes que cambiar su configuración?

Para los puntos de conexión de Nexusguard cubiertos por la actualización, el intercambio de claves híbrido se gestiona a nivel de plataforma. Los clientes no necesitan seleccionar una nueva política criptográfica en el Portal de Administración, pero su cliente debe ser compatible con el grupo híbrido correspondiente para que pueda negociarse. El intercambio de claves clásico sigue estando disponible para garantizar la compatibilidad, siempre que la política de la plataforma lo permita.

‍

¿El PQC hace que la mitigación de DDoS sea más fuerte?

No directamente. El PQC protege aspectos del establecimiento de claves criptográficas; la mitigación de DDoS protege la disponibilidad del servicio frente al tráfico de ataques. Ambos son importantes para la resiliencia de la infraestructura, pero resuelven problemas diferentes y no deben presentarse como protecciones intercambiables.