¿Qué novedades hay en la criptografía poscuántica en RHEL 10.1?

En mayo de 2025, Red Hat Enterprise Linux 10 (RHEL) se distribuyó con los primeros pasos hacia la criptografía poscuántica (PQC) para proteger contra ataques de computadoras cuánticas, que harán factibles los ataques a algoritmos criptográficos clásicos existentes, como RSA y las curvas elípticas. Todavía no se conoce la existencia de computadoras cuánticas criptográficamente relevantes (CRQC), pero eso no significa que el riesgo sea cero. Por ejemplo, los ataques de "recolectar ahora, descifrar después" no necesitan una computadora cuántica ahora; solo se necesita que una esté disponible antes de que los datos cifrados almacenados pierdan su valor y, según los datos transferidos, podrían pasar décadas antes de que eso suceda.

Para prepararse para un futuro cuántico, RHEL 10.1 mejora las defensas contra ataques de este tipo de “recolección ahora, descifrado después” e introduce firmas poscuánticas para sus paquetes.

La siguiente sección abarca los cambios en PQC en la seguridad de la capa de transporte (TLS), seguida de una sección que explica un cambio en las políticas de cifrado predeterminadas de RHEL. ¿Sabías que RHEL es la primera distribución importante de Linux que firma sus paquetes con claves híbridas poscuánticas?

En la tercera sección, se tratan los detalles de estos cambios y, por último, se recomiendan los próximos pasos para los usuarios y los proveedores de software de terceros.

Criptografía poscuántica en TLS

TLS puede usar la criptografía poscuántica en dos lugares: el intercambio de claves, que protege contra ataques de tipo "recolectar ahora, descifrar después", y las firmas, lo que evita los ataques de máquina en medio que utilizan computadoras cuánticas. Con el lanzamiento de RHEL 10.1, las aplicaciones que usan OpenSSL, GnuTLS, NSS o el lenguaje de programación Go ahora son compatibles con el intercambio de claves poscuánticas habilitado de forma predeterminada.

Las bibliotecas de cifrado OpenSSL, GnuTLS y NSS también admiten firmas y certificados TLS con el algoritmo de firma digital basado en entramado modular (ML-DSA), un algoritmo de PQC estandarizado por el NIST. Ten en cuenta que, en la actualidad, ninguna autoridad de certificación (CA) pública ofrece criptografía poscuántica, pero hoy se pueden crear CA privadas o certificados autofirmados con ML-DSA.

En RHEL 10.0, esta funcionalidad se lanzó como Technology Preview debido a la rápida evolución de los estándares y las implementaciones. Ahora esto está cambiando: la criptografía poscuántica con el mecanismo de encapsulación de claves basado en entramado modular (ML-KEM) y ML-DSA en TLS está disponible de forma general y totalmente soportada en Go, OpenSSL, GnuTLS y NSS.

En el período previo a RHEL 10.1, los desarrolladores de Red Hat realizaron un esfuerzo de prueba en todo el producto del intercambio de claves PQC y los certificados PQC. Esto ayudó a identificar varios problemas que los responsables del mantenimiento de los paquetes solucionaron en los proyectos open source upstream y downstream en RHEL. Te recomendamos que empieces a probar el intercambio de claves PQC híbrido en tus implementaciones de TLS hoy mismo, y que hagas planes para servidores de certificados TLS duales clásicos/PQC (consulta “Creating a post-quantum TLS certificate”).

Política de PQC por DEFAULT

La configuración de cifrado en RHEL se gestiona mediante políticas criptográficas de todo el sistema, siendo DEFAULT la política estándar. En RHEL 10.1, esta política ha cambiado para habilitar y preferir la criptografía poscuántica de forma predeterminada. Esto significa que las conexiones TLS y SSH desde y hacia RHEL 10.1 o versiones posteriores utilizarán automáticamente el intercambio de claves poscuánticas cuando esté disponible. Estos dos protocolos se utilizan mucho y es probable que representen la mayoría de las transferencias de datos cifrados, lo que supone un aumento significativo en la postura de seguridad.

Las aplicaciones en RHEL 9.7 basadas en OpenSSL o NSS también pueden usar PQC en TLS si el módulo de política criptográfica para todo el sistema “PQ” se habilita mediante sudo update-crypto-policies --set DEFAULT:PQ.

Para verificar la política que utiliza tu sistema, ejecuta update-crypto-policies --show.

Actualizaciones de paquetes con firmas poscuánticas

Por último, los desarrolladores de Red Hat han estado trabajando para introducir protecciones contra ataques basados en computadoras cuánticas para nuestras rutas de distribución de software. Esto es importante porque las actualizaciones de paquetes a través de estas rutas serán la forma en que Red Hat ofrezca futuras mejoras en la transición poscuántica.

Red Hat Enterprise Linux 10 utiliza la implementación Sequoia-PGP de OpenPGP para verificar las firmas de los paquetes. Una especificación para usar PQC en OpenPGP está en sus etapas finales, y Red Hat ha contribuido con fondos para su implementación en Sequoia-PGP, que ahora está disponible como versión preliminar. Algunos entornos operativos enfrentan requisitos normativos para la firma de software PQC en plazos cortos, por lo que, tras pruebas exhaustivas, RHEL 10.1 ahora incluye esta implementación.

En el mismo proyecto, las herramientas sq-cryptoki y sq obtuvieron compatibilidad para acceder a las claves poscuánticas a través de PKCS#11. Esto permite la integración con módulos de seguridad de hardware. Red Hat ha modernizado su infraestructura de firma, ha creado una clave de firma poscuántica que utiliza un híbrido de ML-DSA-87 y Ed448, y ha comenzado a firmar sus paquetes RPM con esta clave. RHEL es la primera y, actualmente, la única distribución importante de Linux en alcanzar este hito.

El primer paquete firmado poscuánticamente fue ipmitool-1.8.19-10.el10_1 en RHBA-2025:23156:

# dnf download ipmitool
ipmitool-1.8.19-10.el10_1.aarch64.rpm                                                                                                                                                                           
# rpm -Kv ipmitool-1.8.19-10.el10_1.aarch64.rpm | head -3
ipmitool-1.8.19-10.el10_1.aarch64.rpm:
    Header V6 ML-DSA-87+Ed448/SHA512 Signature, key ID 05707a62: OK
    Header V4 RSA/SHA256 Signature, key ID fd431d51: OK

Ten en cuenta que este paquete también está firmado por nuestra clave RSA. Los sistemas que comprenden el formato de encabezado RPM 6 y las firmas OpenPGP v6 verificarán las firmas RSA y PQC. Los sistemas más antiguos solo validarán la firma RSA clásica.

Conclusión

Red Hat ha dado pasos importantes en su transición poscuántica para preparar a nuestros clientes para los riesgos y requisitos normativos futuros. TLS con intercambio de claves híbrido ML-KEM ya no está en Technology Preview y, actualmente, puede mitigar los ataques de “recolectar ahora, descifrar después”. La compatibilidad con certificados y firmas ML-DSA en las bibliotecas de criptografía principales de RHEL OpenSSL, GnuTLS y NSS también está disponible de forma general.

En consonancia con los recientes impulsos de la industria (por ejemplo, la Ley Europea de Resiliencia Cibernética) para la seguridad por defecto, la configuración estándar ha cambiado para habilitar y preferir los algoritmos poscuánticos en TLS y SSH. En el futuro, se añadirán más protocolos. Animamos a todos nuestros usuarios a implementar el intercambio de claves PQC y a probar configuraciones de certificados TLS duales clásicos/PQC con sus servidores TLS. También es posible que desees obtener información sobre cómo preparar a tu organización para el futuro cuántico.

Por último, RHEL es la primera distribución importante que añade firmas poscuánticas híbridas a sus paquetes. Mi colega Jakub Jelen ha documentado cómo firmar paquetes RPM con claves poscuánticas para nuestros socios. Actualmente, es posible la integración con módulos de seguridad de hardware a través de PKCS#11 3.2 para la firma de RPM. Nuestros equipos de soporte e ingeniería pueden ayudarte a empezar con ello.

Actualmente, Go solo es compatible con ML-KEM a partir de la versión 1.24. Se prevé la compatibilidad con ML-DSA en una futura versión.