Creación de una autoridad de certificación poscuántica con los certificados de árbol de Merkle

Cuando escribes una dirección en el navegador, ¿cómo sabes que te estás conectando a la página web correcta? La infraestructura de clave pública de la Web (Web PKI) es ese ecosistema complejo y distribuido de políticas, protocolos y operadores de infraestructura que te ayuda a confiar en que no te están redirigiendo a una página web incorrecta o maliciosa. En las últimas décadas, este ecosistema ha sufrido cambios importantes. Uno de ellos es la incorporación de la transparencia: el requisito, ahora obligatorio, de que todos los certificados se registren en registros públicos de transparencia de certificados. Ahora se enfrenta a otro reto: la inminente llegada de un ordenador cuántico, lo que nos ha llevado a dar el salto a la criptografía poscuántica (PQ) para 2029.

Esta transición no es sencilla: limitarse a incorporar la criptografía poscuántica en los certificados a escala de Internet provocaría una degradación inaceptable del rendimiento. Este momento exige un nuevo enfoque para la Web PKI, uno que nos permita tratar la transparencia como una propiedad propia en lugar de un complemento, y diseñar un nuevo sistema que escale las firmas poscuánticas de manera eficiente.

Tras obtener un amplio apoyo en todo el sector, los certificados de árbol de Merkle (MTC) se han perfilado como el camino a seguir. Este año, tras una exitosa implementación experimental con Chrome, Cloudflare avanza a toda máquina con los MTC.

Tras el anuncio de hoy de que Cloudflare se convierte en una autoridad de certificación (CA), nos complace compartir que esta CA admitirá la emisión de MTC, con el objetivo de incluirlos a principios de 2027 en el recién lanzado almacén de raíces resistente a la computación poscuántica de Chrome. Como parte de nuestra misión de ayudar a mejorar Internet mejor, y siguiendo la tradición de Cloudflare de ofrecer la criptografía más sólida disponible de forma gratuita, ofreceremos la emisión de MTC estándar sin coste alguno. Contar con una CA que admita tanto la emisión de certificados clásicos como de MTC nos permite establecer por defecto el método de autenticación más seguro disponible, proporcionando una ruta de actualización a PQ sencilla y eficaz para una gran parte de Internet.

El ecosistema de confianza actual

Para entender cómo los MTC están cambiando las reglas del juego, empecemos por explicar un poco cómo funciona la confianza en la web hoy en día.

Por el lado del cliente, los navegadores —en este caso, los “clientes TLS”— mantienen programas raíz, que especifican un conjunto de políticas que las CA deben seguir para que se confíe en ellas. Por el lado del servidor, las CA son los guardianes de confianza: gestionan la infraestructura de emisión de certificados, donde validan la propiedad del dominio y certifican la vinculación entre un nombre de dominio y una clave pública que demuestra la propiedad de ese dominio.

Pero, ¿cómo comprobamos que las CA siguen las reglas? Aquí entra en juego la transparencia de certificados (CT), que hace que la emisión de certificados sea auditable públicamente. Cuando una CA emite un certificado, también debe enviarlo a al menos dos registros públicos. Cloudflare lleva gestionando la familia de registros de CT Nimbus desde 2016 y, de cara al futuro, va a lanzar Raio, una nueva familia de registros CT estáticos.

Aunque el ecosistema de CT permite ver los certificados públicamente, eso no significa que estén emitidos correctamente o que sean seguros de usar. La monitorización ayuda en este sentido al comparar esos registros con lo que esperaban los propietarios de los dominios y al informar de actividades sospechosas. Cloudflare lanzó la supervisión de la transparencia de certificados en 2019 y recientemente la ha puesto a disposición de todos. También publicamos mediciones a gran escala sobre certificados en la página de transparencia de certificados de Radar (antes conocido como Merkle Town).

A medida que las organizaciones empiecen a actualizar sus servidores para usar la autenticación poscuántica, la supervisión de la transparencia de certificados cobrará aún más importancia a la hora de detectar posibles retrocesos poscuánticos. Los propietarios de dominios que hayan actualizado sus dominios a la autenticación poscuántica deberían supervisar los registros de CT en busca de certificados heredados emitidos de forma inesperada para evitar que los clientes caigan en una ruta de degradación maliciosa.

Parte del problema con el sistema actual es que la transparencia era un complemento, lo que provocaba problemas de escalabilidad. Los certificados suelen registrarse varias veces, en diferentes formatos, en múltiples registros, lo que obliga a los supervisores a descargar y procesar cada registro para no pasar por alto ninguna emisión. Esto puede resultar caro, lo que dificulta fomentar una amplia variedad de operadores de registros a escala de Internet. Según nuestras estimaciones, las firmas poscuánticas multiplicarán por 40 la cantidad de datos que deben almacenar los registros CT. Este reto de escalabilidad, y la consiguiente falta de alineación de incentivos, es el núcleo del problema de escalabilidad poscuántica.

El problema de escalabilidad poscuántica

Hemos escrito mucho sobre los retos de escalar la criptografía poscuántica, pero en resumen: para permitir la autenticación de servidores a escala de Internet, la Web PKI debe autenticar aproximadamente 1000 millones de servidores TLS sin tener que precargar la clave pública de cada servidor en cada cliente. Tradicionalmente, las CA abordaban este problema utilizando cadenas de certificados como mecanismo de distribución de confianza. Pero con el tiempo, novedades como las comprobaciones de revocación de claves y la transparencia de certificados han añadido más claves públicas y firmas: cinco firmas y dos claves en un protocolo de enlace TLS típico. Las firmas poscuánticas son aproximadamente 40 veces más grandes que las clásicas, lo que genera una sobrecarga mayor que resultaría costosa de gestionar a gran escala para los clientes, las CA, los registros y los monitores.

Aquí es donde entran en juego los certificados de árbol de Merkle (MTC), un borrador de especificación del grupo de trabajo IETF PLANTS que describe una arquitectura para certificados poscuánticos compactos y eficientes. Los MTC agrupan los certificados en un árbol de Merkle de solo añadir, lo que permite a una CA firmar la raíz de ese árbol en lugar de muchos certificados individuales. Esto permite que los navegadores u otros clientes verifiquen un certificado mediante una prueba de inclusión compacta —una secuencia de hash criptográficos— comparándola con la raíz firmada del árbol, en lugar de validar cada certificado por separado. Una idea clave detrás de los MTC es “no registres lo que emites, emite registrando”. Al unir la emisión y el registro, la transparencia se convierte en un requisito para el funcionamiento, en lugar de un complemento.

El papel de una autoridad de certificación en una PKI rediseñada

Estamos desarrollando nuestra capacidad para emitir MTC como parte integral de la creación de una CA de Cloudflare. Eso significa estar al tanto de los nuevos requisitos del Programa de Raíces PQ y desarrollar una pila de software de emisión y replicación al mismo tiempo que creamos las instalaciones, las operaciones y las funciones de cumplimiento de una CA tradicional —¡nada fácil!

La ventaja es que podemos priorizar los requisitos y la arquitectura de esta nueva PKI poscuántica desde el primer día, construyendo nuestra infraestructura de una forma que se ajuste a los valores y a la red global de Cloudflare, con el objetivo de ser lo más transparentes posible al embarcarnos en este nuevo viaje.

Echemos un vistazo a la arquitectura actualizada para los MTC:

Si lo comparas con el ecosistema tradicional de las CA, verás que las responsabilidades de una CA siguen siendo prácticamente las mismas: validar el control de un dominio, vincularlo a una clave pública y emitir certificados. La principal diferencia es que, en el ecosistema MTC, en lugar de firmar los certificados directamente y luego registrarlos, la CA ahora mantiene un registro de transparencia respaldado por un árbol de Merkle, donde una prueba de inclusión que confirma que el certificado está efectivamente en el árbol sirve como ancla de confianza. Las CA también gestionarán cofirmantes espejo que almacenan una copia de los registros de emisión, verificando su consistencia de “solo añadir” y garantizando la transparencia y disponibilidad de estos registros para el ecosistema en general.

Emisión de MTC

Los MTC pueden presentarse en dos formas, ambas codificables en el formato de certificado X.509 que el software de cliente reconoce hoy en día, solo que con un algoritmo de firma “curioso”. En su forma autónoma, el valor de la firma del certificado contiene una cabeza de árbol firmada conjuntamente de un registro de emisión y una prueba de inclusión (una secuencia de hash) que demuestra que el certificado está incluido en ese registro. Si los clientes pueden obtener las cabeceras de árbol firmadas conjuntamente fuera de banda (por ejemplo, a través de un mecanismo de actualización del navegador), el certificado se puede servir en formato relativo a un hito, donde el valor de la firma consiste en la prueba de inclusión ligera, sin ninguna firma poscuántica pesada.

Para simplificar, echemos un vistazo a un ejemplo de emisión de certificados independientes. Cuando un sitio web quiere un certificado para su dominio, puede solicitarlo a una CA a través del protocolo ACME (Entorno Automatizado de Gestión de Certificados), que se encarga de las solicitudes de certificados, la validación del control del dominio y los flujos de trabajo de emisión. La infraestructura ACME de Cloudflare será una bifurcación de Boulder, el software ACME ampliamente implantado y bien probado que utiliza Let’s Encrypt. Let's Encrypt está desarrollando activamente la compatibilidad con MTC en Boulder, y tenemos pensado mantener nuestra propia bifurcación que incorpore estos cambios del proyecto original junto con modificaciones específicas de Cloudflare, contribuyendo al proyecto original siempre que sea posible.

Cuando la CA de MTC recibe una solicitud de emisión de certificado, el servidor ACME de la CA comprueba que el servidor controle realmente el dominio. Si se superan esas comprobaciones, la CA serializa esos datos y los añade a un registro de solo apéndice.

Tras añadir la entrada de MTC a su registro de emisión, la CA calcula el estado actualizado del registro y, a continuación, firma un punto de control sobre ese estado. Este punto de control certifica que la CA ha emitido todas las entradas incluidas en el árbol de Merkle del registro hasta ese momento.

A continuación, la CA envía el estado actualizado de su registro y el nuevo punto de control a un segundo firmante de confianza, que almacena de forma permanente una copia del registro de emisión de la CA y comprueba que cada nuevo estado sea de solo adición, coherente con el árbol anterior y esté correctamente formado. Esta firma adicional te da a ti, como cliente, y a los supervisores la confianza de que otra parte de confianza ha observado el mismo estado del registro y ha verificado que la CA no está mostrando visiones diferentes de las emisiones a distintas partes del ecosistema. También garantiza que los certificados emitidos estarán disponibles para su supervisión incluso si el registro de emisión de la CA no está disponible.

El borrador de la política del Programa de Raíces Resistentes al Cuántico de Chrome exige al menos dos firmas conjuntas: una de un cofirmante espejo reconocido por Chrome y gestionado por una organización distinta, y otra de la propia CA MTC emisora. Por eso, gestionaremos servidores espejo para otras CA piloto y exigiremos al menos una firma conjunta independiente en los certificados que emitamos nosotros mismos.

Cloudflare implementará nuestro firmante espejo en Azul, nuestro registro de transparencia de código abierto basado en Rust, y, para lograr la máxima interoperabilidad, implementará el protocolo tlog mirror de c2sp.

Por último, tras recibir con éxito una firma conjunta de un firmante espejo, la CA genera un MTC con las firmas conjuntas, la clave pública del servidor y una prueba de inclusión. A continuación, envía ese MTC al servidor, ¡que ya podrá utilizarlo para TLS en adelante!

Entrega eficiente de firmas PQ: la optimización de los puntos de referencia

Aunque los certificados independientes funcionan, siguen enviando grandes firmas PQ durante el protocolo de enlace TLS, lo que limita su eficiencia. Las verdaderas mejoras de rendimiento que aporta el diseño del MTC son los certificados relativos a puntos de referencia.

En lugar de enviar firmas conjuntas en cada certificado, las CA pueden designar como punto de referencia una secuencia de subárboles que cubran todos los certificados activos del registro, y distribuir esos subárboles (junto con los datos para autenticarlos) a los clientes a través de un servicio de actualización fuera de banda. Durante un protocolo de enlace TLS, la autenticación real con el servidor se produce cuando el navegador comprueba que los datos del certificado del servidor —incluidos su nombre de dominio y su clave pública— aparecen en un subárbol de confianza del registro de la CA. Si la prueba de inclusión vincula ese certificado a un punto de referencia firmado conjuntamente, y la clave pública demuestra entonces su posesión durante el protocolo de enlace TLS, el cliente sabe que se está comunicando con el servidor correcto.

Al transmitir periódicamente estas firmas y los metadatos del árbol a los clientes TLS fuera de banda, un pequeño conjunto de firmas por lotes de MTC puede cubrir de forma eficiente miles de millones de certificados emitidos por una CA determinada. Aunque los puntos de referencia son más eficientes a escala, no eliminan la necesidad de MTC independientes: los clientes pueden estar recién instalados, sin conexión o carecer de la actualización relevante del punto de referencia. Por eso es importante que los servidores mantengan un certificado de reserva independiente.

Los MTC en la práctica: resultados de nuestro experimento con Chrome

Este año, hicimos un experimento con Chrome para comprobar si los MTC funcionaban entre un cliente y un servidor. Pusimos en marcha una “CA de arranque” (una CA falsa que simulaba el proceso de emisión) que emitía MTC respaldados por una cadena de certificados tradicional para una selección de dominios de Cloudflare en el plan gratuito de Cloudflare y los servimos al 50 % de los usuarios de Chrome Beta 146. A lo largo del experimento, servimos con éxito miles de millones de MTC.

En cuanto a TLS, descubrimos que el caso habitual es bastante eficiente: con un certificado relativo a un punto de referencia, el protocolo de enlace solo tiene que transmitir una clave pública, una firma y una prueba de inclusión de menos de 1 kB. En el experimento, recurrimos a la cadena de certificados tradicional en lugar de servir un certificado independiente en los casos en los que no pudimos negociar un certificado relativo a un punto de referencia con el cliente. En cuanto a CT, los MTC también cambian las propiedades de escalabilidad de la transparencia: el registro solo tiene que contener los hash de las claves públicas; no hay firmas por entrada, y la firma en la raíz del árbol cubre todo el registro. Esto evita la “explosión de certificados”, ya que el registro de emisión de la CA es la fuente de verdad para todos los certificados que emite la CA, y los usuarios del registro solo tienen que obtener una única copia de cada certificado.

El resultado: ¡los MTC realmente funcionan! En la mediana, el uso de un MTC es un 9 % más rápido con MTC de puntos de referencia que con una cadena de firmas clásica (aunque hay que reconocer que la mayor parte de esta mejora de rendimiento se debe a la eliminación de pasos intermedios). Y como hemos probado los MTC con firmas clásicas, esperamos una mejora aún mayor con las firmas poscuánticas. Satisfechos con estos resultados y con el nivel de colaboración intersectorial en torno a los MTC en el PLANTS WG de la IETF, empezamos a dar por concluido el experimento el mes pasado (agosto de 2026).

El futuro de los MTC

Nos alegra mucho que nuestro experimento con Chrome haya demostrado que los MTC funcionan en la práctica, y nos hace especial ilusión poder emitir certificados como una CA de verdad.

Sin embargo, aún quedan cuestiones más amplias que solo podremos resolver llevando a cabo este gran experimento con todo el ecosistema PKI. ¿Podrán los supervisores independientes consultar y verificar los registros de emisión de MTC a escala real? ¿Surgirán múltiples CA y firmantes conjuntos para que el sistema cuente con la diversidad necesaria para su resiliencia? ¿Cómo deberían los navegadores equilibrar las ventajas de rendimiento de los MTC compactos con puntos de referencia con las rutas alternativas necesarias para los clientes que no dispongan de puntos de referencia actualizados? Los MTC se han consolidado como el diseño de referencia para la autenticación poscuántica, pero demostrarlo a escala real de Internet requerirá la participación de un conjunto diverso de programas raíz, proveedores de navegadores, CA, servidores espejo, supervisores y la comunidad en general.

Consideramos un honor poder participar en esta nueva fase de la Web PKI  y nos tomamos muy en serio la responsabilidad de gestionar la infraestructura de la CA. Las CA ocupan una posición privilegiada en el ecosistema de confianza: los navegadores, los propietarios de dominios y la gente de a pie confían en ellas para validar identidades correctamente, proteger las claves de firma, cumplir las políticas y funcionar de forma fiable. Antes de que los navegadores puedan confiar en la CA de Cloudflare para emitir MTC, tendremos que solicitar nuestra inclusión en el almacén raíz resistente a la computación cuántica de Chrome y someternos a un riguroso proceso de evaluación. Acogemos con agrado ese escrutinio y esperamos cumplir con los mismos altos estándares que cualquier otra CA a la que se le confíe la tarea de ayudar a proteger Internet. Esperamos que surjan otras CA para apoyar la adopción de los MTC, y estamos deseando colaborar con cualquier navegador que quiera implementar MTC.