Análisis detallado de la compatibilidad con la criptografía post-cuántica en el plano de control de Red Hat OpenShift 4.20

Se acerca la era de la informática cuántica, y su inmenso poder de procesamiento supone una gran amenaza para las bases criptográficas de nuestro mundo digital. En este artículo, analizaremos la nueva compatibilidad con la criptografía post-cuántica (PQC) en Red Hat OpenShift 4.20 y nos centraremos en la forma en que mejora los elementos principales del plano de control de Kubernetes: el API server, el kubelet, el programador y el controlador-gestor. Falta etcd, ya que se utiliza una versión anterior de Go.

La amenaza cuántica

Los sistemas criptográficos de clave pública que se utilizan ampliamente en la actualidad, como RSA y la criptografía de curva elíptica (ECC), constituyen la base de las comunicaciones en línea con seguridad mejorada. Sin embargo, estos sistemas son vulnerables a los ataques de las computadoras cuánticas a gran escala, las cuales pueden resolver los problemas matemáticos que subyacen a estos algoritmos a una velocidad alarmante. Esto ha dado lugar a ataques en los que los agentes malintencionados registran el tráfico cifrado en la actualidad para descifrarlo en el futuro, una vez que tengan acceso a una computadora cuántica potente. El mismo desafío se aplica a los datos en reposo si un agente malintencionado logra hacer una copia ahora para descifrarla más tarde.

Para hacer frente a esta amenaza, surgió el campo de PQC, que desarrolla nuevos algoritmos criptográficos que son resistentes a los ataques de las computadoras clásicas y cuánticas.

PQC en Kubernetes y OpenShift

Red Hat OpenShift es una distribución de Kubernetes certificada por la Cloud Native Computing Foundation (CNCF), la cual está escrita en el lenguaje de programación Go. Por lo tanto, el proceso para admitir PQC en OpenShift comienza con Go.

La versión Go 1.24 marcó un hito importante al incorporar la compatibilidad con el mecanismo de intercambio de claves híbridas X25519MLKEM768. X25519MLKEM768 es un intercambio de claves híbrido que combina X25519 clásico (curva elíptica de Diffie-Hellman) con ML-KEM-768 (algoritmo poscuántico). El secreto compartido final se deriva de ambos mecanismos combinados. El ML-KEM puro se basa por completo en la criptografía basada en retículos para la resistencia cuántica. X25519MLKEM768 ofrece la resistencia cuántica de ML-KEM y la seguridad clásica de X25519 al mismo tiempo.

El enfoque híbrido es realmente más sólido en este momento. ML-KEM solo se estandarizó en agosto de 2024, lo que significa que se considera «nuevo» en términos criptográficos. Si alguien descubre un ataque clásico inesperado contra los supuestos de retículos de ML-KEM (no cuántico, solo criptoanálisis normal), las implementaciones de ML-KEM puro se verán afectadas. Con la versión híbrida, aún tienes X25519 que resiste.

El secreto compartido resultante para una sesión de seguridad de la capa de transporte (TLS) proporciona el nivel de seguridad esperado, siempre que al menos uno de los algoritmos del componente permanezca intacto. Esto ofrece una forma sólida y compatible con versiones posteriores de incorporar PQC en el ecosistema.

Aplicación de PQC al plano de control de OpenShift

El soporte para PQC en OpenShift 4.20 no se trata de configurar indicadores de PQC específicos en cada elemento de Kubernetes. En cambio, se trata de la solidez de la comunicación TLS entre estos elementos, que está habilitada por la versión subyacente de Go y sus bibliotecas criptográficas.

Así es como el soporte de PQC mejora la seguridad de la comunicación entre los elementos principales de OpenShift (el estado de etcd se analiza por separado a continuación):

• API server: al ser el eje central del plano de control de Kubernetes, toda la comunicación hacia y desde el API server es un punto de seguridad fundamental. Con el TLS habilitado para ML-KEM, la comunicación del plano de control está protegida de los ataques que registran el tráfico cifrado en la actualidad y planean descifrarlo en el futuro.
• Kubelet: el kubelet, que se ejecuta en cada nodo, se comunica con el servidor API para proporcionar actualizaciones sobre el estado de los nodos y recibir las especificaciones de los pods. Esta comunicación ahora incorpora un intercambio de claves de PQC híbrido para mejorar la seguridad, lo que ayuda a verificar la integridad y la confidencialidad de este enlace.
• Programador y controlador-gestor: el programador y el controlador-gestor interactúan permanentemente con el API server para tomar decisiones sobre la programación y gestionar el estado del clúster. Estas interacciones también están protegidas por el TLS habilitado para ML-KEM para fortalecer la seguridad de la lógica y las operaciones que mantienen tus aplicaciones en funcionamiento.

La perspectiva de Red Hat

Si bien muchas normativas del sector no exigen el PQC hasta el año 2035, estamos trabajando activamente en la transición a PQC. En un artículo reciente, «Preparing your organization for the quantum future» destacamos la importancia de comenzar el proceso de PQC ahora mismo. Además, el trabajo que se está realizando para integrar PQC en Red Hat Enterprise Linux (RHEL) es un claro indicador de la dirección que tomará OpenShift. La inclusión de las funciones de PQC en OpenShift 4.20 es un gran avance.

Discrepancia entre las versiones de Go

Un aspecto fundamental que deben tener en cuenta los administradores es la posibilidad de que las versiones Go no coincidan entre los distintos elementos de un clúster. Por ejemplo, si un cliente kubectl diseñado con una versión de Go compatible con ML-KEM se comunica con un servidor de API anterior, el protocolo de enlace TLS puede pasar a un algoritmo criptográfico clásico de forma silenciosa. Esto provocaría la pérdida de la protección de PQC sin ninguna advertencia explícita. Por lo tanto, es fundamental confirmar que todos los elementos del entorno de OpenShift ejecuten versiones compatibles que admitan PQC.

¿Qué pasa con etcd?

Si bien los elementos principales del plano de control se benefician del TLS compatible con ML-KEM, la historia de etcd es diferente, ya que se basa en su función y filosofía de desarrollo distintas. Como fuente de información definitiva para todo el clúster, las prioridades absolutas de etcd son la estabilidad, la integridad de los datos y el rendimiento. El proyecto etcd intencionalmente mantiene un cronograma de control de versiones de Go más conservador en comparación con Kubernetes. Mientras que el proyecto de Kubernetes suele adoptar la última versión de Go para utilizar las funciones nuevas y las mejoras de rendimiento con rapidez, el equipo de etcd prioriza la estabilidad y utiliza las versiones de Go más antiguas y probadas para sus versiones estables. Este retraso deliberado ayuda a la comunidad en general a examinar minuciosamente cualquier posible problema en un nuevo tiempo de ejecución de Go antes de que se incorpore a un elemento tan importante como etcd.

La falta de soporte inmediato de PQC no es un descuido, sino una consecuencia directa de este enfoque que prioriza la estabilidad. Antes de que etcd admita oficialmente los algoritmos de PQC, que se introdujeron en Go 1.24, esa versión de Go primero debe adoptarse en las ramas de lanzamiento estables de etcd, que actualmente todavía usan Go 1.23. Este proceso implica una validación exhaustiva para confirmar que no haya un impacto negativo en el protocolo de consenso de Raft, la latencia de E/S o las operaciones de recuperación. La compatibilidad con quantum-safe en etcd llegará en una versión futura.

El camino por recorrer

La integración de PQC en OpenShift 4.20 es una prueba del enfoque preventivo que adopta Red Hat para desarrollar un futuro listo para la tecnología cuántica para la informática nativa de la nube. Si bien el PQC para las firmas y los certificados digitales aún se encuentra en sus primeras etapas, la implementación del intercambio de claves híbridas en TLS es un primer paso fundamental.